<?xml version="1.0" encoding="UTF-8"?>
<updates>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2001</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44267" id="CVE-2022-44267" title="CVE-2022-44267" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44268" id="CVE-2022-44268" title="CVE-2022-44268" type="cve"></reference>
		</references>
		<description>CVE-2022-44267:ImageMagick 7.1.0-49 is vulnerable to Denial of Service. When it parses a PNG image (e.g., for resize), the convert process could be left waiting for stdin input.&#xA;CVE-2022-44268:ImageMagick 7.1.0-49 is vulnerable to Information Disclosure. When it parses a PNG image (e.g., for resize), the resulting image could have embedded the content of an arbitrary. file (if the magick binary has permissions to read it).</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-7.1.0.28-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ImageMagick-7.1.0.28-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-devel-7.1.0.28-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ImageMagick-devel-7.1.0.28-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-help-7.1.0.28-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ImageMagick-help-7.1.0.28-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-perl-7.1.0.28-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ImageMagick-perl-7.1.0.28-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-c++-7.1.0.28-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ImageMagick-c++-7.1.0.28-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-c++-devel-7.1.0.28-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ImageMagick-c++-devel-7.1.0.28-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-7.1.0.28-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ImageMagick-7.1.0.28-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-devel-7.1.0.28-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ImageMagick-devel-7.1.0.28-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-help-7.1.0.28-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ImageMagick-help-7.1.0.28-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-perl-7.1.0.28-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ImageMagick-perl-7.1.0.28-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-c++-7.1.0.28-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ImageMagick-c++-7.1.0.28-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="6.u1.fos23" version="7.1.0.28">
					<filename>ImageMagick-c++-devel-7.1.0.28-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ImageMagick-c++-devel-7.1.0.28-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2002</id>
		<title>An update for SDL2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-13"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4743" id="CVE-2022-4743" title="CVE-2022-4743" type="cve"></reference>
		</references>
		<description>CVE-2022-4743:A potential memory leak issue was discovered in SDL2 in GLES_CreateTexture() function in SDL_render_gles.c. The vulnerability allows an attacker to cause a denial of service attack. The vulnerability affects SDL2 v2.0.4 and above. SDL-1.x are not affected.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="SDL2" release="5.u1.fos23" version="2.0.12">
					<filename>SDL2-2.0.12-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/SDL2-2.0.12-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="SDL2-devel" release="5.u1.fos23" version="2.0.12">
					<filename>SDL2-devel-2.0.12-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/SDL2-devel-2.0.12-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="SDL2-static" release="5.u1.fos23" version="2.0.12">
					<filename>SDL2-static-2.0.12-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/SDL2-static-2.0.12-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="SDL2" release="5.u1.fos23" version="2.0.12">
					<filename>SDL2-2.0.12-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/SDL2-2.0.12-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="SDL2-devel" release="5.u1.fos23" version="2.0.12">
					<filename>SDL2-devel-2.0.12-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/SDL2-devel-2.0.12-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="SDL2-static" release="5.u1.fos23" version="2.0.12">
					<filename>SDL2-static-2.0.12-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/SDL2-static-2.0.12-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2003</id>
		<title>An update for amanda is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37704" id="CVE-2022-37704" title="CVE-2022-37704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37705" id="CVE-2022-37705" title="CVE-2022-37705" type="cve"></reference>
		</references>
		<description>CVE-2022-37704:Amanda 3.5.1 allows privilege escalation from the regular user backup to root. The SUID binary located at /lib/amanda/rundump will execute /usr/sbin/dump as root with controlled arguments from the attacker which may lead to escalation of privileges, denial of service, and information disclosure.&#xA;CVE-2022-37705:A privilege escalation flaw was found in Amanda 3.5.1 in which the backup user can acquire root privileges. The vulnerable component is the runtar SUID program, which is a wrapper to run /usr/bin/tar with specific arguments that are controllable by the attacker. This program mishandles the arguments passed to tar binary (it expects that the argument name and value are separated with a space; however, separating them with an equals sign is also supported),</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="amanda" release="23.u2.fos23" version="3.5.1">
					<filename>amanda-3.5.1-23.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/amanda-3.5.1-23.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="amanda-help" release="23.u2.fos23" version="3.5.1">
					<filename>amanda-help-3.5.1-23.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/amanda-help-3.5.1-23.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="amanda" release="23.u2.fos23" version="3.5.1">
					<filename>amanda-3.5.1-23.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/amanda-3.5.1-23.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2004</id>
		<title>An update for apache-commons-fileupload is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24998" id="CVE-2023-24998" title="CVE-2023-24998" type="cve"></reference>
		</references>
		<description>CVE-2023-24998:Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="apache-commons-fileupload" release="2.u1.fos23" version="1.4">
					<filename>apache-commons-fileupload-1.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apache-commons-fileupload-1.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-fileupload-help" release="2.u1.fos23" version="1.4">
					<filename>apache-commons-fileupload-help-1.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apache-commons-fileupload-help-1.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2005</id>
		<title>An update for apr is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24963" id="CVE-2022-24963" title="CVE-2022-24963" type="cve"></reference>
		</references>
		<description>CVE-2022-24963:Integer Overflow or Wraparound vulnerability in apr_encode functions of Apache Portable Runtime (APR) allows an attacker to write beyond bounds of a buffer. This issue affects Apache Portable Runtime (APR) version 1.7.0.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="apr" release="6.u1.fos23" version="1.7.0">
					<filename>apr-1.7.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-1.7.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="apr-devel" release="6.u1.fos23" version="1.7.0">
					<filename>apr-devel-1.7.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-devel-1.7.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apr-help" release="6.u1.fos23" version="1.7.0">
					<filename>apr-help-1.7.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-help-1.7.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr" release="6.u1.fos23" version="1.7.0">
					<filename>apr-1.7.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/apr-1.7.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr-devel" release="6.u1.fos23" version="1.7.0">
					<filename>apr-devel-1.7.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/apr-devel-1.7.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2006</id>
		<title>An update for apr-util is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25147" id="CVE-2022-25147" title="CVE-2022-25147" type="cve"></reference>
		</references>
		<description>CVE-2022-25147:Integer Overflow or Wraparound vulnerability in apr_base64 functions of Apache Portable Runtime Utility (APR-util) allows an attacker to write beyond bounds of a buffer. This issue affects Apache Portable Runtime Utility (APR-util) 1.6.1 and prior versions.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="apr-util" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-1.6.1-14.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-util-1.6.1-14.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="apr-util-devel" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-devel-1.6.1-14.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-util-devel-1.6.1-14.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="apr-util-pgsql" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-pgsql-1.6.1-14.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-util-pgsql-1.6.1-14.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="apr-util-odbc" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-odbc-1.6.1-14.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/apr-util-odbc-1.6.1-14.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr-util" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-1.6.1-14.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/apr-util-1.6.1-14.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr-util-devel" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-devel-1.6.1-14.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/apr-util-devel-1.6.1-14.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr-util-pgsql" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-pgsql-1.6.1-14.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/apr-util-pgsql-1.6.1-14.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr-util-odbc" release="14.u1.fos23" version="1.6.1">
					<filename>apr-util-odbc-1.6.1-14.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/apr-util-odbc-1.6.1-14.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2007</id>
		<title>An update for batik is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-03"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41704" id="CVE-2022-41704" title="CVE-2022-41704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42890" id="CVE-2022-42890" title="CVE-2022-42890" type="cve"></reference>
		</references>
		<description>CVE-2022-41704:A vulnerability in Batik of Apache XML Graphics allows an attacker to run untrusted Java code from an SVG. This issue affects Apache XML Graphics prior to 1.16. It is recommended to update to version 1.16.&#xA;CVE-2022-42890:A vulnerability in Batik of Apache XML Graphics allows an attacker to run Java code from untrusted SVG via JavaScript. This issue affects Apache XML Graphics prior to 1.16. Users are recommended to upgrade to version 1.16.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="batik" release="8.u1.fos23" version="1.10">
					<filename>batik-1.10-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/batik-1.10-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="batik-help" release="8.u1.fos23" version="1.10">
					<filename>batik-help-1.10-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/batik-help-1.10-8.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2008</id>
		<title>An update for byacc is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33641" id="CVE-2021-33641" title="CVE-2021-33641" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33642" id="CVE-2021-33642" title="CVE-2021-33642" type="cve"></reference>
		</references>
		<description>CVE-2021-33641:When processing files, malloc stores the data of the current line. When processing comments, malloc incorrectly accesses the released memory (use after free).&#xA;CVE-2021-33642:When a file is processed, an infinite loop occurs in next_inline() of the more_curly() function.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="byacc" release="4.u1.fos23" version="2.0.20210808">
					<filename>byacc-2.0.20210808-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/byacc-2.0.20210808-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="byacc-help" release="4.u1.fos23" version="2.0.20210808">
					<filename>byacc-help-2.0.20210808-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/byacc-help-2.0.20210808-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="byacc" release="4.u1.fos23" version="2.0.20210808">
					<filename>byacc-2.0.20210808-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/byacc-2.0.20210808-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2009</id>
		<title>An update for c-ares is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4904" id="CVE-2022-4904" title="CVE-2022-4904" type="cve"></reference>
		</references>
		<description>CVE-2022-4904:A flaw was found in the c-ares package. The ares_set_sortlist is missing checks about the validity of the input string, which allows a possible arbitrary length stack overflow. This issue may cause a denial of service or a limited impact on confidentiality and integrity.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="c-ares" release="5.u2.fos23" version="1.18.1">
					<filename>c-ares-1.18.1-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/c-ares-1.18.1-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="c-ares-devel" release="5.u2.fos23" version="1.18.1">
					<filename>c-ares-devel-1.18.1-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/c-ares-devel-1.18.1-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="c-ares-help" release="5.u2.fos23" version="1.18.1">
					<filename>c-ares-help-1.18.1-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/c-ares-help-1.18.1-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="c-ares" release="5.u2.fos23" version="1.18.1">
					<filename>c-ares-1.18.1-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/c-ares-1.18.1-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="c-ares-devel" release="5.u2.fos23" version="1.18.1">
					<filename>c-ares-devel-1.18.1-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/c-ares-devel-1.18.1-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2010</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3650" id="CVE-2022-3650" title="CVE-2022-3650" type="cve"></reference>
		</references>
		<description>CVE-2022-3650:A privilege escalation flaw was found in Ceph. Ceph-crash.service allows a local attacker to escalate privileges to root in the form of a crash dump, and dump privileged information.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="2" name="ceph" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-base" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-base-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephadm" release="14.u6.fos23" version="16.2.7">
					<filename>cephadm-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cephadm-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-common" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-common-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mds" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mds-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mon" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mon-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mgr" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-dashboard" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-dashboard-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-dashboard-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-diskprediction-local" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-diskprediction-local-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-diskprediction-local-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-modules-core" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-modules-core-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-modules-core-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-rook" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-rook-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-rook-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-k8sevents" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-k8sevents-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-k8sevents-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-cephadm" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-cephadm-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-mgr-cephadm-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-fuse" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-fuse-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="cephfs-mirror" release="14.u6.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cephfs-mirror-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-fuse" release="14.u6.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rbd-fuse-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-mirror" release="14.u6.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rbd-mirror-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-immutable-object-cache" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-immutable-object-cache-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-nbd" release="14.u6.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rbd-nbd-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-radosgw" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-radosgw-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephfs-top" release="14.u6.fos23" version="16.2.7">
					<filename>cephfs-top-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cephfs-top-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-osd" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-osd-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados2" release="14.u6.fos23" version="16.2.7">
					<filename>librados2-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/librados2-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados-devel" release="14.u6.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/librados-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradospp-devel" release="14.u6.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libradospp-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw2" release="14.u6.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/librgw2-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw-devel" release="14.u6.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/librgw-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rgw" release="14.u6.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-rgw-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rados" release="14.u6.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-rados-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite" release="14.u6.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libcephsqlite-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite-devel" release="14.u6.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libcephsqlite-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd1" release="14.u6.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/librbd1-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd-devel" release="14.u6.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/librbd-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rbd" release="14.u6.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-rbd-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs2" release="14.u6.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libcephfs2-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs-devel" release="14.u6.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libcephfs-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-cephfs" release="14.u6.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-cephfs-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-argparse" release="14.u6.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-ceph-argparse-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-common" release="14.u6.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-ceph-common-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-test" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-test-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rados-objclass-devel" release="14.u6.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rados-objclass-devel-16.2.7-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-grafana-dashboards" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-grafana-dashboards-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-grafana-dashboards-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-prometheus-alerts" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-prometheus-alerts-16.2.7-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ceph-prometheus-alerts-16.2.7-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-base" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-base-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-common" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-common-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mds" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-mds-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mon" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-mon-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mgr" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-mgr-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-fuse" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-fuse-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="cephfs-mirror" release="14.u6.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/cephfs-mirror-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-fuse" release="14.u6.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rbd-fuse-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-mirror" release="14.u6.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rbd-mirror-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-immutable-object-cache" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-immutable-object-cache-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-nbd" release="14.u6.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rbd-nbd-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-radosgw" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-radosgw-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-osd" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-osd-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados2" release="14.u6.fos23" version="16.2.7">
					<filename>librados2-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/librados2-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados-devel" release="14.u6.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/librados-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradospp-devel" release="14.u6.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libradospp-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw2" release="14.u6.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/librgw2-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw-devel" release="14.u6.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/librgw-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rgw" release="14.u6.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-rgw-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rados" release="14.u6.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-rados-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite" release="14.u6.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libcephsqlite-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite-devel" release="14.u6.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libcephsqlite-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd1" release="14.u6.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/librbd1-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd-devel" release="14.u6.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/librbd-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rbd" release="14.u6.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-rbd-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs2" release="14.u6.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libcephfs2-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs-devel" release="14.u6.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libcephfs-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-cephfs" release="14.u6.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-cephfs-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-argparse" release="14.u6.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-ceph-argparse-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-common" release="14.u6.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-ceph-common-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-test" release="14.u6.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ceph-test-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rados-objclass-devel" release="14.u6.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rados-objclass-devel-16.2.7-14.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2011</id>
		<title>An update for clamav is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20032" id="CVE-2023-20032" title="CVE-2023-20032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20052" id="CVE-2023-20052" title="CVE-2023-20052" type="cve"></reference>
		</references>
		<description>CVE-2023-20032:On Feb 15, 2023, the following vulnerability in the ClamAV scanning library was disclosed: A vulnerability in the HFS+ partition file parser of ClamAV versions 1.0.0 and earlier, 0.105.1 and earlier, and 0.103.7 and earlier could allow an unauthenticated, remote attacker to execute arbitrary code. This vulnerability is due to a missing buffer size check that may result in a heap buffer overflow write. An attacker could exploit this vulnerability by submitting a crafted HFS+ partition file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to execute arbitrary code with the privileges of the ClamAV scanning process, or else crash the process, resulting in a denial of service (DoS) condition. For a description of this vulnerability, see the ClamAV blog [&#34;https://blog.clamav.net/&#34;].&#xA;CVE-2023-20052:On Feb 15, 2023, the following vulnerability in the ClamAV scanning library was disclosed: A vulnerability in the DMG file parser of ClamAV versions 1.0.0 and earlier, 0.105.1 and earlier, and 0.103.7 and earlier could allow an unauthenticated, remote attacker to access sensitive information on an affected device. This vulnerability is due to enabling XML entity substitution that may result in XML external entity injection. An attacker could exploit this vulnerability by submitting a crafted DMG file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to leak bytes from any file that may be read by the ClamAV scanning process.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="clamav" release="1.fos23" version="0.103.8">
					<filename>clamav-0.103.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-0.103.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-devel" release="1.fos23" version="0.103.8">
					<filename>clamav-devel-0.103.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-devel-0.103.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-help" release="1.fos23" version="0.103.8">
					<filename>clamav-help-0.103.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-help-0.103.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-filesystem" release="1.fos23" version="0.103.8">
					<filename>clamav-filesystem-0.103.8-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-filesystem-0.103.8-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-data" release="1.fos23" version="0.103.8">
					<filename>clamav-data-0.103.8-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-data-0.103.8-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-update" release="1.fos23" version="0.103.8">
					<filename>clamav-update-0.103.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-update-0.103.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamd" release="1.fos23" version="0.103.8">
					<filename>clamd-0.103.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamd-0.103.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-milter" release="1.fos23" version="0.103.8">
					<filename>clamav-milter-0.103.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/clamav-milter-0.103.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav" release="1.fos23" version="0.103.8">
					<filename>clamav-0.103.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/clamav-0.103.8-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-devel" release="1.fos23" version="0.103.8">
					<filename>clamav-devel-0.103.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/clamav-devel-0.103.8-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-help" release="1.fos23" version="0.103.8">
					<filename>clamav-help-0.103.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/clamav-help-0.103.8-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-update" release="1.fos23" version="0.103.8">
					<filename>clamav-update-0.103.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/clamav-update-0.103.8-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamd" release="1.fos23" version="0.103.8">
					<filename>clamd-0.103.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/clamd-0.103.8-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-milter" release="1.fos23" version="0.103.8">
					<filename>clamav-milter-0.103.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/clamav-milter-0.103.8-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2012</id>
		<title>An update for containerd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23471" id="CVE-2022-23471" title="CVE-2022-23471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25153" id="CVE-2023-25153" title="CVE-2023-25153" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25173" id="CVE-2023-25173" title="CVE-2023-25173" type="cve"></reference>
		</references>
		<description>CVE-2022-23471:containerd is an open source container runtime. A bug was found in containerd&#39;s CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user&#39;s process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd&#39;s CRI implementation and the stream server is used for handling container IO. This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.&#xA;CVE-2023-25153:containerd is an open source container runtime. Before versions 1.6.18 and 1.5.18, when importing an OCI image, there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file where a limit was not applied could cause a denial of service. This bug has been fixed in containerd 1.6.18 and 1.5.18. Users should update to these versions to resolve the issue. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.&#xA;CVE-2023-25173:containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and 1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. Downstream applications that use the containerd client library may be affected as well. This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd&#39;s client library should check that application for a separate advisory and instructions. As a workaround, ensure that the `&#34;USER $USERNAME&#34;` Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to `ENTRYPOINT [&#34;su&#34;, &#34;-&#34;, &#34;user&#34;]` to allow `su` to properly set up supplementary groups.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="containerd" release="1.u3.fos23" version="1.6.9">
					<filename>containerd-1.6.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/containerd-1.6.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="containerd-stress" release="1.u3.fos23" version="1.6.9">
					<filename>containerd-stress-1.6.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/containerd-stress-1.6.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd" release="1.u3.fos23" version="1.6.9">
					<filename>containerd-1.6.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/containerd-1.6.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd-stress" release="1.u3.fos23" version="1.6.9">
					<filename>containerd-stress-1.6.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/containerd-stress-1.6.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2013</id>
		<title>An update for cryptsetup is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-03"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4122" id="CVE-2021-4122" title="CVE-2021-4122" type="cve"></reference>
		</references>
		<description>CVE-2021-4122:It was found that a specially crafted LUKS header could trick cryptsetup into disabling encryption during the recovery of the device. An attacker with physical access to the medium, such as a flash disk, could use this flaw to force a user into permanently disabling the encryption layer of that medium.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="cryptsetup" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-2.4.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cryptsetup-2.4.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cryptsetup-devel" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-devel-2.4.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cryptsetup-devel-2.4.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="veritysetup" release="4.u2.fos23" version="2.4.1">
					<filename>veritysetup-2.4.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/veritysetup-2.4.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="integritysetup" release="4.u2.fos23" version="2.4.1">
					<filename>integritysetup-2.4.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/integritysetup-2.4.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cryptsetup-reencrypt" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-reencrypt-2.4.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cryptsetup-reencrypt-2.4.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cryptsetup-help" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-help-2.4.1-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/cryptsetup-help-2.4.1-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cryptsetup" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-2.4.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/cryptsetup-2.4.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cryptsetup-devel" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-devel-2.4.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/cryptsetup-devel-2.4.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="veritysetup" release="4.u2.fos23" version="2.4.1">
					<filename>veritysetup-2.4.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/veritysetup-2.4.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="integritysetup" release="4.u2.fos23" version="2.4.1">
					<filename>integritysetup-2.4.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/integritysetup-2.4.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cryptsetup-reencrypt" release="4.u2.fos23" version="2.4.1">
					<filename>cryptsetup-reencrypt-2.4.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/cryptsetup-reencrypt-2.4.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2014</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-03"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43551" id="CVE-2022-43551" title="CVE-2022-43551" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43552" id="CVE-2022-43552" title="CVE-2022-43552" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23914" id="CVE-2023-23914" title="CVE-2023-23914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23915" id="CVE-2023-23915" title="CVE-2023-23915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23916" id="CVE-2023-23916" title="CVE-2023-23916" type="cve"></reference>
		</references>
		<description>CVE-2022-43551:A vulnerability exists in curl &lt;7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) `.`. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.&#xA;CVE-2022-43552:A use after free vulnerability exists in curl &lt;7.87.0. Curl can be asked to *tunnel* virtually all protocols it supports through an HTTP proxy. HTTP proxies can (and often do) deny such tunnel operations. When getting denied to tunnel the specific protocols SMB or TELNET, curl would use a heap-allocated struct after it had been freed, in its transfer shutdown code path.&#xA;CVE-2023-23914:A cleartext transmission of sensitive information vulnerability exists in curl &lt;v7.88.0 that could cause HSTS functionality fail when multiple URLs are requested serially. Using its HSTS support, curl can be instructed to use HTTPS instead of usingan insecure clear-text HTTP step even when HTTP is provided in the URL. ThisHSTS mechanism would however surprisingly be ignored by subsequent transferswhen done on the same command line because the state would not be properlycarried on.&#xA;CVE-2023-23915:A cleartext transmission of sensitive information vulnerability exists in curl &lt;v7.88.0 that could cause HSTS functionality to behave incorrectly when multiple URLs are requested in parallel. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This HSTS mechanism would however surprisingly fail when multiple transfers are done in parallel as the HSTS cache file gets overwritten by the most recentlycompleted transfer. A later HTTP-only transfer to the earlier host name would then *not* get upgraded properly to HSTS.&#xA;CVE-2023-23916:An allocation of resources without limits or throttling vulnerability exists in curl &lt;v7.88.0 based on the &#34;chained&#34; HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with differentalgorithms. The number of acceptable &#34;links&#34; in this &#34;decompression chain&#34; wascapped, but the cap was implemented on a per-header basis allowing a maliciousserver to insert a virtually unlimited number of compression steps simply byusing many headers. The use of such a decompression chain could result in a &#34;malloc bomb&#34;, making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="curl" release="14.u4.fos23" version="7.79.1">
					<filename>curl-7.79.1-14.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/curl-7.79.1-14.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="14.u4.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-14.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libcurl-7.79.1-14.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="14.u4.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-14.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libcurl-devel-7.79.1-14.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="14.u4.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-14.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/curl-help-7.79.1-14.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="14.u4.fos23" version="7.79.1">
					<filename>curl-7.79.1-14.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/curl-7.79.1-14.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="14.u4.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-14.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libcurl-7.79.1-14.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="14.u4.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-14.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libcurl-devel-7.79.1-14.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2015</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-06"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0401" id="CVE-2023-0401" title="CVE-2023-0401" type="cve"></reference>
		</references>
		<description>CVE-2023-0401:A NULL pointer can be dereferenced when signatures are being verified on PKCS7 signed or signedAndEnveloped data. In case the hash algorithm used for the signature is known to the OpenSSL library but the implementation of the hash algorithm is not available the digest initialization will fail. There is a missing check for the return value from the initialization function which later leads to invalid usage of the digest API most likely leading to a crash. The unavailability of an algorithm can be caused by using FIPS enabled configuration of providers or more commonly by not loading the legacy provider. PKCS7 data is processed by the SMIME library calls and also by the time stamp (TS) library calls. The TLS implementation in OpenSSL does not call these functions however third party applications would be affected if they call these functions to verify signatures on untrusted data.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="11.u1.fos23" version="202011">
					<filename>edk2-devel-202011-11.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/edk2-devel-202011-11.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="11.u1.fos23" version="202011">
					<filename>python3-edk2-devel-202011-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-edk2-devel-202011-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="11.u1.fos23" version="202011">
					<filename>edk2-help-202011-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/edk2-help-202011-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="11.u1.fos23" version="202011">
					<filename>edk2-ovmf-202011-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/edk2-ovmf-202011-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="11.u1.fos23" version="202011">
					<filename>edk2-devel-202011-11.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/edk2-devel-202011-11.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="11.u1.fos23" version="202011">
					<filename>edk2-aarch64-202011-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/edk2-aarch64-202011-11.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2016</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-06"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48337" id="CVE-2022-48337" title="CVE-2022-48337" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48338" id="CVE-2022-48338" title="CVE-2022-48338" type="cve"></reference>
		</references>
		<description>CVE-2022-48337:GNU Emacs through 28.2 allows attackers to execute commands via shell metacharacters in the name of a source-code file, because lib-src/etags.c uses the system C library function in its implementation of the etags program. For example, a victim may use the &#34;etags -u *&#34; command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.&#xA;CVE-2022-48338:An issue was discovered in GNU Emacs through 28.2. In ruby-mode.el, the ruby-find-library-file function has a local command injection vulnerability. The ruby-find-library-file function is an interactive function, and bound to C-c C-f. Inside the function, the external command gem is called through shell-command-to-string, but the feature-name parameters are not escaped. Thus, malicious Ruby source files may cause commands to be executed.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="emacs" release="9.u1.fos23" version="27.2">
					<filename>emacs-27.2-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-27.2-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="9.u1.fos23" version="27.2">
					<filename>emacs-devel-27.2-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-devel-27.2-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="9.u1.fos23" version="27.2">
					<filename>emacs-lucid-27.2-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-lucid-27.2-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="9.u1.fos23" version="27.2">
					<filename>emacs-nox-27.2-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-nox-27.2-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="9.u1.fos23" version="27.2">
					<filename>emacs-common-27.2-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-common-27.2-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="9.u1.fos23" version="27.2">
					<filename>emacs-terminal-27.2-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-terminal-27.2-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="9.u1.fos23" version="27.2">
					<filename>emacs-filesystem-27.2-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-filesystem-27.2-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="9.u1.fos23" version="27.2">
					<filename>emacs-help-27.2-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/emacs-help-27.2-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="9.u1.fos23" version="27.2">
					<filename>emacs-27.2-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/emacs-27.2-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="9.u1.fos23" version="27.2">
					<filename>emacs-devel-27.2-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/emacs-devel-27.2-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="9.u1.fos23" version="27.2">
					<filename>emacs-lucid-27.2-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/emacs-lucid-27.2-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="9.u1.fos23" version="27.2">
					<filename>emacs-nox-27.2-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/emacs-nox-27.2-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="9.u1.fos23" version="27.2">
					<filename>emacs-common-27.2-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/emacs-common-27.2-9.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2017</id>
		<title>An update for future is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40899" id="CVE-2022-40899" title="CVE-2022-40899" type="cve"></reference>
		</references>
		<description>CVE-2022-40899:An issue discovered in Python Charmers Future 0.18.2 and earlier allows remote attackers to cause a denial of service via crafted Set-Cookie header from malicious web server.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="python3-future" release="2.u1.fos23" version="0.18.2">
					<filename>python3-future-0.18.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-future-0.18.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2018</id>
		<title>An update for git is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22490" id="CVE-2023-22490" title="CVE-2023-22490" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23946" id="CVE-2023-23946" title="CVE-2023-23946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41903" id="CVE-2022-41903" title="CVE-2022-41903" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23521" id="CVE-2022-23521" title="CVE-2022-23521" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41953" id="CVE-2022-41953" title="CVE-2022-41953" type="cve"></reference>
		</references>
		<description>CVE-2023-22490:Git is a revision control system. Using a specially-crafted repository, Git prior to versions 2.39.2, 2.38.4, 2.37.6, 2.36.5, 2.35.7, 2.34.7, 2.33.7, 2.32.6, 2.31.7, and 2.30.8 can be tricked into using its local clone optimization even when using a non-local transport. Though Git will abort local clones whose source `$GIT_DIR/objects` directory contains symbolic links, the `objects` directory itself may still be a symbolic link. These two may be combined to include arbitrary files based on known paths on the victim&#39;s filesystem within the malicious repository&#39;s working copy, allowing for data exfiltration in a similar manner as CVE-2022-39253. A fix has been prepared and will appear in v2.39.2 v2.38.4 v2.37.6 v2.36.5 v2.35.7 v2.34.7 v2.33.7 v2.32.6, v2.31.7 and v2.30.8. If upgrading is impractical, two short-term workarounds are available. Avoid cloning repositories from untrusted sources with `--recurse-submodules`. Instead, consider cloning repositories without recursively cloning their submodules, and instead run `git submodule update` at each layer. Before doing so, inspect each new `.gitmodules` file to ensure that it does not contain suspicious module URLs.&#xA;CVE-2023-23946:Git, a revision control system, is vulnerable to path traversal prior to versions 2.39.2, 2.38.4, 2.37.6, 2.36.5, 2.35.7, 2.34.7, 2.33.7, 2.32.6, 2.31.7, and 2.30.8. By feeding a crafted input to `git apply`, a path outside the working tree can be overwritten as the user who is running `git apply`. A fix has been prepared and will appear in v2.39.2, v2.38.4, v2.37.6, v2.36.5, v2.35.7, v2.34.7, v2.33.7, v2.32.6, v2.31.7, and v2.30.8. As a workaround, use `git apply --stat` to inspect a patch before applying; avoid applying one that creates a symbolic link and then creates a file beyond the symbolic link.&#xA;CVE-2022-41903:Git is distributed revision control system. `git log` can display commits in an arbitrary format using its `--format` specifiers. This functionality is also exposed to `git archive` via the `export-subst` gitattribute. When processing the padding operators, there is a integer overflow in `pretty.c::format_and_pad_commit()` where a `size_t` is stored improperly as an `int`, and then added as an offset to a `memcpy()`. This overflow can be triggered directly by a user running a command which invokes the commit formatting machinery (e.g., `git log --format=...`). It may also be triggered indirectly through git archive via the export-subst mechanism, which expands format specifiers inside of files within the repository during a git archive. This integer overflow can result in arbitrary heap writes, which may result in arbitrary code execution. The problem has been patched in the versions published on 2023-01-17, going back to v2.30.7. Users are advised to upgrade. Users who are unable to upgrade should disable `git archive` in untrusted repositories. If you expose git archive via `git daemon`, disable it by running `git config --global daemon.uploadArch false`.&#xA;CVE-2022-23521:Git is distributed revision control system. gitattributes are a mechanism to allow defining attributes for paths. These attributes can be defined by adding a `.gitattributes` file to the repository, which contains a set of file patterns and the attributes that should be set for paths matching this pattern. When parsing gitattributes, multiple integer overflows can occur when there is a huge number of path patterns, a huge number of attributes for a single pattern, or when the declared attribute names are huge. These overflows can be triggered via a crafted `.gitattributes` file that may be part of the commit history. Git silently splits lines longer than 2KB when parsing gitattributes from a file, but not when parsing them from the index. Consequentially, the failure mode depends on whether the file exists in the working tree, the index or both. This integer overflow can result in arbitrary heap reads and writes, which may result in remote code execution. The problem has been patched in the versions published on 2023-01-17, going back to v2.30.7. Users are advised to upgrade. There are no known workarounds for this issue.&#xA;CVE-2022-41953:Git GUI is a convenient graphical tool that comes with Git for Windows. Its target audience is users who are uncomfortable with using Git on the command-line. Git GUI has a function to clone repositories. Immediately after the local clone is available, Git GUI will automatically post-process it, among other things running a spell checker called `aspell.exe` if it was found. Git GUI is implemented as a Tcl/Tk script. Due to the unfortunate design of Tcl on Windows, the search path when looking for an executable _always includes the current directory_. Therefore, malicious repositories can ship with an `aspell.exe` in their top-level directory which is executed by Git GUI without giving the user a chance to inspect it first, i.e. running untrusted code. This issue has been addressed in version 2.39.1. Users are advised to upgrade. Users unable to upgrade should avoid using Git GUI for cloning. If that is not a viable option, at least avoid cloning from untrusted sources.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="git" release="9.u2.fos23" version="2.33.0">
					<filename>git-2.33.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-2.33.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-core" release="9.u2.fos23" version="2.33.0">
					<filename>git-core-2.33.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-core-2.33.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-daemon" release="9.u2.fos23" version="2.33.0">
					<filename>git-daemon-2.33.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-daemon-2.33.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-gui" release="9.u2.fos23" version="2.33.0">
					<filename>git-gui-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-gui-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gitk" release="9.u2.fos23" version="2.33.0">
					<filename>gitk-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/gitk-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-web" release="9.u2.fos23" version="2.33.0">
					<filename>git-web-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-web-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-svn" release="9.u2.fos23" version="2.33.0">
					<filename>git-svn-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-svn-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-email" release="9.u2.fos23" version="2.33.0">
					<filename>git-email-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-email-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git" release="9.u2.fos23" version="2.33.0">
					<filename>perl-Git-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/perl-Git-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git-SVN" release="9.u2.fos23" version="2.33.0">
					<filename>perl-Git-SVN-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/perl-Git-SVN-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-help" release="9.u2.fos23" version="2.33.0">
					<filename>git-help-2.33.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/git-help-2.33.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git" release="9.u2.fos23" version="2.33.0">
					<filename>git-2.33.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/git-2.33.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-core" release="9.u2.fos23" version="2.33.0">
					<filename>git-core-2.33.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/git-core-2.33.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-daemon" release="9.u2.fos23" version="2.33.0">
					<filename>git-daemon-2.33.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/git-daemon-2.33.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2019</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-03"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0687" id="CVE-2023-0687" title="CVE-2023-0687" type="cve"></reference>
		</references>
		<description>CVE-2023-0687:** DISPUTED ** A vulnerability was found in GNU C Library 2.38. It has been declared as critical. This vulnerability affects the function __monstartup of the file gmon.c of the component Call Graph Monitor. The manipulation leads to buffer overflow. It is recommended to apply a patch to fix this issue. VDB-220246 is the identifier assigned to this vulnerability. NOTE: The real existence of this vulnerability is still doubted at the moment. The inputs that induce this vulnerability are basically addresses of the running application that is built with gmon enabled. It&#39;s basically trusted input or input that needs an actual security flaw to be compromised or controlled.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="glibc" release="113.u11.fos23" version="2.34">
					<filename>glibc-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="113.u11.fos23" version="2.34">
					<filename>glibc-common-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-common-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="113.u11.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-all-langpacks-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="113.u11.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-locale-source-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="113.u11.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-locale-archive-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="113.u11.fos23" version="2.34">
					<filename>glibc-devel-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-devel-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="113.u11.fos23" version="2.34">
					<filename>nscd-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nscd-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="113.u11.fos23" version="2.34">
					<filename>nss_modules-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nss_modules-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="113.u11.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-nss-devel-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="113.u11.fos23" version="2.34">
					<filename>libnsl-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libnsl-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="113.u11.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-debugutils-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="113.u11.fos23" version="2.34">
					<filename>glibc-help-2.34-113.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-help-2.34-113.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="113.u11.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-113.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/glibc-compat-2.17-2.34-113.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="113.u11.fos23" version="2.34">
					<filename>glibc-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="113.u11.fos23" version="2.34">
					<filename>glibc-common-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-common-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="113.u11.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-all-langpacks-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="113.u11.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-locale-source-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="113.u11.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-locale-archive-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="113.u11.fos23" version="2.34">
					<filename>glibc-devel-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-devel-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="113.u11.fos23" version="2.34">
					<filename>nscd-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/nscd-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="113.u11.fos23" version="2.34">
					<filename>nss_modules-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/nss_modules-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="113.u11.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-nss-devel-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="113.u11.fos23" version="2.34">
					<filename>libnsl-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libnsl-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="113.u11.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-debugutils-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="113.u11.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-113.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/glibc-compat-2.17-2.34-113.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2020</id>
		<title>An update for gmp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-18"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43618" id="CVE-2021-43618" title="CVE-2021-43618" type="cve"></reference>
		</references>
		<description>CVE-2021-43618:GNU Multiple Precision Arithmetic Library (GMP) through 6.2.1 has an mpz/inp_raw.c integer overflow and resultant buffer overflow via crafted input, leading to a segmentation fault on 32-bit platforms.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="gmp" release="2.u1.fos23" version="6.2.1">
					<filename>gmp-6.2.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/gmp-6.2.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="gmp-devel" release="2.u1.fos23" version="6.2.1">
					<filename>gmp-devel-6.2.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/gmp-devel-6.2.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="gmp-c++" release="2.u1.fos23" version="6.2.1">
					<filename>gmp-c++-6.2.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/gmp-c++-6.2.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="gmp" release="2.u1.fos23" version="6.2.1">
					<filename>gmp-6.2.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/gmp-6.2.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="gmp-devel" release="2.u1.fos23" version="6.2.1">
					<filename>gmp-devel-6.2.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/gmp-devel-6.2.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="gmp-c++" release="2.u1.fos23" version="6.2.1">
					<filename>gmp-c++-6.2.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/gmp-c++-6.2.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2021</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-13"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-44716" id="CVE-2021-44716" title="CVE-2021-44716" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23772" id="CVE-2022-23772" title="CVE-2022-23772" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23773" id="CVE-2022-23773" title="CVE-2022-23773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23806" id="CVE-2022-23806" title="CVE-2022-23806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24921" id="CVE-2022-24921" title="CVE-2022-24921" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41717" id="CVE-2022-41717" title="CVE-2022-41717" type="cve"></reference>
		</references>
		<description>CVE-2021-44716:net/http in Go before 1.16.12 and 1.17.x before 1.17.5 allows uncontrolled memory consumption in the header canonicalization cache via HTTP/2 requests.&#xA;CVE-2022-23772:Rat.SetString in math/big in Go before 1.16.14 and 1.17.x before 1.17.7 has an overflow that can lead to Uncontrolled Memory Consumption.&#xA;CVE-2022-23773:cmd/go in Go before 1.16.14 and 1.17.x before 1.17.7 can misinterpret branch names that falsely appear to be version tags. This can lead to incorrect access control if an actor is supposed to be able to create branches but not tags.&#xA;CVE-2022-23806:Curve.IsOnCurve in crypto/elliptic in Go before 1.16.14 and 1.17.x before 1.17.7 can incorrectly return true in situations with a big.Int value that is not a valid field element.&#xA;CVE-2022-24921:regexp.Compile in Go before 1.16.15 and 1.17.x before 1.17.8 allows stack exhaustion via a deeply nested expression.&#xA;CVE-2022-41717:An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="golang" release="1.u1.fos23" version="1.19.4">
					<filename>golang-1.19.4-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/golang-1.19.4-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="1.u1.fos23" version="1.19.4">
					<filename>golang-help-1.19.4-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/golang-help-1.19.4-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="1.u1.fos23" version="1.19.4">
					<filename>golang-devel-1.19.4-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/golang-devel-1.19.4-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="1.u1.fos23" version="1.19.4">
					<filename>golang-1.19.4-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/golang-1.19.4-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2022</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0056" id="CVE-2023-0056" title="CVE-2023-0056" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25725" id="CVE-2023-25725" title="CVE-2023-25725" type="cve"></reference>
		</references>
		<description>CVE-2023-0056:An uncontrolled resource consumption vulnerability was discovered in HAProxy which could crash the service. This issue could allow an authenticated remote attacker to run a specially crafted malicious server in an OpenShift cluster. The biggest impact is to availability.&#xA;CVE-2023-25725:HAProxy before 2.7.3 may allow a bypass of access control because HTTP/1 headers are inadvertently lost in some situations, aka &#34;request smuggling.&#34; The HTTP header parsers in HAProxy may accept empty header field names, which could be used to truncate the list of HTTP headers and thus make some headers disappear after being parsed and processed for HTTP/1.0 and HTTP/1.1. For HTTP/2 and HTTP/3, the impact is limited because the headers disappear before being parsed and processed, as if they had not been sent by the client.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="2.u1.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/haproxy-2.6.6-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="2.u1.fos23" version="2.6.6">
					<filename>haproxy-help-2.6.6-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/haproxy-help-2.6.6-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="2.u1.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/haproxy-2.6.6-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2023</id>
		<title>An update for harfbuzz is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25193" id="CVE-2023-25193" title="CVE-2023-25193" type="cve"></reference>
		</references>
		<description>CVE-2023-25193:hb-ot-layout-gsubgpos.hh in HarfBuzz through 6.0.0 allows attackers to trigger O(n^2) growth via consecutive marks during the process of looking back for base glyphs when attaching marks.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="harfbuzz" release="4.u1.fos23" version="2.8.2">
					<filename>harfbuzz-2.8.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/harfbuzz-2.8.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="harfbuzz-devel" release="4.u1.fos23" version="2.8.2">
					<filename>harfbuzz-devel-2.8.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/harfbuzz-devel-2.8.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="harfbuzz-help" release="4.u1.fos23" version="2.8.2">
					<filename>harfbuzz-help-2.8.2-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/harfbuzz-help-2.8.2-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="harfbuzz" release="4.u1.fos23" version="2.8.2">
					<filename>harfbuzz-2.8.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/harfbuzz-2.8.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="harfbuzz-devel" release="4.u1.fos23" version="2.8.2">
					<filename>harfbuzz-devel-2.8.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/harfbuzz-devel-2.8.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2024</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-21"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2006-2001" id="CVE-2006-2001" title="CVE-2006-2001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36760" id="CVE-2022-36760" title="CVE-2022-36760" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37436" id="CVE-2022-37436" title="CVE-2022-37436" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25690" id="CVE-2023-25690" title="CVE-2023-25690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27522" id="CVE-2023-27522" title="CVE-2023-27522" type="cve"></reference>
		</references>
		<description>CVE-2006-2001:Cross-site scripting (XSS) vulnerability in index.php in Scry Gallery 1.1 allows remote attackers to inject arbitrary web script or HTML via the p parameter. NOTE: this is a different vulnerability than the directory traversal vector.&#xA;CVE-2022-36760:Inconsistent Interpretation of HTTP Requests (&#39;HTTP Request Smuggling&#39;) vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.54 and prior versions.&#xA;CVE-2022-37436:Prior to Apache HTTP Server 2.4.55, a malicious backend can cause the response headers to be truncated early, resulting in some headers being incorporated into the response body. If the later headers have any security purpose, they will not be interpreted by the client.&#xA;CVE-2023-25690:Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack. Configurations are affected when mod_proxy is enabled along with some form of RewriteRule or ProxyPassMatch in which a non-specific pattern matches some portion of the user-supplied request-target (URL) data and is then re-inserted into the proxied request-target using variable substitution. For example, something like: RewriteEngine on RewriteRule &#34;^/here/(.*)&#34; &#34;http://example.com:8080/elsewhere?$1&#34;; [P] ProxyPassReverse /here/ http://example.com:8080/ Request splitting/smuggling could result in bypass of access controls in the proxy server, proxying unintended URLs to existing origin servers, and cache poisoning. Users are recommended to update to at least version 2.4.56 of Apache HTTP Server.&#xA;CVE-2023-27522:HTTP Response Smuggling vulnerability in Apache HTTP Server via mod_proxy_uwsgi. This issue affects Apache HTTP Server: from 2.4.30 through 2.4.55. Special characters in the origin response header can truncate/split the response forwarded to the client.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="httpd" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/httpd-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/httpd-devel-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-15.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/httpd-help-2.4.51-15.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-15.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/httpd-filesystem-2.4.51-15.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/httpd-tools-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="15.u5.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/mod_ssl-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="15.u5.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/mod_md-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="15.u5.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/mod_proxy_html-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="15.u5.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/mod_ldap-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="15.u5.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/mod_session-2.4.51-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/httpd-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/httpd-devel-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="15.u5.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/httpd-tools-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="15.u5.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/mod_ssl-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="15.u5.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/mod_md-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="15.u5.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/mod_proxy_html-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="15.u5.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/mod_ldap-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="15.u5.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/mod_session-2.4.51-15.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2025</id>
		<title>An update for jackson-databind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-18"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"></reference>
		</references>
		<description>CVE-2022-42004:In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="jackson-databind" release="9.u1.fos23" version="2.9.8">
					<filename>jackson-databind-2.9.8-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/jackson-databind-2.9.8-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jackson-databind-javadoc" release="9.u1.fos23" version="2.9.8">
					<filename>jackson-databind-javadoc-2.9.8-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/jackson-databind-javadoc-2.9.8-9.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2026</id>
		<title>An update for java-xmlbuilder is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-18"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2014-125087" id="CVE-2014-125087" title="CVE-2014-125087" type="cve"></reference>
		</references>
		<description>CVE-2014-125087:A vulnerability was found in java-xmlbuilder up to 1.1. It has been rated as problematic. Affected by this issue is some unknown functionality. The manipulation leads to xml external entity reference. Upgrading to version 1.2 is able to address this issue. The name of the patch is e6fddca201790abab4f2c274341c0bb8835c3e73. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-221480.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="java-xmlbuilder" release="1.u1.fos23" version="1.1">
					<filename>java-xmlbuilder-1.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/java-xmlbuilder-1.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="java-xmlbuilder-help" release="1.u1.fos23" version="1.1">
					<filename>java-xmlbuilder-help-1.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/java-xmlbuilder-help-1.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2027</id>
		<title>An update for jersey is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-18"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28168" id="CVE-2021-28168" title="CVE-2021-28168" type="cve"></reference>
		</references>
		<description>CVE-2021-28168:Eclipse Jersey 2.28 to 2.33 and Eclipse Jersey 3.0.0 to 3.0.1 contains a local information disclosure vulnerability. This is due to the use of the File.createTempFile which creates a file inside of the system temporary directory with the permissions: -rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system. As such, if the contents written is security sensitive, it can be disclosed to other local users.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="jersey" release="1.u1.fos23" version="2.29.1">
					<filename>jersey-2.29.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/jersey-2.29.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jersey-test-framework" release="1.u1.fos23" version="2.29.1">
					<filename>jersey-test-framework-2.29.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/jersey-test-framework-2.29.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jersey-javadoc" release="1.u1.fos23" version="2.29.1">
					<filename>jersey-javadoc-2.29.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/jersey-javadoc-2.29.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2028</id>
		<title>An update for less is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46663" id="CVE-2022-46663" title="CVE-2022-46663" type="cve"></reference>
		</references>
		<description>CVE-2022-46663:In GNU Less before 609, crafted data can result in &#34;less -R&#34; not filtering ANSI escape sequences sent to the terminal.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="less" release="4.u1.fos23" version="590">
					<filename>less-590-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/less-590-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="less-help" release="4.u1.fos23" version="590">
					<filename>less-help-590-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/less-help-590-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="less" release="4.u1.fos23" version="590">
					<filename>less-590-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/less-590-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2029</id>
		<title>An update for libXpm is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44617" id="CVE-2022-44617" title="CVE-2022-44617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46285" id="CVE-2022-46285" title="CVE-2022-46285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4883" id="CVE-2022-4883" title="CVE-2022-4883" type="cve"></reference>
		</references>
		<description>CVE-2022-44617:A flaw was found in libXpm. When processing a file with width of 0 and a very large height, some parser functions will be called repeatedly and can lead to an infinite loop, resulting in a Denial of Service in the application linked to the library.&#xA;CVE-2022-46285:A flaw was found in libXpm. This issue occurs when parsing a file with a comment not closed; the end-of-file condition will not be detected, leading to an infinite loop and resulting in a Denial of Service in the application linked to the library.&#xA;CVE-2022-4883:A flaw was found in libXpm. When processing files with .Z or .gz extensions, the library calls external programs to compress and uncompress files, relying on the PATH environment variable to find these programs, which could allow a malicious user to execute other programs by manipulating the PATH environment variable.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="libXpm" release="4.u1.fos23" version="3.5.13">
					<filename>libXpm-3.5.13-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libXpm-3.5.13-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libXpm-devel" release="4.u1.fos23" version="3.5.13">
					<filename>libXpm-devel-3.5.13-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libXpm-devel-3.5.13-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libXpm-help" release="4.u1.fos23" version="3.5.13">
					<filename>libXpm-help-3.5.13-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libXpm-help-3.5.13-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libXpm" release="4.u1.fos23" version="3.5.13">
					<filename>libXpm-3.5.13-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libXpm-3.5.13-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libXpm-devel" release="4.u1.fos23" version="3.5.13">
					<filename>libXpm-devel-3.5.13-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libXpm-devel-3.5.13-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2030</id>
		<title>An update for libarchive is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36976" id="CVE-2021-36976" title="CVE-2021-36976" type="cve"></reference>
		</references>
		<description>CVE-2021-36976:libarchive 3.4.1 through 3.5.1 has a use-after-free in copy_string (called from do_uncompress_block and process_block).</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="libarchive" release="6.u3.fos23" version="3.5.2">
					<filename>libarchive-3.5.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libarchive-3.5.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive-devel" release="6.u3.fos23" version="3.5.2">
					<filename>libarchive-devel-3.5.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libarchive-devel-3.5.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libarchive-help" release="6.u3.fos23" version="3.5.2">
					<filename>libarchive-help-3.5.2-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libarchive-help-3.5.2-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdtar" release="6.u3.fos23" version="3.5.2">
					<filename>bsdtar-3.5.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/bsdtar-3.5.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcpio" release="6.u3.fos23" version="3.5.2">
					<filename>bsdcpio-3.5.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/bsdcpio-3.5.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcat" release="6.u3.fos23" version="3.5.2">
					<filename>bsdcat-3.5.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/bsdcat-3.5.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive" release="6.u3.fos23" version="3.5.2">
					<filename>libarchive-3.5.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libarchive-3.5.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive-devel" release="6.u3.fos23" version="3.5.2">
					<filename>libarchive-devel-3.5.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libarchive-devel-3.5.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdtar" release="6.u3.fos23" version="3.5.2">
					<filename>bsdtar-3.5.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/bsdtar-3.5.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcpio" release="6.u3.fos23" version="3.5.2">
					<filename>bsdcpio-3.5.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/bsdcpio-3.5.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcat" release="6.u3.fos23" version="3.5.2">
					<filename>bsdcat-3.5.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/bsdcat-3.5.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2031</id>
		<title>An update for libksba is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47629" id="CVE-2022-47629" title="CVE-2022-47629" type="cve"></reference>
		</references>
		<description>CVE-2022-47629:Libksba before 1.6.3 is prone to an integer overflow vulnerability in the CRL signature parser.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="libksba" release="3.u1.fos23" version="1.6.0">
					<filename>libksba-1.6.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libksba-1.6.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libksba-devel" release="3.u1.fos23" version="1.6.0">
					<filename>libksba-devel-1.6.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libksba-devel-1.6.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libksba-help" release="3.u1.fos23" version="1.6.0">
					<filename>libksba-help-1.6.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libksba-help-1.6.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libksba" release="3.u1.fos23" version="1.6.0">
					<filename>libksba-1.6.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libksba-1.6.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libksba-devel" release="3.u1.fos23" version="1.6.0">
					<filename>libksba-devel-1.6.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libksba-devel-1.6.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2032</id>
		<title>An update for libmicrohttpd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-21"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27371" id="CVE-2023-27371" title="CVE-2023-27371" type="cve"></reference>
		</references>
		<description>CVE-2023-27371:GNU libmicrohttpd before 0.9.76 allows remote DoS (Denial of Service) due to improper parsing of a multipart/form-data boundary in the postprocessor.c MHD_create_post_processor() method. This allows an attacker to remotely send a malicious HTTP POST packet that includes one or more &#39;\0&#39; bytes in a multipart/form-data boundary field, which - assuming a specific heap layout - will result in an out-of-bounds read and a crash in the find_boundary() function.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="libmicrohttpd" release="4.u1.fos23" version="0.9.75">
					<filename>libmicrohttpd-0.9.75-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libmicrohttpd-0.9.75-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="libmicrohttpd-devel" release="4.u1.fos23" version="0.9.75">
					<filename>libmicrohttpd-devel-0.9.75-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libmicrohttpd-devel-0.9.75-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="libmicrohttpd-help" release="4.u1.fos23" version="0.9.75">
					<filename>libmicrohttpd-help-0.9.75-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libmicrohttpd-help-0.9.75-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libmicrohttpd" release="4.u1.fos23" version="0.9.75">
					<filename>libmicrohttpd-0.9.75-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libmicrohttpd-0.9.75-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libmicrohttpd-devel" release="4.u1.fos23" version="0.9.75">
					<filename>libmicrohttpd-devel-0.9.75-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libmicrohttpd-devel-0.9.75-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2033</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23009" id="CVE-2023-23009" title="CVE-2023-23009" type="cve"></reference>
		</references>
		<description>CVE-2023-23009:Libreswan 4.9 allows remote attackers to cause a denial of service (assert failure and daemon restart) via crafted TS payload with an incorrect selector length.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="libreswan" release="3.u1.fos23" version="4.5">
					<filename>libreswan-4.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libreswan-4.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libreswan-help" release="3.u1.fos23" version="4.5">
					<filename>libreswan-help-4.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libreswan-help-4.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan" release="3.u1.fos23" version="4.5">
					<filename>libreswan-4.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libreswan-4.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan-help" release="3.u1.fos23" version="4.5">
					<filename>libreswan-help-4.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libreswan-help-4.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2034</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48281" id="CVE-2022-48281" title="CVE-2022-48281" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0795" id="CVE-2023-0795" title="CVE-2023-0795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0796" id="CVE-2023-0796" title="CVE-2023-0796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0797" id="CVE-2023-0797" title="CVE-2023-0797" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0798" id="CVE-2023-0798" title="CVE-2023-0798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0799" id="CVE-2023-0799" title="CVE-2023-0799" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0800" id="CVE-2023-0800" title="CVE-2023-0800" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0801" id="CVE-2023-0801" title="CVE-2023-0801" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0802" id="CVE-2023-0802" title="CVE-2023-0802" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0803" id="CVE-2023-0803" title="CVE-2023-0803" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0804" id="CVE-2023-0804" title="CVE-2023-0804" type="cve"></reference>
		</references>
		<description>CVE-2022-48281:processCropSelections in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based buffer overflow (e.g., &#34;WRITE of size 307203&#34;) via a crafted TIFF image.&#xA;CVE-2023-0795:LibTIFF 4.4.0 has an out-of-bounds read in tiffcrop in tools/tiffcrop.c:3488, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit afaabc3e.&#xA;CVE-2023-0796:LibTIFF 4.4.0 has an out-of-bounds read in tiffcrop in tools/tiffcrop.c:3592, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit afaabc3e.&#xA;CVE-2023-0797:LibTIFF 4.4.0 has an out-of-bounds read in tiffcrop in libtiff/tif_unix.c:368, invoked by tools/tiffcrop.c:2903 and tools/tiffcrop.c:6921, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit afaabc3e.&#xA;CVE-2023-0798:LibTIFF 4.4.0 has an out-of-bounds read in tiffcrop in tools/tiffcrop.c:3400, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit afaabc3e.&#xA;CVE-2023-0799:LibTIFF 4.4.0 has an out-of-bounds read in tiffcrop in tools/tiffcrop.c:3701, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit afaabc3e.&#xA;CVE-2023-0800:LibTIFF 4.4.0 has an out-of-bounds write in tiffcrop in tools/tiffcrop.c:3502, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 33aee127.&#xA;CVE-2023-0801:LibTIFF 4.4.0 has an out-of-bounds write in tiffcrop in libtiff/tif_unix.c:368, invoked by tools/tiffcrop.c:2903 and tools/tiffcrop.c:6778, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 33aee127.&#xA;CVE-2023-0802:LibTIFF 4.4.0 has an out-of-bounds write in tiffcrop in tools/tiffcrop.c:3724, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 33aee127.&#xA;CVE-2023-0803:LibTIFF 4.4.0 has an out-of-bounds write in tiffcrop in tools/tiffcrop.c:3516, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 33aee127.&#xA;CVE-2023-0804:LibTIFF 4.4.0 has an out-of-bounds write in tiffcrop in tools/tiffcrop.c:3609, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 33aee127.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-24.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libtiff-4.3.0-24.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-24.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libtiff-devel-4.3.0-24.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-24.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libtiff-static-4.3.0-24.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-24.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libtiff-tools-4.3.0-24.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-24.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/libtiff-help-4.3.0-24.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-24.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libtiff-4.3.0-24.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-24.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libtiff-devel-4.3.0-24.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-24.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libtiff-static-4.3.0-24.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="24.u2.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-24.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/libtiff-tools-4.3.0-24.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2035</id>
		<title>An update for lxc is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47952" id="CVE-2022-47952" title="CVE-2022-47952" type="cve"></reference>
		</references>
		<description>CVE-2022-47952:lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because &#34;Failed to open&#34; often indicates that a file does not exist, whereas &#34;does not refer to a network namespace path&#34; often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that &#34;we will report back to the user that the open() failed but the user has no way of knowing why it failed&#34;; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="lxc" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-4.0.3-2022102413.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/lxc-4.0.3-2022102413.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lxc-libs" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-libs-4.0.3-2022102413.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/lxc-libs-4.0.3-2022102413.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lxc-devel" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-devel-4.0.3-2022102413.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/lxc-devel-4.0.3-2022102413.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="lxc-help" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-help-4.0.3-2022102413.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/lxc-help-4.0.3-2022102413.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lxc" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-4.0.3-2022102413.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/lxc-4.0.3-2022102413.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lxc-libs" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-libs-4.0.3-2022102413.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/lxc-libs-4.0.3-2022102413.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lxc-devel" release="2022102413.u4.fos23" version="4.0.3">
					<filename>lxc-devel-4.0.3-2022102413.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/lxc-devel-4.0.3-2022102413.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2036</id>
		<title>An update for net-snmp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44792" id="CVE-2022-44792" title="CVE-2022-44792" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44793" id="CVE-2022-44793" title="CVE-2022-44793" type="cve"></reference>
		</references>
		<description>CVE-2022-44792:handle_ipDefaultTTL in agent/mibgroup/ip-mib/ip_scalars.c in Net-SNMP 5.8 through 5.9.3 has a NULL Pointer Exception bug that can be used by a remote attacker (who has write access) to cause the instance to crash via a crafted UDP packet, resulting in Denial of Service.&#xA;CVE-2022-44793:handle_ipv6IpForwarding in agent/mibgroup/ip-mib/ip_scalars.c in Net-SNMP 5.4.3 through 5.9.3 has a NULL Pointer Exception bug that can be used by a remote attacker to cause the instance to crash via a crafted UDP packet, resulting in Denial of Service.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="net-snmp" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-5.9.1-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/net-snmp-5.9.1-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-libs" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-libs-5.9.1-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/net-snmp-libs-5.9.1-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-devel" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-devel-5.9.1-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/net-snmp-devel-5.9.1-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-perl" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-perl-5.9.1-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/net-snmp-perl-5.9.1-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-gui" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-gui-5.9.1-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/net-snmp-gui-5.9.1-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="python3-net-snmp" release="5.u1.fos23" version="5.9.1">
					<filename>python3-net-snmp-5.9.1-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-net-snmp-5.9.1-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="net-snmp-help" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-help-5.9.1-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/net-snmp-help-5.9.1-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-5.9.1-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/net-snmp-5.9.1-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-libs" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-libs-5.9.1-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/net-snmp-libs-5.9.1-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-devel" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-devel-5.9.1-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/net-snmp-devel-5.9.1-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-perl" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-perl-5.9.1-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/net-snmp-perl-5.9.1-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-gui" release="5.u1.fos23" version="5.9.1">
					<filename>net-snmp-gui-5.9.1-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/net-snmp-gui-5.9.1-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="python3-net-snmp" release="5.u1.fos23" version="5.9.1">
					<filename>python3-net-snmp-5.9.1-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-net-snmp-5.9.1-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2037</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
		</references>
		<description>CVE-2022-4304:A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.&#xA;CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data. If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as the decoders introduced in OpenSSL 3.0. The OpenSSL asn1parse command line application is also impacted by this issue.&#xA;CVE-2023-0215:The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. This scenario occurs directly in the internal function B64_write_ASN1() which may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on the BIO. This internal function is in turn called by the public API functions PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream, SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7. Other public API functions that may be impacted by this include i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and i2d_PKCS7_bio_stream. The OpenSSL cms and smime command line applications are similarly affected.&#xA;CVE-2023-0286:There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="nodejs" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nodejs-12.22.11-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nodejs-devel-12.22.11-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nodejs-libs-12.22.11-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nodejs-full-i18n-12.22.11-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.4.u1.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/v8-devel-7.8.279.23-1.12.22.11.4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.4.u1.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/npm-6.14.16-1.12.22.11.4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-docs-12.22.11-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/nodejs-docs-12.22.11-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/nodejs-12.22.11-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/nodejs-devel-12.22.11-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/nodejs-libs-12.22.11-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="4.u1.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/nodejs-full-i18n-12.22.11-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.4.u1.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/v8-devel-7.8.279.23-1.12.22.11.4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.4.u1.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/npm-6.14.16-1.12.22.11.4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2038</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25136" id="CVE-2023-25136" title="CVE-2023-25136" type="cve"></reference>
		</references>
		<description>CVE-2023-25136:OpenSSH server (sshd) 9.1 introduced a double-free vulnerability during options.kex_algorithms handling. This is fixed in OpenSSH 9.2. The double free can be leveraged, by an unauthenticated remote attacker in the default configuration, to jump to any location in the sshd address space. One third-party report states &#34;remote code execution is theoretically possible.&#34;</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="openssh" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-8.8p1-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssh-8.8p1-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssh-clients-8.8p1-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssh-server-8.8p1-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssh-keycat-8.8p1-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssh-askpass-8.8p1-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.19.u6.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/pam_ssh_agent_auth-0.10.4-4.19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-help-8.8p1-19.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssh-help-8.8p1-19.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-8.8p1-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssh-8.8p1-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssh-clients-8.8p1-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssh-server-8.8p1-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssh-keycat-8.8p1-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="19.u6.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssh-askpass-8.8p1-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.19.u6.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/pam_ssh_agent_auth-0.10.4-4.19.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2039</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
		</references>
		<description>CVE-2022-4304:A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.&#xA;CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data. If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as the decoders introduced in OpenSSL 3.0. The OpenSSL asn1parse command line application is also impacted by this issue.&#xA;CVE-2023-0215:The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. This scenario occurs directly in the internal function B64_write_ASN1() which may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on the BIO. This internal function is in turn called by the public API functions PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream, SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7. Other public API functions that may be impacted by this include i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and i2d_PKCS7_bio_stream. The OpenSSL cms and smime command line applications are similarly affected.&#xA;CVE-2023-0286:There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="openssl" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-18.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssl-1.1.1m-18.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-18.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssl-libs-1.1.1m-18.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-18.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssl-perl-1.1.1m-18.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-18.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssl-devel-1.1.1m-18.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-18.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openssl-help-1.1.1m-18.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-18.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssl-1.1.1m-18.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-18.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssl-libs-1.1.1m-18.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-18.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssl-perl-1.1.1m-18.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="18.u3.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-18.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openssl-devel-1.1.1m-18.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2040</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4338" id="CVE-2022-4338" title="CVE-2022-4338" type="cve"></reference>
		</references>
		<description>CVE-2022-4338:An integer underflow in Organization Specific TLV was found in various versions of OpenvSwitch.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="openvswitch" release="2.u1.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openvswitch-2.12.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-devel" release="2.u1.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openvswitch-devel-2.12.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-help" release="2.u1.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openvswitch-help-2.12.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-openvswitch" release="2.u1.fos23" version="2.12.4">
					<filename>python3-openvswitch-2.12.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-openvswitch-2.12.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch" release="2.u1.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openvswitch-2.12.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-devel" release="2.u1.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openvswitch-devel-2.12.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-help" release="2.u1.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openvswitch-help-2.12.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2041</id>
		<title>An update for opusfile is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-24"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47021" id="CVE-2022-47021" title="CVE-2022-47021" type="cve"></reference>
		</references>
		<description>CVE-2022-47021:A null pointer dereference issue was discovered in functions op_get_data and op_open1 in opusfile.c in xiph opusfile 0.9 thru 0.12 allows attackers to cause denial of service or other unspecified impacts.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="opusfile" release="5.u1.fos23" version="0.11">
					<filename>opusfile-0.11-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/opusfile-0.11-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="opusfile-devel" release="5.u1.fos23" version="0.11">
					<filename>opusfile-devel-0.11-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/opusfile-devel-0.11-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opusfile" release="5.u1.fos23" version="0.11">
					<filename>opusfile-0.11-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/opusfile-0.11-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opusfile-devel" release="5.u1.fos23" version="0.11">
					<filename>opusfile-devel-0.11-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/opusfile-devel-0.11-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2042</id>
		<title>An update for pesign is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3560" id="CVE-2022-3560" title="CVE-2022-3560" type="cve"></reference>
		</references>
		<description>CVE-2022-3560:A flaw was found in pesign. The pesign package provides a systemd service used to start the pesign daemon. This service unit runs a script to set ACLs for /etc/pki/pesign and /run/pesign directories to grant access privileges to users in the &#39;pesign&#39; group. However, the script doesn&#39;t check for symbolic links. This could allow an attacker to gain access to privileged files and directories via a path traversal attack.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="pesign" release="4.u1.fos23" version="115">
					<filename>pesign-115-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/pesign-115-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pesign-help" release="4.u1.fos23" version="115">
					<filename>pesign-help-115-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/pesign-help-115-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pesign" release="4.u1.fos23" version="115">
					<filename>pesign-115-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/pesign-115-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pesign-help" release="4.u1.fos23" version="115">
					<filename>pesign-help-115-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/pesign-help-115-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2043</id>
		<title>An update for pkgconf is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24056" id="CVE-2023-24056" title="CVE-2023-24056" type="cve"></reference>
		</references>
		<description>CVE-2023-24056:In pkgconf through 1.9.3, variable duplication can cause unbounded string expansion due to incorrect checks in libpkgconf/tuple.c:pkgconf_tuple_parse. For example, a .pc file containing a few hundred bytes can expand to one billion bytes.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="pkgconf" release="3.u1.fos23" version="1.8.0">
					<filename>pkgconf-1.8.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/pkgconf-1.8.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pkgconf-devel" release="3.u1.fos23" version="1.8.0">
					<filename>pkgconf-devel-1.8.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/pkgconf-devel-1.8.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pkgconf-help" release="3.u1.fos23" version="1.8.0">
					<filename>pkgconf-help-1.8.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/pkgconf-help-1.8.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pkgconf" release="3.u1.fos23" version="1.8.0">
					<filename>pkgconf-1.8.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/pkgconf-1.8.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pkgconf-devel" release="3.u1.fos23" version="1.8.0">
					<filename>pkgconf-devel-1.8.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/pkgconf-devel-1.8.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2044</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-21"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37337" id="CVE-2022-37337" title="CVE-2022-37337" type="cve"></reference>
		</references>
		<description>CVE-2022-37337:A command execution vulnerability exists in the access control functionality of Netgear Orbi Router RBR750 4.6.8.5. A specially-crafted HTTP request can lead to arbitrary command execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="poppler" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-devel-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-glib-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-glib-devel-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-glib-doc-0.90.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-qt5-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-qt5-devel-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-cpp-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-cpp-devel-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-utils-0.90.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/poppler-help-0.90.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-devel-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-glib-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-glib-devel-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-qt5-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-qt5-devel-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-cpp-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-cpp-devel-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="4.u1.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/poppler-utils-0.90.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2045</id>
		<title>An update for ppp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4603" id="CVE-2022-4603" title="CVE-2022-4603" type="cve"></reference>
		</references>
		<description>CVE-2022-4603:** DISPUTED ** A vulnerability classified as problematic has been found in ppp. Affected is the function dumpppp of the file pppdump/pppdump.c of the component pppdump. The manipulation of the argument spkt.buf/rpkt.buf leads to improper validation of array index. The real existence of this vulnerability is still doubted at the moment. The name of the patch is a75fb7b198eed50d769c80c36629f38346882cbf. It is recommended to apply a patch to fix this issue. VDB-216198 is the identifier assigned to this vulnerability. NOTE: pppdump is not used in normal process of setting up a PPP connection, is not installed setuid-root, and is not invoked automatically in any scenario.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="ppp" release="5.u3.fos23" version="2.4.9">
					<filename>ppp-2.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ppp-2.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ppp-devel" release="5.u3.fos23" version="2.4.9">
					<filename>ppp-devel-2.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ppp-devel-2.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ppp-help" release="5.u3.fos23" version="2.4.9">
					<filename>ppp-help-2.4.9-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ppp-help-2.4.9-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ppp" release="5.u3.fos23" version="2.4.9">
					<filename>ppp-2.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ppp-2.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ppp-devel" release="5.u3.fos23" version="2.4.9">
					<filename>ppp-devel-2.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ppp-devel-2.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2046</id>
		<title>An update for python-cryptography is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23931" id="CVE-2023-23931" title="CVE-2023-23931" type="cve"></reference>
		</references>
		<description>CVE-2023-23931:cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. In affected versions `Cipher.update_into` would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as `bytes`) to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This now correctly raises an exception. This issue has been present since `update_into` was originally introduced in cryptography 1.8.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="python3-cryptography" release="2.u1.fos23" version="36.0.1">
					<filename>python3-cryptography-36.0.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-cryptography-36.0.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-cryptography-help" release="2.u1.fos23" version="36.0.1">
					<filename>python-cryptography-help-36.0.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python-cryptography-help-36.0.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-cryptography" release="2.u1.fos23" version="36.0.1">
					<filename>python3-cryptography-36.0.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/python3-cryptography-36.0.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2047</id>
		<title>An update for python-wheel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40898" id="CVE-2022-40898" title="CVE-2022-40898" type="cve"></reference>
		</references>
		<description>CVE-2022-40898:An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="1" name="python3-wheel" release="2.u1.fos23" version="0.37.0">
					<filename>python3-wheel-0.37.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python3-wheel-0.37.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="python-wheel-wheel" release="2.u1.fos23" version="0.37.0">
					<filename>python-wheel-wheel-0.37.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/python-wheel-wheel-0.37.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2048</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33621" id="CVE-2021-33621" title="CVE-2021-33621" type="cve"></reference>
		</references>
		<description>CVE-2021-33621:The cgi gem before 0.1.0.2, 0.2.x before 0.2.2, and 0.3.x before 0.3.5 for Ruby allows HTTP response splitting. This is relevant to applications that use untrusted user input either to generate an HTTP response or to create a CGI::Cookie object.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="ruby" release="128.u1.fos23" version="3.0.3">
					<filename>ruby-3.0.3-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ruby-3.0.3-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="128.u1.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ruby-devel-3.0.3-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="128.u1.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygems-3.2.32-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="128.u1.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygems-devel-3.2.32-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="128.u1.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-rake-13.0.3-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="128.u1.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-rbs-1.4.0-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="128.u1.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ruby-irb-3.0.3-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="128.u1.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-rdoc-6.3.3-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="128.u1.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/ruby-help-3.0.3-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="128.u1.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-bigdecimal-3.0.0-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="128.u1.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-did_you_mean-1.5.0-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="128.u1.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-io-console-0.5.7-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="128.u1.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-json-2.5.1-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="128.u1.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-minitest-5.14.2-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="128.u1.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-openssl-2.2.1-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-power_assert" release="128.u1.fos23" version="1.2.0">
					<filename>rubygem-power_assert-1.2.0-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-power_assert-1.2.0-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="128.u1.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-128.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-psych-3.3.2-128.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="128.u1.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-test-unit-3.3.7-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="128.u1.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-rexml-3.2.5-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="128.u1.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-rss-0.2.9-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="128.u1.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-128.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-typeprof-0.15.2-128.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="128.u1.fos23" version="3.0.3">
					<filename>ruby-3.0.3-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ruby-3.0.3-128.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="128.u1.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/ruby-devel-3.0.3-128.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="128.u1.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rubygem-bigdecimal-3.0.0-128.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="128.u1.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rubygem-io-console-0.5.7-128.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="128.u1.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rubygem-json-2.5.1-128.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="128.u1.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rubygem-openssl-2.2.1-128.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="128.u1.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-128.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/rubygem-psych-3.3.2-128.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2049</id>
		<title>An update for rubygem-activerecord is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44566" id="CVE-2022-44566" title="CVE-2022-44566" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22794" id="CVE-2023-22794" title="CVE-2023-22794" type="cve"></reference>
		</references>
		<description>CVE-2022-44566:A denial of service vulnerability present in ActiveRecord&#39;s PostgreSQL adapter &lt;7.0.4.1 and &lt;6.1.7.1. When a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.&#xA;CVE-2023-22794:A vulnerability in ActiveRecord &lt;6.0.6.1, v6.1.7.1 and v7.0.4.1 related to the sanitization of comments. If malicious user input is passed to either the `annotate` query method, the `optimizer_hints` query method, or through the QueryLogs interface which automatically adds annotations, it may be sent to the database withinsufficient sanitization and be able to inject SQL outside of the comment.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="1" name="rubygem-activerecord" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-activerecord-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-activerecord-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-activerecord-doc" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-activerecord-doc-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-activerecord-doc-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2050</id>
		<title>An update for rubygem-activesupport is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22796" id="CVE-2023-22796" title="CVE-2023-22796" type="cve"></reference>
		</references>
		<description>CVE-2023-22796:A regular expression based DoS vulnerability in Active Support &lt;6.1.7.1 and &lt;7.0.4.1. A specially crafted string passed to the underscore method can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="1" name="rubygem-activesupport" release="5.u2.fos23" version="6.1.4.1">
					<filename>rubygem-activesupport-6.1.4.1-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-activesupport-6.1.4.1-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-activesupport-doc" release="5.u2.fos23" version="6.1.4.1">
					<filename>rubygem-activesupport-doc-6.1.4.1-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-activesupport-doc-6.1.4.1-5.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2051</id>
		<title>An update for rubygem-globalid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22799" id="CVE-2023-22799" title="CVE-2023-22799" type="cve"></reference>
		</references>
		<description>CVE-2023-22799:A ReDoS based DoS vulnerability in the GlobalID &lt;1.0.1 which could allow an attacker supplying a carefully crafted input can cause the regular expression engine to take an unexpected amount of time. All users running an affected release should either upgrade or use one of the workarounds immediately.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="rubygem-globalid" release="4.u1.fos23" version="0.4.2">
					<filename>rubygem-globalid-0.4.2-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-globalid-0.4.2-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-globalid-doc" release="4.u1.fos23" version="0.4.2">
					<filename>rubygem-globalid-doc-0.4.2-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/rubygem-globalid-doc-0.4.2-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2052</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
		</references>
		<description>CVE-2023-0286:There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="shim" release="9.u4.fos23" version="15.6">
					<filename>shim-15.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/shim-15.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="9.u4.fos23" version="15.6">
					<filename>shim-15.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/shim-15.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2053</id>
		<title>An update for snakeyaml is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25857" id="CVE-2022-25857" title="CVE-2022-25857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38749" id="CVE-2022-38749" title="CVE-2022-38749" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38750" id="CVE-2022-38750" title="CVE-2022-38750" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38751" id="CVE-2022-38751" title="CVE-2022-38751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38752" id="CVE-2022-38752" title="CVE-2022-38752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41854" id="CVE-2022-41854" title="CVE-2022-41854" type="cve"></reference>
		</references>
		<description>CVE-2022-25857:The package org.yaml:snakeyaml from 0 and before 1.31 are vulnerable to Denial of Service (DoS) due missing to nested depth limitation for collections.&#xA;CVE-2022-38749:Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow.&#xA;CVE-2022-38750:Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow.&#xA;CVE-2022-38751:Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow.&#xA;CVE-2022-38752:Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stack-overflow.&#xA;CVE-2022-41854:Those using Snakeyaml to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stack overflow. This effect may support a denial of service attack.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="snakeyaml" release="1.u1.fos23" version="1.32">
					<filename>snakeyaml-1.32-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/snakeyaml-1.32-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="snakeyaml-javadoc" release="1.u1.fos23" version="1.32">
					<filename>snakeyaml-javadoc-1.32-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/snakeyaml-javadoc-1.32-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2054</id>
		<title>An update for sudo is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-18"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22809" id="CVE-2023-22809" title="CVE-2023-22809" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27320" id="CVE-2023-27320" title="CVE-2023-27320" type="cve"></reference>
		</references>
		<description>CVE-2023-22809:In Sudo before 1.9.12p2, the sudoedit (aka -e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation. Affected versions are 1.8.0 through 1.9.12.p1. The problem exists because a user-specified editor may contain a &#34;--&#34; argument that defeats a protection mechanism, e.g., an EDITOR=&#39;vim -- /path/to/extra/file&#39; value.&#xA;CVE-2023-27320:This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="sudo" release="10.u3.fos23" version="1.9.8p2">
					<filename>sudo-1.9.8p2-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/sudo-1.9.8p2-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sudo-devel" release="10.u3.fos23" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/sudo-devel-1.9.8p2-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sudo-help" release="10.u3.fos23" version="1.9.8p2">
					<filename>sudo-help-1.9.8p2-10.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/sudo-help-1.9.8p2-10.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo" release="10.u3.fos23" version="1.9.8p2">
					<filename>sudo-1.9.8p2-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/sudo-1.9.8p2-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo-devel" release="10.u3.fos23" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/sudo-devel-1.9.8p2-10.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2055</id>
		<title>An update for systemd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-01-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4415" id="CVE-2022-4415" title="CVE-2022-4415" type="cve"></reference>
		</references>
		<description>CVE-2022-4415:A vulnerability was found in systemd. This security flaw can cause a local information leak due to systemd-coredump not respecting the fs.suid_dumpable kernel setting.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="systemd" release="46.u7.fos23" version="249">
					<filename>systemd-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-devel" release="46.u7.fos23" version="249">
					<filename>systemd-devel-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-devel-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-libs" release="46.u7.fos23" version="249">
					<filename>systemd-libs-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-libs-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-udev" release="46.u7.fos23" version="249">
					<filename>systemd-udev-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-udev-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-container" release="46.u7.fos23" version="249">
					<filename>systemd-container-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-container-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-resolved" release="46.u7.fos23" version="249">
					<filename>systemd-resolved-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-resolved-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-nspawn" release="46.u7.fos23" version="249">
					<filename>systemd-nspawn-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-nspawn-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-networkd" release="46.u7.fos23" version="249">
					<filename>systemd-networkd-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-networkd-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-timesyncd" release="46.u7.fos23" version="249">
					<filename>systemd-timesyncd-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-timesyncd-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-pam" release="46.u7.fos23" version="249">
					<filename>systemd-pam-249-46.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-pam-249-46.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="systemd-help" release="46.u7.fos23" version="249">
					<filename>systemd-help-249-46.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/systemd-help-249-46.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="46.u7.fos23" version="249">
					<filename>systemd-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-devel" release="46.u7.fos23" version="249">
					<filename>systemd-devel-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-devel-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-libs" release="46.u7.fos23" version="249">
					<filename>systemd-libs-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-libs-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-udev" release="46.u7.fos23" version="249">
					<filename>systemd-udev-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-udev-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-container" release="46.u7.fos23" version="249">
					<filename>systemd-container-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-container-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-resolved" release="46.u7.fos23" version="249">
					<filename>systemd-resolved-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-resolved-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-nspawn" release="46.u7.fos23" version="249">
					<filename>systemd-nspawn-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-nspawn-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-networkd" release="46.u7.fos23" version="249">
					<filename>systemd-networkd-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-networkd-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-timesyncd" release="46.u7.fos23" version="249">
					<filename>systemd-timesyncd-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-timesyncd-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-pam" release="46.u7.fos23" version="249">
					<filename>systemd-pam-249-46.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/systemd-pam-249-46.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2056</id>
		<title>An update for tar is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48303" id="CVE-2022-48303" title="CVE-2022-48303" type="cve"></reference>
		</references>
		<description>CVE-2022-48303:GNU Tar through 1.34 has a one-byte out-of-bounds read that results in use of uninitialized memory for a conditional jump. Exploitation to change the flow of control has not been demonstrated. The issue occurs in from_header in list.c via a V7 archive in which mtime has approximately 11 whitespace characters.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="2" name="tar" release="4.u1.fos23" version="1.34">
					<filename>tar-1.34-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tar-1.34-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="tar-help" release="4.u1.fos23" version="1.34">
					<filename>tar-help-1.34-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tar-help-1.34-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="tar" release="4.u1.fos23" version="1.34">
					<filename>tar-1.34-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/tar-1.34-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2057</id>
		<title>An update for tmux is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-13"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47016" id="CVE-2022-47016" title="CVE-2022-47016" type="cve"></reference>
		</references>
		<description>CVE-2022-47016:** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="tmux" release="3.u1.fos23" version="3.2a">
					<filename>tmux-3.2a-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tmux-3.2a-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tmux-help" release="3.u1.fos23" version="3.2a">
					<filename>tmux-help-3.2a-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tmux-help-3.2a-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tmux" release="3.u1.fos23" version="3.2a">
					<filename>tmux-3.2a-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/tmux-3.2a-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2058</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42252" id="CVE-2022-42252" title="CVE-2022-42252" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43980" id="CVE-2021-43980" title="CVE-2021-43980" type="cve"></reference>
		</references>
		<description>CVE-2022-42252:If Apache Tomcat 8.5.0 to 8.5.82, 9.0.0-M1 to 9.0.67, 10.0.0-M1 to 10.0.26 or 10.1.0-M1 to 10.1.0 was configured to ignore invalid HTTP headers via setting rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did not reject a request containing an invalid Content-Length header making a request smuggling attack possible if Tomcat was located behind a reverse proxy that also failed to reject the request with the invalid header.&#xA;CVE-2021-43980:The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug in Apache Tomcat 10.1.0 to 10.1.0-M12, 10.0.0-M1 to 10.0.18, 9.0.0-M1 to 9.0.60 and 8.5.0 to 8.5.77 that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="1" name="tomcat" release="29.u4.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-29.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tomcat-9.0.10-29.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="29.u4.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-29.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tomcat-jsvc-9.0.10-29.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="29.u4.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-29.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tomcat-help-9.0.10-29.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2059</id>
		<title>An update for tpm2-tss is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-01-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22745" id="CVE-2023-22745" title="CVE-2023-22745" type="cve"></reference>
		</references>
		<description>CVE-2023-22745:tpm2-tss is an open source software implementation of the Trusted Computing Group (TCG) Trusted Platform Module (TPM) 2 Software Stack (TSS2). In affected versions `Tss2_RC_SetHandler` and `Tss2_RC_Decode` both index into `layer_handler` with an 8 bit layer number, but the array only has `TPM2_ERROR_TSS2_RC_LAYER_COUNT` entries, so trying to add a handler for higher-numbered layers or decode a response code with such a layer number reads/writes past the end of the buffer. This Buffer overrun, could result in arbitrary code execution. An example attack would be a MiTM bus attack that returns 0xFFFFFFFF for the RC. Given the common use case of TPM modules an attacker must have local access to the target machine with local system privileges which allows access to the TPM system. Usually TPM access requires administrative privilege.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="tpm2-tss" release="3.u1.fos23" version="3.1.0">
					<filename>tpm2-tss-3.1.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tpm2-tss-3.1.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tpm2-tss-devel" release="3.u1.fos23" version="3.1.0">
					<filename>tpm2-tss-devel-3.1.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tpm2-tss-devel-3.1.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tpm2-tss-help" release="3.u1.fos23" version="3.1.0">
					<filename>tpm2-tss-help-3.1.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/tpm2-tss-help-3.1.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tpm2-tss" release="3.u1.fos23" version="3.1.0">
					<filename>tpm2-tss-3.1.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/tpm2-tss-3.1.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tpm2-tss-devel" release="3.u1.fos23" version="3.1.0">
					<filename>tpm2-tss-devel-3.1.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/tpm2-tss-devel-3.1.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2060</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0051" id="CVE-2023-0051" title="CVE-2023-0051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0054" id="CVE-2023-0054" title="CVE-2023-0054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0049" id="CVE-2023-0049" title="CVE-2023-0049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0288" id="CVE-2023-0288" title="CVE-2023-0288" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47024" id="CVE-2022-47024" title="CVE-2022-47024" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0433" id="CVE-2023-0433" title="CVE-2023-0433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1170" id="CVE-2023-1170" title="CVE-2023-1170" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1175" id="CVE-2023-1175" title="CVE-2023-1175" type="cve"></reference>
		</references>
		<description>CVE-2023-0051:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1144.&#xA;CVE-2023-0054:Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1145.&#xA;CVE-2023-0049:Out-of-bounds Read in GitHub repository vim/vim prior to 9.0.1143.&#xA;CVE-2023-0288:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1189.&#xA;CVE-2022-47024:A null pointer dereference issue was discovered in function gui_x11_create_blank_mouse in gui_x11.c in vim 8.1.2269 thru 9.0.0339 allows attackers to cause denial of service or other unspecified impacts.&#xA;CVE-2023-0433:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1225.&#xA;CVE-2023-1170:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1376.&#xA;CVE-2023-1175:Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="11.u4.fos23" version="9.0">
					<filename>vim-common-9.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/vim-common-9.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="11.u4.fos23" version="9.0">
					<filename>vim-minimal-9.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/vim-minimal-9.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="11.u4.fos23" version="9.0">
					<filename>vim-enhanced-9.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/vim-enhanced-9.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="11.u4.fos23" version="9.0">
					<filename>vim-filesystem-9.0-11.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/vim-filesystem-9.0-11.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="11.u4.fos23" version="9.0">
					<filename>vim-X11-9.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/vim-X11-9.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="11.u4.fos23" version="9.0">
					<filename>vim-common-9.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/vim-common-9.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="11.u4.fos23" version="9.0">
					<filename>vim-minimal-9.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/vim-minimal-9.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="11.u4.fos23" version="9.0">
					<filename>vim-enhanced-9.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/vim-enhanced-9.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="11.u4.fos23" version="9.0">
					<filename>vim-X11-9.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/vim-X11-9.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2061</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-23"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3724" id="CVE-2022-3724" title="CVE-2022-3724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0416" id="CVE-2023-0416" title="CVE-2023-0416" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0411" id="CVE-2023-0411" title="CVE-2023-0411" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0413" id="CVE-2023-0413" title="CVE-2023-0413" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0415" id="CVE-2023-0415" title="CVE-2023-0415" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0417" id="CVE-2023-0417" title="CVE-2023-0417" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4344" id="CVE-2022-4344" title="CVE-2022-4344" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4345" id="CVE-2022-4345" title="CVE-2022-4345" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0412" id="CVE-2023-0412" title="CVE-2023-0412" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1161" id="CVE-2023-1161" title="CVE-2023-1161" type="cve"></reference>
		</references>
		<description>CVE-2022-3724:Crash in the USB HID protocol dissector in Wireshark 3.6.0 to 3.6.8 allows denial of service via packet injection or crafted capture file on Windows&#xA;CVE-2023-0416:GNW dissector crash in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-0411:Excessive loops in multiple dissectors in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-0413:Dissection engine bug in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-0415:iSCSI dissector crash in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-0417:Memory leak in the NFS dissector in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file&#xA;CVE-2022-4344:Memory exhaustion in the Kafka protocol dissector in Wireshark 4.0.0 to 4.0.1 and 3.6.0 to 3.6.9 allows denial of service via packet injection or crafted capture file&#xA;CVE-2022-4345:Infinite loops in the BPv6, OpenFlow, and Kafka protocol dissectors in Wireshark 4.0.0 to 4.0.1 and 3.6.0 to 3.6.9 allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-0412:TIPC dissector crash in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-1161:ISO 15765 and ISO 10681 dissector crash in Wireshark 4.0.0 to 4.0.3 and 3.6.0 to 3.6.11 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="1.u1.fos23" version="3.6.11">
					<filename>wireshark-3.6.11-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/wireshark-3.6.11-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="1.u1.fos23" version="3.6.11">
					<filename>wireshark-devel-3.6.11-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/wireshark-devel-3.6.11-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="1.u1.fos23" version="3.6.11">
					<filename>wireshark-help-3.6.11-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/wireshark-help-3.6.11-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="1.u1.fos23" version="3.6.11">
					<filename>wireshark-3.6.11-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/wireshark-3.6.11-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="1.u1.fos23" version="3.6.11">
					<filename>wireshark-devel-3.6.11-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/wireshark-devel-3.6.11-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="1.u1.fos23" version="3.6.11">
					<filename>wireshark-help-3.6.11-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/wireshark-help-3.6.11-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2062</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-02-14"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0494" id="CVE-2023-0494" title="CVE-2023-0494" type="cve"></reference>
		</references>
		<description>CVE-2023-0494:A vulnerability was found in X.Org. This issue occurs due to a dangling pointer in DeepCopyPointerClasses that can be exploited by ProcXkbSetDeviceInfo() and ProcXkbGetDeviceInfo() to read and write into freed memory. This can lead to local privilege elevation on systems where the X server runs privileged and remote code execution for ssh X forwarding sessions.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-common-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-Xnest-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-Xdmx-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-Xvfb-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-Xephyr-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-devel-1.20.11-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-16.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-help-1.20.11-16.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-16.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xorg-x11-server-source-1.20.11-16.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-common-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-Xnest-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-Xdmx-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-Xvfb-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-Xephyr-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="16.u3.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-16.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/xorg-x11-server-devel-1.20.11-16.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2063</id>
		<title>An update for xstream is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-03-18"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41966" id="CVE-2022-41966" title="CVE-2022-41966" type="cve"></reference>
		</references>
		<description>CVE-2022-41966:XStream serializes Java objects to XML and back again. Versions prior to 1.4.20 may allow a remote attacker to terminate the application with a stack overflow error, resulting in a denial of service only via manipulation the processed input stream. The attack uses the hash code implementation for collections and maps to force recursive hash calculation causing a stack overflow. This issue is patched in version 1.4.20 which handles the stack overflow and raises an InputManipulationException instead. A potential workaround for users who only use HashMap or HashSet and whose XML refers these only as default map or set, is to change the default implementation of java.util.Map and java.util per the code example in the referenced advisory. However, this implies that your application does not care about the implementation of the map and all elements are comparable.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="xstream" release="3.u2.fos23" version="1.4.18">
					<filename>xstream-1.4.18-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xstream-1.4.18-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-javadoc" release="3.u2.fos23" version="1.4.18">
					<filename>xstream-javadoc-1.4.18-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xstream-javadoc-1.4.18-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-hibernate" release="3.u2.fos23" version="1.4.18">
					<filename>xstream-hibernate-1.4.18-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xstream-hibernate-1.4.18-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-benchmark" release="3.u2.fos23" version="1.4.18">
					<filename>xstream-benchmark-1.4.18-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xstream-benchmark-1.4.18-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-parent" release="3.u2.fos23" version="1.4.18">
					<filename>xstream-parent-1.4.18-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/xstream-parent-1.4.18-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2064</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1289" id="CVE-2023-1289" title="CVE-2023-1289" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1906" id="CVE-2023-1906" title="CVE-2023-1906" type="cve"></reference>
		</references>
		<description>CVE-2023-1289:A vulnerability was discovered in ImageMagick where a specially created SVG file loads itself and causes a segmentation fault. This flaw allows a remote attacker to pass a specially crafted SVG file that leads to a segmentation fault, generating many trash files in &#34;/tmp,&#34; resulting in a denial of service. When ImageMagick crashes, it generates a lot of trash files. These trash files can be large if the SVG file contains many render actions. In a denial of service attack, if a remote attacker uploads an SVG file of size t, ImageMagick generates files of size 103*t. If an attacker uploads a 100M SVG, the server will generate about 10G.&#xA;CVE-2023-1906:A heap-based buffer overflow issue was discovered in ImageMagick&#39;s ImportMultiSpectralQuantum() function in MagickCore/quantum-import.c. An attacker could pass specially crafted file to convert, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ImageMagick-7.1.1.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ImageMagick-devel-7.1.1.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ImageMagick-help-7.1.1.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ImageMagick-perl-7.1.1.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ImageMagick-c++-7.1.1.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ImageMagick-c++-devel-7.1.1.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ImageMagick-7.1.1.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ImageMagick-devel-7.1.1.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ImageMagick-help-7.1.1.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ImageMagick-perl-7.1.1.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ImageMagick-c++-7.1.1.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="1.u1.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ImageMagick-c++-devel-7.1.1.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2065</id>
		<title>An update for avahi is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1981" id="CVE-2023-1981" title="CVE-2023-1981" type="cve"></reference>
		</references>
		<description>CVE-2023-1981:It was discovered that the avahi deamon can be locally crashed by a dbus call made by an unprivileged user, causing a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="avahi" release="15.u1.fos23" version="0.8">
					<filename>avahi-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-tools" release="15.u1.fos23" version="0.8">
					<filename>avahi-tools-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-tools-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui" release="15.u1.fos23" version="0.8">
					<filename>avahi-ui-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-ui-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-autoipd" release="15.u1.fos23" version="0.8">
					<filename>avahi-autoipd-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-autoipd-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-dnsconfd" release="15.u1.fos23" version="0.8">
					<filename>avahi-dnsconfd-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-dnsconfd-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-howl-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-compat-howl-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-compat-howl-devel-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-compat-libdns_sd-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-compat-libdns_sd-devel-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-devel-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-devel-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib" release="15.u1.fos23" version="0.8">
					<filename>avahi-glib-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-glib-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-glib-devel-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-glib-devel-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject" release="15.u1.fos23" version="0.8">
					<filename>avahi-gobject-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-gobject-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-gobject-devel-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-gobject-devel-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-gtk3" release="15.u1.fos23" version="0.8">
					<filename>avahi-ui-gtk3-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-ui-gtk3-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-ui-devel-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-ui-devel-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-libs" release="15.u1.fos23" version="0.8">
					<filename>avahi-libs-0.8-15.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-libs-0.8-15.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="avahi-help" release="15.u1.fos23" version="0.8">
					<filename>avahi-help-0.8-15.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/avahi-help-0.8-15.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi" release="15.u1.fos23" version="0.8">
					<filename>avahi-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-tools" release="15.u1.fos23" version="0.8">
					<filename>avahi-tools-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-tools-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui" release="15.u1.fos23" version="0.8">
					<filename>avahi-ui-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-ui-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-autoipd" release="15.u1.fos23" version="0.8">
					<filename>avahi-autoipd-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-autoipd-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-dnsconfd" release="15.u1.fos23" version="0.8">
					<filename>avahi-dnsconfd-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-dnsconfd-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-howl-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-compat-howl-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-compat-howl-devel-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-compat-libdns_sd-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-compat-libdns_sd-devel-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-devel-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-devel-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib" release="15.u1.fos23" version="0.8">
					<filename>avahi-glib-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-glib-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-glib-devel-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-glib-devel-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject" release="15.u1.fos23" version="0.8">
					<filename>avahi-gobject-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-gobject-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-gobject-devel-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-gobject-devel-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-gtk3" release="15.u1.fos23" version="0.8">
					<filename>avahi-ui-gtk3-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-ui-gtk3-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-devel" release="15.u1.fos23" version="0.8">
					<filename>avahi-ui-devel-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-ui-devel-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-libs" release="15.u1.fos23" version="0.8">
					<filename>avahi-libs-0.8-15.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/avahi-libs-0.8-15.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2066</id>
		<title>An update for bluez is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27349" id="CVE-2023-27349" title="CVE-2023-27349" type="cve"></reference>
		</references>
		<description>CVE-2023-27349:This package provides all utilities for use in Bluetooth applications. The BLUETOOTH trademarks are owned by Bluetooth SIG, Inc., U.S.A.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="bluez" release="17.u2.fos23" version="5.54">
					<filename>bluez-5.54-17.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bluez-5.54-17.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bluez-libs" release="17.u2.fos23" version="5.54">
					<filename>bluez-libs-5.54-17.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bluez-libs-5.54-17.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bluez-devel" release="17.u2.fos23" version="5.54">
					<filename>bluez-devel-5.54-17.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bluez-devel-5.54-17.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="bluez-help" release="17.u2.fos23" version="5.54">
					<filename>bluez-help-5.54-17.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bluez-help-5.54-17.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bluez-cups" release="17.u2.fos23" version="5.54">
					<filename>bluez-cups-5.54-17.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bluez-cups-5.54-17.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez" release="17.u2.fos23" version="5.54">
					<filename>bluez-5.54-17.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bluez-5.54-17.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez-libs" release="17.u2.fos23" version="5.54">
					<filename>bluez-libs-5.54-17.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bluez-libs-5.54-17.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez-devel" release="17.u2.fos23" version="5.54">
					<filename>bluez-devel-5.54-17.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bluez-devel-5.54-17.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez-cups" release="17.u2.fos23" version="5.54">
					<filename>bluez-cups-5.54-17.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bluez-cups-5.54-17.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2067</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27533" id="CVE-2023-27533" title="CVE-2023-27533" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27534" id="CVE-2023-27534" title="CVE-2023-27534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27535" id="CVE-2023-27535" title="CVE-2023-27535" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27536" id="CVE-2023-27536" title="CVE-2023-27536" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27538" id="CVE-2023-27538" title="CVE-2023-27538" type="cve"></reference>
		</references>
		<description>CVE-2023-27533:curl supports communicating using the TELNET protocol and as a part of this it offers users to pass on user name and &#34;telnet options&#34; for the servernegotiation. Due to lack of proper input scrubbing and without it being the documented functionality, curl would pass on user name and telnet options to the server as provided. This could allow users to pass in carefully crafted content that pass on content or do option negotiation without the application intending to do so. In particular if an application for example allows users to provide the data or parts of the data.&#xA;CVE-2023-27534:to-become RFC draft](https://datatracker.ietf.org/doc/html/draft-ietf-secsh-scp-sftp-ssh-uri-04) that was to dictate how SFTP URLs work. Due to a bug, the handling of the tilde in SFTP path did however not only replace it when it is used stand-alone as the first path element but also wrongly when used as a mere prefix in the first element. Using a path like `/~2/foo` when accessing a server using the user `dan` (with home directory `/home/dan`) would then quite suprisingly access the file `/home/dan2/foo`. This can be taken advantage of to circumvent filtering or worse.&#xA;CVE-2023-27535:libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, several FTP settings were left out from the configuration match checks, making them match too easily. The settings in questions are `CURLOPT_FTP_ACCOUNT`, `CURLOPT_FTP_ALTERNATIVE_TO_USER`, `CURLOPT_FTP_SSL_CCC` and `CURLOPT_USE_SSL` level.&#xA;CVE-2023-27536:libcurl would reuse a previously created connection even when the GSS delegation (`CURLOPT_GSSAPI_DELEGATION`) option had been changed that could have changed the user&#39;s permissions in a second transfer. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, this GSS delegation setting was left out from the configuration match checks, making them match too easily, affecting krb5/kerberos/negotiate/GSSAPI transfers.&#xA;CVE-2023-27538:libcurl would reuse a previously created connection even when an SSH related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, two SSH settings were left out from the configuration match checks, making them match too easily.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="curl" release="15.u5.fos23" version="7.79.1">
					<filename>curl-7.79.1-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/curl-7.79.1-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="15.u5.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libcurl-7.79.1-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="15.u5.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libcurl-devel-7.79.1-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="15.u5.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-15.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/curl-help-7.79.1-15.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="15.u5.fos23" version="7.79.1">
					<filename>curl-7.79.1-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/curl-7.79.1-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="15.u5.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libcurl-7.79.1-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="15.u5.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libcurl-devel-7.79.1-15.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2068</id>
		<title>An update for dmidecode is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30630" id="CVE-2023-30630" title="CVE-2023-30630" type="cve"></reference>
		</references>
		<description>CVE-2023-30630:Dmidecode reports information about your system&#39;s hardware as described in your system BIOS according to the SMBIOS/DMI standard (see a sample output). This information typically includes system manufacturer, model name, serial number, BIOS version, asset tag as well as a lot of other details of varying level of interest and reliability depending on the manufacturer. This will often include usage status for the CPU sockets, expansion slots (e.g. AGP, PCI, ISA) and memory module slots, and the list of I/O ports (e.g. serial, parallel, USB).DMI data can be used to enable or disable specific portions of kernel code depending on the specific hardware. Thus, one use of dmidecode is for kernel developers to detect system &#34;signatures&#34; and add them to the kernel source code when needed.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="1" name="dmidecode" release="3.u1.fos23" version="3.4">
					<filename>dmidecode-3.4-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/dmidecode-3.4-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dmidecode" release="3.u1.fos23" version="3.4">
					<filename>dmidecode-3.4-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/dmidecode-3.4-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2069</id>
		<title>An update for dnsmasq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28450" id="CVE-2023-28450" title="CVE-2023-28450" type="cve"></reference>
		</references>
		<description>CVE-2023-28450:An issue was discovered in Dnsmasq before 2.90. The default maximum EDNS.0 UDP packet size was set to 4096 but should be 1232 because of DNS Flag Day 2020.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="dnsmasq" release="5.u2.fos23" version="2.86">
					<filename>dnsmasq-2.86-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/dnsmasq-2.86-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="dnsmasq-help" release="5.u2.fos23" version="2.86">
					<filename>dnsmasq-help-2.86-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/dnsmasq-help-2.86-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dnsmasq" release="5.u2.fos23" version="2.86">
					<filename>dnsmasq-2.86-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/dnsmasq-2.86-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dnsmasq-help" release="5.u2.fos23" version="2.86">
					<filename>dnsmasq-help-2.86-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/dnsmasq-help-2.86-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2070</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28617" id="CVE-2023-28617" title="CVE-2023-28617" type="cve"></reference>
		</references>
		<description>CVE-2023-28617:Emacs is the extensible, customizable, self-documenting real-time display editor. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp programming language with extensions to support text editing. And it is an entire ecosystem of functionality beyond text editing, including a project planner, mail and news reader, debugger interface, calendar, and more.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="1" name="emacs" release="10.u2.fos23" version="27.2">
					<filename>emacs-27.2-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-27.2-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="10.u2.fos23" version="27.2">
					<filename>emacs-devel-27.2-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-devel-27.2-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="10.u2.fos23" version="27.2">
					<filename>emacs-lucid-27.2-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-lucid-27.2-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="10.u2.fos23" version="27.2">
					<filename>emacs-nox-27.2-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-nox-27.2-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="10.u2.fos23" version="27.2">
					<filename>emacs-common-27.2-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-common-27.2-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="10.u2.fos23" version="27.2">
					<filename>emacs-terminal-27.2-10.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-terminal-27.2-10.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="10.u2.fos23" version="27.2">
					<filename>emacs-filesystem-27.2-10.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-filesystem-27.2-10.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="10.u2.fos23" version="27.2">
					<filename>emacs-help-27.2-10.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/emacs-help-27.2-10.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="10.u2.fos23" version="27.2">
					<filename>emacs-27.2-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/emacs-27.2-10.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="10.u2.fos23" version="27.2">
					<filename>emacs-devel-27.2-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/emacs-devel-27.2-10.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="10.u2.fos23" version="27.2">
					<filename>emacs-lucid-27.2-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/emacs-lucid-27.2-10.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="10.u2.fos23" version="27.2">
					<filename>emacs-nox-27.2-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/emacs-nox-27.2-10.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="10.u2.fos23" version="27.2">
					<filename>emacs-common-27.2-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/emacs-common-27.2-10.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2071</id>
		<title>An update for freetype is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2004" id="CVE-2023-2004" title="CVE-2023-2004" type="cve"></reference>
		</references>
		<description>CVE-2023-2004:FreeType is written in C, designed to be small,efficient, highly customizable, and  portable while capable of producing high-quality output (glyph images) of most vector and bitmap font formats</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="freetype" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-2.12.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/freetype-2.12.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freetype-demos" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-demos-2.12.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/freetype-demos-2.12.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freetype-devel" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-devel-2.12.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/freetype-devel-2.12.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="freetype-help" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-help-2.12.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/freetype-help-2.12.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-2.12.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/freetype-2.12.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype-demos" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-demos-2.12.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/freetype-demos-2.12.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype-devel" release="2.u1.fos23" version="2.12.1">
					<filename>freetype-devel-2.12.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/freetype-devel-2.12.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2072</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24593" id="CVE-2023-24593" title="CVE-2023-24593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25180" id="CVE-2023-25180" title="CVE-2023-25180" type="cve"></reference>
		</references>
		<description>CVE-2023-24593:GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib&#39;s code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since.&#xA;CVE-2023-25180:GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib&#39;s code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="glib2" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-2.72.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glib2-2.72.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-devel-2.72.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glib2-devel-2.72.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-static" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-static-2.72.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glib2-static-2.72.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-tests-2.72.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glib2-tests-2.72.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-help-2.72.2-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glib2-help-2.72.2-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-2.72.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glib2-2.72.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-devel-2.72.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glib2-devel-2.72.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-static" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-static-2.72.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glib2-static-2.72.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="9.u4.fos23" version="2.72.2">
					<filename>glib2-tests-2.72.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glib2-tests-2.72.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2073</id>
		<title>An update for glusterfs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26253" id="CVE-2023-26253" title="CVE-2023-26253" type="cve"></reference>
		</references>
		<description>CVE-2023-26253:In Gluster GlusterFS 11.0, there is an xlators/mount/fuse/src/fuse-bridge.c notify stack-based buffer over-read.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="glusterfs" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-cli" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-cli-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-cli-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-cloudsync-plugins" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-cloudsync-plugins-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-cloudsync-plugins-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-extra-xlators" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-extra-xlators-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-extra-xlators-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-fuse" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-fuse-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-fuse-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-geo-replication" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-geo-replication-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-geo-replication-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libglusterfs0" release="8.u1.fos23" version="10.0">
					<filename>libglusterfs0-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libglusterfs0-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libglusterfs-devel" release="8.u1.fos23" version="10.0">
					<filename>libglusterfs-devel-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libglusterfs-devel-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfapi0" release="8.u1.fos23" version="10.0">
					<filename>libgfapi0-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfapi0-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfapi-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfapi-devel-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfapi-devel-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfchangelog0" release="8.u1.fos23" version="10.0">
					<filename>libgfchangelog0-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfchangelog0-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfchangelog-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfchangelog-devel-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfchangelog-devel-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfrpc0" release="8.u1.fos23" version="10.0">
					<filename>libgfrpc0-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfrpc0-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfrpc-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfrpc-devel-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfrpc-devel-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfxdr0" release="8.u1.fos23" version="10.0">
					<filename>libgfxdr0-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfxdr0-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfxdr-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfxdr-devel-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libgfxdr-devel-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libglusterd0" release="8.u1.fos23" version="10.0">
					<filename>libglusterd0-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libglusterd0-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-gluster" release="8.u1.fos23" version="10.0">
					<filename>python3-gluster-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-gluster-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glusterfs-resource-agents" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-resource-agents-10.0-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-resource-agents-10.0-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-server" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-server-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-server-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-thin-arbiter" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-thin-arbiter-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-thin-arbiter-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-client-xlators" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-client-xlators-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-client-xlators-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-events" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-events-10.0-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/glusterfs-events-10.0-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-cli" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-cli-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-cli-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-cloudsync-plugins" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-cloudsync-plugins-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-cloudsync-plugins-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-extra-xlators" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-extra-xlators-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-extra-xlators-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-fuse" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-fuse-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-fuse-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-geo-replication" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-geo-replication-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-geo-replication-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libglusterfs0" release="8.u1.fos23" version="10.0">
					<filename>libglusterfs0-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libglusterfs0-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libglusterfs-devel" release="8.u1.fos23" version="10.0">
					<filename>libglusterfs-devel-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libglusterfs-devel-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfapi0" release="8.u1.fos23" version="10.0">
					<filename>libgfapi0-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfapi0-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfapi-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfapi-devel-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfapi-devel-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfchangelog0" release="8.u1.fos23" version="10.0">
					<filename>libgfchangelog0-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfchangelog0-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfchangelog-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfchangelog-devel-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfchangelog-devel-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfrpc0" release="8.u1.fos23" version="10.0">
					<filename>libgfrpc0-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfrpc0-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfrpc-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfrpc-devel-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfrpc-devel-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfxdr0" release="8.u1.fos23" version="10.0">
					<filename>libgfxdr0-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfxdr0-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfxdr-devel" release="8.u1.fos23" version="10.0">
					<filename>libgfxdr-devel-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libgfxdr-devel-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libglusterd0" release="8.u1.fos23" version="10.0">
					<filename>libglusterd0-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libglusterd0-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-gluster" release="8.u1.fos23" version="10.0">
					<filename>python3-gluster-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-gluster-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-server" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-server-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-server-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-thin-arbiter" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-thin-arbiter-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-thin-arbiter-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-client-xlators" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-client-xlators-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-client-xlators-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-events" release="8.u1.fos23" version="10.0">
					<filename>glusterfs-events-10.0-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/glusterfs-events-10.0-8.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2074</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0361" id="CVE-2023-0361" title="CVE-2023-0361" type="cve"></reference>
		</references>
		<description>CVE-2023-0361:A timing side-channel in the handling of RSA ClientKeyExchange messages was discovered in GnuTLS. This side-channel can be sufficient to recover the key encrypted in the RSA ciphertext across a network in a Bleichenbacher style attack. To achieve a successful decryption the attacker would need to send a large amount of specially crafted messages to the vulnerable server. By recovering the secret from the ClientKeyExchange message, the attacker would be able to decrypt the application data exchanged over that connection.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="gnutls" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/gnutls-3.7.2-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/gnutls-devel-3.7.2-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/gnutls-utils-3.7.2-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnutls-help" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-help-3.7.2-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/gnutls-help-3.7.2-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/gnutls-3.7.2-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/gnutls-devel-3.7.2-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="7.u1.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/gnutls-utils-3.7.2-7.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2075</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25950" id="CVE-2023-25950" title="CVE-2023-25950" type="cve"></reference>
		</references>
		<description>CVE-2023-25950:HTTP request/response smuggling vulnerability in HAProxy version 2.7.0, and 2.6.1 to 2.6.7 allows a remote attacker to alter a legitimate user&#39;s request. As a result, the attacker may obtain sensitive information or cause a denial-of-service (DoS) condition.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="3.u2.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/haproxy-2.6.6-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="3.u2.fos23" version="2.6.6">
					<filename>haproxy-help-2.6.6-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/haproxy-help-2.6.6-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="3.u2.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/haproxy-2.6.6-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2076</id>
		<title>An update for hdf5 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13867" id="CVE-2018-13867" title="CVE-2018-13867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14031" id="CVE-2018-14031" title="CVE-2018-14031" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-16438" id="CVE-2018-16438" title="CVE-2018-16438" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8396" id="CVE-2019-8396" title="CVE-2019-8396" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10812" id="CVE-2020-10812" title="CVE-2020-10812" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37501" id="CVE-2021-37501" title="CVE-2021-37501" type="cve"></reference>
		</references>
		<description>CVE-2018-13867:An issue was discovered in the HDF HDF5 1.8.20 library. There is an out of bounds read in the function H5F__accum_read in H5Faccum.c.&#xA;CVE-2018-14031:An issue was discovered in the HDF HDF5 1.8.20 library. There is a heap-based buffer over-read in the function H5T_copy in H5T.c.&#xA;CVE-2018-16438:An issue was discovered in the HDF HDF5 1.8.20 library. There is an out of bounds read in H5L_extern_query at H5Lexternal.c.&#xA;CVE-2019-8396:A buffer overflow in H5O__layout_encode in H5Olayout.c in the HDF HDF5 through 1.10.4 library allows attackers to cause a denial of service via a crafted HDF5 file. This issue was triggered while repacking an HDF5 file, aka &#34;Invalid write of size 2.&#34;&#xA;CVE-2020-10812:An issue was discovered in HDF5 through 1.12.0. A NULL pointer dereference exists in the function H5F_get_nrefs() located in H5Fquery.c. It allows an attacker to cause Denial of Service.&#xA;CVE-2021-37501:Buffer Overflow vulnerability in HDFGroup hdf5-h5dump 1.12.0 through 1.13.0 allows attackers to cause a denial of service via h5tools_str_sprint in /hdf5/tools/lib/h5tools_str.c.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="hdf5" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-devel" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-devel-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-devel-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-mpich-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-mpich-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-devel" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-mpich-devel-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-mpich-devel-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-static" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-mpich-static-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-mpich-static-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-openmpi-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-openmpi-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-devel" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-openmpi-devel-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-openmpi-devel-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-static" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-openmpi-static-1.12.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/hdf5-openmpi-static-1.12.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-devel" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-devel-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-devel-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-mpich-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-mpich-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-devel" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-mpich-devel-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-mpich-devel-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-static" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-mpich-static-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-mpich-static-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-openmpi-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-openmpi-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-devel" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-openmpi-devel-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-openmpi-devel-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-static" release="4.u3.fos23" version="1.12.1">
					<filename>hdf5-openmpi-static-1.12.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/hdf5-openmpi-static-1.12.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2077</id>
		<title>An update for jetty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2047" id="CVE-2022-2047" title="CVE-2022-2047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2048" id="CVE-2022-2048" title="CVE-2022-2048" type="cve"></reference>
		</references>
		<description>CVE-2022-2047:In Eclipse Jetty versions 9.4.0 thru 9.4.46, and 10.0.0 thru 10.0.9, and 11.0.0 thru 11.0.9 versions, the parsing of the authority segment of an http scheme URI, the Jetty HttpURI class improperly detects an invalid input as a hostname. This can lead to failures in a Proxy scenario.&#xA;CVE-2022-2048:In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="noarch" epoch="0" name="jetty" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-client" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-client-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-client-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-continuation" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-continuation-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-continuation-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http-spi" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http-spi-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http-spi-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-io" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-io-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-io-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jaas" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jaas-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jaas-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jsp" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jsp-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jsp-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-security" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-security-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-security-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-server" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-server-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-server-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-servlet" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-servlet-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-servlet-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-util" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-util-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-util-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-webapp" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-webapp-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-webapp-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jmx" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jmx-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jmx-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-xml" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-xml-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-xml-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-project" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-project-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-project-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-deploy" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-deploy-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-deploy-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-annotations" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-annotations-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-annotations-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-ant" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-ant-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-ant-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-cdi" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-cdi-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-cdi-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-fcgi-client" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-fcgi-client-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-fcgi-client-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-fcgi-server" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-fcgi-server-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-fcgi-server-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-infinispan" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-infinispan-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-infinispan-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jaspi" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jaspi-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jaspi-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jndi" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jndi-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jndi-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jspc-maven-plugin" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jspc-maven-plugin-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jspc-maven-plugin-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-maven-plugin" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-maven-plugin-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-maven-plugin-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-plus" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-plus-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-plus-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-proxy" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-proxy-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-proxy-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-rewrite" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-rewrite-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-rewrite-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-servlets" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-servlets-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-servlets-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-spring" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-spring-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-spring-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-start" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-start-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-start-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-unixsocket" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-unixsocket-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-unixsocket-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-util-ajax" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-util-ajax-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-util-ajax-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-api" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-websocket-api-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-websocket-api-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-client" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-websocket-client-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-websocket-client-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-common" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-websocket-common-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-websocket-common-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-server" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-websocket-server-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-websocket-server-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-servlet" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-websocket-servlet-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-websocket-servlet-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-javax-websocket-client-impl" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-javax-websocket-client-impl-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-javax-websocket-client-impl-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-javax-websocket-server-impl" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-javax-websocket-server-impl-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-javax-websocket-server-impl-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-nosql" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-nosql-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-nosql-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-httpservice" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-httpservice-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-httpservice-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-boot" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-osgi-boot-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-osgi-boot-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-boot-warurl" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-osgi-boot-warurl-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-osgi-boot-warurl-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-boot-jsp" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-osgi-boot-jsp-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-osgi-boot-jsp-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-alpn" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-osgi-alpn-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-osgi-alpn-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-quickstart" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-quickstart-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-quickstart-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-alpn-client" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-alpn-client-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-alpn-client-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-alpn-server" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-alpn-server-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-alpn-server-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-client" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http2-client-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http2-client-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-common" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http2-common-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http2-common-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-hpack" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http2-hpack-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http2-hpack-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-http-client-transport" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http2-http-client-transport-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http2-http-client-transport-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-server" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-http2-server-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-http2-server-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jstl" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-jstl-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-jstl-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-javadoc" release="3.u1.fos23" version="9.4.16">
					<filename>jetty-javadoc-9.4.16-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/jetty-javadoc-9.4.16-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2078</id>
		<title>An update for json-smart is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1370" id="CVE-2023-1370" title="CVE-2023-1370" type="cve"></reference>
		</references>
		<description>CVE-2023-1370:[Json-smart](https://netplex.github.io/json-smart/) is a performance focused, JSON processor lib. When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the code does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause a stack exhaustion (stack overflow) and crash the software.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="noarch" epoch="0" name="json-smart" release="2.u1.fos23" version="2.2">
					<filename>json-smart-2.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/json-smart-2.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="json-smart-javadoc" release="2.u1.fos23" version="2.2">
					<filename>json-smart-javadoc-2.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/json-smart-javadoc-2.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2079</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36280" id="CVE-2022-36280" title="CVE-2022-36280" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4269" id="CVE-2022-4269" title="CVE-2022-4269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48423" id="CVE-2022-48423" title="CVE-2022-48423" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48424" id="CVE-2022-48424" title="CVE-2022-48424" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48425" id="CVE-2022-48425" title="CVE-2022-48425" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0266" id="CVE-2023-0266" title="CVE-2023-0266" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1079" id="CVE-2023-1079" title="CVE-2023-1079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1249" id="CVE-2023-1249" title="CVE-2023-1249" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1281" id="CVE-2023-1281" title="CVE-2023-1281" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1380" id="CVE-2023-1380" title="CVE-2023-1380" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1382" id="CVE-2023-1382" title="CVE-2023-1382" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1513" id="CVE-2023-1513" title="CVE-2023-1513" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1611" id="CVE-2023-1611" title="CVE-2023-1611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1670" id="CVE-2023-1670" title="CVE-2023-1670" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1855" id="CVE-2023-1855" title="CVE-2023-1855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1859" id="CVE-2023-1859" title="CVE-2023-1859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1872" id="CVE-2023-1872" title="CVE-2023-1872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1989" id="CVE-2023-1989" title="CVE-2023-1989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1990" id="CVE-2023-1990" title="CVE-2023-1990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1998" id="CVE-2023-1998" title="CVE-2023-1998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2006" id="CVE-2023-2006" title="CVE-2023-2006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28327" id="CVE-2023-28327" title="CVE-2023-28327" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28328" id="CVE-2023-28328" title="CVE-2023-28328" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28466" id="CVE-2023-28466" title="CVE-2023-28466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30456" id="CVE-2023-30456" title="CVE-2023-30456" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30772" id="CVE-2023-30772" title="CVE-2023-30772" type="cve"></reference>
		</references>
		<description>CVE-2022-36280:An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file &#39;/dev/dri/renderD128 (or Dxxx)&#39;. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).&#xA;CVE-2022-4269:A flaw was found in the Linux kernel Traffic Control (TC) subsystem. Using a specific networking configuration (redirecting egress packets to ingress using TC action &#34;mirred&#34;) a local unprivileged user could trigger a CPU soft lockup (ABBA deadlock) when the transport protocol in use (TCP or SCTP) does a retransmission, resulting in a denial of service condition.&#xA;CVE-2022-48423:In the Linux kernel before 6.1.3, fs/ntfs3/record.c does not validate resident attribute names. An out-of-bounds write may occur.&#xA;CVE-2022-48424:In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur.&#xA;CVE-2022-48425:In the Linux kernel through 6.2.7, fs/ntfs3/inode.c has an invalid kfree because it does not validate MFT flags before replaying logs.&#xA;CVE-2023-0266:A use after free vulnerability exists in the ALSA PCM package in the Linux Kernel. SNDRV_CTL_IOCTL_ELEM_{READ|WRITE}32 is missing locks that can be used in a use-after-free that can result in a priviledge escalation to gain ring0 access from the system user. We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e&#xA;CVE-2023-1079:A flaw was found in the Linux kernel. A use-after-free may be triggered in asus_kbd_backlight_set when plugging/disconnecting in a malicious USB device, which advertises itself as an Asus device. Similarly to the previous known CVE-2023-25012, but in asus devices, the work_struct may be scheduled by the LED controller while the device is disconnecting, triggering a use-after-free on the struct asus_kbd_leds *led structure. A malicious USB device may exploit the issue to cause memory corruption with controlled data.&#xA;CVE-2023-1249:A use-after-free flaw was found in the Linux kernel’s core dump subsystem. This flaw allows a local user to crash the system. Only if patch 390031c94211 (&#34;coredump: Use the vma snapshot in fill_files_note&#34;) not applied yet, then kernel could be affected.&#xA;CVE-2023-1281:Use After Free vulnerability in Linux kernel traffic control index filter (tcindex) allows Privilege Escalation. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when &#39;tcf_exts_exec()&#39; is called with the destroyed tcf_ext. A local attacker user can use this vulnerability to elevate its privileges to root. This issue affects Linux Kernel: from 4.14 before git commit ee059170b1f7e94e55fa6cadee544e176a6e59c2.&#xA;CVE-2023-1380:in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info-&gt;req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service.&#xA;CVE-2023-1382:A data race flaw was found in the Linux kernel, between where con is allocated and con-&gt;sock is set. This issue leads to a NULL pointer dereference when accessing con-&gt;sock-&gt;sk in net/tipc/topsrv.c in the tipc protocol in the Linux kernel.&#xA;CVE-2023-1513:A flaw was found in KVM. When calling the KVM_GET_DEBUGREGS ioctl, on 32-bit systems, there might be some uninitialized portions of the kvm_debugregs structure that could be copied to userspace, causing an information leak.&#xA;CVE-2023-1611:A use-after-free flaw was found in btrfs_search_slot in fs/btrfs/ctree.c in btrfs in the Linux Kernel.This flaw allows an attacker to crash the system and possibly cause a kernel information lea&#xA;CVE-2023-1670:A flaw use after free in the Linux kernel Xircom 16-bit PCMCIA (PC-card) Ethernet driver was found.A local user could use this flaw to crash the system or potentially escalate their privileges on the system.&#xA;CVE-2023-1855:A use-after-free flaw was found in xgene_hwmon_remove in drivers/hwmon/xgene-hwmon.c in the Hardware Monitoring Linux Kernel Driver (xgene-hwmon). This flaw could allow a local attacker to crash the system due to a race problem. This vulnerability could even lead to a kernel information leak problem.&#xA;CVE-2023-1859:A use-after-free flaw was found in xen_9pfs_front_removet in net/9p/trans_xen.c in Xen transport for 9pfs in the Linux Kernel. This flaw could allow a local attacker to crash the system due to a race problem, possibly leading to a kernel information leak.&#xA;CVE-2023-1872:A use-after-free vulnerability in the Linux Kernel io_uring system can be exploited to achieve local privilege escalation. The io_file_get_fixed function lacks the presence of ctx-&gt;uring_lock which can lead to a Use-After-Free vulnerability due a race condition with fixed files getting unregistered. We recommend upgrading past commit&#xA;CVE-2023-1989:A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices.&#xA;CVE-2023-1990:A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem.&#xA;CVE-2023-1998:The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.&#xA;CVE-2023-2006:A race condition was found in the Linux kernel&#39;s RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.&#xA;CVE-2023-28327:Reference:https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/https://lore.kernel.org/netdev/20221127012412.37969-3-kuniyu@amazon.com/T/&#xA;CVE-2023-28328:A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service.&#xA;CVE-2023-28466:do_tls_getsockopt in net/tls/tls_main.c in the Linux kernel through 6.2.6 lacks a lock_sock call, leading to a race condition (with a resultant use-after-free or NULL pointer dereference).&#xA;CVE-2023-30456:An issue was discovered in arch/x86/kvm/vmx/nested.c in the Linux kernel before 6.2.8. nVMX on x86_64 lacks consistency checks for CR0 and CR4.&#xA;CVE-2023-30772:The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/power/supply/da9150-charger.c if a physically proximate attacker unplugs a device.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-headers-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-devel-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-tools-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-tools-devel-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perf-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-perf-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bpftool-5.10.0-136.30.0.106.u42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-headers-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-devel-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-tools-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-tools-devel-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/perf-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-perf-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.30.0.106.u42.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bpftool-5.10.0-136.30.0.106.u42.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2080</id>
		<title>An update for libfastjson is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12762" id="CVE-2020-12762" title="CVE-2020-12762" type="cve"></reference>
		</references>
		<description>CVE-2020-12762:json-c through 0.14 has an integer overflow and out-of-bounds write via a large JSON file, as demonstrated by printbuf_memappend.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="libfastjson" release="3.u1.fos23" version="0.99.9">
					<filename>libfastjson-0.99.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libfastjson-0.99.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libfastjson-devel" release="3.u1.fos23" version="0.99.9">
					<filename>libfastjson-devel-0.99.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libfastjson-devel-0.99.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libfastjson" release="3.u1.fos23" version="0.99.9">
					<filename>libfastjson-0.99.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libfastjson-0.99.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libfastjson-devel" release="3.u1.fos23" version="0.99.9">
					<filename>libfastjson-devel-0.99.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libfastjson-devel-0.99.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2081</id>
		<title>An update for libldb is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0614" id="CVE-2023-0614" title="CVE-2023-0614" type="cve"></reference>
		</references>
		<description>CVE-2023-0614:The fix in 4.6.16, 4.7.9, 4.8.4 and 4.9.7 for CVE-2018-10919 Confidential attribute disclosure vi LDAP filters was insufficient and an attacker may be able to obtain confidential BitLocker recovery keys from a Samba AD DC.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="libldb" release="2.u1.fos23" version="2.6.1">
					<filename>libldb-2.6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libldb-2.6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libldb-devel" release="2.u1.fos23" version="2.6.1">
					<filename>libldb-devel-2.6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libldb-devel-2.6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python-ldb-devel-common" release="2.u1.fos23" version="2.6.1">
					<filename>python-ldb-devel-common-2.6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python-ldb-devel-common-2.6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-ldb" release="2.u1.fos23" version="2.6.1">
					<filename>python3-ldb-2.6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-ldb-2.6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-ldb-devel" release="2.u1.fos23" version="2.6.1">
					<filename>python3-ldb-devel-2.6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-ldb-devel-2.6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libldb-help" release="2.u1.fos23" version="2.6.1">
					<filename>libldb-help-2.6.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libldb-help-2.6.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libldb" release="2.u1.fos23" version="2.6.1">
					<filename>libldb-2.6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libldb-2.6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libldb-devel" release="2.u1.fos23" version="2.6.1">
					<filename>libldb-devel-2.6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libldb-devel-2.6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python-ldb-devel-common" release="2.u1.fos23" version="2.6.1">
					<filename>python-ldb-devel-common-2.6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python-ldb-devel-common-2.6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-ldb" release="2.u1.fos23" version="2.6.1">
					<filename>python3-ldb-2.6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-ldb-2.6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-ldb-devel" release="2.u1.fos23" version="2.6.1">
					<filename>python3-ldb-devel-2.6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-ldb-devel-2.6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2082</id>
		<title>An update for liblouis is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26769" id="CVE-2023-26769" title="CVE-2023-26769" type="cve"></reference>
		</references>
		<description>CVE-2023-26769:Buffer Overflow vulnerability found in Liblouis Lou_Trace v.3.24.0 allows a remote attacker to cause a denial of service via the resolveSubtable function at compileTranslationTabel.c.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="liblouis" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-3.7.0-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/liblouis-3.7.0-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="liblouis-devel" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-devel-3.7.0-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/liblouis-devel-3.7.0-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="liblouis-utils" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-utils-3.7.0-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/liblouis-utils-3.7.0-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="liblouis-help" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-help-3.7.0-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/liblouis-help-3.7.0-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-louis" release="5.u2.fos23" version="3.7.0">
					<filename>python3-louis-3.7.0-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-louis-3.7.0-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblouis" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-3.7.0-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/liblouis-3.7.0-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblouis-devel" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-devel-3.7.0-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/liblouis-devel-3.7.0-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblouis-utils" release="5.u2.fos23" version="3.7.0">
					<filename>liblouis-utils-3.7.0-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/liblouis-utils-3.7.0-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2083</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28484" id="CVE-2023-28484" title="CVE-2023-28484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29469" id="CVE-2023-29469" title="CVE-2023-29469" type="cve"></reference>
		</references>
		<description>CVE-2023-28484:In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.&#xA;CVE-2023-29469:An issue was discovered in libxml2 before 2.10.4. When hashing empty dict strings in a crafted XML document, xmlDictComputeFastKey in dict.c can produce non-deterministic values, leading to various logic and memory errors, such as a double free. This behavior occurs because there is an attempt to use the first byte of an empty string, and any value is possible (not solely the &#39;\0&#39; value).</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="libxml2" release="5.u1.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libxml2-2.9.14-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="5.u1.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libxml2-devel-2.9.14-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="5.u1.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-libxml2-2.9.14-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="5.u1.fos23" version="2.9.14">
					<filename>libxml2-help-2.9.14-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libxml2-help-2.9.14-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="5.u1.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libxml2-2.9.14-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="5.u1.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libxml2-devel-2.9.14-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="5.u1.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-libxml2-2.9.14-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2084</id>
		<title>An update for lua is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-45985" id="CVE-2021-45985" title="CVE-2021-45985" type="cve"></reference>
		</references>
		<description>CVE-2021-45985:In Lua 5.4.3, an erroneous finalizer called during a tail call leads to a heap-based buffer over-read.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="lua" release="11.u2.fos23" version="5.4.3">
					<filename>lua-5.4.3-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/lua-5.4.3-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lua-devel" release="11.u2.fos23" version="5.4.3">
					<filename>lua-devel-5.4.3-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/lua-devel-5.4.3-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="lua-help" release="11.u2.fos23" version="5.4.3">
					<filename>lua-help-5.4.3-11.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/lua-help-5.4.3-11.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lua" release="11.u2.fos23" version="5.4.3">
					<filename>lua-5.4.3-11.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/lua-5.4.3-11.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lua-devel" release="11.u2.fos23" version="5.4.3">
					<filename>lua-devel-5.4.3-11.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/lua-devel-5.4.3-11.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2085</id>
		<title>An update for nasm is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44370" id="CVE-2022-44370" title="CVE-2022-44370" type="cve"></reference>
		</references>
		<description>CVE-2022-44370:NASM v2.16 was discovered to contain a heap buffer overflow in the component quote_for_pmake() asm/nasm.c:856</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="nasm" release="5.u2.fos23" version="2.15.05">
					<filename>nasm-2.15.05-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/nasm-2.15.05-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nasm-help" release="5.u2.fos23" version="2.15.05">
					<filename>nasm-help-2.15.05-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/nasm-help-2.15.05-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nasm" release="5.u2.fos23" version="2.15.05">
					<filename>nasm-2.15.05-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/nasm-2.15.05-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2086</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"></reference>
		</references>
		<description>CVE-2023-0464:A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0465:Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0466:The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy check when doing certificate verification. However the implementation of the function does not enable the check which allows certificates with invalid or incorrect policies to pass the certificate verification. As suddenly enabling the policy check could break existing deployments it was decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument. Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="1" name="openssl" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-19.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openssl-1.1.1m-19.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-19.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openssl-libs-1.1.1m-19.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-19.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openssl-perl-1.1.1m-19.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-19.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openssl-devel-1.1.1m-19.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-19.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openssl-help-1.1.1m-19.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-19.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openssl-1.1.1m-19.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-19.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openssl-libs-1.1.1m-19.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-19.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openssl-perl-1.1.1m-19.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="19.u5.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-19.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openssl-devel-1.1.1m-19.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2087</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1668" id="CVE-2023-1668" title="CVE-2023-1668" type="cve"></reference>
		</references>
		<description>CVE-2023-1668:A flaw was found in openvswitch (OVS). When processing an IP packet with protocol 0, OVS will install the datapath flow without the action modifying the IP header. This issue results (for both kernel and userspace datapath) in installing a datapath flow matching all IP protocols (nw_proto is wildcarded) for this flow, but with an incorrect action, possibly causing incorrect handling of other IP packets with a != 0 IP protocol that matches this dp flow.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="openvswitch" release="3.u2.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openvswitch-2.12.4-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-devel" release="3.u2.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openvswitch-devel-2.12.4-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-help" release="3.u2.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/openvswitch-help-2.12.4-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-openvswitch" release="3.u2.fos23" version="2.12.4">
					<filename>python3-openvswitch-2.12.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-openvswitch-2.12.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch" release="3.u2.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openvswitch-2.12.4-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-devel" release="3.u2.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openvswitch-devel-2.12.4-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-help" release="3.u2.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/openvswitch-help-2.12.4-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2088</id>
		<title>An update for python-setuptools is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40897" id="CVE-2022-40897" title="CVE-2022-40897" type="cve"></reference>
		</references>
		<description>CVE-2022-40897:Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote attackers to cause a denial of service via HTML in a crafted package or custom PackageIndex page. There is a Regular Expression Denial of Service (ReDoS) in package_index.py.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="noarch" epoch="0" name="python-setuptools" release="5.u1.fos23" version="59.4.0">
					<filename>python-setuptools-59.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python-setuptools-59.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-setuptools" release="5.u1.fos23" version="59.4.0">
					<filename>python3-setuptools-59.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-setuptools-59.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-setuptools-help" release="5.u1.fos23" version="59.4.0">
					<filename>python-setuptools-help-59.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python-setuptools-help-59.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2089</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24329" id="CVE-2023-24329" title="CVE-2023-24329" type="cve"></reference>
		</references>
		<description>CVE-2023-24329:An issue in the urllib.parse component of Python before v3.11 allows attackers to bypass blocklisting methods by supplying a URL that starts with blank characters.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="python3" release="24.u3.fos23" version="3.9.9">
					<filename>python3-3.9.9-24.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-3.9.9-24.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="24.u3.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-24.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-unversioned-command-3.9.9-24.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="24.u3.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-24.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-devel-3.9.9-24.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="24.u3.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-24.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-debug-3.9.9-24.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="24.u3.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-24.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-help-3.9.9-24.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="24.u3.fos23" version="3.9.9">
					<filename>python3-3.9.9-24.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-3.9.9-24.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="24.u3.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-24.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-unversioned-command-3.9.9-24.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="24.u3.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-24.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-devel-3.9.9-24.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="24.u3.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-24.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-debug-3.9.9-24.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2090</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36021" id="CVE-2022-36021" title="CVE-2022-36021" type="cve"></reference>
		</references>
		<description>CVE-2022-36021:Redis is an in-memory database that persists on disk. Authenticated users can use string matching commands (like `SCAN` or `KEYS`) with a specially crafted pattern to trigger a denial-of-service attack on Redis, causing it to hang and consume 100% CPU time.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="redis5" release="5.u1.fos23" version="5.0.7">
					<filename>redis5-5.0.7-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/redis5-5.0.7-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="5.u1.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/redis5-devel-5.0.7-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="5.u1.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/redis5-doc-5.0.7-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="5.u1.fos23" version="5.0.7">
					<filename>redis5-5.0.7-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/redis5-5.0.7-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="5.u1.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/redis5-devel-5.0.7-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2091</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36021" id="CVE-2022-36021" title="CVE-2022-36021" type="cve"></reference>
		</references>
		<description>CVE-2022-36021:Redis is an in-memory database that persists on disk. Authenticated users can use string matching commands (like `SCAN` or `KEYS`) with a specially crafted pattern to trigger a denial-of-service attack on Redis, causing it to hang and consume 100% CPU time.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="redis6" release="2.u1.fos23" version="6.2.7">
					<filename>redis6-6.2.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/redis6-6.2.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="2.u1.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/redis6-devel-6.2.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="2.u1.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/redis6-doc-6.2.7-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="2.u1.fos23" version="6.2.7">
					<filename>redis6-6.2.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/redis6-6.2.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="2.u1.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/redis6-devel-6.2.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2092</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28755" id="CVE-2023-28755" title="CVE-2023-28755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28756" id="CVE-2023-28756" title="CVE-2023-28756" type="cve"></reference>
		</references>
		<description>CVE-2023-28755:A ReDoS issue was discovered in the URI component through 0.12.0 in Ruby through 3.2.1. The URI parser mishandles invalid URLs that have specific characters. It causes an increase in execution time for parsing strings to URI objects.&#xA;CVE-2023-28756:A ReDoS issue was discovered in the Time component through 0.2.1 in Ruby through 3.2.1. The Time parser mishandles invalid URLs that have specific characters. It causes an increase in execution time for parsing strings to Time objects.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="ruby" release="129.u2.fos23" version="3.0.3">
					<filename>ruby-3.0.3-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ruby-3.0.3-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="129.u2.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ruby-devel-3.0.3-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="129.u2.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygems-3.2.32-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="129.u2.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygems-devel-3.2.32-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="129.u2.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-rake-13.0.3-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="129.u2.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-rbs-1.4.0-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="129.u2.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ruby-irb-3.0.3-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="129.u2.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-rdoc-6.3.3-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="129.u2.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ruby-help-3.0.3-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="129.u2.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-bigdecimal-3.0.0-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="129.u2.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-did_you_mean-1.5.0-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="129.u2.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-io-console-0.5.7-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="129.u2.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-json-2.5.1-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="129.u2.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-minitest-5.14.2-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="129.u2.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-openssl-2.2.1-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-power_assert" release="129.u2.fos23" version="1.2.0">
					<filename>rubygem-power_assert-1.2.0-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-power_assert-1.2.0-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="129.u2.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-129.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-psych-3.3.2-129.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="129.u2.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-test-unit-3.3.7-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="129.u2.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-rexml-3.2.5-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="129.u2.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-rss-0.2.9-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="129.u2.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-129.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/rubygem-typeprof-0.15.2-129.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="129.u2.fos23" version="3.0.3">
					<filename>ruby-3.0.3-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ruby-3.0.3-129.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="129.u2.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ruby-devel-3.0.3-129.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="129.u2.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/rubygem-bigdecimal-3.0.0-129.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="129.u2.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/rubygem-io-console-0.5.7-129.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="129.u2.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/rubygem-json-2.5.1-129.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="129.u2.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/rubygem-openssl-2.2.1-129.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="129.u2.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-129.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/rubygem-psych-3.3.2-129.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2093</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28642" id="CVE-2023-28642" title="CVE-2023-28642" type="cve"></reference>
		</references>
		<description>CVE-2023-28642:runc is a CLI tool for spawning and running containers according to the OCI specification. It was found that AppArmor can be bypassed when `/proc` inside the container is symlinked with a specific mount configuration. This issue has been fixed in runc version 1.1.5, by prohibiting symlinked `/proc`. See PR #3785 for details. users are advised to upgrade. Users unable to upgrade should avoid using an untrusted container image.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="runc" release="11.u3.fos23" version="1.1.3">
					<filename>runc-1.1.3-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/runc-1.1.3-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="runc" release="11.u3.fos23" version="1.1.3">
					<filename>runc-1.1.3-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/runc-1.1.3-11.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2094</id>
		<title>An update for screen is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24626" id="CVE-2023-24626" title="CVE-2023-24626" type="cve"></reference>
		</references>
		<description>CVE-2023-24626:socket.c in GNU Screen through 4.9.0, when installed setuid or setgid (the default on platforms such as Arch Linux and FreeBSD), allows local users to send a privileged SIGHUP signal to any PID, causing a denial of service or disruption of the target process.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="1" name="screen" release="2.u1.fos23" version="4.9.0">
					<filename>screen-4.9.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/screen-4.9.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="screen-help" release="2.u1.fos23" version="4.9.0">
					<filename>screen-help-4.9.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/screen-help-4.9.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="screen" release="2.u1.fos23" version="4.9.0">
					<filename>screen-4.9.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/screen-4.9.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2095</id>
		<title>An update for shadow is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29383" id="CVE-2023-29383" title="CVE-2023-29383" type="cve"></reference>
		</references>
		<description>CVE-2023-29383:In Shadow 4.13, it is possible to inject control characters into fields provided to the SUID program chfn (change finger). Although it is not possible to exploit this directly (e.g., adding a new user fails because \n is in the block list), it is possible to misrepresent the /etc/passwd file when viewed. Use of \r manipulations and Unicode characters to work around blocking of the : character make it possible to give the impression that a new user has been added. In other words, an adversary may be able to convince a system administrator to take the system offline (an indirect, social-engineered denial of service) by demonstrating that &#34;cat /etc/passwd&#34; shows a rogue user account.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="2" name="shadow" release="9.u3.fos23" version="4.9">
					<filename>shadow-4.9-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/shadow-4.9-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="shadow-subid-devel" release="9.u3.fos23" version="4.9">
					<filename>shadow-subid-devel-4.9-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/shadow-subid-devel-4.9-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="shadow-help" release="9.u3.fos23" version="4.9">
					<filename>shadow-help-4.9-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/shadow-help-4.9-9.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="shadow" release="9.u3.fos23" version="4.9">
					<filename>shadow-4.9-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/shadow-4.9-9.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="shadow-subid-devel" release="9.u3.fos23" version="4.9">
					<filename>shadow-subid-devel-4.9-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/shadow-subid-devel-4.9-9.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2096</id>
		<title>An update for sqlite is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46908" id="CVE-2022-46908" title="CVE-2022-46908" type="cve"></reference>
		</references>
		<description>CVE-2022-46908:SQLite through 3.40.0, when relying on --safe for execution of an untrusted CLI script, does not properly implement the azProhibitedFunctions protection mechanism, and instead allows UDF functions such as WRITEFILE.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="sqlite" release="5.u2.fos23" version="3.37.2">
					<filename>sqlite-3.37.2-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/sqlite-3.37.2-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sqlite-devel" release="5.u2.fos23" version="3.37.2">
					<filename>sqlite-devel-3.37.2-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/sqlite-devel-3.37.2-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sqlite-help" release="5.u2.fos23" version="3.37.2">
					<filename>sqlite-help-3.37.2-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/sqlite-help-3.37.2-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite" release="5.u2.fos23" version="3.37.2">
					<filename>sqlite-3.37.2-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/sqlite-3.37.2-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite-devel" release="5.u2.fos23" version="3.37.2">
					<filename>sqlite-devel-3.37.2-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/sqlite-devel-3.37.2-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2097</id>
		<title>An update for sudo is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28486" id="CVE-2023-28486" title="CVE-2023-28486" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28487" id="CVE-2023-28487" title="CVE-2023-28487" type="cve"></reference>
		</references>
		<description>CVE-2023-28486:Sudo before 1.9.13 does not escape control characters in log messages.&#xA;CVE-2023-28487:Sudo before 1.9.13 does not escape control characters in sudoreplay output.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="sudo" release="10.u4.fos23" version="1.9.8p2">
					<filename>sudo-1.9.8p2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/sudo-1.9.8p2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sudo-devel" release="10.u4.fos23" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/sudo-devel-1.9.8p2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sudo-help" release="10.u4.fos23" version="1.9.8p2">
					<filename>sudo-help-1.9.8p2-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/sudo-help-1.9.8p2-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo" release="10.u4.fos23" version="1.9.8p2">
					<filename>sudo-1.9.8p2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/sudo-1.9.8p2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo-devel" release="10.u4.fos23" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/sudo-devel-1.9.8p2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2098</id>
		<title>An update for tcpdump is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1801" id="CVE-2023-1801" title="CVE-2023-1801" type="cve"></reference>
		</references>
		<description>CVE-2023-1801:The SMB protocol decoder in tcpdump version 4.99.3 can perform an out-of-bounds write when decoding a crafted network packet.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="14" name="tcpdump" release="6.u1.fos23" version="4.99.1">
					<filename>tcpdump-4.99.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/tcpdump-4.99.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="14" name="tcpdump-help" release="6.u1.fos23" version="4.99.1">
					<filename>tcpdump-help-4.99.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/tcpdump-help-4.99.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="tcpdump" release="6.u1.fos23" version="4.99.1">
					<filename>tcpdump-4.99.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/tcpdump-4.99.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="tcpdump-help" release="6.u1.fos23" version="4.99.1">
					<filename>tcpdump-help-4.99.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/tcpdump-help-4.99.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2099</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28708" id="CVE-2023-28708" title="CVE-2023-28708" type="cve"></reference>
		</references>
		<description>CVE-2023-28708:When using the RemoteIpFilter with requests received from a reverse proxy via HTTP that include the X-Forwarded-Proto header set to https, session cookies created by Apache Tomcat 11.0.0-M1 to 11.0.0.-M2, 10.1.0-M1 to 10.1.5, 9.0.0-M1 to 9.0.71 and 8.5.0 to 8.5.85 did not include the secure attribute. This could result in the user agent transmitting the session cookie over an insecure channel.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="noarch" epoch="1" name="tomcat" release="30.u5.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-30.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/tomcat-9.0.10-30.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="30.u5.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-30.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/tomcat-jsvc-9.0.10-30.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="30.u5.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-30.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/tomcat-help-9.0.10-30.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2100</id>
		<title>An update for undertow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1108" id="CVE-2023-1108" title="CVE-2023-1108" type="cve"></reference>
		</references>
		<description>CVE-2023-1108:A flaw was found in undertow. This issue makes achieving a denial of service possible due to an unexpected handshake status updated in SslConduit, where the loop never terminates.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="noarch" epoch="1" name="undertow" release="4.u1.fos23" version="1.4.0">
					<filename>undertow-1.4.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/undertow-1.4.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="undertow-javadoc" release="4.u1.fos23" version="1.4.0">
					<filename>undertow-javadoc-1.4.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/undertow-javadoc-1.4.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2101</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1264" id="CVE-2023-1264" title="CVE-2023-1264" type="cve"></reference>
		</references>
		<description>CVE-2023-1264:NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1392.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="12.u5.fos23" version="9.0">
					<filename>vim-common-9.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/vim-common-9.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="12.u5.fos23" version="9.0">
					<filename>vim-minimal-9.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/vim-minimal-9.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="12.u5.fos23" version="9.0">
					<filename>vim-enhanced-9.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/vim-enhanced-9.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="12.u5.fos23" version="9.0">
					<filename>vim-filesystem-9.0-12.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/vim-filesystem-9.0-12.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="12.u5.fos23" version="9.0">
					<filename>vim-X11-9.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/vim-X11-9.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="12.u5.fos23" version="9.0">
					<filename>vim-common-9.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/vim-common-9.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="12.u5.fos23" version="9.0">
					<filename>vim-minimal-9.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/vim-minimal-9.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="12.u5.fos23" version="9.0">
					<filename>vim-enhanced-9.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/vim-enhanced-9.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="12.u5.fos23" version="9.0">
					<filename>vim-X11-9.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/vim-X11-9.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2102</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1992" id="CVE-2023-1992" title="CVE-2023-1992" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1993" id="CVE-2023-1993" title="CVE-2023-1993" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1994" id="CVE-2023-1994" title="CVE-2023-1994" type="cve"></reference>
		</references>
		<description>CVE-2023-1992:RPCoRDMA dissector crash in Wireshark 4.0.0 to 4.0.4 and 3.6.0 to 3.6.12 allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-1993:LISP dissector large loop in Wireshark 4.0.0 to 4.0.4 and 3.6.0 to 3.6.12 allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-1994:GQUIC dissector crash in Wireshark 4.0.0 to 4.0.4 and 3.6.0 to 3.6.12 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="3.u2.fos23" version="3.6.11">
					<filename>wireshark-3.6.11-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/wireshark-3.6.11-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="3.u2.fos23" version="3.6.11">
					<filename>wireshark-devel-3.6.11-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/wireshark-devel-3.6.11-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="3.u2.fos23" version="3.6.11">
					<filename>wireshark-help-3.6.11-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/wireshark-help-3.6.11-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="3.u2.fos23" version="3.6.11">
					<filename>wireshark-3.6.11-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/wireshark-3.6.11-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="3.u2.fos23" version="3.6.11">
					<filename>wireshark-devel-3.6.11-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/wireshark-devel-3.6.11-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="3.u2.fos23" version="3.6.11">
					<filename>wireshark-help-3.6.11-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/wireshark-help-3.6.11-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2103</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1393" id="CVE-2023-1393" title="CVE-2023-1393" type="cve"></reference>
		</references>
		<description>CVE-2023-1393:A flaw was found in X.Org Server Overlay Window. A Use-After-Free may lead to local privilege escalation. If a client explicitly destroys the compositor overlay window (aka COW), the Xserver would leave a dangling pointer to that window in the CompScreen structure, which will trigger a use-after-free later.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-common-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-Xnest-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-Xdmx-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-Xvfb-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-Xephyr-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-devel-1.20.11-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-18.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-help-1.20.11-18.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-18.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/xorg-x11-server-source-1.20.11-18.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-common-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-Xnest-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-Xdmx-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-Xvfb-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-Xephyr-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="18.u5.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/xorg-x11-server-devel-1.20.11-18.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2104</id>
		<title>An update for zstd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-05-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4899" id="CVE-2022-4899" title="CVE-2022-4899" type="cve"></reference>
		</references>
		<description>CVE-2022-4899:A vulnerability was found in zstd v1.4.10, where an attacker can supply empty string as an argument to the command line tool to cause buffer overrun.</description>
		<pkglist>
			<collection>
				<name>23.0.1.2</name>
				<package arch="x86_64" epoch="0" name="zstd" release="4.u2.fos23" version="1.5.0">
					<filename>zstd-1.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/zstd-1.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="zstd-devel" release="4.u2.fos23" version="1.5.0">
					<filename>zstd-devel-1.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/zstd-devel-1.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="zstd-help" release="4.u2.fos23" version="1.5.0">
					<filename>zstd-help-1.5.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/zstd-help-1.5.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zstd" release="4.u2.fos23" version="1.5.0">
					<filename>zstd-1.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/zstd-1.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zstd-devel" release="4.u2.fos23" version="1.5.0">
					<filename>zstd-devel-1.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/zstd-devel-1.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2105</id>
		<title>An update for LibRaw is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1729" id="CVE-2023-1729" title="CVE-2023-1729" type="cve"></reference>
		</references>
		<description>CVE-2023-1729:A flaw was found in LibRaw. A heap-buffer-overflow in raw2image_ex() caused by a maliciously crafted file may lead to an application crash.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="LibRaw" release="6.u1.fos23" version="0.20.2">
					<filename>LibRaw-0.20.2-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/LibRaw-0.20.2-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="LibRaw-devel" release="6.u1.fos23" version="0.20.2">
					<filename>LibRaw-devel-0.20.2-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/LibRaw-devel-0.20.2-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="LibRaw" release="6.u1.fos23" version="0.20.2">
					<filename>LibRaw-0.20.2-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/LibRaw-0.20.2-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="LibRaw-devel" release="6.u1.fos23" version="0.20.2">
					<filename>LibRaw-devel-0.20.2-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/LibRaw-devel-0.20.2-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2106</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3736 " id="CVE-2022-3736 " title="CVE-2022-3736 " type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3924" id="CVE-2022-3924" title="CVE-2022-3924" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3094" id="CVE-2022-3094" title="CVE-2022-3094" type="cve"></reference>
		</references>
		<description>CVE-2022-3736 :BIND 9 resolver can crash when stale cache and stale answers are enabled, option `stale-answer-client-timeout` is set to a positive integer, and the resolver receives an RRSIG query. &#xA;This issue affects BIND 9 versions 9.16.12 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.12-S1 through 9.16.36-S1.&#xA;CVE-2022-3924:This issue can affect BIND 9 resolvers with `stale-answer-enable yes;` that also make use of the option `stale-answer-client-timeout`, configured with a value greater than zero. If the resolver receives many queries that require recursion, there will be a corresponding increase in the number of clients that are waiting for recursion to complete. If there are sufficient clients already waiting when a new client query is received so that it is necessary to SERVFAIL the longest waiting client (see BIND 9 ARM `recursive-clients` limit and soft quota), then it is possible for a race to occur between providing a stale answer to this older client and sending an early timeout SERVFAIL, which may cause an assertion failure. This issue affects BIND 9 versions 9.16.12 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.12-S1 through 9.16.36-S1.&#xA;CVE-2022-3094:Sending a flood of dynamic DNS updates may cause `named` to allocate large amounts of memory. This, in turn, may cause `named` to exit due to a lack of free memory. We are not aware of any cases where this has been exploited. Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes. If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop `named` by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome. BIND 9.11 and earlier branches are also affected, but through exhaustion of internal resources rather than memory constraints. This may reduce performance but should not be a significant problem for most servers. Therefore we don&#39;t intend to address this for BIND versions prior to BIND 9.16. This issue affects BIND 9 versions 9.16.0 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.8-S1 through 9.16.36-S1.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="32" name="bind" release="14.u3.fos23" version="9.16.23">
					<filename>bind-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-pkcs11-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-pkcs11-utils-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-pkcs11-libs-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-pkcs11-devel-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="14.u3.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-libs-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="14.u3.fos23" version="9.16.23">
					<filename>bind-license-9.16.23-14.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-license-9.16.23-14.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="14.u3.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-utils-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="14.u3.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-dnssec-utils-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="14.u3.fos23" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-14.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-dnssec-doc-9.16.23-14.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="14.u3.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-devel-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="14.u3.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-14.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bind-chroot-9.16.23-14.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="14.u3.fos23" version="9.16.23">
					<filename>python3-bind-9.16.23-14.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-bind-9.16.23-14.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="14.u3.fos23" version="9.16.23">
					<filename>bind-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-pkcs11-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-pkcs11-utils-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-pkcs11-libs-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="14.u3.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-pkcs11-devel-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="14.u3.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-libs-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="14.u3.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-utils-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="14.u3.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-dnssec-utils-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="14.u3.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-devel-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="14.u3.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-14.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bind-chroot-9.16.23-14.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2107</id>
		<title>An update for git is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25815" id="CVE-2023-25815" title="CVE-2023-25815" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29007" id="CVE-2023-29007" title="CVE-2023-29007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25652" id="CVE-2023-25652" title="CVE-2023-25652" type="cve"></reference>
		</references>
		<description>CVE-2023-25815:In Git for Windows, the Windows port of Git, no localized messages are shipped with the installer. As a consequence, Git is expected not to localize messages at all, and skips the gettext initialization. However, due to a change in MINGW-packages, the `gettext()` function&#39;s implicit initialization no longer uses the runtime prefix but uses the hard-coded path `C:\mingw64\share\locale` to look for localized messages. And since any authenticated user has the permission to create folders in `C:\` (and since `C:\mingw64` does not typically exist), it is possible for low-privilege users to place fake messages in that location where `git.exe` will pick them up in version 2.40.1. This vulnerability is relatively hard to exploit and requires social engineering. For example, a legitimate message at the end of a clone could be maliciously modified to ask the user to direct their web browser to a malicious website, and the user might think that the message comes from Git and is legitimate. It does require local write access by the attacker, though, which makes this attack vector less likely. Version 2.40.1 contains a patch for this issue. Some workarounds are available. Do not work on a Windows machine with shared accounts, or alternatively create a `C:\mingw64` folder and leave it empty. Users who have administrative rights may remove the permission to create folders in `C:\`.&#xA;CVE-2023-29007:Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, a specially crafted `.gitmodules` file with submodule URLs that are longer than 1024 characters can used to exploit a bug in `config.c::git_config_copy_or_rename_section_in_file()`. This bug can be used to inject arbitrary configuration into a user&#39;s `$GIT_DIR/config` when attempting to remove the configuration section associated with that submodule. When the attacker injects configuration values which specify executables to run (such as `core.pager`, `core.editor`, `core.sshCommand`, etc.) this can lead to a remote code execution. A fix A fix is available in versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1. As a workaround, avoid running `git submodule deinit` on untrusted repositories or without prior inspection of any submodule sections in `$GIT_DIR/config`.&#xA;CVE-2023-25652:Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, by feeding specially crafted input to `git apply --reject`, a path outside the working tree can be overwritten with partially controlled contents (corresponding to the rejected hunk(s) from the given patch). A fix is available in versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1. As a workaround, avoid using `git apply` with `--reject` when applying patches from an untrusted source. Use `git apply --stat` to inspect a patch before applying; avoid applying one that create a conflict where a link corresponding to the `*.rej` file exists.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="git" release="11.u3.fos23" version="2.33.0">
					<filename>git-2.33.0-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-2.33.0-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-core" release="11.u3.fos23" version="2.33.0">
					<filename>git-core-2.33.0-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-core-2.33.0-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-daemon" release="11.u3.fos23" version="2.33.0">
					<filename>git-daemon-2.33.0-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-daemon-2.33.0-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-gui" release="11.u3.fos23" version="2.33.0">
					<filename>git-gui-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-gui-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gitk" release="11.u3.fos23" version="2.33.0">
					<filename>gitk-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/gitk-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-web" release="11.u3.fos23" version="2.33.0">
					<filename>git-web-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-web-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-svn" release="11.u3.fos23" version="2.33.0">
					<filename>git-svn-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-svn-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-email" release="11.u3.fos23" version="2.33.0">
					<filename>git-email-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-email-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git" release="11.u3.fos23" version="2.33.0">
					<filename>perl-Git-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perl-Git-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git-SVN" release="11.u3.fos23" version="2.33.0">
					<filename>perl-Git-SVN-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perl-Git-SVN-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-help" release="11.u3.fos23" version="2.33.0">
					<filename>git-help-2.33.0-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/git-help-2.33.0-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git" release="11.u3.fos23" version="2.33.0">
					<filename>git-2.33.0-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/git-2.33.0-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-core" release="11.u3.fos23" version="2.33.0">
					<filename>git-core-2.33.0-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/git-core-2.33.0-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-daemon" release="11.u3.fos23" version="2.33.0">
					<filename>git-daemon-2.33.0-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/git-daemon-2.33.0-11.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2108</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29400" id="CVE-2023-29400" title="CVE-2023-29400" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24540" id="CVE-2023-24540" title="CVE-2023-24540" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24539" id="CVE-2023-24539" title="CVE-2023-24539" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24538" id="CVE-2023-24538" title="CVE-2023-24538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24537" id="CVE-2023-24537" title="CVE-2023-24537" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24536" id="CVE-2023-24536" title="CVE-2023-24536" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24534" id="CVE-2023-24534" title="CVE-2023-24534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24532" id="CVE-2023-24532" title="CVE-2023-24532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41725" id="CVE-2022-41725" title="CVE-2022-41725" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41724" id="CVE-2022-41724" title="CVE-2022-41724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41722" id="CVE-2022-41722" title="CVE-2022-41722" type="cve"></reference>
		</references>
		<description>CVE-2023-29400:Templates containing actions in unquoted HTML attributes (e.g. &#34;attr={{.}}&#34;) executed with empty input can result in output with unexpected results when parsed due to HTML normalization rules. This may allow injection of arbitrary attributes into tags.&#xA;CVE-2023-24540:Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing whitespace characters outside of the character set &#34;\t\n\f\r\u0020\u2028\u2029&#34; in JavaScript contexts that also contain actions may not be properly sanitized during execution.&#xA;CVE-2023-24539:Angle brackets (&lt;&gt;) are not considered dangerous characters when inserted into CSS contexts. Templates containing multiple actions separated by a &#39;/&#39; character can result in unexpectedly closing the CSS context and allowing for injection of unexpected HTML, if executed with untrusted input.&#xA;CVE-2023-24538:Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected.&#xA;With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12.&#xA;CVE-2023-24537:Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow.&#xA;CVE-2023-24536:Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=.&#xA;CVE-2023-24534:HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service. With fix, header parsing now correctly allocates only the memory required to hold parsed headers.&#xA;CVE-2023-24532:The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an incorrect result if called with some specific unreduced scalars (a scalar larger than the order of the curve). This does not impact usages of crypto/ecdsa or crypto/ecdh.&#xA;CVE-2022-41725:A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue.&#xA;CVE-2022-41724:Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth &gt;= RequestClientCert).&#xA;CVE-2022-41723:A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.&#xA;CVE-2022-41722:A path traversal vulnerability exists in filepath.Clean on Windows. On Windows, the filepath.Clean function could transform an invalid path such as &#34;a/../c:/b&#34; into the valid path &#34;c:\b&#34;. This transformation of a relative (if invalid) path into an absolute path could enable a directory traversal attack. After fix, the filepath.Clean function transforms this path into the relative (but still invalid) path &#34;.\c:\b&#34;.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="golang" release="1.u2.fos23" version="1.19.4">
					<filename>golang-1.19.4-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/golang-1.19.4-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="1.u2.fos23" version="1.19.4">
					<filename>golang-help-1.19.4-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/golang-help-1.19.4-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="1.u2.fos23" version="1.19.4">
					<filename>golang-devel-1.19.4-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/golang-devel-1.19.4-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="1.u2.fos23" version="1.19.4">
					<filename>golang-1.19.4-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/golang-1.19.4-1.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2109</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1829" id="CVE-2023-1829" title="CVE-2023-1829" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4382" id="CVE-2022-4382" title="CVE-2022-4382" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0458" id="CVE-2023-0458" title="CVE-2023-0458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2269" id="CVE-2023-2269" title="CVE-2023-2269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2483" id="CVE-2023-2483" title="CVE-2023-2483" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31436" id="CVE-2023-31436" title="CVE-2023-31436" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2176" id="CVE-2023-2176" title="CVE-2023-2176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2194" id="CVE-2023-2194" title="CVE-2023-2194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2166" id="CVE-2023-2166" title="CVE-2023-2166" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2007" id="CVE-2023-2007" title="CVE-2023-2007" type="cve"></reference>
		</references>
		<description>CVE-2023-1829:A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root.&#xA;CVE-2022-4382:A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side.&#xA;CVE-2023-0458:A speculative pointer dereference problem exists in the Linux Kernel on the do_prlimit() function. The resource argument value is controlled and is used in pointer arithmetic for the &#39;rlim&#39; variable and can be used to leak the contents.&#xA;CVE-2023-2269:A denial of service problem was found, due to a possible recursive locking scenario, resulting in a deadlock in table_clear in drivers/md/dm-ioctl.c in the Linux Kernel Device Mapper-Multipathing sub-component.&#xA;CVE-2023-2483:In emac_probe, &amp;adpt-&gt;work_thread is bound with emac_work_thread. Then it will be started by timeout handler emac_tx_timeout or a IRQ handler emac_isr. If we remove the driver which will call emac_remove to make cleanup, there may be a unfinished work. This could lead to a use-after-free.&#xA;CVE-2023-31436:qfq_change_class in net/sched/sch_qfq.c in the Linux kernel before 6.2.13 allows an out-of-bounds write because lmax can exceed QFQ_MIN_LMAX.&#xA;CVE-2023-2176:A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.&#xA;CVE-2023-2194:An out-of-bounds write vulnerability was found in the Linux kernel&#39;s SLIMpro I2C device driver. The userspace &#34;data-&gt;block[0]&#34; variable was not capped to a number between 0-255 and was used as the size of a memcpy, possibly writing beyond the end of dma_buffer. This flaw could allow a local privileged user to crash the system or potentially achieve code execution.&#xA;CVE-2023-2166:A null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service.&#xA;CVE-2023-2007:The specific flaw exists within the DPT I2O Controller driver. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the kernel.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-headers-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-devel-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-tools-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/kernel-tools-devel-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perf-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-perf-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/bpftool-5.10.0-136.31.0.107.u46.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-headers-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-devel-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-tools-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/kernel-tools-devel-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/perf-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-perf-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.31.0.107.u46.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/bpftool-5.10.0-136.31.0.107.u46.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2110</id>
		<title>An update for mod_auth_openidc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28625" id="CVE-2023-28625" title="CVE-2023-28625" type="cve"></reference>
		</references>
		<description>CVE-2023-28625:mod_auth_openidc is an authentication and authorization module for the Apache 2.x HTTP server that implements the OpenID Connect Relying Party functionality. In versions 2.0.0 through 2.4.13.1, when `OIDCStripCookies` is set and a crafted cookie supplied, a NULL pointer dereference would occur, resulting in a segmentation fault. This could be used in a Denial-of-Service attack and thus presents an availability risk. Version 2.4.13.2 contains a patch for this issue. As a workaround, avoid using `OIDCStripCookies`.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="mod_auth_openidc" release="1.fos23" version="2.4.13.2">
					<filename>mod_auth_openidc-2.4.13.2-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mod_auth_openidc-2.4.13.2-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_auth_openidc" release="1.fos23" version="2.4.13.2">
					<filename>mod_auth_openidc-2.4.13.2-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mod_auth_openidc-2.4.13.2-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2111</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37434" id="CVE-2022-37434" title="CVE-2022-37434" type="cve"></reference>
		</references>
		<description>CVE-2022-37434:zlib through 1.2.12 has a heap-based buffer over-read or buffer overflow in inflate in inflate.c via a large gzip header extra field. NOTE: only applications that call inflateGetHeader are affected. Some common applications bundle the affected zlib source code but may be unable to call inflateGetHeader (e.g., see the nodejs/node reference).</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="mysql" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-libs-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-libs-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-config-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-config-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-common-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-common-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-errmsg-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-errmsg-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-server-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-server-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-devel-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-devel-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-test-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-test-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-help-8.0.29-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/mysql-help-8.0.29-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-libs-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-libs-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-config-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-config-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-common-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-common-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-errmsg-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-errmsg-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-server-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-server-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-devel-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-devel-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-test-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-test-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="2.u1.fos23" version="8.0.29">
					<filename>mysql-help-8.0.29-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/mysql-help-8.0.29-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2112</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31484" id="CVE-2023-31484" title="CVE-2023-31484" type="cve"></reference>
		</references>
		<description>CVE-2023-31484:CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="4" name="perl" release="7.u1.fos23" version="5.34.0">
					<filename>perl-5.34.0-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perl-5.34.0-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-libs" release="7.u1.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perl-libs-5.34.0-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-devel" release="7.u1.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perl-devel-5.34.0-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="4" name="perl-help" release="7.u1.fos23" version="5.34.0">
					<filename>perl-help-5.34.0-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/perl-help-5.34.0-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl" release="7.u1.fos23" version="5.34.0">
					<filename>perl-5.34.0-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/perl-5.34.0-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-libs" release="7.u1.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/perl-libs-5.34.0-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-devel" release="7.u1.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/perl-devel-5.34.0-7.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2113</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-02"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38023" id="CVE-2022-38023" title="CVE-2022-38023" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37966" id="CVE-2022-37966" title="CVE-2022-37966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37967" id="CVE-2022-37967" title="CVE-2022-37967" type="cve"></reference>
		</references>
		<description>CVE-2022-38023:Netlogon RPC Elevation of Privilege Vulnerability.&#xA;CVE-2022-37966:Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability&#xA;CVE-2022-37967:Windows Kerberos Elevation of Privilege Vulnerability</description>
		<pkglist>
			<collection>
				<name>23.0.1.3</name>
				<package arch="x86_64" epoch="0" name="samba" release="2.fos23" version="4.17.5">
					<filename>samba-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-libs" release="2.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-libs-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client" release="2.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-client-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common" release="2.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-common-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common-tools" release="2.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-common-tools-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc" release="2.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-dc-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-provision" release="2.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-dc-provision-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-bind-dlz" release="2.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-dc-bind-dlz-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-devel" release="2.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-devel-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-vfs-glusterfs" release="2.fos23" version="4.17.5">
					<filename>samba-vfs-glusterfs-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-vfs-glusterfs-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-krb5-printing" release="2.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-krb5-printing-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient" release="2.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libsmbclient-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient-devel" release="2.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libsmbclient-devel-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient" release="2.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libwbclient-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient-devel" release="2.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/libwbclient-devel-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba" release="2.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-samba-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-test" release="2.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-samba-test-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-dc" release="2.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/python3-samba-dc-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="samba-pidl" release="2.fos23" version="4.17.5">
					<filename>samba-pidl-4.17.5-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-pidl-4.17.5-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-test" release="2.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-test-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-usershares" release="2.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-usershares-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-winbind-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-clients" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-winbind-clients-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-krb5-locator" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-winbind-krb5-locator-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-modules" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-winbind-modules-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ctdb" release="2.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/ctdb-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-help" release="2.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages/samba-help-4.17.5-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba" release="2.fos23" version="4.17.5">
					<filename>samba-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-libs" release="2.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-libs-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client" release="2.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-client-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common" release="2.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-common-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common-tools" release="2.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-common-tools-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc" release="2.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-dc-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-provision" release="2.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-dc-provision-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-bind-dlz" release="2.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-dc-bind-dlz-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-devel" release="2.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-devel-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-krb5-printing" release="2.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-krb5-printing-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient" release="2.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libsmbclient-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient-devel" release="2.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libsmbclient-devel-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient" release="2.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libwbclient-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient-devel" release="2.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/libwbclient-devel-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba" release="2.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-samba-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-test" release="2.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-samba-test-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-dc" release="2.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/python3-samba-dc-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-test" release="2.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-test-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-usershares" release="2.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-usershares-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-winbind-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-clients" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-winbind-clients-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-krb5-locator" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-winbind-krb5-locator-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-modules" release="2.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-winbind-modules-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctdb" release="2.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/ctdb-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-help" release="2.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages/samba-help-4.17.5-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2114</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34151" id="CVE-2023-34151" title="CVE-2023-34151" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34153" id="CVE-2023-34153" title="CVE-2023-34153" type="cve"></reference>
		</references>
		<description>CVE-2023-34151:A vulnerability was found in ImageMagick. This security flaw ouccers as an undefined behaviors of casting double to size_t in svg, mvg and other coders (recurring bugs of CVE-2022-32546).&#xA;CVE-2023-34153:A vulnerability was found in ImageMagick. This security flaw causes a shell command injection vulnerability via video:vsync or video:pixel-format options in VIDEO encoding/decoding.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ImageMagick-7.1.1.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ImageMagick-devel-7.1.1.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ImageMagick-help-7.1.1.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ImageMagick-perl-7.1.1.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ImageMagick-c++-7.1.1.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ImageMagick-c++-devel-7.1.1.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ImageMagick-7.1.1.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ImageMagick-devel-7.1.1.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ImageMagick-help-7.1.1.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ImageMagick-perl-7.1.1.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ImageMagick-c++-7.1.1.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="2.u2.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ImageMagick-c++-devel-7.1.1.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2115</id>
		<title>An update for c-ares is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31130" id="CVE-2023-31130" title="CVE-2023-31130" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32067" id="CVE-2023-32067" title="CVE-2023-32067" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31124" id="CVE-2023-31124" title="CVE-2023-31124" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31147" id="CVE-2023-31147" title="CVE-2023-31147" type="cve"></reference>
		</references>
		<description>CVE-2023-31130:c-ares is an asynchronous resolver library. ares_inet_net_pton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular &#34;0::00:00:00/2&#34; was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via ares_set_sortlist(). However, users may externally use ares_inet_net_pton() for other purposes and thus be vulnerable to more severe issues. This issue has been fixed in 1.19.1.&#xA;CVE-2023-32067:c-ares is an asynchronous resolver library. c-ares is vulnerable to denial of service. If a target resolver sends a query, the attacker forges a malformed UDP packet with a length of 0 and returns them to the target resolver. The target resolver erroneously interprets the 0 length as a graceful shutdown of the connection. This issue has been patched in version 1.19.1.&#xA;CVE-2023-31124:c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build system, CARES_RANDOM_FILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG. This issue was patched in version 1.19.1.&#xA;CVE-2023-31147:c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has been fixed in version 1.19.1.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="c-ares" release="7.u3.fos23" version="1.18.1">
					<filename>c-ares-1.18.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/c-ares-1.18.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="c-ares-devel" release="7.u3.fos23" version="1.18.1">
					<filename>c-ares-devel-1.18.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/c-ares-devel-1.18.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="c-ares-help" release="7.u3.fos23" version="1.18.1">
					<filename>c-ares-help-1.18.1-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/c-ares-help-1.18.1-7.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="c-ares" release="7.u3.fos23" version="1.18.1">
					<filename>c-ares-1.18.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/c-ares-1.18.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="c-ares-devel" release="7.u3.fos23" version="1.18.1">
					<filename>c-ares-devel-1.18.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/c-ares-devel-1.18.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2116</id>
		<title>An update for cloud-init is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2084" id="CVE-2022-2084" title="CVE-2022-2084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1786" id="CVE-2023-1786" title="CVE-2023-1786" type="cve"></reference>
		</references>
		<description>CVE-2022-2084:Sensitive data could be exposed in world readable logs of cloud-init before version 22.3 when schema failures are reported. This leak could include hashed passwords.&#xA;CVE-2023-1786:Sensitive data could be exposed in logs of cloud-init before version 23.1.2. An attacker could use this information to find hashed passwords and possibly escalate their privilege.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="0" name="cloud-init" release="16.u8.fos23" version="21.4">
					<filename>cloud-init-21.4-16.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cloud-init-21.4-16.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cloud-init-help" release="16.u8.fos23" version="21.4">
					<filename>cloud-init-help-21.4-16.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cloud-init-help-21.4-16.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2117</id>
		<title>An update for cpio is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-1197" id="CVE-2015-1197" title="CVE-2015-1197" type="cve"></reference>
		</references>
		<description>CVE-2015-1197:cpio 2.11, when using the --no-absolute-filenames option, allows local users to write to arbitrary files via a symlink attack on a file in an archive.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="cpio" release="8.u1.fos23" version="2.13">
					<filename>cpio-2.13-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cpio-2.13-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cpio-help" release="8.u1.fos23" version="2.13">
					<filename>cpio-help-2.13-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cpio-help-2.13-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cpio" release="8.u1.fos23" version="2.13">
					<filename>cpio-2.13-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cpio-2.13-8.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2118</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32324" id="CVE-2023-32324" title="CVE-2023-32324" type="cve"></reference>
		</references>
		<description>CVE-2023-32324:OpenPrinting CUPS is an open source printing system. In versions 2.4.2 and prior, a heap buffer overflow vulnerability would allow a remote attacker to launch a denial of service (DoS) attack. A buffer overflow vulnerability in the function `format_log_line` could allow remote attackers to cause a DoS on the affected system. Exploitation of the vulnerability can be triggered when the configuration file `cupsd.conf` sets the value of `loglevel `to `DEBUG`.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="cups" release="7.u2.fos23" version="2.4.0">
					<filename>cups-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="7.u2.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-client-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="7.u2.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-devel-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="7.u2.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-libs-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="7.u2.fos23" version="2.4.0">
					<filename>cups-filesystem-2.4.0-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-filesystem-2.4.0-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="7.u2.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-lpd-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="7.u2.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-ipptool-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="7.u2.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-printerapp-2.4.0-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="7.u2.fos23" version="2.4.0">
					<filename>cups-help-2.4.0-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-help-2.4.0-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="7.u2.fos23" version="2.4.0">
					<filename>cups-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="7.u2.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-client-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="7.u2.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-devel-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="7.u2.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-libs-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="7.u2.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-lpd-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="7.u2.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-ipptool-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="7.u2.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-printerapp-2.4.0-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2119</id>
		<title>An update for cups-filters is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24805" id="CVE-2023-24805" title="CVE-2023-24805" type="cve"></reference>
		</references>
		<description>CVE-2023-24805:cups-filters contains backends, filters, and other software required to get the cups printing service working on operating systems other than macos. If you use the Backend Error Handler (beh) to create an accessible network printer, this security vulnerability can cause remote code execution. `beh.c` contains the line `retval = system(cmdline) &gt;&gt; 8;` which calls the `system` command with the operand `cmdline`. `cmdline` contains multiple user controlled, unsanitized values. As a result an attacker with network access to the hosted print server can exploit this vulnerability to inject system commands which are executed in the context of the running server.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="cups-filters" release="3.u1.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-filters-1.28.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters-devel" release="3.u1.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-filters-devel-1.28.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cups-filters-help" release="3.u1.fos23" version="1.28.9">
					<filename>cups-filters-help-1.28.9-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/cups-filters-help-1.28.9-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters" release="3.u1.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-filters-1.28.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters-devel" release="3.u1.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/cups-filters-devel-1.28.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2120</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28322" id="CVE-2023-28322" title="CVE-2023-28322" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28320" id="CVE-2023-28320" title="CVE-2023-28320" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28321" id="CVE-2023-28321" title="CVE-2023-28321" type="cve"></reference>
		</references>
		<description>CVE-2023-28322:An information disclosure vulnerability exists in curl &lt;v8.1.0 when doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously wasused to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the second transfer. The problem exists in the logic for a reused handle when it is (expected to be) changed from a PUT to a POST.&#xA;CVE-2023-28320:A denial of service vulnerability exists in curl &lt;v8.1.0 in the way libcurl provides several different backends for resolving host names, selected at build time. If it is built to use the synchronous resolver, it allows name resolves to time-out slow operations using `alarm()` and `siglongjmp()`. When doing this, libcurl used a global buffer that was not mutex protected and a multi-threaded application might therefore crash or otherwise misbehave.&#xA;CVE-2023-28321:An improper certificate validation vulnerability exists in curl &lt;v8.1.0 in the way it supports matching of wildcard patterns when listed as &#34;Subject Alternative Name&#34; in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to pattern match, but the wildcard check in curl could still check for `x*`, which would match even though the IDN name most likely contained nothing even resembling an `x`.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="curl" release="19.u9.fos23" version="7.79.1">
					<filename>curl-7.79.1-19.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/curl-7.79.1-19.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="19.u9.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-19.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libcurl-7.79.1-19.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="19.u9.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-19.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libcurl-devel-7.79.1-19.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="19.u9.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-19.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/curl-help-7.79.1-19.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="19.u9.fos23" version="7.79.1">
					<filename>curl-7.79.1-19.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/curl-7.79.1-19.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="19.u9.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-19.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libcurl-7.79.1-19.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="19.u9.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-19.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libcurl-devel-7.79.1-19.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2121</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28879" id="CVE-2023-28879" title="CVE-2023-28879" type="cve"></reference>
		</references>
		<description>CVE-2023-28879:In Artifex Ghostscript through 10.01.0, there is a buffer overflow leading to potential corruption of data internal to the PostScript interpreter, in base/sbcp.c. This affects BCPEncode, BCPDecode, TBCPEncode, and TBCPDecode. If the write buffer is filled to one byte less than full, and one then tries to write an escaped character, two bytes are written.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ghostscript-9.55.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ghostscript-devel-9.55.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ghostscript-help-9.55.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ghostscript-tools-dvipdf-9.55.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ghostscript-9.55.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ghostscript-devel-9.55.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="2.u1.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ghostscript-tools-dvipdf-9.55.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2122</id>
		<title>An update for jackson-databind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42003" id="CVE-2022-42003" title="CVE-2022-42003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36518" id="CVE-2020-36518" title="CVE-2020-36518" type="cve"></reference>
		</references>
		<description>CVE-2022-42003:In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled.&#xA;CVE-2022-42004:In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization.&#xA;CVE-2020-36518:jackson-databind before 2.13.0 allows a Java StackOverflow exception and denial of service via a large depth of nested objects.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="0" name="jackson-databind" release="9.u3.fos23" version="2.9.8">
					<filename>jackson-databind-2.9.8-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/jackson-databind-2.9.8-9.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jackson-databind-javadoc" release="9.u3.fos23" version="2.9.8">
					<filename>jackson-databind-javadoc-2.9.8-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/jackson-databind-javadoc-2.9.8-9.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2123</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
		</references>
		<description>CVE-2023-21930:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21954:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21967:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-headless-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-headless-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-headless-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-devel-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-devel-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-demo-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-demo-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-demo-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-src-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-src-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-src-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.372.b07-0.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-javadoc-1.8.0.372.b07-0.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.372.b07-0.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-javadoc-zip-1.8.0.372.b07-0.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-accessibility-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-devel-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-headless-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-headless-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-headless-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-devel-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-devel-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-demo-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-demo-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-demo-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-src-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-src-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-src-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-accessibility-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-devel-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u1.fos23" version="1.8.0.372.b07">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.372.b07-0.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2124</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
		</references>
		<description>CVE-2023-21930:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21967:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-headless-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-headless-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-headless-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-headless-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-devel-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-devel-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-devel-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-devel-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-jmods-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-jmods-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-jmods-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-demo-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-demo-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-demo-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-demo-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-src-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-src-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-src-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-src-slowdebug-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-javadoc-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-javadoc-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-javadoc-zip-11.0.19.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-11-openjdk-javadoc-zip-11.0.19.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-headless-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-headless-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-headless-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-headless-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-devel-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-devel-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-devel-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-devel-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-jmods-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-jmods-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-jmods-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-demo-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-demo-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-demo-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-demo-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-src-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-src-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-src-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-src-slowdebug-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-javadoc-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-javadoc-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.19.7">
					<filename>java-11-openjdk-javadoc-zip-11.0.19.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-11-openjdk-javadoc-zip-11.0.19.7-0.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2125</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
		</references>
		<description>CVE-2023-21930:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21967:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-headless-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-headless-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-headless-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-headless-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-devel-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-devel-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-devel-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-devel-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-jmods-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-jmods-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-jmods-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-demo-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-demo-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-demo-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-demo-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-src-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-src-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-src-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-src-slowdebug-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-javadoc-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-javadoc-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-javadoc-zip-17.0.5.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/java-17-openjdk-javadoc-zip-17.0.5.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-headless-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-headless-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-headless-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-headless-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-devel-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-devel-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-devel-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-devel-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-jmods-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-jmods-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-jmods-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-demo-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-demo-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-demo-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-demo-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-src-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-src-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-src-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-src-slowdebug-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-javadoc-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-javadoc-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u1.fos23" version="17.0.5.8">
					<filename>java-17-openjdk-javadoc-zip-17.0.5.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/java-17-openjdk-javadoc-zip-17.0.5.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2126</id>
		<title>An update for jettison is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45693" id="CVE-2022-45693" title="CVE-2022-45693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40149" id="CVE-2022-40149" title="CVE-2022-40149" type="cve"></reference>
		</references>
		<description>CVE-2022-45685:A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data.&#xA;CVE-2022-45693:Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string.&#xA;CVE-2022-40149:Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="0" name="jettison" release="1.u2.fos23" version="1.3.7">
					<filename>jettison-1.3.7-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/jettison-1.3.7-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jettison-javadoc" release="1.u2.fos23" version="1.3.7">
					<filename>jettison-javadoc-1.3.7-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/jettison-javadoc-1.3.7-1.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2127</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3141" id="CVE-2023-3141" title="CVE-2023-3141" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22998" id="CVE-2023-22998" title="CVE-2023-22998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34256" id="CVE-2023-34256" title="CVE-2023-34256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25012" id="CVE-2023-25012" title="CVE-2023-25012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2985" id="CVE-2023-2985" title="CVE-2023-2985" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3111" id="CVE-2023-3111" title="CVE-2023-3111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32233" id="CVE-2023-32233" title="CVE-2023-32233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1015" id="CVE-2022-1015" title="CVE-2022-1015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32233" id="CVE-2023-32233" title="CVE-2023-32233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2124" id="CVE-2023-2124" title="CVE-2023-2124" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32269" id="CVE-2023-32269" title="CVE-2023-32269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2002" id="CVE-2023-2002" title="CVE-2023-2002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26544" id="CVE-2023-26544" title="CVE-2023-26544" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0459" id="CVE-2023-0459" title="CVE-2023-0459" type="cve"></reference>
		</references>
		<description>CVE-2023-3141:A use-after-free flaw was found in r592_remove in drivers/memstick/host/r592.c in media access in the Linux Kernel. This flaw allows a local attacker to crash the system at device disconnect, possibly leading to a kernel information leak.&#xA;CVE-2023-22998:In the Linux kernel before 6.0.3, drivers/gpu/drm/virtio/virtgpu_object.c misinterprets the drm_gem_shmem_get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).&#xA;CVE-2023-34256:An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4_group_desc_csum does not properly check an offset.&#xA;CVE-2022-48502:An issue was discovered in the Linux kernel before 6.2. The ntfs3 subsystem does not properly check for correctness during disk reads, leading to an out-of-bounds read in ntfs_set_ea in fs/ntfs3/xattr.c.&#xA;CVE-2023-25012:The Linux kernel through 6.1.9 has a Use-After-Free in bigben_remove in drivers/hid/hid-bigbenff.c via a crafted USB device because the LED controllers remain registered for too long.&#xA;CVE-2023-2985:A use after free flaw was found in hfsplus_put_super in fs/hfsplus/super.c in the Linux Kernel. This flaw could allow a local user to cause a denial of service problem.&#xA;CVE-2023-3111:A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag().&#xA;CVE-2023-32233:In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled.&#xA;CVE-2022-1015:A flaw was found in the Linux kernel in linux/net/netfilter/nf_tables_api.c of the netfilter subsystem. This flaw allows a local user to cause an out-of-bounds write issue.&#xA;CVE-2023-32233:In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled.&#xA;CVE-2023-2124:An out-of-bounds memory access flaw was found in the Linux kernel’s XFS file system in how a user restores an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or potentially escalate their privileges on the system.&#xA;CVE-2023-32269:An issue was discovered in the Linux kernel before 6.1.11. In net/netrom/af_netrom.c, there is a use-after-free because accept is also allowed for a successfully connected AF_NETROM socket. However, in order for an attacker to exploit this, the system must have netrom routing configured or the attacker must have the CAP_NET_ADMIN capability.&#xA;CVE-2023-2002:A vulnerability was found in the HCI sockets implementation due to a missing capability check in net/bluetooth/hci_sock.c in the Linux Kernel. This flaw allows an attacker to unauthorized execution of management commands, compromising the confidentiality, integrity, and availability of Bluetooth communication.&#xA;CVE-2023-26544:In the Linux kernel 6.0.8, there is a use-after-free in run_unpack in fs/ntfs3/run.c, related to a difference between NTFS sector size and media sector size.&#xA;CVE-2023-0459:Copy_from_user on 64-bit versions of the Linux kernel does not implement the __uaccess_begin_nospec allowing a user to bypass the &#34;access_ok&#34; check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/kernel-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/kernel-headers-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/kernel-devel-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/kernel-tools-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/kernel-tools-devel-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/perf-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-perf-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/bpftool-5.10.0-136.35.0.111.u63.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/kernel-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/kernel-headers-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/kernel-devel-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/kernel-tools-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/kernel-tools-devel-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/perf-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/python3-perf-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.35.0.111.u63.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/bpftool-5.10.0-136.35.0.111.u63.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2128</id>
		<title>An update for libcap is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2602" id="CVE-2023-2602" title="CVE-2023-2602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2603" id="CVE-2023-2603" title="CVE-2023-2603" type="cve"></reference>
		</references>
		<description>CVE-2023-2602:A vulnerability was found in the pthread_create() function in libcap. This issue may allow a malicious actor to use cause __real_pthread_create() to return an error, which can exhaust the process memory.&#xA;CVE-2023-2603:A vulnerability was found in libcap. This issue occurs in the _libcap_strdup() function and can lead to an integer overflow if the input string is close to 4GiB.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="libcap" release="5.u1.fos23" version="2.61">
					<filename>libcap-2.61-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libcap-2.61-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcap-devel" release="5.u1.fos23" version="2.61">
					<filename>libcap-devel-2.61-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libcap-devel-2.61-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libcap-help" release="5.u1.fos23" version="2.61">
					<filename>libcap-help-2.61-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libcap-help-2.61-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcap" release="5.u1.fos23" version="2.61">
					<filename>libcap-2.61-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libcap-2.61-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcap-devel" release="5.u1.fos23" version="2.61">
					<filename>libcap-devel-2.61-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libcap-devel-2.61-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2129</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30570" id="CVE-2023-30570" title="CVE-2023-30570" type="cve"></reference>
		</references>
		<description>CVE-2023-30570:pluto in Libreswan before 4.11 allows a denial of service (responder SPI mishandling and daemon crash) via unauthenticated IKEv1 Aggressive Mode packets. The earliest affected version is 3.28.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.11">
					<filename>libreswan-4.11-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libreswan-4.11-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.11">
					<filename>libreswan-help-4.11-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libreswan-help-4.11-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.11">
					<filename>libreswan-4.11-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libreswan-4.11-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.11">
					<filename>libreswan-help-4.11-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libreswan-help-4.11-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2130</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1667" id="CVE-2023-1667" title="CVE-2023-1667" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2283" id="CVE-2023-2283" title="CVE-2023-2283" type="cve"></reference>
		</references>
		<description>CVE-2023-1667:A NULL pointer dereference was found In libssh during re-keying with algorithm guessing. This issue may allow an authenticated client to cause a denial of service.&#xA;CVE-2023-2283:A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="libssh" release="7.u2.fos23" version="0.9.6">
					<filename>libssh-0.9.6-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libssh-0.9.6-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="7.u2.fos23" version="0.9.6">
					<filename>libssh-devel-0.9.6-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libssh-devel-0.9.6-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="7.u2.fos23" version="0.9.6">
					<filename>libssh-help-0.9.6-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libssh-help-0.9.6-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="7.u2.fos23" version="0.9.6">
					<filename>libssh-0.9.6-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libssh-0.9.6-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="7.u2.fos23" version="0.9.6">
					<filename>libssh-devel-0.9.6-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libssh-devel-0.9.6-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2131</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1916" id="CVE-2023-1916" title="CVE-2023-1916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2731" id="CVE-2023-2731" title="CVE-2023-2731" type="cve"></reference>
		</references>
		<description>CVE-2023-1916:A flaw was found in tiffcrop, a program distributed by the libtiff package. A specially crafted tiff file can lead to an out-of-bounds read in the extractImageSection function in tools/tiffcrop.c, resulting in a denial of service and limited information disclosure. This issue affects libtiff versions 4.x.&#xA;CVE-2023-2731:A NULL pointer dereference flaw was found in Libtiff&#39;s LZWDecode() function in the libtiff/tif_lzw.c file. This flaw allows a local attacker to craft specific input data that can cause the program to dereference a NULL pointer when decompressing a TIFF format file, resulting in a program crash or denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-25.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtiff-4.3.0-25.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-25.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtiff-devel-4.3.0-25.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-25.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtiff-static-4.3.0-25.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-25.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtiff-tools-4.3.0-25.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-25.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtiff-help-4.3.0-25.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-25.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libtiff-4.3.0-25.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-25.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libtiff-devel-4.3.0-25.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-25.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libtiff-static-4.3.0-25.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="25.u4.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-25.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libtiff-tools-4.3.0-25.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2132</id>
		<title>An update for libtpms is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1017" id="CVE-2023-1017" title="CVE-2023-1017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1018" id="CVE-2023-1018" title="CVE-2023-1018" type="cve"></reference>
		</references>
		<description>CVE-2023-1017:An out-of-bounds write vulnerability exists in TPM2.0&#39;s Module Library allowing writing of a 2-byte data past the end of TPM2.0 command in the CryptParameterDecryption routine. An attacker who can successfully exploit this vulnerability can lead to denial of service (crashing the TPM chip/process or rendering it unusable) and/or arbitrary code execution in the TPM context.&#xA;CVE-2023-1018:An out-of-bounds read vulnerability exists in TPM2.0&#39;s Module Library allowing a 2-byte read past the end of a TPM2.0 command in the CryptParameterDecryption routine. An attacker who can successfully exploit this vulnerability can read or access sensitive data stored in the TPM.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="libtpms" release="8.u1.fos23" version="0.7.3">
					<filename>libtpms-0.7.3-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtpms-0.7.3-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtpms-devel" release="8.u1.fos23" version="0.7.3">
					<filename>libtpms-devel-0.7.3-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libtpms-devel-0.7.3-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtpms" release="8.u1.fos23" version="0.7.3">
					<filename>libtpms-0.7.3-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libtpms-0.7.3-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtpms-devel" release="8.u1.fos23" version="0.7.3">
					<filename>libtpms-devel-0.7.3-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libtpms-devel-0.7.3-8.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2133</id>
		<title>An update for libwebp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1999" id="CVE-2023-1999" title="CVE-2023-1999" type="cve"></reference>
		</references>
		<description>CVE-2023-1999:There exists a use after free/double free in libwebp. An attacker can use the ApplyFiltersAndEncode() function and loop through to free best.bw and assign best = trial pointer. The second loop will then return 0 because of an Out of memory error in VP8 encoder, the pointer is still assigned to trial and the AddressSanitizer will attempt a double free.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="libwebp" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-1.2.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwebp-1.2.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebp-tools" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-tools-1.2.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwebp-tools-1.2.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebp-devel" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-devel-1.2.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwebp-devel-1.2.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebp-java" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-java-1.2.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwebp-java-1.2.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libwebp-help" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-help-1.2.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwebp-help-1.2.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-1.2.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libwebp-1.2.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp-tools" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-tools-1.2.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libwebp-tools-1.2.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp-devel" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-devel-1.2.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libwebp-devel-1.2.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp-java" release="3.u1.fos23" version="1.2.1">
					<filename>libwebp-java-1.2.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libwebp-java-1.2.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2134</id>
		<title>An update for lodash is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-16487" id="CVE-2018-16487" title="CVE-2018-16487" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-3721" id="CVE-2018-3721" title="CVE-2018-3721" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10744" id="CVE-2019-10744" title="CVE-2019-10744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-8203" id="CVE-2020-8203" title="CVE-2020-8203" type="cve"></reference>
		</references>
		<description>CVE-2018-16487:A prototype pollution vulnerability was found in lodash &lt;4.17.11 where the functions merge, mergeWith, and defaultsDeep can be tricked into adding or modifying properties of Object.prototype.&#xA;CVE-2018-3721:lodash node module before 4.17.5 suffers from a Modification of Assumed-Immutable Data (MAID) vulnerability via defaultsDeep, merge, and mergeWith functions, which allows a malicious user to modify the prototype of &#34;Object&#34; via __proto__, causing the addition or modification of an existing property that will exist on all objects.&#xA;CVE-2019-10744:Versions of lodash lower than 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep could be tricked into adding or modifying properties of Object.prototype using a constructor payload.&#xA;CVE-2020-8203:Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="0" name="lodash" release="1.u1.fos23" version="3.10.1">
					<filename>lodash-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/lodash-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="js-lodash" release="1.u1.fos23" version="3.10.1">
					<filename>js-lodash-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/js-lodash-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-compat" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-compat-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-compat-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-node" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-node-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-node-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-cli" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-cli-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-cli-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-add" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-add-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-add-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-after" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-after-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-after-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-arraycopy" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-arraycopy-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-arraycopy-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-arrayeach" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-arrayeach-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-arrayeach-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-arrayevery" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-arrayevery-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-arrayevery-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-arrayfilter" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-arrayfilter-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-arrayfilter-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-arraymap" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-arraymap-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-arraymap-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-ary" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-ary-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-ary-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-assign" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-assign-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-assign-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-at" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-at-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-at-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-attempt" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-attempt-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-attempt-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseassign" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseassign-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseassign-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseat" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseat-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseat-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basecallback" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basecallback-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basecallback-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseclone" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseclone-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseclone-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basecompareascending" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basecompareascending-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basecompareascending-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basecopy" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basecopy-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basecopy-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basecreate" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basecreate-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basecreate-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basedelay" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basedelay-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basedelay-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basedifference" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basedifference-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basedifference-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseeach" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseeach-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseeach-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseeachright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseeachright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseeachright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basefilter" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basefilter-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basefilter-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basefind" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basefind-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basefind-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basefindindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basefindindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basefindindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseflatten" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseflatten-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseflatten-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basefor" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basefor-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basefor-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseforright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseforright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseforright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basefunctions" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basefunctions-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basefunctions-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseget" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseget-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseget-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseindexof" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseindexof-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseindexof-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseisequal" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseisequal-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseisequal-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseismatch" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseismatch-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseismatch-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basematches" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basematches-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basematches-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basematchesproperty" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basematchesproperty-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basematchesproperty-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basepullat" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basepullat-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basepullat-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baserandom" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baserandom-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baserandom-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basereduce" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basereduce-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basereduce-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseslice" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseslice-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseslice-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basesortby" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basesortby-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basesortby-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basesortbyorder" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basesortbyorder-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basesortbyorder-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basetostring" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basetostring-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basetostring-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-baseuniq" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-baseuniq-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-baseuniq-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-basevalues" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-basevalues-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-basevalues-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-before" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-before-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-before-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-binaryindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-binaryindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-binaryindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-binaryindexby" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-binaryindexby-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-binaryindexby-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-bind" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-bind-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-bind-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-bindall" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-bindall-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-bindall-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-bindcallback" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-bindcallback-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-bindcallback-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-bindkey" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-bindkey-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-bindkey-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-cacheindexof" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-cacheindexof-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-cacheindexof-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-callback" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-callback-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-callback-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-camelcase" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-camelcase-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-camelcase-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-capitalize" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-capitalize-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-capitalize-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-ceil" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-ceil-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-ceil-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-charsleftindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-charsleftindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-charsleftindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-charsrightindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-charsrightindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-charsrightindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-chunk" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-chunk-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-chunk-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-clone" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-clone-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-clone-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-clonedeep" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-clonedeep-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-clonedeep-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-compact" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-compact-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-compact-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-constant" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-constant-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-constant-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-countby" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-countby-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-countby-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-create" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-create-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-create-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-createaggregator" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-createaggregator-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-createaggregator-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-createassigner" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-createassigner-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-createassigner-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-createcache" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-createcache-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-createcache-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-createcompounder" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-createcompounder-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-createcompounder-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-createpadding" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-createpadding-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-createpadding-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-createwrapper" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-createwrapper-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-createwrapper-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-curry" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-curry-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-curry-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-curryright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-curryright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-curryright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-debounce" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-debounce-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-debounce-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-deburr" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-deburr-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-deburr-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-defaults" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-defaults-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-defaults-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-defaultsdeep" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-defaultsdeep-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-defaultsdeep-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-defer" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-defer-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-defer-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-delay" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-delay-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-delay-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-difference" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-difference-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-difference-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-drop" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-drop-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-drop-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-dropright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-dropright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-dropright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-droprightwhile" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-droprightwhile-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-droprightwhile-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-dropwhile" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-dropwhile-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-dropwhile-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-endswith" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-endswith-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-endswith-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-escape" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-escape-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-escape-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-escaperegexp" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-escaperegexp-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-escaperegexp-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-every" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-every-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-every-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-fill" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-fill-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-fill-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-filter" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-filter-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-filter-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-find" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-find-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-find-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-findindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-findindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-findindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-findkey" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-findkey-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-findkey-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-findlast" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-findlast-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-findlast-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-findlastindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-findlastindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-findlastindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-findlastkey" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-findlastkey-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-findlastkey-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-findwhere" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-findwhere-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-findwhere-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-first" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-first-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-first-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-flatten" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-flatten-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-flatten-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-flattendeep" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-flattendeep-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-flattendeep-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-floor" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-floor-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-floor-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-flow" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-flow-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-flow-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-flowright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-flowright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-flowright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-foreach" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-foreach-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-foreach-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-foreachright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-foreachright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-foreachright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-forin" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-forin-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-forin-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-forinright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-forinright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-forinright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-forown" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-forown-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-forown-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-forownright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-forownright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-forownright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-functions" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-functions-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-functions-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-get" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-get-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-get-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-getnative" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-getnative-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-getnative-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-groupby" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-groupby-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-groupby-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-gt" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-gt-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-gt-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-gte" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-gte-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-gte-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-has" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-has-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-has-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-identity" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-identity-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-identity-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-includes" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-includes-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-includes-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-indexby" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-indexby-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-indexby-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-indexof" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-indexof-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-indexof-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-initial" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-initial-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-initial-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-inrange" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-inrange-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-inrange-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-intersection" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-intersection-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-intersection-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-invert" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-invert-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-invert-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-invoke" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-invoke-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-invoke-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-invokepath" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-invokepath-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-invokepath-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isarguments" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isarguments-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isarguments-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isarray" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isarray-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isarray-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isboolean" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isboolean-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isboolean-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isdate" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isdate-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isdate-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-iselement" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-iselement-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-iselement-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isempty" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isempty-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isempty-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isequal" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isequal-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isequal-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-iserror" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-iserror-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-iserror-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isfinite" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isfinite-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isfinite-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isfunction" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isfunction-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isfunction-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isiterateecall" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isiterateecall-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isiterateecall-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-ismatch" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-ismatch-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-ismatch-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isnan" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isnan-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isnan-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isnative" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isnative-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isnative-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isnull" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isnull-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isnull-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isnumber" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isnumber-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isnumber-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isobject" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isobject-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isobject-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isplainobject" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isplainobject-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isplainobject-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isregexp" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isregexp-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isregexp-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isstring" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isstring-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isstring-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-istypedarray" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-istypedarray-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-istypedarray-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-isundefined" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-isundefined-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-isundefined-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-kebabcase" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-kebabcase-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-kebabcase-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-keys" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-keys-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-keys-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-keysin" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-keysin-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-keysin-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-last" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-last-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-last-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-lastindexof" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-lastindexof-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-lastindexof-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-lt" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-lt-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-lt-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-lte" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-lte-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-lte-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-map" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-map-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-map-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-mapkeys" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-mapkeys-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-mapkeys-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-mapvalues" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-mapvalues-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-mapvalues-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-matches" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-matches-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-matches-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-matchesproperty" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-matchesproperty-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-matchesproperty-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-max" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-max-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-max-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-memoize" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-memoize-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-memoize-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-merge" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-merge-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-merge-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-method" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-method-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-method-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-methodof" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-methodof-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-methodof-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-min" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-min-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-min-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-mixin" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-mixin-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-mixin-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-modargs" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-modargs-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-modargs-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-negate" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-negate-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-negate-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-noop" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-noop-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-noop-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-now" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-now-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-now-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-omit" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-omit-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-omit-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-once" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-once-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-once-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pad" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pad-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pad-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-padleft" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-padleft-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-padleft-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-padright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-padright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-padright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pairs" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pairs-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pairs-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-parseint" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-parseint-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-parseint-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-partial" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-partial-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-partial-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-partialright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-partialright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-partialright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-partition" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-partition-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-partition-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pick" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pick-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pick-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pickbyarray" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pickbyarray-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pickbyarray-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pickbycallback" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pickbycallback-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pickbycallback-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pluck" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pluck-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pluck-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-property" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-property-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-property-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-propertyof" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-propertyof-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-propertyof-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pull" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pull-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pull-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-pullat" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-pullat-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-pullat-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-random" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-random-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-random-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-range" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-range-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-range-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-rearg" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-rearg-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-rearg-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-reduce" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-reduce-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-reduce-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-reduceright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-reduceright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-reduceright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-reescape" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-reescape-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-reescape-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-reevaluate" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-reevaluate-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-reevaluate-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-reinterpolate" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-reinterpolate-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-reinterpolate-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-reject" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-reject-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-reject-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-remove" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-remove-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-remove-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-repeat" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-repeat-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-repeat-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-replaceholders" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-replaceholders-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-replaceholders-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-rest" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-rest-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-rest-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-restparam" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-restparam-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-restparam-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-result" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-result-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-result-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-round" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-round-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-round-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sample" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sample-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sample-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-set" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-set-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-set-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-shuffle" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-shuffle-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-shuffle-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-size" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-size-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-size-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-slice" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-slice-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-slice-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-snakecase" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-snakecase-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-snakecase-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-some" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-some-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-some-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sortby" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sortby-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sortby-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sortbyall" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sortbyall-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sortbyall-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sortbyorder" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sortbyorder-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sortbyorder-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sortedindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sortedindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sortedindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sortedlastindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sortedlastindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sortedlastindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-spread" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-spread-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-spread-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-startcase" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-startcase-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-startcase-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-startswith" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-startswith-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-startswith-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-sum" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-sum-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-sum-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-support" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-support-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-support-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-take" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-take-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-take-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-takeright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-takeright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-takeright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-takerightwhile" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-takerightwhile-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-takerightwhile-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-takewhile" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-takewhile-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-takewhile-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-template" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-template-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-template-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-templatesettings" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-templatesettings-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-templatesettings-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-throttle" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-throttle-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-throttle-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-times" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-times-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-times-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-toarray" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-toarray-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-toarray-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-toiterable" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-toiterable-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-toiterable-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-topath" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-topath-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-topath-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-toplainobject" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-toplainobject-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-toplainobject-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-transform" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-transform-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-transform-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-trim" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-trim-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-trim-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-trimleft" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-trimleft-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-trimleft-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-trimmedleftindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-trimmedleftindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-trimmedleftindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-trimmedrightindex" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-trimmedrightindex-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-trimmedrightindex-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-trimright" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-trimright-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-trimright-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-trunc" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-trunc-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-trunc-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-unescape" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-unescape-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-unescape-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-union" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-union-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-union-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-uniq" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-uniq-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-uniq-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-uniqueid" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-uniqueid-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-uniqueid-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-unzip" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-unzip-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-unzip-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-unzipwith" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-unzipwith-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-unzipwith-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-values" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-values-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-values-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-valuesin" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-valuesin-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-valuesin-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-where" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-where-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-where-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-without" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-without-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-without-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-words" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-words-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-words-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-wrap" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-wrap-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-wrap-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-xor" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-xor-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-xor-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-zip" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-zip-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-zip-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-zipobject" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-zipobject-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-zipobject-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nodejs-lodash-zipwith" release="1.u1.fos23" version="3.10.1">
					<filename>nodejs-lodash-zipwith-3.10.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/nodejs-lodash-zipwith-3.10.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2135</id>
		<title>An update for lxc is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47952" id="CVE-2022-47952" title="CVE-2022-47952" type="cve"></reference>
		</references>
		<description>CVE-2022-47952:lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because &#34;Failed to open&#34; often indicates that a file does not exist, whereas &#34;does not refer to a network namespace path&#34; often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that &#34;we will report back to the user that the open() failed but the user has no way of knowing why it failed&#34;; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="lxc" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-4.0.3-2022102419.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/lxc-4.0.3-2022102419.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lxc-libs" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-libs-4.0.3-2022102419.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/lxc-libs-4.0.3-2022102419.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lxc-devel" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-devel-4.0.3-2022102419.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/lxc-devel-4.0.3-2022102419.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="lxc-help" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-help-4.0.3-2022102419.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/lxc-help-4.0.3-2022102419.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lxc" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-4.0.3-2022102419.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/lxc-4.0.3-2022102419.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lxc-libs" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-libs-4.0.3-2022102419.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/lxc-libs-4.0.3-2022102419.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lxc-devel" release="2022102419.u6.fos23" version="4.0.3">
					<filename>lxc-devel-4.0.3-2022102419.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/lxc-devel-4.0.3-2022102419.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2136</id>
		<title>An update for netty3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-16869" id="CVE-2019-16869" title="CVE-2019-16869" type="cve"></reference>
		</references>
		<description>CVE-2019-16869:Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a &#34;Transfer-Encoding : chunked&#34; line), which leads to HTTP request smuggling.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="0" name="netty3" release="6.u1.fos23" version="3.10.6">
					<filename>netty3-3.10.6-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/netty3-3.10.6-6.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2137</id>
		<title>An update for ntp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26551" id="CVE-2023-26551" title="CVE-2023-26551" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26552" id="CVE-2023-26552" title="CVE-2023-26552" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26553" id="CVE-2023-26553" title="CVE-2023-26553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26554" id="CVE-2023-26554" title="CVE-2023-26554" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26555" id="CVE-2023-26555" title="CVE-2023-26555" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26551" id="CVE-2023-26551" title="CVE-2023-26551" type="cve"></reference>
		</references>
		<description>CVE-2023-26551:mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write in the cp&lt;cpdec while loop. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.&#xA;CVE-2023-26552:mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when adding a decimal point. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.&#xA;CVE-2023-26553:mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when copying the trailing number. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.&#xA;CVE-2023-26554:mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when adding a &#39;\0&#39; character. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.&#xA;CVE-2023-26555:praecis_parse in ntpd/refclock_palisade.c in NTP 4.2.8p15 has an out-of-bounds write. Any attack method would be complex, e.g., with a manipulated GPS receiver.&#xA;CVE-2023-26551:mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write in the cp&lt;cpdec while loop. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="ntp" release="10.u2.fos23" version="4.2.8p15">
					<filename>ntp-4.2.8p15-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ntp-4.2.8p15-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ntp-perl" release="10.u2.fos23" version="4.2.8p15">
					<filename>ntp-perl-4.2.8p15-10.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ntp-perl-4.2.8p15-10.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ntp-help" release="10.u2.fos23" version="4.2.8p15">
					<filename>ntp-help-4.2.8p15-10.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ntp-help-4.2.8p15-10.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ntp" release="10.u2.fos23" version="4.2.8p15">
					<filename>ntp-4.2.8p15-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ntp-4.2.8p15-10.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2138</id>
		<title>An update for openldap is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2953" id="CVE-2023-2953" title="CVE-2023-2953" type="cve"></reference>
		</references>
		<description>CVE-2023-2953:A vulnerability was found in openldap. This security flaw causes a null pointer dereference in ber_memalloc_x() function.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="openldap" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-2.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openldap-2.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openldap-devel" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-devel-2.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openldap-devel-2.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openldap-servers" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-servers-2.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openldap-servers-2.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openldap-clients" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-clients-2.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openldap-clients-2.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openldap-help" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-help-2.6.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openldap-help-2.6.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openldap" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-2.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openldap-2.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openldap-devel" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-devel-2.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openldap-devel-2.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openldap-servers" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-servers-2.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openldap-servers-2.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openldap-clients" release="6.u2.fos23" version="2.6.0">
					<filename>openldap-clients-2.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openldap-clients-2.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2139</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
		</references>
		<description>CVE-2023-2650:Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow. Impact summary: Applications that use OBJ_obj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service. An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers - most of which have no size limit. OBJ_obj2txt() may be used to translate an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL type ASN1_OBJECT) to its canonical numeric text form, which are the sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by periods. When one of the sub-identifiers in the OBJECT IDENTIFIER is very large (these are sizes that are seen as absurdly large, taking up tens or hundreds of KiBs), the translation to a decimal number in text may take a very long time. The time complexity is O(n^2) with &#39;n&#39; being the size of the sub-identifiers in bytes (*). With OpenSSL 3.0, support to fetch cryptographic algorithms using names / identifiers in string form was introduced. This includes using OBJECT IDENTIFIERs in canonical numeric text form as identifiers for fetching algorithms. Such OBJECT IDENTIFIERs may be received through the ASN.1 structure AlgorithmIdentifier, which is commonly used in multiple protocols to specify what cryptographic algorithm should be used to sign or verify, encrypt or decrypt, or digest passed data. Applications that call OBJ_obj2txt() directly with untrusted data are affected, with any version of OpenSSL. If the use is for the mere purpose of display, the severity is considered low. In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS. It also impacts anything that processes X.509 certificates, including simple things like verifying its signature. The impact on TLS is relatively low, because all versions of OpenSSL have a 100KiB limit on the peer&#39;s certificate chain. Additionally, this only impacts clients, or servers that have explicitly enabled client authentication. In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects, such as X.509 certificates. This is assumed to not happen in such a way that it would cause a Denial of Service, so these versions are considered not affected by this issue in such a way that it would be cause for concern, and the severity is therefore considered low.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="openssl" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openssl-1.1.1m-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openssl-libs-1.1.1m-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openssl-perl-1.1.1m-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openssl-devel-1.1.1m-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-22.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/openssl-help-1.1.1m-22.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openssl-1.1.1m-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openssl-libs-1.1.1m-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openssl-perl-1.1.1m-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="22.u7.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/openssl-devel-1.1.1m-22.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2140</id>
		<title>An update for python-flask is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30861" id="CVE-2023-30861" title="CVE-2023-30861" type="cve"></reference>
		</references>
		<description>CVE-2023-30861:Flask is a lightweight WSGI web application framework. When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches `Set-Cookie` headers, it may send one client&#39;s `session` cookie to other clients. The severity depends on the application&#39;s use of the session and the proxy&#39;s behavior regarding cookies. The risk depends on all these conditions being met. 1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies. 2. The application sets `session.permanent = True` 3. The application does not access or modify the session at any point during a request. 4. `SESSION_REFRESH_EACH_REQUEST` enabled (the default). 5. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached. This happens because vulnerable versions of Flask only set the `Vary: Cookie` header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="1" name="python3-flask" release="4.u1.fos23" version="2.1.2">
					<filename>python3-flask-2.1.2-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-flask-2.1.2-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2141</id>
		<title>An update for python-reportlab is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33733" id="CVE-2023-33733" title="CVE-2023-33733" type="cve"></reference>
		</references>
		<description>CVE-2023-33733:Cross Site Scripting (XSS) in the New Policy form in Microworld Technologies eScan management console 14.0.1400.2281 allows a remote attacker to inject arbitrary code via the vulnerable parameters type, txtPolicyType, and Deletefileval.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="python3-reportlab" release="1.u1.fos23" version="3.6.10">
					<filename>python3-reportlab-3.6.10-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-reportlab-3.6.10-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-reportlab-help" release="1.u1.fos23" version="3.6.10">
					<filename>python-reportlab-help-3.6.10-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python-reportlab-help-3.6.10-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-reportlab" release="1.u1.fos23" version="3.6.10">
					<filename>python3-reportlab-3.6.10-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/python3-reportlab-3.6.10-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2142</id>
		<title>An update for python-requests is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32681" id="CVE-2023-32681" title="CVE-2023-32681" type="cve"></reference>
		</references>
		<description>CVE-2023-32681:Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use `rebuild_proxies` to reattach the `Proxy-Authorization` header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="noarch" epoch="0" name="python3-requests" release="8.u2.fos23" version="2.26.0">
					<filename>python3-requests-2.26.0-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-requests-2.26.0-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-requests-help" release="8.u2.fos23" version="2.26.0">
					<filename>python-requests-help-2.26.0-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python-requests-help-2.26.0-8.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2143</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32762" id="CVE-2023-32762" title="CVE-2023-32762" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/,CVE-2023-32763" id=",CVE-2023-32763" title=",CVE-2023-32763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24607" id="CVE-2023-24607" title="CVE-2023-24607" type="cve"></reference>
		</references>
		<description>CVE-2023-32762:An issue was discovered in Qt before 5.15.14, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. Qt Network incorrectly parses the strict-transport-security (HSTS) header, allowing unencrypted connections to be established, even when explicitly prohibited by the server. This happens if the case used for this header does not exactly match.&#xA;,CVE-2023-32763:An issue was discovered in Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. When a SVG file with an image inside it is rendered, a QTextLayout buffer overflow can be triggered.&#xA;CVE-2023-24607:Qt before 6.4.3 allows a denial of service via a crafted string when the SQL ODBC driver plugin is used and the size of SQLTCHAR is 4. The affected versions are 5.x before 5.15.13, 6.x before 6.2.8, and 6.3.x before 6.4.3.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-common-5.15.2-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-devel-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-private-devel-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-examples-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-static-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-mysql-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-odbc-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-postgresql-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/qt5-qtbase-gui-5.15.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-devel-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-private-devel-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-examples-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-static-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-mysql-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-odbc-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-postgresql-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="6.u2.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/qt5-qtbase-gui-5.15.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2144</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28856" id="CVE-2023-28856" title="CVE-2023-28856" type="cve"></reference>
		</references>
		<description>CVE-2023-28856:Redis is an open source, in-memory database that persists on disk. Authenticated users can use the `HINCRBYFLOAT` command to create an invalid hash field that will crash Redis on access in affected versions. This issue has been addressed in in versions 7.0.11, 6.2.12, and 6.0.19. Users are advised to upgrade. There are no known workarounds for this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="redis5" release="5.u2.fos23" version="5.0.7">
					<filename>redis5-5.0.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/redis5-5.0.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="5.u2.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/redis5-devel-5.0.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="5.u2.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/redis5-doc-5.0.7-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="5.u2.fos23" version="5.0.7">
					<filename>redis5-5.0.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/redis5-5.0.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="5.u2.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/redis5-devel-5.0.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2145</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28856" id="CVE-2023-28856" title="CVE-2023-28856" type="cve"></reference>
		</references>
		<description>CVE-2023-28856:Redis is an open source, in-memory database that persists on disk. Authenticated users can use the `HINCRBYFLOAT` command to create an invalid hash field that will crash Redis on access in affected versions. This issue has been addressed in in versions 7.0.11, 6.2.12, and 6.0.19. Users are advised to upgrade. There are no known workarounds for this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="redis6" release="2.u2.fos23" version="6.2.7">
					<filename>redis6-6.2.7-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/redis6-6.2.7-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="2.u2.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/redis6-devel-6.2.7-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="2.u2.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/redis6-doc-6.2.7-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="2.u2.fos23" version="6.2.7">
					<filename>redis6-6.2.7-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/redis6-6.2.7-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="2.u2.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/redis6-devel-6.2.7-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2146</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14628" id="CVE-2018-14628" title="CVE-2018-14628" type="cve"></reference>
		</references>
		<description>CVE-2018-14628:An information leak vulnerability was discovered in Samba&#39;s LDAP server. Due to missing access control checks, an authenticated but unprivileged attacker could discover the names and preserved attributes of deleted objects in the LDAP store.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="samba" release="3.u2.fos23" version="4.17.5">
					<filename>samba-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-libs" release="3.u2.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-libs-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client" release="3.u2.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-client-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common" release="3.u2.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-common-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common-tools" release="3.u2.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-common-tools-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc" release="3.u2.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-dc-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-provision" release="3.u2.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-dc-provision-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-bind-dlz" release="3.u2.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-dc-bind-dlz-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-devel" release="3.u2.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-devel-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-vfs-glusterfs" release="3.u2.fos23" version="4.17.5">
					<filename>samba-vfs-glusterfs-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-vfs-glusterfs-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-krb5-printing" release="3.u2.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-krb5-printing-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient" release="3.u2.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libsmbclient-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient-devel" release="3.u2.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libsmbclient-devel-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient" release="3.u2.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwbclient-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient-devel" release="3.u2.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libwbclient-devel-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba" release="3.u2.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-samba-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-test" release="3.u2.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-samba-test-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-dc" release="3.u2.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-samba-dc-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="samba-pidl" release="3.u2.fos23" version="4.17.5">
					<filename>samba-pidl-4.17.5-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-pidl-4.17.5-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-test" release="3.u2.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-test-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-usershares" release="3.u2.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-usershares-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-winbind-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-clients" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-winbind-clients-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-krb5-locator" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-winbind-krb5-locator-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-modules" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-winbind-modules-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ctdb" release="3.u2.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/ctdb-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-help" release="3.u2.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/samba-help-4.17.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba" release="3.u2.fos23" version="4.17.5">
					<filename>samba-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-libs" release="3.u2.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-libs-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client" release="3.u2.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-client-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common" release="3.u2.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-common-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common-tools" release="3.u2.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-common-tools-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc" release="3.u2.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-dc-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-provision" release="3.u2.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-dc-provision-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-bind-dlz" release="3.u2.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-dc-bind-dlz-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-devel" release="3.u2.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-devel-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-krb5-printing" release="3.u2.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-krb5-printing-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient" release="3.u2.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libsmbclient-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient-devel" release="3.u2.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libsmbclient-devel-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient" release="3.u2.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libwbclient-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient-devel" release="3.u2.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libwbclient-devel-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba" release="3.u2.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/python3-samba-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-test" release="3.u2.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/python3-samba-test-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-dc" release="3.u2.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/python3-samba-dc-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-test" release="3.u2.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-test-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-usershares" release="3.u2.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-usershares-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-winbind-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-clients" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-winbind-clients-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-krb5-locator" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-winbind-krb5-locator-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-modules" release="3.u2.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-winbind-modules-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctdb" release="3.u2.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/ctdb-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-help" release="3.u2.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/samba-help-4.17.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2147</id>
		<title>An update for sysstat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33204" id="CVE-2023-33204" title="CVE-2023-33204" type="cve"></reference>
		</references>
		<description>CVE-2023-33204:sysstat through 12.7.2 allows a multiplication integer overflow in check_overflow in common.c. NOTE: this issue exists because of an incomplete fix for CVE-2022-39377.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="sysstat" release="8.u2.fos23" version="12.5.4">
					<filename>sysstat-12.5.4-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/sysstat-12.5.4-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sysstat" release="8.u2.fos23" version="12.5.4">
					<filename>sysstat-12.5.4-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/sysstat-12.5.4-8.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2148</id>
		<title>An update for util-linux is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0563" id="CVE-2022-0563" title="CVE-2022-0563" type="cve"></reference>
		</references>
		<description>CVE-2022-0563:A flaw was found in the util-linux chfn and chsh utilities when compiled with Readline support. The Readline library uses an &#34;INPUTRC&#34; environment variable to get a path to the library config file. When the library cannot parse the specified file, it prints an error message containing data from the file. This flaw allows an unprivileged user to read root-owned files, potentially leading to privilege escalation. This flaw affects util-linux versions prior to 2.37.4.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="util-linux" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/util-linux-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libfdisk" release="19.u6.fos23" version="2.37.2">
					<filename>libfdisk-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libfdisk-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmartcols" release="19.u6.fos23" version="2.37.2">
					<filename>libsmartcols-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libsmartcols-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libmount" release="19.u6.fos23" version="2.37.2">
					<filename>libmount-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libmount-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libblkid" release="19.u6.fos23" version="2.37.2">
					<filename>libblkid-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libblkid-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uuidd" release="19.u6.fos23" version="2.37.2">
					<filename>uuidd-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/uuidd-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libuuid" release="19.u6.fos23" version="2.37.2">
					<filename>libuuid-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/libuuid-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux-user" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-user-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/util-linux-user-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libmount" release="19.u6.fos23" version="2.37.2">
					<filename>python3-libmount-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/python3-libmount-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux-devel" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-devel-2.37.2-19.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/util-linux-devel-2.37.2-19.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="util-linux-help" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-help-2.37.2-19.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/util-linux-help-2.37.2-19.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/util-linux-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libfdisk" release="19.u6.fos23" version="2.37.2">
					<filename>libfdisk-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libfdisk-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmartcols" release="19.u6.fos23" version="2.37.2">
					<filename>libsmartcols-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libsmartcols-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libmount" release="19.u6.fos23" version="2.37.2">
					<filename>libmount-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libmount-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libblkid" release="19.u6.fos23" version="2.37.2">
					<filename>libblkid-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libblkid-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uuidd" release="19.u6.fos23" version="2.37.2">
					<filename>uuidd-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/uuidd-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libuuid" release="19.u6.fos23" version="2.37.2">
					<filename>libuuid-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/libuuid-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux-user" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-user-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/util-linux-user-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libmount" release="19.u6.fos23" version="2.37.2">
					<filename>python3-libmount-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/python3-libmount-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux-devel" release="19.u6.fos23" version="2.37.2">
					<filename>util-linux-devel-2.37.2-19.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/util-linux-devel-2.37.2-19.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2149</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2609" id="CVE-2023-2609" title="CVE-2023-2609" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2610" id="CVE-2023-2610" title="CVE-2023-2610" type="cve"></reference>
		</references>
		<description>CVE-2023-2609:NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1531.&#xA;CVE-2023-2610:Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1532.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="15.u8.fos23" version="9.0">
					<filename>vim-common-9.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/vim-common-9.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="15.u8.fos23" version="9.0">
					<filename>vim-minimal-9.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/vim-minimal-9.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="15.u8.fos23" version="9.0">
					<filename>vim-enhanced-9.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/vim-enhanced-9.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="15.u8.fos23" version="9.0">
					<filename>vim-filesystem-9.0-15.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/vim-filesystem-9.0-15.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="15.u8.fos23" version="9.0">
					<filename>vim-X11-9.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/vim-X11-9.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="15.u8.fos23" version="9.0">
					<filename>vim-common-9.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/vim-common-9.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="15.u8.fos23" version="9.0">
					<filename>vim-minimal-9.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/vim-minimal-9.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="15.u8.fos23" version="9.0">
					<filename>vim-enhanced-9.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/vim-enhanced-9.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="15.u8.fos23" version="9.0">
					<filename>vim-X11-9.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/vim-X11-9.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2150</id>
		<title>An update for webkit2gtk3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28204" id="CVE-2023-28204" title="CVE-2023-28204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32373" id="CVE-2023-32373" title="CVE-2023-32373" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32409" id="CVE-2023-32409" title="CVE-2023-32409" type="cve"></reference>
		</references>
		<description>CVE-2023-28204:A flaw was found in the webkitgtk package. An out of bounds read may be possible when processing malicious web content, which can lead to information disclosure.&#xA;CVE-2023-32373:A use after free vulnerability was found in the webkitgtk package. Processing maliciously crafted web content may lead to arbitrary code execution.&#xA;CVE-2023-32409:A flaw was found in the WebGPU, part of the Webkit project. This flaw allows a remote attacker to break out of the Web Content sandbox.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="webkit2gtk3" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-devel-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-devel-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-jsc" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-jsc-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-jsc-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-devel-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-devel-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-jsc" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-jsc-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-jsc-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2151</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0668" id="CVE-2023-0668" title="CVE-2023-0668" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2855" id="CVE-2023-2855" title="CVE-2023-2855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2856" id="CVE-2023-2856" title="CVE-2023-2856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2857" id="CVE-2023-2857" title="CVE-2023-2857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2858" id="CVE-2023-2858" title="CVE-2023-2858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2879" id="CVE-2023-2879" title="CVE-2023-2879" type="cve"></reference>
		</references>
		<description>CVE-2023-0668:Due to failure in validating the length provided by an attacker-crafted IEEE-C37.118 packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark.&#xA;CVE-2023-2855:Candump log parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file&#xA;CVE-2023-2856:VMS TCPIPtrace file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file&#xA;CVE-2023-2857:BLF file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file&#xA;CVE-2023-2858:NetScaler file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file&#xA;CVE-2023-2879:GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="4.u3.fos23" version="3.6.11">
					<filename>wireshark-3.6.11-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/wireshark-3.6.11-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="4.u3.fos23" version="3.6.11">
					<filename>wireshark-devel-3.6.11-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/wireshark-devel-3.6.11-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="4.u3.fos23" version="3.6.11">
					<filename>wireshark-help-3.6.11-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/wireshark-help-3.6.11-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="4.u3.fos23" version="3.6.11">
					<filename>wireshark-3.6.11-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/wireshark-3.6.11-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="4.u3.fos23" version="3.6.11">
					<filename>wireshark-devel-3.6.11-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/wireshark-devel-3.6.11-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="4.u3.fos23" version="3.6.11">
					<filename>wireshark-help-3.6.11-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/wireshark-help-3.6.11-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2152</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3550" id="CVE-2022-3550" title="CVE-2022-3550" type="cve"></reference>
		</references>
		<description>CVE-2022-3550:A vulnerability classified as critical was found in X.org Server. Affected by this vulnerability is the function _GetCountedString of the file xkb/xkb.c. The manipulation leads to buffer overflow.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-common-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-Xnest-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-Xdmx-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-Xvfb-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-Xephyr-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-devel-1.20.11-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-help-1.20.11-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/xorg-x11-server-source-1.20.11-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-common-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-Xnest-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-Xdmx-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-Xvfb-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-Xephyr-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="20.u7.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/xorg-x11-server-devel-1.20.11-20.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2153</id>
		<title>An update for yasm is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-06-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33454" id="CVE-2021-33454" title="CVE-2021-33454" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33455" id="CVE-2021-33455" title="CVE-2021-33455" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33456" id="CVE-2021-33456" title="CVE-2021-33456" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33457" id="CVE-2021-33457" title="CVE-2021-33457" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33458" id="CVE-2021-33458" title="CVE-2021-33458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33459" id="CVE-2021-33459" title="CVE-2021-33459" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33460" id="CVE-2021-33460" title="CVE-2021-33460" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33461" id="CVE-2021-33461" title="CVE-2021-33461" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33462" id="CVE-2021-33462" title="CVE-2021-33462" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33463" id="CVE-2021-33463" title="CVE-2021-33463" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33464" id="CVE-2021-33464" title="CVE-2021-33464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33465" id="CVE-2021-33465" title="CVE-2021-33465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33466" id="CVE-2021-33466" title="CVE-2021-33466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33467" id="CVE-2021-33467" title="CVE-2021-33467" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33468" id="CVE-2021-33468" title="CVE-2021-33468" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30402" id="CVE-2023-30402" title="CVE-2023-30402" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31972" id="CVE-2023-31972" title="CVE-2023-31972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31973" id="CVE-2023-31973" title="CVE-2023-31973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31974" id="CVE-2023-31974" title="CVE-2023-31974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31975" id="CVE-2023-31975" title="CVE-2023-31975" type="cve"></reference>
		</references>
		<description>CVE-2021-33454:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in yasm_expr_get_intnum() in libyasm/expr.c.&#xA;CVE-2021-33455:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in do_directive() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33456:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in hash() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33457:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in expand_mmac_params() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33458:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in find_cc() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33459:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in nasm_parser_directive() in modules/parsers/nasm/nasm-parse.c.&#xA;CVE-2021-33460:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in if_condition() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33461:An issue was discovered in yasm version 1.3.0. There is a use-after-free in yasm_intnum_destroy() in libyasm/intnum.c.&#xA;CVE-2021-33462:An issue was discovered in yasm version 1.3.0. There is a use-after-free in expr_traverse_nodes_post() in libyasm/expr.c.&#xA;CVE-2021-33463:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in yasm_expr__copy_except() in libyasm/expr.c.&#xA;CVE-2021-33464:An issue was discovered in yasm version 1.3.0. There is a heap-buffer-overflow in inc_fopen() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33465:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in expand_mmacro() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33466:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in expand_smacro() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33467:An issue was discovered in yasm version 1.3.0. There is a use-after-free in pp_getline() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2021-33468:An issue was discovered in yasm version 1.3.0. There is a use-after-free in error() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2023-30402:yasm v1.3.0 was discovered to contain a heap overflow via the function handle_dot_label at /nasm/nasm-token.re&#xA;CVE-2023-31972:yasm v1.3.0 was discovered to contain a use after free via the function pp_getline at /nasm/nasm-pp.c.&#xA;CVE-2023-31973:yasm v1.3.0 was discovered to contain a use after free via the function expand_mmac_params at /nasm/nasm-pp.c.&#xA;CVE-2023-31974:yasm v1.3.0 was discovered to contain a use after free via the function error at /nasm/nasm-pp.c.&#xA;CVE-2023-31975:yasm v1.3.0 was discovered to contain a memory leak via the function yasm_intnum_copy at /libyasm/intnum.c.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="yasm" release="10.u1.fos23" version="1.3.0">
					<filename>yasm-1.3.0-10.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/yasm-1.3.0-10.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yasm" release="10.u1.fos23" version="1.3.0">
					<filename>yasm-1.3.0-10.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/yasm-1.3.0-10.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2154</id>
		<title>An update for perl-DBD-SQLite is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35737" id="CVE-2022-35737" title="CVE-2022-35737" type="cve"></reference>
		</references>
		<description>CVE-2022-35737:SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a string argument to a C API.</description>
		<pkglist>
			<collection>
				<name>23.0.2.1</name>
				<package arch="x86_64" epoch="0" name="perl-DBD-SQLite" release="2.u1.fos23" version="1.70">
					<filename>perl-DBD-SQLite-1.70-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/perl-DBD-SQLite-1.70-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-DBD-SQLite-help" release="2.u1.fos23" version="1.70">
					<filename>perl-DBD-SQLite-help-1.70-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/perl-DBD-SQLite-help-1.70-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-DBD-SQLite" release="2.u1.fos23" version="1.70">
					<filename>perl-DBD-SQLite-1.70-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.1/perl-DBD-SQLite-1.70-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-DBD-SQLite-help" release="2.u1.fos23" version="1.70">
					<filename>perl-DBD-SQLite-help-1.70-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.1/perl-DBD-SQLite-help-1.70-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2155</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23840" id="CVE-2021-23840" title="CVE-2021-23840" type="cve"></reference>
		</references>
		<description>CVE-2021-23840:Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).</description>
		<pkglist>
			<collection>
				<name>23.0.2.1</name>
				<package arch="x86_64" epoch="0" name="shim" release="9.u6.fos23" version="15.6">
					<filename>shim-15.6-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/shim-15.6-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="9.u6.fos23" version="15.6">
					<filename>shim-15.6-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.1/shim-15.6-9.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2156</id>
		<title>An update for syslinux is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9840" id="CVE-2016-9840" title="CVE-2016-9840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9841" id="CVE-2016-9841" title="CVE-2016-9841" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9842" id="CVE-2016-9842" title="CVE-2016-9842" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9843" id="CVE-2016-9843" title="CVE-2016-9843" type="cve"></reference>
		</references>
		<description>CVE-2016-9840:inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.&#xA;CVE-2016-9841:inffast.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.&#xA;CVE-2016-9842:The inflateMark function in inflate.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving left shifts of negative integers.&#xA;CVE-2016-9843:The crc32_big function in crc32.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving big-endian CRC calculation.</description>
		<pkglist>
			<collection>
				<name>23.0.2.1</name>
				<package arch="x86_64" epoch="0" name="syslinux" release="13.u1.fos23" version="6.04">
					<filename>syslinux-6.04-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-6.04-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-perl" release="13.u1.fos23" version="6.04">
					<filename>syslinux-perl-6.04-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-perl-6.04-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-devel" release="13.u1.fos23" version="6.04">
					<filename>syslinux-devel-6.04-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-devel-6.04-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-extlinux" release="13.u1.fos23" version="6.04">
					<filename>syslinux-extlinux-6.04-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-extlinux-6.04-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-tftpboot" release="13.u1.fos23" version="6.04">
					<filename>syslinux-tftpboot-6.04-13.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-tftpboot-6.04-13.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-extlinux-nonlinux" release="13.u1.fos23" version="6.04">
					<filename>syslinux-extlinux-nonlinux-6.04-13.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-extlinux-nonlinux-6.04-13.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-nonlinux" release="13.u1.fos23" version="6.04">
					<filename>syslinux-nonlinux-6.04-13.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-nonlinux-6.04-13.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-efi64" release="13.u1.fos23" version="6.04">
					<filename>syslinux-efi64-6.04-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.1/syslinux-efi64-6.04-13.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2157</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2911" id="CVE-2023-2911" title="CVE-2023-2911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2828" id="CVE-2023-2828" title="CVE-2023-2828" type="cve"></reference>
		</references>
		<description>CVE-2023-2911:If the `recursive-clients` quota is reached on a BIND 9 resolver configured with both `stale-answer-enable yes;` and `stale-answer-client-timeout 0;`, a sequence of serve-stale-related lookups could cause `named` to loop and terminate unexpectedly due to a stack overflow. This issue affects BIND 9 versions 9.16.33 through 9.16.41, 9.18.7 through 9.18.15, 9.16.33-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1.&#xA;CVE-2023-2828:Every named instance configured to run as a recursive resolver maintains a cache database holding the responses to the queries it has recently sent to authoritative servers. The size limit for that cache database can be configured using the max-cache-size statement in the configuration file; it defaults to 90% of the total amount of memory available on the host. When the size of the cache reaches 7/8 of the configured limit, a cache-cleaning algorithm starts to remove expired and/or least-recently used RRsets from the cache, to keep memory use below the configured limit.It has been discovered that the effectiveness of the cache-cleaning algorithm used in named can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured max-cache-size limit to be significantly exceeded.This issue affects BIND 9 versions 9.11.0 through 9.16.41, 9.18.0 through 9.18.15, 9.19.0 through 9.19.13, 9.11.3-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="32" name="bind" release="18.u5.fos23" version="9.16.23">
					<filename>bind-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-pkcs11-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-pkcs11-utils-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-pkcs11-libs-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-pkcs11-devel-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="18.u5.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-libs-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="18.u5.fos23" version="9.16.23">
					<filename>bind-license-9.16.23-18.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-license-9.16.23-18.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="18.u5.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-utils-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="18.u5.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-dnssec-utils-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="18.u5.fos23" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-18.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-dnssec-doc-9.16.23-18.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="18.u5.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-devel-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="18.u5.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-18.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bind-chroot-9.16.23-18.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="18.u5.fos23" version="9.16.23">
					<filename>python3-bind-9.16.23-18.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/python3-bind-9.16.23-18.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="18.u5.fos23" version="9.16.23">
					<filename>bind-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-pkcs11-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-pkcs11-utils-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-pkcs11-libs-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="18.u5.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-pkcs11-devel-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="18.u5.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-libs-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="18.u5.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-utils-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="18.u5.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-dnssec-utils-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="18.u5.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-devel-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="18.u5.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-18.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/bind-chroot-9.16.23-18.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2158</id>
		<title>An update for bouncycastle is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33201" id="CVE-2023-33201" title="CVE-2023-33201" type="cve"></reference>
		</references>
		<description>CVE-2023-33201:Bouncy Castle For Java before 1.74 is affected by an LDAP injection vulnerability. The vulnerability only affects applications that use an LDAP CertStore from Bouncy Castle to validate X.509 certificates. During the certificate validation process, Bouncy Castle inserts the certificate&#39;s Subject Name into an LDAP search filter without any escaping, which leads to an LDAP injection vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="noarch" epoch="0" name="bouncycastle" release="2.u1.fos23" version="1.67">
					<filename>bouncycastle-1.67-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/bouncycastle-1.67-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2159</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34241" id="CVE-2023-34241" title="CVE-2023-34241" type="cve"></reference>
		</references>
		<description>CVE-2023-34241:OpenPrinting CUPS is a standards-based, open source printing system for Linux and other Unix-like operating systems. Starting in version 2.0.0 and prior to version 2.4.6, CUPS logs data of free memory to the logging service AFTER the connection has been closed, when it should have logged the data right before. This is a use-after-free bug that impacts the entire cupsd process. The exact cause of this issue is the function `httpClose(con-&gt;http)` being called in `scheduler/client.c`. The problem is that httpClose always, provided its argument is not null, frees the pointer at the end of the call, only for cupsdLogClient to pass the pointer to httpGetHostname. This issue happens in function `cupsdAcceptClient` if LogLevel is warn or higher and in two scenarios: there is a double-lookup for the IP Address (HostNameLookups Double is set in `cupsd.conf`) which fails to resolve, or if CUPS is compiled with TCP wrappers and the connection is refused by rules from `/etc/hosts.allow` and `/etc/hosts.deny`. Version 2.4.6 has a patch for this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="1" name="cups" release="8.u3.fos23" version="2.4.0">
					<filename>cups-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="8.u3.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-client-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="8.u3.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-devel-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="8.u3.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-libs-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="8.u3.fos23" version="2.4.0">
					<filename>cups-filesystem-2.4.0-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-filesystem-2.4.0-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="8.u3.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-lpd-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="8.u3.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-ipptool-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="8.u3.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-printerapp-2.4.0-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="8.u3.fos23" version="2.4.0">
					<filename>cups-help-2.4.0-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/cups-help-2.4.0-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="8.u3.fos23" version="2.4.0">
					<filename>cups-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="8.u3.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-client-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="8.u3.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-devel-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="8.u3.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-libs-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="8.u3.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-lpd-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="8.u3.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-ipptool-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="8.u3.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/cups-printerapp-2.4.0-8.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2160</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
		</references>
		<description>CVE-2022-4304:A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="12.u3.fos23" version="202011">
					<filename>edk2-devel-202011-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/edk2-devel-202011-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="12.u3.fos23" version="202011">
					<filename>python3-edk2-devel-202011-12.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/python3-edk2-devel-202011-12.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="12.u3.fos23" version="202011">
					<filename>edk2-help-202011-12.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/edk2-help-202011-12.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="12.u3.fos23" version="202011">
					<filename>edk2-ovmf-202011-12.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/edk2-ovmf-202011-12.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="12.u3.fos23" version="202011">
					<filename>edk2-devel-202011-12.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/edk2-devel-202011-12.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="12.u3.fos23" version="202011">
					<filename>edk2-aarch64-202011-12.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/edk2-aarch64-202011-12.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2161</id>
		<title>An update for gnuplot is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-25969" id="CVE-2020-25969" title="CVE-2020-25969" type="cve"></reference>
		</references>
		<description>CVE-2020-25969:gnuplot v5.5 was discovered to contain a buffer overflow via the function plotrequest().</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="gnuplot" release="14.u1.fos23" version="5.0.6">
					<filename>gnuplot-5.0.6-14.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/gnuplot-5.0.6-14.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnuplot-help" release="14.u1.fos23" version="5.0.6">
					<filename>gnuplot-help-5.0.6-14.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/gnuplot-help-5.0.6-14.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnuplot" release="14.u1.fos23" version="5.0.6">
					<filename>gnuplot-5.0.6-14.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/gnuplot-5.0.6-14.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2162</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29402" id="CVE-2023-29402" title="CVE-2023-29402" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29403" id="CVE-2023-29403" title="CVE-2023-29403" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29404" id="CVE-2023-29404" title="CVE-2023-29404" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29405" id="CVE-2023-29405" title="CVE-2023-29405" type="cve"></reference>
		</references>
		<description>CVE-2023-29402:The go command may generate unexpected code at build time when using cgo. This may result in unexpected behavior when running a go program which uses cgo. This may occur when running an untrusted module which contains directories with newline characters in their names. Modules which are retrieved using the go command, i.e. via go get , are not affected (modules retrieved using GOPATH-mode, i.e. GO111MODULE=off, may be affected).&#xA;CVE-2023-29403:On Unix platforms, the Go runtime does not behave differently when a binary is run with the setuid/setgid bits. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors. If a setuid/setgid binary is executed with standard I/O file descriptors closed, opening any files can result in unexpected content being read or written with elevated privileges. Similarly, if a setuid/setgid program is terminated, either via panic or signal, it may leak the contents of its registers.&#xA;CVE-2023-29404:he go command may execute arbitrary code at build time when using cgo. This may occur when running &#34;go get&#34; on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a &#34;#cgo LDFLAGS&#34; directive. The arguments for a number of flags which are non-optional are incorrectly considered optional, allowing disallowed flags to be smuggled through the LDFLAGS sanitization. This affects usage of both the gc and gccgo compilers.&#xA;CVE-2023-29405:The go command may execute arbitrary code at build time when using cgo. This may occur when running go get on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a #cgo LDFLAGS directive. Flags containing embedded spaces are mishandled, allowing disallowed flags to be smuggled through the LDFLAGS sanitization by including them in the argument of another flag. This only affects usage of the gccgo compiler.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="golang" release="1.u2.fos23" version="1.20.5">
					<filename>golang-1.20.5-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/golang-1.20.5-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="1.u2.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/golang-help-1.20.5-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="1.u2.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/golang-devel-1.20.5-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="1.u2.fos23" version="1.20.5">
					<filename>golang-1.20.5-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/golang-1.20.5-1.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2163</id>
		<title>An update for guava is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2976" id="CVE-2023-2976" title="CVE-2023-2976" type="cve"></reference>
		</references>
		<description>CVE-2023-2976:Use of Java&#39;s default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="noarch" epoch="0" name="guava" release="6.u1.fos23" version="25.0">
					<filename>guava-25.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/guava-25.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="guava-help" release="6.u1.fos23" version="25.0">
					<filename>guava-help-25.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/guava-help-25.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="guava-testlib" release="6.u1.fos23" version="25.0">
					<filename>guava-testlib-25.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/guava-testlib-25.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2164</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3389" id="CVE-2023-3389" title="CVE-2023-3389" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3090" id="CVE-2023-3090" title="CVE-2023-3090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3327" id="CVE-2023-3327" title="CVE-2023-3327" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35823" id="CVE-2023-35823" title="CVE-2023-35823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35824" id="CVE-2023-35824" title="CVE-2023-35824" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3006" id="CVE-2023-3006" title="CVE-2023-3006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31084" id="CVE-2023-31084" title="CVE-2023-31084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35828" id="CVE-2023-35828" title="CVE-2023-35828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35788" id="CVE-2023-35788" title="CVE-2023-35788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3358" id="CVE-2023-3358" title="CVE-2023-3358" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33288" id="CVE-2023-33288" title="CVE-2023-33288" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2985" id="CVE-2023-2985" title="CVE-2023-2985" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3161" id="CVE-2023-3161" title="CVE-2023-3161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3212" id="CVE-2023-3212" title="CVE-2023-3212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3268" id="CVE-2023-3268" title="CVE-2023-3268" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35829" id="CVE-2023-35829" title="CVE-2023-35829" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3141" id="CVE-2023-3141" title="CVE-2023-3141" type="cve"></reference>
		</references>
		<description>CVE-2023-3389:A use-after-free vulnerability in the Linux Kernel io_uring subsystem can be exploited to achieve local privilege escalation. Racing a io_uring cancel poll request with a linked timeout can cause a UAF in a hrtimer.&#xA;CVE-2023-3090:A heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation.The out-of-bounds write is caused by missing skb-&gt;cb initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled.&#xA;CVE-2023-3327:An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in drivers/media/pci/saa7134/saa7134-core.c.&#xA;CVE-2023-35823:An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in drivers/media/pci/saa7134/saa7134-core.c.&#xA;CVE-2023-35824:An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in dm1105_remove in drivers/media/pci/dm1105/dm1105.c.&#xA;CVE-2023-3006:A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim s hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.&#xA;CVE-2023-31084:An issue was discovered in drivers/media/dvb-core/dvb_frontend.c in the Linux kernel 6.2. There is a blocking operation when a task is in !TASK_RUNNING. In dvb_frontend_get_event, wait_event_interruptible is called; the condition is dvb_frontend_test_event(fepriv,events). In dvb_frontend_test_event, down(&amp;fepriv-&gt;sem) is called. However, wait_event_interruptible would put the process to sleep, and down(&amp;fepriv-&gt;sem) may block the process.&#xA;CVE-2023-35828:An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c.&#xA;CVE-2023-35788:An issue was discovered in fl_set_geneve_opt in net/sched/cls_flower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets. This may result in denial of service or privilege escalation.&#xA;CVE-2023-3358:A null pointer dereference was found in the Linux kernel&#39;s Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system.&#xA;CVE-2022-48502:An issue was discovered in the Linux kernel before 6.2. The ntfs3 subsystem does not properly check for correctness during disk reads, leading to an out-of-bounds read in ntfs_set_ea in fs/ntfs3/xattr.c.&#xA;CVE-2023-33288:An issue was discovered in the Linux kernel before 6.2.9. A use-after-free was found in bq24190_remove in drivers/power/supply/bq24190_charger.c. It could allow a local attacker to crash the system due to a race condition.&#xA;CVE-2023-2985:A use after free flaw was found in hfsplus_put_super in fs/hfsplus/super.c in the Linux Kernel. This flaw could allow a local user to cause a denial of service problem.&#xA;CVE-2023-3161:A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing font-&gt;width and font-&gt;height greater than 32 to fbcon_set_font, since there are no checks in place, a shift-out-of-bounds occurs leading to undefined behavior and possible denial of service.&#xA;CVE-2023-3212:A NULL pointer dereference issue was found in the gfs2 file system in the Linux kernel. It occurs on corrupt gfs2 file systems when the evict code tries to reference the journal descriptor structure after it has been freed and set to NULL. A privileged local user could use this flaw to cause a kernel panic.&#xA;CVE-2023-3268:An out of bounds (OOB) memory access flaw was found in the Linux kernel in relay_file_read_start_pos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.&#xA;CVE-2023-35829:An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in rkvdec_remove in drivers/staging/media/rkvdec/rkvdec.c.&#xA;CVE-2023-3141:A use-after-free flaw was found in r592_remove in drivers/memstick/host/r592.c in media access in the Linux Kernel. This flaw allows a local attacker to crash the system at device disconnect, possibly leading to a kernel information leak.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-headers-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-tools-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/bpftool-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-headers-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-tools-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/bpftool-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2165</id>
		<title>An update for librabbitmq is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35789" id="CVE-2023-35789" title="CVE-2023-35789" type="cve"></reference>
		</references>
		<description>CVE-2023-35789:An issue was discovered in the C AMQP client library (aka rabbitmq-c) through 0.13.0 for RabbitMQ. Credentials can only be entered on the command line (e.g., for amqp-publish or amqp-consume) and are thus visible to local attackers by listing a process and its arguments.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="librabbitmq" release="9.u1.fos23" version="0.9.0">
					<filename>librabbitmq-0.9.0-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/librabbitmq-0.9.0-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="librabbitmq-devel" release="9.u1.fos23" version="0.9.0">
					<filename>librabbitmq-devel-0.9.0-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/librabbitmq-devel-0.9.0-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="librabbitmq-help" release="9.u1.fos23" version="0.9.0">
					<filename>librabbitmq-help-0.9.0-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/librabbitmq-help-0.9.0-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="librabbitmq" release="9.u1.fos23" version="0.9.0">
					<filename>librabbitmq-0.9.0-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/librabbitmq-0.9.0-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="librabbitmq-devel" release="9.u1.fos23" version="0.9.0">
					<filename>librabbitmq-devel-0.9.0-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/librabbitmq-devel-0.9.0-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="librabbitmq-help" release="9.u1.fos23" version="0.9.0">
					<filename>librabbitmq-help-0.9.0-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/librabbitmq-help-0.9.0-9.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2166</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26965" id="CVE-2023-26965" title="CVE-2023-26965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3316" id="CVE-2023-3316" title="CVE-2023-3316" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25433" id="CVE-2023-25433" title="CVE-2023-25433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26966" id="CVE-2023-26966" title="CVE-2023-26966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2908" id="CVE-2023-2908" title="CVE-2023-2908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3576" id="CVE-2023-3576" title="CVE-2023-3576" type="cve"></reference>
		</references>
		<description>CVE-2023-26965:loadImage() in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based use after free via a crafted TIFF image.&#xA;CVE-2023-3316:A NULL pointer dereference in TIFFClose() is caused by a failure to open an output file (non-existent path or a path that requires permissions like /dev/null) while specifying zones.&#xA;CVE-2023-25433:libtiff 4.5.0 is vulnerable to Buffer Overflow via /libtiff/tools/tiffcrop.c:8499. Incorrect updating of buffer size after rotateImage() in tiffcrop cause heap-buffer-overflow and SEGV.&#xA;CVE-2023-26966:libtiff 4.5.0 is vulnerable to Buffer Overflow in uv_encode() when libtiff reads a corrupted little-endian TIFF file and specifies the output to be big-endian.&#xA;CVE-2023-2908:A null pointer dereference issue was found in Libtiff&#39;s tif_dir.c file. This issue may allow an attacker to pass a crafted TIFF image file to the tiffcp utility which triggers a runtime error that causes undefined behavior. This will result in an application crash, eventually leading to a denial of service.&#xA;CVE-2023-3576:A vulnerability was found in libtiff where a memory leak exists in tools/tiffcrop.c</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-29.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/libtiff-4.3.0-29.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-29.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/libtiff-devel-4.3.0-29.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-29.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/libtiff-static-4.3.0-29.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-29.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/libtiff-tools-4.3.0-29.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-29.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/libtiff-help-4.3.0-29.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-29.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/libtiff-4.3.0-29.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-29.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/libtiff-devel-4.3.0-29.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-29.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/libtiff-static-4.3.0-29.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="29.u5.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-29.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/libtiff-tools-4.3.0-29.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2167</id>
		<title>An update for ncurses is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29491" id="CVE-2023-29491" title="CVE-2023-29491" type="cve"></reference>
		</references>
		<description>CVE-2023-29491:curses before 6.4 20230408, when used by a setuid application, allows local users to trigger security-relevant memory corruption via malformed data in a terminfo database file that is found in $HOME/.terminfo or reached via the TERMINFO or TERM environment variable.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="ncurses" release="7.u2.fos23" version="6.3">
					<filename>ncurses-6.3-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-6.3-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ncurses-base" release="7.u2.fos23" version="6.3">
					<filename>ncurses-base-6.3-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-base-6.3-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-libs" release="7.u2.fos23" version="6.3">
					<filename>ncurses-libs-6.3-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-libs-6.3-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-devel" release="7.u2.fos23" version="6.3">
					<filename>ncurses-devel-6.3-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-devel-6.3-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-compat-libs" release="7.u2.fos23" version="6.3">
					<filename>ncurses-compat-libs-6.3-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-compat-libs-6.3-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-static" release="7.u2.fos23" version="6.3">
					<filename>ncurses-static-6.3-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-static-6.3-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-help" release="7.u2.fos23" version="6.3">
					<filename>ncurses-help-6.3-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ncurses-help-6.3-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses" release="7.u2.fos23" version="6.3">
					<filename>ncurses-6.3-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ncurses-6.3-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-libs" release="7.u2.fos23" version="6.3">
					<filename>ncurses-libs-6.3-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ncurses-libs-6.3-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-devel" release="7.u2.fos23" version="6.3">
					<filename>ncurses-devel-6.3-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ncurses-devel-6.3-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-compat-libs" release="7.u2.fos23" version="6.3">
					<filename>ncurses-compat-libs-6.3-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ncurses-compat-libs-6.3-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-static" release="7.u2.fos23" version="6.3">
					<filename>ncurses-static-6.3-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ncurses-static-6.3-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-help" release="7.u2.fos23" version="6.3">
					<filename>ncurses-help-6.3-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ncurses-help-6.3-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2168</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
		</references>
		<description>CVE-2022-4304:A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.&#xA;CVE-2023-0465:Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0466:The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy check when doing certificate verification. However the implementation of the function does not enable the check which allows certificates with invalid or incorrect policies to pass the certificate verification. As suddenly enabling the policy check could break existing deployments it was decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument. Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.&#xA;CVE-2023-0286:There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u2.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/openresty-openssl111-asan-1.1.1h-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u2.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/openresty-openssl111-asan-1.1.1h-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2169</id>
		<title>An update for perl-HTTP-Tiny is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31486" id="CVE-2023-31486" title="CVE-2023-31486" type="cve"></reference>
		</references>
		<description>CVE-2023-31486:HTTP::Tiny before 0.083, a Perl core module since 5.13.9 and available standalone on CPAN, has an insecure default TLS configuration where users must opt in to verify certificates.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="noarch" epoch="0" name="perl-HTTP-Tiny" release="2.u1.fos23" version="0.080">
					<filename>perl-HTTP-Tiny-0.080-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/perl-HTTP-Tiny-0.080-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-HTTP-Tiny-help" release="2.u1.fos23" version="0.080">
					<filename>perl-HTTP-Tiny-help-0.080-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/perl-HTTP-Tiny-help-0.080-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2170</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36617" id="CVE-2023-36617" title="CVE-2023-36617" type="cve"></reference>
		</references>
		<description>CVE-2023-36617:A ReDoS issue was discovered in the URI component before 0.12.2 for Ruby. The URI parser mishandles invalid URLs that have specific characters. There is an increase in execution time for parsing strings to URI objects with rfc2396_parser.rb and rfc3986_parser.rb. NOTE: this issue exists becuse of an incomplete fix for CVE-2023-28755. Version 0.10.3 is also a fixed version.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="ruby" release="131.u3.fos23" version="3.0.3">
					<filename>ruby-3.0.3-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ruby-3.0.3-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="131.u3.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ruby-devel-3.0.3-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="131.u3.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygems-3.2.32-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="131.u3.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygems-devel-3.2.32-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="131.u3.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-rake-13.0.3-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="131.u3.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-rbs-1.4.0-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="131.u3.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ruby-irb-3.0.3-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="131.u3.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-rdoc-6.3.3-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="131.u3.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/ruby-help-3.0.3-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="131.u3.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-bigdecimal-3.0.0-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="131.u3.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-did_you_mean-1.5.0-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="131.u3.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-io-console-0.5.7-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="131.u3.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-json-2.5.1-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="131.u3.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-minitest-5.14.2-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="131.u3.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-openssl-2.2.1-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-power_assert" release="131.u3.fos23" version="1.2.0">
					<filename>rubygem-power_assert-1.2.0-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-power_assert-1.2.0-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="131.u3.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-131.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-psych-3.3.2-131.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="131.u3.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-test-unit-3.3.7-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="131.u3.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-rexml-3.2.5-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="131.u3.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-rss-0.2.9-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="131.u3.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-131.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/rubygem-typeprof-0.15.2-131.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="131.u3.fos23" version="3.0.3">
					<filename>ruby-3.0.3-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ruby-3.0.3-131.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="131.u3.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/ruby-devel-3.0.3-131.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="131.u3.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/rubygem-bigdecimal-3.0.0-131.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="131.u3.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/rubygem-io-console-0.5.7-131.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="131.u3.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/rubygem-json-2.5.1-131.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="131.u3.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/rubygem-openssl-2.2.1-131.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="131.u3.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-131.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/rubygem-psych-3.3.2-131.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2171</id>
		<title>An update for snappy-java is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34454" id="CVE-2023-34454" title="CVE-2023-34454" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34455" id="CVE-2023-34455" title="CVE-2023-34455" type="cve"></reference>
		</references>
		<description>CVE-2023-34454:snappy-java is a fast compressor/decompressor for Java. Due to unchecked multiplications, an integer overflow may occur in versions prior to 1.1.10.1, causing an unrecoverable fatal error. The function `compress(char[] input)` in the file `Snappy.java` receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the rawCompress` function. Since the length is not tested, the multiplication by two can cause an integer overflow and become negative. The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array. Since the maxCompressedLength function treats the length as an unsigned integer, it doesn’t care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine. If the result is negative, a `java.lang.NegativeArraySizeException` exception will be raised while trying to allocate the array `buf`. On the other side, if the result is positive, the `buf` array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error. The same issue exists also when using the `compress` functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won’t occur when using a byte array, since creating a byte array of size 0x80000000 (or any other negative value) is impossible in the first place.&#xA;CVE-2023-34455:snappy-java is a fast compressor/decompressor for Java. Due to use of an unchecked chunk length, an unrecoverable fatal error can occur in versions prior to 1.1.10.1. The code in the function hasNextChunk in the fileSnappyInputStream.java checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk. In the case that the `compressed` variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the `chunkSize` variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a `java.lang.NegativeArraySizeException` exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal `java.lang.OutOfMemoryError` error. Version 1.1.10.1 contains a patch for this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="snappy-java" release="2.u1.fos23" version="1.1.2.4">
					<filename>snappy-java-1.1.2.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/snappy-java-1.1.2.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="snappy-java-javadoc" release="2.u1.fos23" version="1.1.2.4">
					<filename>snappy-java-javadoc-1.1.2.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/snappy-java-javadoc-1.1.2.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="snappy-java" release="2.u1.fos23" version="1.1.2.4">
					<filename>snappy-java-1.1.2.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/snappy-java-1.1.2.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2172</id>
		<title>An update for tang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1672" id="CVE-2023-1672" title="CVE-2023-1672" type="cve"></reference>
		</references>
		<description>CVE-2023-1672:A race condition exists in the Tang server functionality for key generation and key rotation. This flaw results in a small time window where Tang private keys become readable by other processes on the same host.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="tang" release="3.u2.fos23" version="7">
					<filename>tang-7-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/tang-7-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tang-help" release="3.u2.fos23" version="7">
					<filename>tang-help-7-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/tang-help-7-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tang" release="3.u2.fos23" version="7">
					<filename>tang-7-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/tang-7-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2173</id>
		<title>An update for texlive-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32700" id="CVE-2023-32700" title="CVE-2023-32700" type="cve"></reference>
		</references>
		<description>CVE-2023-32700:LuaTeX before 1.17.0 allows execution of arbitrary shell commands when compiling a TeX file obtained from an untrusted source. This occurs because luatex-core.lua lets the original io.popen be accessed. This also affects TeX Live before 2023 r66984 and MiKTeX before 23.5.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="7" name="texlive-base" release="34.u1.fos23" version="20180414">
					<filename>texlive-base-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-base-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-a2ping" release="34.u1.fos23" version="20180414">
					<filename>texlive-a2ping-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-a2ping-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-accfonts" release="34.u1.fos23" version="20180414">
					<filename>texlive-accfonts-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-accfonts-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-adhocfilelist" release="34.u1.fos23" version="20180414">
					<filename>texlive-adhocfilelist-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-adhocfilelist-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-afm2pl" release="34.u1.fos23" version="20180414">
					<filename>texlive-afm2pl-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-afm2pl-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-aleph" release="34.u1.fos23" version="20180414">
					<filename>texlive-aleph-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-aleph-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-amstex" release="34.u1.fos23" version="20180414">
					<filename>texlive-amstex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-amstex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-arara" release="34.u1.fos23" version="20180414">
					<filename>texlive-arara-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-arara-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-authorindex" release="34.u1.fos23" version="20180414">
					<filename>texlive-authorindex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-authorindex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-autosp" release="34.u1.fos23" version="20180414">
					<filename>texlive-autosp-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-autosp-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-axodraw2" release="34.u1.fos23" version="20180414">
					<filename>texlive-axodraw2-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-axodraw2-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bib2gls" release="34.u1.fos23" version="20180414">
					<filename>texlive-bib2gls-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-bib2gls-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bibexport" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibexport-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-bibexport-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibtex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-bibtex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtexu" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibtexu-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-bibtexu-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex8" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibtex8-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-bibtex8-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bundledoc" release="34.u1.fos23" version="20180414">
					<filename>texlive-bundledoc-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-bundledoc-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cachepic" release="34.u1.fos23" version="20180414">
					<filename>texlive-cachepic-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-cachepic-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checkcites" release="34.u1.fos23" version="20180414">
					<filename>texlive-checkcites-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-checkcites-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checklistings" release="34.u1.fos23" version="20180414">
					<filename>texlive-checklistings-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-checklistings-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-chktex" release="34.u1.fos23" version="20180414">
					<filename>texlive-chktex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-chktex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cjkutils" release="34.u1.fos23" version="20180414">
					<filename>texlive-cjkutils-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-cjkutils-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-context" release="34.u1.fos23" version="20180414">
					<filename>texlive-context-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-context-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-convbkmk" release="34.u1.fos23" version="20180414">
					<filename>texlive-convbkmk-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-convbkmk-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-crossrefware" release="34.u1.fos23" version="20180414">
					<filename>texlive-crossrefware-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-crossrefware-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cslatex" release="34.u1.fos23" version="20180414">
					<filename>texlive-cslatex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-cslatex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-csplain" release="34.u1.fos23" version="20180414">
					<filename>texlive-csplain-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-csplain-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctan-o-mat" release="34.u1.fos23" version="20180414">
					<filename>texlive-ctan-o-mat-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ctan-o-mat-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctanify" release="34.u1.fos23" version="20180414">
					<filename>texlive-ctanify-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ctanify-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ctie" release="34.u1.fos23" version="20180414">
					<filename>texlive-ctie-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ctie-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cweb" release="34.u1.fos23" version="20180414">
					<filename>texlive-cweb-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-cweb-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cyrillic" release="34.u1.fos23" version="20180414">
					<filename>texlive-cyrillic-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-cyrillic-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-de-macro" release="34.u1.fos23" version="20180414">
					<filename>texlive-de-macro-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-de-macro-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-detex" release="34.u1.fos23" version="20180414">
					<filename>texlive-detex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-detex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-diadia" release="34.u1.fos23" version="20180414">
					<filename>texlive-diadia-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-diadia-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dosepsbin" release="34.u1.fos23" version="20180414">
					<filename>texlive-dosepsbin-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dosepsbin-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dtl" release="34.u1.fos23" version="20180414">
					<filename>texlive-dtl-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dtl-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dtxgen" release="34.u1.fos23" version="20180414">
					<filename>texlive-dtxgen-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dtxgen-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvi2tty" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvi2tty-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvi2tty-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviasm" release="34.u1.fos23" version="20180414">
					<filename>texlive-dviasm-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dviasm-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvicopy" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvicopy-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvicopy-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvidvi" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvidvi-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvidvi-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviinfox" release="34.u1.fos23" version="20180414">
					<filename>texlive-dviinfox-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dviinfox-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dviljk" release="34.u1.fos23" version="20180414">
					<filename>texlive-dviljk-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dviljk-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipdfmx" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvipdfmx-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvipdfmx-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipng" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvipng-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvipng-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipos" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvipos-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvipos-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvips" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvips-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvips-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvisvgm" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvisvgm-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-dvisvgm-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ebong" release="34.u1.fos23" version="20180414">
					<filename>texlive-ebong-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ebong-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-eplain" release="34.u1.fos23" version="20180414">
					<filename>texlive-eplain-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-eplain-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epspdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-epspdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-epspdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epstopdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-epstopdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-epstopdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fig4latex" release="34.u1.fos23" version="20180414">
					<filename>texlive-fig4latex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-fig4latex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-findhyph" release="34.u1.fos23" version="20180414">
					<filename>texlive-findhyph-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-findhyph-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontinst" release="34.u1.fos23" version="20180414">
					<filename>texlive-fontinst-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-fontinst-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontools" release="34.u1.fos23" version="20180414">
					<filename>texlive-fontools-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-fontools-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-fontware" release="34.u1.fos23" version="20180414">
					<filename>texlive-fontware-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-fontware-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fragmaster" release="34.u1.fos23" version="20180414">
					<filename>texlive-fragmaster-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-fragmaster-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-getmap" release="34.u1.fos23" version="20180414">
					<filename>texlive-getmap-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-getmap-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glossaries" release="34.u1.fos23" version="20180414">
					<filename>texlive-glossaries-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-glossaries-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glyphlist" release="34.u1.fos23" version="20180414">
					<filename>texlive-glyphlist-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-glyphlist-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gregoriotex" release="34.u1.fos23" version="20180414">
					<filename>texlive-gregoriotex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-gregoriotex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gsftopk" release="34.u1.fos23" version="20180414">
					<filename>texlive-gsftopk-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-gsftopk-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-installfont" release="34.u1.fos23" version="20180414">
					<filename>texlive-installfont-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-installfont-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jadetex" release="34.u1.fos23" version="20180414">
					<filename>texlive-jadetex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-jadetex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jfmutil" release="34.u1.fos23" version="20180414">
					<filename>texlive-jfmutil-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-jfmutil-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-kotex-utils" release="34.u1.fos23" version="20180414">
					<filename>texlive-kotex-utils-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-kotex-utils-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-kpathsea" release="34.u1.fos23" version="20180414">
					<filename>texlive-kpathsea-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-kpathsea-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-l3build" release="34.u1.fos23" version="20180414">
					<filename>texlive-l3build-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-l3build-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lacheck" release="34.u1.fos23" version="20180414">
					<filename>texlive-lacheck-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lacheck-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex" release="34.u1.fos23" version="20180414">
					<filename>texlive-latex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-git-log" release="34.u1.fos23" version="20180414">
					<filename>texlive-latex-git-log-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latex-git-log-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-papersize" release="34.u1.fos23" version="20180414">
					<filename>texlive-latex-papersize-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latex-papersize-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2man" release="34.u1.fos23" version="20180414">
					<filename>texlive-latex2man-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latex2man-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2nemeth" release="34.u1.fos23" version="20180414">
					<filename>texlive-latex2nemeth-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latex2nemeth-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexdiff" release="34.u1.fos23" version="20180414">
					<filename>texlive-latexdiff-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latexdiff-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexfileversion" release="34.u1.fos23" version="20180414">
					<filename>texlive-latexfileversion-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latexfileversion-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexpand" release="34.u1.fos23" version="20180414">
					<filename>texlive-latexpand-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-latexpand-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lcdftypetools" release="34.u1.fos23" version="20180414">
					<filename>texlive-lcdftypetools-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lcdftypetools-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib" release="34.u1.fos23" version="20180414">
					<filename>texlive-lib-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lib-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib-devel" release="34.u1.fos23" version="20180414">
					<filename>texlive-lib-devel-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lib-devel-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lilyglyphs" release="34.u1.fos23" version="20180414">
					<filename>texlive-lilyglyphs-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lilyglyphs-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listbib" release="34.u1.fos23" version="20180414">
					<filename>texlive-listbib-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-listbib-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listings-ext" release="34.u1.fos23" version="20180414">
					<filename>texlive-listings-ext-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-listings-ext-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lollipop" release="34.u1.fos23" version="20180414">
					<filename>texlive-lollipop-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lollipop-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltxfileinfo" release="34.u1.fos23" version="20180414">
					<filename>texlive-ltxfileinfo-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ltxfileinfo-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltximg" release="34.u1.fos23" version="20180414">
					<filename>texlive-ltximg-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ltximg-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lua2dox" release="34.u1.fos23" version="20180414">
					<filename>texlive-lua2dox-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lua2dox-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-luaotfload" release="34.u1.fos23" version="20180414">
					<filename>texlive-luaotfload-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-luaotfload-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-luatex" release="34.u1.fos23" version="20180414">
					<filename>texlive-luatex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-luatex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lwarp" release="34.u1.fos23" version="20180414">
					<filename>texlive-lwarp-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lwarp-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lyluatex" release="34.u1.fos23" version="svn47584">
					<filename>texlive-lyluatex-svn47584-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-lyluatex-svn47584-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-make4ht" release="34.u1.fos23" version="20180414">
					<filename>texlive-make4ht-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-make4ht-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-makedtx" release="34.u1.fos23" version="20180414">
					<filename>texlive-makedtx-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-makedtx-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-makeindex" release="34.u1.fos23" version="20180414">
					<filename>texlive-makeindex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-makeindex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-match_parens" release="34.u1.fos23" version="20180414">
					<filename>texlive-match_parens-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-match_parens-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mathspic" release="34.u1.fos23" version="20180414">
					<filename>texlive-mathspic-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mathspic-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metafont" release="34.u1.fos23" version="20180414">
					<filename>texlive-metafont-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-metafont-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metapost" release="34.u1.fos23" version="20180414">
					<filename>texlive-metapost-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-metapost-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mex" release="34.u1.fos23" version="20180414">
					<filename>texlive-mex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mflua" release="34.u1.fos23" version="20180414">
					<filename>texlive-mflua-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mflua-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mfware" release="34.u1.fos23" version="20180414">
					<filename>texlive-mfware-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mfware-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mf2pt1" release="34.u1.fos23" version="20180414">
					<filename>texlive-mf2pt1-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mf2pt1-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkgrkindex" release="34.u1.fos23" version="20180414">
					<filename>texlive-mkgrkindex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mkgrkindex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkjobtexmf" release="34.u1.fos23" version="20180414">
					<filename>texlive-mkjobtexmf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mkjobtexmf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkpic" release="34.u1.fos23" version="20180414">
					<filename>texlive-mkpic-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mkpic-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mltex" release="34.u1.fos23" version="20180414">
					<filename>texlive-mltex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mltex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mptopdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-mptopdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-mptopdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-multibibliography" release="34.u1.fos23" version="20180414">
					<filename>texlive-multibibliography-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-multibibliography-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-musixtex" release="34.u1.fos23" version="20180414">
					<filename>texlive-musixtex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-musixtex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-musixtnt" release="34.u1.fos23" version="20180414">
					<filename>texlive-musixtnt-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-musixtnt-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-m-tx" release="34.u1.fos23" version="20180414">
					<filename>texlive-m-tx-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-m-tx-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-oberdiek" release="34.u1.fos23" version="20180414">
					<filename>texlive-oberdiek-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-oberdiek-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-omegaware" release="34.u1.fos23" version="20180414">
					<filename>texlive-omegaware-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-omegaware-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-patgen" release="34.u1.fos23" version="20180414">
					<filename>texlive-patgen-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-patgen-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pax" release="34.u1.fos23" version="20180414">
					<filename>texlive-pax-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pax-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfbook2" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdfbook2-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdfbook2-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfcrop" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdfcrop-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdfcrop-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfjam" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdfjam-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdfjam-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdflatexpicscale" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdflatexpicscale-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdflatexpicscale-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftex" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdftex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdftex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftools" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdftools-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdftools-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfxup" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdfxup-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pdfxup-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pedigree-perl" release="34.u1.fos23" version="20180414">
					<filename>texlive-pedigree-perl-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pedigree-perl-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-perltex" release="34.u1.fos23" version="20180414">
					<filename>texlive-perltex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-perltex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-petri-nets" release="34.u1.fos23" version="20180414">
					<filename>texlive-petri-nets-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-petri-nets-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pfarrei" release="34.u1.fos23" version="20180414">
					<filename>texlive-pfarrei-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pfarrei-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix" release="34.u1.fos23" version="20180414">
					<filename>texlive-pkfix-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pkfix-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix-helper" release="34.u1.fos23" version="20180414">
					<filename>texlive-pkfix-helper-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pkfix-helper-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pmx" release="34.u1.fos23" version="20180414">
					<filename>texlive-pmx-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pmx-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pmxchords" release="34.u1.fos23" version="20180414">
					<filename>texlive-pmxchords-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pmxchords-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pstools" release="34.u1.fos23" version="20180414">
					<filename>texlive-pstools-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pstools-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst2pdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-pst2pdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pst2pdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst-pdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-pst-pdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pst-pdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ps2pk" release="34.u1.fos23" version="20180414">
					<filename>texlive-ps2pk-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ps2pk-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ptex" release="34.u1.fos23" version="20180414">
					<filename>texlive-ptex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ptex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex-fontmaps" release="34.u1.fos23" version="20180414">
					<filename>texlive-ptex-fontmaps-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ptex-fontmaps-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex2pdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-ptex2pdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ptex2pdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-purifyeps" release="34.u1.fos23" version="20180414">
					<filename>texlive-purifyeps-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-purifyeps-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pygmentex" release="34.u1.fos23" version="20180414">
					<filename>texlive-pygmentex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pygmentex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pythontex" release="34.u1.fos23" version="20180414">
					<filename>texlive-pythontex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-pythontex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-rubik" release="34.u1.fos23" version="20180414">
					<filename>texlive-rubik-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-rubik-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-seetexk" release="34.u1.fos23" version="20180414">
					<filename>texlive-seetexk-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-seetexk-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-splitindex" release="34.u1.fos23" version="20180414">
					<filename>texlive-splitindex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-splitindex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-srcredact" release="34.u1.fos23" version="20180414">
					<filename>texlive-srcredact-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-srcredact-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-sty2dtx" release="34.u1.fos23" version="20180414">
					<filename>texlive-sty2dtx-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-sty2dtx-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-svn-multi" release="34.u1.fos23" version="20180414">
					<filename>texlive-svn-multi-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-svn-multi-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-synctex" release="34.u1.fos23" version="20180414">
					<filename>texlive-synctex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-synctex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tetex" release="34.u1.fos23" version="20180414">
					<filename>texlive-tetex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-tetex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex" release="34.u1.fos23" version="20180414">
					<filename>texlive-tex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-tex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tex4ebook" release="34.u1.fos23" version="20180414">
					<filename>texlive-tex4ebook-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-tex4ebook-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex4ht" release="34.u1.fos23" version="20180414">
					<filename>texlive-tex4ht-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-tex4ht-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texconfig" release="34.u1.fos23" version="20180414">
					<filename>texlive-texconfig-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texconfig-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texcount" release="34.u1.fos23" version="20180414">
					<filename>texlive-texcount-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texcount-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdef" release="34.u1.fos23" version="20180414">
					<filename>texlive-texdef-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texdef-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdiff" release="34.u1.fos23" version="20180414">
					<filename>texlive-texdiff-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texdiff-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdirflatten" release="34.u1.fos23" version="20180414">
					<filename>texlive-texdirflatten-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texdirflatten-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoc" release="34.u1.fos23" version="20180414">
					<filename>texlive-texdoc-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texdoc-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoctk" release="34.u1.fos23" version="20180414">
					<filename>texlive-texdoctk-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texdoctk-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texfot" release="34.u1.fos23" version="20180414">
					<filename>texlive-texfot-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texfot-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texliveonfly" release="34.u1.fos23" version="20180414">
					<filename>texlive-texliveonfly-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texliveonfly-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-en" release="34.u1.fos23" version="20180414">
					<filename>texlive-texlive-en-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texlive-en-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-scripts" release="34.u1.fos23" version="20180414">
					<filename>texlive-texlive-scripts-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texlive-scripts-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive.infra" release="34.u1.fos23" version="20180414">
					<filename>texlive-texlive.infra-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texlive.infra-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texloganalyser" release="34.u1.fos23" version="20180414">
					<filename>texlive-texloganalyser-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texloganalyser-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texosquery" release="34.u1.fos23" version="20180414">
					<filename>texlive-texosquery-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texosquery-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texsis" release="34.u1.fos23" version="20180414">
					<filename>texlive-texsis-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texsis-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-texware" release="34.u1.fos23" version="20180414">
					<filename>texlive-texware-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-texware-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-thumbpdf" release="34.u1.fos23" version="20180414">
					<filename>texlive-thumbpdf-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-thumbpdf-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tie" release="34.u1.fos23" version="20180414">
					<filename>texlive-tie-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-tie-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tpic2pdftex" release="34.u1.fos23" version="20180414">
					<filename>texlive-tpic2pdftex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-tpic2pdftex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ttfutils" release="34.u1.fos23" version="20180414">
					<filename>texlive-ttfutils-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ttfutils-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-typeoutfileinfo" release="34.u1.fos23" version="20180414">
					<filename>texlive-typeoutfileinfo-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-typeoutfileinfo-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ulqda" release="34.u1.fos23" version="20180414">
					<filename>texlive-ulqda-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-ulqda-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-uptex" release="34.u1.fos23" version="20180414">
					<filename>texlive-uptex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-uptex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-urlbst" release="34.u1.fos23" version="20180414">
					<filename>texlive-urlbst-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-urlbst-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-velthuis" release="34.u1.fos23" version="20180414">
					<filename>texlive-velthuis-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-velthuis-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-vlna" release="34.u1.fos23" version="20180414">
					<filename>texlive-vlna-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-vlna-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-vpe" release="34.u1.fos23" version="20180414">
					<filename>texlive-vpe-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-vpe-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-web" release="34.u1.fos23" version="20180414">
					<filename>texlive-web-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-web-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-wordcount" release="34.u1.fos23" version="20180414">
					<filename>texlive-wordcount-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-wordcount-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xdvi" release="34.u1.fos23" version="20180414">
					<filename>texlive-xdvi-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-xdvi-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xetex" release="34.u1.fos23" version="20180414">
					<filename>texlive-xetex-20180414-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-xetex-20180414-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-xmltex" release="34.u1.fos23" version="20180414">
					<filename>texlive-xmltex-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-xmltex-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-yplan" release="34.u1.fos23" version="20180414">
					<filename>texlive-yplan-20180414-34.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/texlive-yplan-20180414-34.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-base" release="34.u1.fos23" version="20180414">
					<filename>texlive-base-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-base-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-afm2pl" release="34.u1.fos23" version="20180414">
					<filename>texlive-afm2pl-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-afm2pl-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-aleph" release="34.u1.fos23" version="20180414">
					<filename>texlive-aleph-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-aleph-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-autosp" release="34.u1.fos23" version="20180414">
					<filename>texlive-autosp-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-autosp-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-axodraw2" release="34.u1.fos23" version="20180414">
					<filename>texlive-axodraw2-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-axodraw2-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibtex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-bibtex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtexu" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibtexu-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-bibtexu-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex8" release="34.u1.fos23" version="20180414">
					<filename>texlive-bibtex8-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-bibtex8-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-chktex" release="34.u1.fos23" version="20180414">
					<filename>texlive-chktex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-chktex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cjkutils" release="34.u1.fos23" version="20180414">
					<filename>texlive-cjkutils-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-cjkutils-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ctie" release="34.u1.fos23" version="20180414">
					<filename>texlive-ctie-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-ctie-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cweb" release="34.u1.fos23" version="20180414">
					<filename>texlive-cweb-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-cweb-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-detex" release="34.u1.fos23" version="20180414">
					<filename>texlive-detex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-detex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dtl" release="34.u1.fos23" version="20180414">
					<filename>texlive-dtl-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dtl-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvi2tty" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvi2tty-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvi2tty-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvicopy" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvicopy-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvicopy-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvidvi" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvidvi-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvidvi-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dviljk" release="34.u1.fos23" version="20180414">
					<filename>texlive-dviljk-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dviljk-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipdfmx" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvipdfmx-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvipdfmx-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipng" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvipng-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvipng-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipos" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvipos-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvipos-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvips" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvips-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvips-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvisvgm" release="34.u1.fos23" version="20180414">
					<filename>texlive-dvisvgm-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-dvisvgm-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-fontware" release="34.u1.fos23" version="20180414">
					<filename>texlive-fontware-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-fontware-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gregoriotex" release="34.u1.fos23" version="20180414">
					<filename>texlive-gregoriotex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-gregoriotex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gsftopk" release="34.u1.fos23" version="20180414">
					<filename>texlive-gsftopk-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-gsftopk-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-kpathsea" release="34.u1.fos23" version="20180414">
					<filename>texlive-kpathsea-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-kpathsea-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lacheck" release="34.u1.fos23" version="20180414">
					<filename>texlive-lacheck-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-lacheck-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lcdftypetools" release="34.u1.fos23" version="20180414">
					<filename>texlive-lcdftypetools-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-lcdftypetools-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib" release="34.u1.fos23" version="20180414">
					<filename>texlive-lib-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-lib-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib-devel" release="34.u1.fos23" version="20180414">
					<filename>texlive-lib-devel-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-lib-devel-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-luatex" release="34.u1.fos23" version="20180414">
					<filename>texlive-luatex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-luatex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-makeindex" release="34.u1.fos23" version="20180414">
					<filename>texlive-makeindex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-makeindex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metafont" release="34.u1.fos23" version="20180414">
					<filename>texlive-metafont-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-metafont-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metapost" release="34.u1.fos23" version="20180414">
					<filename>texlive-metapost-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-metapost-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mflua" release="34.u1.fos23" version="20180414">
					<filename>texlive-mflua-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-mflua-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mfware" release="34.u1.fos23" version="20180414">
					<filename>texlive-mfware-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-mfware-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-musixtnt" release="34.u1.fos23" version="20180414">
					<filename>texlive-musixtnt-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-musixtnt-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-m-tx" release="34.u1.fos23" version="20180414">
					<filename>texlive-m-tx-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-m-tx-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-omegaware" release="34.u1.fos23" version="20180414">
					<filename>texlive-omegaware-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-omegaware-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-patgen" release="34.u1.fos23" version="20180414">
					<filename>texlive-patgen-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-patgen-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftex" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdftex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-pdftex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftools" release="34.u1.fos23" version="20180414">
					<filename>texlive-pdftools-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-pdftools-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pmx" release="34.u1.fos23" version="20180414">
					<filename>texlive-pmx-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-pmx-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pstools" release="34.u1.fos23" version="20180414">
					<filename>texlive-pstools-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-pstools-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ps2pk" release="34.u1.fos23" version="20180414">
					<filename>texlive-ps2pk-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-ps2pk-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ptex" release="34.u1.fos23" version="20180414">
					<filename>texlive-ptex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-ptex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-seetexk" release="34.u1.fos23" version="20180414">
					<filename>texlive-seetexk-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-seetexk-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-synctex" release="34.u1.fos23" version="20180414">
					<filename>texlive-synctex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-synctex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex" release="34.u1.fos23" version="20180414">
					<filename>texlive-tex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-tex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex4ht" release="34.u1.fos23" version="20180414">
					<filename>texlive-tex4ht-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-tex4ht-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-texware" release="34.u1.fos23" version="20180414">
					<filename>texlive-texware-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-texware-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tie" release="34.u1.fos23" version="20180414">
					<filename>texlive-tie-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-tie-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ttfutils" release="34.u1.fos23" version="20180414">
					<filename>texlive-ttfutils-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-ttfutils-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-uptex" release="34.u1.fos23" version="20180414">
					<filename>texlive-uptex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-uptex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-velthuis" release="34.u1.fos23" version="20180414">
					<filename>texlive-velthuis-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-velthuis-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-vlna" release="34.u1.fos23" version="20180414">
					<filename>texlive-vlna-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-vlna-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-web" release="34.u1.fos23" version="20180414">
					<filename>texlive-web-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-web-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xdvi" release="34.u1.fos23" version="20180414">
					<filename>texlive-xdvi-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-xdvi-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xetex" release="34.u1.fos23" version="20180414">
					<filename>texlive-xetex-20180414-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/texlive-xetex-20180414-34.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2174</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-07-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0667" id="CVE-2023-0667" title="CVE-2023-0667" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2952" id="CVE-2023-2952" title="CVE-2023-2952" type="cve"></reference>
		</references>
		<description>CVE-2023-0667:Due to failure in validating the length provided by an attacker-crafted MSMMS packet, Wireshark version 4.0.5 and prior, in an unusual configuration, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark&#xA;CVE-2023-2952:XRA dissector infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="1.u4.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/wireshark-3.6.14-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="1.u4.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/wireshark-devel-3.6.14-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="1.u4.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/wireshark-help-3.6.14-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="1.u4.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/wireshark-3.6.14-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="1.u4.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/wireshark-devel-3.6.14-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="1.u4.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/wireshark-help-3.6.14-1.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2175</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3428" id="CVE-2023-3428" title="CVE-2023-3428" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34474" id="CVE-2023-34474" title="CVE-2023-34474" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34475" id="CVE-2023-34475" title="CVE-2023-34475" type="cve"></reference>
		</references>
		<description>CVE-2023-3428:A vulnerability was found in ImageMagick &lt;=7.1.1, where heap-based buffer overflow was found in coders/tiff.c.&#xA;CVE-2023-34474:A heap-based buffer overflow issue was discovered in ImageMagick&#39;s ReadTIM2ImageData() function in coders/tim2.c. A local attacker could trick the user in opening specially crafted file, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.&#xA;CVE-2023-34475:A heap use after free issue was discovered in ImageMagick&#39;s ReplaceXmpValue() function in MagickCore/profile.c. An attacker could trick user to open a specially crafted file to convert, triggering an heap-use-after-free write error, allowing an application to crash, resulting in a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ImageMagick-7.1.1.8-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ImageMagick-devel-7.1.1.8-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ImageMagick-help-7.1.1.8-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ImageMagick-perl-7.1.1.8-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ImageMagick-c++-7.1.1.8-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ImageMagick-c++-devel-7.1.1.8-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ImageMagick-7.1.1.8-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ImageMagick-devel-7.1.1.8-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ImageMagick-help-7.1.1.8-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ImageMagick-perl-7.1.1.8-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ImageMagick-c++-7.1.1.8-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="4.u4.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ImageMagick-c++-devel-7.1.1.8-4.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2176</id>
		<title>An update for cjose is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37464" id="CVE-2023-37464" title="CVE-2023-37464" type="cve"></reference>
		</references>
		<description>CVE-2023-37464:OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). The AES GCM decryption routine incorrectly uses the Tag length from the actual Authentication Tag provided in the JWE. The spec  says that a fixed length of 16 octets must be applied. Therefore this bug allows an attacker to provide a truncated Authentication Tag and to modify the JWE accordingly. Users should upgrade to a version &gt;= 0.6.2.2. Users unable to upgrade should avoid using AES GCM encryption and replace it with another encryption algorithm (e.g. AES CBC).</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="cjose" release="1.fos23" version="0.6.2.2">
					<filename>cjose-0.6.2.2-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/cjose-0.6.2.2-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cjose-devel" release="1.fos23" version="0.6.2.2">
					<filename>cjose-devel-0.6.2.2-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/cjose-devel-0.6.2.2-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjose" release="1.fos23" version="0.6.2.2">
					<filename>cjose-0.6.2.2-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/cjose-0.6.2.2-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjose-devel" release="1.fos23" version="0.6.2.2">
					<filename>cjose-devel-0.6.2.2-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/cjose-devel-0.6.2.2-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2177</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32001" id="CVE-2023-32001" title="CVE-2023-32001" type="cve"></reference>
		</references>
		<description>CVE-2023-32001:libcurl can be told to save cookie, HSTS and/or alt-svc data to files. When&#xA;doing this, it called `stat()` followed by `fopen()` in a way that made it&#xA;vulnerable to a TOCTOU race condition problem.&#xA;By exploiting this flaw, an attacker could trick the victim to create or&#xA;overwrite protected files holding this data in ways it was not intended to.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="curl" release="23.u10.fos23" version="7.79.1">
					<filename>curl-7.79.1-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/curl-7.79.1-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="23.u10.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libcurl-7.79.1-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="23.u10.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libcurl-devel-7.79.1-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="23.u10.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-23.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/curl-help-7.79.1-23.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="23.u10.fos23" version="7.79.1">
					<filename>curl-7.79.1-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/curl-7.79.1-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="23.u10.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libcurl-7.79.1-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="23.u10.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libcurl-devel-7.79.1-23.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2178</id>
		<title>An update for dbus is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34969" id="CVE-2023-34969" title="CVE-2023-34969" type="cve"></reference>
		</references>
		<description>CVE-2023-34969:D-Bus before 1.15.6 sometimes allows unprivileged users to crash dbus-daemon. If a privileged user with control over the dbus-daemon is using the org.freedesktop.DBus.Monitoring interface to monitor message bus traffic, then an unprivileged user with the ability to connect to the same dbus-daemon can cause a dbus-daemon crash under some circumstances via an unreplyable message. When done on the well-known system bus, this is a denial-of-service vulnerability. The fixed versions are 1.12.28, 1.14.8, and 1.15.6.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="1" name="dbus" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-1.12.20-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/dbus-1.12.20-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dbus-libs" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-libs-1.12.20-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/dbus-libs-1.12.20-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dbus-daemon" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-daemon-1.12.20-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/dbus-daemon-1.12.20-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="dbus-common" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-common-1.12.20-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-common-1.12.20-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dbus-tools" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-tools-1.12.20-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/dbus-tools-1.12.20-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dbus-devel" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-devel-1.12.20-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/dbus-devel-1.12.20-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dbus-x11" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-x11-1.12.20-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/dbus-x11-1.12.20-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="dbus-help" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-help-1.12.20-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-help-1.12.20-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dbus" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-1.12.20-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-1.12.20-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dbus-libs" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-libs-1.12.20-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-libs-1.12.20-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dbus-daemon" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-daemon-1.12.20-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-daemon-1.12.20-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dbus-tools" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-tools-1.12.20-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-tools-1.12.20-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dbus-devel" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-devel-1.12.20-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-devel-1.12.20-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dbus-x11" release="9.u1.fos23" version="1.12.20">
					<filename>dbus-x11-1.12.20-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/dbus-x11-1.12.20-9.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2179</id>
		<title>An update for gdk-pixbuf2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-44648" id="CVE-2021-44648" title="CVE-2021-44648" type="cve"></reference>
		</references>
		<description>CVE-2021-44648:GNOME gdk-pixbuf 2.42.6 is vulnerable to a heap-buffer overflow vulnerability when decoding the lzw compressed stream of image data in GIF files with lzw minimum code size equals to 12.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/gdk-pixbuf2-2.42.6-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-modules" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/gdk-pixbuf2-modules-2.42.6-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-devel" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/gdk-pixbuf2-devel-2.42.6-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-tests" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/gdk-pixbuf2-tests-2.42.6-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdk-pixbuf2-help" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-help-2.42.6-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/gdk-pixbuf2-help-2.42.6-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/gdk-pixbuf2-2.42.6-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-modules" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/gdk-pixbuf2-modules-2.42.6-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-devel" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/gdk-pixbuf2-devel-2.42.6-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-tests" release="6.u1.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/gdk-pixbuf2-tests-2.42.6-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2181</id>
		<title>An update for guava20 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2976" id="CVE-2023-2976" title="CVE-2023-2976" type="cve"></reference>
		</references>
		<description>CVE-2023-2976:Use of Java&#39;s default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.&#xA;Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="0" name="guava20" release="11.u1.fos23" version="20.0">
					<filename>guava20-20.0-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/guava20-20.0-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="guava20-help" release="11.u1.fos23" version="20.0">
					<filename>guava20-help-20.0-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/guava20-help-20.0-11.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2182</id>
		<title>An update for iperf3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38403" id="CVE-2023-38403" title="CVE-2023-38403" type="cve"></reference>
		</references>
		<description>CVE-2023-38403:iperf3 before 3.14 allows peers to cause an integer overflow and heap corruption via a crafted length field.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="iperf3" release="3.u1.fos23" version="3.10.1">
					<filename>iperf3-3.10.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/iperf3-3.10.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3-devel" release="3.u1.fos23" version="3.10.1">
					<filename>iperf3-devel-3.10.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/iperf3-devel-3.10.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="iperf3-help" release="3.u1.fos23" version="3.10.1">
					<filename>iperf3-help-3.10.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/iperf3-help-3.10.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3" release="3.u1.fos23" version="3.10.1">
					<filename>iperf3-3.10.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/iperf3-3.10.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3-devel" release="3.u1.fos23" version="3.10.1">
					<filename>iperf3-devel-3.10.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/iperf3-devel-3.10.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2183</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3117" id="CVE-2023-3117" title="CVE-2023-3117" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3390" id="CVE-2023-3390" title="CVE-2023-3390" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45886" id="CVE-2022-45886" title="CVE-2022-45886" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3338" id="CVE-2023-3338" title="CVE-2023-3338" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3220" id="CVE-2023-3220" title="CVE-2023-3220" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31248" id="CVE-2023-31248" title="CVE-2023-31248" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3567" id="CVE-2023-3567" title="CVE-2023-3567" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2163" id="CVE-2023-2163" title="CVE-2023-2163" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35001" id="CVE-2023-35001" title="CVE-2023-35001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32248" id="CVE-2023-32248" title="CVE-2023-32248" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32255" id="CVE-2023-32255" title="CVE-2023-32255" type="cve"></reference>
		</references>
		<description>CVE-2023-3117:A use-after-free flaw was found in the Netfilter subsystem of the Linux kernel when processing named and anonymous sets in batch requests, which can lead to performing arbitrary reads and writes in kernel memory. This flaw allows a local user with CAP_NET_ADMIN capability to crash or potentially escalate their privileges on the system.&#xA;CVE-2023-3390:A use-after-free vulnerability was found in the Linux kernel&#39;s netfilter subsystem in net/netfilter/nf_tables_api.c.&#xA;Mishandled error handling with NFT_MSG_NEWRULE makes it possible to use a dangling pointer in the same transaction causing a use-after-free vulnerability. This flaw allows a local attacker with user access to cause a privilege escalation issue.&#xA;We recommend upgrading past commit 1240eb93f0616b21c675416516ff3d74798fdc97.&#xA;CVE-2022-45886:An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_net.c has a .disconnect versus dvb_device_open race condition that leads to a use-after-free.&#xA;CVE-2023-3338:A null pointer dereference flaw was found in the Linux kernel&#39;s DECnet networking protocol. This issue could allow a remote user to crash the system.&#xA;CVE-2023-3220:An issue was discovered in the Linux kernel through 6.1-rc8. dpu_crtc_atomic_check in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c lacks check of the return value of kzalloc() and will cause the NULL Pointer Dereference.&#xA;CVE-2023-31248:Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace&#xA;CVE-2023-3567:A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This flaw allows an attacker with local user access to cause a system crash or leak internal kernel information.&#xA;CVE-2023-2163:bpf: incorrect verifier pruning due to missing register precision taints, which may lead to out-of-band read/write access due to an incorrect verifier conclusion.&#xA;CVE-2023-35001:Linux Kernel nftables Out-Of-Bounds Read/Write Vulnerability; nft_byteorder poorly handled vm register contents when CAP_NET_ADMIN is in any user or network namespace&#xA;CVE-2023-32248:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_TREE_CONNECT and SMB2_QUERY_INFO commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.&#xA;CVE-2023-32255:Linux Kernel ksmbd Session Setup Memory Leak Denial-of-Service Vulnerability</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-headers-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-tools-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-perf-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/bpftool-5.10.0-136.42.0.120.u69.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-headers-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-tools-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/kernel-tools-devel-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-perf-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.42.0.120.u69.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/bpftool-5.10.0-136.42.0.120.u69.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2184</id>
		<title>An update for libX11 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3138" id="CVE-2023-3138" title="CVE-2023-3138" type="cve"></reference>
		</references>
		<description>CVE-2023-3138:A vulnerability was found in libX11. The security flaw occurs because the functions in src/InitExt.c in libX11 do not check that the values provided for the Request, Event, or Error IDs are within the bounds of the arrays that those functions write to, using those IDs as array indexes. They trust that they were called with values provided by an Xserver adhering to the bounds specified in the X11 protocol, as all X servers provided by X.Org do. As the protocol only specifies a single byte for these values, an out-of-bounds value provided by a malicious server (or a malicious proxy-in-the-middle) can only overwrite other portions of the Display structure and not write outside the bounds of the Display structure itself, possibly causing the client to crash with this memory corruption.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="libX11" release="6.u1.fos23" version="1.7.2">
					<filename>libX11-1.7.2-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libX11-1.7.2-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libX11-devel" release="6.u1.fos23" version="1.7.2">
					<filename>libX11-devel-1.7.2-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libX11-devel-1.7.2-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libX11-help" release="6.u1.fos23" version="1.7.2">
					<filename>libX11-help-1.7.2-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libX11-help-1.7.2-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libX11" release="6.u1.fos23" version="1.7.2">
					<filename>libX11-1.7.2-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libX11-1.7.2-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libX11-devel" release="6.u1.fos23" version="1.7.2">
					<filename>libX11-devel-1.7.2-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libX11-devel-1.7.2-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2185</id>
		<title>An update for libqb is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39976" id="CVE-2023-39976" title="CVE-2023-39976" type="cve"></reference>
		</references>
		<description>CVE-2023-39976:log_blackbox.c in libqb before 2.0.8 allows a buffer overflow via long log messages because the header size is not considered.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="libqb" release="2.u1.fos23" version="2.0.0">
					<filename>libqb-2.0.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libqb-2.0.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libqb-devel" release="2.u1.fos23" version="2.0.0">
					<filename>libqb-devel-2.0.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libqb-devel-2.0.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libqb-help" release="2.u1.fos23" version="2.0.0">
					<filename>libqb-help-2.0.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libqb-help-2.0.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="doxygen2man" release="2.u1.fos23" version="2.0.0">
					<filename>doxygen2man-2.0.0-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/doxygen2man-2.0.0-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libqb" release="2.u1.fos23" version="2.0.0">
					<filename>libqb-2.0.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libqb-2.0.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libqb-devel" release="2.u1.fos23" version="2.0.0">
					<filename>libqb-devel-2.0.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libqb-devel-2.0.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="doxygen2man" release="2.u1.fos23" version="2.0.0">
					<filename>doxygen2man-2.0.0-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/doxygen2man-2.0.0-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2186</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38288" id="CVE-2023-38288" title="CVE-2023-38288" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38289" id="CVE-2023-38289" title="CVE-2023-38289" type="cve"></reference>
		</references>
		<description>CVE-2023-38288:Multiple potential integer overflow in raw2tiff.c in libtiff &lt;= 4.5.1 can allow remote attackers to cause a denial of service (application crash) or possibly execute an arbitrary code via a crafted tiff image which triggers a heap-based buffer overflow.&#xA;CVE-2023-38289:Multiple potential integer overflow in tiffcp.c in libtiff &lt;= 4.5.1 can allow remote attackers to cause a denial of service (application crash) or possibly execute an arbitrary code via a crafted tiff image which triggers a heap-based buffer overflow.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-30.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libtiff-4.3.0-30.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-30.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libtiff-devel-4.3.0-30.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-30.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libtiff-static-4.3.0-30.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-30.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libtiff-tools-4.3.0-30.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-30.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libtiff-help-4.3.0-30.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-30.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libtiff-4.3.0-30.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-30.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libtiff-devel-4.3.0-30.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-30.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libtiff-static-4.3.0-30.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="30.u6.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-30.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libtiff-tools-4.3.0-30.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2187</id>
		<title>An update for nghttp2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35945" id="CVE-2023-35945" title="CVE-2023-35945" type="cve"></reference>
		</references>
		<description>CVE-2023-35945:Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy’s HTTP/2 codec may leak a header map and bookkeeping structures upon receiving `RST_STREAM` immediately followed by the `GOAWAY` frames from an upstream server. In nghttp2, cleanup of pending requests due to receipt of the `GOAWAY` frame skips de-allocation of the bookkeeping structure and pending compressed header. The error return [code path] is taken if connection is already marked for not sending more requests due to `GOAWAY` frame. The clean-up code is right after the return statement, causing memory leak. Denial of service through memory exhaustion. This vulnerability was patched in versions(s) 1.26.3, 1.25.8, 1.24.9, 1.23.11.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="nghttp2" release="4.u2.fos23" version="1.46.0">
					<filename>nghttp2-1.46.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/nghttp2-1.46.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2" release="4.u2.fos23" version="1.46.0">
					<filename>libnghttp2-1.46.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libnghttp2-1.46.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2-devel" release="4.u2.fos23" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libnghttp2-devel-1.46.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nghttp2-help" release="4.u2.fos23" version="1.46.0">
					<filename>nghttp2-help-1.46.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/nghttp2-help-1.46.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nghttp2" release="4.u2.fos23" version="1.46.0">
					<filename>nghttp2-1.46.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/nghttp2-1.46.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2" release="4.u2.fos23" version="1.46.0">
					<filename>libnghttp2-1.46.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libnghttp2-1.46.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2-devel" release="4.u2.fos23" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libnghttp2-devel-1.46.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2188</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
		</references>
		<description>CVE-2023-0286:There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.</description>
		<pkglist>
			<collection>
				<name>23.0.2.3</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u2.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.3/openresty-openssl111-asan-1.1.1h-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u2.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.3/openresty-openssl111-asan-1.1.1h-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2189</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38408" id="CVE-2023-38408" title="CVE-2023-38408" type="cve"></reference>
		</references>
		<description>CVE-2023-38408:The PKCS#11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system. (Code in /usr/lib is not necessarily safe for loading into ssh-agent.) NOTE: this issue exists because of an incomplete fix for CVE-2016-10009.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="openssh" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-8.8p1-23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssh-8.8p1-23.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssh-clients-8.8p1-23.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssh-server-8.8p1-23.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssh-keycat-8.8p1-23.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssh-askpass-8.8p1-23.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.23.u12.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/pam_ssh_agent_auth-0.10.4-4.23.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-help-8.8p1-23.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssh-help-8.8p1-23.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-8.8p1-23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssh-8.8p1-23.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssh-clients-8.8p1-23.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssh-server-8.8p1-23.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssh-keycat-8.8p1-23.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="23.u12.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssh-askpass-8.8p1-23.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.23.u12.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/pam_ssh_agent_auth-0.10.4-4.23.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2190</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
		</references>
		<description>CVE-2023-3817:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. After fixing&#xA;CVE-2023-3446 it was discovered that a large q parameter value can also trigger&#xA;an overly long computation during some of these checks. A correct q value,&#xA;if present, cannot be larger than the modulus p parameter, thus it is&#xA;unnecessary to perform these checks if q is larger than p.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulnerable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#34;-check&#34; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2023-3446:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. One of those&#xA;checks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to use&#xA;a very large modulus is slow and OpenSSL will not normally use a modulus which&#xA;is over 10,000 bits in length.&#xA;However the DH_check() function checks numerous aspects of the key or parameters&#xA;that have been supplied. Some of those checks use the supplied modulus value&#xA;even if it has already been found to be too large.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulernable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#39;-check&#39; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="1" name="openssl" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-25.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssl-1.1.1m-25.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-25.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssl-libs-1.1.1m-25.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-25.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssl-perl-1.1.1m-25.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-25.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/openssl-devel-1.1.1m-25.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-25.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssl-help-1.1.1m-25.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-25.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssl-1.1.1m-25.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-25.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssl-libs-1.1.1m-25.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-25.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssl-perl-1.1.1m-25.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="25.u10.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-25.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/openssl-devel-1.1.1m-25.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2191</id>
		<title>An update for pcre2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41409" id="CVE-2022-41409" title="CVE-2022-41409" type="cve"></reference>
		</references>
		<description>CVE-2022-41409:Integer overflow vulnerability in pcre2test before 10.41 allows attackers to cause a denial of service or other unspecified impacts via negative input.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="pcre2" release="9.u3.fos23" version="10.39">
					<filename>pcre2-10.39-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/pcre2-10.39-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcre2-devel" release="9.u3.fos23" version="10.39">
					<filename>pcre2-devel-10.39-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/pcre2-devel-10.39-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pcre2-help" release="9.u3.fos23" version="10.39">
					<filename>pcre2-help-10.39-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/pcre2-help-10.39-9.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcre2" release="9.u3.fos23" version="10.39">
					<filename>pcre2-10.39-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/pcre2-10.39-9.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcre2-devel" release="9.u3.fos23" version="10.39">
					<filename>pcre2-devel-10.39-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/pcre2-devel-10.39-9.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2192</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31486" id="CVE-2023-31486" title="CVE-2023-31486" type="cve"></reference>
		</references>
		<description>CVE-2023-31486:HTTP::Tiny before 0.083, a Perl core module since 5.13.9 and available standalone on CPAN, has an insecure default TLS configuration where users must opt in to verify certificates.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="4" name="perl" release="8.u2.fos23" version="5.34.0">
					<filename>perl-5.34.0-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/perl-5.34.0-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-libs" release="8.u2.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/perl-libs-5.34.0-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-devel" release="8.u2.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/perl-devel-5.34.0-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="4" name="perl-help" release="8.u2.fos23" version="5.34.0">
					<filename>perl-help-5.34.0-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perl-help-5.34.0-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl" release="8.u2.fos23" version="5.34.0">
					<filename>perl-5.34.0-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perl-5.34.0-8.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-libs" release="8.u2.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perl-libs-5.34.0-8.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-devel" release="8.u2.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perl-devel-5.34.0-8.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2193</id>
		<title>An update for perl-CPAN is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31484" id="CVE-2023-31484" title="CVE-2023-31484" type="cve"></reference>
		</references>
		<description>CVE-2023-31484:CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="0" name="perl-CPAN" release="2.u1.fos23" version="2.29">
					<filename>perl-CPAN-2.29-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perl-CPAN-2.29-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-CPAN-help" release="2.u1.fos23" version="2.29">
					<filename>perl-CPAN-help-2.29-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/perl-CPAN-help-2.29-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2194</id>
		<title>An update for postgresql-jdbc is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41946" id="CVE-2022-41946" title="CVE-2022-41946" type="cve"></reference>
		</references>
		<description>CVE-2022-41946:pgjdbc is an open source postgresql JDBC Driver. In affected versions a prepared statement using either `PreparedStatement.setText(int, InputStream)` or `PreparedStatemet.setBytea(int, InputStream)` will create a temporary file if the InputStream is larger than 2k. This will create a temporary file which is readable by other users on Unix like systems, but not MacOS. On Unix like systems, the system&#39;s temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. Java 1.7 and higher users: this vulnerability is fixed in 4.5.0. Java 1.6 and lower users: no patch is available. If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will mitigate this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="0" name="postgresql-jdbc" release="2.u1.fos23" version="42.4.1">
					<filename>postgresql-jdbc-42.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/postgresql-jdbc-42.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-jdbc-javadoc" release="2.u1.fos23" version="42.4.1">
					<filename>postgresql-jdbc-javadoc-42.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/postgresql-jdbc-javadoc-42.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-jdbc-help" release="2.u1.fos23" version="42.4.1">
					<filename>postgresql-jdbc-help-42.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/postgresql-jdbc-help-42.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2195</id>
		<title>An update for procps-ng is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4016" id="CVE-2023-4016" title="CVE-2023-4016" type="cve"></reference>
		</references>
		<description>CVE-2023-4016:Under some circumstances, this weakness allows a user who has access to run the “ps” utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="procps-ng" release="10.u6.fos23" version="4.0.2">
					<filename>procps-ng-4.0.2-10.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/procps-ng-4.0.2-10.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="procps-ng-devel" release="10.u6.fos23" version="4.0.2">
					<filename>procps-ng-devel-4.0.2-10.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/procps-ng-devel-4.0.2-10.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="procps-ng-i18n" release="10.u6.fos23" version="4.0.2">
					<filename>procps-ng-i18n-4.0.2-10.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/procps-ng-i18n-4.0.2-10.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="procps-ng-help" release="10.u6.fos23" version="4.0.2">
					<filename>procps-ng-help-4.0.2-10.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/procps-ng-help-4.0.2-10.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="procps-ng" release="10.u6.fos23" version="4.0.2">
					<filename>procps-ng-4.0.2-10.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/procps-ng-4.0.2-10.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="procps-ng-devel" release="10.u6.fos23" version="4.0.2">
					<filename>procps-ng-devel-4.0.2-10.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/procps-ng-devel-4.0.2-10.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2196</id>
		<title>An update for python-certifi is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37920" id="CVE-2023-37920" title="CVE-2023-37920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23491" id="CVE-2022-23491" title="CVE-2022-23491" type="cve"></reference>
		</references>
		<description>CVE-2023-37920:Certifi is a curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. Certifi prior to version 2023.07.22 recognizes &#34;e-Tugra&#34; root certificates. e-Tugra&#39;s root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from &#34;e-Tugra&#34; from the root store.&#xA;CVE-2022-23491:Certifi is a curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. Certifi 2022.12.07 removes root certificates from &#34;TrustCor&#34; from the root store. These are in the process of being removed from Mozilla&#39;s trust store. TrustCor&#39;s root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor&#39;s ownership also operated a business that produced spyware. Conclusions of Mozilla&#39;s investigation can be found in the linked google group discussion.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="0" name="python3-certifi" release="1.fos23" version="2023.7.22">
					<filename>python3-certifi-2023.7.22-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-certifi-2023.7.22-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-certifi-help" release="1.fos23" version="2023.7.22">
					<filename>python-certifi-help-2023.7.22-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python-certifi-help-2023.7.22-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2197</id>
		<title>An update for python-pygments is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40896" id="CVE-2022-40896" title="CVE-2022-40896" type="cve"></reference>
		</references>
		<description>CVE-2022-40896:A ReDoS issue was discovered in pygments/lexers/smithy.py in pygments through 2.15.0 via SmithyLexer.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="0" name="python3-pygments" release="4.u1.fos23" version="2.10.0">
					<filename>python3-pygments-2.10.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-pygments-2.10.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pygments-help" release="4.u1.fos23" version="2.10.0">
					<filename>python-pygments-help-2.10.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python-pygments-help-2.10.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2198</id>
		<title>An update for python-tornado is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28370" id="CVE-2023-28370" title="CVE-2023-28370" type="cve"></reference>
		</references>
		<description>CVE-2023-28370:Open redirect vulnerability in Tornado versions 6.3.1 and earlier allows a remote unauthenticated attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having user access a specially crafted URL.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="python3-tornado" release="2.u1.fos23" version="6.1">
					<filename>python3-tornado-6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-tornado-6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python-tornado-help" release="2.u1.fos23" version="6.1">
					<filename>python-tornado-help-6.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python-tornado-help-6.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-tornado" release="2.u1.fos23" version="6.1">
					<filename>python3-tornado-6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-tornado-6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python-tornado-help" release="2.u1.fos23" version="6.1">
					<filename>python-tornado-help-6.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python-tornado-help-6.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2199</id>
		<title>An update for python-werkzeug is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23934" id="CVE-2023-23934" title="CVE-2023-23934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25577" id="CVE-2023-25577" title="CVE-2023-25577" type="cve"></reference>
		</references>
		<description>CVE-2023-23934:Werkzeug is a comprehensive WSGI web application library. Browsers may allow &#34;nameless&#34; cookies that look like `=value` instead of `key=value`. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like `=__Host-test=bad` for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie `=__Host-test=bad` as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.&#xA;CVE-2023-25577:Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug&#39;s multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses `request.data`, `request.form`, `request.files`, or `request.get_data(parse_form_data=False)`, it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="0" name="python3-werkzeug" release="4.u2.fos23" version="2.0.3">
					<filename>python3-werkzeug-2.0.3-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-werkzeug-2.0.3-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-werkzeug-help" release="4.u2.fos23" version="2.0.3">
					<filename>python-werkzeug-help-2.0.3-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python-werkzeug-help-2.0.3-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2200</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2007-4559" id="CVE-2007-4559" title="CVE-2007-4559" type="cve"></reference>
		</references>
		<description>CVE-2007-4559:Directory traversal vulnerability in the (1) extract and (2) extractall functions in the tarfile module in Python allows user-assisted remote attackers to overwrite arbitrary files via a .. (dot dot) sequence in filenames in a TAR archive, a related issue to CVE-2001-1267.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="python3" release="25.u6.fos23" version="3.9.9">
					<filename>python3-3.9.9-25.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-3.9.9-25.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="25.u6.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-25.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-unversioned-command-3.9.9-25.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="25.u6.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-25.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-devel-3.9.9-25.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="25.u6.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-25.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-debug-3.9.9-25.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="25.u6.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-25.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-help-3.9.9-25.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="25.u6.fos23" version="3.9.9">
					<filename>python3-3.9.9-25.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-3.9.9-25.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="25.u6.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-25.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-unversioned-command-3.9.9-25.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="25.u6.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-25.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-devel-3.9.9-25.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="25.u6.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-25.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-debug-3.9.9-25.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2201</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0664" id="CVE-2023-0664" title="CVE-2023-0664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2861" id="CVE-2023-2861" title="CVE-2023-2861" type="cve"></reference>
		</references>
		<description>CVE-2023-0664:A flaw was found in the QEMU Guest Agent service for Windows. A local unprivileged user may be able to manipulate the QEMU Guest Agent&#39;s Windows installer via repair custom actions to elevate their privileges on the system.&#xA;CVE-2023-2861:A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. The 9pfs server did not prohibit opening special files on the host side, potentially allowing a malicious client to escape from the exported 9p tree by creating and opening a device file in the shared folder.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="10" name="qemu" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-guest-agent-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-76.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-help-6.2.0-76.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-img-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-block-rbd-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-block-ssh-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-block-iscsi-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-block-curl-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-hw-usb-host-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-seabios-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-system-aarch64-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-system-arm-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-system-x86_64-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-76.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/qemu-system-riscv-6.2.0-76.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-guest-agent-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-img-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-block-rbd-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-block-ssh-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-block-iscsi-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-block-curl-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-hw-usb-host-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-system-aarch64-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-system-arm-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-system-x86_64-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="76.u4.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-76.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/qemu-system-riscv-6.2.0-76.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2202</id>
		<title>An update for rubygem-actionpack is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28362" id="CVE-2023-28362" title="CVE-2023-28362" type="cve"></reference>
		</references>
		<description>CVE-2023-28362:A Cross-site Scripting (XSS) vulnerability was found in Actionpack due to improper sanitization of user-supplied values. This allows provided values to contain characters that are not legal in an HTTP header value. This results in the potential for downstream services which enforce RFC compliance on HTTP response headers to remove the assigned location header.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="noarch" epoch="1" name="rubygem-actionpack" release="3.u1.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-6.1.4.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/rubygem-actionpack-6.1.4.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-actionpack-doc" release="3.u1.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-doc-6.1.4.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/rubygem-actionpack-doc-6.1.4.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2203</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2127" id="CVE-2022-2127" title="CVE-2022-2127" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3347" id="CVE-2023-3347" title="CVE-2023-3347" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34966" id="CVE-2023-34966" title="CVE-2023-34966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34967" id="CVE-2023-34967" title="CVE-2023-34967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34968" id="CVE-2023-34968" title="CVE-2023-34968" type="cve"></reference>
		</references>
		<description>CVE-2022-2127:An out-of-bounds read vulnerability was found in Samba due to insufficient length checks in winbindd_pam_auth_crap.c. When performing NTLM authentication, the client replies to cryptographic challenges back to the server. These replies have variable lengths, and Winbind fails to check the lan manager response length. When Winbind is used for NTLM authentication, a maliciously crafted request can trigger an out-of-bounds read in Winbind, possibly resulting in a crash.&#xA;CVE-2023-3347:A vulnerability was found in Samba&#39;s SMB2 packet signing mechanism. The SMB2 packet signing is not enforced if an admin configured &#34;server signing = required&#34; or for SMB2 connections to Domain Controllers where SMB2 packet signing is mandatory. This flaw allows an attacker to perform attacks, such as a man-in-the-middle attack, by intercepting the network traffic and modifying the SMB2 messages between client and server, affecting the integrity of the data.&#xA;CVE-2023-34966:An infinite loop vulnerability was found in Samba&#39;s mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets sent by the client, the core unmarshalling function sl_unpack_loop() did not validate a field in the network packet that contains the count of elements in an array-like structure. By passing 0 as the count value, the attacked function will run in an endless loop consuming 100% CPU. This flaw allows an attacker to issue a malformed RPC request, triggering an infinite loop, resulting in a denial of service condition.&#xA;CVE-2023-34967:A Type Confusion vulnerability was found in Samba&#39;s mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets, one encoded data structure is a key-value style dictionary where the keys are character strings, and the values can be any of the supported types in the mdssvc protocol. Due to a lack of type checking in callers of the dalloc_value_for_key() function, which returns the object associated with a key, a caller may trigger a crash in talloc_get_size() when talloc detects that the passed-in pointer is not a valid talloc pointer. With an RPC worker process shared among multiple client connections, a malicious client or attacker can trigger a process crash in a shared RPC mdssvc worker process, affecting all other clients this worker serves.&#xA;CVE-2023-34968:A path disclosure vulnerability was found in Samba. As part of the Spotlight protocol, Samba discloses the server-side absolute path of shares, files, and directories in the results for search queries. This flaw allows a malicious client or an attacker with a targeted RPC request to view the information that is part of the disclosed path.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="samba" release="6.u3.fos23" version="4.17.5">
					<filename>samba-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-libs" release="6.u3.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-libs-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client" release="6.u3.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-client-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common" release="6.u3.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-common-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common-tools" release="6.u3.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-common-tools-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc" release="6.u3.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-dc-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-provision" release="6.u3.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-dc-provision-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-bind-dlz" release="6.u3.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-dc-bind-dlz-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-devel" release="6.u3.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-devel-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-vfs-glusterfs" release="6.u3.fos23" version="4.17.5">
					<filename>samba-vfs-glusterfs-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-vfs-glusterfs-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-krb5-printing" release="6.u3.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-krb5-printing-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient" release="6.u3.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libsmbclient-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient-devel" release="6.u3.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libsmbclient-devel-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient" release="6.u3.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libwbclient-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient-devel" release="6.u3.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/libwbclient-devel-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba" release="6.u3.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-samba-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-test" release="6.u3.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-samba-test-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-dc" release="6.u3.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-samba-dc-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="samba-pidl" release="6.u3.fos23" version="4.17.5">
					<filename>samba-pidl-4.17.5-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-pidl-4.17.5-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-test" release="6.u3.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-test-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-usershares" release="6.u3.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-usershares-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-winbind-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-clients" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-winbind-clients-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-krb5-locator" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-winbind-krb5-locator-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-modules" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-winbind-modules-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ctdb" release="6.u3.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/ctdb-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-help" release="6.u3.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/samba-help-4.17.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba" release="6.u3.fos23" version="4.17.5">
					<filename>samba-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-libs" release="6.u3.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-libs-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client" release="6.u3.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-client-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common" release="6.u3.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-common-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common-tools" release="6.u3.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-common-tools-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc" release="6.u3.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-dc-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-provision" release="6.u3.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-dc-provision-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-bind-dlz" release="6.u3.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-dc-bind-dlz-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-devel" release="6.u3.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-devel-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-krb5-printing" release="6.u3.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-krb5-printing-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient" release="6.u3.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libsmbclient-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient-devel" release="6.u3.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libsmbclient-devel-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient" release="6.u3.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libwbclient-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient-devel" release="6.u3.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/libwbclient-devel-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba" release="6.u3.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-samba-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-test" release="6.u3.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-samba-test-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-dc" release="6.u3.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-samba-dc-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-test" release="6.u3.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-test-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-usershares" release="6.u3.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-usershares-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-winbind-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-clients" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-winbind-clients-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-krb5-locator" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-winbind-krb5-locator-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-modules" release="6.u3.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-winbind-modules-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctdb" release="6.u3.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/ctdb-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-help" release="6.u3.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/samba-help-4.17.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2204</id>
		<title>An update for scipy is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25399" id="CVE-2023-25399" title="CVE-2023-25399" type="cve"></reference>
		</references>
		<description>CVE-2023-25399:A refcounting issue which leads to potential memory leak was discovered in scipy commit 8627df31ab in Py_FindObjects() function.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="python3-scipy" release="2.u1.fos23" version="1.6.2">
					<filename>python3-scipy-1.6.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/python3-scipy-1.6.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-scipy" release="2.u1.fos23" version="1.6.2">
					<filename>python3-scipy-1.6.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/python3-scipy-1.6.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2205</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-0737" id="CVE-2018-0737" title="CVE-2018-0737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23840" id="CVE-2021-23840" title="CVE-2021-23840" type="cve"></reference>
		</references>
		<description>CVE-2018-0737:The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a cache timing side channel attack. An attacker with sufficient access to mount cache timing attacks during the RSA key generation process could recover the private key.&#xA;CVE-2021-23840:Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="shim" release="10.u7.fos23" version="15.6">
					<filename>shim-15.6-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/shim-15.6-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="10.u7.fos23" version="15.6">
					<filename>shim-15.6-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/shim-15.6-10.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2206</id>
		<title>An update for sqlite is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36191" id="CVE-2023-36191" title="CVE-2023-36191" type="cve"></reference>
		</references>
		<description>CVE-2023-36191:sqlite3 v3.40.1 was discovered to contain a segmentation violation at /sqlite3_aflpp/shell.c.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="sqlite" release="6.u3.fos23" version="3.37.2">
					<filename>sqlite-3.37.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/sqlite-3.37.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sqlite-devel" release="6.u3.fos23" version="3.37.2">
					<filename>sqlite-devel-3.37.2-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/sqlite-devel-3.37.2-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sqlite-help" release="6.u3.fos23" version="3.37.2">
					<filename>sqlite-help-3.37.2-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/sqlite-help-3.37.2-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite" release="6.u3.fos23" version="3.37.2">
					<filename>sqlite-3.37.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/sqlite-3.37.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite-devel" release="6.u3.fos23" version="3.37.2">
					<filename>sqlite-devel-3.37.2-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/sqlite-devel-3.37.2-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2207</id>
		<title>An update for syslinux is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9840" id="CVE-2016-9840" title="CVE-2016-9840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9841" id="CVE-2016-9841" title="CVE-2016-9841" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9842" id="CVE-2016-9842" title="CVE-2016-9842" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9843" id="CVE-2016-9843" title="CVE-2016-9843" type="cve"></reference>
		</references>
		<description>CVE-2016-9840:inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.&#xA;CVE-2016-9841:inffast.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.&#xA;CVE-2016-9842:The inflateMark function in inflate.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving left shifts of negative integers.&#xA;CVE-2016-9843:The crc32_big function in crc32.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving big-endian CRC calculation.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="syslinux" release="14.u2.fos23" version="6.04">
					<filename>syslinux-6.04-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-6.04-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-perl" release="14.u2.fos23" version="6.04">
					<filename>syslinux-perl-6.04-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-perl-6.04-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-devel" release="14.u2.fos23" version="6.04">
					<filename>syslinux-devel-6.04-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-devel-6.04-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-extlinux" release="14.u2.fos23" version="6.04">
					<filename>syslinux-extlinux-6.04-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-extlinux-6.04-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-tftpboot" release="14.u2.fos23" version="6.04">
					<filename>syslinux-tftpboot-6.04-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-tftpboot-6.04-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-extlinux-nonlinux" release="14.u2.fos23" version="6.04">
					<filename>syslinux-extlinux-nonlinux-6.04-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-extlinux-nonlinux-6.04-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-nonlinux" release="14.u2.fos23" version="6.04">
					<filename>syslinux-nonlinux-6.04-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-nonlinux-6.04-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-efi64" release="14.u2.fos23" version="6.04">
					<filename>syslinux-efi64-6.04-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/syslinux-efi64-6.04-14.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2208</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3648" id="CVE-2023-3648" title="CVE-2023-3648" type="cve"></reference>
		</references>
		<description>CVE-2023-3648:Kafka dissector crash in Wireshark 4.0.0 to 4.0.6 and 3.6.0 to 3.6.14 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="2.u5.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/wireshark-3.6.14-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="2.u5.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/wireshark-devel-3.6.14-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="2.u5.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/wireshark-help-3.6.14-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="2.u5.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/wireshark-3.6.14-2.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="2.u5.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/wireshark-devel-3.6.14-2.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="2.u5.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/wireshark-help-3.6.14-2.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2209</id>
		<title>An update for yasm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-08-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37732" id="CVE-2023-37732" title="CVE-2023-37732" type="cve"></reference>
		</references>
		<description>CVE-2023-37732:Yasm v1.3.0.78 was found prone to NULL Pointer Dereference in /libyasm/intnum.c and /elf/elf.c, which allows the attacker to cause a denial of service via a crafted file.</description>
		<pkglist>
			<collection>
				<name>23.0.2.5</name>
				<package arch="x86_64" epoch="0" name="yasm" release="11.u2.fos23" version="1.3.0">
					<filename>yasm-1.3.0-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.5/yasm-1.3.0-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yasm" release="11.u2.fos23" version="1.3.0">
					<filename>yasm-1.3.0-11.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.5/yasm-1.3.0-11.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2210</id>
		<title>An update for amanda is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30577" id="CVE-2023-30577" title="CVE-2023-30577" type="cve"></reference>
		</references>
		<description>CVE-2023-30577:AMANDA (Advanced Maryland Automatic Network Disk Archiver) before tag-community-3.5.4 mishandles argument checking for runtar.c, a different vulnerability than CVE-2022-37705.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="amanda" release="1.u2.fos23" version="3.5.4">
					<filename>amanda-3.5.4-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/amanda-3.5.4-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="amanda-help" release="1.u2.fos23" version="3.5.4">
					<filename>amanda-help-3.5.4-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/amanda-help-3.5.4-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="amanda" release="1.u2.fos23" version="3.5.4">
					<filename>amanda-3.5.4-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/amanda-3.5.4-1.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2211</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46174" id="CVE-2021-46174" title="CVE-2021-46174" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1972" id="CVE-2023-1972" title="CVE-2023-1972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48064" id="CVE-2022-48064" title="CVE-2022-48064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4285" id="CVE-2022-4285" title="CVE-2022-4285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47696" id="CVE-2022-47696" title="CVE-2022-47696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47011" id="CVE-2022-47011" title="CVE-2022-47011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47008" id="CVE-2022-47008" title="CVE-2022-47008" type="cve"></reference>
		</references>
		<description>CVE-2021-46174:Heap-based Buffer Overflow in function bfd_getl32 in Binutils objdump 3.37.&#xA;CVE-2023-1972:A potential heap based buffer overflow was found in _bfd_elf_slurp_version_tables() in bfd/elf.c. This may lead to loss of availability.&#xA;CVE-2022-48064:GNU Binutils before 2.40 was discovered to contain an excessive memory consumption vulnerability via the function bfd_dwarf2_find_nearest_line_with_alt at dwarf2.c. The attacker could supply a crafted ELF file and cause a DNS attack.&#xA;CVE-2022-4285:An illegal memory access flaw was found in the binutils package. Parsing an ELF file containing corrupt symbol version information may result in a denial of service. This issue is the result of an incomplete fix for CVE-2020-16599.&#xA;CVE-2022-47696:An issue was discovered Binutils objdump before 2.39.3 allows attackers to cause a denial of service or other unspecified impacts via function compare_symbols.&#xA;CVE-2022-47011:An issue was discovered function parse_stab_struct_fields in stabs.c in Binutils 2.34 thru 2.38, allows attackers to cause a denial of service due to memory leaks.&#xA;CVE-2022-47008:An issue was discovered function make_tempdir, and make_tempname in bucomm.c in Binutils 2.34 thru 2.38, allows attackers to cause a denial of service due to memory leaks.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="binutils" release="22.u6.fos23" version="2.37">
					<filename>binutils-2.37-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/binutils-2.37-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="22.u6.fos23" version="2.37">
					<filename>binutils-devel-2.37-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/binutils-devel-2.37-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="22.u6.fos23" version="2.37">
					<filename>binutils-help-2.37-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/binutils-help-2.37-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="22.u6.fos23" version="2.37">
					<filename>binutils-2.37-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/binutils-2.37-22.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="22.u6.fos23" version="2.37">
					<filename>binutils-devel-2.37-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/binutils-devel-2.37-22.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="22.u6.fos23" version="2.37">
					<filename>binutils-help-2.37-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/binutils-help-2.37-22.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2212</id>
		<title>An update for cpio is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-1197" id="CVE-2015-1197" title="CVE-2015-1197" type="cve"></reference>
		</references>
		<description>CVE-2015-1197:cpio 2.11, when using the --no-absolute-filenames option, allows local users to write to arbitrary files via a symlink attack on a file in an archive.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="cpio" release="10.u2.fos23" version="2.13">
					<filename>cpio-2.13-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/cpio-2.13-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cpio-help" release="10.u2.fos23" version="2.13">
					<filename>cpio-help-2.13-10.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/cpio-help-2.13-10.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cpio" release="10.u2.fos23" version="2.13">
					<filename>cpio-2.13-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/cpio-2.13-10.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2213</id>
		<title>An update for file is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48554" id="CVE-2022-48554" title="CVE-2022-48554" type="cve"></reference>
		</references>
		<description>CVE-2022-48554:File before 5.43 has an stack-based buffer over-read in file_copystr in funcs.c. NOTE: &#34;File&#34; is the name of an Open Source project.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="file" release="3.u1.fos23" version="5.41">
					<filename>file-5.41-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/file-5.41-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="file-libs" release="3.u1.fos23" version="5.41">
					<filename>file-libs-5.41-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/file-libs-5.41-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="file-devel" release="3.u1.fos23" version="5.41">
					<filename>file-devel-5.41-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/file-devel-5.41-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="file-help" release="3.u1.fos23" version="5.41">
					<filename>file-help-5.41-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/file-help-5.41-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-magic" release="3.u1.fos23" version="5.41">
					<filename>python3-magic-5.41-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/python3-magic-5.41-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="file" release="3.u1.fos23" version="5.41">
					<filename>file-5.41-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/file-5.41-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="file-libs" release="3.u1.fos23" version="5.41">
					<filename>file-libs-5.41-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/file-libs-5.41-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="file-devel" release="3.u1.fos23" version="5.41">
					<filename>file-devel-5.41-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/file-devel-5.41-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="file-help" release="3.u1.fos23" version="5.41">
					<filename>file-help-5.41-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/file-help-5.41-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2214</id>
		<title>An update for flac is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22219" id="CVE-2020-22219" title="CVE-2020-22219" type="cve"></reference>
		</references>
		<description>CVE-2020-22219:Buffer Overflow vulnerability in function bitwriter_grow_ in flac before 1.4.0 allows remote attackers to run arbitrary code via crafted input to the encoder.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="flac" release="2.u1.fos23" version="1.3.4">
					<filename>flac-1.3.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/flac-1.3.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="flac-devel" release="2.u1.fos23" version="1.3.4">
					<filename>flac-devel-1.3.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/flac-devel-1.3.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xmms-flac" release="2.u1.fos23" version="1.3.4">
					<filename>xmms-flac-1.3.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/xmms-flac-1.3.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="flac-help" release="2.u1.fos23" version="1.3.4">
					<filename>flac-help-1.3.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/flac-help-1.3.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flac" release="2.u1.fos23" version="1.3.4">
					<filename>flac-1.3.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/flac-1.3.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flac-devel" release="2.u1.fos23" version="1.3.4">
					<filename>flac-devel-1.3.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/flac-devel-1.3.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xmms-flac" release="2.u1.fos23" version="1.3.4">
					<filename>xmms-flac-1.3.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/xmms-flac-1.3.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flac-help" release="2.u1.fos23" version="1.3.4">
					<filename>flac-help-1.3.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/flac-help-1.3.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2215</id>
		<title>An update for gawk is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4156" id="CVE-2023-4156" title="CVE-2023-4156" type="cve"></reference>
		</references>
		<description>CVE-2023-4156:A heap out of bound read issue exists in builtin.c of gawk prior to version 5.1.1. The array the_args takes an unsafe index val , while it does not validate the index to ensure the index refers to a valid position in the array (e.g., exceedingly large or negative). The vulnerability can cause crash of the software and might be used by attackers to read sensitive information.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="gawk" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-5.1.1-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gawk-5.1.1-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gawk-devel" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-devel-5.1.1-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gawk-devel-5.1.1-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gawk-help" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-help-5.1.1-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gawk-help-5.1.1-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gawk-lang" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-lang-5.1.1-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gawk-lang-5.1.1-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gawk" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-5.1.1-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gawk-5.1.1-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gawk-devel" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-devel-5.1.1-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gawk-devel-5.1.1-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gawk-lang" release="5.u2.fos23" version="5.1.1">
					<filename>gawk-lang-5.1.1-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gawk-lang-5.1.1-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2216</id>
		<title>An update for gdb is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39128" id="CVE-2023-39128" title="CVE-2023-39128" type="cve"></reference>
		</references>
		<description>CVE-2023-39128:GNU gdb (GDB) 13.0.50.20220805-git was discovered to contain a stack overflow via the function ada_decode at /gdb/ada-lang.c.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="gdb" release="6.u2.fos23" version="11.1">
					<filename>gdb-11.1-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gdb-11.1-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-headless" release="6.u2.fos23" version="11.1">
					<filename>gdb-headless-11.1-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gdb-headless-11.1-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-gdbserver" release="6.u2.fos23" version="11.1">
					<filename>gdb-gdbserver-11.1-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gdb-gdbserver-11.1-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdb-help" release="6.u2.fos23" version="11.1">
					<filename>gdb-help-11.1-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gdb-help-11.1-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb" release="6.u2.fos23" version="11.1">
					<filename>gdb-11.1-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gdb-11.1-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-headless" release="6.u2.fos23" version="11.1">
					<filename>gdb-headless-11.1-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gdb-headless-11.1-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-gdbserver" release="6.u2.fos23" version="11.1">
					<filename>gdb-gdbserver-11.1-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gdb-gdbserver-11.1-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2217</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38559" id="CVE-2023-38559" title="CVE-2023-38559" type="cve"></reference>
		</references>
		<description>CVE-2023-38559:A buffer overflow flaw was found in base/gdevdevn.c:1973 in devn_pcx_write_rle() in ghostscript. This issue may allow a local attacker to cause a denial of service via outputting a crafted PDF file for a DEVN device with gs.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/ghostscript-9.55.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/ghostscript-devel-9.55.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/ghostscript-help-9.55.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/ghostscript-tools-dvipdf-9.55.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/ghostscript-9.55.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/ghostscript-devel-9.55.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="3.u2.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/ghostscript-tools-dvipdf-9.55.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2218</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29406" id="CVE-2023-29406" title="CVE-2023-29406" type="cve"></reference>
		</references>
		<description>CVE-2023-29406:The HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host header can inject additional headers or entire requests. With fix, the HTTP/1 client now refuses to send requests containing an invalid Request.Host or</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u5.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/golang-1.20.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u5.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/golang-help-1.20.5-3.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u5.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/golang-devel-1.20.5-3.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u5.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/golang-1.20.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2219</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40225" id="CVE-2023-40225" title="CVE-2023-40225" type="cve"></reference>
		</references>
		<description>CVE-2023-40225:HAProxy through 2.0.32, 2.1.x and 2.2.x through 2.2.30, 2.3.x and 2.4.x through 2.4.23, 2.5.x and 2.6.x before 2.6.15, 2.7.x before 2.7.10, and 2.8.x before 2.8.2 forwards empty Content-Length headers, violating RFC 9110 section 8.6. In uncommon cases, an HTTP/1 server behind HAProxy may interpret the payload as an extra request.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="4.u3.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/haproxy-2.6.6-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="4.u3.fos23" version="2.6.6">
					<filename>haproxy-help-2.6.6-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/haproxy-help-2.6.6-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="4.u3.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/haproxy-2.6.6-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2220</id>
		<title>An update for hwloc is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47022" id="CVE-2022-47022" title="CVE-2022-47022" type="cve"></reference>
		</references>
		<description>CVE-2022-47022:An issue was discovered in open-mpi hwloc 2.1.0 allows attackers to cause a denial of service or other unspecified impacts via glibc-cpuset in topology-linux.c.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="hwloc" release="2.u1.fos23" version="2.7.1">
					<filename>hwloc-2.7.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/hwloc-2.7.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hwloc-devel" release="2.u1.fos23" version="2.7.1">
					<filename>hwloc-devel-2.7.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/hwloc-devel-2.7.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hwloc-help" release="2.u1.fos23" version="2.7.1">
					<filename>hwloc-help-2.7.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/hwloc-help-2.7.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hwloc" release="2.u1.fos23" version="2.7.1">
					<filename>hwloc-2.7.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/hwloc-2.7.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hwloc-devel" release="2.u1.fos23" version="2.7.1">
					<filename>hwloc-devel-2.7.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/hwloc-devel-2.7.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hwloc-help" release="2.u1.fos23" version="2.7.1">
					<filename>hwloc-help-2.7.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/hwloc-help-2.7.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2221</id>
		<title>An update for indent is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40305" id="CVE-2023-40305" title="CVE-2023-40305" type="cve"></reference>
		</references>
		<description>CVE-2023-40305:GNU indent 2.2.13 has a heap-based buffer overflow in search_brace in indent.c via a crafted file.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="indent" release="29.u1.fos23" version="2.2.11">
					<filename>indent-2.2.11-29.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/indent-2.2.11-29.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="indent-help" release="29.u1.fos23" version="2.2.11">
					<filename>indent-help-2.2.11-29.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/indent-help-2.2.11-29.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="indent" release="29.u1.fos23" version="2.2.11">
					<filename>indent-2.2.11-29.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/indent-2.2.11-29.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2222</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20593" id="CVE-2023-20593" title="CVE-2023-20593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4128" id="CVE-2023-4128" title="CVE-2023-4128" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4133" id="CVE-2023-4133" title="CVE-2023-4133" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4134" id="CVE-2023-4134" title="CVE-2023-4134" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4132" id="CVE-2023-4132" title="CVE-2023-4132" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3867" id="CVE-2023-3867" title="CVE-2023-3867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4147" id="CVE-2023-4147" title="CVE-2023-4147" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3772" id="CVE-2023-3772" title="CVE-2023-3772" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3863" id="CVE-2023-3863" title="CVE-2023-3863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3611" id="CVE-2023-3611" title="CVE-2023-3611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38426" id="CVE-2023-38426" title="CVE-2023-38426" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3609" id="CVE-2023-3609" title="CVE-2023-3609" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21255" id="CVE-2023-21255" title="CVE-2023-21255" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38428" id="CVE-2023-38428" title="CVE-2023-38428" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3776" id="CVE-2023-3776" title="CVE-2023-3776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4004" id="CVE-2023-4004" title="CVE-2023-4004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38427" id="CVE-2023-38427" title="CVE-2023-38427" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38429" id="CVE-2023-38429" title="CVE-2023-38429" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38430" id="CVE-2023-38430" title="CVE-2023-38430" type="cve"></reference>
		</references>
		<description>CVE-2023-20593:An issue in “Zen 2” CPUs, under specific microarchitectural circumstances, may allow an attacker to potentially access sensitive information.&#xA;CVE-2023-4128:A use-after-free flaw was found in net/sched/cls_fw.c in classifiers (cls_fw, cls_u32, and cls_route) in the Linux Kernel. This flaw allows a local attacker to perform a local privilege escalation due to incorrect handling of the existing filter, leading to a kernel information leak issue.&#xA;CVE-2023-4133:A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition.&#xA;CVE-2023-4134:A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service.&#xA;CVE-2023-4132:A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition.&#xA;CVE-2023-3867:A vulnerability was found in Linux Kernel (Operating System) (the affected version is unknown). It has been rated as critical. Affected by this issue is an unknown code of the file fs/smb/server/smb2pdu.c of the component ksmbd. The manipulation with an unknown input leads to a out-of-bounds vulnerability.&#xA;CVE-2023-4147:A use-after-free flaw was found in the Linux kernel’s Netfilter functionality when adding a rule with NFTA_RULE_CHAIN_ID. This flaw allows a local user to crash or escalate their privileges on the system.&#xA;CVE-2023-3772:A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service.&#xA;CVE-2023-3863:A use-after-free flaw was found in nfc_llcp_find_local in net/nfc/llcp_core.c in NFC in the Linux kernel. This flaw allows a local user with special privileges to impact a kernel information leak issue.&#xA;CVE-2023-3611:An out-of-bounds write vulnerability in the Linux kernel&#39;s net/sched: sch_qfq component can be exploited to achieve local privilege escalation.&#xA;The qfq_change_agg() function in net/sched/sch_qfq.c allows an out-of-bounds write because lmax is updated according to packet sizes without bounds checks.&#xA;We recommend upgrading past commit 3e337087c3b5805fe0b8a46ba622a962880b5d64.&#xA;CVE-2023-38426:An issue was discovered in the Linux kernel before 6.3.4. ksmbd has an out-of-bounds read in smb2_find_context_vals when create_context&#39;s name_len is larger than the tag length.&#xA;CVE-2023-3609:A use-after-free vulnerability in the Linux kernel&#39;s net/sched: cls_u32 component can be exploited to achieve local privilege escalation.&#xA;If tcf_change_indev() fails, u32_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.&#xA;We recommend upgrading past commit 04c55383fa5689357bcdd2c8036725a55ed632bc.&#xA;CVE-2023-21255:In multiple functions of binder.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.&#xA;CVE-2023-38428:An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/smb2pdu.c in ksmbd does not properly check the UserName value because it does not consider the address of security buffer, leading to an out-of-bounds read.&#xA;CVE-2023-3776:A use-after-free vulnerability in the Linux kernel&#39;s net/sched: cls_fw component can be exploited to achieve local privilege escalation.&#xA;If tcf_change_indev() fails, fw_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.&#xA;We recommend upgrading past commit 0323bce598eea038714f941ce2b22541c46d488f.&#xA;CVE-2023-4004:A use-after-free flaw was found in the Linux kernel&#39;s netfilter in the way a user triggers the nft_pipapo_remove function with the element, without a NFT_SET_EXT_KEY_END. This issue could allow a local user to crash the system or potentially escalate their privileges on the system.&#xA;CVE-2023-38427:An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/smb2pdu.c in ksmbd has an integer underflow and out-of-bounds read in deassemble_neg_contexts.&#xA;CVE-2023-38429:An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/connection.c in ksmbd has an off-by-one error in memory allocation (because of ksmbd_smb2_check_message) that may lead to out-of-bounds access.&#xA;CVE-2023-38430:An issue was discovered in the Linux kernel before 6.3.9. ksmbd does not validate the SMB request protocol ID, leading to an out-of-bounds read.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/kernel-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/kernel-headers-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/kernel-devel-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/kernel-tools-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/kernel-tools-devel-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/perf-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/python3-perf-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/bpftool-5.10.0-136.46.0.124.u73.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/kernel-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/kernel-headers-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/kernel-devel-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/kernel-tools-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/kernel-tools-devel-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/perf-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/python3-perf-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.46.0.124.u73.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/bpftool-5.10.0-136.46.0.124.u73.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2223</id>
		<title>An update for krb5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36054" id="CVE-2023-36054" title="CVE-2023-36054" type="cve"></reference>
		</references>
		<description>CVE-2023-36054:lib/kadm5/kadm_rpc_xdr.c in MIT Kerberos 5 (aka krb5) before 1.20.2 and 1.21.x before 1.21.1 frees an uninitialized pointer. A remote authenticated user can trigger a kadmind crash. This occurs because _xdr_kadm5_principal_ent_rec does not validate the relationship between n_key_data and the key_data array count.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="krb5" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-1.19.2-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/krb5-1.19.2-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-server" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-server-1.19.2-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/krb5-server-1.19.2-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-client" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-client-1.19.2-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/krb5-client-1.19.2-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-devel" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-devel-1.19.2-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/krb5-devel-1.19.2-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-libs" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-libs-1.19.2-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/krb5-libs-1.19.2-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="krb5-help" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-help-1.19.2-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/krb5-help-1.19.2-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-1.19.2-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/krb5-1.19.2-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-server" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-server-1.19.2-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/krb5-server-1.19.2-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-client" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-client-1.19.2-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/krb5-client-1.19.2-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-devel" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-devel-1.19.2-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/krb5-devel-1.19.2-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-libs" release="9.u2.fos23" version="1.19.2">
					<filename>krb5-libs-1.19.2-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/krb5-libs-1.19.2-9.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2224</id>
		<title>An update for librsvg2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38633" id="CVE-2023-38633" title="CVE-2023-38633" type="cve"></reference>
		</references>
		<description>CVE-2023-38633:A directory traversal problem in the URL decoder of librsvg before 2.56.3 could be used by local or remote attackers to disclose files (on the local filesystem outside of the expected area), as demonstrated by href=&#34;.?../../../../../../../../../../etc/passwd&#34; in an xi:include element.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="librsvg2" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-2.50.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/librsvg2-2.50.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="librsvg2-devel" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-devel-2.50.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/librsvg2-devel-2.50.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="librsvg2-tools" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-tools-2.50.5-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/librsvg2-tools-2.50.5-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="librsvg2-help" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-help-2.50.5-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/librsvg2-help-2.50.5-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="librsvg2" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-2.50.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/librsvg2-2.50.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="librsvg2-devel" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-devel-2.50.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/librsvg2-devel-2.50.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="librsvg2-tools" release="6.u3.fos23" version="2.50.5">
					<filename>librsvg2-tools-2.50.5-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/librsvg2-tools-2.50.5-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2225</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40090" id="CVE-2022-40090" title="CVE-2022-40090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3618" id="CVE-2023-3618" title="CVE-2023-3618" type="cve"></reference>
		</references>
		<description>CVE-2022-40090:An issue was discovered in function TIFFReadDirectory libtiff before 4.4.0 allows attackers to cause a denial of service via crafted TIFF file.&#xA;CVE-2023-3618:A flaw was found in libtiff. A specially crafted tiff file can lead to a segmentation fault due to a buffer overflow in the Fax3Encode function in libtiff/tif_fax3.c, resulting in a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-32.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/libtiff-4.3.0-32.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-32.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/libtiff-devel-4.3.0-32.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-32.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/libtiff-static-4.3.0-32.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-32.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/libtiff-tools-4.3.0-32.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-32.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/libtiff-help-4.3.0-32.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-32.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/libtiff-4.3.0-32.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-32.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/libtiff-devel-4.3.0-32.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-32.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/libtiff-static-4.3.0-32.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="32.u8.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-32.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/libtiff-tools-4.3.0-32.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2226</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48522" id="CVE-2022-48522" title="CVE-2022-48522" type="cve"></reference>
		</references>
		<description>CVE-2022-48522:In Perl 5.34.0, function S_find_uninit_var in sv.c has a stack-based crash that can lead to remote code execution or local privilege escalation.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="4" name="perl" release="9.u3.fos23" version="5.34.0">
					<filename>perl-5.34.0-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/perl-5.34.0-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-libs" release="9.u3.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/perl-libs-5.34.0-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-devel" release="9.u3.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/perl-devel-5.34.0-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="4" name="perl-help" release="9.u3.fos23" version="5.34.0">
					<filename>perl-help-5.34.0-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/perl-help-5.34.0-9.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl" release="9.u3.fos23" version="5.34.0">
					<filename>perl-5.34.0-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/perl-5.34.0-9.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-libs" release="9.u3.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/perl-libs-5.34.0-9.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-devel" release="9.u3.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/perl-devel-5.34.0-9.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2227</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3301" id="CVE-2023-3301" title="CVE-2023-3301" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3180" id="CVE-2023-3180" title="CVE-2023-3180" type="cve"></reference>
		</references>
		<description>CVE-2023-3301:A flaw was found in QEMU. The async nature of hot-unplug enables a race scenario where the net device backend is cleared before the virtio-net pci frontend has been unplugged. A malicious guest could use this time window to trigger an assertion and cause a denial of service.&#xA;CVE-2023-3180:A flaw was found in the QEMU virtual crypto device while handling data encryption/decryption requests in virtio_crypto_handle_sym_req. There is no check for the value of `src_len` and `dst_len` in virtio_crypto_sym_op_helper, potentially leading to a heap buffer overflow when the two values differ.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="10" name="qemu" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-guest-agent-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-79.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-help-6.2.0-79.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-img-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-block-rbd-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-block-ssh-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-block-iscsi-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-block-curl-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-hw-usb-host-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-seabios-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-system-aarch64-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-system-arm-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-system-x86_64-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-79.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qemu-system-riscv-6.2.0-79.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-guest-agent-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-img-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-block-rbd-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-block-ssh-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-block-iscsi-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-block-curl-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-hw-usb-host-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-system-aarch64-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-system-arm-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-system-x86_64-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="79.u7.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-79.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qemu-system-riscv-6.2.0-79.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2228</id>
		<title>An update for qpdf is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-25786" id="CVE-2021-25786" title="CVE-2021-25786" type="cve"></reference>
		</references>
		<description>CVE-2021-25786:An issue was discovered in QPDF version 10.0.4, allows remote attackers to execute arbitrary code via crafted .pdf file to Pl_ASCII85Decoder::write parameter in libqpdf.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="qpdf" release="4.u1.fos23" version="8.4.2">
					<filename>qpdf-8.4.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qpdf-8.4.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qpdf-devel" release="4.u1.fos23" version="8.4.2">
					<filename>qpdf-devel-8.4.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qpdf-devel-8.4.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qpdf-help" release="4.u1.fos23" version="8.4.2">
					<filename>qpdf-help-8.4.2-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qpdf-help-8.4.2-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qpdf" release="4.u1.fos23" version="8.4.2">
					<filename>qpdf-8.4.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qpdf-8.4.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qpdf-devel" release="4.u1.fos23" version="8.4.2">
					<filename>qpdf-devel-8.4.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qpdf-devel-8.4.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2229</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32573" id="CVE-2023-32573" title="CVE-2023-32573" type="cve"></reference>
		</references>
		<description>CVE-2023-32573:In Qt before 5.15.14, 6.0.x through 6.2.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1, QtSvg QSvgFont m_unitsPerEm initialization is mishandled.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="1" name="qt" release="53.u2.fos23" version="4.8.7">
					<filename>qt-4.8.7-53.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qt-4.8.7-53.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="qt-devel" release="53.u2.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-53.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/qt-devel-4.8.7-53.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt" release="53.u2.fos23" version="4.8.7">
					<filename>qt-4.8.7-53.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qt-4.8.7-53.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt-devel" release="53.u2.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-53.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/qt-devel-4.8.7-53.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2230</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24834" id="CVE-2022-24834" title="CVE-2022-24834" type="cve"></reference>
		</references>
		<description>CVE-2022-24834:Redis is an in-memory database that persists on disk. A specially crafted Lua script executing in Redis can trigger a heap overflow in the cjson library, and result with heap corruption and potentially remote code execution. The problem exists in all versions of Redis with Lua scripting support, starting from 2.6, and affects only authenticated and authorized users. The problem is fixed in versions 7.0.12, 6.2.13, and 6.0.20.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u4.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/redis5-5.0.7-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u4.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/redis5-devel-5.0.7-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u4.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/redis5-doc-5.0.7-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u4.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/redis5-5.0.7-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u4.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/redis5-devel-5.0.7-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2231</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24834" id="CVE-2022-24834" title="CVE-2022-24834" type="cve"></reference>
		</references>
		<description>CVE-2022-24834:Redis is an in-memory database that persists on disk. A specially crafted Lua script executing in Redis can trigger a heap overflow in the cjson library, and result with heap corruption and potentially remote code execution. The problem exists in all versions of Redis with Lua scripting support, starting from 2.6, and affects only authenticated and authorized users. The problem is fixed in versions 7.0.12, 6.2.13, and 6.0.20.</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u4.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/redis6-6.2.7-3.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u4.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/redis6-devel-6.2.7-3.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u4.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/redis6-doc-6.2.7-3.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u4.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/redis6-6.2.7-3.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u4.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/redis6-devel-6.2.7-3.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2232</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2157" id="CVE-2023-2157" title="CVE-2023-2157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3195" id="CVE-2023-3195" title="CVE-2023-3195" type="cve"></reference>
		</references>
		<description>CVE-2023-2157:A heap-based buffer overflow vulnerability was found in the ImageMagick package that can lead to the application crashing.&#xA;CVE-2023-3195:A stack-based buffer overflow issue was found in ImageMagick&#39;s coders/tiff.c. This flaw allows an attacker to trick the user into opening a specially crafted malicious tiff file, causing an application to crash, resulting in a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-4.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ImageMagick-7.1.1.8-4.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-4.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ImageMagick-devel-7.1.1.8-4.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-4.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ImageMagick-help-7.1.1.8-4.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-4.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ImageMagick-perl-7.1.1.8-4.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-4.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ImageMagick-c++-7.1.1.8-4.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-4.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ImageMagick-c++-devel-7.1.1.8-4.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-4.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ImageMagick-7.1.1.8-4.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-4.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ImageMagick-devel-7.1.1.8-4.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-4.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ImageMagick-help-7.1.1.8-4.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-4.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ImageMagick-perl-7.1.1.8-4.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-4.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ImageMagick-c++-7.1.1.8-4.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="4.u5.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-4.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ImageMagick-c++-devel-7.1.1.8-4.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2233</id>
		<title>An update for apache-commons-net is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37533" id="CVE-2021-37533" title="CVE-2021-37533" type="cve"></reference>
		</references>
		<description>CVE-2021-37533:Prior to Apache Commons Net 3.9.0, Net&#39;s FTP client trusts the host from PASV response by default. A malicious server can redirect the Commons Net code to use a different host, but the user has to connect to the malicious server in the first place. This may lead to leakage of information about services running on the private network of the client. The default in version 3.9.0 is now false to ignore such hosts, as cURL does. See https://issues.apache.org/jira/browse/NET-711.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="0" name="apache-commons-net" release="6.u2.fos23" version="3.6">
					<filename>apache-commons-net-3.6-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/apache-commons-net-3.6-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-net-help" release="6.u2.fos23" version="3.6">
					<filename>apache-commons-net-help-3.6-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/apache-commons-net-help-3.6-6.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2234</id>
		<title>An update for batik is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38398" id="CVE-2022-38398" title="CVE-2022-38398" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38648" id="CVE-2022-38648" title="CVE-2022-38648" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40146" id="CVE-2022-40146" title="CVE-2022-40146" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44729" id="CVE-2022-44729" title="CVE-2022-44729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44730" id="CVE-2022-44730" title="CVE-2022-44730" type="cve"></reference>
		</references>
		<description>CVE-2022-38398:Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache XML Graphics allows an attacker to load a url thru the jar protocol. This issue affects Apache XML Graphics Batik 1.14.&#xA;CVE-2022-38648:Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache XML Graphics allows an attacker to fetch external resources. This issue affects Apache XML Graphics Batik 1.14.&#xA;CVE-2022-40146:Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache XML Graphics allows an attacker to access files using a Jar url. This issue affects Apache XML Graphics Batik 1.14.&#xA;CVE-2022-44729:Server-Side Request Forgery (SSRF) vulnerability in Apache Software Foundation Apache XML Graphics Batik.This issue affects Apache XML Graphics Batik: 1.16.&#xA;On version 1.16, a malicious SVG could trigger loading external resources by default, causing resource consumption or in some cases even information disclosure. Users are recommended to upgrade to version 1.17 or later.&#xA;CVE-2022-44730:Server-Side Request Forgery (SSRF) vulnerability in Apache Software Foundation Apache XML Graphics Batik.This issue affects Apache XML Graphics Batik: 1.16.&#xA;A malicious SVG can probe user profile / data and send it directly as parameter to a URL.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="0" name="batik" release="8.u2.fos23" version="1.10">
					<filename>batik-1.10-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/batik-1.10-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="batik-help" release="8.u2.fos23" version="1.10">
					<filename>batik-help-1.10-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/batik-help-1.10-8.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2235</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47007" id="CVE-2022-47007" title="CVE-2022-47007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47010" id="CVE-2022-47010" title="CVE-2022-47010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48063" id="CVE-2022-48063" title="CVE-2022-48063" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44840" id="CVE-2022-44840" title="CVE-2022-44840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47695" id="CVE-2022-47695" title="CVE-2022-47695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48065" id="CVE-2022-48065" title="CVE-2022-48065" type="cve"></reference>
		</references>
		<description>CVE-2022-47007:An issue was discovered function stab_demangle_v3_arg in stabs.c in Binutils 2.34 thru 2.38, allows attackers to cause a denial of service due to memory leaks.&#xA;CVE-2022-47010:An issue was discovered function pr_function_type in prdbg.c in Binutils 2.34 thru 2.38, allows attackers to cause a denial of service due to memory leaks.&#xA;CVE-2022-48063:GNU Binutils before 2.40 was discovered to contain an excessive memory consumption vulnerability via the function load_separate_debug_files at dwarf2.c. The attacker could supply a crafted ELF file and cause a DNS attack.&#xA;CVE-2022-44840:Heap buffer overflow vulnerability in binutils readelf before 2.40 via function find_section_in_set in file readelf.c.&#xA;CVE-2022-47695:An issue was discovered Binutils objdump before 2.39.3 allows attackers to cause a denial of service or other unspecified impacts via function bfd_mach_o_get_synthetic_symtab in match-o.c.&#xA;CVE-2022-48065:GNU Binutils before 2.40 was discovered to contain a memory leak vulnerability var the function find_abstract_instance in dwarf2.c.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="binutils" release="24.u10.fos23" version="2.37">
					<filename>binutils-2.37-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/binutils-2.37-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="24.u10.fos23" version="2.37">
					<filename>binutils-devel-2.37-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/binutils-devel-2.37-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="24.u10.fos23" version="2.37">
					<filename>binutils-help-2.37-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/binutils-help-2.37-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="24.u10.fos23" version="2.37">
					<filename>binutils-2.37-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/binutils-2.37-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="24.u10.fos23" version="2.37">
					<filename>binutils-devel-2.37-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/binutils-devel-2.37-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="24.u10.fos23" version="2.37">
					<filename>binutils-help-2.37-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/binutils-help-2.37-24.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2236</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48174" id="CVE-2022-48174" title="CVE-2022-48174" type="cve"></reference>
		</references>
		<description>CVE-2022-48174:There is a stack overflow vulnerability in ash.c:6030 in busybox before 1.35. In the environment of Internet of Vehicles, this vulnerability can be executed from command to arbitrary code execution.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="busybox" release="19.u1.fos23" version="1.34.1">
					<filename>busybox-1.34.1-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/busybox-1.34.1-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-petitboot" release="19.u1.fos23" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/busybox-petitboot-1.34.1-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-help" release="19.u1.fos23" version="1.34.1">
					<filename>busybox-help-1.34.1-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/busybox-help-1.34.1-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox" release="19.u1.fos23" version="1.34.1">
					<filename>busybox-1.34.1-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/busybox-1.34.1-19.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-petitboot" release="19.u1.fos23" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/busybox-petitboot-1.34.1-19.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-help" release="19.u1.fos23" version="1.34.1">
					<filename>busybox-help-1.34.1-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/busybox-help-1.34.1-19.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2237</id>
		<title>An update for clamav is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20197" id="CVE-2023-20197" title="CVE-2023-20197" type="cve"></reference>
		</references>
		<description>CVE-2023-20197:A vulnerability in the filesystem image parser for Hierarchical File System Plus (HFS+) of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.&#xA; This vulnerability is due to an incorrect check for completion when a file is decompressed, which may result in a loop condition that could cause the affected software to stop responding. An attacker could exploit this vulnerability by submitting a crafted HFS+ filesystem image to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to cause the ClamAV scanning process to stop responding, resulting in a DoS condition on the affected software and consuming available system resources.&#xA; For a description of this vulnerability, see the ClamAV blog .</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="clamav" release="1.fos23" version="0.103.9">
					<filename>clamav-0.103.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-0.103.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-devel" release="1.fos23" version="0.103.9">
					<filename>clamav-devel-0.103.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-devel-0.103.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-help" release="1.fos23" version="0.103.9">
					<filename>clamav-help-0.103.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-help-0.103.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-filesystem" release="1.fos23" version="0.103.9">
					<filename>clamav-filesystem-0.103.9-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-filesystem-0.103.9-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-data" release="1.fos23" version="0.103.9">
					<filename>clamav-data-0.103.9-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-data-0.103.9-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-update" release="1.fos23" version="0.103.9">
					<filename>clamav-update-0.103.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-update-0.103.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamd" release="1.fos23" version="0.103.9">
					<filename>clamd-0.103.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamd-0.103.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-milter" release="1.fos23" version="0.103.9">
					<filename>clamav-milter-0.103.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/clamav-milter-0.103.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav" release="1.fos23" version="0.103.9">
					<filename>clamav-0.103.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/clamav-0.103.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-devel" release="1.fos23" version="0.103.9">
					<filename>clamav-devel-0.103.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/clamav-devel-0.103.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-help" release="1.fos23" version="0.103.9">
					<filename>clamav-help-0.103.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/clamav-help-0.103.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-update" release="1.fos23" version="0.103.9">
					<filename>clamav-update-0.103.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/clamav-update-0.103.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamd" release="1.fos23" version="0.103.9">
					<filename>clamd-0.103.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/clamd-0.103.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-milter" release="1.fos23" version="0.103.9">
					<filename>clamav-milter-0.103.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/clamav-milter-0.103.9-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2238</id>
		<title>An update for djvulibre is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46310" id="CVE-2021-46310" title="CVE-2021-46310" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46312" id="CVE-2021-46312" title="CVE-2021-46312" type="cve"></reference>
		</references>
		<description>CVE-2021-46310:An issue was discovered IW44Image.cpp in djvulibre 3.5.28 in allows attackers to cause a denial of service via divide by zero.&#xA;CVE-2021-46312:An issue was discovered IW44EncodeCodec.cpp in djvulibre 3.5.28 in allows attackers to cause a denial of service via divide by zero.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="djvulibre" release="19.u1.fos23" version="3.5.27">
					<filename>djvulibre-3.5.27-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/djvulibre-3.5.27-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="djvulibre-devel" release="19.u1.fos23" version="3.5.27">
					<filename>djvulibre-devel-3.5.27-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/djvulibre-devel-3.5.27-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="djvulibre-help" release="19.u1.fos23" version="3.5.27">
					<filename>djvulibre-help-3.5.27-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/djvulibre-help-3.5.27-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="djvulibre" release="19.u1.fos23" version="3.5.27">
					<filename>djvulibre-3.5.27-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/djvulibre-3.5.27-19.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="djvulibre-devel" release="19.u1.fos23" version="3.5.27">
					<filename>djvulibre-devel-3.5.27-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/djvulibre-devel-3.5.27-19.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="djvulibre-help" release="19.u1.fos23" version="3.5.27">
					<filename>djvulibre-help-3.5.27-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/djvulibre-help-3.5.27-19.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2239</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15663" id="CVE-2020-15663" title="CVE-2020-15663" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15664" id="CVE-2020-15664" title="CVE-2020-15664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15665" id="CVE-2020-15665" title="CVE-2020-15665" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15666" id="CVE-2020-15666" title="CVE-2020-15666" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15667" id="CVE-2020-15667" title="CVE-2020-15667" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15668" id="CVE-2020-15668" title="CVE-2020-15668" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15670" id="CVE-2020-15670" title="CVE-2020-15670" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15673" id="CVE-2020-15673" title="CVE-2020-15673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15674" id="CVE-2020-15674" title="CVE-2020-15674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15675" id="CVE-2020-15675" title="CVE-2020-15675" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15676" id="CVE-2020-15676" title="CVE-2020-15676" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15677" id="CVE-2020-15677" title="CVE-2020-15677" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15678" id="CVE-2020-15678" title="CVE-2020-15678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15680" id="CVE-2020-15680" title="CVE-2020-15680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15681" id="CVE-2020-15681" title="CVE-2020-15681" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15682" id="CVE-2020-15682" title="CVE-2020-15682" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15683" id="CVE-2020-15683" title="CVE-2020-15683" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15684" id="CVE-2020-15684" title="CVE-2020-15684" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-16012" id="CVE-2020-16012" title="CVE-2020-16012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-16044" id="CVE-2020-16044" title="CVE-2020-16044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26950" id="CVE-2020-26950" title="CVE-2020-26950" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26951" id="CVE-2020-26951" title="CVE-2020-26951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26953" id="CVE-2020-26953" title="CVE-2020-26953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26956" id="CVE-2020-26956" title="CVE-2020-26956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26958" id="CVE-2020-26958" title="CVE-2020-26958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26959" id="CVE-2020-26959" title="CVE-2020-26959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26960" id="CVE-2020-26960" title="CVE-2020-26960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26961" id="CVE-2020-26961" title="CVE-2020-26961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26962" id="CVE-2020-26962" title="CVE-2020-26962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26965" id="CVE-2020-26965" title="CVE-2020-26965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26966" id="CVE-2020-26966" title="CVE-2020-26966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26968" id="CVE-2020-26968" title="CVE-2020-26968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26969" id="CVE-2020-26969" title="CVE-2020-26969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26971" id="CVE-2020-26971" title="CVE-2020-26971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26972" id="CVE-2020-26972" title="CVE-2020-26972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26973" id="CVE-2020-26973" title="CVE-2020-26973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26974" id="CVE-2020-26974" title="CVE-2020-26974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26976" id="CVE-2020-26976" title="CVE-2020-26976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26978" id="CVE-2020-26978" title="CVE-2020-26978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26979" id="CVE-2020-26979" title="CVE-2020-26979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35111" id="CVE-2020-35111" title="CVE-2020-35111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35113" id="CVE-2020-35113" title="CVE-2020-35113" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35114" id="CVE-2020-35114" title="CVE-2020-35114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23953" id="CVE-2021-23953" title="CVE-2021-23953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23954" id="CVE-2021-23954" title="CVE-2021-23954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23955" id="CVE-2021-23955" title="CVE-2021-23955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23956" id="CVE-2021-23956" title="CVE-2021-23956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23958" id="CVE-2021-23958" title="CVE-2021-23958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23960" id="CVE-2021-23960" title="CVE-2021-23960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23961" id="CVE-2021-23961" title="CVE-2021-23961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23962" id="CVE-2021-23962" title="CVE-2021-23962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23963" id="CVE-2021-23963" title="CVE-2021-23963" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23964" id="CVE-2021-23964" title="CVE-2021-23964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23965" id="CVE-2021-23965" title="CVE-2021-23965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23968" id="CVE-2021-23968" title="CVE-2021-23968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23969" id="CVE-2021-23969" title="CVE-2021-23969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23970" id="CVE-2021-23970" title="CVE-2021-23970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23971" id="CVE-2021-23971" title="CVE-2021-23971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23972" id="CVE-2021-23972" title="CVE-2021-23972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23973" id="CVE-2021-23973" title="CVE-2021-23973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23974" id="CVE-2021-23974" title="CVE-2021-23974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23975" id="CVE-2021-23975" title="CVE-2021-23975" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23978" id="CVE-2021-23978" title="CVE-2021-23978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23979" id="CVE-2021-23979" title="CVE-2021-23979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23981" id="CVE-2021-23981" title="CVE-2021-23981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23982" id="CVE-2021-23982" title="CVE-2021-23982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23983" id="CVE-2021-23983" title="CVE-2021-23983" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23984" id="CVE-2021-23984" title="CVE-2021-23984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23985" id="CVE-2021-23985" title="CVE-2021-23985" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23986" id="CVE-2021-23986" title="CVE-2021-23986" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23987" id="CVE-2021-23987" title="CVE-2021-23987" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23988" id="CVE-2021-23988" title="CVE-2021-23988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23994" id="CVE-2021-23994" title="CVE-2021-23994" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23995" id="CVE-2021-23995" title="CVE-2021-23995" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23996" id="CVE-2021-23996" title="CVE-2021-23996" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23997" id="CVE-2021-23997" title="CVE-2021-23997" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23998" id="CVE-2021-23998" title="CVE-2021-23998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23999" id="CVE-2021-23999" title="CVE-2021-23999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24000" id="CVE-2021-24000" title="CVE-2021-24000" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24001" id="CVE-2021-24001" title="CVE-2021-24001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24002" id="CVE-2021-24002" title="CVE-2021-24002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29944" id="CVE-2021-29944" title="CVE-2021-29944" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29945" id="CVE-2021-29945" title="CVE-2021-29945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29946" id="CVE-2021-29946" title="CVE-2021-29946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29947" id="CVE-2021-29947" title="CVE-2021-29947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29952" id="CVE-2021-29952" title="CVE-2021-29952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29953" id="CVE-2021-29953" title="CVE-2021-29953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29955" id="CVE-2021-29955" title="CVE-2021-29955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29959" id="CVE-2021-29959" title="CVE-2021-29959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29960" id="CVE-2021-29960" title="CVE-2021-29960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29961" id="CVE-2021-29961" title="CVE-2021-29961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29964" id="CVE-2021-29964" title="CVE-2021-29964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29965" id="CVE-2021-29965" title="CVE-2021-29965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29966" id="CVE-2021-29966" title="CVE-2021-29966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29967" id="CVE-2021-29967" title="CVE-2021-29967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29970" id="CVE-2021-29970" title="CVE-2021-29970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29972" id="CVE-2021-29972" title="CVE-2021-29972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29974" id="CVE-2021-29974" title="CVE-2021-29974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29975" id="CVE-2021-29975" title="CVE-2021-29975" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29976" id="CVE-2021-29976" title="CVE-2021-29976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29977" id="CVE-2021-29977" title="CVE-2021-29977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29980" id="CVE-2021-29980" title="CVE-2021-29980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29981" id="CVE-2021-29981" title="CVE-2021-29981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29982" id="CVE-2021-29982" title="CVE-2021-29982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29984" id="CVE-2021-29984" title="CVE-2021-29984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29985" id="CVE-2021-29985" title="CVE-2021-29985" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29986" id="CVE-2021-29986" title="CVE-2021-29986" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29987" id="CVE-2021-29987" title="CVE-2021-29987" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29988" id="CVE-2021-29988" title="CVE-2021-29988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29989" id="CVE-2021-29989" title="CVE-2021-29989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29990" id="CVE-2021-29990" title="CVE-2021-29990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29991" id="CVE-2021-29991" title="CVE-2021-29991" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-30547" id="CVE-2021-30547" title="CVE-2021-30547" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32810" id="CVE-2021-32810" title="CVE-2021-32810" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38491" id="CVE-2021-38491" title="CVE-2021-38491" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38493" id="CVE-2021-38493" title="CVE-2021-38493" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38494" id="CVE-2021-38494" title="CVE-2021-38494" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38496" id="CVE-2021-38496" title="CVE-2021-38496" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38497" id="CVE-2021-38497" title="CVE-2021-38497" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38498" id="CVE-2021-38498" title="CVE-2021-38498" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38499" id="CVE-2021-38499" title="CVE-2021-38499" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38500" id="CVE-2021-38500" title="CVE-2021-38500" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38501" id="CVE-2021-38501" title="CVE-2021-38501" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38503" id="CVE-2021-38503" title="CVE-2021-38503" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38504" id="CVE-2021-38504" title="CVE-2021-38504" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38505" id="CVE-2021-38505" title="CVE-2021-38505" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38506" id="CVE-2021-38506" title="CVE-2021-38506" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38507" id="CVE-2021-38507" title="CVE-2021-38507" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38508" id="CVE-2021-38508" title="CVE-2021-38508" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38509" id="CVE-2021-38509" title="CVE-2021-38509" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38510" id="CVE-2021-38510" title="CVE-2021-38510" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4140" id="CVE-2021-4140" title="CVE-2021-4140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43531" id="CVE-2021-43531" title="CVE-2021-43531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43532" id="CVE-2021-43532" title="CVE-2021-43532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43533" id="CVE-2021-43533" title="CVE-2021-43533" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43534" id="CVE-2021-43534" title="CVE-2021-43534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43535" id="CVE-2021-43535" title="CVE-2021-43535" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43536" id="CVE-2021-43536" title="CVE-2021-43536" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43537" id="CVE-2021-43537" title="CVE-2021-43537" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43538" id="CVE-2021-43538" title="CVE-2021-43538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43539" id="CVE-2021-43539" title="CVE-2021-43539" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43540" id="CVE-2021-43540" title="CVE-2021-43540" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43541" id="CVE-2021-43541" title="CVE-2021-43541" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43542" id="CVE-2021-43542" title="CVE-2021-43542" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43543" id="CVE-2021-43543" title="CVE-2021-43543" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43545" id="CVE-2021-43545" title="CVE-2021-43545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43546" id="CVE-2021-43546" title="CVE-2021-43546" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0511" id="CVE-2022-0511" title="CVE-2022-0511" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0843" id="CVE-2022-0843" title="CVE-2022-0843" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1097" id="CVE-2022-1097" title="CVE-2022-1097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1196" id="CVE-2022-1196" title="CVE-2022-1196" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1529" id="CVE-2022-1529" title="CVE-2022-1529" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1802" id="CVE-2022-1802" title="CVE-2022-1802" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1919" id="CVE-2022-1919" title="CVE-2022-1919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2200" id="CVE-2022-2200" title="CVE-2022-2200" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22737" id="CVE-2022-22737" title="CVE-2022-22737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22738" id="CVE-2022-22738" title="CVE-2022-22738" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22739" id="CVE-2022-22739" title="CVE-2022-22739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22740" id="CVE-2022-22740" title="CVE-2022-22740" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22741" id="CVE-2022-22741" title="CVE-2022-22741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22742" id="CVE-2022-22742" title="CVE-2022-22742" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22743" id="CVE-2022-22743" title="CVE-2022-22743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22745" id="CVE-2022-22745" title="CVE-2022-22745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22747" id="CVE-2022-22747" title="CVE-2022-22747" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22748" id="CVE-2022-22748" title="CVE-2022-22748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22753" id="CVE-2022-22753" title="CVE-2022-22753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22754" id="CVE-2022-22754" title="CVE-2022-22754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22755" id="CVE-2022-22755" title="CVE-2022-22755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22756" id="CVE-2022-22756" title="CVE-2022-22756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22757" id="CVE-2022-22757" title="CVE-2022-22757" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22759" id="CVE-2022-22759" title="CVE-2022-22759" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22760" id="CVE-2022-22760" title="CVE-2022-22760" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22761" id="CVE-2022-22761" title="CVE-2022-22761" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22763" id="CVE-2022-22763" title="CVE-2022-22763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24713" id="CVE-2022-24713" title="CVE-2022-24713" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26381" id="CVE-2022-26381" title="CVE-2022-26381" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26382" id="CVE-2022-26382" title="CVE-2022-26382" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26383" id="CVE-2022-26383" title="CVE-2022-26383" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26384" id="CVE-2022-26384" title="CVE-2022-26384" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26385" id="CVE-2022-26385" title="CVE-2022-26385" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26386" id="CVE-2022-26386" title="CVE-2022-26386" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26387" id="CVE-2022-26387" title="CVE-2022-26387" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26485" id="CVE-2022-26485" title="CVE-2022-26485" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26486" id="CVE-2022-26486" title="CVE-2022-26486" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28281" id="CVE-2022-28281" title="CVE-2022-28281" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28282" id="CVE-2022-28282" title="CVE-2022-28282" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28283" id="CVE-2022-28283" title="CVE-2022-28283" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28284" id="CVE-2022-28284" title="CVE-2022-28284" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28285" id="CVE-2022-28285" title="CVE-2022-28285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28286" id="CVE-2022-28286" title="CVE-2022-28286" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28287" id="CVE-2022-28287" title="CVE-2022-28287" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28289" id="CVE-2022-28289" title="CVE-2022-28289" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29909" id="CVE-2022-29909" title="CVE-2022-29909" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29911" id="CVE-2022-29911" title="CVE-2022-29911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29912" id="CVE-2022-29912" title="CVE-2022-29912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29914" id="CVE-2022-29914" title="CVE-2022-29914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29915" id="CVE-2022-29915" title="CVE-2022-29915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29916" id="CVE-2022-29916" title="CVE-2022-29916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29918" id="CVE-2022-29918" title="CVE-2022-29918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31736" id="CVE-2022-31736" title="CVE-2022-31736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31737" id="CVE-2022-31737" title="CVE-2022-31737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31738" id="CVE-2022-31738" title="CVE-2022-31738" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31740" id="CVE-2022-31740" title="CVE-2022-31740" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31741" id="CVE-2022-31741" title="CVE-2022-31741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31742" id="CVE-2022-31742" title="CVE-2022-31742" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31743" id="CVE-2022-31743" title="CVE-2022-31743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31744" id="CVE-2022-31744" title="CVE-2022-31744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31745" id="CVE-2022-31745" title="CVE-2022-31745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31748" id="CVE-2022-31748" title="CVE-2022-31748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3266" id="CVE-2022-3266" title="CVE-2022-3266" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34468" id="CVE-2022-34468" title="CVE-2022-34468" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34469" id="CVE-2022-34469" title="CVE-2022-34469" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34470" id="CVE-2022-34470" title="CVE-2022-34470" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34471" id="CVE-2022-34471" title="CVE-2022-34471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34472" id="CVE-2022-34472" title="CVE-2022-34472" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34473" id="CVE-2022-34473" title="CVE-2022-34473" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34474" id="CVE-2022-34474" title="CVE-2022-34474" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34475" id="CVE-2022-34475" title="CVE-2022-34475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34476" id="CVE-2022-34476" title="CVE-2022-34476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34477" id="CVE-2022-34477" title="CVE-2022-34477" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34479" id="CVE-2022-34479" title="CVE-2022-34479" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34480" id="CVE-2022-34480" title="CVE-2022-34480" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34481" id="CVE-2022-34481" title="CVE-2022-34481" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34482" id="CVE-2022-34482" title="CVE-2022-34482" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34483" id="CVE-2022-34483" title="CVE-2022-34483" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34484" id="CVE-2022-34484" title="CVE-2022-34484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34485" id="CVE-2022-34485" title="CVE-2022-34485" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36318" id="CVE-2022-36318" title="CVE-2022-36318" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36319" id="CVE-2022-36319" title="CVE-2022-36319" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38472" id="CVE-2022-38472" title="CVE-2022-38472" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38473" id="CVE-2022-38473" title="CVE-2022-38473" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38477" id="CVE-2022-38477" title="CVE-2022-38477" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38478" id="CVE-2022-38478" title="CVE-2022-38478" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40956" id="CVE-2022-40956" title="CVE-2022-40956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40957" id="CVE-2022-40957" title="CVE-2022-40957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40958" id="CVE-2022-40958" title="CVE-2022-40958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40959" id="CVE-2022-40959" title="CVE-2022-40959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40960" id="CVE-2022-40960" title="CVE-2022-40960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40962" id="CVE-2022-40962" title="CVE-2022-40962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42928" id="CVE-2022-42928" title="CVE-2022-42928" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43680" id="CVE-2022-43680" title="CVE-2022-43680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45408" id="CVE-2022-45408" title="CVE-2022-45408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45409" id="CVE-2022-45409" title="CVE-2022-45409" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45410" id="CVE-2022-45410" title="CVE-2022-45410" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45411" id="CVE-2022-45411" title="CVE-2022-45411" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45412" id="CVE-2022-45412" title="CVE-2022-45412" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45416" id="CVE-2022-45416" title="CVE-2022-45416" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45418" id="CVE-2022-45418" title="CVE-2022-45418" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45420" id="CVE-2022-45420" title="CVE-2022-45420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45421" id="CVE-2022-45421" title="CVE-2022-45421" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46871" id="CVE-2022-46871" title="CVE-2022-46871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46874" id="CVE-2022-46874" title="CVE-2022-46874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46875" id="CVE-2022-46875" title="CVE-2022-46875" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46878" id="CVE-2022-46878" title="CVE-2022-46878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46882" id="CVE-2022-46882" title="CVE-2022-46882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0767" id="CVE-2023-0767" title="CVE-2023-0767" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1945" id="CVE-2023-1945" title="CVE-2023-1945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1999" id="CVE-2023-1999" title="CVE-2023-1999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23598" id="CVE-2023-23598" title="CVE-2023-23598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23599" id="CVE-2023-23599" title="CVE-2023-23599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23601" id="CVE-2023-23601" title="CVE-2023-23601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23602" id="CVE-2023-23602" title="CVE-2023-23602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23603" id="CVE-2023-23603" title="CVE-2023-23603" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25728" id="CVE-2023-25728" title="CVE-2023-25728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25729" id="CVE-2023-25729" title="CVE-2023-25729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25730" id="CVE-2023-25730" title="CVE-2023-25730" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25732" id="CVE-2023-25732" title="CVE-2023-25732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25735" id="CVE-2023-25735" title="CVE-2023-25735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25737" id="CVE-2023-25737" title="CVE-2023-25737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25739" id="CVE-2023-25739" title="CVE-2023-25739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25742" id="CVE-2023-25742" title="CVE-2023-25742" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25751" id="CVE-2023-25751" title="CVE-2023-25751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25752" id="CVE-2023-25752" title="CVE-2023-25752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28162" id="CVE-2023-28162" title="CVE-2023-28162" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28164" id="CVE-2023-28164" title="CVE-2023-28164" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28176" id="CVE-2023-28176" title="CVE-2023-28176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29531" id="CVE-2023-29531" title="CVE-2023-29531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29532" id="CVE-2023-29532" title="CVE-2023-29532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29533" id="CVE-2023-29533" title="CVE-2023-29533" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29535" id="CVE-2023-29535" title="CVE-2023-29535" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29536" id="CVE-2023-29536" title="CVE-2023-29536" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29539" id="CVE-2023-29539" title="CVE-2023-29539" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29541" id="CVE-2023-29541" title="CVE-2023-29541" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29542" id="CVE-2023-29542" title="CVE-2023-29542" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29545" id="CVE-2023-29545" title="CVE-2023-29545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29548" id="CVE-2023-29548" title="CVE-2023-29548" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29550" id="CVE-2023-29550" title="CVE-2023-29550" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32205" id="CVE-2023-32205" title="CVE-2023-32205" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32206" id="CVE-2023-32206" title="CVE-2023-32206" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32207" id="CVE-2023-32207" title="CVE-2023-32207" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32211" id="CVE-2023-32211" title="CVE-2023-32211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32212" id="CVE-2023-32212" title="CVE-2023-32212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32213" id="CVE-2023-32213" title="CVE-2023-32213" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32214" id="CVE-2023-32214" title="CVE-2023-32214" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32215" id="CVE-2023-32215" title="CVE-2023-32215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34414" id="CVE-2023-34414" title="CVE-2023-34414" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34416" id="CVE-2023-34416" title="CVE-2023-34416" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37201" id="CVE-2023-37201" title="CVE-2023-37201" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37202" id="CVE-2023-37202" title="CVE-2023-37202" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37207" id="CVE-2023-37207" title="CVE-2023-37207" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37208" id="CVE-2023-37208" title="CVE-2023-37208" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37211" id="CVE-2023-37211" title="CVE-2023-37211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4045" id="CVE-2023-4045" title="CVE-2023-4045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4046" id="CVE-2023-4046" title="CVE-2023-4046" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4047" id="CVE-2023-4047" title="CVE-2023-4047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4048" id="CVE-2023-4048" title="CVE-2023-4048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4049" id="CVE-2023-4049" title="CVE-2023-4049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4050" id="CVE-2023-4050" title="CVE-2023-4050" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4054" id="CVE-2023-4054" title="CVE-2023-4054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4055" id="CVE-2023-4055" title="CVE-2023-4055" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4056" id="CVE-2023-4056" title="CVE-2023-4056" type="cve"></reference>
		</references>
		<description>CVE-2020-15663:If Firefox is installed to a user-writable directory, the Mozilla Maintenance Service would execute updater.exe from the install location with system privileges. Although the Mozilla Maintenance Service does ensure that updater.exe is signed by Mozilla, the version could have been rolled back to a previous version which would have allowed exploitation of an older bug and arbitrary code execution with System Privileges. *Note: This issue only affected Windows operating systems. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 80, Thunderbird &lt; 78.2, Thunderbird &lt; 68.12, Firefox ESR &lt; 68.12, and Firefox ESR &lt; 78.2.&#xA;CVE-2020-15664:By holding a reference to the eval() function from an about:blank window, a malicious webpage could have gained access to the InstallTrigger object which would allow them to prompt the user to install an extension. Combined with user confusion, this could result in an unintended or malicious extension being installed. This vulnerability affects Firefox &lt; 80, Thunderbird &lt; 78.2, Thunderbird &lt; 68.12, Firefox ESR &lt; 68.12, Firefox ESR &lt; 78.2, and Firefox for Android &lt; 80.&#xA;CVE-2020-15665:Firefox did not reset the address bar after the beforeunload dialog was shown if the user chose to remain on the page. This could have resulted in an incorrect URL being shown when used in conjunction with other unexpected browser behaviors. This vulnerability affects Firefox &lt; 80.&#xA;CVE-2020-15666:When trying to load a non-video in an audio/video context the exact status code (200, 302, 404, 500, 412, 403, etc.) was disclosed via the MediaError Message. This level of information leakage is inconsistent with the standardized onerror/onsuccess disclosure and can lead to inferring login status to services or device discovery on a local network among other attacks. This vulnerability affects Firefox &lt; 80 and Firefox for Android &lt; 80.&#xA;CVE-2020-15667:When processing a MAR update file, after the signature has been validated, an invalid name length could result in a heap overflow, leading to memory corruption and potentially arbitrary code execution. Within Firefox as released by Mozilla, this issue is only exploitable with the Mozilla-controlled signing key. This vulnerability affects Firefox &lt; 80.&#xA;CVE-2020-15668:A lock was missing when accessing a data structure and importing certificate information into the trust database. This vulnerability affects Firefox &lt; 80 and Firefox for Android &lt; 80.&#xA;CVE-2020-15670:Mozilla developers reported memory safety bugs present in Firefox for Android 79. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 80, Firefox ESR &lt; 78.2, Thunderbird &lt; 78.2, and Firefox for Android &lt; 80.&#xA;CVE-2020-15673:Mozilla developers reported memory safety bugs present in Firefox 80 and Firefox ESR 78.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 81, Thunderbird &lt; 78.3, and Firefox ESR &lt; 78.3.&#xA;CVE-2020-15674:Mozilla developers reported memory safety bugs present in Firefox 80. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 81.&#xA;CVE-2020-15675:When processing surfaces, the lifetime may outlive a persistent buffer leading to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 81.&#xA;CVE-2020-15676:Firefox sometimes ran the onload handler for SVG elements that the DOM sanitizer decided to remove, resulting in JavaScript being executed after pasting attacker-controlled data into a contenteditable element. This vulnerability affects Firefox &lt; 81, Thunderbird &lt; 78.3, and Firefox ESR &lt; 78.3.&#xA;CVE-2020-15677:By exploiting an Open Redirect vulnerability on a website, an attacker could have spoofed the site displayed in the download file dialog to show the original site (the one suffering from the open redirect) rather than the site the file was actually downloaded from. This vulnerability affects Firefox &lt; 81, Thunderbird &lt; 78.3, and Firefox ESR &lt; 78.3.&#xA;CVE-2020-15678:When recursing through graphical layers while scrolling, an iterator may have become invalid, resulting in a potential use-after-free. This occurs because the function APZCTreeManager::ComputeClippedCompositionBounds did not follow iterator invalidation rules. This vulnerability affects Firefox &lt; 81, Thunderbird &lt; 78.3, and Firefox ESR &lt; 78.3.&#xA;CVE-2020-15680:If a valid external protocol handler was referenced in an image tag, the resulting broken image size could be distinguished from a broken image size of a non-existent protocol handler. This allowed an attacker to successfully probe whether an external protocol handler was registered. This vulnerability affects Firefox &lt; 82.&#xA;CVE-2020-15681:When multiple WASM threads had a reference to a module, and were looking up exported functions, one WASM thread could have overwritten another&#39;s entry in a shared stub table, resulting in a potentially exploitable crash. This vulnerability affects Firefox &lt; 82.&#xA;CVE-2020-15682:When a link to an external protocol was clicked, a prompt was presented that allowed the user to choose what application to open it in. An attacker could induce that prompt to be associated with an origin they didn&#39;t control, resulting in a spoofing attack. This was fixed by changing external protocol prompts to be tab-modal while also ensuring they could not be incorrectly associated with a different origin. This vulnerability affects Firefox &lt; 82.&#xA;CVE-2020-15683:Mozilla developers and community members reported memory safety bugs present in Firefox 81 and Firefox ESR 78.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 78.4, Firefox &lt; 82, and Thunderbird &lt; 78.4.&#xA;CVE-2020-15684:Mozilla developers reported memory safety bugs present in Firefox 81. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 82.&#xA;CVE-2020-16012:Side-channel information leakage in graphics in Google Chrome prior to 87.0.4280.66 allowed a remote attacker to leak cross-origin data via a crafted HTML page.&#xA;CVE-2020-16044:Use after free in WebRTC in Google Chrome prior to 88.0.4324.96 allowed a remote attacker to potentially exploit heap corruption via a crafted SCTP packet.&#xA;CVE-2020-26950:In certain circumstances, the MCallGetProperty opcode can be emitted with unmet assumptions resulting in an exploitable use-after-free condition. This vulnerability affects Firefox &lt; 82.0.3, Firefox ESR &lt; 78.4.1, and Thunderbird &lt; 78.4.2.&#xA;CVE-2020-26951:A parsing and event loading mismatch in Firefox&#39;s SVG code could have allowed load events to fire, even after sanitization. An attacker already capable of exploiting an XSS vulnerability in privileged internal pages could have used this attack to bypass our built-in sanitizer. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26953:It was possible to cause the browser to enter fullscreen mode without displaying the security UI; thus making it possible to attempt a phishing attack or otherwise confuse the user. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26956:In some cases, removing HTML elements during sanitization would keep existing SVG event handlers and therefore lead to XSS. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26958:Firefox did not block execution of scripts with incorrect MIME types when the response was intercepted and cached through a ServiceWorker. This could lead to a cross-site script inclusion vulnerability, or a Content Security Policy bypass. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26959:During browser shutdown, reference decrementing could have occured on a previously freed object, resulting in a use-after-free, memory corruption, and a potentially exploitable crash. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26960:If the Compact() method was called on an nsTArray, the array could have been reallocated without updating other pointers, leading to a potential use-after-free and exploitable crash. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26961:When DNS over HTTPS is in use, it intentionally filters RFC1918 and related IP ranges from the responses as these do not make sense coming from a DoH resolver. However when an IPv4 address was mapped through IPv6, these addresses were erroneously let through, leading to a potential DNS Rebinding attack. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26962:Cross-origin iframes that contained a login form could have been recognized by the login autofill service, and populated. This could have been used in clickjacking attacks, as well as be read across partitions in dynamic first party isolation. This vulnerability affects Firefox &lt; 83.&#xA;CVE-2020-26965:Some websites have a feature &#34;Show Password&#34; where clicking a button will change a password field into a textbook field, revealing the typed password. If, when using a software keyboard that remembers user input, a user typed their password and used that feature, the type of the password field was changed, resulting in a keyboard layout change and the possibility for the software keyboard to remember the typed password. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26966:Searching for a single word from the address bar caused an mDNS request to be sent on the local network searching for a hostname consisting of that string; resulting in an information leak. *Note: This issue only affected Windows operating systems. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26968:Mozilla developers reported memory safety bugs present in Firefox 82 and Firefox ESR 78.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 83, Firefox ESR &lt; 78.5, and Thunderbird &lt; 78.5.&#xA;CVE-2020-26969:Mozilla developers reported memory safety bugs present in Firefox 82. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 83.&#xA;CVE-2020-26971:Certain blit values provided by the user were not properly constrained leading to a heap buffer overflow on some video drivers. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.&#xA;CVE-2020-26972:The lifecycle of IPC Actors allows managed actors to outlive their manager actors; and the former must ensure that they are not attempting to use a dead actor they have a reference to. Such a check was omitted in WebGL, resulting in a use-after-free and a potentially exploitable crash. This vulnerability affects Firefox &lt; 84.&#xA;CVE-2020-26973:Certain input to the CSS Sanitizer confused it, resulting in incorrect components being removed. This could have been used as a sanitizer bypass. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.&#xA;CVE-2020-26974:When flex-basis was used on a table wrapper, a StyleGenericFlexBasis object could have been incorrectly cast to the wrong type. This resulted in a heap user-after-free, memory corruption, and a potentially exploitable crash. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.&#xA;CVE-2020-26976:When a HTTPS pages was embedded in a HTTP page, and there was a service worker registered for the former, the service worker could have intercepted the request for the secure page despite the iframe not being a secure context due to the (insecure) framing. This vulnerability affects Firefox &lt; 84.&#xA;CVE-2020-26978:Using techniques that built on the slipstream research, a malicious webpage could have exposed both an internal network&#39;s hosts as well as services running on the user&#39;s local machine. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.&#xA;CVE-2020-26979:When a user typed a URL in the address bar or the search bar and quickly hit the enter key, a website could sometimes capture that event and then redirect the user before navigation occurred to the desired, entered address. To construct a convincing spoof the attacker would have had to guess what the user was typing, perhaps by suggesting it. This vulnerability affects Firefox &lt; 84.&#xA;CVE-2020-35111:When an extension with the proxy permission registered to receive &lt;all_urls&gt;, the proxy.onRequest callback was not triggered for view-source URLs. While web content cannot navigate to such URLs, a user opening View Source could have inadvertently leaked their IP address. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.&#xA;CVE-2020-35113:Mozilla developers reported memory safety bugs present in Firefox 83 and Firefox ESR 78.5. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.&#xA;CVE-2020-35114:Mozilla developers reported memory safety bugs present in Firefox 83. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 84.&#xA;CVE-2021-23953:If a user clicked into a specifically crafted PDF, the PDF reader could be confused into leaking cross-origin information, when said information is served as chunked data. This vulnerability affects Firefox &lt; 85, Thunderbird &lt; 78.7, and Firefox ESR &lt; 78.7.&#xA;CVE-2021-23954:Using the new logical assignment operators in a JavaScript switch statement could have caused a type confusion, leading to a memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 85, Thunderbird &lt; 78.7, and Firefox ESR &lt; 78.7.&#xA;CVE-2021-23955:The browser could have been confused into transferring a pointer lock state into another tab, which could have lead to clickjacking attacks. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23956:An ambiguous file picker design could have confused users who intended to select and upload a single file into uploading a whole directory. This was addressed by adding a new prompt. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23958:The browser could have been confused into transferring a screen sharing state into another tab, which would leak unintended information. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23960:Performing garbage collection on re-declared JavaScript variables resulted in a user-after-poison, and a potentially exploitable crash. This vulnerability affects Firefox &lt; 85, Thunderbird &lt; 78.7, and Firefox ESR &lt; 78.7.&#xA;CVE-2021-23961:Further techniques that built on the slipstream research combined with a malicious webpage could have exposed both an internal network&#39;s hosts as well as services running on the user&#39;s local machine. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23962:Incorrect use of the &#39;&lt;RowCountChanged&gt;&#39; method could have led to a user-after-poison and a potentially exploitable crash. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23963:When sharing geolocation during an active WebRTC share, Firefox could have reset the webRTC sharing state in the user interface, leading to loss of control over the currently granted permission. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23964:Mozilla developers reported memory safety bugs present in Firefox 84 and Firefox ESR 78.6. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 85, Thunderbird &lt; 78.7, and Firefox ESR &lt; 78.7.&#xA;CVE-2021-23965:Mozilla developers reported memory safety bugs present in Firefox 84. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 85.&#xA;CVE-2021-23968:If Content Security Policy blocked frame navigation, the full destination of a redirect served in the frame was reported in the violation report; as opposed to the original frame URI. This could be used to leak sensitive information contained in such URIs. This vulnerability affects Firefox &lt; 86, Thunderbird &lt; 78.8, and Firefox ESR &lt; 78.8.&#xA;CVE-2021-23969:As specified in the W3C Content Security Policy draft, when creating a violation report, &#34;User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.&#34; Under certain types of redirects, Firefox incorrectly set the source file to be the destination of the redirects. This was fixed to be the redirect destination&#39;s origin. This vulnerability affects Firefox &lt; 86, Thunderbird &lt; 78.8, and Firefox ESR &lt; 78.8.&#xA;CVE-2021-23970:Context-specific code was included in a shared jump table; resulting in assertions being triggered in multithreaded wasm code. This vulnerability affects Firefox &lt; 86.&#xA;CVE-2021-23971:When processing a redirect with a conflicting Referrer-Policy, Firefox would have adopted the redirect&#39;s Referrer-Policy. This would have potentially resulted in more information than intended by the original origin being provided to the destination of the redirect. This vulnerability affects Firefox &lt; 86.&#xA;CVE-2021-23972:One phishing tactic on the web is to provide a link with HTTP Auth. For example &#39;https://www.phishingtarget.com@evil.com&#39;. To mitigate this type of attack, Firefox will display a warning dialog; however, this warning dialog would not have been displayed if evil.com used a redirect that was cached by the browser. This vulnerability affects Firefox &lt; 86.&#xA;CVE-2021-23973:When trying to load a cross-origin resource in an audio/video context a decoding error may have resulted, and the content of that error may have revealed information about the resource. This vulnerability affects Firefox &lt; 86, Thunderbird &lt; 78.8, and Firefox ESR &lt; 78.8.&#xA;CVE-2021-23974:The DOMParser API did not properly process &#39;&lt;noscript&gt;&#39; elements for escaping. This could be used as an mXSS vector to bypass an HTML Sanitizer. This vulnerability affects Firefox &lt; 86.&#xA;CVE-2021-23975:The developer page about:memory has a Measure function for exploring what object types the browser has allocated and their sizes. When this function was invoked we incorrectly called the sizeof function, instead of using the API method that checks for invalid pointers. This vulnerability affects Firefox &lt; 86.&#xA;CVE-2021-23978:Mozilla developers reported memory safety bugs present in Firefox 85 and Firefox ESR 78.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 86, Thunderbird &lt; 78.8, and Firefox ESR &lt; 78.8.&#xA;CVE-2021-23979:Mozilla developers reported memory safety bugs present in Firefox 85. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 86.&#xA;CVE-2021-23981:A texture upload of a Pixel Buffer Object could have confused the WebGL code to skip binding the buffer used to unpack it, resulting in memory corruption and a potentially exploitable information leak or crash. This vulnerability affects Firefox ESR &lt; 78.9, Firefox &lt; 87, and Thunderbird &lt; 78.9.&#xA;CVE-2021-23982:Using techniques that built on the slipstream research, a malicious webpage could have scanned both an internal network&#39;s hosts as well as services running on the user&#39;s local machine utilizing WebRTC connections. This vulnerability affects Firefox ESR &lt; 78.9, Firefox &lt; 87, and Thunderbird &lt; 78.9.&#xA;CVE-2021-23983:By causing a transition on a parent node by removing a CSS rule, an invalid property for a marker could have been applied, resulting in memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 87.&#xA;CVE-2021-23984:A malicious extension could have opened a popup window lacking an address bar. The title of the popup lacking an address bar should not be fully controllable, but in this situation was. This could have been used to spoof a website and attempt to trick the user into providing credentials. This vulnerability affects Firefox ESR &lt; 78.9, Firefox &lt; 87, and Thunderbird &lt; 78.9.&#xA;CVE-2021-23985:If an attacker is able to alter specific about:config values (for example malware running on the user&#39;s computer), the Devtools remote debugging feature could have been enabled in a way that was unnoticable to the user. This would have allowed a remote attacker (able to make a direct network connection to the victim) to monitor the user&#39;s browsing activity and (plaintext) network traffic. This was addressed by providing a visual cue when Devtools has an open network socket. This vulnerability affects Firefox &lt; 87.&#xA;CVE-2021-23986:A malicious extension with the &#39;search&#39; permission could have installed a new search engine whose favicon referenced a cross-origin URL. The response to this cross-origin request could have been read by the extension, allowing a same-origin policy bypass by the extension, which should not have cross-origin permissions. This cross-origin request was made without cookies, so the sensitive information disclosed by the violation was limited to local-network resources or resources that perform IP-based authentication. This vulnerability affects Firefox &lt; 87.&#xA;CVE-2021-23987:Mozilla developers and community members reported memory safety bugs present in Firefox 86 and Firefox ESR 78.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 78.9, Firefox &lt; 87, and Thunderbird &lt; 78.9.&#xA;CVE-2021-23988:Mozilla developers reported memory safety bugs present in Firefox 86. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 87.&#xA;CVE-2021-23994:A WebGL framebuffer was not initialized early enough, resulting in memory corruption and an out of bound write. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-23995:When Responsive Design Mode was enabled, it used references to objects that were previously freed. We presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-23996:By utilizing 3D CSS in conjunction with Javascript, content could have been rendered outside the webpage&#39;s viewport, resulting in a spoofing attack that could have been used for phishing or other attacks on a user. This vulnerability affects Firefox &lt; 88.&#xA;CVE-2021-23997:Due to unexpected data type conversions, a use-after-free could have occurred when interacting with the font cache. We presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 88.&#xA;CVE-2021-23998:Through complicated navigations with new windows, an HTTP page could have inherited a secure lock icon from an HTTPS page. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-23999:If a Blob URL was loaded through some unusual user interaction, it could have been loaded by the System Principal and granted additional privileges that should not be granted to web content. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-24000:A race condition with requestPointerLock() and setTimeout() could have resulted in a user interacting with one tab when they believed they were on a separate tab. In conjunction with certain elements (such as &amp;lt;input type=&#34;file&#34;&amp;gt;) this could have led to an attack where a user was confused about the origin of the webpage and potentially disclosed information they did not intend to. This vulnerability affects Firefox &lt; 88.&#xA;CVE-2021-24001:A compromised content process could have performed session history manipulations it should not have been able to due to testing infrastructure that was not restricted to testing-only configurations. This vulnerability affects Firefox &lt; 88.&#xA;CVE-2021-24002:When a user clicked on an FTP URL containing encoded newline characters (%0A and %0D), the newlines would have been interpreted as such and allowed arbitrary commands to be sent to the FTP server. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-29944:Lack of escaping allowed HTML injection when a webpage was viewed in Reader View. While a Content Security Policy prevents direct code execution, HTML injection is still possible. *Note: This issue only affected Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 88.&#xA;CVE-2021-29945:The WebAssembly JIT could miscalculate the size of a return type, which could lead to a null read and result in a crash. *Note: This issue only affected x86-32 platforms. Other platforms are unaffected.*. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-29946:Ports that were written as an integer overflow above the bounds of a 16-bit integer could have bypassed port blocking restrictions when used in the Alt-Svc header. This vulnerability affects Firefox ESR &lt; 78.10, Thunderbird &lt; 78.10, and Firefox &lt; 88.&#xA;CVE-2021-29947:Mozilla developers and community members reported memory safety bugs present in Firefox 87. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 88.&#xA;CVE-2021-29952:When Web Render components were destructed, a race condition could have caused undefined behavior, and we presume that with enough effort may have been exploitable to run arbitrary code. This vulnerability affects Firefox &lt; 88.0.1 and Firefox for Android &lt; 88.1.3.&#xA;CVE-2021-29953:A malicious webpage could have forced a Firefox for Android user into executing attacker-controlled JavaScript in the context of another domain, resulting in a Universal Cross-Site Scripting vulnerability. *Note: This issue only affected Firefox for Android. Other operating systems are unaffected. Further details are being temporarily withheld to allow users an opportunity to update.*. This vulnerability affects Firefox &lt; 88.0.1 and Firefox for Android &lt; 88.1.3.&#xA;CVE-2021-29955:A transient execution vulnerability, named Floating Point Value Injection (FPVI) allowed an attacker to leak arbitrary memory addresses and may have also enabled JIT type confusion attacks. (A related vulnerability, Speculative Code Store Bypass (SCSB), did not affect Firefox.). This vulnerability affects Firefox ESR &lt; 78.9 and Firefox &lt; 87.&#xA;CVE-2021-29959:When a user has already allowed a website to access microphone and camera, disabling camera sharing would not fully prevent the website from re-enabling it without an additional prompt. This was only possible if the website kept recording with the microphone until re-enabling the camera. This vulnerability affects Firefox &lt; 89.&#xA;CVE-2021-29960:Firefox used to cache the last filename used for printing a file. When generating a filename for printing, Firefox usually suggests the web page title. The caching and suggestion techniques combined may have lead to the title of a website visited during private browsing mode being stored on disk. This vulnerability affects Firefox &lt; 89.&#xA;CVE-2021-29961:When styling and rendering an oversized `&lt;select&gt;` element, Firefox did not apply correct clipping which allowed an attacker to paint over the user interface. This vulnerability affects Firefox &lt; 89.&#xA;CVE-2021-29964:A locally-installed hostile program could send `WM_COPYDATA` messages that Firefox would process incorrectly, leading to an out-of-bounds read. *This bug only affects Firefox on Windows. Other operating systems are unaffected.*. This vulnerability affects Thunderbird &lt; 78.11, Firefox &lt; 89, and Firefox ESR &lt; 78.11.&#xA;CVE-2021-29965:A malicious website that causes an HTTP Authentication dialog to be spawned could trick the built-in password manager to suggest passwords for the currently active website instead of the website that triggered the dialog. *This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 89.&#xA;CVE-2021-29966:Mozilla developers reported memory safety bugs present in Firefox 88. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 89.&#xA;CVE-2021-29967:Mozilla developers reported memory safety bugs present in Firefox 88 and Firefox ESR 78.11. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird &lt; 78.11, Firefox &lt; 89, and Firefox ESR &lt; 78.11.&#xA;CVE-2021-29970:A malicious webpage could have triggered a use-after-free, memory corruption, and a potentially exploitable crash. *This bug could only be triggered when accessibility was enabled.*. This vulnerability affects Thunderbird &lt; 78.12, Firefox ESR &lt; 78.12, and Firefox &lt; 90.&#xA;CVE-2021-29972:A use-after-free vulnerability was found via testing, and traced to an out-of-date Cairo library. Updating the library resolved the issue, and may have remediated other, unknown security vulnerabilities as well. This vulnerability affects Firefox &lt; 90.&#xA;CVE-2021-29974:When network partitioning was enabled, e.g. as a result of Enhanced Tracking Protection settings, a TLS error page would allow the user to override an error on a domain which had specified HTTP Strict Transport Security (which implies that the error should not be override-able.) This issue did not affect the network connections, and they were correctly upgraded to HTTPS automatically. This vulnerability affects Firefox &lt; 90.&#xA;CVE-2021-29975:Through a series of DOM manipulations, a message, over which the attacker had control of the text but not HTML or formatting, could be overlaid on top of another domain (with the new domain correctly shown in the address bar) resulting in possible user confusion. This vulnerability affects Firefox &lt; 90.&#xA;CVE-2021-29976:Mozilla developers reported memory safety bugs present in code shared between Firefox and Thunderbird. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird &lt; 78.12, Firefox ESR &lt; 78.12, and Firefox &lt; 90.&#xA;CVE-2021-29977:Mozilla developers reported memory safety bugs present in Firefox 89. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 90.&#xA;CVE-2021-29980:Uninitialized memory in a canvas object could have caused an incorrect free() leading to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 78.13, Thunderbird &lt; 91, Firefox ESR &lt; 78.13, and Firefox &lt; 91.&#xA;CVE-2021-29981:An issue present in lowering/register allocation could have led to obscure but deterministic register confusion failures in JITted code that would lead to a potentially exploitable crash. This vulnerability affects Firefox &lt; 91 and Thunderbird &lt; 91.&#xA;CVE-2021-29982:Due to incorrect JIT optimization, we incorrectly interpreted data from the wrong type of object, resulting in the potential leak of a single bit of memory. This vulnerability affects Firefox &lt; 91 and Thunderbird &lt; 91.&#xA;CVE-2021-29984:Instruction reordering resulted in a sequence of instructions that would cause an object to be incorrectly considered during garbage collection. This led to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 78.13, Thunderbird &lt; 91, Firefox ESR &lt; 78.13, and Firefox &lt; 91.&#xA;CVE-2021-29985:A use-after-free vulnerability in media channels could have led to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 78.13, Thunderbird &lt; 91, Firefox ESR &lt; 78.13, and Firefox &lt; 91.&#xA;CVE-2021-29986:A suspected race condition when calling getaddrinfo led to memory corruption and a potentially exploitable crash. *Note: This issue only affected Linux operating systems. Other operating systems are unaffected.* This vulnerability affects Thunderbird &lt; 78.13, Thunderbird &lt; 91, Firefox ESR &lt; 78.13, and Firefox &lt; 91.&#xA;CVE-2021-29987:After requesting multiple permissions, and closing the first permission panel, subsequent permission panels will be displayed in a different position but still record a click in the default location, making it possible to trick a user into accepting a permission they did not want to. *This bug only affects Firefox on Linux. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 91 and Thunderbird &lt; 91.&#xA;CVE-2021-29988:Firefox incorrectly treated an inline list-item element as a block element, resulting in an out of bounds read or memory corruption, and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 78.13, Thunderbird &lt; 91, Firefox ESR &lt; 78.13, and Firefox &lt; 91.&#xA;CVE-2021-29989:Mozilla developers reported memory safety bugs present in Firefox 90 and Firefox ESR 78.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird &lt; 78.13, Firefox ESR &lt; 78.13, and Firefox &lt; 91.&#xA;CVE-2021-29990:Mozilla developers and community members reported memory safety bugs present in Firefox 90. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 91.&#xA;CVE-2021-29991:Firefox incorrectly accepted a newline in a HTTP/3 header, interpretting it as two separate headers. This allowed for a header splitting attack against servers using HTTP/3. This vulnerability affects Firefox &lt; 91.0.1 and Thunderbird &lt; 91.0.1.&#xA;CVE-2021-30547:Out of bounds write in ANGLE in Google Chrome prior to 91.0.4472.101 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page.&#xA;CVE-2021-32810:crossbeam-deque is a package of work-stealing deques for building task schedulers when programming in Rust. In versions prior to 0.7.4 and 0.8.0, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. This has been fixed in crossbeam-deque 0.8.1 and 0.7.4.&#xA;CVE-2021-38491:Mixed-content checks were unable to analyze opaque origins which led to some mixed content being loaded. This vulnerability affects Firefox &lt; 92.&#xA;CVE-2021-38493:Mozilla developers reported memory safety bugs present in Firefox 91 and Firefox ESR 78.13. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 78.14, Thunderbird &lt; 78.14, and Firefox &lt; 92.&#xA;CVE-2021-38494:Mozilla developers reported memory safety bugs present in Firefox 91. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 92.&#xA;CVE-2021-38496:During operations on MessageTasks, a task may have been removed while it was still scheduled, resulting in memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 78.15, Thunderbird &lt; 91.2, Firefox ESR &lt; 91.2, Firefox ESR &lt; 78.15, and Firefox &lt; 93.&#xA;CVE-2021-38497:Through use of reportValidity() and window.open(), a plain-text validation message could have been overlaid on another origin, leading to possible user confusion and spoofing attacks. This vulnerability affects Firefox &lt; 93, Thunderbird &lt; 91.2, and Firefox ESR &lt; 91.2.&#xA;CVE-2021-38498:During process shutdown, a document could have caused a use-after-free of a languages service object, leading to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 93, Thunderbird &lt; 91.2, and Firefox ESR &lt; 91.2.&#xA;CVE-2021-38499:Mozilla developers reported memory safety bugs present in Firefox 92. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 93.&#xA;CVE-2021-38500:Mozilla developers reported memory safety bugs present in Firefox 92 and Firefox ESR 91.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird &lt; 78.15, Thunderbird &lt; 91.2, Firefox ESR &lt; 91.2, Firefox ESR &lt; 78.15, and Firefox &lt; 93.&#xA;CVE-2021-38501:Mozilla developers reported memory safety bugs present in Firefox 92 and Firefox ESR 91.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 93, Thunderbird &lt; 91.2, and Firefox ESR &lt; 91.2.&#xA;CVE-2021-38503:The iframe sandbox rules were not correctly applied to XSLT stylesheets, allowing an iframe to bypass restrictions such as executing scripts or navigating the top-level frame. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38504:When interacting with an HTML input element&#39;s file picker dialog with webkitdirectory set, a use-after-free could have resulted, leading to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38505:Microsoft introduced a new feature in Windows 10 known as Cloud Clipboard which, if enabled, will record data copied to the clipboard to the cloud, and make it available on other computers in certain scenarios. Applications that wish to prevent copied data from being recorded in Cloud History must use specific clipboard formats; and Firefox before versions 94 and ESR 91.3 did not implement them. This could have caused sensitive data to be recorded to a user&#39;s Microsoft account. *This bug only affects Firefox for Windows 10+ with Cloud Clipboard enabled. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38506:Through a series of navigations, Firefox could have entered fullscreen mode without notification or warning to the user. This could lead to spoofing attacks on the browser UI including phishing. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38507:The Opportunistic Encryption feature of HTTP2 (RFC 8164) allows a connection to be transparently upgraded to TLS while retaining the visual properties of an HTTP connection, including being same-origin with unencrypted connections on port 80. However, if a second encrypted port on the same IP address (e.g. port 8443) did not opt-in to opportunistic encryption; a network attacker could forward a connection from the browser to port 443 to port 8443, causing the browser to treat the content of port 8443 as same-origin with HTTP. This was resolved by disabling the Opportunistic Encryption feature, which had low usage. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38508:By displaying a form validity message in the correct location at the same time as a permission prompt (such as for geolocation), the validity message could have obscured the prompt, resulting in the user potentially being tricked into granting the permission. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38509:Due to an unusual sequence of attacker-controlled events, a Javascript alert() dialog with arbitrary (although unstyled) contents could be displayed over top an uncontrolled webpage of the attacker&#39;s choosing. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-38510:The executable file warning was not presented when downloading .inetloc files, which, due to a flaw in Mac OS, can run commands on a user&#39;s computer.*Note: This issue only affected Mac OS operating systems. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-4140:It was possible to construct specific XSLT markup that would be able to bypass an iframe sandbox. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2021-43531:When a user loaded a Web Extensions context menu, the Web Extension could access the post-redirect URL of the element clicked. If the Web Extension lacked the WebRequest permission for the hosts involved in the redirect, this would be a same-origin-violation leaking data the Web Extension should have access to. This was fixed to provide the pre-redirect URL. This is related to CVE-2021-43532 but in the context of Web Extensions. This vulnerability affects Firefox &lt; 94.&#xA;CVE-2021-43532:The &#39;Copy Image Link&#39; context menu action would copy the final image URL after redirects. By embedding an image that triggered authentication flows - in conjunction with a Content Security Policy that stopped a redirection chain in the middle - the final image URL could be one that contained an authentication token used to takeover a user account. If a website tricked a user into copy and pasting the image link back to the page, the page would be able to steal the authentication tokens. This was fixed by making the action return the original URL, before any redirects. This vulnerability affects Firefox &lt; 94.&#xA;CVE-2021-43533:When parsing internationalized domain names, high bits of the characters in the URLs were sometimes stripped, resulting in inconsistencies that could lead to user confusion or attacks such as phishing. This vulnerability affects Firefox &lt; 94.&#xA;CVE-2021-43534:Mozilla developers and community members reported memory safety bugs present in Firefox 93 and Firefox ESR 91.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-43535:A use-after-free could have occured when an HTTP2 session object was released on a different thread, leading to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 93, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.&#xA;CVE-2021-43536:Under certain circumstances, asynchronous functions could have caused a navigation to fail but expose the target URL. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43537:An incorrect type conversion of sizes from 64bit to 32bit integers allowed an attacker to corrupt memory leading to a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43538:By misusing a race in our notification code, an attacker could have forcefully hidden the notification for pages that had received full screen and pointer lock access, which could have been used for spoofing attacks. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43539:Failure to correctly record the location of live pointers across wasm instance calls resulted in a GC occurring within the call not tracing those live pointers. This could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43540:WebExtensions with the correct permissions were able to create and install ServiceWorkers for third-party websites that would not have been uninstalled with the extension. This vulnerability affects Firefox &lt; 95.&#xA;CVE-2021-43541:When invoking protocol handlers for external protocols, a supplied parameter URL containing spaces was not properly escaped. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43542:Using XMLHttpRequest, an attacker could have identified installed applications by probing error messages for loading external protocols. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43543:Documents loaded with the CSP sandbox directive could have escaped the sandbox&#39;s script restriction by embedding additional content. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43545:Using the Location API in a loop could have caused severe application hangs and crashes. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2021-43546:It was possible to recreate previous cursor spoofing attacks against users with a zoomed native cursor. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.&#xA;CVE-2022-0511:Mozilla developers and community members Gabriele Svelto, Sebastian Hengst, Randell Jesup, Luan Herrera, Lars T Hansen, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 96. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 97.&#xA;CVE-2022-0843:Mozilla developers Kershaw Chang, Ryan VanderMeulen, and Randell Jesup reported memory safety bugs present in Firefox 97. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 98.&#xA;CVE-2022-1097:&lt;code&gt;NSSToken&lt;/code&gt; objects were referenced via direct points, and could have been accessed in an unsafe way on different threads, leading to a use-after-free and potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.&#xA;CVE-2022-1196:After a VR Process is destroyed, a reference to it may have been retained and used, leading to a use-after-free and potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.8 and Firefox ESR &lt; 91.8.&#xA;CVE-2022-1529:An attacker could have sent a message to the parent process where the contents were used to double-index into a JavaScript object, leading to prototype pollution and ultimately attacker-controlled JavaScript executing in the privileged parent process. This vulnerability affects Firefox ESR &lt; 91.9.1, Firefox &lt; 100.0.2, Firefox for Android &lt; 100.3.0, and Thunderbird &lt; 91.9.1.&#xA;CVE-2022-1802:If an attacker was able to corrupt the methods of an Array object in JavaScript via prototype pollution, they could have achieved execution of attacker-controlled JavaScript code in a privileged context. This vulnerability affects Firefox ESR &lt; 91.9.1, Firefox &lt; 100.0.2, Firefox for Android &lt; 100.3.0, and Thunderbird &lt; 91.9.1.&#xA;CVE-2022-1919:Use after free in Codecs in Google Chrome prior to 101.0.4951.41 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.&#xA;CVE-2022-2200:If an object prototype was corrupted by an attacker, they would have been able to set undesired attributes on a JavaScript object, leading to privileged code execution. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-22737:Constructing audio sinks could have lead to a race condition when playing audio files and closing windows. This could have lead to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22738:Applying a CSS filter effect could have accessed out of bounds memory. This could have lead to a heap-buffer-overflow causing a potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22739:Malicious websites could have tricked users into accepting launching a program to handle an external URL protocol. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22740:Certain network request objects were freed too early when releasing a network request handle. This could have lead to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22741:When resizing a popup while requesting fullscreen access, the popup would have become unable to leave fullscreen mode. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22742:When inserting text while in edit mode, some characters might have lead to out-of-bounds memory access causing a potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22743:When navigating from inside an iframe while requesting fullscreen access, an attacker-controlled tab could have made the browser unable to leave fullscreen mode. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22745:Securitypolicyviolation events could have leaked cross-origin information for frame-ancestors violations. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22747:After accepting an untrusted certificate, handling an empty pkcs7 sequence as part of the certificate data could have lead to a crash. This crash is believed to be unexploitable. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22748:Malicious websites could have confused Firefox into showing the wrong origin when asking to launch a program and handling an external URL protocol. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;CVE-2022-22753:A Time-of-Check Time-of-Use bug existed in the Maintenance (Updater) Service that could be abused to grant Users write access to an arbitrary directory. This could have been used to escalate to SYSTEM access.&lt;br&gt;*This bug only affects Firefox on Windows. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-22754:If a user installed an extension of a particular type, the extension could have auto-updated itself and while doing so, bypass the prompt which grants the new version the new requested permissions. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-22755:By using XSL Transforms, a malicious webserver could have served a user an XSL document that would continue to execute JavaScript (within the bounds of the same-origin policy) even after the tab was closed. This vulnerability affects Firefox &lt; 97.&#xA;CVE-2022-22756:If a user was convinced to drag and drop an image to their desktop or other folder, the resulting object could have been changed into an executable script which would have run arbitrary code after the user clicked on it. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-22757:Remote Agent, used in WebDriver, did not validate the Host or Origin headers. This could have allowed websites to connect back locally to the user&#39;s browser to control it. &lt;br&gt;*This bug only affected Firefox when WebDriver was enabled, which is not the default configuration.*. This vulnerability affects Firefox &lt; 97.&#xA;CVE-2022-22759:If a document created a sandboxed iframe without &lt;code&gt;allow-scripts&lt;/code&gt;, and subsequently appended an element to the iframe&#39;s document that e.g. had a JavaScript event handler - the event handler would have run despite the iframe&#39;s sandbox. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-22760:When importing resources using Web Workers, error messages would distinguish the difference between &lt;code&gt;application/javascript&lt;/code&gt; responses and non-script responses. This could have been abused to learn information cross-origin. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-22761:Web-accessible extension pages (pages with a moz-extension:// scheme) were not correctly enforcing the frame-ancestors directive when it was used in the Web Extension&#39;s Content Security Policy. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-22763:When a worker is shutdown, it was possible to cause script to run late in the lifecycle, at a point after where it should not be possible. This vulnerability affects Firefox &lt; 96, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.&#xA;CVE-2022-24713:regex is an implementation of regular expressions for the Rust language. The regex crate features built-in mitigations to prevent denial of service attacks caused by untrusted regexes, or untrusted input matched by trusted regexes. Those (tunable) mitigations already provide sane defaults to prevent attacks. This guarantee is documented and it&#39;s considered part of the crate&#39;s API. Unfortunately a bug was discovered in the mitigations designed to prevent untrusted regexes to take an arbitrary amount of time during parsing, and it&#39;s possible to craft regexes that bypass such mitigations. This makes it possible to perform denial of service attacks by sending specially crafted regexes to services accepting user-controlled, untrusted regexes.&#xA;CVE-2022-26381:An attacker could have caused a use-after-free by forcing a text reflow in an SVG object leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 98, Firefox ESR &lt; 91.7, and Thunderbird &lt; 91.7.&#xA;CVE-2022-26382:While the text displayed in Autofill tooltips cannot be directly read by JavaScript, the text was rendered using page fonts. Side-channel attacks on the text by using specially crafted fonts could have lead to this text being inferred by the webpage. This vulnerability affects Firefox &lt; 98.&#xA;CVE-2022-26383:When resizing a popup after requesting fullscreen access, the popup would not display the fullscreen notification. This vulnerability affects Firefox &lt; 98, Firefox ESR &lt; 91.7, and Thunderbird &lt; 91.7.&#xA;CVE-2022-26384:If an attacker could control the contents of an iframe sandboxed with &lt;code&gt;allow-popups&lt;/code&gt; but not &lt;code&gt;allow-scripts&lt;/code&gt;, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox &lt; 98, Firefox ESR &lt; 91.7, and Thunderbird &lt; 91.7.&#xA;CVE-2022-26385:In unusual circumstances, an individual thread may outlive the thread&#39;s manager during shutdown. This could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox &lt; 98.&#xA;CVE-2022-26386:Previously Firefox for macOS and Linux would download temporary files to a user-specific directory in &lt;code&gt;/tmp&lt;/code&gt;, but this behavior was changed to download them to &lt;code&gt;/tmp&lt;/code&gt; where they could be affected by other local users. This behavior was reverted to the original, user-specific directory. &lt;br&gt;*This bug only affects Firefox for macOS and Linux. Other operating systems are unaffected.*. This vulnerability affects Firefox ESR &lt; 91.7 and Thunderbird &lt; 91.7.&#xA;CVE-2022-26387:When installing an add-on, Firefox verified the signature before prompting the user; but while the user was confirming the prompt, the underlying add-on file could have been modified and Firefox would not have noticed. This vulnerability affects Firefox &lt; 98, Firefox ESR &lt; 91.7, and Thunderbird &lt; 91.7.&#xA;CVE-2022-26485:Removing an XSLT parameter during processing could have lead to an exploitable use-after-free. We have had reports of attacks in the wild abusing this flaw. This vulnerability affects Firefox &lt; 97.0.2, Firefox ESR &lt; 91.6.1, Firefox for Android &lt; 97.3.0, Thunderbird &lt; 91.6.2, and Focus &lt; 97.3.0.&#xA;CVE-2022-26486:An unexpected message in the WebGPU IPC framework could lead to a use-after-free and exploitable sandbox escape. We have had reports of attacks in the wild abusing this flaw. This vulnerability affects Firefox &lt; 97.0.2, Firefox ESR &lt; 91.6.1, Firefox for Android &lt; 97.3.0, Thunderbird &lt; 91.6.2, and Focus &lt; 97.3.0.&#xA;CVE-2022-28281:If a compromised content process sent an unexpected number of WebAuthN Extensions in a Register command to the parent process, an out of bounds write would have occurred leading to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.&#xA;CVE-2022-28282:By using a link with &lt;code&gt;rel=&#34;localization&#34;&lt;/code&gt; a use-after-free could have been triggered by destroying an object during JavaScript execution and then referencing the object through a freed pointer, leading to a potential exploitable crash. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.&#xA;CVE-2022-28283:The sourceMapURL feature in devtools was missing security checks that would have allowed a webpage to attempt to include local files or other files that should have been inaccessible. This vulnerability affects Firefox &lt; 99.&#xA;CVE-2022-28284:SVG&#39;s &lt;code&gt;&amp;lt;use&amp;gt;&lt;/code&gt; element could have been used to load unexpected content that could have executed script in certain circumstances. While the specification seems to allow this, other browsers do not, and web developers relied on this property for script security so gecko&#39;s implementation was aligned with theirs. This vulnerability affects Firefox &lt; 99.&#xA;CVE-2022-28285:When generating the assembly code for &lt;code&gt;MLoadTypedArrayElementHole&lt;/code&gt;, an incorrect AliasSet was used. In conjunction with another vulnerability this could have been used for an out of bounds memory read. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.&#xA;CVE-2022-28286:Due to a layout change, iframe contents could have been rendered outside of its border. This could have led to user confusion or spoofing attacks. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.&#xA;CVE-2022-28287:In unusual circumstances, selecting text could cause text selection caching to behave incorrectly, leading to a crash. This vulnerability affects Firefox &lt; 99.&#xA;CVE-2022-28289:Mozilla developers and community members Nika Layzell, Andrew McCreight, Gabriele Svelto, and the Mozilla Fuzzing Team reported memory safety bugs present in Thunderbird 91.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.&#xA;CVE-2022-29909:Documents in deeply-nested cross-origin browsing contexts could have obtained permissions granted to the top-level origin, bypassing the existing prompt and wrongfully inheriting the top-level permissions. This vulnerability affects Thunderbird &lt; 91.9, Firefox ESR &lt; 91.9, and Firefox &lt; 100.&#xA;CVE-2022-29911:An improper implementation of the new iframe sandbox keyword &lt;code&gt;allow-top-navigation-by-user-activation&lt;/code&gt; could lead to script execution without &lt;code&gt;allow-scripts&lt;/code&gt; being present. This vulnerability affects Thunderbird &lt; 91.9, Firefox ESR &lt; 91.9, and Firefox &lt; 100.&#xA;CVE-2022-29912:Requests initiated through reader mode did not properly omit cookies with a SameSite attribute. This vulnerability affects Thunderbird &lt; 91.9, Firefox ESR &lt; 91.9, and Firefox &lt; 100.&#xA;CVE-2022-29914:When reusing existing popups Firefox would have allowed them to cover the fullscreen notification UI, which could have enabled browser spoofing attacks. This vulnerability affects Thunderbird &lt; 91.9, Firefox ESR &lt; 91.9, and Firefox &lt; 100.&#xA;CVE-2022-29915:The Performance API did not properly hide the fact whether a request cross-origin resource has observed redirects. This vulnerability affects Firefox &lt; 100.&#xA;CVE-2022-29916:Firefox behaved slightly differently for already known resources when loading CSS resources involving CSS variables. This could have been used to probe the browser history. This vulnerability affects Thunderbird &lt; 91.9, Firefox ESR &lt; 91.9, and Firefox &lt; 100.&#xA;CVE-2022-29918:Mozilla developers Gabriele Svelto, Randell Jesup and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 99. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 100.&#xA;CVE-2022-31736:A malicious website could have learned the size of a cross-origin resource that supported Range requests. This vulnerability affects Thunderbird &lt; 91.10, Firefox &lt; 101, and Firefox ESR &lt; 91.10.&#xA;CVE-2022-31737:A malicious webpage could have caused an out-of-bounds write in WebGL, leading to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.10, Firefox &lt; 101, and Firefox ESR &lt; 91.10.&#xA;CVE-2022-31738:When exiting fullscreen mode, an iframe could have confused the browser about the current state of fullscreen, resulting in potential user confusion or spoofing attacks. This vulnerability affects Thunderbird &lt; 91.10, Firefox &lt; 101, and Firefox ESR &lt; 91.10.&#xA;CVE-2022-31740:On arm64, WASM code could have resulted in incorrect assembly generation leading to a register allocation problem, and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 91.10, Firefox &lt; 101, and Firefox ESR &lt; 91.10.&#xA;CVE-2022-31741:A crafted CMS message could have been processed incorrectly, leading to an invalid memory read, and potentially further memory corruption. This vulnerability affects Thunderbird &lt; 91.10, Firefox &lt; 101, and Firefox ESR &lt; 91.10.&#xA;CVE-2022-31742:An attacker could have exploited a timing attack by sending a large number of allowCredential entries and detecting the difference between invalid key handles and cross-origin key handles. This could have led to cross-origin account linking in violation of WebAuthn goals. This vulnerability affects Thunderbird &lt; 91.10, Firefox &lt; 101, and Firefox ESR &lt; 91.10.&#xA;CVE-2022-31743:Firefox&#39;s HTML parser did not correctly interpret HTML comment tags, resulting in an incongruity with other browsers. This could have been used to escape HTML comments on pages that put user-controlled data in them. This vulnerability affects Firefox &lt; 101.&#xA;CVE-2022-31744:An attacker could have injected CSS into stylesheets accessible via internal URIs, such as resource:, and in doing so bypass a page&#39;s Content Security Policy. This vulnerability affects Firefox ESR &lt; 91.11, Thunderbird &lt; 102, Thunderbird &lt; 91.11, and Firefox &lt; 101.&#xA;CVE-2022-31745:If array shift operations are not used, the Garbage Collector may have become confused about valid objects. This vulnerability affects Firefox &lt; 101.&#xA;CVE-2022-31748:Mozilla developers Gabriele Svelto, Timothy Nikkel, Randell Jesup, Jon Coppeard, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 100. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 101.&#xA;CVE-2022-3266:An out-of-bounds read can occur when decoding H264 video. This results in a potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-34468:An iframe that was not permitted to run scripts could do so if the user clicked on a &lt;code&gt;javascript:&lt;/code&gt; link. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-34469:When a TLS Certificate error occurs on a domain protected by the HSTS header, the browser should not allow the user to bypass the certificate error. On Firefox for Android, the user was presented with the option to bypass the error; this could only have been done by the user explicitly. &lt;br&gt;*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34470:Session history navigations may have led to a use-after-free and potentially exploitable crash. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-34471:When downloading an update for an addon, the downloaded addon update&#39;s version was not verified to match the version selected from the manifest. If the manifest had been tampered with on the server, an attacker could trick the browser into downgrading the addon to a prior version. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34472:If there was a PAC URL set and the server that hosts the PAC was not reachable, OCSP requests would have been blocked, resulting in incorrect error pages being shown. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-34473:The HTML Sanitizer should have sanitized the &lt;code&gt;href&lt;/code&gt; attribute of SVG &lt;code&gt;&amp;lt;use&amp;gt;&lt;/code&gt; tags; however it incorrectly did not sanitize &lt;code&gt;xlink:href&lt;/code&gt; attributes. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34474:Even when an iframe was sandboxed with &lt;code&gt;allow-top-navigation-by-user-activation&lt;/code&gt;, if it received a redirect header to an external protocol the browser would process the redirect and prompt the user as appropriate. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34475:SVG &lt;code&gt;&amp;lt;use&amp;gt;&lt;/code&gt; tags that referenced a same-origin document could have resulted in script execution if attacker input was sanitized via the HTML Sanitizer API. This would have required the attacker to reference a same-origin JavaScript file containing the script to be executed. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34476:ASN.1 parsing of an indefinite SEQUENCE inside an indefinite GROUP could have resulted in the parser accepting malformed ASN.1. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34477:The MediaError message property should be consistent to avoid leaking information about cross-origin resources; however for a same-site cross-origin resource, the message could have leaked information enabling XS-Leaks attacks. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34479:A malicious website that could create a popup could have resized the popup to overlay the address bar with its own content, resulting in potential user confusion or spoofing attacks. &lt;br&gt;*This bug only affects Thunderbird for Linux. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-34480:Within the &lt;code&gt;lg_init()&lt;/code&gt; function, if several allocations succeed but then one fails, an uninitialized pointer would have been freed despite never being allocated. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34481:In the &lt;code&gt;nsTArray_Impl::ReplaceElementsAt()&lt;/code&gt; function, an integer overflow could have occurred when the number of elements to replace was too large for the container. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-34482:An attacker who could have convinced a user to drag and drop an image to a filesystem could have manipulated the resulting filename to contain an executable extension, and by extension potentially tricked the user into executing malicious code. While very similar, this is a separate issue from CVE-2022-34483. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34483:An attacker who could have convinced a user to drag and drop an image to a filesystem could have manipulated the resulting filename to contain an executable extension, and by extension potentially tricked the user into executing malicious code. While very similar, this is a separate issue from CVE-2022-34482. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-34484:The Mozilla Fuzzing Team reported potential vulnerabilities present in Thunderbird 91.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2022-34485:Mozilla developers Bryce Seager van Dyk and the Mozilla Fuzzing Team reported potential vulnerabilities present in Firefox 101. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 102.&#xA;CVE-2022-36318:When visiting directory listings for `chrome://` URLs as source text, some parameters were reflected. This vulnerability affects Firefox ESR &lt; 102.1, Firefox ESR &lt; 91.12, Firefox &lt; 103, Thunderbird &lt; 102.1, and Thunderbird &lt; 91.12.&#xA;CVE-2022-36319:When combining CSS properties for overflow and transform, the mouse cursor could interact with different coordinates than displayed. This vulnerability affects Firefox ESR &lt; 102.1, Firefox ESR &lt; 91.12, Firefox &lt; 103, Thunderbird &lt; 102.1, and Thunderbird &lt; 91.12.&#xA;CVE-2022-38472:An attacker could have abused XSLT error handling to associate attacker-controlled content with another origin which was displayed in the address bar. This could have been used to fool the user into submitting data intended for the spoofed origin. This vulnerability affects Thunderbird &lt; 102.2, Thunderbird &lt; 91.13, Firefox ESR &lt; 91.13, Firefox ESR &lt; 102.2, and Firefox &lt; 104.&#xA;CVE-2022-38473:A cross-origin iframe referencing an XSLT document would inherit the parent domain&#39;s permissions (such as microphone or camera access). This vulnerability affects Thunderbird &lt; 102.2, Thunderbird &lt; 91.13, Firefox ESR &lt; 91.13, Firefox ESR &lt; 102.2, and Firefox &lt; 104.&#xA;CVE-2022-38477:Mozilla developer Nika Layzell and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 103 and Firefox ESR 102.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 102.2, Thunderbird &lt; 102.2, and Firefox &lt; 104.&#xA;CVE-2022-38478:Members the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 103, Firefox ESR 102.1, and Firefox ESR 91.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird &lt; 102.2, Thunderbird &lt; 91.13, Firefox ESR &lt; 91.13, Firefox ESR &lt; 102.2, and Firefox &lt; 104.&#xA;CVE-2022-40956:When injecting an HTML base element, some requests would ignore the CSP&#39;s base-uri settings and accept the injected element&#39;s base instead. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-40957:Inconsistent data in instruction and data cache when creating wasm code could lead to a potentially exploitable crash.&lt;br&gt;*This bug only affects Firefox on ARM64 platforms.*. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-40958:By injecting a cookie with certain special characters, an attacker on a shared subdomain which is not a secure context could set and thus overwrite cookies from a secure context, leading to session fixation and other attacks. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-40959:During iframe navigation, certain pages did not have their FeaturePolicy fully initialized leading to a bypass that leaked device permissions into untrusted subdocuments. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-40960:Concurrent use of the URL parser with non-UTF-8 data was not thread-safe. This could lead to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-40962:Mozilla developers Nika Layzell, Timothy Nikkel, Sebastian Hengst, Andreas Pehrson, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 104 and Firefox ESR 102.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.&#xA;CVE-2022-42928:Certain types of allocations were missing annotations that, if the Garbage Collector was in a specific state, could have lead to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 106, Firefox ESR &lt; 102.4, and Thunderbird &lt; 102.4.&#xA;CVE-2022-43680:In libexpat through 2.4.9, there is a use-after free caused by overeager destruction of a shared DTD in XML_ExternalEntityParserCreate in out-of-memory situations.&#xA;CVE-2022-45408:Through a series of popups that reuse windowName, an attacker can cause a window to go fullscreen without the user seeing the notification prompt, resulting in potential user confusion or spoofing attacks. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45409:The garbage collector could have been aborted in several states and zones and &lt;code&gt;GCRuntime::finishCollection&lt;/code&gt; may not have been called, leading to a use-after-free and potentially exploitable crash. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45410:When a ServiceWorker intercepted a request with &lt;code&gt;FetchEvent&lt;/code&gt;, the origin of the request was lost after the ServiceWorker took ownership of it. This had the effect of negating SameSite cookie protections. This was addressed in the spec and then in browsers. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45411:Cross-Site Tracing occurs when a server will echo a request back via the Trace method, allowing an XSS attack to access to authorization headers and cookies inaccessible to JavaScript (such as cookies protected by HTTPOnly). To mitigate this attack, browsers placed limits on &lt;code&gt;fetch()&lt;/code&gt; and XMLHttpRequest; however some webservers have implemented non-standard headers such as &lt;code&gt;X-Http-Method-Override&lt;/code&gt; that override the HTTP method, and made this attack possible again. Thunderbird has applied the same mitigations to the use of this and similar headers. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45412:When resolving a symlink such as &lt;code&gt;file:///proc/self/fd/1&lt;/code&gt;, an error message may be produced where the symlink was resolved to a string containing unitialized memory in the buffer. &lt;br&gt;*This bug only affects Thunderbird on Unix-based operated systems (Android, Linux, MacOS). Windows is unaffected.*. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45416:Keyboard events reference strings like &#34;KeyA&#34; that were at fixed, known, and widely-spread addresses. Cache-based timing attacks such as Prime+Probe could have possibly figured out which keys were being pressed. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45418:If a custom mouse cursor is specified in CSS, under certain circumstances the cursor could have been drawn over the browser UI, resulting in potential user confusion or spoofing attacks. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45420:Use tables inside of an iframe, an attacker could have caused iframe contents to be rendered outside the boundaries of the iframe, resulting in potential user confusion or spoofing attacks. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-45421:Mozilla developers Andrew McCreight and Gabriele Svelto reported memory safety bugs present in Thunderbird 102.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.&#xA;CVE-2022-46871:An out of date library (libusrsctp) contained vulnerabilities that could potentially be exploited. This vulnerability affects Firefox &lt; 108.&#xA;CVE-2022-46874:A file with a long filename could have had its filename truncated to remove the valid extension, leaving a malicious extension in its place. This could potentially led to user confusion and the execution of malicious code.&lt;br/&gt;*Note*: This issue was originally included in the advisories for Thunderbird 102.6, but a patch (specific to Thunderbird) was omitted, resulting in it actually being fixed in Thunderbird 102.6.1. This vulnerability affects Firefox &lt; 108, Thunderbird &lt; 102.6.1, Thunderbird &lt; 102.6, and Firefox ESR &lt; 102.6.&#xA;CVE-2022-46875:The executable file warning was not presented when downloading .atloc and .ftploc files, which can run commands on a user&#39;s computer. &lt;br&gt;*Note: This issue only affected Mac OS operating systems. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 108, Firefox ESR &lt; 102.6, and Thunderbird &lt; 102.6.&#xA;CVE-2022-46878:Mozilla developers Randell Jesup, Valentin Gosu, Olli Pettay, and the Mozilla Fuzzing Team reported memory safety bugs present in Thunderbird 102.5. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 108, Firefox ESR &lt; 102.6, and Thunderbird &lt; 102.6.&#xA;CVE-2022-46882:A use-after-free in WebGL extensions could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 107, Firefox ESR &lt; 102.6, and Thunderbird &lt; 102.6.&#xA;CVE-2023-0767:An attacker could construct a PKCS 12 cert bundle in such a way that could allow for arbitrary memory writes via PKCS 12 Safe Bag attributes being mishandled. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-1945:Unexpected data returned from the Safe Browsing API could have led to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird &lt; 102.10 and Firefox ESR &lt; 102.10.&#xA;CVE-2023-1999:There exists a use after free/double free in libwebp. An attacker can use the ApplyFiltersAndEncode() function and loop through to free best.bw and assign best = trial pointer. The second loop will then return 0 because of an Out of memory error in VP8 encoder, the pointer is still assigned to trial and the AddressSanitizer will attempt a double free.&#xA;CVE-2023-23598:Due to the Firefox GTK wrapper code&#39;s use of text/plain for drag data and GTK treating all text/plain MIMEs containing file URLs as being dragged a website could arbitrarily read a file via a call to &lt;code&gt;DataTransfer.setData&lt;/code&gt;. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-23599:When copying a network request from the developer tools panel as a curl command the output was not being properly sanitized and could allow arbitrary commands to be hidden within. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-23601:Navigations were being allowed when dragging a URL from a cross-origin iframe into the same tab which could lead to website spoofing attacks. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-23602:A mishandled security check when creating a WebSocket in a WebWorker caused the Content Security Policy connect-src header to be ignored. This could lead to connections to restricted origins from inside WebWorkers. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-23603:Regular expressions used to filter out forbidden properties and values from style directives in calls to &lt;code&gt;console.log&lt;/code&gt; weren&#39;t accounting for external URLs. Data could then be potentially exfiltrated from the browser. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-25728:The &lt;code&gt;Content-Security-Policy-Report-Only&lt;/code&gt; header could allow an attacker to leak a child iframe&#39;s unredacted URI when interaction with that iframe triggers a redirect. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25729:Permission prompts for opening external schemes were only shown for &lt;code&gt;ContentPrincipals&lt;/code&gt; resulting in extensions being able to open them without user interaction via &lt;code&gt;ExpandedPrincipals&lt;/code&gt;. This could lead to further malicious actions such as downloading files or interacting with software already installed on the system. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25730:A background script invoking &lt;code&gt;requestFullscreen&lt;/code&gt; and then blocking the main thread could force the browser into fullscreen mode indefinitely, resulting in potential user confusion or spoofing attacks. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25732:When encoding data from an &lt;code&gt;inputStream&lt;/code&gt; in &lt;code&gt;xpcom&lt;/code&gt; the size of the input being encoded was not correctly calculated potentially leading to an out of bounds memory write. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25735:Cross-compartment wrappers wrapping a scripted proxy could have caused objects from other compartments to be stored in the main compartment resulting in a use-after-free after unwrapping the proxy. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25737:An invalid downcast from &lt;code&gt;nsTextNode&lt;/code&gt; to &lt;code&gt;SVGElement&lt;/code&gt; could have lead to undefined behavior. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25739:Module load requests that failed were not being checked as to whether or not they were cancelled causing a use-after-free in &lt;code&gt;ScriptLoadContext&lt;/code&gt;. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25742:When importing a SPKI RSA public key as ECDSA P-256, the key would be handled incorrectly causing the tab to crash. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.&#xA;CVE-2023-25751:Sometimes, when invalidating JIT code while following an iterator, the newly generated code could be overwritten incorrectly. This could lead to a potentially exploitable crash. This vulnerability affects Firefox &lt; 111, Firefox ESR &lt; 102.9, and Thunderbird &lt; 102.9.&#xA;CVE-2023-25752:When accessing throttled streams, the count of available bytes needed to be checked in the calling function to be within bounds. This may have lead future code to be incorrect and vulnerable. This vulnerability affects Firefox &lt; 111, Firefox ESR &lt; 102.9, and Thunderbird &lt; 102.9.&#xA;CVE-2023-28162:While implementing AudioWorklets, some code may have casted one type to another, invalid, dynamic type. This could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 111, Firefox ESR &lt; 102.9, and Thunderbird &lt; 102.9.&#xA;CVE-2023-28164:Dragging a URL from a cross-origin iframe that was removed during the drag could have led to user confusion and website spoofing attacks. This vulnerability affects Firefox &lt; 111, Firefox ESR &lt; 102.9, and Thunderbird &lt; 102.9.&#xA;CVE-2023-28176:Mozilla developers Timothy Nikkel, Andrew McCreight, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 110 and Firefox ESR 102.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 111, Firefox ESR &lt; 102.9, and Thunderbird &lt; 102.9.&#xA;CVE-2023-29531:An attacker could have caused an out of bounds memory access using WebGL APIs, leading to memory corruption and a potentially exploitable crash.&#xA;*This bug only affects Firefox and Thunderbird for macOS. Other operating systems are unaffected.* This vulnerability affects Firefox &lt; 112, Firefox ESR &lt; 102.10, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29532:A local attacker can trick the Mozilla Maintenance Service into applying an unsigned update file by pointing the service at an update file on a malicious SMB server. The update file can be replaced after the signature check, before the use, because the write-lock requested by the service does not work on a SMB server.&#xA;*Note: This attack requires local system access and only affects Windows. Other operating systems are not affected.* This vulnerability affects Firefox &lt; 112, Firefox ESR &lt; 102.10, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29533:A website could have obscured the fullscreen notification by using a combination of &lt;code&gt;window.open&lt;/code&gt;, fullscreen requests, &lt;code&gt;window.name&lt;/code&gt; assignments, and &lt;code&gt;setInterval&lt;/code&gt; calls. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29535:Following a Garbage Collector compaction, weak maps may have been accessed before they were correctly traced. This resulted in memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29536:An attacker could cause the memory manager to incorrectly free a pointer that addresses attacker-controlled memory, resulting in an assertion, memory corruption, or a potentially exploitable crash. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29539:When handling the filename directive in the Content-Disposition header, the filename would be truncated if the filename contained a NULL character. This could have led to reflected file download attacks potentially tricking users to install malware. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29541:Firefox did not properly handle downloads of files ending in &lt;code&gt;.desktop&lt;/code&gt;, which can be interpreted to run attacker-controlled commands. &lt;br&gt;*This bug only affects Firefox for Linux on certain Distributions. Other operating systems are unaffected, and Mozilla is unable to enumerate all affected Linux Distributions.*. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29542:A newline in a filename could have been used to bypass the file extension security mechanisms that replace malicious file extensions such as .lnk  with .download. This could have led to accidental execution of malicious code.&#xA;*This bug only affects Firefox and Thunderbird on Windows. Other versions of Firefox and Thunderbird are unaffected.* This vulnerability affects Firefox &lt; 112, Firefox ESR &lt; 102.10, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29545:Similar to CVE-2023-28163, this time when choosing &#39;Save Link As&#39;, suggested filenames containing environment variable names would have resolved those in the context of the current user. &#xA;*This bug only affects Firefox and Thunderbird on Windows. Other versions of Firefox and Thunderbird are unaffected.* This vulnerability affects Firefox &lt; 112, Firefox ESR &lt; 102.10, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29548:A wrong lowering instruction in the ARM64 Ion compiler resulted in a wrong optimization result. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-29550:Mozilla developers Randell Jesup, Andrew Osmond, Sebastian Hengst, Andrew McCreight, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 111 and Firefox ESR 102.9. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 112, Focus for Android &lt; 112, Firefox ESR &lt; 102.10, Firefox for Android &lt; 112, and Thunderbird &lt; 102.10.&#xA;CVE-2023-32205:In multiple cases browser prompts could have been obscured by popups controlled by content. These could have led to potential user confusion and spoofing attacks. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32206:An out-of-bound read could have led to a crash in the RLBox Expat driver. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32207:A missing delay in popup notifications could have made it possible for an attacker to trick a user into granting permissions. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32211:A type checking bug would have led to invalid code being compiled. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32212:An attacker could have positioned a &lt;code&gt;datalist&lt;/code&gt; element to obscure the address bar. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32213:When reading a file, an uninitialized value could have been used as read limit. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32214:Protocol handlers `ms-cxh` and `ms-cxh-full` could have been leveraged to trigger a denial of service.&#xA;*Note: This attack only affects Windows. Other operating systems are not affected.* This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-32215:Mozilla developers and community members Gabriele Svelto, Andrew Osmond, Emily McDonough, Sebastian Hengst, Andrew McCreight and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 112 and Firefox ESR 102.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 113, Firefox ESR &lt; 102.11, and Thunderbird &lt; 102.11.&#xA;CVE-2023-34414:The error page for sites with invalid TLS certificates was missing the&#xA;activation-delay Firefox uses to protect prompts and permission dialogs&#xA;from attacks that exploit human response time delays. If a malicious&#xA;page elicited user clicks in precise locations immediately before&#xA;navigating to a site with a certificate error and made the renderer&#xA;extremely busy at the same time, it could create a gap between when&#xA;the error page was loaded and when the display actually refreshed.&#xA;With the right timing the elicited clicks could land in that gap and &#xA;activate the button that overrides the certificate error for that site. This vulnerability affects Firefox ESR &lt; 102.12, Firefox &lt; 114, and Thunderbird &lt; 102.12.&#xA;CVE-2023-34416:Memory safety bugs present in Firefox 113, Firefox ESR 102.11, and Thunderbird 102.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 102.12, Firefox &lt; 114, and Thunderbird &lt; 102.12.&#xA;CVE-2023-37201:An attacker could have triggered a use-after-free condition when creating a WebRTC connection over HTTPS. This vulnerability affects Firefox &lt; 115, Firefox ESR &lt; 102.13, and Thunderbird &lt; 102.13.&#xA;CVE-2023-37202:Cross-compartment wrappers wrapping a scripted proxy could have caused objects from other compartments to be stored in the main compartment resulting in a use-after-free. This vulnerability affects Firefox &lt; 115, Firefox ESR &lt; 102.13, and Thunderbird &lt; 102.13.&#xA;CVE-2023-37207:A website could have obscured the fullscreen notification by using a URL with a scheme handled by an external program, such as a mailto URL. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 115, Firefox ESR &lt; 102.13, and Thunderbird &lt; 102.13.&#xA;CVE-2023-37208:When opening Diagcab files, Firefox did not warn the user that these files may contain malicious code. This vulnerability affects Firefox &lt; 115, Firefox ESR &lt; 102.13, and Thunderbird &lt; 102.13.&#xA;CVE-2023-37211:Memory safety bugs present in Firefox 114, Firefox ESR 102.12, and Thunderbird 102.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 115, Firefox ESR &lt; 102.13, and Thunderbird &lt; 102.13.&#xA;CVE-2023-4045:Offscreen Canvas did not properly track cross-origin tainting, which could have been used to access image data from another site in violation of same-origin policy. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4046:In some circumstances, a stale value could have been used for a global variable in WASM JIT analysis. This resulted in incorrect compilation and a potentially exploitable crash in the content process. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4047:A bug in popup notifications delay calculation could have made it possible for an attacker to trick a user into granting permissions. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4048:An out-of-bounds read could have led to an exploitable crash when parsing HTML with DOMParser in low memory situations. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4049:Race conditions in reference counting code were found through code inspection. These could have resulted in potentially exploitable use-after-free vulnerabilities. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4050:In some cases, an untrusted input stream was copied to a stack buffer without checking its size. This resulted in a potentially exploitable crash which could have led to a sandbox escape. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4054:When opening appref-ms files, Firefox did not warn the user that these files may contain malicious code. &#xA;*This bug only affects Firefox on Windows. Other operating systems are unaffected.* This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, Firefox ESR &lt; 115.1, Thunderbird &lt; 102.14, and Thunderbird &lt; 115.1.&#xA;CVE-2023-4055:When the number of cookies per domain was exceeded in `document.cookie`, the actual cookie jar sent to the host was no longer consistent with expected cookie jar state. This could have caused requests to be sent with some cookies missing. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.&#xA;CVE-2023-4056:Memory safety bugs present in Firefox 115, Firefox ESR 115.0, Firefox ESR 102.13, Thunderbird 115.0, and Thunderbird 102.13. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 102.14, and Firefox ESR &lt; 115.1.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="firefox" release="1.u3.fos23" version="102.14.0">
					<filename>firefox-102.14.0-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/firefox-102.14.0-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="firefox" release="1.u3.fos23" version="102.14.0">
					<filename>firefox-102.14.0-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/firefox-102.14.0-1.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2240</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39350" id="CVE-2023-39350" title="CVE-2023-39350" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39351" id="CVE-2023-39351" title="CVE-2023-39351" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39352" id="CVE-2023-39352" title="CVE-2023-39352" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39353" id="CVE-2023-39353" title="CVE-2023-39353" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39354" id="CVE-2023-39354" title="CVE-2023-39354" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39356" id="CVE-2023-39356" title="CVE-2023-39356" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40181" id="CVE-2023-40181" title="CVE-2023-40181" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40186" id="CVE-2023-40186" title="CVE-2023-40186" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40188" id="CVE-2023-40188" title="CVE-2023-40188" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40567" id="CVE-2023-40567" title="CVE-2023-40567" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40569" id="CVE-2023-40569" title="CVE-2023-40569" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40589" id="CVE-2023-40589" title="CVE-2023-40589" type="cve"></reference>
		</references>
		<description>CVE-2023-39350:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. This issue affects Clients only. Integer underflow leading to DOS (e.g. abort due to `WINPR_ASSERT` with default compilation flags). When an insufficient blockLen is provided, and proper length validation is not performed, an Integer Underflow occurs, leading to a Denial of Service (DOS) vulnerability. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-39351:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions of FreeRDP are subject to a Null Pointer Dereference leading a crash in the RemoteFX (rfx) handling.  Inside the `rfx_process_message_tileset` function, the program allocates tiles using `rfx_allocate_tiles` for the number of numTiles. If the initialization process of tiles is not completed for various reasons, tiles will have a NULL pointer. Which may be accessed in further processing and would cause a program crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-39352:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an invalid offset validation leading to Out Of Bound Write. This can be triggered when the values `rect-&gt;left` and `rect-&gt;top` are exactly equal to `surface-&gt;width` and  `surface-&gt;height`. eg. `rect-&gt;left` == `surface-&gt;width` &amp;&amp; `rect-&gt;top` == `surface-&gt;height`. In practice this should cause a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-39353:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to a missing offset validation leading to Out Of Bound Read. In the `libfreerdp/codec/rfx.c` file there is no offset validation in `tile-&gt;quantIdxY`, `tile-&gt;quantIdxCb`, and `tile-&gt;quantIdxCr`. As a result crafted input can lead to an out of bounds read access which in turn will cause a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-39354:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an Out-Of-Bounds Read in the `nsc_rle_decompress_data` function. The Out-Of-Bounds Read occurs because it processes `context-&gt;Planes` without  checking if it contains data of sufficient length. Should an attacker be able to leverage this vulnerability they may be able to cause a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-39356:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. In affected versions a missing offset validation may lead to an Out Of Bound Read in the function `gdi_multi_opaque_rect`. In particular there is no code to validate if the value `multi_opaque_rect-&gt;numRectangles` is less than 45. Looping through `multi_opaque_rect-&gt;`numRectangles without proper boundary checks can lead to Out-of-Bounds Read errors which will likely lead to a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-40181:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an Integer-Underflow leading to Out-Of-Bound Read in the `zgfx_decompress_segment` function. In the context of `CopyMemory`, it&#39;s possible to read data beyond the transmitted packet range and likely cause a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this issue.&#xA;CVE-2023-40186:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an IntegerOverflow leading to Out-Of-Bound Write Vulnerability in the `gdi_CreateSurface` function. This issue affects FreeRDP based clients only. FreeRDP proxies are not affected as image decoding is not done by a proxy. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this issue.&#xA;CVE-2023-40188:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an Out-Of-Bounds Read in the `general_LumaToYUV444` function. This Out-Of-Bounds Read occurs because processing is done on the `in` variable without checking if it contains data of sufficient length. Insufficient data for the `in` variable may cause errors or crashes. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this issue.&#xA;CVE-2023-40567:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an Out-Of-Bounds Write in the `clear_decompress_bands_data` function in which there is no offset validation. Abuse of this vulnerability may lead to an out of bounds write. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. there are no known workarounds for this vulnerability.&#xA;CVE-2023-40569:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an Out-Of-Bounds Write in the `progressive_decompress` function. This issue is likely down to incorrect calculations of the `nXSrc` and `nYSrc` variables. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. there are no known workarounds for this vulnerability.&#xA;CVE-2023-40589:FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. In affected versions there is a Global-Buffer-Overflow in the ncrush_decompress function. Feeding crafted input into this function can trigger the overflow which has only been shown to cause a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="2" name="freerdp" release="1.fos23" version="2.11.1">
					<filename>freerdp-2.11.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/freerdp-2.11.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-devel" release="1.fos23" version="2.11.1">
					<filename>freerdp-devel-2.11.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/freerdp-devel-2.11.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr" release="1.fos23" version="2.11.1">
					<filename>libwinpr-2.11.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libwinpr-2.11.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr-devel" release="1.fos23" version="2.11.1">
					<filename>libwinpr-devel-2.11.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libwinpr-devel-2.11.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-help" release="1.fos23" version="2.11.1">
					<filename>freerdp-help-2.11.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/freerdp-help-2.11.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp" release="1.fos23" version="2.11.1">
					<filename>freerdp-2.11.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/freerdp-2.11.1-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-devel" release="1.fos23" version="2.11.1">
					<filename>freerdp-devel-2.11.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/freerdp-devel-2.11.1-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr" release="1.fos23" version="2.11.1">
					<filename>libwinpr-2.11.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libwinpr-2.11.1-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr-devel" release="1.fos23" version="2.11.1">
					<filename>libwinpr-devel-2.11.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libwinpr-devel-2.11.1-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-help" release="1.fos23" version="2.11.1">
					<filename>freerdp-help-2.11.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/freerdp-help-2.11.1-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2241</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36664" id="CVE-2023-36664" title="CVE-2023-36664" type="cve"></reference>
		</references>
		<description>CVE-2023-36664:Artifex Ghostscript through 10.01.2 mishandles permission validation for pipe devices (with the %pipe% prefix or the | pipe character prefix).</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ghostscript-9.55.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ghostscript-devel-9.55.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ghostscript-help-9.55.0-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/ghostscript-tools-dvipdf-9.55.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ghostscript-9.55.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ghostscript-devel-9.55.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="5.u3.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/ghostscript-tools-dvipdf-9.55.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2242</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39742" id="CVE-2023-39742" title="CVE-2023-39742" type="cve"></reference>
		</references>
		<description>CVE-2023-39742:giflib v5.2.1 was discovered to contain a segmentation fault via the component getarg.c.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="giflib" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-5.2.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/giflib-5.2.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-devel" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/giflib-devel-5.2.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-utils" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/giflib-utils-5.2.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="giflib-help" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-help-5.2.1-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/giflib-help-5.2.1-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-5.2.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/giflib-5.2.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-devel" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/giflib-devel-5.2.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-utils" release="6.u1.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/giflib-utils-5.2.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2243</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29409" id="CVE-2023-29409" title="CVE-2023-29409" type="cve"></reference>
		</references>
		<description>CVE-2023-29409:Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted to &lt;= 8192 bits. Based on a survey of publicly trusted RSA keys, there are currently only three certificates in circulation with keys larger than this, and all three appear to be test certificates that are not actively deployed. It is possible there are larger keys in use in private PKIs, but we target the web PKI, so causing breakage here in the interests of increasing the default safety of users of crypto/tls seems reasonable.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u6.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/golang-1.20.5-3.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u6.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/golang-help-1.20.5-3.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u6.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/golang-devel-1.20.5-3.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u6.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/golang-1.20.5-3.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2244</id>
		<title>An update for gstreamer1-plugins-bad-free is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37329" id="CVE-2023-37329" title="CVE-2023-37329" type="cve"></reference>
		</references>
		<description>CVE-2023-37329:Heap overwrite in PGS subtitle overlay decoder.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-bad-free" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-1.16.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-bad-free-1.16.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-bad-free-devel" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-devel-1.16.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-bad-free-devel-1.16.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-bad-free" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-1.16.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/gstreamer1-plugins-bad-free-1.16.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-bad-free-devel" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-devel-1.16.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/gstreamer1-plugins-bad-free-devel-1.16.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2245</id>
		<title>An update for gstreamer1-plugins-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37328" id="CVE-2023-37328" title="CVE-2023-37328" type="cve"></reference>
		</references>
		<description>CVE-2023-37327:Integer overflow leading to heap overwrite in FLAC image tag handling.&#xA;CVE-2023-37328:Heap overwrite in subtitle parsing.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base" release="3.u1.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-base-1.18.4-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base-devel" release="3.u1.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-base-devel-1.18.4-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-base-help" release="3.u1.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-help-1.18.4-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-base-help-1.18.4-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base" release="3.u1.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/gstreamer1-plugins-base-1.18.4-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base-devel" release="3.u1.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/gstreamer1-plugins-base-devel-1.18.4-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2246</id>
		<title>An update for gstreamer1-plugins-good is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"></reference>
		</references>
		<description>CVE-2023-37327:Integer overflow leading to heap overwrite in FLAC image tag handling.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-good-1.16.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good-gtk" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-good-gtk-1.16.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-good-help" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-help-1.16.2-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/gstreamer1-plugins-good-help-1.16.2-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/gstreamer1-plugins-good-1.16.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good-gtk" release="5.u1.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/gstreamer1-plugins-good-gtk-1.16.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2247</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21549" id="CVE-2022-21549" title="CVE-2022-21549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21830" id="CVE-2023-21830" title="CVE-2023-21830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"></reference>
		</references>
		<description>CVE-2022-21549:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 17.0.3.1; Oracle GraalVM Enterprise Edition: 21.3.2 and 22.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2022-40433:An issue was discovered in function ciMethodBlocks::make_block_at in Oracle JDK (HotSpot VM) 11, 17 and OpenJDK (HotSpot VM) 8, 11, 17, allows attackers to cause a denial of service.&#xA;CVE-2023-21830:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf; Oracle GraalVM Enterprise Edition: 20.3.8 and  21.3.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-21843:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Sound).  Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf, 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-21930:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2023-21937:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-21938:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-21939:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21954:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21967:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21968:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-22045:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.&#xA;CVE-2023-22049:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-headless-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-headless-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-devel-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-demo-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-demo-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-src-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-src-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.382.b05-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-javadoc-1.8.0.382.b05-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.382.b05-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-javadoc-zip-1.8.0.382.b05-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-accessibility-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-devel-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-headless-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-headless-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-devel-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-demo-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-demo-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-src-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-src-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-accessibility-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-devel-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="8.u1.fos23" version="1.8.0.382.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.382.b05-8.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2248</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21835" id="CVE-2023-21835" title="CVE-2023-21835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22006" id="CVE-2023-22006" title="CVE-2023-22006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22036" id="CVE-2023-22036" title="CVE-2023-22036" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22041" id="CVE-2023-22041" title="CVE-2023-22041" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"></reference>
		</references>
		<description>CVE-2022-40433:An issue was discovered in function ciMethodBlocks::make_block_at in Oracle JDK (HotSpot VM) 11, 17 and OpenJDK (HotSpot VM) 8, 11, 17, allows attackers to cause a denial of service.&#xA;CVE-2023-21835:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via DTLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).&#xA;CVE-2023-21843:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Sound).  Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf, 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-21930:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21937:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21938:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-21939:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21954:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21967:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-21968:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.&#xA;CVE-2023-22006:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2023-22036:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Utility).  Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.&#xA;CVE-2023-22041:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-22045:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.&#xA;CVE-2023-22049:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-headless-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-headless-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-headless-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-devel-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-devel-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-devel-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-jmods-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-jmods-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-jmods-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-demo-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-demo-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-demo-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-src-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-src-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-src-slowdebug-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-javadoc-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-javadoc-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.20.8-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/java-11-openjdk-javadoc-zip-11.0.20.8-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-headless-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-headless-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-headless-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-devel-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-devel-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-devel-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-jmods-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-jmods-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-jmods-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-demo-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-demo-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-demo-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-src-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-src-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-src-slowdebug-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-javadoc-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-javadoc-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="2.fos23" version="11.0.20.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.20.8-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/java-11-openjdk-javadoc-zip-11.0.20.8-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2249</id>
		<title>An update for jettison is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1436" id="CVE-2023-1436" title="CVE-2023-1436" type="cve"></reference>
		</references>
		<description>CVE-2022-45685:A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data.&#xA;CVE-2023-1436:An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="0" name="jettison" release="1.u3.fos23" version="1.3.7">
					<filename>jettison-1.3.7-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/jettison-1.3.7-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jettison-javadoc" release="1.u3.fos23" version="1.3.7">
					<filename>jettison-javadoc-1.3.7-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/jettison-javadoc-1.3.7-1.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2250</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1206" id="CVE-2023-1206" title="CVE-2023-1206" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20593" id="CVE-2023-20593" title="CVE-2023-20593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34319" id="CVE-2023-34319" title="CVE-2023-34319" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38432" id="CVE-2023-38432" title="CVE-2023-38432" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40283" id="CVE-2023-40283" title="CVE-2023-40283" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4194" id="CVE-2023-4194" title="CVE-2023-4194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32250" id="CVE-2023-32250" title="CVE-2023-32250" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32252" id="CVE-2023-32252" title="CVE-2023-32252" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32257" id="CVE-2023-32257" title="CVE-2023-32257" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3865" id="CVE-2023-3865" title="CVE-2023-3865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4273" id="CVE-2023-4273" title="CVE-2023-4273" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32247" id="CVE-2023-32247" title="CVE-2023-32247" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32249" id="CVE-2023-32249" title="CVE-2023-32249" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32251" id="CVE-2023-32251" title="CVE-2023-32251" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32253" id="CVE-2023-32253" title="CVE-2023-32253" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3777" id="CVE-2023-3777" title="CVE-2023-3777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3866" id="CVE-2023-3866" title="CVE-2023-3866" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4015" id="CVE-2023-4015" title="CVE-2023-4015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4622" id="CVE-2023-4622" title="CVE-2023-4622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4623" id="CVE-2023-4623" title="CVE-2023-4623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45884" id="CVE-2022-45884" title="CVE-2022-45884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45887" id="CVE-2022-45887" title="CVE-2022-45887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2156" id="CVE-2023-2156" title="CVE-2023-2156" type="cve"></reference>
		</references>
		<description>CVE-2023-1206:A hash collision flaw was found in the IPv6 connection lookup table in the Linux kernel’s IPv6 functionality when a user makes a new kind of SYN flood attack. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%.&#xA;CVE-2023-20593:An issue in “Zen 2” CPUs, under specific microarchitectural circumstances, may allow an attacker to potentially access sensitive information.&#xA;CVE-2023-34319:A buffer overrun vulnerability was found in the netback driver in Xen due to an unusual split packet. This flaw allows an unprivileged guest to cause a denial of service (DoS) of the host by sending network packets to the backend, causing the backend to crash.&#xA;CVE-2023-38432:An issue was discovered in the Linux kernel before 6.3.10. fs/smb/server/smb2misc.c in ksmbd does not validate the relationship between the command payload size and the RFC1002 length specification, leading to an out-of-bounds read.&#xA;CVE-2023-40283:An issue was discovered in l2cap_sock_release in net/bluetooth/l2cap_sock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.&#xA;CVE-2023-4194:A flaw was found in the Linux kernel&#39;s TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 (&#34;tun: tun_chr_open(): correctly initialize socket uid&#34;), - 66b2c338adce (&#34;tap: tap_open(): correctly initialize socket uid&#34;), pass &#34;inode-&gt;i_uid&#34; to sock_init_data_uid() as the last parameter and that turns out to not be accurate.&#xA;CVE-2023-32250:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.&#xA;CVE-2023-32252:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_LOGOFF commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.&#xA;CVE-2023-32257:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP and SMB2_LOGOFF commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.&#xA;CVE-2023-3865:This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication may or may not be required to exploit this vulnerability, depending upon configuration. Furthermore, only systems with ksmbd enabled are vulnerable.&#xA;CVE-2023-4273:A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack.&#xA;CVE-2023-32247:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_SESSION_SETUP commands. The issue results from the lack of control of resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.&#xA;CVE-2023-32249:Linux Kernel ksmbd Multichannel Improper Authentication Session Hijack Vulnerability.&#xA;CVE-2023-32251:A vulnerability classified as problematic has been found in Linux Kernel up to 6.3 (Operating System). Affected is the function smb2_sess_setup of the file fs/ksmbd/smb2pdu.c of the component ksmbd. The manipulation with an unknown input leads to a improper authentication vulnerability.&#xA;CVE-2023-32253:Linux Kernel ksmbd Session Deadlock Denial-of-Service Vulnerability&#xA;CVE-2023-3777:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.&#xA;When nf_tables_delrule() is flushing table rules, it is not checked whether the chain is bound and the chain&#39;s owner rule can also release the objects in certain circumstances.&#xA;We recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8.&#xA;CVE-2023-3866:A vulnerability classified as critical was found in Linux Kernel (Operating System) (version now known). This vulnerability affects some unknown processing of the component ksmbd. The manipulation with an unknown input leads to a null pointer dereference vulnerability.&#xA;CVE-2023-4015:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.&#xA;On an error when building a nftables rule, deactivating immediate expressions in nft_immediate_deactivate() can lead unbinding the chain and objects be deactivated but later used.&#xA;CVE-2023-4622:A use-after-free vulnerability in the Linux kernel&#39;s af_unix component can be exploited to achieve local privilege escalation.&#xA;The unix_stream_sendpage() function tries to add data to the last skb in the peer&#39;s recv queue without locking the queue. Thus there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.&#xA;CVE-2023-4623:A use-after-free vulnerability in the Linux kernel&#39;s net/sched: sch_hfsc (HFSC qdisc traffic control) component can be exploited to achieve local privilege escalation.&#xA;If a class with a link-sharing curve (i.e. with the HFSC_FSC flag set) has a parent without a link-sharing curve, then init_vf() will call vttree_insert() on the parent, but vttree_remove() will be skipped in update_vf(). This leaves a dangling pointer that can cause a use-after-free.&#xA;CVE-2022-45884:An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvbdev.c has a use-after-free, related to dvb_register_device dynamically allocating fops.&#xA;CVE-2022-45887:An issue was discovered in the Linux kernel through 6.0.9. drivers/media/usb/ttusb-dec/ttusb_dec.c has a memory leak because of the lack of a dvb_frontend_detach call.&#xA;CVE-2023-2156:A flaw was found in the networking subsystem of the Linux kernel within the handling of the RPL protocol. This issue results from the lack of proper handling of user-supplied data, which can lead to an assertion failure. This may allow an unauthenticated remote attacker to create a denial of service condition on the system.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/kernel-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/kernel-headers-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/kernel-devel-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/kernel-tools-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/kernel-tools-devel-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/perf-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-perf-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/bpftool-5.10.0-136.49.0.127.u85.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/kernel-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/kernel-headers-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/kernel-devel-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/kernel-tools-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/kernel-tools-devel-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/perf-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-perf-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.49.0.127.u85.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/bpftool-5.10.0-136.49.0.127.u85.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2251</id>
		<title>An update for libpq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21469" id="CVE-2020-21469" title="CVE-2020-21469" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2454" id="CVE-2023-2454" title="CVE-2023-2454" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2455" id="CVE-2023-2455" title="CVE-2023-2455" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39418" id="CVE-2023-39418" title="CVE-2023-39418" type="cve"></reference>
		</references>
		<description>CVE-2020-21469:An issue was discovered in PostgreSQL 12.2 allows attackers to cause a denial of service via repeatedly sending SIGHUP signals. NOTE: this is disputed by the vendor because untrusted users cannot send SIGHUP signals; they can only be sent by a PostgreSQL superuser, a user with pg_reload_conf access, or a user with sufficient privileges at the OS level (the postgres account or the root account).&#xA;CVE-2023-2454:schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.&#xA;CVE-2023-2455:Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.&#xA;CVE-2023-39417:IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, &#39;&#39;, or &#34;&#34;). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.&#xA;CVE-2023-39418:A vulnerability was found in PostgreSQL with the use of the MERGE command, which fails to test new rows against row security policies defined for UPDATE and SELECT. If UPDATE and SELECT policies forbid some rows that INSERT policies do not forbid, a user could store such rows.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="libpq" release="1.u1.fos23" version="13.12">
					<filename>libpq-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libpq-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libpq-devel" release="1.u1.fos23" version="13.12">
					<filename>libpq-devel-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libpq-devel-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libpq" release="1.u1.fos23" version="13.12">
					<filename>libpq-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libpq-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libpq-devel" release="1.u1.fos23" version="13.12">
					<filename>libpq-devel-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libpq-devel-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2252</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38710" id="CVE-2023-38710" title="CVE-2023-38710" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38711" id="CVE-2023-38711" title="CVE-2023-38711" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38712" id="CVE-2023-38712" title="CVE-2023-38712" type="cve"></reference>
		</references>
		<description>CVE-2023-38710:An issue was discovered in Libreswan before 4.12. When an IKEv2 Child SA REKEY packet contains an invalid IPsec protocol ID number of 0 or 1, an error notify INVALID_SPI is sent back. The notify payload&#39;s protocol ID is copied from the incoming packet, but the code that verifies outgoing packets fails an assertion that the protocol ID must be ESP (2) or AH(3) and causes the pluto daemon to crash and restart. NOTE: the earliest affected version is 3.20.&#xA;CVE-2023-38711:An issue was discovered in Libreswan before 4.12. When an IKEv1 Quick Mode connection configured with ID_IPV4_ADDR or ID_IPV6_ADDR receives an IDcr payload with ID_FQDN, a NULL pointer dereference causes a crash and restart of the pluto daemon. NOTE: the earliest affected version is 4.6.&#xA;CVE-2023-38712:An issue was discovered in Libreswan 3.x and 4.x before 4.12. When an IKEv1 ISAKMP SA Informational Exchange packet contains a Delete/Notify payload followed by further Notifies that act on the ISAKMP SA, such as a duplicated Delete/Notify message, a NULL pointer dereference on the deleted state causes the pluto daemon to crash and restart.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.12">
					<filename>libreswan-4.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libreswan-4.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.12">
					<filename>libreswan-help-4.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libreswan-help-4.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.12">
					<filename>libreswan-4.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libreswan-4.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.12">
					<filename>libreswan-help-4.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libreswan-help-4.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2253</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34526" id="CVE-2022-34526" title="CVE-2022-34526" type="cve"></reference>
		</references>
		<description>CVE-2022-34526:A stack overflow was discovered in the _TIFFVGetField function of Tiffsplit v4.4.0. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted TIFF file parsed by the &#34;tiffsplit&#34; or &#34;tiffcrop&#34; utilities.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-33.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtiff-4.3.0-33.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-33.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtiff-devel-4.3.0-33.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-33.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtiff-static-4.3.0-33.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-33.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtiff-tools-4.3.0-33.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-33.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtiff-help-4.3.0-33.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-33.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtiff-4.3.0-33.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-33.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtiff-devel-4.3.0-33.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-33.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtiff-static-4.3.0-33.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="33.u9.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-33.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtiff-tools-4.3.0-33.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2254</id>
		<title>An update for libtommath is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36328" id="CVE-2023-36328" title="CVE-2023-36328" type="cve"></reference>
		</references>
		<description>CVE-2023-36328:Integer Overflow vulnerability in mp_grow in libtom libtommath before commit beba892bc0d4e4ded4d667ab1d2a94f4d75109a9, allows attackers to execute arbitrary code and cause a denial of service (DoS).</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="libtommath" release="4.u2.fos23" version="1.2.0">
					<filename>libtommath-1.2.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtommath-1.2.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtommath-devel" release="4.u2.fos23" version="1.2.0">
					<filename>libtommath-devel-1.2.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtommath-devel-1.2.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtommath-help" release="4.u2.fos23" version="1.2.0">
					<filename>libtommath-help-1.2.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/libtommath-help-1.2.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtommath" release="4.u2.fos23" version="1.2.0">
					<filename>libtommath-1.2.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtommath-1.2.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtommath-devel" release="4.u2.fos23" version="1.2.0">
					<filename>libtommath-devel-1.2.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtommath-devel-1.2.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtommath-help" release="4.u2.fos23" version="1.2.0">
					<filename>libtommath-help-1.2.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/libtommath-help-1.2.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2255</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33196" id="CVE-2022-33196" title="CVE-2022-33196" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38090" id="CVE-2022-38090" title="CVE-2022-38090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40982" id="CVE-2022-40982" title="CVE-2022-40982" type="cve"></reference>
		</references>
		<description>CVE-2022-33196:Incorrect default permissions in some memory controller configurations for some Intel(R) Xeon(R) Processors when using Intel(R) Software Guard Extensions which may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2022-38090:Improper isolation of shared resources in some Intel(R) Processors when using Intel(R) Software Guard Extensions may allow a privileged user to potentially enable information disclosure via local access.&#xA;CVE-2022-40982:Information exposure through microarchitectural state after transient execution in certain vector execution units for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="41.fos23" version="2.1">
					<filename>microcode_ctl-2.1-41.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/microcode_ctl-2.1-41.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2256</id>
		<title>An update for nasm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21528" id="CVE-2020-21528" title="CVE-2020-21528" type="cve"></reference>
		</references>
		<description>CVE-2020-21528:A Segmentation Fault issue discovered in in ieee_segment function in outieee.c in nasm 2.14.03 and 2.15 allows remote attackers to cause a denial of service via crafted assembly file.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="nasm" release="6.u3.fos23" version="2.15.05">
					<filename>nasm-2.15.05-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nasm-2.15.05-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nasm-help" release="6.u3.fos23" version="2.15.05">
					<filename>nasm-help-2.15.05-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nasm-help-2.15.05-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nasm" release="6.u3.fos23" version="2.15.05">
					<filename>nasm-2.15.05-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/nasm-2.15.05-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2257</id>
		<title>An update for netty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41881" id="CVE-2022-41881" title="CVE-2022-41881" type="cve"></reference>
		</references>
		<description>CVE-2022-41881:Netty project is an event-driven asynchronous network application framework. In versions prior to 4.1.86.Final, a StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion. This issue is patched in version 4.1.86.Final. There is no workaround, except using a custom HaProxyMessageDecoder.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="netty" release="19.u1.fos23" version="4.1.13">
					<filename>netty-4.1.13-19.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/netty-4.1.13-19.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="netty-help" release="19.u1.fos23" version="4.1.13">
					<filename>netty-help-4.1.13-19.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/netty-help-4.1.13-19.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netty" release="19.u1.fos23" version="4.1.13">
					<filename>netty-4.1.13-19.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/netty-4.1.13-19.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2258</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25881" id="CVE-2022-25881" title="CVE-2022-25881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32212" id="CVE-2022-32212" title="CVE-2022-32212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32213" id="CVE-2022-32213" title="CVE-2022-32213" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32214" id="CVE-2022-32214" title="CVE-2022-32214" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32215" id="CVE-2022-32215" title="CVE-2022-32215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35256" id="CVE-2022-35256" title="CVE-2022-35256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23918" id="CVE-2023-23918" title="CVE-2023-23918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23920" id="CVE-2023-23920" title="CVE-2023-23920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30581" id="CVE-2023-30581" title="CVE-2023-30581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30589" id="CVE-2023-30589" title="CVE-2023-30589" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30590" id="CVE-2023-30590" title="CVE-2023-30590" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32002" id="CVE-2023-32002" title="CVE-2023-32002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32006" id="CVE-2023-32006" title="CVE-2023-32006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32559" id="CVE-2023-32559" title="CVE-2023-32559" type="cve"></reference>
		</references>
		<description>CVE-2022-25881:This affects versions of the package http-cache-semantics before 4.1.1. The issue can be exploited via malicious request header values sent to a server, when that server reads the cache policy from the request using this library.&#xA;CVE-2022-32212:A OS Command Injection vulnerability exists in Node.js versions &lt;14.20.0, &lt;16.20.0, &lt;18.5.0 due to an insufficient IsAllowedHost check that can easily be bypassed because IsIPAddress does not properly check if an IP address is invalid before making DBS requests allowing rebinding attacks.&#xA;CVE-2022-32213:The llhttp parser &lt;v14.20.1, &lt;v16.17.1 and &lt;v18.9.1 in the http module in Node.js does not correctly parse and validate Transfer-Encoding headers and can lead to HTTP Request Smuggling (HRS).&#xA;CVE-2022-32214:The llhttp parser &lt;v14.20.1, &lt;v16.17.1 and &lt;v18.9.1 in the http module in Node.js does not strictly use the CRLF sequence to delimit HTTP requests. This can lead to HTTP Request Smuggling (HRS).&#xA;CVE-2022-32215:The llhttp parser &lt;v14.20.1, &lt;v16.17.1 and &lt;v18.9.1 in the http module in Node.js does not correctly handle multi-line Transfer-Encoding headers. This can lead to HTTP Request Smuggling (HRS).&#xA;CVE-2022-35256:The llhttp parser in the http module in Node v18.7.0 does not correctly handle header fields that are not terminated with CLRF. This may result in HTTP Request Smuggling.&#xA;CVE-2023-23918:A privilege escalation vulnerability exists in Node.js &lt;19.6.1, &lt;18.14.1, &lt;16.19.1 and &lt;14.21.3 that made it possible to bypass the experimental Permissions (https://nodejs.org/api/permissions.html) feature in Node.js and access non authorized modules by using process.mainModule.require(). This only affects users who had enabled the experimental permissions option with --experimental-policy.&#xA;CVE-2023-23920:An untrusted search path vulnerability exists in Node.js. &lt;19.6.1, &lt;18.14.1, &lt;16.19.1, and &lt;14.21.3 that could allow an attacker to search and potentially load ICU data when running with elevated privileges.&#xA;CVE-2023-30581:The use of proto in process.mainModule.proto.require() can bypass the policy mechanism and require modules outside of the policy.json definition.&#xA;CVE-2023-30589:The llhttp parser in the http module in Node v20.2.0 does not strictly use the CRLF sequence to delimit HTTP requests. This can lead to HTTP Request Smuggling (HRS).&#xA;The CR character (without LF) is sufficient to delimit HTTP header fields in the llhttp parser. According to RFC7230 section 3, only the CRLF sequence should delimit each header-field. This impacts all Node.js active versions: v16, v18, and, v20&#xA;CVE-2023-30590:A vulnerability has been identified in the Node.js, where a generateKeys() API function returned from crypto.createDiffieHellman() only generates missing (or outdated) keys, that is, it only generates a private key if none has been set yet.&#xA;CVE-2023-32002:The use of `Module._load()` can bypass the policy mechanism and require modules outside of the policy.json definition for a given module.&#xA;This vulnerability affects all users using the experimental policy mechanism in all active release lines: 16.x, 18.x and, 20.x.&#xA;Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.&#xA;CVE-2023-32006:The use of `module.constructor.createRequire()` can bypass the policy mechanism and require modules outside of the policy.json definition for a given module.&#xA;This vulnerability affects all users using the experimental policy mechanism in all active release lines: 16.x, 18.x, and, 20.x.&#xA;Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.&#xA;CVE-2023-32559:A privilege escalation vulnerability exists in the experimental policy mechanism in all active release lines: 16.x, 18.x and, 20.x. The use of the deprecated API `process.binding()` can bypass the policy mechanism by requiring internal modules and eventually take advantage of `process.binding(&#39;spawn_sync&#39;)` run arbitrary code, outside of the limits defined in a `policy.json` file. Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="nodejs" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nodejs-12.22.11-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nodejs-devel-12.22.11-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nodejs-libs-12.22.11-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nodejs-full-i18n-12.22.11-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.5.u2.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/v8-devel-7.8.279.23-1.12.22.11.5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.5.u2.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/npm-6.14.16-1.12.22.11.5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-docs-12.22.11-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/nodejs-docs-12.22.11-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/nodejs-12.22.11-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/nodejs-devel-12.22.11-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/nodejs-libs-12.22.11-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="5.u2.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/nodejs-full-i18n-12.22.11-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.5.u2.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/v8-devel-7.8.279.23-1.12.22.11.5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.5.u2.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/npm-6.14.16-1.12.22.11.5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2259</id>
		<title>An update for open-vm-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20867" id="CVE-2023-20867" title="CVE-2023-20867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20900" id="CVE-2023-20900" title="CVE-2023-20900" type="cve"></reference>
		</references>
		<description>CVE-2023-20867:A fully compromised ESXi host can force VMware Tools to fail to authenticate host-to-guest operations, impacting the confidentiality and integrity of the guest virtual machine.&#xA;CVE-2023-20900:A malicious actor that has been granted  Guest Operation Privileges https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-6A952214-0E5E-4CCF-9D2A-90948FF643EC.html  in a target virtual machine may be able to elevate their privileges if that target virtual machine has been assigned a more privileged  Guest Alias https://vdc-download.vmware.com/vmwb-repository/dcr-public/d1902b0e-d479-46bf-8ac9-cee0e31e8ec0/07ce8dbd-db48-4261-9b8f-c6d3ad8ba472/vim.vm.guest.AliasManager.html .</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="open-vm-tools" release="3.u1.fos23" version="12.0.5">
					<filename>open-vm-tools-12.0.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/open-vm-tools-12.0.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-desktop" release="3.u1.fos23" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/open-vm-tools-desktop-12.0.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-sdmp" release="3.u1.fos23" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/open-vm-tools-sdmp-12.0.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools" release="3.u1.fos23" version="12.0.5">
					<filename>open-vm-tools-12.0.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/open-vm-tools-12.0.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-desktop" release="3.u1.fos23" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/open-vm-tools-desktop-12.0.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-sdmp" release="3.u1.fos23" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/open-vm-tools-sdmp-12.0.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2260</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31631" id="CVE-2022-31631" title="CVE-2022-31631" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0567" id="CVE-2023-0567" title="CVE-2023-0567" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0568" id="CVE-2023-0568" title="CVE-2023-0568" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0662" id="CVE-2023-0662" title="CVE-2023-0662" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3823" id="CVE-2023-3823" title="CVE-2023-3823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3824" id="CVE-2023-3824" title="CVE-2023-3824" type="cve"></reference>
		</references>
		<description>CVE-2022-31631:A flaw was found in PHP. This issue occurs due to an uncaught integer overflow in PDO::quote() of PDO_SQLite returning an improperly quoted string. With the implementation of sqlite3_snprintf(), it is possible to force the function to return a single apostrophe if the function is called on user-supplied input without any length restrictions in place.&#xA;CVE-2023-0567:In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, password_verify() function may accept some invalid Blowfish hashes as valid. If such invalid hash ever ends up in the password database, it may lead to an application allowing any password for this entry as valid.&#xA;CVE-2023-0568:In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, core path resolution function allocate buffer one byte too small. When resolving paths with lengths close to system MAXPATHLEN setting, this may lead to the byte after the allocated buffer being overwritten with NUL value, which might lead to unauthorized data access or modification.&#xA;CVE-2023-0662:In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, excessive number of parts in HTTP form upload can cause high resource consumption and excessive number of log entries. This can cause denial of service on the affected server by exhausting CPU resources or disk space.&#xA;CVE-2023-3823:In PHP versions 8.0.* before 8.0.30, 8.1.* before 8.1.22, and 8.2.* before 8.2.8 various XML functions rely on libxml global state to track configuration variables, like whether external entities are loaded. This state is assumed to be unchanged unless the user explicitly changes it by calling appropriate function. However, since the state is process-global, other modules - such as ImageMagick - may also use this library within the same process, and change that global state for their internal purposes, and leave it in a state where external entities loading is enabled. This can lead to the situation where external XML is parsed with external entities loaded, which can lead to disclosure of any local files accessible to PHP. This vulnerable state may persist in the same process across many requests, until the process is shut down.&#xA;CVE-2023-3824:In PHP version 8.0.* before 8.0.30,  8.1.* before 8.1.22, and 8.2.* before 8.2.8, when loading phar file, while reading PHAR directory entries, insufficient length checking may lead to a stack buffer overflow, leading potentially to memory corruption or RCE.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="php" release="1.fos23" version="8.0.30">
					<filename>php-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="1.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-cli-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="1.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-dbg-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="1.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-fpm-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="1.fos23" version="8.0.30">
					<filename>php-common-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-common-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="1.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-devel-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="1.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-opcache-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="1.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-ldap-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="1.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-pdo-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="1.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-mysqlnd-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="1.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-pgsql-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="1.fos23" version="8.0.30">
					<filename>php-process-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-process-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="1.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-odbc-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="1.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-soap-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="1.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-snmp-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="1.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-xml-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="1.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-mbstring-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="1.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-gd-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="1.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-bcmath-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="1.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-gmp-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="1.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-dba-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="1.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-tidy-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="1.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-embedded-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="1.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-intl-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="1.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-enchant-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="1.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-sodium-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="1.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-ffi-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-help" release="1.fos23" version="8.0.30">
					<filename>php-help-8.0.30-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/php-help-8.0.30-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="1.fos23" version="8.0.30">
					<filename>php-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="1.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-cli-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="1.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-dbg-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="1.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-fpm-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="1.fos23" version="8.0.30">
					<filename>php-common-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-common-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="1.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-devel-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="1.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-opcache-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="1.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-ldap-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="1.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-pdo-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="1.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-mysqlnd-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="1.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-pgsql-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="1.fos23" version="8.0.30">
					<filename>php-process-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-process-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="1.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-odbc-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="1.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-soap-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="1.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-snmp-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="1.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-xml-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="1.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-mbstring-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="1.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-gd-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="1.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-bcmath-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="1.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-gmp-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="1.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-dba-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="1.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-tidy-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="1.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-embedded-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="1.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-intl-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="1.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-enchant-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="1.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-sodium-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="1.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-ffi-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-help" release="1.fos23" version="8.0.30">
					<filename>php-help-8.0.30-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/php-help-8.0.30-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2261</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-23804" id="CVE-2020-23804" title="CVE-2020-23804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37050" id="CVE-2022-37050" title="CVE-2022-37050" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37051" id="CVE-2022-37051" title="CVE-2022-37051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37052" id="CVE-2022-37052" title="CVE-2022-37052" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38349" id="CVE-2022-38349" title="CVE-2022-38349" type="cve"></reference>
		</references>
		<description>CVE-2020-23804:Uncontrolled Recursion in pdfinfo, and pdftops in poppler 0.89.0 allows remote attackers to cause a denial of service via crafted input.&#xA;CVE-2022-37050:In Poppler 22.07.0, PDFDoc::savePageAs in PDFDoc.c callows attackers to cause a denial-of-service (application crashes with SIGABRT) by crafting a PDF file in which the xref data structure is mishandled in getCatalog processing. Note that this vulnerability is caused by the incomplete patch of CVE-2018-20662.&#xA;CVE-2022-37051:An issue was discovered in Poppler 22.07.0. There is a reachable abort which leads to denial of service because the main function in pdfunite.cc lacks a stream check before saving an embedded file.&#xA;CVE-2022-37052:A reachable Object::getString assertion in Poppler 22.07.0 allows attackers to cause a denial of service due to a failure in markObject.&#xA;CVE-2022-38349:An issue was discovered in Poppler 22.08.0. There is a reachable assertion in Object.h, will lead to denial of service because PDFDoc::replacePageDict in PDFDoc.cc lacks a stream check before saving an embedded file.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="poppler" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-devel-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-glib-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-glib-devel-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-glib-doc-0.90.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-qt5-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-qt5-devel-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-cpp-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-cpp-devel-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-utils-0.90.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/poppler-help-0.90.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-devel-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-glib-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-glib-devel-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-qt5-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-qt5-devel-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-cpp-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-cpp-devel-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="6.u3.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/poppler-utils-0.90.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2262</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2625" id="CVE-2022-2625" title="CVE-2022-2625" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2454" id="CVE-2023-2454" title="CVE-2023-2454" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2455" id="CVE-2023-2455" title="CVE-2023-2455" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"></reference>
		</references>
		<description>CVE-2022-2625:A vulnerability was found in PostgreSQL. This attack requires permission to create non-temporary objects in at least one schema, the ability to lure or wait for an administrator to create or update an affected extension in that schema, and the ability to lure or wait for a victim to use the object targeted in CREATE OR REPLACE or CREATE IF NOT EXISTS. Given all three prerequisites, this flaw allows an attacker to run arbitrary code as the victim role, which may be a superuser.&#xA;CVE-2023-2454:schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.&#xA;CVE-2023-2455:Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.&#xA;CVE-2023-39417:IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, &#39;&#39;, or &#34;&#34;). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="postgresql" release="7.u1.fos23" version="13.3">
					<filename>postgresql-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="7.u1.fos23" version="13.3">
					<filename>postgresql-server-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-server-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="7.u1.fos23" version="13.3">
					<filename>postgresql-docs-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-docs-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="7.u1.fos23" version="13.3">
					<filename>postgresql-contrib-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-contrib-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="7.u1.fos23" version="13.3">
					<filename>postgresql-server-devel-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-server-devel-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="7.u1.fos23" version="13.3">
					<filename>postgresql-test-rpm-macros-13.3-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-test-rpm-macros-13.3-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="7.u1.fos23" version="13.3">
					<filename>postgresql-static-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-static-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="7.u1.fos23" version="13.3">
					<filename>postgresql-plperl-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-plperl-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="7.u1.fos23" version="13.3">
					<filename>postgresql-plpython3-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-plpython3-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="7.u1.fos23" version="13.3">
					<filename>postgresql-pltcl-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-pltcl-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="7.u1.fos23" version="13.3">
					<filename>postgresql-test-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-test-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="7.u1.fos23" version="13.3">
					<filename>postgresql-llvmjit-13.3-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/postgresql-llvmjit-13.3-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="7.u1.fos23" version="13.3">
					<filename>postgresql-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="7.u1.fos23" version="13.3">
					<filename>postgresql-server-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-server-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="7.u1.fos23" version="13.3">
					<filename>postgresql-docs-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-docs-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="7.u1.fos23" version="13.3">
					<filename>postgresql-contrib-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-contrib-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="7.u1.fos23" version="13.3">
					<filename>postgresql-server-devel-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-server-devel-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="7.u1.fos23" version="13.3">
					<filename>postgresql-static-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-static-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="7.u1.fos23" version="13.3">
					<filename>postgresql-plperl-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-plperl-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="7.u1.fos23" version="13.3">
					<filename>postgresql-plpython3-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-plpython3-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="7.u1.fos23" version="13.3">
					<filename>postgresql-pltcl-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-pltcl-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="7.u1.fos23" version="13.3">
					<filename>postgresql-test-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-test-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="7.u1.fos23" version="13.3">
					<filename>postgresql-llvmjit-13.3-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/postgresql-llvmjit-13.3-7.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2263</id>
		<title>An update for protobuf2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-5237" id="CVE-2015-5237" title="CVE-2015-5237" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-22570" id="CVE-2021-22570" title="CVE-2021-22570" type="cve"></reference>
		</references>
		<description>CVE-2015-5237:protobuf allows remote authenticated attackers to cause a heap-based buffer overflow.&#xA;CVE-2021-22570:Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file&#39;s name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. We recommend upgrading to version 3.15.0 or greater.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="protobuf2" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-compiler" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-compiler-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-compiler-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-devel" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-devel-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-devel-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-static" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-static-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-static-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-lite" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-lite-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-lite-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-lite-devel" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-lite-devel-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-lite-devel-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-lite-static" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-lite-static-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-lite-static-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-vim" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-vim-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-vim-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-emacs" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-emacs-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-emacs-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-emacs-el" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-emacs-el-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-emacs-el-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-java" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-java-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-java-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf2-javadoc" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-javadoc-2.5.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/protobuf2-javadoc-2.5.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-compiler" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-compiler-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-compiler-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-devel" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-devel-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-devel-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-static" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-static-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-static-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-lite" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-lite-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-lite-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-lite-devel" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-lite-devel-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-lite-devel-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-lite-static" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-lite-static-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-lite-static-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-vim" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-vim-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-vim-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-emacs" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-emacs-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-emacs-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-emacs-el" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-emacs-el-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-emacs-el-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-java" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-java-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-java-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf2-javadoc" release="4.u2.fos23" version="2.5.0">
					<filename>protobuf2-javadoc-2.5.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/protobuf2-javadoc-2.5.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2264</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45198" id="CVE-2022-45198" title="CVE-2022-45198" type="cve"></reference>
		</references>
		<description>CVE-2022-45198:Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="python3-pillow" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-pillow-9.0.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-devel" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-pillow-devel-9.0.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pillow-help" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-help-9.0.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-pillow-help-9.0.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-tk" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-pillow-tk-9.0.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-qt" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-pillow-qt-9.0.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-pillow-9.0.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-devel" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-pillow-devel-9.0.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-tk" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-pillow-tk-9.0.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-qt" release="3.u1.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-pillow-qt-9.0.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2265</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40217" id="CVE-2023-40217" title="CVE-2023-40217" type="cve"></reference>
		</references>
		<description>CVE-2023-40217:An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as &#34;not connected&#34; and won&#39;t initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="python3" release="25.u7.fos23" version="3.9.9">
					<filename>python3-3.9.9-25.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-3.9.9-25.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="25.u7.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-25.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-unversioned-command-3.9.9-25.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="25.u7.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-25.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-devel-3.9.9-25.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="25.u7.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-25.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-debug-3.9.9-25.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="25.u7.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-25.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/python3-help-3.9.9-25.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="25.u7.fos23" version="3.9.9">
					<filename>python3-3.9.9-25.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-3.9.9-25.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="25.u7.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-25.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-unversioned-command-3.9.9-25.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="25.u7.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-25.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-devel-3.9.9-25.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="25.u7.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-25.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/python3-debug-3.9.9-25.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2266</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36648" id="CVE-2022-36648" title="CVE-2022-36648" type="cve"></reference>
		</references>
		<description>CVE-2022-36648:The hardware emulation in the of_dpa_cmd_add_l2_flood of rocker device model in QEMU, as used in 7.0.0 and earlier, allows remote attackers to crash the host qemu and potentially execute code on the host via execute a malformed program in the guest OS.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="10" name="qemu" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-guest-agent-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-80.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-help-6.2.0-80.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-img-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-block-rbd-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-block-ssh-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-block-iscsi-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-block-curl-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-hw-usb-host-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-seabios-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-system-aarch64-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-system-arm-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-system-x86_64-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-80.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qemu-system-riscv-6.2.0-80.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-guest-agent-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-img-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-block-rbd-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-block-ssh-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-block-iscsi-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-block-curl-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-hw-usb-host-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-system-aarch64-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-system-arm-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-system-x86_64-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="80.u9.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-80.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qemu-system-riscv-6.2.0-80.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2267</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32763" id="CVE-2023-32763" title="CVE-2023-32763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"></reference>
		</references>
		<description>CVE-2023-32763:An issue was discovered in Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. When a SVG file with an image inside it is rendered, a QTextLayout buffer overflow can be triggered.&#xA;CVE-2023-37369:In Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.2, there can be an application crash in QXmlStreamReader via a crafted XML string that triggers a situation in which a prefix is greater than a length.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="qt" release="54.u5.fos23" version="4.8.7">
					<filename>qt-4.8.7-54.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt-4.8.7-54.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="qt-devel" release="54.u5.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-54.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt-devel-4.8.7-54.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt" release="54.u5.fos23" version="4.8.7">
					<filename>qt-4.8.7-54.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt-4.8.7-54.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt-devel" release="54.u5.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-54.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt-devel-4.8.7-54.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2268</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32762" id="CVE-2023-32762" title="CVE-2023-32762" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33285" id="CVE-2023-33285" title="CVE-2023-33285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34410" id="CVE-2023-34410" title="CVE-2023-34410" type="cve"></reference>
		</references>
		<description>CVE-2023-32762:An issue was discovered in Qt before 5.15.14, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. Qt Network incorrectly parses the strict-transport-security (HSTS) header, allowing unencrypted connections to be established, even when explicitly prohibited by the server. This happens if the case used for this header does not exactly match.&#xA;CVE-2023-37369:In Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.2, there can be an application crash in QXmlStreamReader via a crafted XML string that triggers a situation in which a prefix is greater than a length.&#xA;CVE-2023-33285:An issue was discovered in Qt 5.x before 5.15.14, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. QDnsLookup has a buffer over-read via a crafted reply from a DNS server.&#xA;CVE-2023-34410:An issue was discovered in Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.2. Certificate validation for TLS does not always consider whether the root of a chain is a configured CA certificate.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-common-5.15.2-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-devel-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-private-devel-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-examples-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-static-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-mysql-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-odbc-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-postgresql-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/qt5-qtbase-gui-5.15.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-devel-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-private-devel-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-examples-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-static-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-mysql-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-odbc-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-postgresql-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="9.u4.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/qt5-qtbase-gui-5.15.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2269</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35977" id="CVE-2022-35977" title="CVE-2022-35977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3647" id="CVE-2022-3647" title="CVE-2022-3647" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22458" id="CVE-2023-22458" title="CVE-2023-22458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25155" id="CVE-2023-25155" title="CVE-2023-25155" type="cve"></reference>
		</references>
		<description>CVE-2022-35977:Redis is an in-memory database that persists on disk. Authenticated users issuing specially crafted `SETRANGE` and `SORT(_RO)` commands can trigger an integer overflow, resulting with Redis attempting to allocate impossible amounts of memory and abort with an out-of-memory (OOM) panic. The problem is fixed in Redis versions 7.0.8, 6.2.9 and 6.0.17. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2022-3647:** DISPUTED ** A vulnerability, which was classified as problematic, was found in Redis. Affected is the function sigsegvHandler of the file debug.c of the component Crash Report. The manipulation leads to denial of service. The real existence of this vulnerability is still doubted at the moment. The name of the patch is 0bf90d944313919eb8e63d3588bf63a367f020a3. It is recommended to apply a patch to fix this issue. VDB-211962 is the identifier assigned to this vulnerability. NOTE: The vendor claims that this is not a DoS because it applies to the crash logging mechanism which is triggered after a crash has occurred.&#xA;CVE-2023-22458:Redis is an in-memory database that persists on disk. Authenticated users can issue a `HRANDFIELD` or `ZRANDMEMBER` command with specially crafted arguments to trigger a denial-of-service by crashing Redis with an assertion failure. This problem affects Redis versions 6.2 or newer up to but not including 6.2.9 as well as versions 7.0 up to but not including 7.0.8. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-25155:Redis is an in-memory database that persists on disk. Authenticated users issuing specially crafted `SRANDMEMBER`, `ZRANDMEMBER`, and `HRANDFIELD` commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. This problem affects all Redis versions. Patches were released in Redis version(s) 6.0.18, 6.2.11 and 7.0.9.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u5.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/redis6-6.2.7-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u5.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/redis6-devel-6.2.7-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u5.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/redis6-doc-6.2.7-3.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u5.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/redis6-6.2.7-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u5.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/redis6-devel-6.2.7-3.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2270</id>
		<title>An update for rubygem-activesupport is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38037" id="CVE-2023-38037" title="CVE-2023-38037" type="cve"></reference>
		</references>
		<description>CVE-2023-38037:An insecure temporary file vulnerability was found in activesupport rubygem. Contents that will be encrypted are written to a temporary file that has the user’s current umask settings, possibly leading to information disclosure by other users on the same system.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="1" name="rubygem-activesupport" release="6.u3.fos23" version="6.1.4.1">
					<filename>rubygem-activesupport-6.1.4.1-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/rubygem-activesupport-6.1.4.1-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-activesupport-doc" release="6.u3.fos23" version="6.1.4.1">
					<filename>rubygem-activesupport-doc-6.1.4.1-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/rubygem-activesupport-doc-6.1.4.1-6.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2271</id>
		<title>An update for rubygem-railties is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38037" id="CVE-2023-38037" title="CVE-2023-38037" type="cve"></reference>
		</references>
		<description>CVE-2023-38037:An insecure temporary file vulnerability was found in activesupport rubygem. Contents that will be encrypted are written to a temporary file that has the user’s current umask settings, possibly leading to information disclosure by other users on the same system.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="0" name="rubygem-railties" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-railties-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/rubygem-railties-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-railties-doc" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-railties-doc-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/rubygem-railties-doc-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2272</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41080" id="CVE-2023-41080" title="CVE-2023-41080" type="cve"></reference>
		</references>
		<description>CVE-2023-41080:URL Redirection to Untrusted Site (&#39;Open Redirect&#39;) vulnerability in FORM authentication feature Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.0.12, from 9.0.0-M1 through 9.0.79 and from 8.5.0 through 8.5.92.&#xA;The vulnerability is limited to the ROOT (default) web application.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="1" name="tomcat" release="31.u8.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-31.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/tomcat-9.0.10-31.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="31.u8.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-31.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/tomcat-jsvc-9.0.10-31.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="31.u8.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-31.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/tomcat-help-9.0.10-31.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2273</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4733" id="CVE-2023-4733" title="CVE-2023-4733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4734" id="CVE-2023-4734" title="CVE-2023-4734" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4735" id="CVE-2023-4735" title="CVE-2023-4735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4736" id="CVE-2023-4736" title="CVE-2023-4736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4738" id="CVE-2023-4738" title="CVE-2023-4738" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4750" id="CVE-2023-4750" title="CVE-2023-4750" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4752" id="CVE-2023-4752" title="CVE-2023-4752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4781" id="CVE-2023-4781" title="CVE-2023-4781" type="cve"></reference>
		</references>
		<description>CVE-2023-4733:Use After Free in GitHub repository vim/vim prior to 9.0.1840.&#xA;CVE-2023-4734:Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1846.&#xA;CVE-2023-4735:Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1847.&#xA;CVE-2023-4736:Untrusted Search Path in GitHub repository vim/vim prior to 9.0.1833.&#xA;CVE-2023-4738:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1848.&#xA;CVE-2023-4750:Use After Free in GitHub repository vim/vim prior to 9.0.1857.&#xA;CVE-2023-4752:Use After Free in GitHub repository vim/vim prior to 9.0.1858.&#xA;CVE-2023-4781:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1873.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="17.u9.fos23" version="9.0">
					<filename>vim-common-9.0-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/vim-common-9.0-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="17.u9.fos23" version="9.0">
					<filename>vim-minimal-9.0-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/vim-minimal-9.0-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="17.u9.fos23" version="9.0">
					<filename>vim-enhanced-9.0-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/vim-enhanced-9.0-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="17.u9.fos23" version="9.0">
					<filename>vim-filesystem-9.0-17.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/vim-filesystem-9.0-17.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="17.u9.fos23" version="9.0">
					<filename>vim-X11-9.0-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/vim-X11-9.0-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="17.u9.fos23" version="9.0">
					<filename>vim-common-9.0-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/vim-common-9.0-17.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="17.u9.fos23" version="9.0">
					<filename>vim-minimal-9.0-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/vim-minimal-9.0-17.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="17.u9.fos23" version="9.0">
					<filename>vim-enhanced-9.0-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/vim-enhanced-9.0-17.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="17.u9.fos23" version="9.0">
					<filename>vim-X11-9.0-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/vim-X11-9.0-17.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2274</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2906" id="CVE-2023-2906" title="CVE-2023-2906" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3649" id="CVE-2023-3649" title="CVE-2023-3649" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4511" id="CVE-2023-4511" title="CVE-2023-4511" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4513" id="CVE-2023-4513" title="CVE-2023-4513" type="cve"></reference>
		</references>
		<description>CVE-2023-2906:Due to a failure in validating the length provided by an attacker-crafted CP2179 packet, Wireshark versions 2.0.0 through 4.0.7 is susceptible to a divide by zero allowing for a denial of service attack.&#xA;CVE-2023-3649:iSCSI dissector crash in Wireshark 4.0.0 to 4.0.6 allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-4511:BT SDP dissector infinite loop in Wireshark 4.0.0 to 4.0.7 and 3.6.0 to 3.6.15 allows denial of service via packet injection or crafted capture file&#xA;CVE-2023-4513:BT SDP dissector memory leak in Wireshark 4.0.0 to 4.0.7 and 3.6.0 to 3.6.15 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="3.u6.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-3.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/wireshark-3.6.14-3.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="3.u6.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-3.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/wireshark-devel-3.6.14-3.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="3.u6.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-3.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/wireshark-help-3.6.14-3.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="3.u6.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-3.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/wireshark-3.6.14-3.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="3.u6.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-3.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/wireshark-devel-3.6.14-3.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="3.u6.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-3.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3/wireshark-help-3.6.14-3.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2275</id>
		<title>An update for woodstox-core is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-09-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40152" id="CVE-2022-40152" title="CVE-2022-40152" type="cve"></reference>
		</references>
		<description>CVE-2022-40152:Those using Woodstox to parse XML data may be vulnerable to Denial of Service attacks (DOS) if DTD support is enabled. If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.</description>
		<pkglist>
			<collection>
				<name>23.0.3</name>
				<package arch="noarch" epoch="0" name="woodstox-core" release="1.u1.fos23" version="5.0.3">
					<filename>woodstox-core-5.0.3-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/woodstox-core-5.0.3-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="woodstox-core-javadoc" release="1.u1.fos23" version="5.0.3">
					<filename>woodstox-core-javadoc-5.0.3-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3/woodstox-core-javadoc-5.0.3-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2276</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5341" id="CVE-2023-5341" title="CVE-2023-5341" type="cve"></reference>
		</references>
		<description>CVE-2023-5341:A vulnerability was found in ImageMagick &lt;=7.1.1, where heap use-after-free was found in coders/bmp.c.References:https://github.com/ImageMagick/ImageMagick/commit/aa673b2e4defc7cad5bec16c4fc8324f71e531f1</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ImageMagick-7.1.1.8-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ImageMagick-devel-7.1.1.8-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ImageMagick-help-7.1.1.8-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ImageMagick-perl-7.1.1.8-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ImageMagick-c++-7.1.1.8-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ImageMagick-c++-devel-7.1.1.8-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ImageMagick-7.1.1.8-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ImageMagick-devel-7.1.1.8-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ImageMagick-help-7.1.1.8-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ImageMagick-perl-7.1.1.8-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ImageMagick-c++-7.1.1.8-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="5.u6.fos23" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ImageMagick-c++-devel-7.1.1.8-5.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2277</id>
		<title>An update for avahi is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38469" id="CVE-2023-38469" title="CVE-2023-38469" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38470" id="CVE-2023-38470" title="CVE-2023-38470" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38471" id="CVE-2023-38471" title="CVE-2023-38471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38472" id="CVE-2023-38472" title="CVE-2023-38472" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38473" id="CVE-2023-38473" title="CVE-2023-38473" type="cve"></reference>
		</references>
		<description>CVE-2023-38469:A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.&#xA;CVE-2023-38470:A vulnerability was found in Avahi. A reachable assertion exists in the avahi_escape_label() function.&#xA;CVE-2023-38471:A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.&#xA;CVE-2023-38472:A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.&#xA;CVE-2023-38473:A vulnerability was found in Avahi. A reachable assertion exists in the avahi_alternative_host_name() function.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="avahi" release="17.u3.fos23" version="0.8">
					<filename>avahi-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-tools" release="17.u3.fos23" version="0.8">
					<filename>avahi-tools-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-tools-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui" release="17.u3.fos23" version="0.8">
					<filename>avahi-ui-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-ui-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-autoipd" release="17.u3.fos23" version="0.8">
					<filename>avahi-autoipd-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-autoipd-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-dnsconfd" release="17.u3.fos23" version="0.8">
					<filename>avahi-dnsconfd-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-dnsconfd-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-howl-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-compat-howl-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-compat-howl-devel-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-compat-libdns_sd-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-compat-libdns_sd-devel-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-devel-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-devel-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib" release="17.u3.fos23" version="0.8">
					<filename>avahi-glib-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-glib-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-glib-devel-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-glib-devel-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject" release="17.u3.fos23" version="0.8">
					<filename>avahi-gobject-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-gobject-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-gobject-devel-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-gobject-devel-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-gtk3" release="17.u3.fos23" version="0.8">
					<filename>avahi-ui-gtk3-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-ui-gtk3-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-ui-devel-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-ui-devel-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-libs" release="17.u3.fos23" version="0.8">
					<filename>avahi-libs-0.8-17.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-libs-0.8-17.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="avahi-help" release="17.u3.fos23" version="0.8">
					<filename>avahi-help-0.8-17.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/avahi-help-0.8-17.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi" release="17.u3.fos23" version="0.8">
					<filename>avahi-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-tools" release="17.u3.fos23" version="0.8">
					<filename>avahi-tools-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-tools-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui" release="17.u3.fos23" version="0.8">
					<filename>avahi-ui-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-ui-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-autoipd" release="17.u3.fos23" version="0.8">
					<filename>avahi-autoipd-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-autoipd-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-dnsconfd" release="17.u3.fos23" version="0.8">
					<filename>avahi-dnsconfd-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-dnsconfd-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-howl-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-compat-howl-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-compat-howl-devel-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-compat-libdns_sd-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-compat-libdns_sd-devel-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-devel-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-devel-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib" release="17.u3.fos23" version="0.8">
					<filename>avahi-glib-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-glib-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-glib-devel-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-glib-devel-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject" release="17.u3.fos23" version="0.8">
					<filename>avahi-gobject-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-gobject-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-gobject-devel-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-gobject-devel-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-gtk3" release="17.u3.fos23" version="0.8">
					<filename>avahi-ui-gtk3-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-ui-gtk3-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-devel" release="17.u3.fos23" version="0.8">
					<filename>avahi-ui-devel-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-ui-devel-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-libs" release="17.u3.fos23" version="0.8">
					<filename>avahi-libs-0.8-17.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/avahi-libs-0.8-17.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2278</id>
		<title>An update for batik is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38398" id="CVE-2022-38398" title="CVE-2022-38398" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38648" id="CVE-2022-38648" title="CVE-2022-38648" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40146" id="CVE-2022-40146" title="CVE-2022-40146" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44729" id="CVE-2022-44729" title="CVE-2022-44729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44730" id="CVE-2022-44730" title="CVE-2022-44730" type="cve"></reference>
		</references>
		<description>CVE-2022-38398:Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache XML Graphics allows an attacker to load a url thru the jar protocol. This issue affects Apache XML Graphics Batik 1.14.&#xA;CVE-2022-38648:Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache XML Graphics allows an attacker to fetch external resources. This issue affects Apache XML Graphics Batik 1.14.&#xA;CVE-2022-40146:Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache XML Graphics allows an attacker to access files using a Jar url. This issue affects Apache XML Graphics Batik 1.14.&#xA;CVE-2022-44729:Server-Side Request Forgery (SSRF) vulnerability in Apache Software Foundation Apache XML Graphics Batik.This issue affects Apache XML Graphics Batik: 1.16. On version 1.16, a malicious SVG could trigger loading external resources by default, causing resource consumption or in some cases even information disclosure. Users are recommended to upgrade to version 1.17 or later.&#xA;CVE-2022-44730:Server-Side Request Forgery (SSRF) vulnerability in Apache Software Foundation Apache XML Graphics Batik.This issue affects Apache XML Graphics Batik: 1.16. A malicious SVG can probe user profile / data and send it directly as parameter to a URL.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="noarch" epoch="0" name="batik" release="1.u2.fos23" version="1.17">
					<filename>batik-1.17-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/batik-1.17-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="batik-help" release="1.u2.fos23" version="1.17">
					<filename>batik-help-1.17-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/batik-help-1.17-1.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2279</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3341" id="CVE-2023-3341" title="CVE-2023-3341" type="cve"></reference>
		</references>
		<description>CVE-2023-3341:The code that processes control channel messages sent to `named` calls certain functions recursively during packet parsing. Recursion depth is only limited by the maximum accepted packet size; depending on the environment, this may cause the packet-parsing code to run out of available stack memory, causing `named` to terminate unexpectedly. Since each incoming control channel message is fully parsed before its contents are authenticated, exploiting this flaw does not require the attacker to hold a valid RNDC key; only network access to the control channel&#39;s configured TCP port is necessary.&#xA;This issue affects BIND 9 versions 9.2.0 through 9.16.43, 9.18.0 through 9.18.18, 9.19.0 through 9.19.16, 9.9.3-S1 through 9.16.43-S1, and 9.18.0-S1 through 9.18.18-S1.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="32" name="bind" release="20.u6.fos23" version="9.16.23">
					<filename>bind-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-pkcs11-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-pkcs11-utils-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-pkcs11-libs-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-pkcs11-devel-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="20.u6.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-libs-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="20.u6.fos23" version="9.16.23">
					<filename>bind-license-9.16.23-20.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-license-9.16.23-20.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="20.u6.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-utils-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="20.u6.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-dnssec-utils-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="20.u6.fos23" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-20.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-dnssec-doc-9.16.23-20.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="20.u6.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-devel-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="20.u6.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bind-chroot-9.16.23-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="20.u6.fos23" version="9.16.23">
					<filename>python3-bind-9.16.23-20.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-bind-9.16.23-20.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="20.u6.fos23" version="9.16.23">
					<filename>bind-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-pkcs11-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-pkcs11-utils-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-pkcs11-libs-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="20.u6.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-pkcs11-devel-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="20.u6.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-libs-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="20.u6.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-utils-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="20.u6.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-dnssec-utils-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="20.u6.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-devel-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="20.u6.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bind-chroot-9.16.23-20.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2280</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38533" id="CVE-2022-38533" title="CVE-2022-38533" type="cve"></reference>
		</references>
		<description>CVE-2022-38533:In GNU Binutils before 2.40, there is a heap-buffer-overflow in the error function bfd_getl32 when called from the strip_main function in strip-new via a crafted file.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="binutils" release="24.u11.fos23" version="2.37">
					<filename>binutils-2.37-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/binutils-2.37-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="24.u11.fos23" version="2.37">
					<filename>binutils-devel-2.37-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/binutils-devel-2.37-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="24.u11.fos23" version="2.37">
					<filename>binutils-help-2.37-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/binutils-help-2.37-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="24.u11.fos23" version="2.37">
					<filename>binutils-2.37-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/binutils-2.37-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="24.u11.fos23" version="2.37">
					<filename>binutils-devel-2.37-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/binutils-devel-2.37-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="24.u11.fos23" version="2.37">
					<filename>binutils-help-2.37-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/binutils-help-2.37-24.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2281</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3854" id="CVE-2022-3854" title="CVE-2022-3854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43040" id="CVE-2023-43040" title="CVE-2023-43040" type="cve"></reference>
		</references>
		<description>CVE-2022-3854:A flaw was found in Ceph, relating to the URL processing on RGW backends. An attacker can exploit the URL processing by providing a null URL to crash the RGW, causing a denial of service.&#xA;CVE-2023-43040:A flaw was found in rgw. This flaw allows an unprivileged user to write to any bucket(s) accessible by a given key if a POST s form-data contains a key called bucket with a value matching the bucket s name used to sign the request. This issue results in a user being able to upload to any bucket accessible by the specified access key as long as the bucket in the POST policy matches the bucket in the said POST form part.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="2" name="ceph" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-base" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-base-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephadm" release="19.u8.fos23" version="16.2.7">
					<filename>cephadm-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cephadm-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-common" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-common-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mds" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mds-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mon" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mon-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mgr" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-dashboard" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-dashboard-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-dashboard-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-diskprediction-local" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-diskprediction-local-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-diskprediction-local-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-modules-core" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-modules-core-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-modules-core-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-rook" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-rook-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-rook-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-k8sevents" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-k8sevents-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-k8sevents-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-cephadm" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-cephadm-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-mgr-cephadm-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-fuse" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-fuse-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="cephfs-mirror" release="19.u8.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cephfs-mirror-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-fuse" release="19.u8.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/rbd-fuse-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-mirror" release="19.u8.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/rbd-mirror-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-immutable-object-cache" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-immutable-object-cache-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-nbd" release="19.u8.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/rbd-nbd-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-radosgw" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-radosgw-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephfs-top" release="19.u8.fos23" version="16.2.7">
					<filename>cephfs-top-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cephfs-top-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-resource-agents" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-resource-agents-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-osd" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-osd-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados2" release="19.u8.fos23" version="16.2.7">
					<filename>librados2-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/librados2-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados-devel" release="19.u8.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/librados-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradospp-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libradospp-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw2" release="19.u8.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/librgw2-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw-devel" release="19.u8.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/librgw-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rgw" release="19.u8.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-rgw-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rados" release="19.u8.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-rados-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite" release="19.u8.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libcephsqlite-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libcephsqlite-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper1" release="19.u8.fos23" version="16.2.7">
					<filename>libradosstriper1-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libradosstriper1-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libradosstriper-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd1" release="19.u8.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/librbd1-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd-devel" release="19.u8.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/librbd-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rbd" release="19.u8.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-rbd-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs2" release="19.u8.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libcephfs2-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libcephfs-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-cephfs" release="19.u8.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-cephfs-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-argparse" release="19.u8.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-ceph-argparse-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-common" release="19.u8.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-ceph-common-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-test" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-test-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rados-objclass-devel" release="19.u8.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/rados-objclass-devel-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-selinux" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-selinux-16.2.7-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-selinux-16.2.7-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-grafana-dashboards" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-grafana-dashboards-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-grafana-dashboards-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-prometheus-alerts" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-prometheus-alerts-16.2.7-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ceph-prometheus-alerts-16.2.7-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-base" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-base-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-common" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-common-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mds" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-mds-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mon" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-mon-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mgr" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-mgr-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-fuse" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-fuse-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="cephfs-mirror" release="19.u8.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cephfs-mirror-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-fuse" release="19.u8.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/rbd-fuse-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-mirror" release="19.u8.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/rbd-mirror-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-immutable-object-cache" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-immutable-object-cache-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-nbd" release="19.u8.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/rbd-nbd-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-radosgw" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-radosgw-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-resource-agents" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-resource-agents-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-osd" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-osd-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados2" release="19.u8.fos23" version="16.2.7">
					<filename>librados2-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/librados2-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados-devel" release="19.u8.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/librados-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradospp-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libradospp-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw2" release="19.u8.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/librgw2-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw-devel" release="19.u8.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/librgw-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rgw" release="19.u8.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-rgw-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rados" release="19.u8.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-rados-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite" release="19.u8.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libcephsqlite-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libcephsqlite-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper1" release="19.u8.fos23" version="16.2.7">
					<filename>libradosstriper1-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libradosstriper1-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libradosstriper-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd1" release="19.u8.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/librbd1-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd-devel" release="19.u8.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/librbd-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rbd" release="19.u8.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-rbd-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs2" release="19.u8.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libcephfs2-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs-devel" release="19.u8.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libcephfs-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-cephfs" release="19.u8.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-cephfs-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-argparse" release="19.u8.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-ceph-argparse-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-common" release="19.u8.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-ceph-common-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-test" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-test-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rados-objclass-devel" release="19.u8.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/rados-objclass-devel-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-selinux" release="19.u8.fos23" version="16.2.7">
					<filename>ceph-selinux-16.2.7-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ceph-selinux-16.2.7-19.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2282</id>
		<title>An update for containerd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
		</references>
		<description>CVE-2023-39325:A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="containerd" release="5.u6.fos23" version="1.6.22">
					<filename>containerd-1.6.22-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/containerd-1.6.22-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="containerd-stress" release="5.u6.fos23" version="1.6.22">
					<filename>containerd-stress-1.6.22-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/containerd-stress-1.6.22-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd" release="5.u6.fos23" version="1.6.22">
					<filename>containerd-1.6.22-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/containerd-1.6.22-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd-stress" release="5.u6.fos23" version="1.6.22">
					<filename>containerd-stress-1.6.22-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/containerd-stress-1.6.22-5.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2283</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4504" id="CVE-2023-4504" title="CVE-2023-4504" type="cve"></reference>
		</references>
		<description>CVE-2023-4504:Due to failure in validating the length provided by an attacker-crafted PPD PostScript document, CUPS and libppd are susceptible to a heap-based buffer overflow and possibly code execution. This issue has been fixed in CUPS version 2.4.7, released in September of 2023.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="cups" release="10.u4.fos23" version="2.4.0">
					<filename>cups-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="10.u4.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-client-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="10.u4.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-devel-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="10.u4.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-libs-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="10.u4.fos23" version="2.4.0">
					<filename>cups-filesystem-2.4.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-filesystem-2.4.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="10.u4.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-lpd-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="10.u4.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-ipptool-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="10.u4.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-printerapp-2.4.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="10.u4.fos23" version="2.4.0">
					<filename>cups-help-2.4.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cups-help-2.4.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="10.u4.fos23" version="2.4.0">
					<filename>cups-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="10.u4.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-client-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="10.u4.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-devel-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="10.u4.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-libs-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="10.u4.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-lpd-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="10.u4.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-ipptool-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="10.u4.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cups-printerapp-2.4.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2284</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38545" id="CVE-2023-38545" title="CVE-2023-38545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38546" id="CVE-2023-38546" title="CVE-2023-38546" type="cve"></reference>
		</references>
		<description>CVE-2023-38545:This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host name can be is 255 bytes.&#xA;If the host name is detected to be longer, curl switches to local name resolving and instead passes on the resolved address only. Due to this bug, the local variable that means &#34;let the host resolve the name&#34; could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long host name to the target buffer instead of copying just the resolved address there.&#xA;The target buffer being a heap based buffer, and the host name coming from the URL that curl has been told to operate with.&#xA;CVE-2023-38546:This flaw allows an attacker to insert cookies at will into a running program&#xA;using libcurl, if the specific series of conditions are met.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="curl" release="24.u11.fos23" version="7.79.1">
					<filename>curl-7.79.1-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/curl-7.79.1-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="24.u11.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libcurl-7.79.1-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="24.u11.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libcurl-devel-7.79.1-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="24.u11.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-24.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/curl-help-7.79.1-24.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="24.u11.fos23" version="7.79.1">
					<filename>curl-7.79.1-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/curl-7.79.1-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="24.u11.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libcurl-7.79.1-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="24.u11.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libcurl-devel-7.79.1-24.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2285</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48337" id="CVE-2022-48337" title="CVE-2022-48337" type="cve"></reference>
		</references>
		<description>CVE-2022-48337:GNU Emacs through 28.2 allows attackers to execute commands via shell metacharacters in the name of a source-code file, because lib-src/etags.c uses the system C library function in its implementation of the etags program. For example, a victim may use the &#34;etags -u *&#34; command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="emacs" release="11.u3.fos23" version="27.2">
					<filename>emacs-27.2-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-27.2-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="11.u3.fos23" version="27.2">
					<filename>emacs-devel-27.2-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-devel-27.2-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="11.u3.fos23" version="27.2">
					<filename>emacs-lucid-27.2-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-lucid-27.2-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="11.u3.fos23" version="27.2">
					<filename>emacs-nox-27.2-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-nox-27.2-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="11.u3.fos23" version="27.2">
					<filename>emacs-common-27.2-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-common-27.2-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="11.u3.fos23" version="27.2">
					<filename>emacs-terminal-27.2-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-terminal-27.2-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="11.u3.fos23" version="27.2">
					<filename>emacs-filesystem-27.2-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-filesystem-27.2-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="11.u3.fos23" version="27.2">
					<filename>emacs-help-27.2-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/emacs-help-27.2-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="11.u3.fos23" version="27.2">
					<filename>emacs-27.2-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/emacs-27.2-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="11.u3.fos23" version="27.2">
					<filename>emacs-devel-27.2-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/emacs-devel-27.2-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="11.u3.fos23" version="27.2">
					<filename>emacs-lucid-27.2-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/emacs-lucid-27.2-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="11.u3.fos23" version="27.2">
					<filename>emacs-nox-27.2-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/emacs-nox-27.2-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="11.u3.fos23" version="27.2">
					<filename>emacs-common-27.2-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/emacs-common-27.2-11.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2286</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4573" id="CVE-2023-4573" title="CVE-2023-4573" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4574" id="CVE-2023-4574" title="CVE-2023-4574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4575" id="CVE-2023-4575" title="CVE-2023-4575" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4576" id="CVE-2023-4576" title="CVE-2023-4576" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4581" id="CVE-2023-4581" title="CVE-2023-4581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4584" id="CVE-2023-4584" title="CVE-2023-4584" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4863" id="CVE-2023-4863" title="CVE-2023-4863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5217" id="CVE-2023-5217" title="CVE-2023-5217" type="cve"></reference>
		</references>
		<description>CVE-2023-4573:When receiving rendering data over IPC `mStream` could have been destroyed when initialized, which could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4574:When creating a callback over IPC for showing the Color Picker window, multiple of the same callbacks could have been created at a time and eventually all simultaneously destroyed as soon as one of the callbacks finished. This could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4575:When creating a callback over IPC for showing the File Picker window, multiple of the same callbacks could have been created at a time and eventually all simultaneously destroyed as soon as one of the callbacks finished. This could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4576:On Windows, an integer overflow could occur in `RecordedSourceSurfaceCreation` which resulted in a heap buffer overflow potentially leaking sensitive data that could have led to a sandbox escape. This bug only affects Firefox on Windows. Other operating systems are unaffected.* This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4581:Excel `.xll` add-in files did not have a blocklist entry in Firefox&#39;s executable blocklist which allowed them to be downloaded without any warning of their potential harm. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4584:Memory safety bugs present in Firefox 116, Firefox ESR 102.14, Firefox ESR 115.1, Thunderbird 102.14, and Thunderbird 115.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4863:Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)&#xA;CVE-2023-5217:Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="firefox" release="3.u4.fos23" version="102.15.0">
					<filename>firefox-102.15.0-3.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/firefox-102.15.0-3.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="firefox" release="3.u4.fos23" version="102.15.0">
					<filename>firefox-102.15.0-3.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/firefox-102.15.0-3.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2287</id>
		<title>An update for gcc is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4039" id="CVE-2023-4039" title="CVE-2023-4039" type="cve"></reference>
		</references>
		<description>CVE-2023-4039:A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables. The default behavior when the stack-protector detects an overflow is to terminate your application, resulting in controlled loss of availability. An attacker who can exploit a buffer overflow without triggering the stack-protector might be able to change program flow control to cause an uncontrolled loss of availability or to go further and affect confidentiality or integrity.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="gcc" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgcc" release="25.u9.fos23" version="10.3.1">
					<filename>libgcc-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libgcc-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gcc-c++" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-c++-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-c++-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libstdc++" release="25.u9.fos23" version="10.3.1">
					<filename>libstdc++-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libstdc++-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libstdc++-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libstdc++-devel-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libstdc++-devel-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libstdc++-static" release="25.u9.fos23" version="10.3.1">
					<filename>libstdc++-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libstdc++-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gcc-objc" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-objc-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-objc-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gcc-objc++" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-objc++-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-objc++-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libobjc" release="25.u9.fos23" version="10.3.1">
					<filename>libobjc-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libobjc-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gcc-gfortran" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-gfortran-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-gfortran-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfortran" release="25.u9.fos23" version="10.3.1">
					<filename>libgfortran-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libgfortran-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfortran-static" release="25.u9.fos23" version="10.3.1">
					<filename>libgfortran-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libgfortran-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgomp" release="25.u9.fos23" version="10.3.1">
					<filename>libgomp-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libgomp-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gcc-gdb-plugin" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-gdb-plugin-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-gdb-plugin-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgccjit" release="25.u9.fos23" version="10.3.1">
					<filename>libgccjit-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libgccjit-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgccjit-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libgccjit-devel-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libgccjit-devel-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libquadmath" release="25.u9.fos23" version="10.3.1">
					<filename>libquadmath-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libquadmath-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libquadmath-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libquadmath-devel-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libquadmath-devel-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libquadmath-static" release="25.u9.fos23" version="10.3.1">
					<filename>libquadmath-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libquadmath-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libitm" release="25.u9.fos23" version="10.3.1">
					<filename>libitm-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libitm-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libitm-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libitm-devel-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libitm-devel-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libitm-static" release="25.u9.fos23" version="10.3.1">
					<filename>libitm-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libitm-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libatomic" release="25.u9.fos23" version="10.3.1">
					<filename>libatomic-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libatomic-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libatomic-static" release="25.u9.fos23" version="10.3.1">
					<filename>libatomic-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libatomic-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libasan" release="25.u9.fos23" version="10.3.1">
					<filename>libasan-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libasan-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libasan-static" release="25.u9.fos23" version="10.3.1">
					<filename>libasan-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libasan-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtsan" release="25.u9.fos23" version="10.3.1">
					<filename>libtsan-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libtsan-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtsan-static" release="25.u9.fos23" version="10.3.1">
					<filename>libtsan-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libtsan-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libubsan" release="25.u9.fos23" version="10.3.1">
					<filename>libubsan-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libubsan-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libubsan-static" release="25.u9.fos23" version="10.3.1">
					<filename>libubsan-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libubsan-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="liblsan" release="25.u9.fos23" version="10.3.1">
					<filename>liblsan-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/liblsan-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="liblsan-static" release="25.u9.fos23" version="10.3.1">
					<filename>liblsan-static-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/liblsan-static-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cpp" release="25.u9.fos23" version="10.3.1">
					<filename>cpp-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/cpp-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gcc-plugin-devel" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-plugin-devel-10.3.1-25.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gcc-plugin-devel-10.3.1-25.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgcc" release="25.u9.fos23" version="10.3.1">
					<filename>libgcc-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libgcc-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc-c++" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-c++-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-c++-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libstdc++" release="25.u9.fos23" version="10.3.1">
					<filename>libstdc++-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libstdc++-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libstdc++-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libstdc++-devel-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libstdc++-devel-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libstdc++-static" release="25.u9.fos23" version="10.3.1">
					<filename>libstdc++-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libstdc++-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc-objc" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-objc-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-objc-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc-objc++" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-objc++-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-objc++-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libobjc" release="25.u9.fos23" version="10.3.1">
					<filename>libobjc-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libobjc-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc-gfortran" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-gfortran-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-gfortran-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfortran" release="25.u9.fos23" version="10.3.1">
					<filename>libgfortran-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libgfortran-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfortran-static" release="25.u9.fos23" version="10.3.1">
					<filename>libgfortran-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libgfortran-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgomp" release="25.u9.fos23" version="10.3.1">
					<filename>libgomp-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libgomp-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc-gdb-plugin" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-gdb-plugin-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-gdb-plugin-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgccjit" release="25.u9.fos23" version="10.3.1">
					<filename>libgccjit-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libgccjit-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgccjit-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libgccjit-devel-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libgccjit-devel-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libquadmath" release="25.u9.fos23" version="10.3.1">
					<filename>libquadmath-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libquadmath-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libquadmath-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libquadmath-devel-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libquadmath-devel-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libquadmath-static" release="25.u9.fos23" version="10.3.1">
					<filename>libquadmath-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libquadmath-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libitm" release="25.u9.fos23" version="10.3.1">
					<filename>libitm-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libitm-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libitm-devel" release="25.u9.fos23" version="10.3.1">
					<filename>libitm-devel-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libitm-devel-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libitm-static" release="25.u9.fos23" version="10.3.1">
					<filename>libitm-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libitm-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libatomic" release="25.u9.fos23" version="10.3.1">
					<filename>libatomic-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libatomic-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libatomic-static" release="25.u9.fos23" version="10.3.1">
					<filename>libatomic-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libatomic-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libasan" release="25.u9.fos23" version="10.3.1">
					<filename>libasan-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libasan-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libasan-static" release="25.u9.fos23" version="10.3.1">
					<filename>libasan-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libasan-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtsan" release="25.u9.fos23" version="10.3.1">
					<filename>libtsan-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libtsan-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtsan-static" release="25.u9.fos23" version="10.3.1">
					<filename>libtsan-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libtsan-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libubsan" release="25.u9.fos23" version="10.3.1">
					<filename>libubsan-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libubsan-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libubsan-static" release="25.u9.fos23" version="10.3.1">
					<filename>libubsan-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libubsan-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblsan" release="25.u9.fos23" version="10.3.1">
					<filename>liblsan-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/liblsan-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblsan-static" release="25.u9.fos23" version="10.3.1">
					<filename>liblsan-static-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/liblsan-static-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cpp" release="25.u9.fos23" version="10.3.1">
					<filename>cpp-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/cpp-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gcc-plugin-devel" release="25.u9.fos23" version="10.3.1">
					<filename>gcc-plugin-devel-10.3.1-25.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gcc-plugin-devel-10.3.1-25.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2288</id>
		<title>An update for gdb is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39129" id="CVE-2023-39129" title="CVE-2023-39129" type="cve"></reference>
		</references>
		<description>CVE-2023-39129:GNU gdb (GDB) 13.0.50.20220805-git was discovered to contain a heap use after free via the function add_pe_exported_sym() at /gdb/coff-pe-read.c.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="gdb" release="7.u3.fos23" version="11.1">
					<filename>gdb-11.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gdb-11.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-headless" release="7.u3.fos23" version="11.1">
					<filename>gdb-headless-11.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gdb-headless-11.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-gdbserver" release="7.u3.fos23" version="11.1">
					<filename>gdb-gdbserver-11.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gdb-gdbserver-11.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdb-help" release="7.u3.fos23" version="11.1">
					<filename>gdb-help-11.1-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gdb-help-11.1-7.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb" release="7.u3.fos23" version="11.1">
					<filename>gdb-11.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gdb-11.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-headless" release="7.u3.fos23" version="11.1">
					<filename>gdb-headless-11.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gdb-headless-11.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-gdbserver" release="7.u3.fos23" version="11.1">
					<filename>gdb-gdbserver-11.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gdb-gdbserver-11.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2289</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39742" id="CVE-2023-39742" title="CVE-2023-39742" type="cve"></reference>
		</references>
		<description>CVE-2023-39742:giflib v5.2.1 was discovered to contain a segmentation fault via the component getarg.c.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="giflib" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-5.2.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/giflib-5.2.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-devel" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/giflib-devel-5.2.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-utils" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/giflib-utils-5.2.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="giflib-help" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-help-5.2.1-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/giflib-help-5.2.1-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-5.2.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/giflib-5.2.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-devel" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/giflib-devel-5.2.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-utils" release="7.u2.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/giflib-utils-5.2.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2290</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4806" id="CVE-2023-4806" title="CVE-2023-4806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4813" id="CVE-2023-4813" title="CVE-2023-4813" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4911" id="CVE-2023-4911" title="CVE-2023-4911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5156" id="CVE-2023-5156" title="CVE-2023-5156" type="cve"></reference>
		</references>
		<description>CVE-2023-4806:A flaw was found in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks without implementing the _nss_*_gethostbyname3_r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AF_INET6 address family with AI_CANONNAME, AI_ALL and AI_V4MAPPED as flags.&#xA;CVE-2023-4813:A flaw was found in glibc. In an uncommon situation, the gaih_inet function may use memory that has been freed, resulting in an application crash. This issue is only exploitable when the getaddrinfo function is called and the hosts database in /etc/nsswitch.conf is configured with SUCCESS=continue or SUCCESS=merge.&#xA;CVE-2023-4911:A buffer overflow was discovered in the GNU C Library&#39;s dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.&#xA;CVE-2023-5156:A flaw was found in the GNU C Library. A recent fix for CVE-2023-4806 introduced the potential for a memory leak, which may result in an application crash.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="glibc" release="140.u19.fos23" version="2.34">
					<filename>glibc-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="140.u19.fos23" version="2.34">
					<filename>glibc-common-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-common-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="140.u19.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-all-langpacks-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="140.u19.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-locale-source-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="140.u19.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-locale-archive-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="140.u19.fos23" version="2.34">
					<filename>glibc-devel-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-devel-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="140.u19.fos23" version="2.34">
					<filename>nscd-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nscd-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="140.u19.fos23" version="2.34">
					<filename>nss_modules-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nss_modules-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="140.u19.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-nss-devel-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="140.u19.fos23" version="2.34">
					<filename>libnsl-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libnsl-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="140.u19.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-debugutils-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="140.u19.fos23" version="2.34">
					<filename>glibc-help-2.34-140.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-help-2.34-140.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="140.u19.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-140.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/glibc-compat-2.17-2.34-140.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="140.u19.fos23" version="2.34">
					<filename>glibc-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="140.u19.fos23" version="2.34">
					<filename>glibc-common-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-common-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="140.u19.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-all-langpacks-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="140.u19.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-locale-source-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="140.u19.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-locale-archive-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="140.u19.fos23" version="2.34">
					<filename>glibc-devel-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-devel-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="140.u19.fos23" version="2.34">
					<filename>nscd-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nscd-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="140.u19.fos23" version="2.34">
					<filename>nss_modules-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nss_modules-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="140.u19.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-nss-devel-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="140.u19.fos23" version="2.34">
					<filename>libnsl-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libnsl-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="140.u19.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-debugutils-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="140.u19.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-140.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/glibc-compat-2.17-2.34-140.u19.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2291</id>
		<title>An update for grpc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33953" id="CVE-2023-33953" title="CVE-2023-33953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4785" id="CVE-2023-4785" title="CVE-2023-4785" type="cve"></reference>
		</references>
		<description>CVE-2023-33953:gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow DOS attacks:&#xA;CVE-2023-4785:Lack of error handling in the TCP server in Google&#39;s gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="grpc" release="8.u3.fos23" version="1.41.1">
					<filename>grpc-1.41.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grpc-1.41.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="grpc-devel" release="8.u3.fos23" version="1.41.1">
					<filename>grpc-devel-1.41.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grpc-devel-1.41.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="grpc-plugins" release="8.u3.fos23" version="1.41.1">
					<filename>grpc-plugins-1.41.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grpc-plugins-1.41.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-grpcio" release="8.u3.fos23" version="1.41.1">
					<filename>python3-grpcio-1.41.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-grpcio-1.41.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="grpc" release="8.u3.fos23" version="1.41.1">
					<filename>grpc-1.41.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/grpc-1.41.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="grpc-devel" release="8.u3.fos23" version="1.41.1">
					<filename>grpc-devel-1.41.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/grpc-devel-1.41.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="grpc-plugins" release="8.u3.fos23" version="1.41.1">
					<filename>grpc-plugins-1.41.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/grpc-plugins-1.41.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-grpcio" release="8.u3.fos23" version="1.41.1">
					<filename>python3-grpcio-1.41.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-grpcio-1.41.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2292</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4692" id="CVE-2023-4692" title="CVE-2023-4692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4693" id="CVE-2023-4693" title="CVE-2023-4693" type="cve"></reference>
		</references>
		<description>CVE-2023-4692:An out-of-bounds write flaw was found in grub2 s NTFS filesystem driver. This issue may allow an attacker to present a specially crafted NTFS filesystem image, leading to grub s heap metadata corruption. In some circumstances, the attack may also corrupt the UEFI firmware heap metadata. As a result, arbitrary code execution and secure boot protection bypass may be achieved.&#xA;CVE-2023-4693:An out-of-bounds read flaw was found on grub2&#39;s NTFS filesystem driver. This issue may allow a physically present attacker to present a specially crafted NTFS file system image to read arbitrary memory locations. A successful attack allows sensitive data cached in memory or EFI variable values to be leaked, presenting a high Confidentiality risk.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="noarch" epoch="1" name="grub2-common" release="38.u12.fos23" version="2.06">
					<filename>grub2-common-2.06-38.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-common-2.06-38.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-tools-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-minimal" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-minimal-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-tools-minimal-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-extra" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-extra-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-tools-extra-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-efi" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-efi-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-tools-efi-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64" release="38.u12.fos23" version="2.06">
					<filename>grub2-efi-x64-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-efi-x64-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-x64-modules" release="38.u12.fos23" version="2.06">
					<filename>grub2-efi-x64-modules-2.06-38.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-efi-x64-modules-2.06-38.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64-cdboot" release="38.u12.fos23" version="2.06">
					<filename>grub2-efi-x64-cdboot-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-efi-x64-cdboot-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32" release="38.u12.fos23" version="2.06">
					<filename>grub2-efi-ia32-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-efi-ia32-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-ia32-modules" release="38.u12.fos23" version="2.06">
					<filename>grub2-efi-ia32-modules-2.06-38.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-efi-ia32-modules-2.06-38.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32-cdboot" release="38.u12.fos23" version="2.06">
					<filename>grub2-efi-ia32-cdboot-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-efi-ia32-cdboot-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-pc" release="38.u12.fos23" version="2.06">
					<filename>grub2-pc-2.06-38.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-pc-2.06-38.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-pc-modules" release="38.u12.fos23" version="2.06">
					<filename>grub2-pc-modules-2.06-38.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-pc-modules-2.06-38.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-help" release="38.u12.fos23" version="2.06">
					<filename>grub2-help-2.06-38.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/grub2-help-2.06-38.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-2.06-38.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/grub2-tools-2.06-38.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-minimal" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-minimal-2.06-38.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/grub2-tools-minimal-2.06-38.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-extra" release="38.u12.fos23" version="2.06">
					<filename>grub2-tools-extra-2.06-38.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/grub2-tools-extra-2.06-38.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2293</id>
		<title>An update for gstreamer1-plugins-bad-free is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40474" id="CVE-2023-40474" title="CVE-2023-40474" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40475" id="CVE-2023-40475" title="CVE-2023-40475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40476" id="CVE-2023-40476" title="CVE-2023-40476" type="cve"></reference>
		</references>
		<description>CVE-2023-40474:gstreamer-plugins-bad: GStreamer MXF File Parsing Integer Overflow Remote Code Execution Vulnerability&#xA;CVE-2023-40475:gstreamer-plugins-bad: GStreamer MXF File Parsing Integer Overflow Remote Code Execution Vulnerability&#xA;CVE-2023-40476:gstreamer-plugins-bad: GStreamer H265 Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-bad-free" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-1.16.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gstreamer1-plugins-bad-free-1.16.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-bad-free-devel" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-devel-1.16.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/gstreamer1-plugins-bad-free-devel-1.16.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-bad-free" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-1.16.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gstreamer1-plugins-bad-free-1.16.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-bad-free-devel" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-devel-1.16.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/gstreamer1-plugins-bad-free-devel-1.16.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2294</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31122" id="CVE-2023-31122" title="CVE-2023-31122" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45802" id="CVE-2023-45802" title="CVE-2023-45802" type="cve"></reference>
		</references>
		<description>CVE-2023-31122:Out-of-bounds Read vulnerability in mod_macro of Apache HTTP Server.This issue affects Apache HTTP Server: through 2.4.57.&#xA;CVE-2023-45802:When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request&#39;s memory resources were not reclaimed immediately. Instead, de-allocation was deferred to connection close. A client could send new requests and resets, keeping the connection busy and open and causing the memory footprint to keep on growing. On connection close, all resources were reclaimed, but the process might run out of memory before that.This was found by the reporter during testing of CVE-2023-44487 (HTTP/2 Rapid Reset Exploit) with their own test client. During &#34;normal&#34; HTTP/2 use, the probability to hit this bug is very low. The kept memory would not become noticeable before the connection closes or times out.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="httpd" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/httpd-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/httpd-devel-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/httpd-help-2.4.51-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/httpd-filesystem-2.4.51-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/httpd-tools-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="20.u9.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mod_ssl-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="20.u9.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mod_md-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="20.u9.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mod_proxy_html-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="20.u9.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mod_ldap-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="20.u9.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mod_session-2.4.51-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/httpd-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/httpd-devel-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="20.u9.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/httpd-tools-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="20.u9.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/mod_ssl-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="20.u9.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/mod_md-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="20.u9.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/mod_proxy_html-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="20.u9.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/mod_ldap-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="20.u9.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/mod_session-2.4.51-20.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2295</id>
		<title>An update for java-latest-openjdk is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21549" id="CVE-2022-21549" title="CVE-2022-21549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21830" id="CVE-2023-21830" title="CVE-2023-21830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21835" id="CVE-2023-21835" title="CVE-2023-21835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2193" id="CVE-2023-2193" title="CVE-2023-2193" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22006" id="CVE-2023-22006" title="CVE-2023-22006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22036" id="CVE-2023-22036" title="CVE-2023-22036" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22041" id="CVE-2023-22041" title="CVE-2023-22041" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22043" id="CVE-2023-22043" title="CVE-2023-22043" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22044" id="CVE-2023-22044" title="CVE-2023-22044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
		</references>
		<description>CVE-2022-21549:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 17.0.3.1; Oracle GraalVM Enterprise Edition: 21.3.2 and 22.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2022-40433:An issue was discovered in function ciMethodBlocks::make_block_at in Oracle JDK (HotSpot VM) 11, 17 and OpenJDK (HotSpot VM) 8, 11, 17, allows attackers to cause a denial of service.&#xA;CVE-2023-21830:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf; Oracle GraalVM Enterprise Edition: 20.3.8 and  21.3.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-21835:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via DTLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2023-21843:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Sound).  Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf, 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-2193:Mattermost fails to invalidate existing authorization codes when deauthorizing an OAuth2 app, allowing an attacker possessing an authorization code to generate an access token.&#xA;CVE-2023-21930:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2023-21938:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-21939:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-21954:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2023-21967:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21968:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-22006:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-22025:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u381-perf, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 21.3.7 and  22.3.3. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition,.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-22036:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Utility).  Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2023-22041:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-22043:Vulnerability in Oracle Java SE (component: JavaFX).   The supported version that is affected is Oracle Java SE: 8u371. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).&#xA;CVE-2023-22044:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u371-perf, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.&#xA;CVE-2023-22045:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.&#xA;CVE-2023-22049:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.&#xA;CVE-2023-22081:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf, 11.0.20, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 20.3.11, 21.3.7 and  22.3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-headless" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-headless-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-headless-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-devel" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-devel-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-devel-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-jmods" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-jmods-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-jmods-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-demo" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-demo-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-demo-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-src" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-src-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-src-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-javadoc" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-javadoc-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-javadoc-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-javadoc-zip" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-javadoc-zip-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/java-latest-openjdk-javadoc-zip-21.0.0.35-1.rolling.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-headless" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-headless-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-headless-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-devel" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-devel-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-devel-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-jmods" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-jmods-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-jmods-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-demo" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-demo-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-demo-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-src" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-src-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-src-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-javadoc" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-javadoc-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-javadoc-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-javadoc-zip" release="1.rolling.u1.fos23" version="21.0.0.35">
					<filename>java-latest-openjdk-javadoc-zip-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/java-latest-openjdk-javadoc-zip-21.0.0.35-1.rolling.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2296</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40982" id="CVE-2022-40982" title="CVE-2022-40982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4379" id="CVE-2022-4379" title="CVE-2022-4379" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45887" id="CVE-2022-45887" title="CVE-2022-45887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45919" id="CVE-2022-45919" title="CVE-2022-45919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20588" id="CVE-2023-20588" title="CVE-2023-20588" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21400" id="CVE-2023-21400" title="CVE-2023-21400" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4881" id="CVE-2023-4881" title="CVE-2023-4881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4921" id="CVE-2023-4921" title="CVE-2023-4921" type="cve"></reference>
		</references>
		<description>CVE-2022-40982:Information exposure through microarchitectural state after transient execution in certain vector execution units for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2022-4379:A use-after-free vulnerability was found in __nfs42_ssc_open() in fs/nfs/nfs4file.c in the Linux kernel. This flaw allows an attacker to conduct a remote denial&#xA;CVE-2022-45887:An issue was discovered in the Linux kernel through 6.0.9. drivers/media/usb/ttusb-dec/ttusb_dec.c has a memory leak because of the lack of a dvb_frontend_detach call.&#xA;CVE-2022-45919:An issue was discovered in the Linux kernel through 6.0.10. In drivers/media/dvb-core/dvb_ca_en50221.c, a use-after-free can occur is there is a disconnect after an open, because of the lack of a wait_event.&#xA;CVE-2023-20588:A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality.&#xA;CVE-2023-21400:In multiple functions  of io_uring.c, there is a possible kernel memory corruption due to improper locking. This could lead to local escalation of privilege in the kernel with System execution privileges needed. User interaction is not needed for exploitation.&#xA;CVE-2023-4881:CVE-2023-4881 was wrongly assigned to a bug that was deemed to be a non-security issue by the Linux kernel security team.&#xA;CVE-2023-4921:A use-after-free vulnerability in the Linux kernel&#39;s net/sched: sch_qfq component can be exploited to achieve local privilege escalation. When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue().</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/kernel-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/kernel-headers-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/kernel-devel-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/kernel-tools-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/kernel-tools-devel-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/perf-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-perf-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/bpftool-5.10.0-136.50.0.129.u88.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/kernel-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/kernel-headers-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/kernel-devel-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/kernel-tools-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/kernel-tools-devel-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/perf-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-perf-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.50.0.129.u88.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/bpftool-5.10.0-136.50.0.129.u88.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2297</id>
		<title>An update for lcr is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33634" id="CVE-2021-33634" title="CVE-2021-33634" type="cve"></reference>
		</references>
		<description>CVE-2021-33634:Isula uses the lxc runtime (default) to run malicious images, which can cause DOS.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="lcr" release="7.u4.fos23" version="2.0.9">
					<filename>lcr-2.0.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/lcr-2.0.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lcr-devel" release="7.u4.fos23" version="2.0.9">
					<filename>lcr-devel-2.0.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/lcr-devel-2.0.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lcr" release="7.u4.fos23" version="2.0.9">
					<filename>lcr-2.0.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/lcr-2.0.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lcr-devel" release="7.u4.fos23" version="2.0.9">
					<filename>lcr-devel-2.0.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/lcr-devel-2.0.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2298</id>
		<title>An update for libX11 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43785" id="CVE-2023-43785" title="CVE-2023-43785" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43786" id="CVE-2023-43786" title="CVE-2023-43786" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43787" id="CVE-2023-43787" title="CVE-2023-43787" type="cve"></reference>
		</references>
		<description>CVE-2023-43785:A vulnerability was found in libX11 due to a boundary condition within the _XkbReadKeySyms() function. This flaw allows a local user to trigger an out-of-bounds read error and read the contents of memory on the system.&#xA;CVE-2023-43786:A vulnerability was found in libX11 due to an infinite loop within the PutSubImage() function. This flaw allows a local user to consume all available system resources and cause a denial of service condition.&#xA;CVE-2023-43787:A vulnerability was found in libX11 due to an integer overflow within the XCreateImage() function. This flaw allows a local user to trigger an integer overflow and execute arbitrary code with elevated privileges.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="libX11" release="8.u2.fos23" version="1.7.2">
					<filename>libX11-1.7.2-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libX11-1.7.2-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libX11-devel" release="8.u2.fos23" version="1.7.2">
					<filename>libX11-devel-1.7.2-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libX11-devel-1.7.2-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libX11-help" release="8.u2.fos23" version="1.7.2">
					<filename>libX11-help-1.7.2-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libX11-help-1.7.2-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libX11" release="8.u2.fos23" version="1.7.2">
					<filename>libX11-1.7.2-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libX11-1.7.2-8.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libX11-devel" release="8.u2.fos23" version="1.7.2">
					<filename>libX11-devel-1.7.2-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libX11-devel-1.7.2-8.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2299</id>
		<title>An update for libXpm is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43786" id="CVE-2023-43786" title="CVE-2023-43786" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43787" id="CVE-2023-43787" title="CVE-2023-43787" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43788" id="CVE-2023-43788" title="CVE-2023-43788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43789" id="CVE-2023-43789" title="CVE-2023-43789" type="cve"></reference>
		</references>
		<description>CVE-2023-43786:A vulnerability was found in libX11 due to an infinite loop within the PutSubImage() function. This flaw allows a local user to consume all available system resources and cause a denial of service condition.&#xA;CVE-2023-43787:A vulnerability was found in libX11 due to an integer overflow within the XCreateImage() function. This flaw allows a local user to trigger an integer overflow and execute arbitrary code with elevated privileges.&#xA;CVE-2023-43788:A vulnerability was found in libXpm due to a boundary condition within the XpmCreateXpmImageFromBuffer() function. This flaw allows a local to trigger an out-of-bounds read error and read the contents of memory on the system.&#xA;CVE-2023-43789:A vulnerability was found in libXpm where a vulnerability exists due to a boundary condition, a local user can trigger an out-of-bounds read error and read contents of memory on the system.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="libXpm" release="5.u2.fos23" version="3.5.13">
					<filename>libXpm-3.5.13-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libXpm-3.5.13-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libXpm-devel" release="5.u2.fos23" version="3.5.13">
					<filename>libXpm-devel-3.5.13-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libXpm-devel-3.5.13-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libXpm-help" release="5.u2.fos23" version="3.5.13">
					<filename>libXpm-help-3.5.13-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libXpm-help-3.5.13-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libXpm" release="5.u2.fos23" version="3.5.13">
					<filename>libXpm-3.5.13-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libXpm-3.5.13-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libXpm-devel" release="5.u2.fos23" version="3.5.13">
					<filename>libXpm-devel-3.5.13-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libXpm-devel-3.5.13-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2300</id>
		<title>An update for libsndfile is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33065" id="CVE-2022-33065" title="CVE-2022-33065" type="cve"></reference>
		</references>
		<description>CVE-2022-33065:Multiple signed integers overflow in function au_read_header in src/au.c and in functions mat4_open and mat4_read_header in src/mat4.c in Libsndfile, allows an attacker to cause Denial of Service or other unspecified impacts.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="libsndfile" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-1.0.31-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libsndfile-1.0.31-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsndfile-devel" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-devel-1.0.31-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libsndfile-devel-1.0.31-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsndfile-utils" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-utils-1.0.31-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libsndfile-utils-1.0.31-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libsndfile-utils-help" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-utils-help-1.0.31-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libsndfile-utils-help-1.0.31-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-1.0.31-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libsndfile-1.0.31-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile-devel" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-devel-1.0.31-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libsndfile-devel-1.0.31-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile-utils" release="4.u2.fos23" version="1.0.31">
					<filename>libsndfile-utils-1.0.31-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libsndfile-utils-1.0.31-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2301</id>
		<title>An update for libvpx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44488" id="CVE-2023-44488" title="CVE-2023-44488" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5217" id="CVE-2023-5217" title="CVE-2023-5217" type="cve"></reference>
		</references>
		<description>CVE-2023-44488:VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding.&#xA;CVE-2023-5217:Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="libvpx" release="10.u2.fos23" version="1.7.0">
					<filename>libvpx-1.7.0-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libvpx-1.7.0-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvpx-devel" release="10.u2.fos23" version="1.7.0">
					<filename>libvpx-devel-1.7.0-10.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libvpx-devel-1.7.0-10.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx" release="10.u2.fos23" version="1.7.0">
					<filename>libvpx-1.7.0-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libvpx-1.7.0-10.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx-devel" release="10.u2.fos23" version="1.7.0">
					<filename>libvpx-devel-1.7.0-10.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libvpx-devel-1.7.0-10.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2302</id>
		<title>An update for libwebp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4863" id="CVE-2023-4863" title="CVE-2023-4863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5129" id="CVE-2023-5129" title="CVE-2023-5129" type="cve"></reference>
		</references>
		<description>CVE-2023-4863:Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)&#xA;CVE-2023-5129:This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Duplicate of CVE-2023-4863.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="libwebp" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-1.2.1-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwebp-1.2.1-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebp-tools" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-tools-1.2.1-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwebp-tools-1.2.1-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebp-devel" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-devel-1.2.1-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwebp-devel-1.2.1-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebp-java" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-java-1.2.1-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwebp-java-1.2.1-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libwebp-help" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-help-1.2.1-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwebp-help-1.2.1-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-1.2.1-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libwebp-1.2.1-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp-tools" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-tools-1.2.1-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libwebp-tools-1.2.1-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp-devel" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-devel-1.2.1-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libwebp-devel-1.2.1-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebp-java" release="3.u2.fos23" version="1.2.1">
					<filename>libwebp-java-1.2.1-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libwebp-java-1.2.1-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2303</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45322" id="CVE-2023-45322" title="CVE-2023-45322" type="cve"></reference>
		</references>
		<description>CVE-2023-45322:libxml2 through 2.11.5 has a use-after-free that can only occur after a certain memory allocation fails. This occurs in xmlUnlinkNode in tree.c. NOTE: the vendor&#39;s position is &#34;I don&#39;t think these issues are critical enough to warrant a CVE ID ... because an attacker typically can&#39;t control when memory allocations fail.&#34;</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="libxml2" release="9.u4.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libxml2-2.9.14-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="9.u4.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libxml2-devel-2.9.14-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="9.u4.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-libxml2-2.9.14-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="9.u4.fos23" version="2.9.14">
					<filename>libxml2-help-2.9.14-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libxml2-help-2.9.14-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="9.u4.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libxml2-2.9.14-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="9.u4.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libxml2-devel-2.9.14-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="9.u4.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-libxml2-2.9.14-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2304</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23583" id="CVE-2023-23583" title="CVE-2023-23583" type="cve"></reference>
		</references>
		<description>CVE-2023-23583:Sequence of processor instructions leads to unexpected behavior for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege and/or information disclosure and/or denial of service via local access.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="42.fos23" version="2.1">
					<filename>microcode_ctl-2.1-42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/microcode_ctl-2.1-42.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2305</id>
		<title>An update for mutt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4874" id="CVE-2023-4874" title="CVE-2023-4874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4875" id="CVE-2023-4875" title="CVE-2023-4875" type="cve"></reference>
		</references>
		<description>CVE-2023-4874:Null pointer dereference when viewing a specially crafted email in Mutt &gt;1.5.2 &lt;2.2.12&#xA;CVE-2023-4875:Null pointer dereference when composing from a specially crafted draft message in Mutt &gt;1.5.2 &lt;2.2.12</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="5" name="mutt" release="1.fos23" version="2.2.12">
					<filename>mutt-2.2.12-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mutt-2.2.12-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="5" name="mutt-help" release="1.fos23" version="2.2.12">
					<filename>mutt-help-2.2.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/mutt-help-2.2.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="5" name="mutt" release="1.fos23" version="2.2.12">
					<filename>mutt-2.2.12-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/mutt-2.2.12-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2306</id>
		<title>An update for nghttp2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
		</references>
		<description>CVE-2023-44487:The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="nghttp2" release="5.u3.fos23" version="1.46.0">
					<filename>nghttp2-1.46.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nghttp2-1.46.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2" release="5.u3.fos23" version="1.46.0">
					<filename>libnghttp2-1.46.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libnghttp2-1.46.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2-devel" release="5.u3.fos23" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libnghttp2-devel-1.46.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nghttp2-help" release="5.u3.fos23" version="1.46.0">
					<filename>nghttp2-help-1.46.0-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nghttp2-help-1.46.0-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nghttp2" release="5.u3.fos23" version="1.46.0">
					<filename>nghttp2-1.46.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nghttp2-1.46.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2" release="5.u3.fos23" version="1.46.0">
					<filename>libnghttp2-1.46.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libnghttp2-1.46.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2-devel" release="5.u3.fos23" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libnghttp2-devel-1.46.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2307</id>
		<title>An update for nginx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
		</references>
		<description>CVE-2023-44487:The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="nginx" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-all-modules-1.21.5-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-filesystem-1.21.5-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-mod-http-image-filter-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-mod-http-perl-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-mod-http-xslt-filter-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-mod-mail-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-mod-stream-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-mod-devel-1.21.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-help-1.21.5-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nginx-help-1.21.5-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-mod-http-image-filter-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-mod-http-perl-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-mod-http-xslt-filter-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-mod-mail-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-mod-stream-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="6.u2.fos23" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nginx-mod-devel-1.21.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2308</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23918" id="CVE-2023-23918" title="CVE-2023-23918" type="cve"></reference>
		</references>
		<description>CVE-2023-23918:A privilege escalation vulnerability exists in Node.js &lt;19.6.1, &lt;18.14.1, &lt;16.19.1 and &lt;14.21.3 that made it possible to bypass the experimental Permissions (https://nodejs.org/api/permissions.html) feature in Node.js and access non authorized modules by using process.mainModule.require(). This only affects users who had enabled the experimental permissions option with --experimental-policy.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="nodejs" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nodejs-12.22.11-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nodejs-devel-12.22.11-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nodejs-libs-12.22.11-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nodejs-full-i18n-12.22.11-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.6.u3.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/v8-devel-7.8.279.23-1.12.22.11.6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.6.u3.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/npm-6.14.16-1.12.22.11.6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-docs-12.22.11-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/nodejs-docs-12.22.11-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nodejs-12.22.11-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nodejs-devel-12.22.11-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nodejs-libs-12.22.11-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="6.u3.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/nodejs-full-i18n-12.22.11-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.6.u3.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/v8-devel-7.8.279.23-1.12.22.11.6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.6.u3.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/npm-6.14.16-1.12.22.11.6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2309</id>
		<title>An update for open-vm-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34058" id="CVE-2023-34058" title="CVE-2023-34058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34059" id="CVE-2023-34059" title="CVE-2023-34059" type="cve"></reference>
		</references>
		<description>CVE-2023-34058:VMware Tools contains a SAML token signature bypass vulnerability. A malicious actor that has been granted  Guest Operation Privileges https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-6A952214-0E5E-4CCF-9D2A-90948FF643EC.html  in a target virtual machine may be able to elevate their privileges if that target virtual machine has been assigned a more privileged  Guest Alias https://vdc-download.vmware.com/vmwb-repository/dcr-public/d1902b0e-d479-46bf-8ac9-cee0e31e8ec0/07ce8dbd-db48-4261-9b8f-c6d3ad8ba472/vim.vm.guest.AliasManager.html .&#xA;CVE-2023-34059:open-vm-tools contains a file descriptor hijack vulnerability in the vmware-user-suid-wrapper. A malicious actor with non-root privileges may be able to hijack the &#xA;/dev/uinput file descriptor allowing them to simulate user inputs.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="open-vm-tools" release="4.u2.fos23" version="12.0.5">
					<filename>open-vm-tools-12.0.5-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/open-vm-tools-12.0.5-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-desktop" release="4.u2.fos23" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/open-vm-tools-desktop-12.0.5-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-sdmp" release="4.u2.fos23" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/open-vm-tools-sdmp-12.0.5-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools" release="4.u2.fos23" version="12.0.5">
					<filename>open-vm-tools-12.0.5-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/open-vm-tools-12.0.5-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-desktop" release="4.u2.fos23" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/open-vm-tools-desktop-12.0.5-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-sdmp" release="4.u2.fos23" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/open-vm-tools-sdmp-12.0.5-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2310</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
		</references>
		<description>CVE-2023-3446:Checking excessively long DH keys or parameters may be very slow.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u3.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openresty-openssl111-asan-1.1.1h-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u3.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openresty-openssl111-asan-1.1.1h-2.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2311</id>
		<title>An update for openresty-zlib is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45853" id="CVE-2023-45853" title="CVE-2023-45853" type="cve"></reference>
		</references>
		<description>CVE-2023-45853:MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="openresty-zlib-asan" release="14.fos23" version="1.2.11">
					<filename>openresty-zlib-asan-1.2.11-14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openresty-zlib-asan-1.2.11-14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-zlib-asan" release="14.fos23" version="1.2.11">
					<filename>openresty-zlib-asan-1.2.11-14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openresty-zlib-asan-1.2.11-14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2312</id>
		<title>An update for opensc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2977" id="CVE-2023-2977" title="CVE-2023-2977" type="cve"></reference>
		</references>
		<description>CVE-2023-2977:A vulnerbility was found in OpenSC. This security flaw cause a buffer overrun vulnerability in pkcs15 cardos_have_verifyrc_package. The attacker can supply a smart card package with malformed ASN1 context. The cardos_have_verifyrc_package function scans the ASN1 buffer for 2 tags, where remaining length is wrongly caculated due to moved starting pointer. This leads to possible heap-based buffer oob read. In cases where ASAN is enabled while compiling this causes a crash. Further info leak or more damage is possible.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="opensc" release="6.u1.fos23" version="0.21.0">
					<filename>opensc-0.21.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/opensc-0.21.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="opensc-help" release="6.u1.fos23" version="0.21.0">
					<filename>opensc-help-0.21.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/opensc-help-0.21.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opensc" release="6.u1.fos23" version="0.21.0">
					<filename>opensc-0.21.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/opensc-0.21.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2313</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"></reference>
		</references>
		<description>CVE-2023-5678:Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays.  Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="openssl" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-29.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openssl-1.1.1m-29.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-29.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openssl-libs-1.1.1m-29.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-29.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openssl-perl-1.1.1m-29.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-29.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openssl-devel-1.1.1m-29.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-29.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openssl-help-1.1.1m-29.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-29.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openssl-1.1.1m-29.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-29.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openssl-libs-1.1.1m-29.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-29.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openssl-perl-1.1.1m-29.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="29.u13.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-29.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openssl-devel-1.1.1m-29.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2314</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5366" id="CVE-2023-5366" title="CVE-2023-5366" type="cve"></reference>
		</references>
		<description>CVE-2023-5366:A flaw was found in Open vSwitch that allows ICMPv6 Neighbor Advertisement packets between virtual machines to bypass OpenFlow rules. This issue may allow a local attacker to create specially crafted packets with a modified or spoofed target IP address field that can redirect ICMPv6 traffic to arbitrary IP addresses.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="openvswitch" release="5.u4.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openvswitch-2.12.4-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-devel" release="5.u4.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openvswitch-devel-2.12.4-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-help" release="5.u4.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/openvswitch-help-2.12.4-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-openvswitch" release="5.u4.fos23" version="2.12.4">
					<filename>python3-openvswitch-2.12.4-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-openvswitch-2.12.4-5.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch" release="5.u4.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openvswitch-2.12.4-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-devel" release="5.u4.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openvswitch-devel-2.12.4-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-help" release="5.u4.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/openvswitch-help-2.12.4-5.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2315</id>
		<title>An update for pmix is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41915" id="CVE-2023-41915" title="CVE-2023-41915" type="cve"></reference>
		</references>
		<description>CVE-2023-41915:OpenPMIx PMIx before 4.2.6 and 5.0.x before 5.0.1 allows attackers to obtain ownership of arbitrary files via a race condition during execution of library code with UID 0.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="pmix" release="1.fos23" version="4.2.6">
					<filename>pmix-4.2.6-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/pmix-4.2.6-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pmix-devel" release="1.fos23" version="4.2.6">
					<filename>pmix-devel-4.2.6-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/pmix-devel-4.2.6-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pmix-tools" release="1.fos23" version="4.2.6">
					<filename>pmix-tools-4.2.6-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/pmix-tools-4.2.6-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pmix" release="1.fos23" version="4.2.6">
					<filename>pmix-4.2.6-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/pmix-4.2.6-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pmix-devel" release="1.fos23" version="4.2.6">
					<filename>pmix-devel-4.2.6-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/pmix-devel-4.2.6-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pmix-tools" release="1.fos23" version="4.2.6">
					<filename>pmix-tools-4.2.6-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/pmix-tools-4.2.6-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2316</id>
		<title>An update for python-gevent is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41419" id="CVE-2023-41419" title="CVE-2023-41419" type="cve"></reference>
		</references>
		<description>CVE-2023-41419:An issue in Gevent before version 23.9.0 allows a remote attacker to escalate privileges via a crafted script to the WSGIServer component.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="noarch" epoch="0" name="python-gevent-help" release="2.u1.fos23" version="21.1.2">
					<filename>python-gevent-help-21.1.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python-gevent-help-21.1.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-gevent" release="2.u1.fos23" version="21.1.2">
					<filename>python3-gevent-21.1.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-gevent-21.1.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-gevent" release="2.u1.fos23" version="21.1.2">
					<filename>python3-gevent-21.1.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-gevent-21.1.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2317</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44271" id="CVE-2023-44271" title="CVE-2023-44271" type="cve"></reference>
		</references>
		<description>CVE-2023-44271:An issue was discovered in Pillow before 10.0.0. It is a Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="python3-pillow" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-pillow-9.0.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-devel" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-pillow-devel-9.0.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pillow-help" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-help-9.0.1-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-pillow-help-9.0.1-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-tk" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-pillow-tk-9.0.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-qt" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-pillow-qt-9.0.1-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-pillow-9.0.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-devel" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-pillow-devel-9.0.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-tk" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-pillow-tk-9.0.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-qt" release="4.u2.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-pillow-qt-9.0.1-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2318</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43804" id="CVE-2023-43804" title="CVE-2023-43804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"></reference>
		</references>
		<description>CVE-2023-43804:urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn&#39;t treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn&#39;t disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.&#xA;CVE-2023-45803:urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn&#39;t remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren&#39;t putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn&#39;t exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren&#39;t expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="noarch" epoch="0" name="python3-urllib3" release="6.u5.fos23" version="1.26.12">
					<filename>python3-urllib3-1.26.12-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-urllib3-1.26.12-6.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2319</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24329" id="CVE-2023-24329" title="CVE-2023-24329" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40217" id="CVE-2023-40217" title="CVE-2023-40217" type="cve"></reference>
		</references>
		<description>CVE-2023-24329:An issue in the urllib.parse component of Python before 3.11.4 allows attackers to bypass blocklisting methods by supplying a URL that starts with blank characters.&#xA;CVE-2023-40217:An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as &#34;not connected&#34; and won&#39;t initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="python3" release="28.u8.fos23" version="3.9.9">
					<filename>python3-3.9.9-28.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-3.9.9-28.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="28.u8.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-28.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-unversioned-command-3.9.9-28.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="28.u8.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-28.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-devel-3.9.9-28.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="28.u8.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-28.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-debug-3.9.9-28.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="28.u8.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-28.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-help-3.9.9-28.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="28.u8.fos23" version="3.9.9">
					<filename>python3-3.9.9-28.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-3.9.9-28.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="28.u8.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-28.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-unversioned-command-3.9.9-28.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="28.u8.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-28.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-devel-3.9.9-28.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="28.u8.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-28.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-debug-3.9.9-28.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2320</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3255" id="CVE-2023-3255" title="CVE-2023-3255" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3255" id="CVE-2023-3255" title="CVE-2023-3255" type="cve"></reference>
		</references>
		<description>CVE-2023-3255:A flaw was found in the QEMU built-in VNC server while processing ClientCutText messages. A wrong exit condition may lead to an infinite loop when inflating an attacker controlled zlib buffer in the `inflate_buffer` function. This could allow a remote authenticated client who is able to send a clipboard to the VNC server to trigger a denial of service.&#xA;CVE-2023-3255:A flaw was found in the QEMU built-in VNC server while processing ClientCutText messages. A wrong exit condition may lead to an infinite loop when inflating an attacker controlled zlib buffer in the `inflate_buffer` function. This could allow a remote authenticated client who is able to send a clipboard to the VNC server to trigger a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="10" name="qemu" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-guest-agent-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-83.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-help-6.2.0-83.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-img-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-block-rbd-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-block-ssh-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-block-iscsi-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-block-curl-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-hw-usb-host-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-seabios-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-system-aarch64-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-system-arm-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-system-x86_64-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-83.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qemu-system-riscv-6.2.0-83.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-guest-agent-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-img-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-block-rbd-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-block-ssh-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-block-iscsi-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-block-curl-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-hw-usb-host-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-system-aarch64-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-system-arm-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-system-x86_64-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="83.u11.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-83.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qemu-system-riscv-6.2.0-83.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2321</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33285" id="CVE-2023-33285" title="CVE-2023-33285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34410" id="CVE-2023-34410" title="CVE-2023-34410" type="cve"></reference>
		</references>
		<description>CVE-2023-33285:An issue was discovered in Qt 5.x before 5.15.14, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1. QDnsLookup has a buffer over-read via a crafted reply from a DNS server.&#xA;CVE-2023-34410:An issue was discovered in Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.2. Certificate validation for TLS does not always consider whether the root of a chain is a configured CA certificate.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-11.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-common-5.15.2-11.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-devel-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-private-devel-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-examples-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-static-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-mysql-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-odbc-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-postgresql-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/qt5-qtbase-gui-5.15.2-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-devel-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-private-devel-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-examples-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-static-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-mysql-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-odbc-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-postgresql-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="11.u5.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/qt5-qtbase-gui-5.15.2-11.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2322</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45145" id="CVE-2023-45145" title="CVE-2023-45145" type="cve"></reference>
		</references>
		<description>CVE-2023-45145:Redis is an in-memory database that persists on disk. On startup, Redis begins listening on a Unix socket before adjusting its permissions to the user-provided configuration. If a permissive umask(2) is used, this creates a race condition that enables, during a short period of time, another process to establish an otherwise unauthorized connection. This problem has existed since Redis 2.6.0-RC1. This issue has been addressed in Redis versions 7.2.2, 7.0.14 and 6.2.14. Users are advised to upgrade. For users unable to upgrade, it is possible to work around the problem by disabling Unix sockets, starting Redis with a restrictive umask, or storing the Unix socket file in a protected directory.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u6.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/redis6-6.2.7-3.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u6.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/redis6-devel-6.2.7-3.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u6.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/redis6-doc-6.2.7-3.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u6.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/redis6-6.2.7-3.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u6.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/redis6-devel-6.2.7-3.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2323</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3961" id="CVE-2023-3961" title="CVE-2023-3961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4091" id="CVE-2023-4091" title="CVE-2023-4091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4154" id="CVE-2023-4154" title="CVE-2023-4154" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42669" id="CVE-2023-42669" title="CVE-2023-42669" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42670" id="CVE-2023-42670" title="CVE-2023-42670" type="cve"></reference>
		</references>
		<description>CVE-2023-3961:A path traversal vulnerability was identified in Samba when processing client pipe names connecting to Unix domain sockets within a private directory. Samba typically uses this mechanism to connect SMB clients to remote procedure call (RPC) services like SAMR LSA or SPOOLSS, which Samba initiates on demand. However, due to inadequate sanitization of incoming client pipe names, allowing a client to send a pipe name containing Unix directory traversal characters (../). This could result in SMB clients connecting as root to Unix domain sockets outside the private directory. If an attacker or client managed to send a pipe name resolving to an external service using an existing Unix domain socket, it could potentially lead to unauthorized access to the service and consequential adverse events, including compromise or service crashes.&#xA;CVE-2023-4091:A vulnerability was discovered in Samba, where the flaw allows SMB clients to truncate files, even with read-only permissions when the Samba VFS module &#34;acl_xattr&#34; is configured with &#34;acl_xattr:ignore system acls = yes&#34;. The SMB protocol allows opening files when the client requests read-only access but then implicitly truncates the opened file to 0 bytes if the client specifies a separate OVERWRITE create disposition request. The issue arises in configurations that bypass kernel file system permissions checks, relying solely on Samba&#39;s permissions.&#xA;CVE-2023-4154:A design flaw was found in Samba&#39;s DirSync control implementation, which exposes passwords and secrets in Active Directory to privileged users and Read-Only Domain Controllers (RODCs). This flaw allows RODCs and users possessing the GET_CHANGES right to access all attributes, including sensitive secrets and passwords. Even in a default setup, RODC DC accounts, which should only replicate some passwords, can gain access to all domain secrets, including the vital krbtgt, effectively eliminating the RODC / DC distinction. Furthermore, the vulnerability fails to account for error conditions (fail open), like out-of-memory situations, potentially granting access to secret attributes, even under low-privileged attacker influence.&#xA;CVE-2023-42669:A vulnerability was found in Samba&#39;s &#34;rpcecho&#34; development server, a non-Windows RPC server used to test Samba&#39;s DCE/RPC stack elements. This vulnerability stems from an RPC function that can be blocked indefinitely. The issue arises because the &#34;rpcecho&#34; service operates with only one worker in the main RPC task, allowing calls to the &#34;rpcecho&#34; server to be blocked for a specified time, causing service disruptions. This disruption is triggered by a &#34;sleep()&#34; call in the &#34;dcesrv_echo_TestSleep()&#34; function under specific conditions. Authenticated users or attackers can exploit this vulnerability to make calls to the &#34;rpcecho&#34; server, requesting it to block for a specified duration, effectively disrupting most services and leading to a complete denial of service on the AD DC. The DoS affects all other services as &#34;rpcecho&#34; runs in the main RPC task.&#xA;CVE-2023-42670:A flaw was found in Samba. It is susceptible to a vulnerability where multiple incompatible RPC listeners can be initiated, causing disruptions in the AD DC service. When Samba&#39;s RPC server experiences a high load or unresponsiveness, servers intended for non-AD DC purposes (for example, NT4-emulation &#34;classic DCs&#34;) can erroneously start and compete for the same unix domain sockets. This issue leads to partial query responses from the AD DC, causing issues such as &#34;The procedure number is out of range&#34; when using tools like Active Directory Users. This flaw allows an attacker to disrupt AD DC services.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="samba" release="8.u6.fos23" version="4.17.5">
					<filename>samba-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-libs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-libs-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client" release="8.u6.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-client-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client-libs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-client-libs-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-client-libs-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common" release="8.u6.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-common-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common-tools" release="8.u6.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-common-tools-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-dc-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-provision" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-dc-provision-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-libs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-libs-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-dc-libs-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-bind-dlz" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-dc-bind-dlz-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-devel" release="8.u6.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-devel-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-vfs-glusterfs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-vfs-glusterfs-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-vfs-glusterfs-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-krb5-printing" release="8.u6.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-krb5-printing-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient" release="8.u6.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libsmbclient-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient-devel" release="8.u6.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libsmbclient-devel-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient" release="8.u6.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwbclient-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient-devel" release="8.u6.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/libwbclient-devel-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba" release="8.u6.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-samba-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-test" release="8.u6.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-samba-test-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-dc" release="8.u6.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/python3-samba-dc-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="samba-pidl" release="8.u6.fos23" version="4.17.5">
					<filename>samba-pidl-4.17.5-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-pidl-4.17.5-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-test" release="8.u6.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-test-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-usershares" release="8.u6.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-usershares-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-winbind-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-clients" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-winbind-clients-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-krb5-locator" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-winbind-krb5-locator-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-modules" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-winbind-modules-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ctdb" release="8.u6.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/ctdb-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-help" release="8.u6.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/samba-help-4.17.5-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba" release="8.u6.fos23" version="4.17.5">
					<filename>samba-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-libs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-libs-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client" release="8.u6.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-client-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client-libs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-client-libs-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-client-libs-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common" release="8.u6.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-common-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common-tools" release="8.u6.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-common-tools-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-dc-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-provision" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-dc-provision-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-libs" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-libs-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-dc-libs-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-bind-dlz" release="8.u6.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-dc-bind-dlz-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-devel" release="8.u6.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-devel-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-krb5-printing" release="8.u6.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-krb5-printing-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient" release="8.u6.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libsmbclient-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient-devel" release="8.u6.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libsmbclient-devel-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient" release="8.u6.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libwbclient-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient-devel" release="8.u6.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/libwbclient-devel-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba" release="8.u6.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-samba-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-test" release="8.u6.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-samba-test-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-dc" release="8.u6.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/python3-samba-dc-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-test" release="8.u6.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-test-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-usershares" release="8.u6.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-usershares-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-winbind-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-clients" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-winbind-clients-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-krb5-locator" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-winbind-krb5-locator-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-modules" release="8.u6.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-winbind-modules-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctdb" release="8.u6.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/ctdb-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-help" release="8.u6.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/samba-help-4.17.5-8.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2324</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40546" id="CVE-2023-40546" title="CVE-2023-40546" type="cve"></reference>
		</references>
		<description>CVE-2023-0464:A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints.  Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-3817:Applications that use the functions DH_check(), DH_check_ex() or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.&#xA;CVE-2023-40546:A vulnerability classified as critical has been found in rhboot shim up to 15.7 on ARM. This affects the function mirror_one_esl of the file mok.c of the component mok.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="shim" release="12.u8.fos23" version="15.6">
					<filename>shim-15.6-12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/shim-15.6-12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="12.u8.fos23" version="15.6">
					<filename>shim-15.6-12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/shim-15.6-12.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2325</id>
		<title>An update for snappy-java is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43642" id="CVE-2023-43642" title="CVE-2023-43642" type="cve"></reference>
		</references>
		<description>CVE-2023-43642:snappy-java is a Java port of the snappy, a fast C++ compresser/decompresser developed by Google. The SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. All versions of snappy-java including the latest released version 1.1.10.3 are vulnerable to this issue. A fix has been introduced in commit `9f8c3cf74` which will be included in the 1.1.10.4 release. Users are advised to upgrade. Users unable to upgrade should only accept compressed data from trusted sources.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="snappy-java" release="3.u2.fos23" version="1.1.2.4">
					<filename>snappy-java-1.1.2.4-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/snappy-java-1.1.2.4-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="snappy-java-javadoc" release="3.u2.fos23" version="1.1.2.4">
					<filename>snappy-java-javadoc-1.1.2.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/snappy-java-javadoc-1.1.2.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="snappy-java" release="3.u2.fos23" version="1.1.2.4">
					<filename>snappy-java-1.1.2.4-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/snappy-java-1.1.2.4-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2326</id>
		<title>An update for sqlite-jdbc is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32697" id="CVE-2023-32697" title="CVE-2023-32697" type="cve"></reference>
		</references>
		<description>CVE-2023-32697:SQLite JDBC is a library for accessing and creating SQLite database files in Java. Sqlite-jdbc addresses a remote code execution vulnerability via JDBC URL. This issue impacting versions 3.6.14.1 through 3.41.2.1 and has been fixed in version 3.41.2.2.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="sqlite-jdbc" release="2.u1.fos23" version="3.15.1">
					<filename>sqlite-jdbc-3.15.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/sqlite-jdbc-3.15.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sqlite-jdbc-javadoc" release="2.u1.fos23" version="3.15.1">
					<filename>sqlite-jdbc-javadoc-3.15.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/sqlite-jdbc-javadoc-3.15.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite-jdbc" release="2.u1.fos23" version="3.15.1">
					<filename>sqlite-jdbc-3.15.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/sqlite-jdbc-3.15.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2327</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46724" id="CVE-2023-46724" title="CVE-2023-46724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46728" id="CVE-2023-46728" title="CVE-2023-46728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46846" id="CVE-2023-46846" title="CVE-2023-46846" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46847" id="CVE-2023-46847" title="CVE-2023-46847" type="cve"></reference>
		</references>
		<description>CVE-2023-46724:Squid is a caching proxy for the Web. Due to an Improper Validation of Specified Index bug, Squid versions 3.3.0.1 through 5.9 and 6.0 prior to 6.4 compiled using `--with-openssl` are vulnerable to a Denial of Service attack against SSL Certificate validation. This problem allows a remote server to perform Denial of Service against Squid Proxy by initiating a TLS Handshake with a specially crafted SSL Certificate in a server certificate chain. This attack is limited to HTTPS and SSL-Bump. This bug is fixed in Squid version 6.4. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives. Those who you use a prepackaged version of Squid should refer to the package vendor for availability information on updated packages.&#xA;CVE-2023-46728:Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to a NULL pointer dereference bug Squid is vulnerable to a Denial of Service attack against Squid&#39;s Gopher gateway. The gopher protocol is always available and enabled in Squid prior to Squid 6.0.1. Responses triggering this bug are possible to be received from any gopher server, even those without malicious intent. Gopher support has been removed in Squid version 6.0.1. Users are advised to upgrade. Users unable to upgrade should reject all gopher URL requests.&#xA;CVE-2023-46846:SQUID is vulnerable to HTTP request smuggling, caused by chunked decoder lenience, allows a remote attacker to perform Request/Response smuggling past firewall and frontend security systems.&#xA;CVE-2023-46847:Squid is vulnerable to a Denial of Service,  where a remote attacker can perform buffer overflow attack by writing up to 2 MB of arbitrary data to heap memory when Squid is configured to accept HTTP Digest Authentication.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="7" name="squid" release="20.u1.fos23" version="4.9">
					<filename>squid-4.9-20.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/squid-4.9-20.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="20.u1.fos23" version="4.9">
					<filename>squid-4.9-20.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/squid-4.9-20.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2328</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45648" id="CVE-2023-45648" title="CVE-2023-45648" type="cve"></reference>
		</references>
		<description>CVE-2023-45648:Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.81 and from 8.5.0 through 8.5.93 did not correctly parse HTTP trailer headers. A specially crafted, invalid trailer header could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="noarch" epoch="1" name="tomcat" release="32.u9.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-32.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/tomcat-9.0.10-32.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="32.u9.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-32.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/tomcat-jsvc-9.0.10-32.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="32.u9.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-32.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/tomcat-help-9.0.10-32.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2329</id>
		<title>An update for traceroute is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46316" id="CVE-2023-46316" title="CVE-2023-46316" type="cve"></reference>
		</references>
		<description>CVE-2023-46316:In buc Traceroute 2.0.12 through 2.1.2 before 2.1.3, the wrapper scripts do not properly parse command lines.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="3" name="traceroute" release="2.fos23" version="2.1.2">
					<filename>traceroute-2.1.2-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/traceroute-2.1.2-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="3" name="traceroute-help" release="2.fos23" version="2.1.2">
					<filename>traceroute-help-2.1.2-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/traceroute-help-2.1.2-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="3" name="traceroute" release="2.fos23" version="2.1.2">
					<filename>traceroute-2.1.2-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/traceroute-2.1.2-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2330</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46246" id="CVE-2023-46246" title="CVE-2023-46246" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5344" id="CVE-2023-5344" title="CVE-2023-5344" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5441" id="CVE-2023-5441" title="CVE-2023-5441" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5535" id="CVE-2023-5535" title="CVE-2023-5535" type="cve"></reference>
		</references>
		<description>CVE-2023-46246:Vim is an improved version of the good old UNIX editor Vi. Heap-use-after-free in memory allocated in the function `ga_grow_inner` in in the file `src/alloc.c` at line 748, which is freed in the file `src/ex_docmd.c` in the function `do_cmdline` at line 1010 and then used again in `src/cmdhist.c` at line 759. When using the `:history` command, it&#39;s possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free. This vulnerability has been patched in version 9.0.2068.&#xA;CVE-2023-5344:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1969.&#xA;CVE-2023-5441:NULL Pointer Dereference in GitHub repository vim/vim prior to 20d161ace307e28690229b68584f2d84556f8960.&#xA;CVE-2023-5535:Use After Free in GitHub repository vim/vim prior to v9.0.2010.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="21.u11.fos23" version="9.0">
					<filename>vim-common-9.0-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/vim-common-9.0-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="21.u11.fos23" version="9.0">
					<filename>vim-minimal-9.0-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/vim-minimal-9.0-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="21.u11.fos23" version="9.0">
					<filename>vim-enhanced-9.0-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/vim-enhanced-9.0-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="21.u11.fos23" version="9.0">
					<filename>vim-filesystem-9.0-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/vim-filesystem-9.0-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="21.u11.fos23" version="9.0">
					<filename>vim-X11-9.0-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/vim-X11-9.0-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="21.u11.fos23" version="9.0">
					<filename>vim-common-9.0-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/vim-common-9.0-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="21.u11.fos23" version="9.0">
					<filename>vim-minimal-9.0-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/vim-minimal-9.0-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="21.u11.fos23" version="9.0">
					<filename>vim-enhanced-9.0-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/vim-enhanced-9.0-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="21.u11.fos23" version="9.0">
					<filename>vim-X11-9.0-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/vim-X11-9.0-21.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2331</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5371" id="CVE-2023-5371" title="CVE-2023-5371" type="cve"></reference>
		</references>
		<description>CVE-2023-5371:RTPS dissector memory leak in Wireshark 4.0.0 to 4.0.8 and 3.6.0 to 3.6.16 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="4.u7.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-4.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/wireshark-3.6.14-4.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="4.u7.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-4.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/wireshark-devel-3.6.14-4.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="4.u7.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-4.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/wireshark-help-3.6.14-4.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="4.u7.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-4.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/wireshark-3.6.14-4.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="4.u7.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-4.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/wireshark-devel-3.6.14-4.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="4.u7.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-4.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/wireshark-help-3.6.14-4.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2332</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5367" id="CVE-2023-5367" title="CVE-2023-5367" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5380" id="CVE-2023-5380" title="CVE-2023-5380" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"></reference>
		</references>
		<description>CVE-2023-5367:A out-of-bounds write flaw was found in the xorg-x11-server. This issue occurs due to an incorrect calculation of a buffer offset when copying data stored in the heap in the XIChangeDeviceProperty function in Xi/xiproperty.c and in RRChangeOutputProperty function in randr/rrproperty.c, allowing for possible escalation of privileges or denial of service.&#xA;CVE-2023-5380:A use-after-free flaw was found in the xorg-x11-server. An X server crash may occur in a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode) if the pointer is warped from within a window on one screen to the root window of the other screen and if the original window is destroyed followed by another window being destroyed.&#xA;CVE-2023-5574:A use-after-free flaw was found in xorg-x11-server-Xvfb. This issue occurs in Xvfb with a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode). If the pointer is warped from a screen 1 to a screen 0, a use-after-free issue may be triggered during shutdown or reset of the Xvfb server, allowing for possible escalation of privileges or denial of service.&#xA;CVE-2023-5574:A use-after-free flaw was found in xorg-x11-server-Xvfb. This issue occurs in Xvfb with a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode). If the pointer is warped from a screen 1 to a screen 0, a use-after-free issue may be triggered during shutdown or reset of the Xvfb server, allowing for possible escalation of privileges or denial of service.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-common-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-Xnest-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-Xdmx-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-Xvfb-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-Xephyr-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-23.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-devel-1.20.11-23.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-23.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-help-1.20.11-23.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-23.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/xorg-x11-server-source-1.20.11-23.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-common-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-Xnest-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-Xdmx-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-Xvfb-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-Xephyr-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="23.u10.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-23.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/xorg-x11-server-devel-1.20.11-23.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2333</id>
		<title>An update for zlib is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45853" id="CVE-2023-45853" title="CVE-2023-45853" type="cve"></reference>
		</references>
		<description>CVE-2023-45853:MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="zlib" release="24.u1.fos23" version="1.2.11">
					<filename>zlib-1.2.11-24.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/zlib-1.2.11-24.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="zlib-devel" release="24.u1.fos23" version="1.2.11">
					<filename>zlib-devel-1.2.11-24.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/zlib-devel-1.2.11-24.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="zlib-help" release="24.u1.fos23" version="1.2.11">
					<filename>zlib-help-1.2.11-24.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/zlib-help-1.2.11-24.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="minizip" release="24.u1.fos23" version="1.2.11">
					<filename>minizip-1.2.11-24.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/minizip-1.2.11-24.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="minizip-devel" release="24.u1.fos23" version="1.2.11">
					<filename>minizip-devel-1.2.11-24.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/minizip-devel-1.2.11-24.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zlib" release="24.u1.fos23" version="1.2.11">
					<filename>zlib-1.2.11-24.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/zlib-1.2.11-24.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zlib-devel" release="24.u1.fos23" version="1.2.11">
					<filename>zlib-devel-1.2.11-24.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/zlib-devel-1.2.11-24.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="minizip" release="24.u1.fos23" version="1.2.11">
					<filename>minizip-1.2.11-24.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/minizip-1.2.11-24.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="minizip-devel" release="24.u1.fos23" version="1.2.11">
					<filename>minizip-devel-1.2.11-24.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/minizip-devel-1.2.11-24.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2334</id>
		<title>An update for zookeeper is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-11-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44981" id="CVE-2023-44981" title="CVE-2023-44981" type="cve"></reference>
		</references>
		<description>CVE-2023-44981:Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it&#39;s missing, like &#39;eve@EXAMPLE.COM&#39;, the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="noarch" epoch="0" name="zookeeper" release="2.4.u1.fos23" version="3.6.2">
					<filename>zookeeper-3.6.2-2.4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/zookeeper-3.6.2-2.4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2335</id>
		<title>An update for apache-commons-net is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37533" id="CVE-2021-37533" title="CVE-2021-37533" type="cve"></reference>
		</references>
		<description>CVE-2021-37533:Prior to Apache Commons Net 3.9.0, Net&#39;s FTP client trusts the host from PASV response by default. A malicious server can redirect the Commons Net code to use a different host, but the user has to connect to the malicious server in the first place. This may lead to leakage of information about services running on the private network of the client. The default in version 3.9.0 is now false to ignore such hosts, as cURL does. See https://issues.apache.org/jira/browse/NET-711.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="0" name="apache-commons-net" release="7.u3.fos23" version="3.6">
					<filename>apache-commons-net-3.6-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/apache-commons-net-3.6-7.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-net-help" release="7.u3.fos23" version="3.6">
					<filename>apache-commons-net-help-3.6-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/apache-commons-net-help-3.6-7.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2336</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46218" id="CVE-2023-46218" title="CVE-2023-46218" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46219" id="CVE-2023-46219" title="CVE-2023-46219" type="cve"></reference>
		</references>
		<description>CVE-2023-46218:This flaw allows a malicious HTTP server to set &#34;super cookies&#34; in curl that are then passed back to more origins than what is otherwise allowed or possible. This allows a site to set cookies that then would get sent to different and unrelated sites and domains. It could do this by exploiting a mixed case flaw in curl&#39;s function that verifies a given cookie domain against the Public Suffix List (PSL). For example a cookie could be set with `domain=co.UK` when the URL used a lower case hostname `curl.co.uk`, even though `co.uk` is listed as a PSL domain.&#xA;CVE-2023-46219:When saving HSTS data to an excessively long file name, curl could end up removing all contents, making subsequent requests using that file unaware of the HSTS status they should otherwise use.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="curl" release="25.u12.fos23" version="7.79.1">
					<filename>curl-7.79.1-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/curl-7.79.1-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="25.u12.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libcurl-7.79.1-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="25.u12.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libcurl-devel-7.79.1-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="25.u12.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-25.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/curl-help-7.79.1-25.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="25.u12.fos23" version="7.79.1">
					<filename>curl-7.79.1-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/curl-7.79.1-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="25.u12.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/libcurl-7.79.1-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="25.u12.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/libcurl-devel-7.79.1-25.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2337</id>
		<title>An update for gdb is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39130" id="CVE-2023-39130" title="CVE-2023-39130" type="cve"></reference>
		</references>
		<description>CVE-2023-39130:GNU gdb (GDB) 13.0.50.20220805-git was discovered to contain a heap buffer overflow via the function pe_as16() at /gdb/coff-pe-read.c.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="gdb" release="8.u4.fos23" version="11.1">
					<filename>gdb-11.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gdb-11.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-headless" release="8.u4.fos23" version="11.1">
					<filename>gdb-headless-11.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gdb-headless-11.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-gdbserver" release="8.u4.fos23" version="11.1">
					<filename>gdb-gdbserver-11.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gdb-gdbserver-11.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdb-help" release="8.u4.fos23" version="11.1">
					<filename>gdb-help-11.1-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gdb-help-11.1-8.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb" release="8.u4.fos23" version="11.1">
					<filename>gdb-11.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/gdb-11.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-headless" release="8.u4.fos23" version="11.1">
					<filename>gdb-headless-11.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/gdb-headless-11.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-gdbserver" release="8.u4.fos23" version="11.1">
					<filename>gdb-gdbserver-11.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/gdb-gdbserver-11.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2338</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46751" id="CVE-2023-46751" title="CVE-2023-46751" type="cve"></reference>
		</references>
		<description>CVE-2023-46751:An issue was discovered in the function gdev_prn_open_printer_seekable() in Artifex Ghostscript through 10.02.0 allows remote attackers to crash the application via a dangling pointer.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/ghostscript-9.55.0-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/ghostscript-devel-9.55.0-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/ghostscript-help-9.55.0-5.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/ghostscript-tools-dvipdf-9.55.0-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/ghostscript-9.55.0-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/ghostscript-devel-9.55.0-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="5.u4.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/ghostscript-tools-dvipdf-9.55.0-5.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2339</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48161" id="CVE-2023-48161" title="CVE-2023-48161" type="cve"></reference>
		</references>
		<description>CVE-2023-48161:Buffer Overflow vulnerability in GifLib Project GifLib v.5.2.1 allows a local attacker to obtain sensitive information via the DumpSCreen2RGB function in gif2rgb.c</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="giflib" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-5.2.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/giflib-5.2.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-devel" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/giflib-devel-5.2.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-utils" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/giflib-utils-5.2.1-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="giflib-help" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-help-5.2.1-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/giflib-help-5.2.1-7.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-5.2.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/giflib-5.2.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-devel" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/giflib-devel-5.2.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-utils" release="7.u3.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/giflib-utils-5.2.1-7.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2340</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5981" id="CVE-2023-5981" title="CVE-2023-5981" type="cve"></reference>
		</references>
		<description>CVE-2023-5981:A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="gnutls" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gnutls-3.7.2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gnutls-devel-3.7.2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gnutls-utils-3.7.2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnutls-help" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-help-3.7.2-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/gnutls-help-3.7.2-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/gnutls-3.7.2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/gnutls-devel-3.7.2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="10.u4.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/gnutls-utils-3.7.2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2341</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0836" id="CVE-2023-0836" title="CVE-2023-0836" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45539" id="CVE-2023-45539" title="CVE-2023-45539" type="cve"></reference>
		</references>
		<description>CVE-2023-0836:An information leak vulnerability was discovered in HAProxy 2.1, 2.2 before 2.2.27, 2.3, 2.4 before 2.4.21, 2.5 before 2.5.11, 2.6 before 2.6.8, 2.7 before 2.7.1. There are 5 bytes left uninitialized in the connection buffer when encoding the FCGI_BEGIN_REQUEST record. Sensitive data may be disclosed to configured FastCGI backends in an unexpected way.&#xA;CVE-2023-45539:HAProxy before 2.8.2 accepts # as part of the URI component, which might allow remote attackers to obtain sensitive information or have unspecified other impact upon misinterpretation of a path_end rule, such as routing index.html#.png to a static server.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="8.u6.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/haproxy-2.6.6-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="8.u6.fos23" version="2.6.6">
					<filename>haproxy-help-2.6.6-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/haproxy-help-2.6.6-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="8.u6.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/haproxy-2.6.6-8.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2342</id>
		<title>An update for hsqldb is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41853" id="CVE-2022-41853" title="CVE-2022-41853" type="cve"></reference>
		</references>
		<description>CVE-2022-41853:Those using java.sql.Statement or java.sql.PreparedStatement in hsqldb (HyperSQL DataBase) to process untrusted input may be vulnerable to a remote code execution attack. By default it is allowed to call any static method of any Java class in the classpath resulting in code execution. The issue can be prevented by updating to 2.7.1 or by setting the system property &#34;hsqldb.method_class_names&#34; to classes which are allowed to be called. For example, System.setProperty(&#34;hsqldb.method_class_names&#34;, &#34;abc&#34;) or Java argument -Dhsqldb.method_class_names=&#34;abc&#34; can be used. From version 2.7.1 all classes by default are not accessible except those in java.lang.Math and need to be manually enabled.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="1" name="hsqldb" release="5.u1.fos23" version="2.4.0">
					<filename>hsqldb-2.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/hsqldb-2.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-lib" release="5.u1.fos23" version="2.4.0">
					<filename>hsqldb-lib-2.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/hsqldb-lib-2.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-manual" release="5.u1.fos23" version="2.4.0">
					<filename>hsqldb-manual-2.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/hsqldb-manual-2.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-javadoc" release="5.u1.fos23" version="2.4.0">
					<filename>hsqldb-javadoc-2.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/hsqldb-javadoc-2.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-demo" release="5.u1.fos23" version="2.4.0">
					<filename>hsqldb-demo-2.4.0-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/hsqldb-demo-2.4.0-5.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2343</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22067" id="CVE-2023-22067" title="CVE-2023-22067" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
		</references>
		<description>CVE-2023-22067:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: CORBA).  Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf; Oracle GraalVM Enterprise Edition: 20.3.11 and  21.3.7. Easily exploitable vulnerability allows unauthenticated attacker with network access via CORBA to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.3 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-22081:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf, 11.0.20, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 20.3.11, 21.3.7 and  22.3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-headless-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-headless-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-headless-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-devel-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-devel-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-demo-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-demo-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-demo-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-src-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-src-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-src-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.392.b08-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-javadoc-1.8.0.392.b08-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.392.b08-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-javadoc-zip-1.8.0.392.b08-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-accessibility-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-devel-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-headless-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-headless-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-headless-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-devel-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-devel-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-demo-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-demo-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-demo-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-src-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-src-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-src-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-accessibility-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-devel-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="2.u1.fos23" version="1.8.0.392.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.392.b08-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2344</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"></reference>
		</references>
		<description>CVE-2023-22081:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf, 11.0.20, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 20.3.11, 21.3.7 and  22.3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2023-22025:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u381-perf, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 21.3.7 and  22.3.3. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition,.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-headless-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-headless-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-headless-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-headless-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-devel-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-devel-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-devel-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-devel-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-jmods-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-jmods-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-jmods-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-demo-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-demo-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-demo-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-demo-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-src-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-src-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-src-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-src-slowdebug-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-javadoc-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-javadoc-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-javadoc-zip-11.0.21.9-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/java-11-openjdk-javadoc-zip-11.0.21.9-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-headless-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-headless-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-headless-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-headless-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-devel-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-devel-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-devel-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-devel-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-jmods-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-jmods-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-jmods-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-demo-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-demo-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-demo-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-demo-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-src-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-src-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-src-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-src-slowdebug-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-javadoc-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-javadoc-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="1.fos23" version="11.0.21.9">
					<filename>java-11-openjdk-javadoc-zip-11.0.21.9-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/java-11-openjdk-javadoc-zip-11.0.21.9-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2345</id>
		<title>An update for jettison is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40149" id="CVE-2022-40149" title="CVE-2022-40149" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40150" id="CVE-2022-40150" title="CVE-2022-40150" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45693" id="CVE-2022-45693" title="CVE-2022-45693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1436" id="CVE-2023-1436" title="CVE-2023-1436" type="cve"></reference>
		</references>
		<description>CVE-2022-40149:Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.&#xA;CVE-2022-40150:Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack.&#xA;CVE-2022-45685:A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data.&#xA;CVE-2022-45693:Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string.&#xA;CVE-2023-1436:An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="0" name="jettison" release="1.u3.fos23" version="1.5.4">
					<filename>jettison-1.5.4-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/jettison-1.5.4-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jettison-javadoc" release="1.u3.fos23" version="1.5.4">
					<filename>jettison-javadoc-1.5.4-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/jettison-javadoc-1.5.4-1.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2346</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42755" id="CVE-2023-42755" title="CVE-2023-42755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5197" id="CVE-2023-5197" title="CVE-2023-5197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1193" id="CVE-2023-1193" title="CVE-2023-1193" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25775" id="CVE-2023-25775" title="CVE-2023-25775" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47233" id="CVE-2023-47233" title="CVE-2023-47233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6176" id="CVE-2023-6176" title="CVE-2023-6176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39197" id="CVE-2023-39197" title="CVE-2023-39197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5197" id="CVE-2023-5197" title="CVE-2023-5197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42753" id="CVE-2023-42753" title="CVE-2023-42753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39194" id="CVE-2023-39194" title="CVE-2023-39194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45871" id="CVE-2023-45871" title="CVE-2023-45871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42754" id="CVE-2023-42754" title="CVE-2023-42754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39192" id="CVE-2023-39192" title="CVE-2023-39192" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39193" id="CVE-2023-39193" title="CVE-2023-39193" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39189" id="CVE-2023-39189" title="CVE-2023-39189" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31085" id="CVE-2023-31085" title="CVE-2023-31085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5717" id="CVE-2023-5717" title="CVE-2023-5717" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45862" id="CVE-2023-45862" title="CVE-2023-45862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45919" id="CVE-2022-45919" title="CVE-2022-45919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31083" id="CVE-2023-31083" title="CVE-2023-31083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2593" id="CVE-2023-2593" title="CVE-2023-2593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32256" id="CVE-2023-32256" title="CVE-2023-32256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32258" id="CVE-2023-32258" title="CVE-2023-32258" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32246" id="CVE-2023-32246" title="CVE-2023-32246" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32254" id="CVE-2023-32254" title="CVE-2023-32254" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44033" id="CVE-2022-44033" title="CVE-2022-44033" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34324" id="CVE-2023-34324" title="CVE-2023-34324" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2898" id="CVE-2023-2898" title="CVE-2023-2898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46862" id="CVE-2023-46862" title="CVE-2023-46862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37453" id="CVE-2023-37453" title="CVE-2023-37453" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5178" id="CVE-2023-5178" title="CVE-2023-5178" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46813" id="CVE-2023-46813" title="CVE-2023-46813" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45884" id="CVE-2022-45884" title="CVE-2022-45884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39198" id="CVE-2023-39198" title="CVE-2023-39198" type="cve"></reference>
		</references>
		<description>CVE-2023-42755:A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service.&#xA;CVE-2023-5197:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation. Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.&#xA;CVE-2023-1193:A use-after-free flaw was found in setup_async_work in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. This issue could allow an attacker to crash the system by accessing freed work.&#xA;CVE-2023-25775:Improper access control in the Intel(R) Ethernet Controller RDMA driver for linux before version 1.9.30 may allow an unauthenticated user to potentially enable escalation of privilege via network access.&#xA;CVE-2023-47233:The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this &#34;could be exploited in a real world scenario.&#34; This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.&#xA;CVE-2023-6176:A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific socket configuration, which could allow a local user to crash the system or escalate their privileges on the system.&#xA;CVE-2023-39197:An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.&#xA;CVE-2023-5197:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation. Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.&#xA;CVE-2023-42753:An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the `h-&gt;nets` array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.&#xA;CVE-2023-39194:A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.&#xA;CVE-2023-45871:An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU.&#xA;CVE-2023-42754:A NULL pointer dereference flaw was found in the Linux kernel ipv4 stack. The socket buffer (skb) was assumed to be associated with a device before calling __ip_options_compile, which is not always the case if the skb is re-routed by ipvs. This issue may allow a local user with CAP_NET_ADMIN privileges to crash the system.&#xA;CVE-2023-39192:A flaw was found in the Netfilter subsystem in the Linux kernel. The xt_u32 module did not validate the fields in the xt_u32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure.&#xA;CVE-2023-39193:A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.&#xA;CVE-2023-39189:A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.&#xA;CVE-2023-31085:An issue was discovered in drivers/mtd/ubi/cdev.c in the Linux kernel 6.2. There is a divide-by-zero error in do_div(sz,mtd-&gt;erasesize), used indirectly by ctrl_cdev_ioctl, when mtd-&gt;erasesize is 0.&#xA;CVE-2023-5717:A heap out-of-bounds write vulnerability in the Linux kernel&#39;s Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation. If perf_read_group() is called while an event&#39;s sibling_list is smaller than its child&#39;s sibling_list, it can increment or write to memory locations outside of the allocated buffer.&#xA;CVE-2023-45862:An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.&#xA;CVE-2022-45919:An issue was discovered in the Linux kernel through 6.0.10. In drivers/media/dvb-core/dvb_ca_en50221.c, a use-after-free can occur is there is a disconnect after an open, because of the lack of a wait_event.&#xA;CVE-2023-31083:An issue was discovered in drivers/bluetooth/hci_ldisc.c in the Linux kernel 6.2. In hci_uart_tty_ioctl, there is a race condition between HCIUARTSETPROTO and HCIUARTGETPROTO. HCI_UART_PROTO_SET is set before hu-&gt;proto is set. A NULL pointer dereference may occur.&#xA;CVE-2023-2593:VUL-0: CVE-2023-2593: kernel: Linux Kernel ksmbd Memory Exhaustion Denial-of-Service Vulnerability&#xA;CVE-2023-32256:This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication is not required to exploit this vulnerability, but only systems with ksmbd enabled are vulnerable.The specific flaw exists within the processing of SMB2_QUERY_INFO and SMB2_LOGOFF commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the kernel.&#xA;CVE-2023-32258:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_LOGOFF and SMB2_CLOSE commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.&#xA;CVE-2023-32246:VUL-0: CVE-2023-32246: kernel: Linux Kernel ksmbd RCU Callback Race Condition Local Privilege Escalation Vulnerability&#xA;CVE-2023-32254:A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.&#xA;CVE-2022-44033:An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach().&#xA;CVE-2023-34324:Closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest. The closing of an event channel is e.g. triggered by removal of a paravirtual device on the other side. As this action will cause console messages to be issued on the other side quite often, the chance of triggering the deadlock is not neglectable.A (malicious) guest administrator could cause a denial of service (DoS) in a backend domain (other than dom0) by disabling a paravirtualized device. A malicious backend could cause DoS in a guest running a Linux kernel by disabling a paravirtualized device.&#xA;CVE-2023-2898:There is a null-pointer-dereference flaw found in f2fs_write_end_io in fs/f2fs/data.c in the Linux kernel. This flaw allows a local privileged user to cause a denial of service problem.&#xA;CVE-2023-46862:An issue was discovered in the Linux kernel through 6.5.9. During a race with SQ thread exit, an io_uring/fdinfo.c io_uring_show_fdinfo NULL pointer dereference can occur.&#xA;CVE-2023-37453:An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in read_descriptors in drivers/usb/core/sysfs.c.&#xA;CVE-2023-5178:A use-after-free vulnerability was found in drivers/nvme/target/tcp.c` in `nvmet_tcp_free_crypto` due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel. This issue may allow a malicious local privileged user to cause a use-after-free and double-free problem, which may permit remote code execution or lead to local privilege escalation problem.&#xA;CVE-2023-46813:An issue was discovered in the Linux kernel before 6.5.9, exploitable by local users with userspace access to MMIO registers. Incorrect access checking in the #VC handler and instruction emulation of the SEV-ES emulation of MMIO accesses could lead to arbitrary write access to kernel memory (and thus privilege escalation). This depends on a race condition through which userspace can replace an instruction before the #VC handler reads it.&#xA;CVE-2022-45884:An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvbdev.c has a use-after-free, related to dvb_register_device dynamically allocating fops.&#xA;CVE-2023-39198:A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/kernel-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/kernel-headers-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/kernel-devel-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/kernel-tools-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/kernel-tools-devel-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/perf-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/python3-perf-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/bpftool-5.10.0-136.57.0.136.u94.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/kernel-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/kernel-headers-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/kernel-devel-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/kernel-tools-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/kernel-tools-devel-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/perf-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/python3-perf-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.57.0.136.u94.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/bpftool-5.10.0-136.57.0.136.u94.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2347</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6277" id="CVE-2023-6277" title="CVE-2023-6277" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6277" id="CVE-2023-6277" title="CVE-2023-6277" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6228" id="CVE-2023-6228" title="CVE-2023-6228" type="cve"></reference>
		</references>
		<description>CVE-2023-6277:An out-of-memory flaw was found in libtiff. Passing a crafted tiff file to TIFFOpen() API may allow a remote attacker to cause a denial of service via a craft input with size smaller than 379 KB.&#xA;CVE-2023-6277:An out-of-memory flaw was found in libtiff. Passing a crafted tiff file to TIFFOpen() API may allow a remote attacker to cause a denial of service via a craft input with size smaller than 379 KB.&#xA;CVE-2023-6228:An issue was found in the tiffcp utility distributed by the libtiff package where a crafted TIFF file on processing may cause a heap-based buffer overflow leads to an application crash.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-36.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libtiff-4.3.0-36.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-36.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libtiff-devel-4.3.0-36.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-36.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libtiff-static-4.3.0-36.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-36.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libtiff-tools-4.3.0-36.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-36.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libtiff-help-4.3.0-36.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-36.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/libtiff-4.3.0-36.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-36.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/libtiff-devel-4.3.0-36.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-36.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/libtiff-static-4.3.0-36.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="36.u12.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-36.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/libtiff-tools-4.3.0-36.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2348</id>
		<title>An update for linux-sgx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1941" id="CVE-2022-1941" title="CVE-2022-1941" type="cve"></reference>
		</references>
		<description>CVE-2022-1941:A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input. We recommend upgrading to versions 3.18.3, 3.19.5, 3.20.2, 3.21.6 for protobuf-cpp and 3.18.3, 3.19.5, 3.20.2, 4.21.6 for protobuf-python. Versions for 3.16 and 3.17 are no longer updated.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="sgxsdk" release="9.u1.fos23" version="2.15.1">
					<filename>sgxsdk-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/sgxsdk-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qe3" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ae-qe3-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ae-qe3-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-pce-logic" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-pce-logic-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-pce-logic-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-qe3-logic" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-qe3-logic-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-qe3-logic-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-aesm-service" release="9.u1.fos23" version="2.15.1">
					<filename>sgx-aesm-service-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/sgx-aesm-service-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-epid" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ae-epid-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ae-epid-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-le" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ae-le-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ae-le-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-pce" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ae-pce-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ae-pce-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-ecdsa-plugin" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-aesm-ecdsa-plugin-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-aesm-ecdsa-plugin-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-epid-plugin" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-aesm-epid-plugin-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-aesm-epid-plugin-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-launch-plugin" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-aesm-launch-plugin-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-aesm-launch-plugin-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-pce-plugin" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-aesm-pce-plugin-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-aesm-pce-plugin-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-quote-ex-plugin" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-aesm-quote-ex-plugin-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-aesm-quote-ex-plugin-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-epid-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-epid-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-epid-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-epid-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-launch-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-launch-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-launch-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-launch-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-quote-ex-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-quote-ex-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-uae-service" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-uae-service-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-uae-service-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-enclave-common-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-enclave-common-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-urts" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-urts-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-urts-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-dcap-default-qpl-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-dcap-default-qpl-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-dcap-pccs" release="9.u1.fos23" version="2.15.1">
					<filename>sgx-dcap-pccs-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/sgx-dcap-pccs-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-dcap-ql-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-dcap-ql-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qve" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ae-qve-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ae-qve-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-dcap-quote-verify-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-dcap-quote-verify-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-pck-id-retrieval-tool" release="9.u1.fos23" version="2.15.1">
					<filename>sgx-pck-id-retrieval-tool-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/sgx-pck-id-retrieval-tool-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ra-uefi-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ra-uefi-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ra-network-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ra-network-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network-devel" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-ra-network-devel-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-ra-network-devel-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-ra-service" release="9.u1.fos23" version="2.15.1">
					<filename>sgx-ra-service-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/sgx-ra-service-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-headers" release="9.u1.fos23" version="2.15.1">
					<filename>libsgx-headers-2.15.1-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/libsgx-headers-2.15.1-9.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2349</id>
		<title>An update for mariadb is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5157" id="CVE-2023-5157" title="CVE-2023-5157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47015" id="CVE-2022-47015" title="CVE-2022-47015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38791" id="CVE-2022-38791" title="CVE-2022-38791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32087" id="CVE-2022-32087" title="CVE-2022-32087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32091" id="CVE-2022-32091" title="CVE-2022-32091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32085" id="CVE-2022-32085" title="CVE-2022-32085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32084" id="CVE-2022-32084" title="CVE-2022-32084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32088" id="CVE-2022-32088" title="CVE-2022-32088" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32083" id="CVE-2022-32083" title="CVE-2022-32083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-28912" id="CVE-2020-28912" title="CVE-2020-28912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-2144" id="CVE-2021-2144" title="CVE-2021-2144" type="cve"></reference>
		</references>
		<description>CVE-2023-5157:A vulnerability was found in MariaDB. An OpenVAS port scan on ports 3306 and 4567 allows a malicious remote client to cause a denial of service.&#xA;CVE-2022-47015:MariaDB Server before 10.3.34 thru 10.9.3 is vulnerable to Denial of Service. It is possible for function spider_db_mbase::print_warnings to dereference a null pointer.&#xA;CVE-2022-38791:In MariaDB before 10.9.2, compress_write in extra/mariabackup/ds_compress.cc does not release data_mutex upon a stream write failure, which allows local users to trigger a deadlock.&#xA;CVE-2022-0778:The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).&#xA;CVE-2022-32087:MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_args::walk_args.&#xA;CVE-2022-32091:MariaDB v10.7 was discovered to contain an use-after-poison in in __interceptor_memset at /libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc.&#xA;CVE-2022-32085:MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_func_in::cleanup/Item::cleanup_processor.&#xA;CVE-2022-32084:MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component sub_select.&#xA;CVE-2022-32088:MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Exec_time_tracker::get_loops/Filesort_tracker::report_use/filesort.&#xA;CVE-2022-32083:MariaDB v10.2 to v10.6.1 was discovered to contain a segmentation fault via the component Item_subselect::init_expr_cache_tracker.&#xA;CVE-2020-28912:With MariaDB running on Windows, when local clients connect to the server over named pipes, it&#39;s possible for an unprivileged user with an ability to run code on the server machine to intercept the named pipe connection and act as a man-in-the-middle, gaining access to all the data passed between the client and the server, and getting the ability to run SQL commands on behalf of the connected user. This occurs because of an incorrect security descriptor. This affects MariaDB Server before 10.1.48, 10.2.x before 10.2.35, 10.3.x before 10.3.26, 10.4.x before 10.4.16, and 10.5.x before 10.5.7. NOTE: this issue exists because certain details of the MariaDB CVE-2019-2503 fix did not comprehensively address attack variants against MariaDB. This situation is specific to MariaDB, and thus CVE-2020-28912 does NOT apply to other vendors that were originally affected by CVE-2019-2503.&#xA;CVE-2021-2144:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 5.7.29 and prior and 8.0.19 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in takeover of MySQL Server. CVSS 3.1 Base Score 7.2 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="4" name="mariadb" release="1.fos23" version="10.5.22">
					<filename>mariadb-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-config" release="1.fos23" version="10.5.22">
					<filename>mariadb-config-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-config-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-common" release="1.fos23" version="10.5.22">
					<filename>mariadb-common-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-common-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-errmsg" release="1.fos23" version="10.5.22">
					<filename>mariadb-errmsg-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-errmsg-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server-galera" release="1.fos23" version="10.5.22">
					<filename>mariadb-server-galera-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-server-galera-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server" release="1.fos23" version="10.5.22">
					<filename>mariadb-server-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-server-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-oqgraph-engine" release="1.fos23" version="10.5.22">
					<filename>mariadb-oqgraph-engine-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-oqgraph-engine-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-backup" release="1.fos23" version="10.5.22">
					<filename>mariadb-backup-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-backup-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-gssapi-server" release="1.fos23" version="10.5.22">
					<filename>mariadb-gssapi-server-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-gssapi-server-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-pam" release="1.fos23" version="10.5.22">
					<filename>mariadb-pam-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-pam-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server-utils" release="1.fos23" version="10.5.22">
					<filename>mariadb-server-utils-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-server-utils-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-devel" release="1.fos23" version="10.5.22">
					<filename>mariadb-devel-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-devel-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-embedded" release="1.fos23" version="10.5.22">
					<filename>mariadb-embedded-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-embedded-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-embedded-devel" release="1.fos23" version="10.5.22">
					<filename>mariadb-embedded-devel-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-embedded-devel-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-test" release="1.fos23" version="10.5.22">
					<filename>mariadb-test-10.5.22-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mariadb-test-10.5.22-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb" release="1.fos23" version="10.5.22">
					<filename>mariadb-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-config" release="1.fos23" version="10.5.22">
					<filename>mariadb-config-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-config-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-common" release="1.fos23" version="10.5.22">
					<filename>mariadb-common-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-common-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-errmsg" release="1.fos23" version="10.5.22">
					<filename>mariadb-errmsg-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-errmsg-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server-galera" release="1.fos23" version="10.5.22">
					<filename>mariadb-server-galera-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-server-galera-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server" release="1.fos23" version="10.5.22">
					<filename>mariadb-server-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-server-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-oqgraph-engine" release="1.fos23" version="10.5.22">
					<filename>mariadb-oqgraph-engine-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-oqgraph-engine-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-backup" release="1.fos23" version="10.5.22">
					<filename>mariadb-backup-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-backup-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-gssapi-server" release="1.fos23" version="10.5.22">
					<filename>mariadb-gssapi-server-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-gssapi-server-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-pam" release="1.fos23" version="10.5.22">
					<filename>mariadb-pam-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-pam-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server-utils" release="1.fos23" version="10.5.22">
					<filename>mariadb-server-utils-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-server-utils-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-devel" release="1.fos23" version="10.5.22">
					<filename>mariadb-devel-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-devel-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-embedded" release="1.fos23" version="10.5.22">
					<filename>mariadb-embedded-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-embedded-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-embedded-devel" release="1.fos23" version="10.5.22">
					<filename>mariadb-embedded-devel-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-embedded-devel-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-test" release="1.fos23" version="10.5.22">
					<filename>mariadb-test-10.5.22-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mariadb-test-10.5.22-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2350</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23583" id="CVE-2023-23583" title="CVE-2023-23583" type="cve"></reference>
		</references>
		<description>CVE-2023-23583:Sequence of processor instructions leads to unexpected behavior for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege and/or information disclosure and/or denial of service via local access.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="42.fos23" version="2.1">
					<filename>microcode_ctl-2.1-42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/microcode_ctl-2.1-42.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2351</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22068" id="CVE-2023-22068" title="CVE-2023-22068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38545" id="CVE-2023-38545" title="CVE-2023-38545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22079" id="CVE-2023-22079" title="CVE-2023-22079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22084" id="CVE-2023-22084" title="CVE-2023-22084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22064" id="CVE-2023-22064" title="CVE-2023-22064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22078" id="CVE-2023-22078" title="CVE-2023-22078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22066" id="CVE-2023-22066" title="CVE-2023-22066" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22113" id="CVE-2023-22113" title="CVE-2023-22113" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22026" id="CVE-2023-22026" title="CVE-2023-22026" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22015" id="CVE-2023-22015" title="CVE-2023-22015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22032" id="CVE-2023-22032" title="CVE-2023-22032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22059" id="CVE-2023-22059" title="CVE-2023-22059" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22070" id="CVE-2023-22070" title="CVE-2023-22070" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22115" id="CVE-2023-22115" title="CVE-2023-22115" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22028" id="CVE-2023-22028" title="CVE-2023-22028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22104" id="CVE-2023-22104" title="CVE-2023-22104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22114" id="CVE-2023-22114" title="CVE-2023-22114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22097" id="CVE-2023-22097" title="CVE-2023-22097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22110" id="CVE-2023-22110" title="CVE-2023-22110" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22065" id="CVE-2023-22065" title="CVE-2023-22065" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22112" id="CVE-2023-22112" title="CVE-2023-22112" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22092" id="CVE-2023-22092" title="CVE-2023-22092" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22111" id="CVE-2023-22111" title="CVE-2023-22111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22103" id="CVE-2023-22103" title="CVE-2023-22103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22058" id="CVE-2023-22058" title="CVE-2023-22058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22046" id="CVE-2023-22046" title="CVE-2023-22046" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22038" id="CVE-2023-22038" title="CVE-2023-22038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22053" id="CVE-2023-22053" title="CVE-2023-22053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22008" id="CVE-2023-22008" title="CVE-2023-22008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22057" id="CVE-2023-22057" title="CVE-2023-22057" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22005" id="CVE-2023-22005" title="CVE-2023-22005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22054" id="CVE-2023-22054" title="CVE-2023-22054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22033" id="CVE-2023-22033" title="CVE-2023-22033" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22048" id="CVE-2023-22048" title="CVE-2023-22048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22056" id="CVE-2023-22056" title="CVE-2023-22056" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22007" id="CVE-2023-22007" title="CVE-2023-22007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43551" id="CVE-2022-43551" title="CVE-2022-43551" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21946" id="CVE-2023-21946" title="CVE-2023-21946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21963" id="CVE-2023-21963" title="CVE-2023-21963" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21912" id="CVE-2023-21912" title="CVE-2023-21912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21945" id="CVE-2023-21945" title="CVE-2023-21945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21933" id="CVE-2023-21933" title="CVE-2023-21933" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21935" id="CVE-2023-21935" title="CVE-2023-21935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21982" id="CVE-2023-21982" title="CVE-2023-21982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21955" id="CVE-2023-21955" title="CVE-2023-21955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21929" id="CVE-2023-21929" title="CVE-2023-21929" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21966" id="CVE-2023-21966" title="CVE-2023-21966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21913" id="CVE-2023-21913" title="CVE-2023-21913" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21980" id="CVE-2023-21980" title="CVE-2023-21980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21947" id="CVE-2023-21947" title="CVE-2023-21947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21919" id="CVE-2023-21919" title="CVE-2023-21919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21972" id="CVE-2023-21972" title="CVE-2023-21972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21962" id="CVE-2023-21962" title="CVE-2023-21962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21917" id="CVE-2023-21917" title="CVE-2023-21917" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21977" id="CVE-2023-21977" title="CVE-2023-21977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21940" id="CVE-2023-21940" title="CVE-2023-21940" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21911" id="CVE-2023-21911" title="CVE-2023-21911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21976" id="CVE-2023-21976" title="CVE-2023-21976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21953" id="CVE-2023-21953" title="CVE-2023-21953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21920" id="CVE-2023-21920" title="CVE-2023-21920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32221" id="CVE-2022-32221" title="CVE-2022-32221" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21836" id="CVE-2023-21836" title="CVE-2023-21836" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21871" id="CVE-2023-21871" title="CVE-2023-21871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21865" id="CVE-2023-21865" title="CVE-2023-21865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21872" id="CVE-2023-21872" title="CVE-2023-21872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21867" id="CVE-2023-21867" title="CVE-2023-21867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21873" id="CVE-2023-21873" title="CVE-2023-21873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21864" id="CVE-2023-21864" title="CVE-2023-21864" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21870" id="CVE-2023-21870" title="CVE-2023-21870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21874" id="CVE-2023-21874" title="CVE-2023-21874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21868" id="CVE-2023-21868" title="CVE-2023-21868" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21863" id="CVE-2023-21863" title="CVE-2023-21863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21869" id="CVE-2023-21869" title="CVE-2023-21869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21882" id="CVE-2023-21882" title="CVE-2023-21882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21881" id="CVE-2023-21881" title="CVE-2023-21881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21883" id="CVE-2023-21883" title="CVE-2023-21883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21887" id="CVE-2023-21887" title="CVE-2023-21887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21880" id="CVE-2023-21880" title="CVE-2023-21880" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21879" id="CVE-2023-21879" title="CVE-2023-21879" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21875" id="CVE-2023-21875" title="CVE-2023-21875" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21876" id="CVE-2023-21876" title="CVE-2023-21876" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21877" id="CVE-2023-21877" title="CVE-2023-21877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21878" id="CVE-2023-21878" title="CVE-2023-21878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21592" id="CVE-2022-21592" title="CVE-2022-21592" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21641" id="CVE-2022-21641" title="CVE-2022-21641" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21638" id="CVE-2022-21638" title="CVE-2022-21638" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21635" id="CVE-2022-21635" title="CVE-2022-21635" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21611" id="CVE-2022-21611" title="CVE-2022-21611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21625" id="CVE-2022-21625" title="CVE-2022-21625" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21599" id="CVE-2022-21599" title="CVE-2022-21599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21632" id="CVE-2022-21632" title="CVE-2022-21632" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21633" id="CVE-2022-21633" title="CVE-2022-21633" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39400" id="CVE-2022-39400" title="CVE-2022-39400" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21640" id="CVE-2022-21640" title="CVE-2022-21640" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21608" id="CVE-2022-21608" title="CVE-2022-21608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21594" id="CVE-2022-21594" title="CVE-2022-21594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21617" id="CVE-2022-21617" title="CVE-2022-21617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21637" id="CVE-2022-21637" title="CVE-2022-21637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21604" id="CVE-2022-21604" title="CVE-2022-21604" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39410" id="CVE-2022-39410" title="CVE-2022-39410" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39408" id="CVE-2022-39408" title="CVE-2022-39408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21569" id="CVE-2022-21569" title="CVE-2022-21569" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21526" id="CVE-2022-21526" title="CVE-2022-21526" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21528" id="CVE-2022-21528" title="CVE-2022-21528" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21525" id="CVE-2022-21525" title="CVE-2022-21525" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21531" id="CVE-2022-21531" title="CVE-2022-21531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21537" id="CVE-2022-21537" title="CVE-2022-21537" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21538" id="CVE-2022-21538" title="CVE-2022-21538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21539" id="CVE-2022-21539" title="CVE-2022-21539" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21509" id="CVE-2022-21509" title="CVE-2022-21509" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21553" id="CVE-2022-21553" title="CVE-2022-21553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21529" id="CVE-2022-21529" title="CVE-2022-21529" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21534" id="CVE-2022-21534" title="CVE-2022-21534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21515" id="CVE-2022-21515" title="CVE-2022-21515" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21547" id="CVE-2022-21547" title="CVE-2022-21547" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21522" id="CVE-2022-21522" title="CVE-2022-21522" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21527" id="CVE-2022-21527" title="CVE-2022-21527" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21530" id="CVE-2022-21530" title="CVE-2022-21530" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21517" id="CVE-2022-21517" title="CVE-2022-21517" type="cve"></reference>
		</references>
		<description>CVE-2023-22068:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-38545:This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host name can be is 255 bytes.&#xA;If the host name is detected to be longer, curl switches to local name resolving and instead passes on the resolved address only. Due to this bug, the local variable that means &#34;let the host resolve the name&#34; could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long host name to the target buffer instead of copying just the resolved address there. The target buffer being a heap based buffer, and the host name coming from the URL that curl has been told to operate with.&#xA;CVE-2023-22079:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22084:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 5.7.43 and prior, 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22064:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22078:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22066:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22113:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2023-22026:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 5.7.42 and prior and  8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22015:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 5.7.42 and prior and  8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22032:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22059:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22070:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22115:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22028:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 5.7.43 and prior and  8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22104:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22114:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22097:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22110:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22065:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22112:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22092:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22111:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: UDF).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22103:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22058:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.33 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22046:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22038:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-22053:Vulnerability in the MySQL Server product of Oracle MySQL (component: Client programs).  Supported versions that are affected are 5.7.42 and prior and  8.0.33 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server and  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H).&#xA;CVE-2023-22008:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22057:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22005:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.33 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22054:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22033:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.33 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22048:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Pluggable Auth).  Supported versions that are affected are 8.0.33 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 3.1 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2023-22056:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.33 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-22007:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 5.7.41 and prior and  8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-0215:The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications.&#xA;The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash.&#xA;CVE-2022-43551:A vulnerability exists in curl &lt;7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) `.`. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.&#xA;CVE-2023-21946:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21963:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Connection Handling).  Supported versions that are affected are 5.7.40 and prior and  8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2023-21912:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 5.7.41 and prior and  8.0.30 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 7.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21945:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21933:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21935:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21982:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21955:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Partition).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21929:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2023-21966:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: JSON).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21913:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21980:Vulnerability in the MySQL Server product of Oracle MySQL (component: Client programs).  Supported versions that are affected are 5.7.41 and prior and  8.0.32 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of MySQL Server. CVSS 3.1 Base Score 7.1 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H).&#xA;CVE-2023-21947:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.32 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21919:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21972:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21962:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21917:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21977:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21940:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.32 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21911:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21976:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21953:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Partition).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21920:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-32221:When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent `POST` request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST.&#xA;CVE-2023-21836:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21871:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21865:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21872:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2023-21867:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21873:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21864:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21870:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21874:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2023-21868:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21863:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21869:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2023-21882:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-21881:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21883:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21887:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: GIS).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21880:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2023-21879:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21875:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption).  Supported versions that are affected are 8.0.31 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all MySQL Server accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.9 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H).&#xA;CVE-2023-21876:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-21877:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2023-21878:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21592:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption). Supported versions that are affected are 5.7.39 and prior and 8.0.29 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2022-21641:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21638:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21635:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all MySQL Server accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H).&#xA;CVE-2022-21611:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.30 and prior. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.1 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21625:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.30 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21599:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21632:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21633:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-39400:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21640:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21608:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 5.7.39 and prior and 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21594:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21617:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Connection Handling). Supported versions that are affected are 5.7.39 and prior and 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21637:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21604:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-39410:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-39408:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.30 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21569:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21526:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21528:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2022-21525:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21531:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21537:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21538:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption). Supported versions that are affected are 8.0.29 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 3.1 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2022-21539:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.29 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data as well as unauthorized read access to a subset of MySQL Server accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 5.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L).&#xA;CVE-2022-21509:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2022-21553:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21529:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21534:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21515:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Options). Supported versions that are affected are 5.7.38 and prior and 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21547:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Federated). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21522:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 8.0.29 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21527:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2022-21530:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2022-21517:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.29 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-libs-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-libs-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-config-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-config-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-common-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-common-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-errmsg-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-errmsg-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-server-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-server-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-devel-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-devel-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-test-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-test-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-help-8.0.35-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/mysql-help-8.0.35-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-libs-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-libs-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-config-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-config-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-common-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-common-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-errmsg-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-errmsg-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-server-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-server-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-devel-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-devel-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-test-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-test-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u1.fos23" version="8.0.35">
					<filename>mysql-help-8.0.35-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/mysql-help-8.0.35-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2352</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-1971" id="CVE-2020-1971" title="CVE-2020-1971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23840" id="CVE-2021-23840" title="CVE-2021-23840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23841" id="CVE-2021-23841" title="CVE-2021-23841" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3449" id="CVE-2021-3449" title="CVE-2021-3449" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3450" id="CVE-2021-3450" title="CVE-2021-3450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3711" id="CVE-2021-3711" title="CVE-2021-3711" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3712" id="CVE-2021-3712" title="CVE-2021-3712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4160" id="CVE-2021-4160" title="CVE-2021-4160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1292" id="CVE-2022-1292" title="CVE-2022-1292" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2068" id="CVE-2022-2068" title="CVE-2022-2068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2097" id="CVE-2022-2097" title="CVE-2022-2097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"></reference>
		</references>
		<description>CVE-2023-0464:A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints.  Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-2650:Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow. Applications that use OBJ_obj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service.&#xA;CVE-2020-1971:The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL&#39;s s_server, s_client and verify tools have support for the &#34;-crl_download&#34; option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL&#39;s parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. Fixed in OpenSSL 1.1.1i (Affected 1.1.1-1.1.1h). Fixed in OpenSSL 1.0.2x (Affected 1.0.2-1.0.2w).&#xA;CVE-2021-23840:Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).&#xA;CVE-2021-23841:The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).&#xA;CVE-2021-3449:An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).&#xA;CVE-2021-3450:The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a &#34;purpose&#34; has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named &#34;purpose&#34; values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j).&#xA;CVE-2021-3711:In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Typically an application will call this function twice. The first time, on entry, the &#34;out&#34; parameter can be NULL and, on exit, the &#34;outlen&#34; parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL value for the &#34;out&#34; parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to EVP_PKEY_decrypt() can be smaller than the actual size required by the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k).&#xA;CVE-2021-3712:ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL&#39;s own &#34;d2i&#34; functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the &#34;data&#34; and &#34;length&#34; fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the &#34;data&#34; field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).&#xA;CVE-2021-4160:There is a carry propagation bug in the MIPS32 and MIPS64 squaring procedure. Many EC algorithms are affected, including some of the TLS 1.3 default curves. Impact was not analyzed in detail, because the pre-requisites for attack are considered unlikely and include reusing private keys. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH private key among multiple clients, which is no longer an option since CVE-2016-0701. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.0. It was addressed in the releases of 1.1.1m and 3.0.1 on the 15th of December 2021. For the 1.0.2 release it is addressed in git commit 6fc1aaaf3 that is available to premium support customers only. It will be made available in 1.0.2zc when it is released. The issue only affects OpenSSL on MIPS platforms. Fixed in OpenSSL 3.0.1 (Affected 3.0.0). Fixed in OpenSSL 1.1.1m (Affected 1.1.1-1.1.1l). Fixed in OpenSSL 1.0.2zc-dev (Affected 1.0.2-1.0.2zb).&#xA;CVE-2022-0778:The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).&#xA;CVE-2022-1292:The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd).&#xA;CVE-2022-2068:In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze).&#xA;CVE-2022-2097:AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised implementation will not encrypt the entirety of the data under some circumstances. This could reveal sixteen bytes of data that was preexisting in the memory that wasn&#39;t written. In the special case of &#34;in place&#34; encryption, sixteen bytes of the plaintext would be revealed. Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected. Fixed in OpenSSL 3.0.5 (Affected 3.0.0-3.0.4). Fixed in OpenSSL 1.1.1q (Affected 1.1.1-1.1.1p).&#xA;CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data. If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack.&#xA;CVE-2023-0215:The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash.&#xA;CVE-2023-3817:Checking excessively long DH keys or parameters may be very slow. Applications that use the functions DH_check(), DH_check_ex() or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.&#xA;CVE-2023-5678:Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Applications that use the functions DH_generate_key() togenerate an X9.42 DH key may experience long delays.  Likewise, applicationsthat use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u4.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/openresty-openssl111-asan-1.1.1h-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u4.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/openresty-openssl111-asan-1.1.1h-2.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2353</id>
		<title>An update for optipng is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43907" id="CVE-2023-43907" title="CVE-2023-43907" type="cve"></reference>
		</references>
		<description>CVE-2023-43907:OptiPNG v0.7.7 was discovered to contain a global buffer overflow via the &#39;buffer&#39; variable at gifread.c.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="optipng" release="1.fos23" version="0.7.8">
					<filename>optipng-0.7.8-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/optipng-0.7.8-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="optipng" release="1.fos23" version="0.7.8">
					<filename>optipng-0.7.8-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/optipng-0.7.8-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2354</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47038" id="CVE-2023-47038" title="CVE-2023-47038" type="cve"></reference>
		</references>
		<description>CVE-2023-47038:A vulnerability was found in perl. This issue occurs when a crafted regular expression is compiled by perl, which can allow an attacker controlled byte buffer overflow in a heap allocated buffer.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="4" name="perl" release="10.u4.fos23" version="5.34.0">
					<filename>perl-5.34.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/perl-5.34.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-libs" release="10.u4.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/perl-libs-5.34.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-devel" release="10.u4.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/perl-devel-5.34.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="4" name="perl-help" release="10.u4.fos23" version="5.34.0">
					<filename>perl-help-5.34.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/perl-help-5.34.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl" release="10.u4.fos23" version="5.34.0">
					<filename>perl-5.34.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/perl-5.34.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-libs" release="10.u4.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/perl-libs-5.34.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-devel" release="10.u4.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/perl-devel-5.34.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2355</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36023" id="CVE-2020-36023" title="CVE-2020-36023" type="cve"></reference>
		</references>
		<description>CVE-2020-36023:An issue was discovered in freedesktop poppler version 20.12.1, allows remote attackers to cause a denial of service (DoS) via crafted .pdf file to FoFiType1C::cvtGlyph function.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="poppler" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-devel-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-glib-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-glib-devel-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-glib-doc-0.90.0-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-qt5-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-qt5-devel-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-cpp-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-cpp-devel-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-utils-0.90.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/poppler-help-0.90.0-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-devel-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-glib-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-glib-devel-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-qt5-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-qt5-devel-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-cpp-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-cpp-devel-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="7.u4.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/poppler-utils-0.90.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2356</id>
		<title>An update for python-cryptography is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49083" id="CVE-2023-49083" title="CVE-2023-49083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49083" id="CVE-2023-49083" title="CVE-2023-49083" type="cve"></reference>
		</references>
		<description>CVE-2023-49083:cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Calling `load_pem_pkcs7_certificates` or `load_der_pkcs7_certificates` could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability. This vulnerability has been patched in version 41.0.6.&#xA;CVE-2023-49083:cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Calling `load_pem_pkcs7_certificates` or `load_der_pkcs7_certificates` could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability. This vulnerability has been patched in version 41.0.6.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="python3-cryptography" release="6.u5.fos23" version="36.0.1">
					<filename>python3-cryptography-36.0.1-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/python3-cryptography-36.0.1-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-cryptography-help" release="6.u5.fos23" version="36.0.1">
					<filename>python-cryptography-help-36.0.1-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/python-cryptography-help-36.0.1-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-cryptography" release="6.u5.fos23" version="36.0.1">
					<filename>python3-cryptography-36.0.1-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/python3-cryptography-36.0.1-6.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2357</id>
		<title>An update for python-werkzeug is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46136" id="CVE-2023-46136" title="CVE-2023-46136" type="cve"></reference>
		</references>
		<description>CVE-2023-46136:Werkzeug is a comprehensive WSGI web application library. If an upload of a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. This vulnerability has been patched in version 3.0.1.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="0" name="python3-werkzeug" release="4.u3.fos23" version="2.0.3">
					<filename>python3-werkzeug-2.0.3-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/python3-werkzeug-2.0.3-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-werkzeug-help" release="4.u3.fos23" version="2.0.3">
					<filename>python-werkzeug-help-2.0.3-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/python-werkzeug-help-2.0.3-4.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2358</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1544" id="CVE-2023-1544" title="CVE-2023-1544" type="cve"></reference>
		</references>
		<description>CVE-2023-1544:A flaw was found in the QEMU implementation of VMWare&#39;s paravirtual RDMA device. This flaw allows a crafted guest driver to allocate and initialize a huge number of page tables to be used as a ring of descriptors for CQ and async events, potentially leading to an out-of-bounds read and crash of QEMU.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="10" name="qemu" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-guest-agent-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-86.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-help-6.2.0-86.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-img-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-block-rbd-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-block-ssh-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-block-iscsi-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-block-curl-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-hw-usb-host-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-seabios-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-system-aarch64-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-system-arm-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-system-x86_64-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-86.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qemu-system-riscv-6.2.0-86.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-guest-agent-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-img-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-block-rbd-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-block-ssh-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-block-iscsi-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-block-curl-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-hw-usb-host-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-system-aarch64-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-system-arm-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-system-x86_64-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="86.u12.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-86.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qemu-system-riscv-6.2.0-86.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2359</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43114" id="CVE-2023-43114" title="CVE-2023-43114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38197" id="CVE-2023-38197" title="CVE-2023-38197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"></reference>
		</references>
		<description>CVE-2023-43114:An issue was discovered in Qt before 5.15.16, 6.x before 6.2.10, and 6.3.x through 6.5.x before 6.5.3 on Windows. When using the GDI font engine, if a corrupted font is loaded via QFontDatabase::addApplicationFont{FromData], then it can cause the application to crash because of missing length checks.&#xA;CVE-2023-38197:An issue was discovered in Qt before 5.15.15, 6.x before 6.2.10, and 6.3.x through 6.5.x before 6.5.3. There are infinite loops in recursive entity expansion.&#xA;CVE-2023-37369:In Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.2, there can be an application crash in QXmlStreamReader via a crafted XML string that triggers a situation in which a prefix is greater than a length.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="1" name="qt" release="58.u7.fos23" version="4.8.7">
					<filename>qt-4.8.7-58.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt-4.8.7-58.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="qt-devel" release="58.u7.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-58.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt-devel-4.8.7-58.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt" release="58.u7.fos23" version="4.8.7">
					<filename>qt-4.8.7-58.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt-4.8.7-58.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt-devel" release="58.u7.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-58.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt-devel-4.8.7-58.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2360</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38197" id="CVE-2023-38197" title="CVE-2023-38197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43114" id="CVE-2023-43114" title="CVE-2023-43114" type="cve"></reference>
		</references>
		<description>CVE-2023-38197:An issue was discovered in Qt before 5.15.15, 6.x before 6.2.10, and 6.3.x through 6.5.x before 6.5.3. There are infinite loops in recursive entity expansion.&#xA;CVE-2023-43114:An issue was discovered in Qt before 5.15.16, 6.x before 6.2.10, and 6.3.x through 6.5.x before 6.5.3 on Windows. When using the GDI font engine, if a corrupted font is loaded via QFontDatabase::addApplicationFont{FromData], then it can cause the application to crash because of missing length checks.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-13.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-common-5.15.2-13.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-devel-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-private-devel-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-examples-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-static-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-mysql-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-odbc-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-postgresql-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-13.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/qt5-qtbase-gui-5.15.2-13.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-devel-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-private-devel-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-examples-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-static-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-mysql-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-odbc-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-postgresql-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="13.u6.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-13.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/qt5-qtbase-gui-5.15.2-13.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2361</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25155" id="CVE-2023-25155" title="CVE-2023-25155" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45145" id="CVE-2023-45145" title="CVE-2023-45145" type="cve"></reference>
		</references>
		<description>CVE-2023-25155:Redis is an in-memory database that persists on disk. Authenticated users issuing specially crafted `SRANDMEMBER`, `ZRANDMEMBER`, and `HRANDFIELD` commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. This problem affects all Redis versions. Patches were released in Redis version(s) 6.0.18, 6.2.11 and 7.0.9.&#xA;CVE-2023-45145:Redis is an in-memory database that persists on disk. On startup, Redis begins listening on a Unix socket before adjusting its permissions to the user-provided configuration. If a permissive umask(2) is used, this creates a race condition that enables, during a short period of time, another process to establish an otherwise unauthorized connection. This problem has existed since Redis 2.6.0-RC1. This issue has been addressed in Redis versions 7.2.2, 7.0.14 and 6.2.14. Users are advised to upgrade. For users unable to upgrade, it is possible to work around the problem by disabling Unix sockets, starting Redis with a restrictive umask, or storing the Unix socket file in a protected directory.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u6.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/redis5-5.0.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u6.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/redis5-devel-5.0.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u6.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/redis5-doc-5.0.7-6.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u6.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/redis5-5.0.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u6.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/redis5-devel-5.0.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2362</id>
		<title>An update for scipy is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29824" id="CVE-2023-29824" title="CVE-2023-29824" type="cve"></reference>
		</references>
		<description>CVE-2023-29824:A use-after-free issue was discovered in Py_FindObjects() function in SciPy versions prior to 1.8.0. NOTE: the vendor and discoverer indicate that this is not a security issue.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="python3-scipy" release="2.u2.fos23" version="1.6.2">
					<filename>python3-scipy-1.6.2-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/python3-scipy-1.6.2-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-scipy" release="2.u2.fos23" version="1.6.2">
					<filename>python3-scipy-1.6.2-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/python3-scipy-1.6.2-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2363</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
		</references>
		<description>CVE-2023-0465:Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-2650:Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow. Applications that use OBJ_obj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service.&#xA;CVE-2023-3446:Checking excessively long DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_check(), DH_check_ex() or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="0" name="shim" release="12.u9.fos23" version="15.6">
					<filename>shim-15.6-12.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/shim-15.6-12.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="12.u9.fos23" version="15.6">
					<filename>shim-15.6-12.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/shim-15.6-12.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2364</id>
		<title>An update for springframework is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-11039" id="CVE-2018-11039" title="CVE-2018-11039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22950" id="CVE-2022-22950" title="CVE-2022-22950" type="cve"></reference>
		</references>
		<description>CVE-2018-11039:Spring Framework (versions 5.0.x prior to 5.0.7, versions 4.3.x prior to 4.3.18, and older unsupported versions) allow web applications to change the HTTP request method to any HTTP method (including TRACE) using the HiddenHttpMethodFilter in Spring MVC. If an application has a pre-existing XSS vulnerability, a malicious user (or attacker) can use this filter to escalate to an XST (Cross Site Tracing) attack.&#xA;CVE-2022-22950:n Spring Framework versions 5.3.0 - 5.3.16 and older unsupported versions, it is possible for a user to provide a specially crafted SpEL expression that may cause a denial of service condition.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="0" name="springframework" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-help" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-help-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-help-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-aop" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-aop-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-aop-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-beans" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-beans-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-beans-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-context" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-context-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-context-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-expression" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-expression-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-expression-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-instrument" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-instrument-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-instrument-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-jdbc" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-jdbc-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-jdbc-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-jms" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-jms-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-jms-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-orm" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-orm-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-orm-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-orm-hibernate4" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-orm-hibernate4-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-orm-hibernate4-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-oxm" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-oxm-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-oxm-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-tx" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-tx-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-tx-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="springframework-web" release="12.u2.fos23" version="3.2.18">
					<filename>springframework-web-3.2.18-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/springframework-web-3.2.18-12.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2365</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49285" id="CVE-2023-49285" title="CVE-2023-49285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49286" id="CVE-2023-49286" title="CVE-2023-49286" type="cve"></reference>
		</references>
		<description>CVE-2023-49285:Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to a Buffer Overread bug Squid is vulnerable to a Denial of Service attack against Squid HTTP Message processing. This bug is fixed by Squid version 6.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-49286:Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to an Incorrect Check of Function Return Value bug Squid is vulnerable to a Denial of Service attack against its Helper process management. This bug is fixed by Squid version 6.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="7" name="squid" release="21.u2.fos23" version="4.9">
					<filename>squid-4.9-21.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/squid-4.9-21.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="21.u2.fos23" version="4.9">
					<filename>squid-4.9-21.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/squid-4.9-21.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2366</id>
		<title>An update for tar is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39840" id="CVE-2023-39804" title="CVE-2023-39804" type="cve"></reference>
		</references>
		<description>CVE-2023-39804:A stack overflow vulnerability exists in GNU Tar up to including v1.34. The bug exists in the function xattr_decoder() in xheader.c, where alloca() is used and it may overflow the stack if a sufficiently long xattr key is used. The vulnerability can be triggered when extracting a tar/pax archive that contains such a long xattr key.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="2" name="tar" release="5.u2.fos23" version="1.34">
					<filename>tar-1.34-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/tar-1.34-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="tar-help" release="5.u2.fos23" version="1.34">
					<filename>tar-help-1.34-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/tar-help-1.34-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="tar" release="5.u2.fos23" version="1.34">
					<filename>tar-1.34-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/tar-1.34-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2367</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46589" id="CVE-2023-46589" title="CVE-2023-46589" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42795" id="CVE-2023-42795" title="CVE-2023-42795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
		</references>
		<description>CVE-2023-46589:Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82 and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single  request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.&#xA;CVE-2023-42795:Incomplete Cleanup vulnerability in Apache Tomcat.When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could  cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next.&#xA;CVE-2023-44487:The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="1" name="tomcat" release="32.u11.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-32.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/tomcat-9.0.10-32.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="32.u11.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-32.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/tomcat-jsvc-9.0.10-32.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="32.u11.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-32.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/tomcat-help-9.0.10-32.u11.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2368</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48706" id="CVE-2023-48706" title="CVE-2023-48706" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48231" id="CVE-2023-48231" title="CVE-2023-48231" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48233" id="CVE-2023-48233" title="CVE-2023-48233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48234" id="CVE-2023-48234" title="CVE-2023-48234" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48235" id="CVE-2023-48235" title="CVE-2023-48235" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48236" id="CVE-2023-48236" title="CVE-2023-48236" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48237" id="CVE-2023-48237" title="CVE-2023-48237" type="cve"></reference>
		</references>
		<description>CVE-2023-48706:Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.&#xA;CVE-2023-48231:Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-48233:Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-48234:Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-48235:Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an&#xA;overflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-48236:Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values larger&#xA;than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2023-48237:Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="23.u13.fos23" version="9.0">
					<filename>vim-common-9.0-23.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/vim-common-9.0-23.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="23.u13.fos23" version="9.0">
					<filename>vim-minimal-9.0-23.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/vim-minimal-9.0-23.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="23.u13.fos23" version="9.0">
					<filename>vim-enhanced-9.0-23.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/vim-enhanced-9.0-23.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="23.u13.fos23" version="9.0">
					<filename>vim-filesystem-9.0-23.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/vim-filesystem-9.0-23.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="23.u13.fos23" version="9.0">
					<filename>vim-X11-9.0-23.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/vim-X11-9.0-23.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="23.u13.fos23" version="9.0">
					<filename>vim-common-9.0-23.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/vim-common-9.0-23.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="23.u13.fos23" version="9.0">
					<filename>vim-minimal-9.0-23.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/vim-minimal-9.0-23.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="23.u13.fos23" version="9.0">
					<filename>vim-enhanced-9.0-23.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/vim-enhanced-9.0-23.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="23.u13.fos23" version="9.0">
					<filename>vim-X11-9.0-23.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/vim-X11-9.0-23.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2023-2369</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2023-12-30"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6175" id="CVE-2023-6175" title="CVE-2023-6175" type="cve"></reference>
		</references>
		<description>CVE-2023-6175:A heap-based buffer overflow was found in Wireshark&#39;s NetScreen file parser. This issue may allow local arbitrary code execution via a crafted capture file.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="5.u8.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-5.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/wireshark-3.6.14-5.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="5.u8.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-5.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/wireshark-devel-3.6.14-5.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="5.u8.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-5.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4/wireshark-help-3.6.14-5.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="5.u8.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-5.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/wireshark-3.6.14-5.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="5.u8.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-5.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/wireshark-devel-3.6.14-5.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="5.u8.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-5.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/wireshark-help-3.6.14-5.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2001</id>
		<title>An update for bluez is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45866" id="CVE-2023-45866" title="CVE-2023-45866" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50229" id="CVE-2023-50229" title="CVE-2023-50229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50230" id="CVE-2023-50230" title="CVE-2023-50230" type="cve"></reference>
		</references>
		<description>CVE-2023-45866:Bluetooth HID Hosts in BlueZ may permit an unauthenticated Peripheral role HID Device to initiate and establish an encrypted connection, and accept HID keyboard reports, potentially permitting injection of HID messages when no user interaction has occurred in the Central role to authorize such access. An example affected package is bluez 5.64-0ubuntu1 in Ubuntu 22.04LTS. NOTE: in some cases, a CVE-2020-0556 mitigation would have already addressed this Bluetooth HID Hosts issue.&#xA;CVE-2023-50229:VUL-0: CVE-2023-50229: bluez: BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code Execution Vulnerability.&#xA;CVE-2023-50230:VUL-0: CVE-2023-50230: bluez: BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code Execution Vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="bluez" release="19.u3.fos23" version="5.54">
					<filename>bluez-5.54-19.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/bluez-5.54-19.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bluez-libs" release="19.u3.fos23" version="5.54">
					<filename>bluez-libs-5.54-19.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/bluez-libs-5.54-19.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bluez-devel" release="19.u3.fos23" version="5.54">
					<filename>bluez-devel-5.54-19.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/bluez-devel-5.54-19.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="bluez-help" release="19.u3.fos23" version="5.54">
					<filename>bluez-help-5.54-19.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/bluez-help-5.54-19.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bluez-cups" release="19.u3.fos23" version="5.54">
					<filename>bluez-cups-5.54-19.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/bluez-cups-5.54-19.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez" release="19.u3.fos23" version="5.54">
					<filename>bluez-5.54-19.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/bluez-5.54-19.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez-libs" release="19.u3.fos23" version="5.54">
					<filename>bluez-libs-5.54-19.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/bluez-libs-5.54-19.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez-devel" release="19.u3.fos23" version="5.54">
					<filename>bluez-devel-5.54-19.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/bluez-devel-5.54-19.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bluez-cups" release="19.u3.fos23" version="5.54">
					<filename>bluez-cups-5.54-19.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/bluez-cups-5.54-19.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2002</id>
		<title>An update for cjson is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50471" id="CVE-2023-50471" title="CVE-2023-50471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50472" id="CVE-2023-50472" title="CVE-2023-50472" type="cve"></reference>
		</references>
		<description>CVE-2023-50471:cJSON v1.7.16 was discovered to contain a segmentation violation via the function cJSON_InsertItemInArray at cJSON.c.&#xA;CVE-2023-50472:cJSON v1.7.16 was discovered to contain a segmentation violation via the function cJSON_SetValuestring at cJSON.c.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="cjson" release="2.u1.fos23" version="1.7.15">
					<filename>cjson-1.7.15-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/cjson-1.7.15-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cjson-devel" release="2.u1.fos23" version="1.7.15">
					<filename>cjson-devel-1.7.15-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/cjson-devel-1.7.15-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson" release="2.u1.fos23" version="1.7.15">
					<filename>cjson-1.7.15-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/cjson-1.7.15-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson-devel" release="2.u1.fos23" version="1.7.15">
					<filename>cjson-devel-1.7.15-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/cjson-devel-1.7.15-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2003</id>
		<title>An update for erlang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37026" id="CVE-2022-37026" title="CVE-2022-37026" type="cve"></reference>
		</references>
		<description>CVE-2022-37026:In Erlang/OTP before 23.3.4.15, 24.x before 24.3.4.2, and 25.x before 25.0.2, there is a Client Authentication Bypass in certain client-certification situations for SSL, TLS, and DTLS.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="erlang" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-asn1" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-asn1-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-common_test" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-common_test-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-compiler" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-compiler-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-crypto" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-crypto-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-debugger" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-debugger-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-dialyzer" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-dialyzer-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-diameter" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-diameter-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-edoc" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-edoc-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eldap" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-eldap-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_docgen" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-erl_docgen-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_interface" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-erl_interface-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erts" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-erts-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-et" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-et-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eunit" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-eunit-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-examples" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-examples-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ftp" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-ftp-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-hipe" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-hipe-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-inets" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-inets-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-jinterface" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-jinterface-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-kernel" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-kernel-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-megaco" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-megaco-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-mnesia" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-mnesia-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-observer" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-observer-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-odbc" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-odbc-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-os_mon" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-os_mon-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-parsetools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-parsetools-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-public_key" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-public_key-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-reltool" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-reltool-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-runtime_tools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-runtime_tools-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-sasl" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-sasl-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-snmp" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-snmp-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssh" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-ssh-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssl" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-ssl-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-stdlib" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-stdlib-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-syntax_tools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-syntax_tools-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tftp" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-tftp-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-tools-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-wx" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-wx-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-xmerl" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/erlang-xmerl-23.3.4.9-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-asn1" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-asn1-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-common_test" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-common_test-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-compiler" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-compiler-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-crypto" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-crypto-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-debugger" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-debugger-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-dialyzer" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-dialyzer-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-diameter" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-diameter-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-edoc" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-edoc-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eldap" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-eldap-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_docgen" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-erl_docgen-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_interface" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-erl_interface-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erts" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-erts-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-et" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-et-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eunit" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-eunit-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-examples" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-examples-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ftp" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-ftp-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-hipe" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-hipe-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-inets" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-inets-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-jinterface" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-jinterface-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-kernel" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-kernel-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-megaco" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-megaco-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-mnesia" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-mnesia-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-observer" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-observer-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-odbc" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-odbc-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-os_mon" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-os_mon-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-parsetools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-parsetools-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-public_key" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-public_key-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-reltool" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-reltool-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-runtime_tools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-runtime_tools-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-sasl" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-sasl-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-snmp" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-snmp-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssh" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-ssh-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssl" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-ssl-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-stdlib" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-stdlib-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-syntax_tools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-syntax_tools-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tftp" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-tftp-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tools" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-tools-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-wx" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-wx-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-xmerl" release="3.u1.fos23" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/erlang-xmerl-23.3.4.9-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2004</id>
		<title>An update for espeak-ng is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49990" id="CVE-2023-49990" title="CVE-2023-49990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49991" id="CVE-2023-49991" title="CVE-2023-49991" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49992" id="CVE-2023-49992" title="CVE-2023-49992" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49993" id="CVE-2023-49993" title="CVE-2023-49993" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49994" id="CVE-2023-49994" title="CVE-2023-49994" type="cve"></reference>
		</references>
		<description>CVE-2023-49990:Espeak-ng 1.52-dev was discovered to contain a buffer-overflow via the function SetUpPhonemeTable at synthdata.c.&#xA;CVE-2023-49991:Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Underflow via the function CountVowelPosition at synthdata.c.&#xA;CVE-2023-49992:Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Overflow via the function RemoveEnding at dictionary.c.&#xA;CVE-2023-49993:Espeak-ng 1.52-dev was discovered to contain a Buffer Overflow via the function ReadClause at readclause.c.&#xA;CVE-2023-49994:Espeak-ng 1.52-dev was discovered to contain a Floating Point Exception via the function PeaksToHarmspect at wavegen.c.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="espeak-ng" release="2.fos23" version="1.51">
					<filename>espeak-ng-1.51-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/espeak-ng-1.51-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="espeak-ng-devel" release="2.fos23" version="1.51">
					<filename>espeak-ng-devel-1.51-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/espeak-ng-devel-1.51-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="espeak-ng-help" release="2.fos23" version="1.51">
					<filename>espeak-ng-help-1.51-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/espeak-ng-help-1.51-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="espeak-ng" release="2.fos23" version="1.51">
					<filename>espeak-ng-1.51-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/espeak-ng-1.51-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="espeak-ng-devel" release="2.fos23" version="1.51">
					<filename>espeak-ng-devel-1.51-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/espeak-ng-devel-1.51-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2005</id>
		<title>An update for gstreamer1-plugins-bad-free is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44446" id="CVE-2023-44446" title="CVE-2023-44446" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37329" id="CVE-2023-37329" title="CVE-2023-37329" type="cve"></reference>
		</references>
		<description>CVE-2023-44446:A use-after-free flaw was found in the MXF demuxer in GStreamer when handling certain MXF video files. This issue could allow a malicious third party to trigger a crash in the application and may allow code execution.&#xA;CVE-2023-37329:Heap-based buffer overflow in the PGS blu-ray subtitle decoder when handling certain files in GStreamer versions before 1.22.4 / 1.20.7. It is possible for a malicious third party to trigger a crash in the application, and possibly also effect code execution through heap manipulation.https://gstreamer.freedesktop.org/security/sa-2023-0003.html</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-bad-free" release="9.u3.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-1.16.2-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/gstreamer1-plugins-bad-free-1.16.2-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-bad-free-devel" release="9.u3.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-devel-1.16.2-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/gstreamer1-plugins-bad-free-devel-1.16.2-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-bad-free" release="9.u3.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-1.16.2-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/gstreamer1-plugins-bad-free-1.16.2-9.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-bad-free-devel" release="9.u3.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-bad-free-devel-1.16.2-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/gstreamer1-plugins-bad-free-devel-1.16.2-9.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2006</id>
		<title>An update for libgit2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22742" id="CVE-2023-22742" title="CVE-2023-22742" type="cve"></reference>
		</references>
		<description>CVE-2023-22742:libgit2 is a cross-platform, linkable library implementation of Git. When using an SSH remote with the optional libssh2 backend, libgit2 does not perform certificate checking by default. Prior versions of libgit2 require the caller to set the `certificate_check` field of libgit2&#39;s `git_remote_callbacks` structure - if a certificate check callback is not set, libgit2 does not perform any certificate checking. This means that by default - without configuring a certificate check callback, clients will not perform validation on the server SSH keys and may be subject to a man-in-the-middle attack. Users are encouraged to upgrade to v1.4.5 or v1.5.1. Users unable to upgrade should ensure that all relevant certificates are manually checked.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="libgit2" release="2.u1.fos23" version="1.3.2">
					<filename>libgit2-1.3.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libgit2-1.3.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgit2-devel" release="2.u1.fos23" version="1.3.2">
					<filename>libgit2-devel-1.3.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libgit2-devel-1.3.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgit2" release="2.u1.fos23" version="1.3.2">
					<filename>libgit2-1.3.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libgit2-1.3.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgit2-devel" release="2.u1.fos23" version="1.3.2">
					<filename>libgit2-devel-1.3.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libgit2-devel-1.3.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2007</id>
		<title>An update for libsass is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26592" id="CVE-2022-26592" title="CVE-2022-26592" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43358" id="CVE-2022-43358" title="CVE-2022-43358" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43357" id="CVE-2022-43357" title="CVE-2022-43357" type="cve"></reference>
		</references>
		<description>CVE-2022-26592:Stack Overflow vulnerability in libsass 3.6.5 via the CompoundSelector::has_real_parent_ref function.&#xA;CVE-2022-43358:Stack overflow vulnerability in ast_selectors.cpp: in function Sass::ComplexSelector::has_placeholder in libsass:3.6.5-8-g210218, which can be exploited by attackers to cause a denial of service (DoS).&#xA;CVE-2022-43357:Stack overflow vulnerability in ast_selectors.cpp in function Sass::CompoundSelector::has_real_parent_ref in libsass:3.6.5-8-g210218, which can be exploited by attackers to causea denial of service (DoS). Also affects the command line driver for libsass, sassc 3.6.2.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="libsass" release="2.u1.fos23" version="3.6.4">
					<filename>libsass-3.6.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libsass-3.6.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsass-devel" release="2.u1.fos23" version="3.6.4">
					<filename>libsass-devel-3.6.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libsass-devel-3.6.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsass" release="2.u1.fos23" version="3.6.4">
					<filename>libsass-3.6.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libsass-3.6.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsass-devel" release="2.u1.fos23" version="3.6.4">
					<filename>libsass-devel-3.6.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libsass-devel-3.6.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2008</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6004" id="CVE-2023-6004" title="CVE-2023-6004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6918" id="CVE-2023-6918" title="CVE-2023-6918" type="cve"></reference>
		</references>
		<description>CVE-2023-6004:A flaw was found in libssh. By utilizing the ProxyCommand or ProxyJump feature, users can exploit unchecked hostname syntax on the client. This issue may allow an attacker to inject malicious code into the command of the features mentioned through the hostname parameter.&#xA;CVE-2023-6918:A flaw was found in the libssh implements abstract layer for message digest (MD) operations implemented by different supported crypto backends. The return values from these were not properly checked, which could cause low-memory situations failures, NULL dereferences, crashes, or usage of the uninitialized memory as an input for the KDF. In this case, non-matching keys will result in decryption/integrity failures, terminating the connection.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="libssh" release="8.u3.fos23" version="0.9.6">
					<filename>libssh-0.9.6-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libssh-0.9.6-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="8.u3.fos23" version="0.9.6">
					<filename>libssh-devel-0.9.6-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libssh-devel-0.9.6-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="8.u3.fos23" version="0.9.6">
					<filename>libssh-help-0.9.6-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libssh-help-0.9.6-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="8.u3.fos23" version="0.9.6">
					<filename>libssh-0.9.6-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libssh-0.9.6-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="8.u3.fos23" version="0.9.6">
					<filename>libssh-devel-0.9.6-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libssh-devel-0.9.6-8.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2009</id>
		<title>An update for logback is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6378" id="CVE-2023-6378" title="CVE-2023-6378" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6481" id="CVE-2023-6481" title="CVE-2023-6481" type="cve"></reference>
		</references>
		<description>CVE-2023-6378:A serialization vulnerability in logback receiver component part of &#xA;logback version 1.4.11 allows an attacker to mount a Denial-Of-Service &#xA;attack by sending poisoned data.&#xA;CVE-2023-6481:A serialization vulnerability in logback receiver component part of &#xA;logback version 1.4.13, 1.3.13 and 1.2.12 allows an attacker to mount a Denial-Of-Service &#xA;attack by sending poisoned data.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="noarch" epoch="0" name="logback" release="3.u1.fos23" version="1.2.8">
					<filename>logback-1.2.8-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/logback-1.2.8-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="logback-help" release="3.u1.fos23" version="1.2.8">
					<filename>logback-help-1.2.8-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/logback-help-1.2.8-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="logback-access" release="3.u1.fos23" version="1.2.8">
					<filename>logback-access-1.2.8-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/logback-access-1.2.8-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="logback-examples" release="3.u1.fos23" version="1.2.8">
					<filename>logback-examples-1.2.8-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/logback-examples-1.2.8-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2010</id>
		<title>An update for sqlite is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7104" id="CVE-2023-7104" title="CVE-2023-7104" type="cve"></reference>
		</references>
		<description>CVE-2023-7104:A vulnerability was found in SQLite SQLite3 up to 3.43.0 and classified as critical. This issue affects the function sessionReadRecord of the file ext/session/sqlite3session.c of the component make alltest Handler. The manipulation leads to heap-based buffer overflow. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-248999.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="sqlite" release="7.u4.fos23" version="3.37.2">
					<filename>sqlite-3.37.2-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/sqlite-3.37.2-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sqlite-devel" release="7.u4.fos23" version="3.37.2">
					<filename>sqlite-devel-3.37.2-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/sqlite-devel-3.37.2-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sqlite-help" release="7.u4.fos23" version="3.37.2">
					<filename>sqlite-help-3.37.2-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/sqlite-help-3.37.2-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite" release="7.u4.fos23" version="3.37.2">
					<filename>sqlite-3.37.2-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/sqlite-3.37.2-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite-devel" release="7.u4.fos23" version="3.37.2">
					<filename>sqlite-devel-3.37.2-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/sqlite-devel-3.37.2-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2011</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50269" id="CVE-2023-50269" title="CVE-2023-50269" type="cve"></reference>
		</references>
		<description>CVE-2023-50269:Squid is a caching proxy for the Web. Due to an Uncontrolled Recursion bug in versions 2.6 through 2.7.STABLE9, versions 3.1 through 5.9, and versions 6.0.1 through 6.5, Squid may be vulnerable to a Denial of Service attack against HTTP Request parsing. This problem allows a remote client to perform Denial of Service attack by sending a large X-Forwarded-For header when the follow_x_forwarded_for feature is configured. This bug is fixed by Squid version 6.6. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="7" name="squid" release="22.u3.fos23" version="4.9">
					<filename>squid-4.9-22.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/squid-4.9-22.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="22.u3.fos23" version="4.9">
					<filename>squid-4.9-22.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/squid-4.9-22.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2012</id>
		<title>An update for strongswan is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41913" id="CVE-2023-41913" title="CVE-2023-41913" type="cve"></reference>
		</references>
		<description>CVE-2023-41913:strongSwan before 5.9.12 has a buffer overflow and possible unauthenticated remote code execution via a DH public value that exceeds the internal buffer in charon-tkm&#39;s DH proxy. The earliest affected version is 5.3.0. An attack can occur via a crafted IKE_SA_INIT message.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="strongswan" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-5.9.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/strongswan-5.9.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="strongswan-libipsec" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-libipsec-5.9.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/strongswan-libipsec-5.9.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="strongswan-charon-nm" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-charon-nm-5.9.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/strongswan-charon-nm-5.9.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="strongswan-sqlite" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-sqlite-5.9.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/strongswan-sqlite-5.9.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="strongswan-tnc-imcvs" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-tnc-imcvs-5.9.7-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/strongswan-tnc-imcvs-5.9.7-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="strongswan" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-5.9.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/strongswan-5.9.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="strongswan-libipsec" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-libipsec-5.9.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/strongswan-libipsec-5.9.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="strongswan-charon-nm" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-charon-nm-5.9.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/strongswan-charon-nm-5.9.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="strongswan-sqlite" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-sqlite-5.9.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/strongswan-sqlite-5.9.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="strongswan-tnc-imcvs" release="5.u2.fos23" version="5.9.7">
					<filename>strongswan-tnc-imcvs-5.9.7-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/strongswan-tnc-imcvs-5.9.7-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2013</id>
		<title>An update for sudo is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42465" id="CVE-2023-42465" title="CVE-2023-42465" type="cve"></reference>
		</references>
		<description>CVE-2023-42465:Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="sudo" release="15.u8.fos23" version="1.9.8p2">
					<filename>sudo-1.9.8p2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/sudo-1.9.8p2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sudo-devel" release="15.u8.fos23" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/sudo-devel-1.9.8p2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sudo-help" release="15.u8.fos23" version="1.9.8p2">
					<filename>sudo-help-1.9.8p2-15.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/sudo-help-1.9.8p2-15.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo" release="15.u8.fos23" version="1.9.8p2">
					<filename>sudo-1.9.8p2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/sudo-1.9.8p2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo-devel" release="15.u8.fos23" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/sudo-devel-1.9.8p2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2014</id>
		<title>An update for systemd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7008" id="CVE-2023-7008" title="CVE-2023-7008" type="cve"></reference>
		</references>
		<description>CVE-2023-7008:A vulnerability was found in systemd-resolved. This issue may allow systemd-resolved to accept records of DNSSEC-signed domains even when they have no signature, allowing man-in-the-middles (or the upstream DNS resolver) to manipulate records.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="systemd" release="63.u16.fos23" version="249">
					<filename>systemd-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-devel" release="63.u16.fos23" version="249">
					<filename>systemd-devel-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-devel-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-libs" release="63.u16.fos23" version="249">
					<filename>systemd-libs-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-libs-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-udev" release="63.u16.fos23" version="249">
					<filename>systemd-udev-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-udev-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-container" release="63.u16.fos23" version="249">
					<filename>systemd-container-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-container-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-resolved" release="63.u16.fos23" version="249">
					<filename>systemd-resolved-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-resolved-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-nspawn" release="63.u16.fos23" version="249">
					<filename>systemd-nspawn-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-nspawn-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-networkd" release="63.u16.fos23" version="249">
					<filename>systemd-networkd-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-networkd-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-timesyncd" release="63.u16.fos23" version="249">
					<filename>systemd-timesyncd-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-timesyncd-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-pam" release="63.u16.fos23" version="249">
					<filename>systemd-pam-249-63.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-pam-249-63.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="systemd-help" release="63.u16.fos23" version="249">
					<filename>systemd-help-249-63.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/systemd-help-249-63.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="63.u16.fos23" version="249">
					<filename>systemd-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-devel" release="63.u16.fos23" version="249">
					<filename>systemd-devel-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-devel-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-libs" release="63.u16.fos23" version="249">
					<filename>systemd-libs-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-libs-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-udev" release="63.u16.fos23" version="249">
					<filename>systemd-udev-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-udev-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-container" release="63.u16.fos23" version="249">
					<filename>systemd-container-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-container-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-resolved" release="63.u16.fos23" version="249">
					<filename>systemd-resolved-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-resolved-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-nspawn" release="63.u16.fos23" version="249">
					<filename>systemd-nspawn-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-nspawn-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-networkd" release="63.u16.fos23" version="249">
					<filename>systemd-networkd-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-networkd-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-timesyncd" release="63.u16.fos23" version="249">
					<filename>systemd-timesyncd-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-timesyncd-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-pam" release="63.u16.fos23" version="249">
					<filename>systemd-pam-249-63.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/systemd-pam-249-63.u16.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2015</id>
		<title>An update for testng is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4065" id="CVE-2022-4065" title="CVE-2022-4065" type="cve"></reference>
		</references>
		<description>CVE-2022-4065:A vulnerability was found in cbeust testng 7.5.0/7.6.0/7.6.1/7.7.0. It has been declared as critical. Affected by this vulnerability is the function testngXmlExistsInJar of the file testng-core/src/main/java/org/testng/JarFileUtils.java of the component XML File Parser. The manipulation leads to path traversal. The attack can be launched remotely. Upgrading to version 7.5.1 and 7.7.1 is able to address this issue. The patch is named 9150736cd2c123a6a3b60e6193630859f9f0422b. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-214027.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="noarch" epoch="0" name="testng" release="7.u1.fos23" version="6.14.3">
					<filename>testng-6.14.3-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/testng-6.14.3-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="testng-javadoc" release="7.u1.fos23" version="6.14.3">
					<filename>testng-javadoc-6.14.3-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/testng-javadoc-6.14.3-7.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2016</id>
		<title>An update for tidy is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33391" id="CVE-2021-33391" title="CVE-2021-33391" type="cve"></reference>
		</references>
		<description>CVE-2021-33391:An issue in HTACG HTML Tidy v5.7.28 allows attacker to execute arbitrary code via the -g option of the CleanNode() function in gdoc.c.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="tidy" release="2.u1.fos23" version="5.7.28">
					<filename>tidy-5.7.28-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/tidy-5.7.28-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtidy" release="2.u1.fos23" version="5.7.28">
					<filename>libtidy-5.7.28-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libtidy-5.7.28-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtidy-devel" release="2.u1.fos23" version="5.7.28">
					<filename>libtidy-devel-5.7.28-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/libtidy-devel-5.7.28-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tidy-help" release="2.u1.fos23" version="5.7.28">
					<filename>tidy-help-5.7.28-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/tidy-help-5.7.28-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tidy" release="2.u1.fos23" version="5.7.28">
					<filename>tidy-5.7.28-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/tidy-5.7.28-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtidy" release="2.u1.fos23" version="5.7.28">
					<filename>libtidy-5.7.28-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libtidy-5.7.28-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtidy-devel" release="2.u1.fos23" version="5.7.28">
					<filename>libtidy-devel-5.7.28-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/libtidy-devel-5.7.28-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2017</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6478" id="CVE-2023-6478" title="CVE-2023-6478" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6377" id="CVE-2023-6377" title="CVE-2023-6377" type="cve"></reference>
		</references>
		<description>CVE-2023-6478:A flaw was found in xorg-server. A specially crafted request to RRChangeProviderProperty or RRChangeOutputProperty can trigger an integer overflow which may lead to a disclosure of sensitive information.&#xA;CVE-2023-6377:A flaw was found in xorg-server. Querying or changing XKB button actions such as moving from a touchpad to a mouse can result in out-of-bounds memory reads and writes. This may allow local privilege escalation or possible remote code execution in cases where X11 forwarding is involved.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-common-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-Xnest-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-Xdmx-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-Xvfb-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-Xephyr-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-devel-1.20.11-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-24.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-help-1.20.11-24.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-24.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/xorg-x11-server-source-1.20.11-24.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-common-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-Xnest-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-Xdmx-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-Xvfb-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-Xephyr-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="24.u11.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/xorg-x11-server-devel-1.20.11-24.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2018</id>
		<title>An update for yasm is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-01-31"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31975" id="CVE-2023-31975" title="CVE-2023-31975" type="cve"></reference>
		</references>
		<description>CVE-2023-31975:yasm v1.3.0 was discovered to contain a memory leak via the function yasm_intnum_copy at /libyasm/intnum.c.</description>
		<pkglist>
			<collection>
				<name>23.0.4.2</name>
				<package arch="x86_64" epoch="0" name="yasm" release="12.u3.fos23" version="1.3.0">
					<filename>yasm-1.3.0-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.2/yasm-1.3.0-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yasm" release="12.u3.fos23" version="1.3.0">
					<filename>yasm-1.3.0-12.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.2/yasm-1.3.0-12.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2019</id>
		<title>An update for ansible is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0690" id="CVE-2024-0690" title="CVE-2024-0690" type="cve"></reference>
		</references>
		<description>CVE-2024-0690:An information disclosure flaw was found in ansible-core due to a failure to respect the ANSIBLE_NO_LOG configuration in some scenarios. It was discovered that information is still included in the output in certain tasks, such as loop items. Depending on the task, this issue may include sensitive information, such as decrypted secret values.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="0" name="ansible" release="4.u4.fos23" version="2.9.27">
					<filename>ansible-2.9.27-4.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ansible-2.9.27-4.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ansible-help" release="4.u4.fos23" version="2.9.27">
					<filename>ansible-help-2.9.27-4.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ansible-help-2.9.27-4.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2020</id>
		<title>An update for apache-sshd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35887" id="CVE-2023-35887" title="CVE-2023-35887" type="cve"></reference>
		</references>
		<description>CVE-2023-35887:Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Software Foundation Apache MINA.&#xA;In SFTP servers implemented using Apache MINA SSHD that use a RootedFileSystem, logged users may be able to discover &#34;exists/does not exist&#34; information about items outside the rooted tree via paths including parent navigation (&#34;..&#34;) beyond the root, or involving symlinks.&#xA;This issue affects Apache MINA: from 1.0 before 2.10. Users are recommended to upgrade to 2.10</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="1" name="apache-sshd" release="2.u1.fos23" version="2.9.2">
					<filename>apache-sshd-2.9.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/apache-sshd-2.9.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="apache-sshd-javadoc" release="2.u1.fos23" version="2.9.2">
					<filename>apache-sshd-javadoc-2.9.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/apache-sshd-javadoc-2.9.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2021</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22211" id="CVE-2024-22211" title="CVE-2024-22211" type="cve"></reference>
		</references>
		<description>CVE-2024-22211:FreeRDP is a set of free and open source remote desktop protocol library and clients. In affected versions an integer overflow in `freerdp_bitmap_planar_context_reset` leads to heap-buffer overflow. This affects FreeRDP based clients. FreeRDP based server implementations and proxy are not affected. A malicious server could prepare a `RDPGFX_RESET_GRAPHICS_PDU` to allocate too small buffers, possibly triggering later out of bound read/write. Data extraction over network is not possible, the buffers are used to display an image. This issue has been addressed in version 2.11.5 and 3.2.0. Users are advised to upgrade. there are no know workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="2" name="freerdp" release="2.u1.fos23" version="2.11.1">
					<filename>freerdp-2.11.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/freerdp-2.11.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-devel" release="2.u1.fos23" version="2.11.1">
					<filename>freerdp-devel-2.11.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/freerdp-devel-2.11.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr" release="2.u1.fos23" version="2.11.1">
					<filename>libwinpr-2.11.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libwinpr-2.11.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr-devel" release="2.u1.fos23" version="2.11.1">
					<filename>libwinpr-devel-2.11.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libwinpr-devel-2.11.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-help" release="2.u1.fos23" version="2.11.1">
					<filename>freerdp-help-2.11.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/freerdp-help-2.11.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp" release="2.u1.fos23" version="2.11.1">
					<filename>freerdp-2.11.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/freerdp-2.11.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-devel" release="2.u1.fos23" version="2.11.1">
					<filename>freerdp-devel-2.11.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/freerdp-devel-2.11.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr" release="2.u1.fos23" version="2.11.1">
					<filename>libwinpr-2.11.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/libwinpr-2.11.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr-devel" release="2.u1.fos23" version="2.11.1">
					<filename>libwinpr-devel-2.11.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/libwinpr-devel-2.11.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-help" release="2.u1.fos23" version="2.11.1">
					<filename>freerdp-help-2.11.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/freerdp-help-2.11.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2022</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0553" id="CVE-2024-0553" title="CVE-2024-0553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0567" id="CVE-2024-0567" title="CVE-2024-0567" type="cve"></reference>
		</references>
		<description>CVE-2024-0553:A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.&#xA;CVE-2024-0567:A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="gnutls" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/gnutls-3.7.2-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/gnutls-devel-3.7.2-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/gnutls-utils-3.7.2-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnutls-help" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-help-3.7.2-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/gnutls-help-3.7.2-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/gnutls-3.7.2-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/gnutls-devel-3.7.2-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="10.u5.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/gnutls-utils-3.7.2-10.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2023</id>
		<title>An update for graphviz is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46045" id="CVE-2023-46045" title="CVE-2023-46045" type="cve"></reference>
		</references>
		<description>CVE-2023-46045:Graphviz 2.36 before 10.0.0 has an out-of-bounds read via a crafted config6a file. NOTE: exploitability may be uncommon because this file is typically owned by root.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="graphviz" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-devel" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-devel-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-devel-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-docs" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-docs-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-docs-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-gd" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-gd-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-gd-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-graphs" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-graphs-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-graphs-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-guile" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-guile-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-guile-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-java" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-java-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-java-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-lua" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-lua-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-lua-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-ocaml" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-ocaml-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-ocaml-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-perl" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-perl-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-perl-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-ruby" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-ruby-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-ruby-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-tcl" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-tcl-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-tcl-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="graphviz-python3" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-python3-2.48.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/graphviz-python3-2.48.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-devel" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-devel-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-devel-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-docs" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-docs-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-docs-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-gd" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-gd-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-gd-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-graphs" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-graphs-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-graphs-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-guile" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-guile-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-guile-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-java" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-java-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-java-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-lua" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-lua-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-lua-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-ocaml" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-ocaml-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-ocaml-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-perl" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-perl-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-perl-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-ruby" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-ruby-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-ruby-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-tcl" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-tcl-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-tcl-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="graphviz-python3" release="5.u1.fos23" version="2.48.0">
					<filename>graphviz-python3-2.48.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/graphviz-python3-2.48.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2024</id>
		<title>An update for hsqldb1 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41853" id="CVE-2022-41853" title="CVE-2022-41853" type="cve"></reference>
		</references>
		<description>CVE-2022-41853:Those using java.sql.Statement or java.sql.PreparedStatement in hsqldb (HyperSQL DataBase) to process untrusted input may be vulnerable to a remote code execution attack. By default it is allowed to call any static method of any Java class in the classpath resulting in code execution. The issue can be prevented by updating to 2.7.1 or by setting the system property &#34;hsqldb.method_class_names&#34; to classes which are allowed to be called. For example, System.setProperty(&#34;hsqldb.method_class_names&#34;, &#34;abc&#34;) or Java argument -Dhsqldb.method_class_names=&#34;abc&#34; can be used. From version 2.7.1 all classes by default are not accessible except those in java.lang.Math and need to be manually enabled.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="0" name="hsqldb1" release="3.u1.fos23" version="1.8.1.3">
					<filename>hsqldb1-1.8.1.3-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/hsqldb1-1.8.1.3-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hsqldb1-javadoc" release="3.u1.fos23" version="1.8.1.3">
					<filename>hsqldb1-javadoc-1.8.1.3-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/hsqldb1-javadoc-1.8.1.3-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2025</id>
		<title>An update for httpcomponents-client is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-13956" id="CVE-2020-13956" title="CVE-2020-13956" type="cve"></reference>
		</references>
		<description>CVE-2020-13956:Apache HttpClient versions prior to version 4.5.13 and 5.0.3 can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="0" name="httpcomponents-client" release="7.u1.fos23" version="4.5.5">
					<filename>httpcomponents-client-4.5.5-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/httpcomponents-client-4.5.5-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpcomponents-client-cache" release="7.u1.fos23" version="4.5.5">
					<filename>httpcomponents-client-cache-4.5.5-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/httpcomponents-client-cache-4.5.5-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpcomponents-client-help" release="7.u1.fos23" version="4.5.5">
					<filename>httpcomponents-client-help-4.5.5-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/httpcomponents-client-help-4.5.5-7.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2026</id>
		<title>An update for indent is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0911" id="CVE-2024-0911" title="CVE-2024-0911" type="cve"></reference>
		</references>
		<description>CVE-2024-0911:A flaw was found in indent, a program for formatting C code. This issue may allow an attacker to trick a user into processing a specially crafted file to trigger a heap-based buffer overflow, causing the application to crash.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="indent" release="30.u2.fos23" version="2.2.11">
					<filename>indent-2.2.11-30.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/indent-2.2.11-30.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="indent-help" release="30.u2.fos23" version="2.2.11">
					<filename>indent-help-2.2.11-30.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/indent-help-2.2.11-30.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="indent" release="30.u2.fos23" version="2.2.11">
					<filename>indent-2.2.11-30.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/indent-2.2.11-30.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2027</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20922" id="CVE-2024-20922" title="CVE-2024-20922" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20925" id="CVE-2024-20925" title="CVE-2024-20925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20923" id="CVE-2024-20923" title="CVE-2024-20923" type="cve"></reference>
		</references>
		<description>CVE-2024-20922:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-20918:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2024-20945:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20952:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2024-20926:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Scripting).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21; Oracle GraalVM for JDK: 17.0.9; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20925:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-20919:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.9 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).&#xA;CVE-2024-20921:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20923:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-headless-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-headless-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-headless-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-devel-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-devel-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-demo-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-demo-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-demo-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-src-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-src-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-src-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.402.b06-0.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-javadoc-1.8.0.402.b06-0.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.402.b06-0.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-javadoc-zip-1.8.0.402.b06-0.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-accessibility-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-devel-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-headless-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-headless-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-headless-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-devel-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-devel-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-demo-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-demo-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-demo-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-src-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-src-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-src-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-accessibility-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-devel-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u1.fos23" version="1.8.0.402.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.402.b06-0.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2028</id>
		<title>An update for jgit is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4759" id="CVE-2023-4759" title="CVE-2023-4759" type="cve"></reference>
		</references>
		<description>CVE-2023-4759:Arbitrary File Overwrite in Eclipse JGit &lt;= 6.6.0&#xA;In Eclipse JGit, all versions &lt;= 6.6.0.202305301015-r, a symbolic link present in a specially crafted git repository can be used to write a file to locations outside the working tree when this repository is cloned with JGit to a case-insensitive filesystem, or when a checkout from a clone of such a repository is performed on a case-insensitive filesystem.&#xA;This can happen on checkout (DirCacheCheckout), merge (ResolveMerger via its WorkingTreeUpdater), pull (PullCommand using merge), and when applying a patch (PatchApplier). This can be exploited for remote code execution (RCE), for instance if the file written outside the working tree is a git filter that gets executed on a subsequent git command.&#xA;The issue occurs only on case-insensitive filesystems, like the default filesystems on Windows and macOS. The user performing the clone or checkout must have the rights to create symbolic links for the problem to occur, and symbolic links must be enabled in the git configuration.&#xA;Setting git configuration option core.symlinks = false before checking out avoids the problem.&#xA;The issue was fixed in Eclipse JGit version 6.6.1.202309021850-r and 6.7.0.202309050840-r, available via  Maven Central https://repo1.maven.org/maven2/org/eclipse/jgit/  and  repo.eclipse.org https://repo.eclipse.org/content/repositories/jgit-releases/ . A backport is available in 5.13.3 starting from  5.13.3.202401111512-r.&#xA;The JGit maintainers would like to thank RyotaK for finding and reporting this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="0" name="jgit" release="3.u1.fos23" version="5.11.0">
					<filename>jgit-5.11.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/jgit-5.11.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jgit-javadoc" release="3.u1.fos23" version="5.11.0">
					<filename>jgit-javadoc-5.11.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/jgit-javadoc-5.11.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2029</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6932" id="CVE-2023-6932" title="CVE-2023-6932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6817" id="CVE-2023-6817" title="CVE-2023-6817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6546" id="CVE-2023-6546" title="CVE-2023-6546" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6931" id="CVE-2023-6931" title="CVE-2023-6931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6610" id="CVE-2023-6610" title="CVE-2023-6610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6606" id="CVE-2023-6606" title="CVE-2023-6606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35827" id="CVE-2023-35827" title="CVE-2023-35827" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51780" id="CVE-2023-51780" title="CVE-2023-51780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33631" id="CVE-2021-33631" title="CVE-2021-33631" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51781" id="CVE-2023-51781" title="CVE-2023-51781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51782" id="CVE-2023-51782" title="CVE-2023-51782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6121" id="CVE-2023-6121" title="CVE-2023-6121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51779" id="CVE-2023-51779" title="CVE-2023-51779" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6610" id="CVE-2023-6610" title="CVE-2023-6610" type="cve"></reference>
		</references>
		<description>CVE-2023-6932:A use-after-free vulnerability in the Linux kernel&#39;s ipv4: igmp component can be exploited to achieve local privilege escalation.&#xA;A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread.&#xA;We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1.&#xA;CVE-2023-6817:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.&#xA;The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free.&#xA;We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.&#xA;CVE-2023-6546:A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system.&#xA;CVE-2023-6931:A heap out-of-bounds write vulnerability in the Linux kernel&#39;s Performance Events system component can be exploited to achieve local privilege escalation.&#xA;A perf_event&#39;s read_size can overflow, leading to an heap out-of-bounds increment or write in perf_read_group().&#xA;We recommend upgrading past commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b.&#xA;CVE-2023-6610:An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.&#xA;CVE-2023-6606:An out-of-bounds read vulnerability was found in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.&#xA;CVE-2023-35827:An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.&#xA;CVE-2023-51780:An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.&#xA;CVE-2021-33631:Integer Overflow or Wraparound vulnerability in openEuler kernel on Linux (filesystem modules) allows Forced Integer Overflow.This issue affects openEuler kernel: from 4.19.90 before 4.19.90-2401.3, from 5.10.0-60.18.0 before 5.10.0-183.0.0.&#xA;CVE-2023-51781:An issue was discovered in the Linux kernel before 6.6.8. atalk_ioctl in net/appletalk/ddp.c has a use-after-free because of an atalk_recvmsg race condition.&#xA;CVE-2023-51782:An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.&#xA;CVE-2023-6121:An out-of-bounds read vulnerability was found in the NVMe-oF/TCP subsystem in the Linux kernel. This issue may allow a remote attacker to send a crafted TCP packet, triggering a heap-based buffer overflow that results in kmalloc data being printed and potentially leaked to the kernel ring buffer (dmesg).&#xA;CVE-2023-51779:A flaw was found in the Bluetooth subsystem of the Linux kernel. A race condition between the bt_sock_recvmsg() and bt_sock_ioctl() functions could lead to a use-after-free on a socket buffer (&#34;skb&#34;). This flaw allows a local user to cause a denial of service condition or potential code execution.&#xA;CVE-2023-6610:An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/kernel-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/kernel-headers-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/kernel-devel-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/kernel-tools-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/kernel-tools-devel-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/perf-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-perf-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/bpftool-5.10.0-136.60.0.139.u98.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/kernel-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/kernel-headers-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/kernel-devel-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/kernel-tools-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/kernel-tools-devel-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/perf-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-perf-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.60.0.139.u98.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/bpftool-5.10.0-136.60.0.139.u98.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2030</id>
		<title>An update for libgit2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24577" id="CVE-2024-24577" title="CVE-2024-24577" type="cve"></reference>
		</references>
		<description>CVE-2024-24577:libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Using well-crafted inputs to `git_index_add` can cause heap corruption that could be leveraged for arbitrary code execution. There is an issue in the `has_dir_name` function in `src/libgit2/index.c`, which frees an entry that should not be freed. The freed entry is later used and overwritten with potentially bad actor-controlled data leading to controlled heap corruption. Depending on the application that uses libgit2, this could lead to arbitrary code execution. This issue has been patched in version 1.6.5 and 1.7.2.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="libgit2" release="3.u2.fos23" version="1.3.2">
					<filename>libgit2-1.3.2-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libgit2-1.3.2-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgit2-devel" release="3.u2.fos23" version="1.3.2">
					<filename>libgit2-devel-1.3.2-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libgit2-devel-1.3.2-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgit2" release="3.u2.fos23" version="1.3.2">
					<filename>libgit2-1.3.2-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/libgit2-1.3.2-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgit2-devel" release="3.u2.fos23" version="1.3.2">
					<filename>libgit2-devel-1.3.2-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/libgit2-devel-1.3.2-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2031</id>
		<title>An update for liblouis is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26981" id="CVE-2022-26981" title="CVE-2022-26981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31783" id="CVE-2022-31783" title="CVE-2022-31783" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26767" id="CVE-2023-26767" title="CVE-2023-26767" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26768" id="CVE-2023-26768" title="CVE-2023-26768" type="cve"></reference>
		</references>
		<description>CVE-2022-26981:Liblouis through 3.21.0 has a buffer overflow in compilePassOpcode in compileTranslationTable.c (called, indirectly, by tools/lou_checktable.c).&#xA;CVE-2022-31783:Liblouis 3.21.0 has an out-of-bounds write in compileRule in compileTranslationTable.c, as demonstrated by lou_trace.&#xA;CVE-2023-26767:Buffer Overflow vulnerability found in Liblouis v.3.24.0 allows a remote attacker to cause a denial of service via the lou_logFile function at logginc.c endpoint.&#xA;CVE-2023-26768:Buffer Overflow vulnerability found in Liblouis v.3.24.0 allows a remote attacker to cause a denial of service via the compileTranslationTable.c and lou_setDataPath functions.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="liblouis" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-3.7.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/liblouis-3.7.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="liblouis-devel" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-devel-3.7.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/liblouis-devel-3.7.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="liblouis-utils" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-utils-3.7.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/liblouis-utils-3.7.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="liblouis-help" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-help-3.7.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/liblouis-help-3.7.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-louis" release="6.u3.fos23" version="3.7.0">
					<filename>python3-louis-3.7.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-louis-3.7.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblouis" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-3.7.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/liblouis-3.7.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblouis-devel" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-devel-3.7.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/liblouis-devel-3.7.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="liblouis-utils" release="6.u3.fos23" version="3.7.0">
					<filename>liblouis-utils-3.7.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/liblouis-utils-3.7.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2032</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25062" id="CVE-2024-25062" title="CVE-2024-25062" type="cve"></reference>
		</references>
		<description>CVE-2024-25062:An issue was discovered in libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="libxml2" release="10.u5.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libxml2-2.9.14-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="10.u5.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libxml2-devel-2.9.14-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="10.u5.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-libxml2-2.9.14-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="10.u5.fos23" version="2.9.14">
					<filename>libxml2-help-2.9.14-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/libxml2-help-2.9.14-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="10.u5.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/libxml2-2.9.14-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="10.u5.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/libxml2-devel-2.9.14-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="10.u5.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-libxml2-2.9.14-10.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2033</id>
		<title>An update for ncurses is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45918" id="CVE-2023-45918" title="CVE-2023-45918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50495" id="CVE-2023-50495" title="CVE-2023-50495" type="cve"></reference>
		</references>
		<description>CVE-2023-45918:ncurses 6.4-20230610 has a NULL pointer dereference in tgetstr in tinfo/lib_termcap.c.&#xA;CVE-2023-50495:NCurse v6.4-20230418 was discovered to contain a segmentation fault via the component _nc_wrap_entry().</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="ncurses" release="10.u5.fos23" version="6.3">
					<filename>ncurses-6.3-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-6.3-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ncurses-base" release="10.u5.fos23" version="6.3">
					<filename>ncurses-base-6.3-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-base-6.3-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-libs" release="10.u5.fos23" version="6.3">
					<filename>ncurses-libs-6.3-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-libs-6.3-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-devel" release="10.u5.fos23" version="6.3">
					<filename>ncurses-devel-6.3-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-devel-6.3-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-compat-libs" release="10.u5.fos23" version="6.3">
					<filename>ncurses-compat-libs-6.3-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-compat-libs-6.3-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-static" release="10.u5.fos23" version="6.3">
					<filename>ncurses-static-6.3-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-static-6.3-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-help" release="10.u5.fos23" version="6.3">
					<filename>ncurses-help-6.3-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/ncurses-help-6.3-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses" release="10.u5.fos23" version="6.3">
					<filename>ncurses-6.3-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/ncurses-6.3-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-libs" release="10.u5.fos23" version="6.3">
					<filename>ncurses-libs-6.3-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/ncurses-libs-6.3-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-devel" release="10.u5.fos23" version="6.3">
					<filename>ncurses-devel-6.3-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/ncurses-devel-6.3-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-compat-libs" release="10.u5.fos23" version="6.3">
					<filename>ncurses-compat-libs-6.3-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/ncurses-compat-libs-6.3-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-static" release="10.u5.fos23" version="6.3">
					<filename>ncurses-static-6.3-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/ncurses-static-6.3-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-help" release="10.u5.fos23" version="6.3">
					<filename>ncurses-help-6.3-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/ncurses-help-6.3-10.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2034</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51385" id="CVE-2023-51385" title="CVE-2023-51385" type="cve"></reference>
		</references>
		<description>CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.&#xA;CVE-2023-51385:In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="openssh" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-8.8p1-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssh-8.8p1-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssh-clients-8.8p1-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssh-server-8.8p1-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssh-keycat-8.8p1-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssh-askpass-8.8p1-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.26.u15.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/pam_ssh_agent_auth-0.10.4-4.26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-help-8.8p1-26.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssh-help-8.8p1-26.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-8.8p1-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssh-8.8p1-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssh-clients-8.8p1-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssh-server-8.8p1-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssh-keycat-8.8p1-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="26.u15.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssh-askpass-8.8p1-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.26.u15.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/pam_ssh_agent_auth-0.10.4-4.26.u15.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2035</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
		</references>
		<description>CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL&#xA;to crash leading to a potential Denial of Service attack&#xA;Impact summary: Applications loading files in the PKCS12 format from untrusted&#xA;sources might terminate abruptly.&#xA;A file in PKCS12 format can contain certificates and keys and may come from an&#xA;untrusted source. The PKCS12 specification allows certain fields to be NULL, but&#xA;OpenSSL does not correctly check for this case. This can lead to a NULL pointer&#xA;dereference that results in OpenSSL crashing. If an application processes PKCS12&#xA;files from an untrusted source using the OpenSSL APIs then that application will&#xA;be vulnerable to this issue.&#xA;OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),&#xA;PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()&#xA;and PKCS12_newpass().&#xA;We have also fixed a similar issue in SMIME_write_PKCS7(). However since this&#xA;function is related to writing data we do not consider it security significant.&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="1" name="openssl" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-32.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssl-1.1.1m-32.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-32.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssl-libs-1.1.1m-32.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-32.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssl-perl-1.1.1m-32.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-32.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssl-devel-1.1.1m-32.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-32.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/openssl-help-1.1.1m-32.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-32.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssl-1.1.1m-32.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-32.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssl-libs-1.1.1m-32.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-32.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssl-perl-1.1.1m-32.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="32.u14.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-32.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/openssl-devel-1.1.1m-32.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2036</id>
		<title>An update for pam is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22365" id="CVE-2024-22365" title="CVE-2024-22365" type="cve"></reference>
		</references>
		<description>CVE-2024-22365:linux-pam (aka Linux PAM) before 1.6.0 allows attackers to cause a denial of service (blocked login process) via mkfifo because the openat call (for protect_dir) lacks O_DIRECTORY.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="pam" release="7.u4.fos23" version="1.5.2">
					<filename>pam-1.5.2-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/pam-1.5.2-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam-devel" release="7.u4.fos23" version="1.5.2">
					<filename>pam-devel-1.5.2-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/pam-devel-1.5.2-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pam-help" release="7.u4.fos23" version="1.5.2">
					<filename>pam-help-1.5.2-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/pam-help-1.5.2-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam" release="7.u4.fos23" version="1.5.2">
					<filename>pam-1.5.2-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/pam-1.5.2-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam-devel" release="7.u4.fos23" version="1.5.2">
					<filename>pam-devel-1.5.2-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/pam-devel-1.5.2-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2037</id>
		<title>An update for proftpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51713" id="CVE-2023-51713" title="CVE-2023-51713" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
		</references>
		<description>CVE-2023-51713:make_ftp_cmd in main.c in ProFTPD before 1.3.8a has a one-byte out-of-bounds read, and daemon crash, because of mishandling of quote/backslash semantics.&#xA;CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="proftpd" release="1.fos23" version="1.3.8b">
					<filename>proftpd-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-devel" release="1.fos23" version="1.3.8b">
					<filename>proftpd-devel-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-devel-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-ldap" release="1.fos23" version="1.3.8b">
					<filename>proftpd-ldap-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-ldap-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-mysql" release="1.fos23" version="1.3.8b">
					<filename>proftpd-mysql-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-mysql-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-postgresql" release="1.fos23" version="1.3.8b">
					<filename>proftpd-postgresql-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-postgresql-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-sqlite" release="1.fos23" version="1.3.8b">
					<filename>proftpd-sqlite-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-sqlite-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-utils" release="1.fos23" version="1.3.8b">
					<filename>proftpd-utils-1.3.8b-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/proftpd-utils-1.3.8b-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd" release="1.fos23" version="1.3.8b">
					<filename>proftpd-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-devel" release="1.fos23" version="1.3.8b">
					<filename>proftpd-devel-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-devel-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-ldap" release="1.fos23" version="1.3.8b">
					<filename>proftpd-ldap-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-ldap-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-mysql" release="1.fos23" version="1.3.8b">
					<filename>proftpd-mysql-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-mysql-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-postgresql" release="1.fos23" version="1.3.8b">
					<filename>proftpd-postgresql-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-postgresql-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-sqlite" release="1.fos23" version="1.3.8b">
					<filename>proftpd-sqlite-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-sqlite-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-utils" release="1.fos23" version="1.3.8b">
					<filename>proftpd-utils-1.3.8b-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/proftpd-utils-1.3.8b-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2038</id>
		<title>An update for python-jinja2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22195" id="CVE-2024-22195" title="CVE-2024-22195" type="cve"></reference>
		</references>
		<description>CVE-2024-22195:Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="0" name="python3-jinja2" release="3.u1.fos23" version="3.0.3">
					<filename>python3-jinja2-3.0.3-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-jinja2-3.0.3-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-jinja2-help" release="3.u1.fos23" version="3.0.3">
					<filename>python-jinja2-help-3.0.3-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python-jinja2-help-3.0.3-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2039</id>
		<title>An update for python-jwcrypto is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3102" id="CVE-2022-3102" title="CVE-2022-3102" type="cve"></reference>
		</references>
		<description>CVE-2022-3102:The JWT code can auto-detect the type of token being provided, and this can lead the application to incorrect conclusions about the trustworthiness of the token.&#xA;Quoting the private disclosure we received : &#34;Under certain circumstances, it is possible to substitute a [..] signed JWS with a JWE that is encrypted with the public key that is normally used for signature validation.&#34; This substitution attack can occur only if the validating application also have access to the private key, normally used to sign the tokens, available during validation of the received JWT.&#xA;The significance of this attacks depends on the use of the token, it may lead to authentication bypass or authorization bypass (respectively if claims are used to authenticate or authorize certain actions), because the attacker has full control of the data placed in the JWE and can inject any desired claim value.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="0" name="python3-jwcrypto" release="1.fos23" version="1.4.2">
					<filename>python3-jwcrypto-1.4.2-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-jwcrypto-1.4.2-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2040</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45198" id="CVE-2022-45198" title="CVE-2022-45198" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50447" id="CVE-2023-50447" title="CVE-2023-50447" type="cve"></reference>
		</references>
		<description>CVE-2022-45198:Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).&#xA;CVE-2023-50447:Pillow through 10.1.0 allows PIL.ImageMath.eval Arbitrary Code Execution via the environment parameter, a different vulnerability than CVE-2022-22817 (which was about the expression parameter).</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="python3-pillow" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pillow-9.0.1-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-devel" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pillow-devel-9.0.1-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pillow-help" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-help-9.0.1-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pillow-help-9.0.1-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-tk" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pillow-tk-9.0.1-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-qt" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pillow-qt-9.0.1-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-pillow-9.0.1-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-devel" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-pillow-devel-9.0.1-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-tk" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-pillow-tk-9.0.1-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-qt" release="6.u3.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-pillow-qt-9.0.1-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2041</id>
		<title>An update for python-pycryptodome is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"></reference>
		</references>
		<description>CVE-2023-52323:PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="python3-pycryptodome" release="1.fos23" version="3.19.1">
					<filename>python3-pycryptodome-3.19.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pycryptodome-3.19.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pycryptodome" release="1.fos23" version="3.19.1">
					<filename>python3-pycryptodome-3.19.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-pycryptodome-3.19.1-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2042</id>
		<title>An update for python-pycryptodomex is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"></reference>
		</references>
		<description>CVE-2023-52323:PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="python3-pycryptodomex" release="1.fos23" version="3.19.1">
					<filename>python3-pycryptodomex-3.19.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python3-pycryptodomex-3.19.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pycryptodomex-help" release="1.fos23" version="3.19.1">
					<filename>python-pycryptodomex-help-3.19.1-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/python-pycryptodomex-help-3.19.1-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pycryptodomex" release="1.fos23" version="3.19.1">
					<filename>python3-pycryptodomex-3.19.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/python3-pycryptodomex-3.19.1-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2043</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51714" id="CVE-2023-51714" title="CVE-2023-51714" type="cve"></reference>
		</references>
		<description>CVE-2023-51714:An issue was discovered in the HTTP2 implementation in Qt before 5.15.17, 6.x before 6.2.11, 6.3.x through 6.5.x before 6.5.4, and 6.6.x before 6.6.2. network/access/http2/hpacktable.cpp has an incorrect HPack integer overflow check.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-14.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-common-5.15.2-14.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-devel-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-private-devel-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-examples-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-static-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-mysql-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-odbc-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-postgresql-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/qt5-qtbase-gui-5.15.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-devel-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-private-devel-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-examples-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-static-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-mysql-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-odbc-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-postgresql-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="14.u7.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/qt5-qtbase-gui-5.15.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2044</id>
		<title>An update for rear is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23301" id="CVE-2024-23301" title="CVE-2024-23301" type="cve"></reference>
		</references>
		<description>CVE-2024-23301:Relax-and-Recover (aka ReaR) through 2.7 creates a world-readable initrd when using GRUB_RESCUE=y. This allows local attackers to gain access to system secrets otherwise only readable by root.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="rear" release="5.u1.fos23" version="2.4">
					<filename>rear-2.4-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/rear-2.4-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rear-help" release="5.u1.fos23" version="2.4">
					<filename>rear-help-2.4-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/rear-help-2.4-5.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2045</id>
		<title>An update for rubygem-actionpack is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22792" id="CVE-2023-22792" title="CVE-2023-22792" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22795" id="CVE-2023-22795" title="CVE-2023-22795" type="cve"></reference>
		</references>
		<description>CVE-2023-22792:A regular expression based DoS vulnerability in Action Dispatch &lt;6.0.6.1,&lt; 6.1.7.1, and &lt;7.0.4.1. Specially crafted cookies, in combination with a specially crafted X_FORWARDED_HOST header can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.&#xA;CVE-2023-22795:A regular expression based DoS vulnerability in Action Dispatch &lt;6.1.7.1 and &lt;7.0.4.1 related to the If-None-Match header. A specially crafted HTTP If-None-Match header can cause the regular expression engine to enter a state of catastrophic backtracking, when on a version of Ruby below 3.2.0. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="1" name="rubygem-actionpack" release="4.u2.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-6.1.4.1-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/rubygem-actionpack-6.1.4.1-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-actionpack-doc" release="4.u2.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-doc-6.1.4.1-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/rubygem-actionpack-doc-6.1.4.1-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2046</id>
		<title>An update for rubygem-puma is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23634" id="CVE-2022-23634" title="CVE-2022-23634" type="cve"></reference>
		</references>
		<description>CVE-2022-23634:Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of these two behaviors (Puma not closing the body + Rails&#39; Executor implementation) causes information leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="rubygem-puma" release="2.u1.fos23" version="5.5.2">
					<filename>rubygem-puma-5.5.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/rubygem-puma-5.5.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-puma-doc" release="2.u1.fos23" version="5.5.2">
					<filename>rubygem-puma-doc-5.5.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/rubygem-puma-doc-5.5.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-puma" release="2.u1.fos23" version="5.5.2">
					<filename>rubygem-puma-5.5.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/rubygem-puma-5.5.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2047</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40547" id="CVE-2023-40547" title="CVE-2023-40547" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40548" id="CVE-2023-40548" title="CVE-2023-40548" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40549" id="CVE-2023-40549" title="CVE-2023-40549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40550" id="CVE-2023-40550" title="CVE-2023-40550" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40551" id="CVE-2023-40551" title="CVE-2023-40551" type="cve"></reference>
		</references>
		<description>CVE-2023-40547:A remote code execution vulnerability was found in Shim. The Shim boot support trusts attacker-controlled values when parsing an HTTP response. This flaw allows an attacker to craft a specific malicious HTTP request, leading to a completely controlled out-of-bounds write primitive and complete system compromise. This flaw is only exploitable during the early boot phase, an attacker needs to perform a Man-in-the-Middle or compromise the boot server to be able to exploit this vulnerability successfully.&#xA;CVE-2023-40548:A buffer overflow was found in Shim in the 32-bit system. The overflow happens due to an addition operation involving a user-controlled value parsed from the PE binary being used by Shim. This value is further used for memory allocation operations, leading to a heap-based buffer overflow. This flaw causes memory corruption and can lead to a crash or data integrity issues during the boot phase.&#xA;CVE-2023-40549:An out-of-bounds read flaw was found in Shim due to the lack of proper boundary verification during the load of a PE binary. This flaw allows an attacker to load a crafted PE binary, triggering the issue and crashing Shim, resulting in a denial of service.&#xA;CVE-2023-40550:An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system&#39;s boot phase.&#xA;CVE-2023-40551:A flaw was found in the MZ binary format in Shim. An out-of-bounds read may occur, leading to a crash or possible exposure of sensitive data during the system&#39;s boot phase.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="shim" release="16.u10.fos23" version="15.6">
					<filename>shim-15.6-16.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/shim-15.6-16.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="16.u10.fos23" version="15.6">
					<filename>shim-15.6-16.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/shim-15.6-16.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2048</id>
		<title>An update for sox is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33844" id="CVE-2021-33844" title="CVE-2021-33844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32627" id="CVE-2023-32627" title="CVE-2023-32627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23159" id="CVE-2021-23159" title="CVE-2021-23159" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34432" id="CVE-2023-34432" title="CVE-2023-34432" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34318" id="CVE-2023-34318" title="CVE-2023-34318" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23172" id="CVE-2021-23172" title="CVE-2021-23172" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3643" id="CVE-2021-3643" title="CVE-2021-3643" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23210" id="CVE-2021-23210" title="CVE-2021-23210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31650" id="CVE-2022-31650" title="CVE-2022-31650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26590" id="CVE-2023-26590" title="CVE-2023-26590" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31651" id="CVE-2022-31651" title="CVE-2022-31651" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32627" id="CVE-2023-32627" title="CVE-2023-32627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-18189" id="CVE-2017-18189" title="CVE-2017-18189" type="cve"></reference>
		</references>
		<description>CVE-2021-33844:A floating point exception (divide-by-zero) issue was discovered in SoX in functon startread() of wav.c file. An attacker with a crafted wav file, could cause an application to crash.&#xA;CVE-2023-32627:A floating point exception vulnerability was found in sox, in the read_samples function at sox/src/voc.c:334:18. This flaw can lead to a denial of service.&#xA;CVE-2021-23159:A vulnerability was found in SoX, where a heap-buffer-overflow occurs in function lsx_read_w_buf() in formats_i.c file. The vulnerability is exploitable with a crafted file, that could cause an application to crash.&#xA;CVE-2023-34432:A heap buffer overflow vulnerability was found in sox, in the lsx_readbuf function at sox/src/formats_i.c:98:16. This flaw can lead to a denial of service, code execution, or information disclosure.&#xA;CVE-2023-34318:A heap buffer overflow vulnerability was found in sox, in the startread function at sox/src/hcom.c:160:41. This flaw can lead to a denial of service, code execution, or information disclosure.&#xA;CVE-2021-23172:A vulnerability was found in SoX, where a heap-buffer-overflow occurs in function startread() in hcom.c file. The vulnerability is exploitable with a crafted hcomn file, that could cause an application to crash.&#xA;CVE-2021-3643:A flaw was found in sox 14.4.1. The lsx_adpcm_init function within libsox leads to a global-buffer-overflow. This flaw allows an attacker to input a malicious file, leading to the disclosure of sensitive information.&#xA;CVE-2021-23210:A floating point exception (divide-by-zero) issue was discovered in SoX in functon read_samples() of voc.c file. An attacker with a crafted file, could cause an application to crash.&#xA;CVE-2022-31650:In SoX 14.4.2, there is a floating-point exception in lsx_aiffstartwrite in aiff.c in libsox.a.&#xA;CVE-2023-26590:A floating point exception vulnerability was found in sox, in the lsx_aiffstartwrite function at sox/src/aiff.c:622:58. This flaw can lead to a denial of service.&#xA;CVE-2022-31651:In SoX 14.4.2, there is an assertion failure in rate_init in rate.c in libsox.a.&#xA;CVE-2023-32627:A floating point exception vulnerability was found in sox, in the read_samples function at sox/src/voc.c:334:18. This flaw can lead to a denial of service.&#xA;CVE-2017-18189:In the startread function in xa.c in Sound eXchange (SoX) through 14.4.2, a corrupt header specifying zero channels triggers an infinite loop with a resultant NULL pointer dereference, which may allow a remote attacker to cause a denial-of-service.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="sox" release="30.u1.fos23" version="14.4.2.0">
					<filename>sox-14.4.2.0-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/sox-14.4.2.0-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sox-devel" release="30.u1.fos23" version="14.4.2.0">
					<filename>sox-devel-14.4.2.0-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/sox-devel-14.4.2.0-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sox-help" release="30.u1.fos23" version="14.4.2.0">
					<filename>sox-help-14.4.2.0-30.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/sox-help-14.4.2.0-30.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sox" release="30.u1.fos23" version="14.4.2.0">
					<filename>sox-14.4.2.0-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/sox-14.4.2.0-30.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sox-devel" release="30.u1.fos23" version="14.4.2.0">
					<filename>sox-devel-14.4.2.0-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/sox-devel-14.4.2.0-30.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2049</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23638" id="CVE-2024-23638" title="CVE-2024-23638" type="cve"></reference>
		</references>
		<description>CVE-2024-23638:Squid is a caching proxy for the Web. Due to an expired pointer reference bug, Squid prior to version 6.6 is vulnerable to a Denial of Service attack against Cache Manager error responses. This problem allows a trusted client to perform Denial of Service when generating error pages for Client Manager reports. Squid older than 5.0.5 have not been tested and should be assumed to be vulnerable. All Squid-5.x up to and including 5.9 are vulnerable. All Squid-6.x up to and including 6.5 are vulnerable. This bug is fixed by Squid version 6.6. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives. As a workaround, prevent access to Cache Manager using Squid&#39;s main access control: `http_access deny manager`.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="7" name="squid" release="23.u4.fos23" version="4.9">
					<filename>squid-4.9-23.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/squid-4.9-23.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="23.u4.fos23" version="4.9">
					<filename>squid-4.9-23.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/squid-4.9-23.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2050</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24998" id="CVE-2023-24998" title="CVE-2023-24998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28709" id="CVE-2023-28709" title="CVE-2023-28709" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42795" id="CVE-2023-42795" title="CVE-2023-42795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21733" id="CVE-2024-21733" title="CVE-2024-21733" type="cve"></reference>
		</references>
		<description>CVE-2023-24998:Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads.&#xA;Note that, like all of the file upload limits, the&#xA;          new configuration option (FileUploadBase#setFileCountMax) is not&#xA;          enabled by default and must be explicitly configured.&#xA;CVE-2023-28709:The fix for CVE-2023-24998 was incomplete for Apache Tomcat 11.0.0-M2 to 11.0.0-M4, 10.1.5 to 10.1.7, 9.0.71 to 9.0.73 and 8.5.85 to 8.5.87. If non-default HTTP       connector settings were used such that the maxParameterCount could be reached using query string parameters and a request was       submitted that supplied exactly maxParameterCount parameters in the query string, the limit for uploaded request parts could be bypassed with the potential for a denial of service to occur.&#xA;CVE-2023-42795:Incomplete Cleanup vulnerability in Apache Tomcat.When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could &#xA;cause Tomcat to skip some parts of the recycling process leading to &#xA;information leaking from the current request/response to the next.&#xA;Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue.&#xA;CVE-2024-21733:Generation of Error Message Containing Sensitive Information vulnerability in Apache Tomcat.This issue affects Apache Tomcat: from 8.5.7 through 8.5.63, from 9.0.0-M11 through 9.0.43.&#xA;Users are recommended to upgrade to version 8.5.64 onwards or 9.0.44 onwards, which contain a fix for the issue.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="1" name="tomcat" release="33.u13.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-33.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/tomcat-9.0.10-33.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="33.u13.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-33.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/tomcat-jsvc-9.0.10-33.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="33.u13.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-33.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/tomcat-help-9.0.10-33.u13.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2051</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0208" id="CVE-2024-0208" title="CVE-2024-0208" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0209" id="CVE-2024-0209" title="CVE-2024-0209" type="cve"></reference>
		</references>
		<description>CVE-2024-0208:GVCP dissector crash in Wireshark 4.2.0, 4.0.0 to 4.0.11, and 3.6.0 to 3.6.19 allows denial of service via packet injection or crafted capture file&#xA;CVE-2024-0209:IEEE 1609.2 dissector crash in Wireshark 4.2.0, 4.0.0 to 4.0.11, and 3.6.0 to 3.6.19 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="6.u9.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-6.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/wireshark-3.6.14-6.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="6.u9.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-6.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/wireshark-devel-3.6.14-6.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="6.u9.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-6.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/wireshark-help-3.6.14-6.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="6.u9.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-6.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/wireshark-3.6.14-6.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="6.u9.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-6.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/wireshark-devel-3.6.14-6.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="6.u9.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-6.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/wireshark-help-3.6.14-6.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2052</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-02-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21885" id="CVE-2024-21885" title="CVE-2024-21885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21886" id="CVE-2024-21886" title="CVE-2024-21886" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0408" id="CVE-2024-0408" title="CVE-2024-0408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0409" id="CVE-2024-0409" title="CVE-2024-0409" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0229" id="CVE-2024-0229" title="CVE-2024-0229" type="cve"></reference>
		</references>
		<description>CVE-2024-21885:A flaw was found in X.Org server. In the XISendDeviceHierarchyEvent function, it is possible to exceed the allocated array length when certain new device IDs are added to the xXIHierarchyInfo struct. This can trigger a heap buffer overflow condition, which may lead to an application crash or remote code execution in SSH X11 forwarding environments.&#xA;CVE-2024-21886:A heap buffer overflow flaw was found in the DisableDevice function in the X.Org server. This issue may lead to an application crash or, in some circumstances, remote code execution in SSH X11 forwarding environments.&#xA;CVE-2024-0408:A flaw was found in the X.Org server. The GLX PBuffer code does not call the XACE hook when creating the buffer, leaving it unlabeled. When the client issues another request to access that resource (as with a GetGeometry) or when it creates another resource that needs to access that buffer, such as a GC, the XSELINUX code will try to use an object that was never labeled and crash because the SID is NULL.&#xA;CVE-2024-0409:A flaw was found in the X.Org server. The cursor code in both Xephyr and Xwayland uses the wrong type of private at creation. It uses the cursor bits type with the cursor as private, and when initiating the cursor, that overwrites the XSELINUX context.&#xA;CVE-2023-6816:A flaw was found in X.Org server. Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Buttons can be arbitrarily mapped to any value up to 255, but the X.Org Server was only allocating space for the device&#39;s particular number of buttons, leading to a heap overflow if a bigger value was used.&#xA;CVE-2024-0229:An out-of-bounds memory access flaw was found in the X.Org server. This issue can be triggered when a device frozen by a sync grab is reattached to a different master device. This issue may lead to an application crash, local privilege escalation (if the server runs with extended privileges), or remote code execution in SSH X11 forwarding environments.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-common-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-Xnest-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-Xdmx-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-Xvfb-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-Xephyr-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-25.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-devel-1.20.11-25.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-25.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-help-1.20.11-25.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-25.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.4.3/xorg-x11-server-source-1.20.11-25.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-common-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-Xnest-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-Xdmx-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-Xvfb-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-Xephyr-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="25.u12.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-25.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/xorg-x11-server-devel-1.20.11-25.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2053</id>
		<title>An update for 389-ds-base is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1062" id="CVE-2024-1062" title="CVE-2024-1062" type="cve"></reference>
		</references>
		<description>CVE-2024-1062:A heap overflow flaw was found in 389-ds-base. This issue leads to a denial of service when writing a value larger than 256 chars in log_entry_attr.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="389-ds-base" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/389-ds-base-1.4.3.36-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-legacy-tools" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/389-ds-base-legacy-tools-1.4.3.36-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-devel" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/389-ds-base-devel-1.4.3.36-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-snmp" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/389-ds-base-snmp-1.4.3.36-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-lib389" release="5.u2.fos23" version="1.4.3.36">
					<filename>python3-lib389-1.4.3.36-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-lib389-1.4.3.36-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-389-ds" release="5.u2.fos23" version="1.4.3.36">
					<filename>cockpit-389-ds-1.4.3.36-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/cockpit-389-ds-1.4.3.36-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-help" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/389-ds-base-help-1.4.3.36-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/389-ds-base-1.4.3.36-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-legacy-tools" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/389-ds-base-legacy-tools-1.4.3.36-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-devel" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/389-ds-base-devel-1.4.3.36-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-snmp" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/389-ds-base-snmp-1.4.3.36-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-help" release="5.u2.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/389-ds-base-help-1.4.3.36-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2054</id>
		<title>An update for OpenEXR is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5841" id="CVE-2023-5841" title="CVE-2023-5841" type="cve"></reference>
		</references>
		<description>CVE-2023-5841:Due to a failure in validating the number of scanline samples of a OpenEXR file containing deep scanline data, Academy Software Foundation OpenEX image parsing library version 3.2.1 and prior is susceptible to a heap-based buffer overflow vulnerability. This issue was resolved as of versions v3.2.2 and v3.1.12 of the affected library.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="OpenEXR" release="2.u1.fos23" version="3.1.5">
					<filename>OpenEXR-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/OpenEXR-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-libs" release="2.u1.fos23" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/OpenEXR-libs-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-devel" release="2.u1.fos23" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/OpenEXR-devel-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR" release="2.u1.fos23" version="3.1.5">
					<filename>OpenEXR-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/OpenEXR-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-libs" release="2.u1.fos23" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/OpenEXR-libs-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-devel" release="2.u1.fos23" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/OpenEXR-devel-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2055</id>
		<title>An update for apache-mime4j is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21742" id="CVE-2024-21742" title="CVE-2024-21742" type="cve"></reference>
		</references>
		<description>CVE-2024-21742:Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message.&#xA;This can be exploited by an attacker to add unintended headers to MIME messages.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="apache-mime4j" release="2.u1.fos23" version="0.8.3">
					<filename>apache-mime4j-0.8.3-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/apache-mime4j-0.8.3-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mime4j-javadoc" release="2.u1.fos23" version="0.8.3">
					<filename>apache-mime4j-javadoc-0.8.3-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/apache-mime4j-javadoc-0.8.3-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2056</id>
		<title>An update for apache-sshd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
		</references>
		<description>CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="1" name="apache-sshd" release="3.u2.fos23" version="2.9.2">
					<filename>apache-sshd-2.9.2-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/apache-sshd-2.9.2-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="apache-sshd-javadoc" release="3.u2.fos23" version="2.9.2">
					<filename>apache-sshd-javadoc-2.9.2-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/apache-sshd-javadoc-2.9.2-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2057</id>
		<title>An update for atune-collector is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24897" id="CVE-2024-24897" title="CVE-2024-24897" type="cve"></reference>
		</references>
		<description>CVE-2024-24897:Improper Neutralization of Special Elements used in a Command (&#39;Command Injection&#39;) vulnerability in openEuler A-Tune-Collector on Linux allows Command Injection. This vulnerability is associated with program files https://gitee.Com/openeuler/A-Tune-Collector/blob/master/atune_collector/plugin/monitor/process/sched.Py.&#xA;This issue affects A-Tune-Collector: from 1.1.0-3 through 1.3.0.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="atune-collector" release="8.u7.fos23" version="1.1.0">
					<filename>atune-collector-1.1.0-8.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/atune-collector-1.1.0-8.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="atune-collector" release="8.u7.fos23" version="1.1.0">
					<filename>atune-collector-1.1.0-8.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/atune-collector-1.1.0-8.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2058</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25584" id="CVE-2023-25584" title="CVE-2023-25584" type="cve"></reference>
		</references>
		<description>CVE-2023-25584:An out-of-bounds read flaw was found in the parse_module function in bfd/vms-alpha.c in Binutils.</description>
		<pkglist>
			<collection>
				<name>23.0.3.3</name>
				<package arch="x86_64" epoch="0" name="binutils" release="24.u11.fos23" version="2.37">
					<filename>binutils-2.37-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/binutils-2.37-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="24.u11.fos23" version="2.37">
					<filename>binutils-devel-2.37-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/binutils-devel-2.37-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="24.u11.fos23" version="2.37">
					<filename>binutils-help-2.37-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.3.3/binutils-help-2.37-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="24.u11.fos23" version="2.37">
					<filename>binutils-2.37-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/binutils-2.37-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="24.u11.fos23" version="2.37">
					<filename>binutils-devel-2.37-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/binutils-devel-2.37-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="24.u11.fos23" version="2.37">
					<filename>binutils-help-2.37-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.3.3/binutils-help-2.37-24.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2059</id>
		<title>An update for c-ares is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25629" id="CVE-2024-25629" title="CVE-2024-25629" type="cve"></reference>
		</references>
		<description>CVE-2024-25629:c-ares is a C library for asynchronous DNS requests. `ares__read_line()` is used to parse local configuration files such as `/etc/resolv.conf`, `/etc/nsswitch.conf`, the `HOSTALIASES` file, and if using a c-ares version prior to 1.27.0, the `/etc/hosts` file. If any of these configuration files has an embedded `NULL` character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="c-ares" release="8.u4.fos23" version="1.18.1">
					<filename>c-ares-1.18.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/c-ares-1.18.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="c-ares-devel" release="8.u4.fos23" version="1.18.1">
					<filename>c-ares-devel-1.18.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/c-ares-devel-1.18.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="c-ares-help" release="8.u4.fos23" version="1.18.1">
					<filename>c-ares-help-1.18.1-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/c-ares-help-1.18.1-8.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="c-ares" release="8.u4.fos23" version="1.18.1">
					<filename>c-ares-1.18.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/c-ares-1.18.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="c-ares-devel" release="8.u4.fos23" version="1.18.1">
					<filename>c-ares-devel-1.18.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/c-ares-devel-1.18.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2060</id>
		<title>An update for derby is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46337" id="CVE-2022-46337" title="CVE-2022-46337" type="cve"></reference>
		</references>
		<description>CVE-2022-46337:A cleverly devised username might bypass LDAP authentication checks. In &#xA;LDAP-authenticated Derby installations, this could let an attacker fill &#xA;up the disk by creating junk Derby databases. In LDAP-authenticated &#xA;Derby installations, this could also allow the attacker to execute &#xA;malware which was visible to and executable by the account which booted &#xA;the Derby server. In LDAP-protected databases which weren&#39;t also &#xA;protected by SQL GRANT/REVOKE authorization, this vulnerability could &#xA;also let an attacker view and corrupt sensitive data and run sensitive &#xA;database functions and procedures.&#xA;Mitigation:&#xA;Users should upgrade to Java 21 and Derby 10.17.1.0.&#xA;Alternatively, users who wish to remain on older Java versions should &#xA;build their own Derby distribution from one of the release families to &#xA;which the fix was backported: 10.16, 10.15, and 10.14. Those are the &#xA;releases which correspond, respectively, with Java LTS versions 17, 11, &#xA;and 8.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="derby" release="1.fos23" version="10.14.2.0">
					<filename>derby-10.14.2.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/derby-10.14.2.0-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="derby-javadoc" release="1.fos23" version="10.14.2.0">
					<filename>derby-javadoc-10.14.2.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/derby-javadoc-10.14.2.0-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2061</id>
		<title>An update for dhcp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2795" id="CVE-2022-2795" title="CVE-2022-2795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38177" id="CVE-2022-38177" title="CVE-2022-38177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38178" id="CVE-2022-38178" title="CVE-2022-38178" type="cve"></reference>
		</references>
		<description>CVE-2022-2795:By flooding the target resolver with queries exploiting this flaw an attacker can significantly impair the resolver&#39;s performance, effectively denying legitimate clients access to the DNS resolution service.&#xA;CVE-2022-38177:By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.&#xA;CVE-2022-38178:By spoofing the target resolver with responses that have a malformed EdDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="12" name="dhcp" release="6.u4.fos23" version="4.4.3">
					<filename>dhcp-4.4.3-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/dhcp-4.4.3-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="dhcp-devel" release="6.u4.fos23" version="4.4.3">
					<filename>dhcp-devel-4.4.3-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/dhcp-devel-4.4.3-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="12" name="dhcp-help" release="6.u4.fos23" version="4.4.3">
					<filename>dhcp-help-4.4.3-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/dhcp-help-4.4.3-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="dhcp" release="6.u4.fos23" version="4.4.3">
					<filename>dhcp-4.4.3-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/dhcp-4.4.3-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="dhcp-devel" release="6.u4.fos23" version="4.4.3">
					<filename>dhcp-devel-4.4.3-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/dhcp-devel-4.4.3-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2062</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36763" id="CVE-2022-36763" title="CVE-2022-36763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36764" id="CVE-2022-36764" title="CVE-2022-36764" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36765" id="CVE-2022-36765" title="CVE-2022-36765" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45229" id="CVE-2023-45229" title="CVE-2023-45229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45230" id="CVE-2023-45230" title="CVE-2023-45230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45231" id="CVE-2023-45231" title="CVE-2023-45231" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45232" id="CVE-2023-45232" title="CVE-2023-45232" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45233" id="CVE-2023-45233" title="CVE-2023-45233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45234" id="CVE-2023-45234" title="CVE-2023-45234" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45235" id="CVE-2023-45235" title="CVE-2023-45235" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
		</references>
		<description>CVE-2022-36763:EDK2 is susceptible to a vulnerability in the Tcg2MeasureGptTable() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.&#xA;CVE-2022-36764:EDK2 is susceptible to a vulnerability in the Tcg2MeasurePeImage() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.&#xA;CVE-2022-36765:EDK2 is susceptible to a vulnerability in the CreateHob() function, allowing a user to trigger a integer overflow to buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.&#xA;CVE-2023-45229:EDK2&#39;s Network Package is susceptible to an out-of-bounds read&#xA; vulnerability when processing the IA_NA or IA_TA option in a DHCPv6 Advertise message. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality.&#xA;CVE-2023-45230:EDK2&#39;s Network Package is susceptible to a buffer overflow vulnerability via a long server ID option in DHCPv6 client. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.&#xA;CVE-2023-45231:EDK2&#39;s Network Package is susceptible to an out-of-bounds read&#xA; vulnerability when processing  Neighbor Discovery Redirect message. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality.&#xA;CVE-2023-45232:EDK2&#39;s Network Package is susceptible to an infinite loop vulnerability when parsing unknown options in the Destination Options header of IPv6. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Availability.&#xA;CVE-2023-45233:EDK2&#39;s Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Availability.&#xA;CVE-2023-45234:EDK2&#39;s Network Package is susceptible to a buffer overflow vulnerability when processing DNS Servers option from a DHCPv6 Advertise message. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.&#xA;CVE-2023-45235:EDK2&#39;s Network Package is susceptible to a buffer overflow vulnerability when&#xA;handling Server ID option &#xA; from a DHCPv6 proxy Advertise message. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.&#xA;CVE-2023-0464:A security vulnerability has been identified in all supported versions&#xA;of OpenSSL related to the verification of X.509 certificate chains&#xA;that include policy constraints.  Attackers may be able to exploit this&#xA;vulnerability by creating a malicious certificate chain that triggers&#xA;exponential use of computational resources, leading to a denial-of-service&#xA;(DoS) attack on affected systems.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0465:Applications that use a non-default option when verifying certificates may be&#xA;vulnerable to an attack from a malicious CA to circumvent certain checks.&#xA;Invalid certificate policies in leaf certificates are silently ignored by&#xA;OpenSSL and other certificate policy checks are skipped for that certificate.&#xA;A malicious CA could use this to deliberately assert invalid certificate policies&#xA;in order to circumvent policy checking on the certificate altogether.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0466:The function X509_VERIFY_PARAM_add0_policy() is documented to&#xA;implicitly enable the certificate policy check when doing certificate&#xA;verification. However the implementation of the function does not&#xA;enable the check which allows certificates with invalid or incorrect&#xA;policies to pass the certificate verification.&#xA;As suddenly enabling the policy check could break existing deployments it was&#xA;decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy()&#xA;function.&#xA;Instead the applications that require OpenSSL to perform certificate&#xA;policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly&#xA;enable the policy check by calling X509_VERIFY_PARAM_set_flags() with&#xA;the X509_V_FLAG_POLICY_CHECK flag argument.&#xA;Certificate policy checks are disabled by default in OpenSSL and are not&#xA;commonly used by applications.&#xA;CVE-2023-2650:Issue summary: Processing some specially crafted ASN.1 object identifiers or&#xA;data containing them may be very slow.&#xA;Impact summary: Applications that use OBJ_obj2txt() directly, or use any of&#xA;the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message&#xA;size limit may experience notable to very long delays when processing those&#xA;messages, which may lead to a Denial of Service.&#xA;An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -&#xA;most of which have no size limit.  OBJ_obj2txt() may be used to translate&#xA;an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL&#xA;type ASN1_OBJECT) to its canonical numeric text form, which are the&#xA;sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by&#xA;periods.&#xA;When one of the sub-identifiers in the OBJECT IDENTIFIER is very large&#xA;(these are sizes that are seen as absurdly large, taking up tens or hundreds&#xA;of KiBs), the translation to a decimal number in text may take a very long&#xA;time.  The time complexity is O(n^2) with &#39;n&#39; being the size of the&#xA;sub-identifiers in bytes (*).&#xA;With OpenSSL 3.0, support to fetch cryptographic algorithms using names /&#xA;identifiers in string form was introduced.  This includes using OBJECT&#xA;IDENTIFIERs in canonical numeric text form as identifiers for fetching&#xA;algorithms.&#xA;Such OBJECT IDENTIFIERs may be received through the ASN.1 structure&#xA;AlgorithmIdentifier, which is commonly used in multiple protocols to specify&#xA;what cryptographic algorithm should be used to sign or verify, encrypt or&#xA;decrypt, or digest passed data.&#xA;Applications that call OBJ_obj2txt() directly with untrusted data are&#xA;affected, with any version of OpenSSL.  If the use is for the mere purpose&#xA;of display, the severity is considered low.&#xA;In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,&#xA;CMS, CMP/CRMF or TS.  It also impacts anything that processes X.509&#xA;certificates, including simple things like verifying its signature.&#xA;The impact on TLS is relatively low, because all versions of OpenSSL have a&#xA;100KiB limit on the peer&#39;s certificate chain.  Additionally, this only&#xA;impacts clients, or servers that have explicitly enabled client&#xA;authentication.&#xA;In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,&#xA;such as X.509 certificates.  This is assumed to not happen in such a way&#xA;that it would cause a Denial of Service, so these versions are considered&#xA;not affected by this issue in such a way that it would be cause for concern,&#xA;and the severity is therefore considered low.&#xA;CVE-2023-3446:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. One of those&#xA;checks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to use&#xA;a very large modulus is slow and OpenSSL will not normally use a modulus which&#xA;is over 10,000 bits in length.&#xA;However the DH_check() function checks numerous aspects of the key or parameters&#xA;that have been supplied. Some of those checks use the supplied modulus value&#xA;even if it has already been found to be too large.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulernable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#39;-check&#39; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2023-3817:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. After fixing&#xA;CVE-2023-3446 it was discovered that a large q parameter value can also trigger&#xA;an overly long computation during some of these checks. A correct q value,&#xA;if present, cannot be larger than the modulus p parameter, thus it is&#xA;unnecessary to perform these checks if q is larger than p.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulnerable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#34;-check&#34; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL&#xA;to crash leading to a potential Denial of Service attack&#xA;Impact summary: Applications loading files in the PKCS12 format from untrusted&#xA;sources might terminate abruptly.&#xA;A file in PKCS12 format can contain certificates and keys and may come from an&#xA;untrusted source. The PKCS12 specification allows certain fields to be NULL, but&#xA;OpenSSL does not correctly check for this case. This can lead to a NULL pointer&#xA;dereference that results in OpenSSL crashing. If an application processes PKCS12&#xA;files from an untrusted source using the OpenSSL APIs then that application will&#xA;be vulnerable to this issue.&#xA;OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),&#xA;PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()&#xA;and PKCS12_newpass().&#xA;We have also fixed a similar issue in SMIME_write_PKCS7(). However since this&#xA;function is related to writing data we do not consider it security significant.&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="16.u5.fos23" version="202011">
					<filename>edk2-devel-202011-16.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/edk2-devel-202011-16.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="16.u5.fos23" version="202011">
					<filename>python3-edk2-devel-202011-16.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-edk2-devel-202011-16.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="16.u5.fos23" version="202011">
					<filename>edk2-help-202011-16.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/edk2-help-202011-16.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="16.u5.fos23" version="202011">
					<filename>edk2-ovmf-202011-16.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/edk2-ovmf-202011-16.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="16.u5.fos23" version="202011">
					<filename>edk2-devel-202011-16.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/edk2-devel-202011-16.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="16.u5.fos23" version="202011">
					<filename>edk2-aarch64-202011-16.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/edk2-aarch64-202011-16.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2063</id>
		<title>An update for erlang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
		</references>
		<description>CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="erlang" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-asn1" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-asn1-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-common_test" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-common_test-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-compiler" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-compiler-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-crypto" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-crypto-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-debugger" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-debugger-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-dialyzer" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-dialyzer-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-diameter" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-diameter-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-edoc" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-edoc-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eldap" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-eldap-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_docgen" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-erl_docgen-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_interface" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-erl_interface-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erts" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-erts-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-et" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-et-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eunit" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-eunit-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-examples" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-examples-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ftp" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-ftp-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-hipe" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-hipe-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-inets" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-inets-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-jinterface" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-jinterface-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-kernel" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-kernel-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-megaco" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-megaco-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-mnesia" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-mnesia-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-observer" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-observer-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-odbc" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-odbc-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-os_mon" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-os_mon-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-parsetools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-parsetools-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-public_key" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-public_key-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-reltool" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-reltool-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-runtime_tools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-runtime_tools-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-sasl" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-sasl-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-snmp" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-snmp-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssh" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-ssh-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssl" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-ssl-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-stdlib" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-stdlib-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-syntax_tools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-syntax_tools-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tftp" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-tftp-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-tools-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-wx" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-wx-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-xmerl" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/erlang-xmerl-23.3.4.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-asn1" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-asn1-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-common_test" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-common_test-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-compiler" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-compiler-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-crypto" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-crypto-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-debugger" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-debugger-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-dialyzer" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-dialyzer-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-diameter" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-diameter-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-edoc" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-edoc-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eldap" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-eldap-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_docgen" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-erl_docgen-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_interface" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-erl_interface-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erts" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-erts-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-et" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-et-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eunit" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-eunit-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-examples" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-examples-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ftp" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-ftp-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-hipe" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-hipe-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-inets" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-inets-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-jinterface" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-jinterface-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-kernel" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-kernel-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-megaco" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-megaco-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-mnesia" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-mnesia-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-observer" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-observer-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-odbc" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-odbc-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-os_mon" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-os_mon-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-parsetools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-parsetools-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-public_key" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-public_key-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-reltool" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-reltool-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-runtime_tools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-runtime_tools-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-sasl" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-sasl-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-snmp" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-snmp-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssh" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-ssh-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssl" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-ssl-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-stdlib" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-stdlib-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-syntax_tools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-syntax_tools-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tftp" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-tftp-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tools" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-tools-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-wx" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-wx-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-xmerl" release="4.u2.fos23" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/erlang-xmerl-23.3.4.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2064</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7104" id="CVE-2023-7104" title="CVE-2023-7104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3479" id="CVE-2022-3479" title="CVE-2022-3479" type="cve"></reference>
		</references>
		<description>CVE-2023-7104:A vulnerability was found in SQLite SQLite3 up to 3.43.0 and classified as critical. This issue affects the function sessionReadRecord of the file ext/session/sqlite3session.c of the component make alltest Handler. The manipulation leads to heap-based buffer overflow. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-248999.&#xA;CVE-2022-3479:A vulnerability found in nss. By this security vulnerability, nss client auth crash without a user certificate in the database and this can lead us to a segmentation fault or crash.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="firefox" release="5.u5.fos23" version="102.15.0">
					<filename>firefox-102.15.0-5.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/firefox-102.15.0-5.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="firefox" release="5.u5.fos23" version="102.15.0">
					<filename>firefox-102.15.0-5.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/firefox-102.15.0-5.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2065</id>
		<title>An update for fontforge is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25081" id="CVE-2024-25081" title="CVE-2024-25081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25082" id="CVE-2024-25082" title="CVE-2024-25082" type="cve"></reference>
		</references>
		<description>CVE-2024-25081:Splinefont in FontForge through 20230101 allows command injection via crafted filenames.&#xA;CVE-2024-25082:Splinefont in FontForge through 20230101 allows command injection via crafted archives or compressed files.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="fontforge" release="8.u1.fos23" version="20200314">
					<filename>fontforge-20200314-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/fontforge-20200314-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fontforge-devel" release="8.u1.fos23" version="20200314">
					<filename>fontforge-devel-20200314-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/fontforge-devel-20200314-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="fontforge-help" release="8.u1.fos23" version="20200314">
					<filename>fontforge-help-20200314-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/fontforge-help-20200314-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fontforge" release="8.u1.fos23" version="20200314">
					<filename>fontforge-20200314-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/fontforge-20200314-8.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fontforge-devel" release="8.u1.fos23" version="20200314">
					<filename>fontforge-devel-20200314-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/fontforge-devel-20200314-8.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2066</id>
		<title>An update for freeglut is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24258" id="CVE-2024-24258" title="CVE-2024-24258" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24259" id="CVE-2024-24259" title="CVE-2024-24259" type="cve"></reference>
		</references>
		<description>CVE-2024-24258:freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function.&#xA;CVE-2024-24259:freeglut through 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddMenuEntry function.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="freeglut" release="12.u1.fos23" version="3.0.0">
					<filename>freeglut-3.0.0-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/freeglut-3.0.0-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeglut-devel" release="12.u1.fos23" version="3.0.0">
					<filename>freeglut-devel-3.0.0-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/freeglut-devel-3.0.0-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeglut-help" release="12.u1.fos23" version="3.0.0">
					<filename>freeglut-help-3.0.0-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/freeglut-help-3.0.0-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeglut" release="12.u1.fos23" version="3.0.0">
					<filename>freeglut-3.0.0-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/freeglut-3.0.0-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeglut-devel" release="12.u1.fos23" version="3.0.0">
					<filename>freeglut-devel-3.0.0-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/freeglut-devel-3.0.0-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeglut-help" release="12.u1.fos23" version="3.0.0">
					<filename>freeglut-help-3.0.0-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/freeglut-help-3.0.0-12.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2067</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46751" id="CVE-2023-46751" title="CVE-2023-46751" type="cve"></reference>
		</references>
		<description>CVE-2023-46751:An issue was discovered in the function gdev_prn_open_printer_seekable() in Artifex Ghostscript through 10.02.0 allows remote attackers to crash the application via a dangling pointer.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/ghostscript-9.55.0-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/ghostscript-devel-9.55.0-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/ghostscript-help-9.55.0-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/ghostscript-tools-dvipdf-9.55.0-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/ghostscript-9.55.0-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/ghostscript-devel-9.55.0-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="6.u5.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/ghostscript-tools-dvipdf-9.55.0-6.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2068</id>
		<title>An update for glade is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36774" id="CVE-2020-36774" title="CVE-2020-36774" type="cve"></reference>
		</references>
		<description>CVE-2020-36774:plugins/gtk+/glade-gtk-box.c in GNOME Glade before 3.38.1 and 3.39.x before 3.40.0 mishandles widget rebuilding for GladeGtkBox, leading to a denial of service (application crash).</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="glade" release="3.u1.fos23" version="3.36.0">
					<filename>glade-3.36.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glade-3.36.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glade-libs" release="3.u1.fos23" version="3.36.0">
					<filename>glade-libs-3.36.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glade-libs-3.36.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glade-devel" release="3.u1.fos23" version="3.36.0">
					<filename>glade-devel-3.36.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glade-devel-3.36.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glade-help" release="3.u1.fos23" version="3.36.0">
					<filename>glade-help-3.36.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glade-help-3.36.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glade" release="3.u1.fos23" version="3.36.0">
					<filename>glade-3.36.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glade-3.36.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glade-libs" release="3.u1.fos23" version="3.36.0">
					<filename>glade-libs-3.36.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glade-libs-3.36.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glade-devel" release="3.u1.fos23" version="3.36.0">
					<filename>glade-devel-3.36.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glade-devel-3.36.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2069</id>
		<title>An update for glusterfs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48340" id="CVE-2022-48340" title="CVE-2022-48340" type="cve"></reference>
		</references>
		<description>CVE-2022-48340:In Gluster GlusterFS 11.0, there is an xlators/cluster/dht/src/dht-common.c dht_setxattr_mds_cbk use-after-free.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="glusterfs" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-cli" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-cli-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-cli-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-cloudsync-plugins" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-cloudsync-plugins-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-cloudsync-plugins-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-extra-xlators" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-extra-xlators-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-extra-xlators-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-fuse" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-fuse-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-fuse-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-geo-replication" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-geo-replication-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-geo-replication-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libglusterfs0" release="9.u2.fos23" version="10.0">
					<filename>libglusterfs0-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libglusterfs0-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libglusterfs-devel" release="9.u2.fos23" version="10.0">
					<filename>libglusterfs-devel-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libglusterfs-devel-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfapi0" release="9.u2.fos23" version="10.0">
					<filename>libgfapi0-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfapi0-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfapi-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfapi-devel-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfapi-devel-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfchangelog0" release="9.u2.fos23" version="10.0">
					<filename>libgfchangelog0-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfchangelog0-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfchangelog-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfchangelog-devel-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfchangelog-devel-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfrpc0" release="9.u2.fos23" version="10.0">
					<filename>libgfrpc0-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfrpc0-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfrpc-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfrpc-devel-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfrpc-devel-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfxdr0" release="9.u2.fos23" version="10.0">
					<filename>libgfxdr0-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfxdr0-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgfxdr-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfxdr-devel-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libgfxdr-devel-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libglusterd0" release="9.u2.fos23" version="10.0">
					<filename>libglusterd0-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libglusterd0-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-gluster" release="9.u2.fos23" version="10.0">
					<filename>python3-gluster-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-gluster-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glusterfs-resource-agents" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-resource-agents-10.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-resource-agents-10.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-server" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-server-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-server-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-thin-arbiter" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-thin-arbiter-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-thin-arbiter-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-client-xlators" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-client-xlators-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-client-xlators-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glusterfs-events" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-events-10.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/glusterfs-events-10.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-cli" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-cli-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-cli-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-cloudsync-plugins" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-cloudsync-plugins-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-cloudsync-plugins-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-extra-xlators" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-extra-xlators-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-extra-xlators-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-fuse" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-fuse-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-fuse-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-geo-replication" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-geo-replication-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-geo-replication-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libglusterfs0" release="9.u2.fos23" version="10.0">
					<filename>libglusterfs0-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libglusterfs0-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libglusterfs-devel" release="9.u2.fos23" version="10.0">
					<filename>libglusterfs-devel-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libglusterfs-devel-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfapi0" release="9.u2.fos23" version="10.0">
					<filename>libgfapi0-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfapi0-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfapi-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfapi-devel-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfapi-devel-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfchangelog0" release="9.u2.fos23" version="10.0">
					<filename>libgfchangelog0-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfchangelog0-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfchangelog-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfchangelog-devel-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfchangelog-devel-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfrpc0" release="9.u2.fos23" version="10.0">
					<filename>libgfrpc0-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfrpc0-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfrpc-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfrpc-devel-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfrpc-devel-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfxdr0" release="9.u2.fos23" version="10.0">
					<filename>libgfxdr0-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfxdr0-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgfxdr-devel" release="9.u2.fos23" version="10.0">
					<filename>libgfxdr-devel-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libgfxdr-devel-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libglusterd0" release="9.u2.fos23" version="10.0">
					<filename>libglusterd0-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libglusterd0-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-gluster" release="9.u2.fos23" version="10.0">
					<filename>python3-gluster-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/python3-gluster-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-server" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-server-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-server-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-thin-arbiter" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-thin-arbiter-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-thin-arbiter-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-client-xlators" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-client-xlators-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-client-xlators-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glusterfs-events" release="9.u2.fos23" version="10.0">
					<filename>glusterfs-events-10.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/glusterfs-events-10.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2070</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39326" id="CVE-2023-39326" title="CVE-2023-39326" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45285" id="CVE-2023-45285" title="CVE-2023-45285" type="cve"></reference>
		</references>
		<description>CVE-2023-39326:A malicious HTTP sender can use chunk extensions to cause a receiver reading from a request or response body to read many more bytes from the network than are in the body. A malicious HTTP client can further exploit this to cause a server to automatically read a large amount of data (up to about 1GiB) when a handler fails to read the entire body of a request. Chunk extensions are a little-used HTTP feature which permit including additional metadata in a request or response body sent using the chunked encoding. The net/http chunked encoding reader discards this metadata. A sender can exploit this by inserting a large metadata segment with each byte transferred. The chunk reader now produces an error if the ratio of real body to encoded bytes grows too small.&#xA;CVE-2023-45285:Using go get to fetch a module with the &#34;.git&#34; suffix may unexpectedly fallback to the insecure &#34;git://&#34; protocol if the module is unavailable via the secure &#34;https://&#34; and &#34;git+ssh://&#34; protocols, even if GOINSECURE is not set for said module. This only affects users who are not using the module proxy and are fetching modules directly (i.e. GOPROXY=off).</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u8.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/golang-1.20.5-3.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u8.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/golang-help-1.20.5-3.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u8.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/golang-devel-1.20.5-3.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u8.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/golang-1.20.5-3.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2071</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1048" id="CVE-2024-1048" title="CVE-2024-1048" type="cve"></reference>
		</references>
		<description>CVE-2024-1048:A flaw was found in the grub2-set-bootflag utility of grub2. After the fix of CVE-2019-14865, grub2-set-bootflag will create a temporary file with the new grubenv content and rename it to the original grubenv file. If the program is killed before the rename operation, the temporary file will not be removed and may fill the filesystem when invoked multiple times, resulting in a filesystem out of free inodes or blocks.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="1" name="grub2-common" release="41.u13.fos23" version="2.06">
					<filename>grub2-common-2.06-41.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-common-2.06-41.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-tools-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-minimal" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-minimal-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-tools-minimal-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-extra" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-extra-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-tools-extra-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-efi" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-efi-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-tools-efi-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64" release="41.u13.fos23" version="2.06">
					<filename>grub2-efi-x64-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-efi-x64-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-x64-modules" release="41.u13.fos23" version="2.06">
					<filename>grub2-efi-x64-modules-2.06-41.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-efi-x64-modules-2.06-41.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64-cdboot" release="41.u13.fos23" version="2.06">
					<filename>grub2-efi-x64-cdboot-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-efi-x64-cdboot-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32" release="41.u13.fos23" version="2.06">
					<filename>grub2-efi-ia32-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-efi-ia32-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-ia32-modules" release="41.u13.fos23" version="2.06">
					<filename>grub2-efi-ia32-modules-2.06-41.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-efi-ia32-modules-2.06-41.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32-cdboot" release="41.u13.fos23" version="2.06">
					<filename>grub2-efi-ia32-cdboot-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-efi-ia32-cdboot-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-pc" release="41.u13.fos23" version="2.06">
					<filename>grub2-pc-2.06-41.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-pc-2.06-41.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-pc-modules" release="41.u13.fos23" version="2.06">
					<filename>grub2-pc-modules-2.06-41.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-pc-modules-2.06-41.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-help" release="41.u13.fos23" version="2.06">
					<filename>grub2-help-2.06-41.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/grub2-help-2.06-41.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-2.06-41.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/grub2-tools-2.06-41.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-minimal" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-minimal-2.06-41.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/grub2-tools-minimal-2.06-41.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-extra" release="41.u13.fos23" version="2.06">
					<filename>grub2-tools-extra-2.06-41.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/grub2-tools-extra-2.06-41.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2072</id>
		<title>An update for gstreamer1-plugins-good is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"></reference>
		</references>
		<description>CVE-2023-37327:A heap-based buffer overflow vulnerability was found in the FLAC parser in GStreamer. This issue occurs when processing malformed image tags, which could allow a malicious third party to induce a crash in the application and potentially execute code by manipulating the heap.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/gstreamer1-plugins-good-1.16.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good-gtk" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/gstreamer1-plugins-good-gtk-1.16.2-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-good-help" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-help-1.16.2-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/gstreamer1-plugins-good-help-1.16.2-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/gstreamer1-plugins-good-1.16.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good-gtk" release="6.u2.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/gstreamer1-plugins-good-gtk-1.16.2-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2073</id>
		<title>An update for hdf5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17433" id="CVE-2018-17433" title="CVE-2018-17433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17436" id="CVE-2018-17436" title="CVE-2018-17436" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10809" id="CVE-2020-10809" title="CVE-2020-10809" type="cve"></reference>
		</references>
		<description>CVE-2018-17433:A heap-based buffer overflow in ReadGifImageDesc() in gifread.c in the HDF HDF5 through 1.10.3 library allows attackers to cause a denial of service via a crafted HDF5 file. This issue was triggered while converting a GIF file to an HDF file.&#xA;CVE-2018-17436:ReadCode() in decompress.c in the HDF HDF5 through 1.10.3 library allows attackers to cause a denial of service (invalid write access) via a crafted HDF5 file. This issue was triggered while converting a GIF file to an HDF file.&#xA;CVE-2020-10809:An issue was discovered in HDF5 through 1.12.0. A heap-based buffer overflow exists in the function Decompress() located in decompress.c. It can be triggered by sending a crafted file to the gif2h5 binary. It allows an attacker to cause Denial of Service.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="hdf5" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-devel" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-devel-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-devel-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-mpich-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-mpich-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-devel" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-mpich-devel-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-mpich-devel-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-static" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-mpich-static-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-mpich-static-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-openmpi-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-openmpi-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-devel" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-openmpi-devel-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-openmpi-devel-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-static" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-openmpi-static-1.12.1-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/hdf5-openmpi-static-1.12.1-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-devel" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-devel-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-devel-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-mpich-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-mpich-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-devel" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-mpich-devel-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-mpich-devel-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-static" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-mpich-static-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-mpich-static-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-openmpi-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-openmpi-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-devel" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-openmpi-devel-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-openmpi-devel-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-static" release="6.u4.fos23" version="1.12.1">
					<filename>hdf5-openmpi-static-1.12.1-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/hdf5-openmpi-static-1.12.1-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2074</id>
		<title>An update for jackson-databind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36518" id="CVE-2020-36518" title="CVE-2020-36518" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42003" id="CVE-2022-42003" title="CVE-2022-42003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"></reference>
		</references>
		<description>CVE-2020-36518:jackson-databind before 2.13.0 allows a Java StackOverflow exception and denial of service via a large depth of nested objects.&#xA;CVE-2022-42003:In FasterXML jackson-databind before versions 2.13.4.1 and 2.12.17.1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled.&#xA;CVE-2022-42004:In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="jackson-databind" release="10.u5.fos23" version="2.9.8">
					<filename>jackson-databind-2.9.8-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jackson-databind-2.9.8-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jackson-databind-javadoc" release="10.u5.fos23" version="2.9.8">
					<filename>jackson-databind-javadoc-2.9.8-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jackson-databind-javadoc-2.9.8-10.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2075</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"></reference>
		</references>
		<description>CVE-2024-20918:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2024-20919:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.9 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).&#xA;CVE-2024-20952:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2024-20945:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20921:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20926:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Scripting).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21; Oracle GraalVM for JDK: 17.0.9; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-headless-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-headless-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-headless-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-headless-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-devel-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-devel-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-devel-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-devel-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-jmods-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-jmods-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-jmods-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-demo-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-demo-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-demo-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-demo-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-src-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-src-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-src-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-src-slowdebug-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-javadoc-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-javadoc-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-javadoc-zip-11.0.22.7-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/java-11-openjdk-javadoc-zip-11.0.22.7-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-headless-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-headless-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-headless-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-headless-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-devel-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-devel-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-devel-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-devel-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-jmods-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-jmods-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-jmods-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-demo-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-demo-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-demo-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-demo-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-src-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-src-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-src-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-src-slowdebug-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-javadoc-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-javadoc-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.22.7">
					<filename>java-11-openjdk-javadoc-zip-11.0.22.7-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/java-11-openjdk-javadoc-zip-11.0.22.7-0.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2076</id>
		<title>An update for jersey is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28168" id="CVE-2021-28168" title="CVE-2021-28168" type="cve"></reference>
		</references>
		<description>CVE-2021-28168:Eclipse Jersey 2.28 to 2.33 and Eclipse Jersey 3.0.0 to 3.0.1 contains a local information disclosure vulnerability. This is due to the use of the File.createTempFile which creates a file inside of the system temporary directory with the permissions: -rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system. As such, if the contents written is security sensitive, it can be disclosed to other local users.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="jersey" release="2.u2.fos23" version="2.29.1">
					<filename>jersey-2.29.1-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jersey-2.29.1-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jersey-test-framework" release="2.u2.fos23" version="2.29.1">
					<filename>jersey-test-framework-2.29.1-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jersey-test-framework-2.29.1-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jersey-javadoc" release="2.u2.fos23" version="2.29.1">
					<filename>jersey-javadoc-2.29.1-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jersey-javadoc-2.29.1-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2077</id>
		<title>An update for jruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28756" id="CVE-2023-28756" title="CVE-2023-28756" type="cve"></reference>
		</references>
		<description>CVE-2023-28756:A ReDoS issue was discovered in the Time component through 0.2.1 in Ruby through 3.2.1. The Time parser mishandles invalid URLs that have specific characters. It causes an increase in execution time for parsing strings to Time objects. The fixed versions are 0.1.1 and 0.2.2.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="jruby" release="4.u3.fos23" version="1.7.22">
					<filename>jruby-1.7.22-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jruby-1.7.22-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jruby-devel" release="4.u3.fos23" version="1.7.22">
					<filename>jruby-devel-1.7.22-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jruby-devel-1.7.22-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jruby-javadoc" release="4.u3.fos23" version="1.7.22">
					<filename>jruby-javadoc-1.7.22-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jruby-javadoc-1.7.22-4.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2078</id>
		<title>An update for json-path is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51074" id="CVE-2023-51074" title="CVE-2023-51074" type="cve"></reference>
		</references>
		<description>CVE-2023-51074:json-path v2.8.0 was discovered to contain a stack overflow via the Criteria.parse() method.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="json-path" release="2.u1.fos23" version="2.1.0">
					<filename>json-path-2.1.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/json-path-2.1.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="json-path-javadoc" release="2.u1.fos23" version="2.1.0">
					<filename>json-path-javadoc-2.1.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/json-path-javadoc-2.1.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2079</id>
		<title>An update for jsoup is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36033" id="CVE-2022-36033" title="CVE-2022-36033" type="cve"></reference>
		</references>
		<description>CVE-2022-36033:jsoup is a Java HTML parser, built for HTML editing, cleaning, scraping, and cross-site scripting (XSS) safety. jsoup may incorrectly sanitize HTML including `javascript:` URL expressions, which could allow XSS attacks when a reader subsequently clicks that link. If the non-default `SafeList.preserveRelativeLinks` option is enabled, HTML including `javascript:` URLs that have been crafted with control characters will not be sanitized. If the site that this HTML is published on does not set a Content Security Policy, an XSS attack is then possible. This issue is patched in jsoup 1.15.3. Users should upgrade to this version. Additionally, as the unsanitized input may have been persisted, old content should be cleaned again using the updated version. To remediate this issue without immediately upgrading: - disable `SafeList.preserveRelativeLinks`, which will rewrite input URLs as absolute URLs - ensure an appropriate [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is defined. (This should be used regardless of upgrading, as a defence-in-depth best practice.)</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="jsoup" release="2.u1.fos23" version="1.14.2">
					<filename>jsoup-1.14.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/jsoup-1.14.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2080</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23850" id="CVE-2024-23850" title="CVE-2024-23850" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7042" id="CVE-2023-7042" title="CVE-2023-7042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52560" id="CVE-2023-52560" title="CVE-2023-52560" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6531" id="CVE-2023-6531" title="CVE-2023-6531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0607" id="CVE-2024-0607" title="CVE-2024-0607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6040" id="CVE-2023-6040" title="CVE-2023-6040" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0641" id="CVE-2024-0641" title="CVE-2024-0641" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0565" id="CVE-2024-0565" title="CVE-2024-0565" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0340" id="CVE-2024-0340" title="CVE-2024-0340" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22705" id="CVE-2024-22705" title="CVE-2024-22705" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46343" id="CVE-2023-46343" title="CVE-2023-46343" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51042" id="CVE-2023-51042" title="CVE-2023-51042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6915" id="CVE-2023-6915" title="CVE-2023-6915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51043" id="CVE-2023-51043" title="CVE-2023-51043" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52340" id="CVE-2023-52340" title="CVE-2023-52340" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23849" id="CVE-2024-23849" title="CVE-2024-23849" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46838" id="CVE-2023-46838" title="CVE-2023-46838" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0639" id="CVE-2024-0639" title="CVE-2024-0639" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1086" id="CVE-2024-1086" title="CVE-2024-1086" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0841" id="CVE-2024-0841" title="CVE-2024-0841" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52435" id="CVE-2023-52435" title="CVE-2023-52435" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23196" id="CVE-2024-23196" title="CVE-2024-23196" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50431" id="CVE-2023-50431" title="CVE-2023-50431" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6560" id="CVE-2023-6560" title="CVE-2023-6560" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6622" id="CVE-2023-6622" title="CVE-2023-6622" type="cve"></reference>
		</references>
		<description>CVE-2024-23850:In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.&#xA;CVE-2023-7042:A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.&#xA;CVE-2023-52560:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()&#xA;When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y&#xA;and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.&#xA;Since commit 9f86d624292c (&#34;mm/damon/vaddr-test: remove unnecessary&#xA;variables&#34;), the damon_destroy_ctx() is removed, but still call&#xA;damon_new_target() and damon_new_region(), the damon_region which is&#xA;allocated by kmem_cache_alloc() in damon_new_region() and the damon_target&#xA;which is allocated by kmalloc in damon_new_target() are not freed.  And&#xA;the damon_region which is allocated in damon_new_region() in&#xA;damon_set_regions() is also not freed.&#xA;So use damon_destroy_target to free all the damon_regions and damon_target.&#xA;    unreferenced object 0xffff888107c9a940 (size 64):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1069, jiffies 4294670592 (age 732.761s)&#xA;      hex dump (first 32 bytes):&#xA;        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk&#xA;        60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff  `...............&#xA;      backtrace:&#xA;        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0&#xA;        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0&#xA;        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0&#xA;        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20&#xA;    unreferenced object 0xffff8881079cc740 (size 56):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1069, jiffies 4294670592 (age 732.761s)&#xA;      hex dump (first 32 bytes):&#xA;        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................&#xA;        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk&#xA;      backtrace:&#xA;        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0&#xA;        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0&#xA;        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20&#xA;    unreferenced object 0xffff888107c9ac40 (size 64):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1071, jiffies 4294670595 (age 732.843s)&#xA;      hex dump (first 32 bytes):&#xA;        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk&#xA;        a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff  ........x.v.....&#xA;      backtrace:&#xA;        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0&#xA;        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0&#xA;        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0&#xA;        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20&#xA;    unreferenced object 0xffff8881079ccc80 (size 56):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1071, jiffies 4294670595 (age 732.843s)&#xA;      hex dump (first 32 bytes):&#xA;        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................&#xA;        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk&#xA;      backtrace:&#xA;        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0&#xA;        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0&#xA;        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffff&#xA;---truncated---&#xA;CVE-2023-6531:A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector&#39;s deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on.&#xA;CVE-2024-0607:A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.&#xA;CVE-2023-6040:An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access.&#xA;CVE-2024-0641:A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.&#xA;CVE-2024-0565:An out-of-bounds memory read flaw was found in receive_encrypted_standard in fs/smb/client/smb2ops.c in the SMB Client sub-component in the Linux Kernel. This issue occurs due to integer underflow on the memcpy length, leading to a denial of service.&#xA;CVE-2024-0340:A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.&#xA;CVE-2024-22705:An issue was discovered in ksmbd in the Linux kernel before 6.6.10. smb2_get_data_area_len in fs/smb/server/smb2misc.c can cause an smb_strndup_from_utf16 out-of-bounds access because the relationship between Name data and CreateContexts data is mishandled.&#xA;CVE-2023-46343:In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.&#xA;CVE-2023-51042:In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.&#xA;CVE-2023-6915:A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.&#xA;CVE-2023-51043:In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.&#xA;CVE-2023-52340:A flaw in the routing table size was found in the ICMPv6 handling of &#34;Packet Too Big&#34;. The size of the routing table is regulated by periodic garbage collection. However, with &#34;Packet Too Big Messages&#34; it is possible to exceed the routing table size and garbage collector threshold. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%.&#xA;CVE-2024-23849:In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.&#xA;CVE-2023-46838:Transmit requests in Xen&#39;s virtual network protocol can consist of&#xA;multiple parts.  While not really useful, except for the initial part&#xA;any of them may be of zero length, i.e. carry no data at all.  Besides a&#xA;certain initial portion of the to be transferred data, these parts are&#xA;directly translated into what Linux calls SKB fragments.  Such converted&#xA;request parts can, when for a particular SKB they are all of length&#xA;zero, lead to a de-reference of NULL in core networking code.&#xA;CVE-2024-0639:A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.&#xA;CVE-2024-1086:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.&#xA;The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT.&#xA;We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.&#xA;CVE-2024-0841:A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.&#xA;CVE-2023-52435:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: prevent mss overflow in skb_segment()&#xA;Once again syzbot is able to crash the kernel in skb_segment() [1]&#xA;GSO_BY_FRAGS is a forbidden value, but unfortunately the following&#xA;computation in skb_segment() can reach it quite easily :&#xA;&#x9;mss = mss * partial_segs;&#xA;65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to&#xA;a bad final result.&#xA;Make sure to limit segmentation so that the new mss value is smaller&#xA;than GSO_BY_FRAGS.&#xA;[1]&#xA;general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN&#xA;KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]&#xA;CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023&#xA;RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551&#xA;Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00&#xA;RSP: 0018:ffffc900043473d0 EFLAGS: 00010202&#xA;RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597&#xA;RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070&#xA;RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff&#xA;R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0&#xA;R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046&#xA;FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109&#xA;ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120&#xA;skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53&#xA;__skb_gso_segment+0x339/0x710 net/core/gso.c:124&#xA;skb_gso_segment include/net/gso.h:83 [inline]&#xA;validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626&#xA;__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338&#xA;dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA;packet_xmit+0x257/0x380 net/packet/af_packet.c:276&#xA;packet_snd net/packet/af_packet.c:3087 [inline]&#xA;packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119&#xA;sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;__sock_sendmsg+0xd5/0x180 net/socket.c:745&#xA;__sys_sendto+0x255/0x340 net/socket.c:2190&#xA;__do_sys_sendto net/socket.c:2202 [inline]&#xA;__se_sys_sendto net/socket.c:2198 [inline]&#xA;__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198&#xA;do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83&#xA;entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;RIP: 0033:0x7f8692032aa9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c&#xA;RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9&#xA;RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003&#xA;RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480&#xA;R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003&#xA;&lt;/TASK&gt;&#xA;Modules linked in:&#xA;---[ end trace 0000000000000000 ]---&#xA;RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551&#xA;Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00&#xA;RSP: 0018:ffffc900043473d0 EFLAGS: 00010202&#xA;RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597&#xA;RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070&#xA;RBP: ffffc90004347578 R0&#xA;---truncated---&#xA;CVE-2024-23196:A race condition was found in the Linux kernel&#39;s sound/hda  device driver in snd_hdac_regmap_sync() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.&#xA;CVE-2023-50431:sec_attest_info in drivers/accel/habanalabs/common/habanalabs_ioctl.c in the Linux kernel through 6.6.5 allows an information leak to user space because info-&gt;pad0 is not initialized.&#xA;CVE-2023-6560:An out-of-bounds memory access flaw was found in the io_uring SQ/CQ rings functionality in the Linux kernel. This issue could allow a local user to crash the system.&#xA;CVE-2023-6622:A null pointer dereference vulnerability was found in nft_dynset_init() in net/netfilter/nft_dynset.c in nf_tables in the Linux kernel. This issue may allow a local attacker with CAP_NET_ADMIN user privilege to trigger a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/kernel-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/kernel-headers-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/kernel-devel-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/kernel-tools-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/kernel-tools-devel-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/perf-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-perf-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/bpftool-5.10.0-136.65.0.145.u108.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/kernel-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/kernel-headers-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/kernel-devel-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/kernel-tools-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/kernel-tools-devel-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/perf-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/python3-perf-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.65.0.145.u108.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/bpftool-5.10.0-136.65.0.145.u108.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2081</id>
		<title>An update for less is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48624" id="CVE-2022-48624" title="CVE-2022-48624" type="cve"></reference>
		</references>
		<description>CVE-2022-48624:close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="less" release="5.u2.fos23" version="590">
					<filename>less-590-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/less-590-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="less-help" release="5.u2.fos23" version="590">
					<filename>less-help-590-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/less-help-590-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="less" release="5.u2.fos23" version="590">
					<filename>less-590-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/less-590-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2082</id>
		<title>An update for libexif is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-0452" id="CVE-2020-0452" title="CVE-2020-0452" type="cve"></reference>
		</references>
		<description>CVE-2020-0452:In exif_entry_get_value of exif-entry.c, there is a possible out of bounds write due to an integer overflow. This could lead to remote code execution if a third party app used this library to process remote image data with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.1 Android-9 Android-10 Android-11 Android-8.0Android ID: A-159625731</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="libexif" release="5.u3.fos23" version="0.6.22">
					<filename>libexif-0.6.22-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libexif-0.6.22-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libexif-devel" release="5.u3.fos23" version="0.6.22">
					<filename>libexif-devel-0.6.22-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libexif-devel-0.6.22-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libexif-help" release="5.u3.fos23" version="0.6.22">
					<filename>libexif-help-0.6.22-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libexif-help-0.6.22-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libexif" release="5.u3.fos23" version="0.6.22">
					<filename>libexif-0.6.22-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libexif-0.6.22-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libexif-devel" release="5.u3.fos23" version="0.6.22">
					<filename>libexif-devel-0.6.22-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libexif-devel-0.6.22-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2083</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
		</references>
		<description>CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="libssh" release="9.u4.fos23" version="0.9.6">
					<filename>libssh-0.9.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libssh-0.9.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="9.u4.fos23" version="0.9.6">
					<filename>libssh-devel-0.9.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libssh-devel-0.9.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="9.u4.fos23" version="0.9.6">
					<filename>libssh-help-0.9.6-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libssh-help-0.9.6-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="9.u4.fos23" version="0.9.6">
					<filename>libssh-0.9.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libssh-0.9.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="9.u4.fos23" version="0.9.6">
					<filename>libssh-devel-0.9.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libssh-devel-0.9.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2084</id>
		<title>An update for libssh2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
		</references>
		<description>CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="libssh2" release="5.u3.fos23" version="1.10.0">
					<filename>libssh2-1.10.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libssh2-1.10.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh2-devel" release="5.u3.fos23" version="1.10.0">
					<filename>libssh2-devel-1.10.0-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libssh2-devel-1.10.0-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh2-help" release="5.u3.fos23" version="1.10.0">
					<filename>libssh2-help-1.10.0-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libssh2-help-1.10.0-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh2" release="5.u3.fos23" version="1.10.0">
					<filename>libssh2-1.10.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libssh2-1.10.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh2-devel" release="5.u3.fos23" version="1.10.0">
					<filename>libssh2-devel-1.10.0-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libssh2-devel-1.10.0-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2085</id>
		<title>An update for libuv is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24806" id="CVE-2024-24806" title="CVE-2024-24806" type="cve"></reference>
		</references>
		<description>CVE-2024-24806:libuv is a multi-platform support library with a focus on asynchronous I/O. The `uv_getaddrinfo` function in `src/unix/getaddrinfo.c` (and its windows counterpart `src/win/getaddrinfo.c`), truncates hostnames to 256 characters before calling `getaddrinfo`. This behavior can be exploited to create addresses like `0x00007f000001`, which are considered valid by `getaddrinfo` and could allow an attacker to craft payloads that resolve to unintended IP addresses, bypassing developer checks. The vulnerability arises due to how the `hostname_ascii` variable (with a length of 256 bytes) is handled in `uv_getaddrinfo` and subsequently in `uv__idna_toascii`. When the hostname exceeds 256 characters, it gets truncated without a terminating null byte. As a result attackers may be able to access internal APIs or for websites (similar to MySpace) that allows users to have `username.example.com` pages. Internal services that crawl or cache these user pages can be exposed to SSRF attacks if a malicious user chooses a long vulnerable username. This issue has been addressed in release version 1.48.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="1" name="libuv" release="8.u2.fos23" version="1.42.0">
					<filename>libuv-1.42.0-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libuv-1.42.0-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="libuv-devel" release="8.u2.fos23" version="1.42.0">
					<filename>libuv-devel-1.42.0-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libuv-devel-1.42.0-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="libuv-help" release="8.u2.fos23" version="1.42.0">
					<filename>libuv-help-1.42.0-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libuv-help-1.42.0-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libuv" release="8.u2.fos23" version="1.42.0">
					<filename>libuv-1.42.0-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libuv-1.42.0-8.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libuv-devel" release="8.u2.fos23" version="1.42.0">
					<filename>libuv-devel-1.42.0-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libuv-devel-1.42.0-8.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2086</id>
		<title>An update for linux-sgx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
		</references>
		<description>CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and&#xA;decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data.&#xA;If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are&#xA;populated with pointers to buffers containing the relevant decoded data. The&#xA;caller is responsible for freeing those buffers. It is possible to construct a&#xA;PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex()&#xA;will return a failure code but will populate the header argument with a pointer&#xA;to a buffer that has already been freed. If the caller also frees this buffer&#xA;then a double free will occur. This will most likely lead to a crash. This&#xA;could be exploited by an attacker who has the ability to supply malicious PEM&#xA;files for parsing to achieve a denial of service attack.&#xA;The functions PEM_read_bio() and PEM_read() are simple wrappers around&#xA;PEM_read_bio_ex() and therefore these functions are also directly affected.&#xA;These functions are also called indirectly by a number of other OpenSSL&#xA;functions including PEM_X509_INFO_read_bio_ex() and&#xA;SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal&#xA;uses of these functions are not vulnerable because the caller does not free the&#xA;header argument if PEM_read_bio_ex() returns a failure code. These locations&#xA;include the PEM_read_bio_TYPE() functions as well as the decoders introduced in&#xA;OpenSSL 3.0.&#xA;The OpenSSL asn1parse command line application is also impacted by this issue.&#xA;CVE-2023-0215:The public API function BIO_new_NDEF is a helper function used for streaming&#xA;ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the&#xA;SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by&#xA;end user applications.&#xA;The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter&#xA;BIO onto the front of it to form a BIO chain, and then returns the new head of&#xA;the BIO chain to the caller. Under certain conditions, for example if a CMS&#xA;recipient public key is invalid, the new filter BIO is freed and the function&#xA;returns a NULL result indicating a failure. However, in this case, the BIO chain&#xA;is not properly cleaned up and the BIO passed by the caller still retains&#xA;internal pointers to the previously freed filter BIO. If the caller then goes on&#xA;to call BIO_pop() on the BIO then a use-after-free will occur. This will most&#xA;likely result in a crash.&#xA;This scenario occurs directly in the internal function B64_write_ASN1() which&#xA;may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on&#xA;the BIO. This internal function is in turn called by the public API functions&#xA;PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream,&#xA;SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7.&#xA;Other public API functions that may be impacted by this include&#xA;i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and&#xA;i2d_PKCS7_bio_stream.&#xA;The OpenSSL cms and smime command line applications are similarly affected.&#xA;CVE-2023-0286:There is a type confusion vulnerability relating to X.400 address processing&#xA;inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but&#xA;the public structure definition for GENERAL_NAME incorrectly specified the type&#xA;of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by&#xA;the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an&#xA;ASN1_STRING.&#xA;When CRL checking is enabled (i.e. the application sets the&#xA;X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass&#xA;arbitrary pointers to a memcmp call, enabling them to read memory contents or&#xA;enact a denial of service. In most cases, the attack requires the attacker to&#xA;provide both the certificate chain and CRL, neither of which need to have a&#xA;valid signature. If the attacker only controls one of these inputs, the other&#xA;input must already contain an X.400 address as a CRL distribution point, which&#xA;is uncommon. As such, this vulnerability is most likely to only affect&#xA;applications which have implemented their own functionality for retrieving CRLs&#xA;over a network.&#xA;CVE-2023-0464:A security vulnerability has been identified in all supported versions&#xA;of OpenSSL related to the verification of X.509 certificate chains&#xA;that include policy constraints.  Attackers may be able to exploit this&#xA;vulnerability by creating a malicious certificate chain that triggers&#xA;exponential use of computational resources, leading to a denial-of-service&#xA;(DoS) attack on affected systems.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0465:Applications that use a non-default option when verifying certificates may be&#xA;vulnerable to an attack from a malicious CA to circumvent certain checks.&#xA;Invalid certificate policies in leaf certificates are silently ignored by&#xA;OpenSSL and other certificate policy checks are skipped for that certificate.&#xA;A malicious CA could use this to deliberately assert invalid certificate policies&#xA;in order to circumvent policy checking on the certificate altogether.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0466:The function X509_VERIFY_PARAM_add0_policy() is documented to&#xA;implicitly enable the certificate policy check when doing certificate&#xA;verification. However the implementation of the function does not&#xA;enable the check which allows certificates with invalid or incorrect&#xA;policies to pass the certificate verification.&#xA;As suddenly enabling the policy check could break existing deployments it was&#xA;decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy()&#xA;function.&#xA;Instead the applications that require OpenSSL to perform certificate&#xA;policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly&#xA;enable the policy check by calling X509_VERIFY_PARAM_set_flags() with&#xA;the X509_V_FLAG_POLICY_CHECK flag argument.&#xA;Certificate policy checks are disabled by default in OpenSSL and are not&#xA;commonly used by applications.&#xA;CVE-2023-2650:Issue summary: Processing some specially crafted ASN.1 object identifiers or&#xA;data containing them may be very slow.&#xA;Impact summary: Applications that use OBJ_obj2txt() directly, or use any of&#xA;the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message&#xA;size limit may experience notable to very long delays when processing those&#xA;messages, which may lead to a Denial of Service.&#xA;An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -&#xA;most of which have no size limit.  OBJ_obj2txt() may be used to translate&#xA;an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL&#xA;type ASN1_OBJECT) to its canonical numeric text form, which are the&#xA;sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by&#xA;periods.&#xA;When one of the sub-identifiers in the OBJECT IDENTIFIER is very large&#xA;(these are sizes that are seen as absurdly large, taking up tens or hundreds&#xA;of KiBs), the translation to a decimal number in text may take a very long&#xA;time.  The time complexity is O(n^2) with &#39;n&#39; being the size of the&#xA;sub-identifiers in bytes (*).&#xA;With OpenSSL 3.0, support to fetch cryptographic algorithms using names /&#xA;identifiers in string form was introduced.  This includes using OBJECT&#xA;IDENTIFIERs in canonical numeric text form as identifiers for fetching&#xA;algorithms.&#xA;Such OBJECT IDENTIFIERs may be received through the ASN.1 structure&#xA;AlgorithmIdentifier, which is commonly used in multiple protocols to specify&#xA;what cryptographic algorithm should be used to sign or verify, encrypt or&#xA;decrypt, or digest passed data.&#xA;Applications that call OBJ_obj2txt() directly with untrusted data are&#xA;affected, with any version of OpenSSL.  If the use is for the mere purpose&#xA;of display, the severity is considered low.&#xA;In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,&#xA;CMS, CMP/CRMF or TS.  It also impacts anything that processes X.509&#xA;certificates, including simple things like verifying its signature.&#xA;The impact on TLS is relatively low, because all versions of OpenSSL have a&#xA;100KiB limit on the peer&#39;s certificate chain.  Additionally, this only&#xA;impacts clients, or servers that have explicitly enabled client&#xA;authentication.&#xA;In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,&#xA;such as X.509 certificates.  This is assumed to not happen in such a way&#xA;that it would cause a Denial of Service, so these versions are considered&#xA;not affected by this issue in such a way that it would be cause for concern,&#xA;and the severity is therefore considered low.&#xA;CVE-2023-3446:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. One of those&#xA;checks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to use&#xA;a very large modulus is slow and OpenSSL will not normally use a modulus which&#xA;is over 10,000 bits in length.&#xA;However the DH_check() function checks numerous aspects of the key or parameters&#xA;that have been supplied. Some of those checks use the supplied modulus value&#xA;even if it has already been found to be too large.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulernable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#39;-check&#39; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2023-3817:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. After fixing&#xA;CVE-2023-3446 it was discovered that a large q parameter value can also trigger&#xA;an overly long computation during some of these checks. A correct q value,&#xA;if present, cannot be larger than the modulus p parameter, thus it is&#xA;unnecessary to perform these checks if q is larger than p.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulnerable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#34;-check&#34; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2023-5678:Issue summary: Generating excessively long X9.42 DH keys or checking&#xA;excessively long X9.42 DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_generate_key() to&#xA;generate an X9.42 DH key may experience long delays.  Likewise, applications&#xA;that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()&#xA;to check an X9.42 DH key or X9.42 DH parameters may experience long delays.&#xA;Where the key or parameters that are being checked have been obtained from&#xA;an untrusted source this may lead to a Denial of Service.&#xA;While DH_check() performs all the necessary checks (as of CVE-2023-3817),&#xA;DH_check_pub_key() doesn&#39;t make any of these checks, and is therefore&#xA;vulnerable for excessively large P and Q parameters.&#xA;Likewise, while DH_generate_key() performs a check for an excessively large&#xA;P, it doesn&#39;t check for an excessively large Q.&#xA;An application that calls DH_generate_key() or DH_check_pub_key() and&#xA;supplies a key or parameters obtained from an untrusted source could be&#xA;vulnerable to a Denial of Service attack.&#xA;DH_generate_key() and DH_check_pub_key() are also called by a number of&#xA;other OpenSSL functions.  An application calling any of those other&#xA;functions may similarly be affected.  The other functions affected by this&#xA;are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().&#xA;Also vulnerable are the OpenSSL pkey command line application when using the&#xA;&#34;-pubcheck&#34; option, as well as the OpenSSL genpkey command line application.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2022-4304:A timing based side channel exists in the OpenSSL RSA Decryption implementation&#xA;which could be sufficient to recover a plaintext across a network in a&#xA;Bleichenbacher style attack. To achieve a successful decryption an attacker&#xA;would have to be able to send a very large number of trial messages for&#xA;decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5,&#xA;RSA-OEAP and RSASVE.&#xA;For example, in a TLS connection, RSA is commonly used by a client to send an&#xA;encrypted pre-master secret to the server. An attacker that had observed a&#xA;genuine connection between a client and a server could use this flaw to send&#xA;trial messages to the server and record the time taken to process them. After a&#xA;sufficiently large number of messages the attacker could recover the pre-master&#xA;secret used for the original connection and thus be able to decrypt the&#xA;application data sent over that connection.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="sgxsdk" release="11.u2.fos23" version="2.15.1">
					<filename>sgxsdk-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/sgxsdk-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qe3" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ae-qe3-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ae-qe3-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-pce-logic" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-pce-logic-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-pce-logic-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-qe3-logic" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-qe3-logic-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-qe3-logic-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-aesm-service" release="11.u2.fos23" version="2.15.1">
					<filename>sgx-aesm-service-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/sgx-aesm-service-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-epid" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ae-epid-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ae-epid-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-le" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ae-le-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ae-le-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-pce" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ae-pce-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ae-pce-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-ecdsa-plugin" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-aesm-ecdsa-plugin-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-aesm-ecdsa-plugin-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-epid-plugin" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-aesm-epid-plugin-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-aesm-epid-plugin-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-launch-plugin" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-aesm-launch-plugin-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-aesm-launch-plugin-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-pce-plugin" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-aesm-pce-plugin-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-aesm-pce-plugin-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-quote-ex-plugin" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-aesm-quote-ex-plugin-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-aesm-quote-ex-plugin-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-epid-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-epid-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-epid-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-epid-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-launch-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-launch-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-launch-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-launch-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-quote-ex-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-quote-ex-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-uae-service" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-uae-service-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-uae-service-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-enclave-common-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-enclave-common-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-urts" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-urts-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-urts-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-dcap-default-qpl-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-dcap-default-qpl-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-dcap-pccs" release="11.u2.fos23" version="2.15.1">
					<filename>sgx-dcap-pccs-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/sgx-dcap-pccs-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-dcap-ql-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-dcap-ql-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qve" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ae-qve-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ae-qve-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-dcap-quote-verify-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-dcap-quote-verify-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-pck-id-retrieval-tool" release="11.u2.fos23" version="2.15.1">
					<filename>sgx-pck-id-retrieval-tool-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/sgx-pck-id-retrieval-tool-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ra-uefi-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ra-uefi-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ra-network-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ra-network-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network-devel" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-ra-network-devel-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-ra-network-devel-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-ra-service" release="11.u2.fos23" version="2.15.1">
					<filename>sgx-ra-service-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/sgx-ra-service-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-headers" release="11.u2.fos23" version="2.15.1">
					<filename>libsgx-headers-2.15.1-11.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsgx-headers-2.15.1-11.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2087</id>
		<title>An update for mod_auth_openidc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24814" id="CVE-2024-24814" title="CVE-2024-24814" type="cve"></reference>
		</references>
		<description>CVE-2024-24814:mod_auth_openidc is an OpenID Certified™ authentication and authorization module for the Apache 2.x HTTP server that implements the OpenID Connect Relying Party functionality. In affected versions missing input validation on mod_auth_openidc_session_chunks cookie value makes the server vulnerable to a denial of service (DoS) attack. An internal security audit has been conducted and the reviewers found that if they manipulated the value of the mod_auth_openidc_session_chunks cookie to a very large integer, like 99999999, the server struggles with the request for a long time and finally gets back with a 500 error. Making a few requests of this kind caused our server to become unresponsive. Attackers can craft requests that would make the server work very hard (and possibly become unresponsive) and/or crash with minimal effort. This issue has been addressed in version 2.4.15.2. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="mod_auth_openidc" release="1.fos23" version="2.4.15.3">
					<filename>mod_auth_openidc-2.4.15.3-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/mod_auth_openidc-2.4.15.3-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_auth_openidc" release="1.fos23" version="2.4.15.3">
					<filename>mod_auth_openidc-2.4.15.3-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/mod_auth_openidc-2.4.15.3-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2088</id>
		<title>An update for mongo-c-driver is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0437" id="CVE-2023-0437" title="CVE-2023-0437" type="cve"></reference>
		</references>
		<description>CVE-2023-0437:When calling bson_utf8_validate on some inputs a loop with an exit condition that cannot be reached may occur, i.e. an infinite loop. This issue affects All MongoDB C Driver versions prior to versions 1.25.0.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="mongo-c-driver" release="7.u1.fos23" version="1.13.1">
					<filename>mongo-c-driver-1.13.1-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/mongo-c-driver-1.13.1-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mongo-c-driver-devel" release="7.u1.fos23" version="1.13.1">
					<filename>mongo-c-driver-devel-1.13.1-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/mongo-c-driver-devel-1.13.1-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libbson" release="7.u1.fos23" version="1.13.1">
					<filename>libbson-1.13.1-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libbson-1.13.1-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libbson-devel" release="7.u1.fos23" version="1.13.1">
					<filename>libbson-devel-1.13.1-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libbson-devel-1.13.1-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mongo-c-driver-help" release="7.u1.fos23" version="1.13.1">
					<filename>mongo-c-driver-help-1.13.1-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/mongo-c-driver-help-1.13.1-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mongo-c-driver" release="7.u1.fos23" version="1.13.1">
					<filename>mongo-c-driver-1.13.1-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/mongo-c-driver-1.13.1-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mongo-c-driver-devel" release="7.u1.fos23" version="1.13.1">
					<filename>mongo-c-driver-devel-1.13.1-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/mongo-c-driver-devel-1.13.1-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libbson" release="7.u1.fos23" version="1.13.1">
					<filename>libbson-1.13.1-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libbson-1.13.1-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libbson-devel" release="7.u1.fos23" version="1.13.1">
					<filename>libbson-devel-1.13.1-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libbson-devel-1.13.1-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mongo-c-driver-help" release="7.u1.fos23" version="1.13.1">
					<filename>mongo-c-driver-help-1.13.1-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/mongo-c-driver-help-1.13.1-7.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2089</id>
		<title>An update for mysql-connector-java is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-2471" id="CVE-2021-2471" title="CVE-2021-2471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21363" id="CVE-2022-21363" title="CVE-2022-21363" type="cve"></reference>
		</references>
		<description>CVE-2021-2471:Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/J). Supported versions that are affected are 8.0.26 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all MySQL Connectors accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Connectors. CVSS 3.1 Base Score 5.9 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H).&#xA;CVE-2022-21363:Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/J). Supported versions that are affected are 8.0.27 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in takeover of MySQL Connectors. CVSS 3.1 Base Score 6.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H).</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="1" name="mysql-connector-java" release="1.fos23" version="8.0.30">
					<filename>mysql-connector-java-8.0.30-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/mysql-connector-java-8.0.30-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2090</id>
		<title>An update for netty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41881" id="CVE-2022-41881" title="CVE-2022-41881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4586" id="CVE-2023-4586" title="CVE-2023-4586" type="cve"></reference>
		</references>
		<description>CVE-2022-41881:Netty project is an event-driven asynchronous network application framework. In versions prior to 4.1.86.Final, a StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion. This issue is patched in version 4.1.86.Final. There is no workaround, except using a custom HaProxyMessageDecoder.&#xA;CVE-2023-4586:A vulnerability was found in the Hot Rod client. This security issue occurs as the Hot Rod client does not enable hostname validation when using TLS, possibly resulting in a man-in-the-middle (MITM) attack.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="netty" release="21.u2.fos23" version="4.1.13">
					<filename>netty-4.1.13-21.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/netty-4.1.13-21.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="netty-help" release="21.u2.fos23" version="4.1.13">
					<filename>netty-help-4.1.13-21.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/netty-help-4.1.13-21.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netty" release="21.u2.fos23" version="4.1.13">
					<filename>netty-4.1.13-21.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/netty-4.1.13-21.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2091</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
		</references>
		<description>CVE-2023-0464:A security vulnerability has been identified in all supported versions&#xA;of OpenSSL related to the verification of X.509 certificate chains&#xA;that include policy constraints.  Attackers may be able to exploit this&#xA;vulnerability by creating a malicious certificate chain that triggers&#xA;exponential use of computational resources, leading to a denial-of-service&#xA;(DoS) attack on affected systems.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-0465:Applications that use a non-default option when verifying certificates may be&#xA;vulnerable to an attack from a malicious CA to circumvent certain checks.&#xA;Invalid certificate policies in leaf certificates are silently ignored by&#xA;OpenSSL and other certificate policy checks are skipped for that certificate.&#xA;A malicious CA could use this to deliberately assert invalid certificate policies&#xA;in order to circumvent policy checking on the certificate altogether.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-44487:The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="1" name="nodejs" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/nodejs-12.22.11-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/nodejs-devel-12.22.11-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/nodejs-libs-12.22.11-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/nodejs-full-i18n-12.22.11-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.9.u4.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/v8-devel-7.8.279.23-1.12.22.11.9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.9.u4.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/npm-6.14.16-1.12.22.11.9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-docs-12.22.11-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/nodejs-docs-12.22.11-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/nodejs-12.22.11-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/nodejs-devel-12.22.11-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/nodejs-libs-12.22.11-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="9.u4.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/nodejs-full-i18n-12.22.11-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.9.u4.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/v8-devel-7.8.279.23-1.12.22.11.9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.9.u4.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/npm-6.14.16-1.12.22.11.9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2092</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
		</references>
		<description>CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL&#xA;to crash leading to a potential Denial of Service attack&#xA;Impact summary: Applications loading files in the PKCS12 format from untrusted&#xA;sources might terminate abruptly.&#xA;A file in PKCS12 format can contain certificates and keys and may come from an&#xA;untrusted source. The PKCS12 specification allows certain fields to be NULL, but&#xA;OpenSSL does not correctly check for this case. This can lead to a NULL pointer&#xA;dereference that results in OpenSSL crashing. If an application processes PKCS12&#xA;files from an untrusted source using the OpenSSL APIs then that application will&#xA;be vulnerable to this issue.&#xA;OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),&#xA;PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()&#xA;and PKCS12_newpass().&#xA;We have also fixed a similar issue in SMIME_write_PKCS7(). However since this&#xA;function is related to writing data we do not consider it security significant.&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u5.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/openresty-openssl111-asan-1.1.1h-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u5.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/openresty-openssl111-asan-1.1.1h-2.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2093</id>
		<title>An update for openresty-zlib is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37434" id="CVE-2022-37434" title="CVE-2022-37434" type="cve"></reference>
		</references>
		<description>CVE-2022-37434:zlib through 1.2.12 has a heap-based buffer over-read or buffer overflow in inflate in inflate.c via a large gzip header extra field. NOTE: only applications that call inflateGetHeader are affected. Some common applications bundle the affected zlib source code but may be unable to call inflateGetHeader (e.g., see the nodejs/node reference).</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="openresty-zlib-asan" release="14.fos23" version="1.2.11">
					<filename>openresty-zlib-asan-1.2.11-14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/openresty-zlib-asan-1.2.11-14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-zlib-asan" release="14.fos23" version="1.2.11">
					<filename>openresty-zlib-asan-1.2.11-14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/openresty-zlib-asan-1.2.11-14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2094</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3966" id="CVE-2023-3966" title="CVE-2023-3966" type="cve"></reference>
		</references>
		<description>CVE-2023-3966:A flaw was found in Open vSwitch where multiple versions are vulnerable to crafted Geneve packets, which may result in a denial of service and invalid memory accesses. Triggering this issue requires that hardware offloading via the netlink path is enabled.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="openvswitch" release="7.u5.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/openvswitch-2.12.4-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-devel" release="7.u5.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/openvswitch-devel-2.12.4-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-help" release="7.u5.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/openvswitch-help-2.12.4-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-openvswitch" release="7.u5.fos23" version="2.12.4">
					<filename>python3-openvswitch-2.12.4-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-openvswitch-2.12.4-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch" release="7.u5.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/openvswitch-2.12.4-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-devel" release="7.u5.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/openvswitch-devel-2.12.4-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-help" release="7.u5.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/openvswitch-help-2.12.4-7.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2095</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47039" id="CVE-2023-47039" title="CVE-2023-47039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47100" id="CVE-2023-47100" title="CVE-2023-47100" type="cve"></reference>
		</references>
		<description>CVE-2023-47039:A vulnerability was found in Perl. This security issue occurs while Perl for Windows relies on the system path environment variable to find the shell (`cmd.exe`). When running an executable that uses the Windows Perl interpreter, Perl attempts to find and execute `cmd.exe` within the operating system. However, due to path search order issues, Perl initially looks for cmd.exe in the current working directory. This flaw allows an attacker with limited privileges to place`cmd.exe` in locations with weak permissions, such as `C:\ProgramData`. By doing so, arbitrary code can be executed when an administrator attempts to use this executable from these compromised locations.&#xA;CVE-2023-47100:In Perl before 5.38.2, S_parse_uniprop_string in regcomp.c can write to unallocated space because a property name associated with a \p{...} regular expression construct is mishandled. The earliest affected version is 5.30.0.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="4" name="perl" release="12.u5.fos23" version="5.34.0">
					<filename>perl-5.34.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/perl-5.34.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-libs" release="12.u5.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/perl-libs-5.34.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-devel" release="12.u5.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/perl-devel-5.34.0-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="4" name="perl-help" release="12.u5.fos23" version="5.34.0">
					<filename>perl-help-5.34.0-12.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/perl-help-5.34.0-12.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl" release="12.u5.fos23" version="5.34.0">
					<filename>perl-5.34.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/perl-5.34.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-libs" release="12.u5.fos23" version="5.34.0">
					<filename>perl-libs-5.34.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/perl-libs-5.34.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-devel" release="12.u5.fos23" version="5.34.0">
					<filename>perl-devel-5.34.0-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/perl-devel-5.34.0-12.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2096</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"></reference>
		</references>
		<description>CVE-2023-39417:IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, &#39;&#39;, or &#34;&#34;). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u1.fos23" version="13.12">
					<filename>postgresql-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u1.fos23" version="13.12">
					<filename>postgresql-private-libs-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-private-libs-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u1.fos23" version="13.12">
					<filename>postgresql-private-devel-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-private-devel-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u1.fos23" version="13.12">
					<filename>postgresql-server-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-server-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u1.fos23" version="13.12">
					<filename>postgresql-docs-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-docs-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u1.fos23" version="13.12">
					<filename>postgresql-contrib-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-contrib-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u1.fos23" version="13.12">
					<filename>postgresql-server-devel-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-server-devel-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u1.fos23" version="13.12">
					<filename>postgresql-test-rpm-macros-13.12-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-test-rpm-macros-13.12-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u1.fos23" version="13.12">
					<filename>postgresql-static-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-static-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u1.fos23" version="13.12">
					<filename>postgresql-plperl-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-plperl-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u1.fos23" version="13.12">
					<filename>postgresql-plpython3-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-plpython3-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u1.fos23" version="13.12">
					<filename>postgresql-pltcl-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-pltcl-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u1.fos23" version="13.12">
					<filename>postgresql-test-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-test-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u1.fos23" version="13.12">
					<filename>postgresql-llvmjit-13.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-llvmjit-13.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u1.fos23" version="13.12">
					<filename>postgresql-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u1.fos23" version="13.12">
					<filename>postgresql-private-libs-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-private-libs-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u1.fos23" version="13.12">
					<filename>postgresql-private-devel-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-private-devel-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u1.fos23" version="13.12">
					<filename>postgresql-server-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-server-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u1.fos23" version="13.12">
					<filename>postgresql-docs-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-docs-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u1.fos23" version="13.12">
					<filename>postgresql-contrib-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-contrib-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u1.fos23" version="13.12">
					<filename>postgresql-server-devel-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-server-devel-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u1.fos23" version="13.12">
					<filename>postgresql-static-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-static-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u1.fos23" version="13.12">
					<filename>postgresql-plperl-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-plperl-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u1.fos23" version="13.12">
					<filename>postgresql-plpython3-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-plpython3-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u1.fos23" version="13.12">
					<filename>postgresql-pltcl-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-pltcl-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u1.fos23" version="13.12">
					<filename>postgresql-test-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-test-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u1.fos23" version="13.12">
					<filename>postgresql-llvmjit-13.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/postgresql-llvmjit-13.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2097</id>
		<title>An update for postgresql-jdbc is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1597" id="CVE-2024-1597" title="CVE-2024-1597" type="cve"></reference>
		</references>
		<description>CVE-2024-1597:pgjdbc, the PostgreSQL JDBC Driver, allows attacker to inject SQL if using PreferQueryMode=SIMPLE. Note this is not the default. In the default mode there is no vulnerability. A placeholder for a numeric value must be immediately preceded by a minus. There must be a second placeholder for a string value after the first placeholder; both must be on the same line. By constructing a matching string payload, the attacker can inject SQL to alter the query,bypassing the protections that parameterized queries bring against SQL Injection attacks. Versions before 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.8 are affected.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="postgresql-jdbc" release="3.u2.fos23" version="42.4.1">
					<filename>postgresql-jdbc-42.4.1-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-jdbc-42.4.1-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-jdbc-javadoc" release="3.u2.fos23" version="42.4.1">
					<filename>postgresql-jdbc-javadoc-42.4.1-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-jdbc-javadoc-42.4.1-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-jdbc-help" release="3.u2.fos23" version="42.4.1">
					<filename>postgresql-jdbc-help-42.4.1-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/postgresql-jdbc-help-42.4.1-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2098</id>
		<title>An update for python-jwcrypto is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6681" id="CVE-2023-6681" title="CVE-2023-6681" type="cve"></reference>
		</references>
		<description>CVE-2023-6681:A vulnerability was found in JWCrypto. This flaw allows an attacker to cause a denial of service (DoS) attack and possible password brute-force and dictionary attacks to be more resource-intensive. This issue can result in a large amount of computational consumption, causing a denial of service attack.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="python3-jwcrypto" release="2.u1.fos23" version="1.4.2">
					<filename>python3-jwcrypto-1.4.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-jwcrypto-1.4.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2099</id>
		<title>An update for python-paramiko is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
		</references>
		<description>CVE-2023-48795:The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="python3-paramiko" release="3.u1.fos23" version="2.11.0">
					<filename>python3-paramiko-2.11.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-paramiko-2.11.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-paramiko-help" release="3.u1.fos23" version="2.11.0">
					<filename>python-paramiko-help-2.11.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python-paramiko-help-2.11.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2100</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5088" id="CVE-2023-5088" title="CVE-2023-5088" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0330" id="CVE-2023-0330" title="CVE-2023-0330" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3019" id="CVE-2023-3019" title="CVE-2023-3019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6693" id="CVE-2023-6693" title="CVE-2023-6693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6683" id="CVE-2023-6683" title="CVE-2023-6683" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24474" id="CVE-2024-24474" title="CVE-2024-24474" type="cve"></reference>
		</references>
		<description>CVE-2023-5088:A bug in QEMU could cause a guest I/O operation otherwise addressed to an arbitrary disk offset to be targeted to offset 0 instead (potentially overwriting the VM&#39;s boot code). This could be used, for example, by L2 guests with a virtual disk (vdiskL2) stored on a virtual disk of an L1 (vdiskL1) hypervisor to read and/or write data to LBA 0 of vdiskL1, potentially gaining control of L1 at its next reboot.&#xA;CVE-2023-0330:A vulnerability in the lsi53c895a device affects the latest version of qemu. A DMA-MMIO reentrancy problem may lead to memory corruption bugs like stack overflow or use-after-free.&#xA;CVE-2023-3019:A DMA reentrancy issue leading to a use-after-free error was found in the e1000e NIC emulation code in QEMU. This issue could allow a privileged guest user to crash the QEMU process on the host, resulting in a denial of service.&#xA;CVE-2023-6693:A stack based buffer overflow was found in the virtio-net device of QEMU. This issue occurs when flushing TX in the virtio_net_flush_tx function if guest features VIRTIO_NET_F_HASH_REPORT, VIRTIO_F_VERSION_1 and VIRTIO_NET_F_MRG_RXBUF are enabled. This could allow a malicious user to overwrite local variables allocated on the stack. Specifically, the `out_sg` variable could be used to read a part of process memory and send it to the wire, causing an information leak.&#xA;CVE-2023-6683:A flaw was found in the QEMU built-in VNC server while processing ClientCutText messages. The qemu_clipboard_request() function can be reached before vnc_server_cut_text_caps() was called and had the chance to initialize the clipboard peer, leading to a NULL pointer dereference. This could allow a malicious authenticated VNC client to crash QEMU and trigger a denial of service.&#xA;CVE-2024-24474:QEMU before 8.2.0 has an integer underflow, and resultant buffer overflow, via a TI command when an expected non-DMA transfer length is less than the length of the available FIFO data. This occurs in esp_do_nodma in hw/scsi/esp.c because of an underflow of async_len.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="10" name="qemu" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-guest-agent-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-89.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-help-6.2.0-89.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-img-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-block-rbd-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-block-ssh-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-block-iscsi-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-block-curl-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-hw-usb-host-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-seabios-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-system-aarch64-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-system-arm-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-system-x86_64-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-89.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/qemu-system-riscv-6.2.0-89.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-guest-agent-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-img-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-block-rbd-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-block-ssh-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-block-iscsi-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-block-curl-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-hw-usb-host-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-system-aarch64-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-system-arm-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-system-x86_64-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="89.u15.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-89.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/qemu-system-riscv-6.2.0-89.u15.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2101</id>
		<title>An update for rubygem-activestorage is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26144" id="CVE-2024-26144" title="CVE-2024-26144" type="cve"></reference>
		</references>
		<description>CVE-2024-26144:Rails is a web-application framework. Starting with version 5.2.0, there is a possible sensitive session information leak in Active Storage. By default, Active Storage sends a Set-Cookie header along with the user&#39;s session cookie when serving blobs. It also sets Cache-Control to public. Certain proxies may cache the Set-Cookie, leading to an information leak. The vulnerability is fixed in 7.0.8.1 and 6.1.7.7.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="rubygem-activestorage" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-activestorage-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rubygem-activestorage-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-activestorage-doc" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-activestorage-doc-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rubygem-activestorage-doc-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2102</id>
		<title>An update for rubygem-yard is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27285" id="CVE-2024-27285" title="CVE-2024-27285" type="cve"></reference>
		</references>
		<description>CVE-2024-27285:YARD is a Ruby Documentation tool. The &#34;frames.html&#34; file within the Yard Doc&#39;s generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the &#34;frames.erb&#34; template file.  This vulnerability is fixed in 0.9.36.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="rubygem-yard" release="3.u1.fos23" version="0.9.26">
					<filename>rubygem-yard-0.9.26-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rubygem-yard-0.9.26-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-yard-doc" release="3.u1.fos23" version="0.9.26">
					<filename>rubygem-yard-doc-0.9.26-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rubygem-yard-doc-0.9.26-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2103</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21626" id="CVE-2024-21626" title="CVE-2024-21626" type="cve"></reference>
		</references>
		<description>CVE-2024-21626:runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem (&#34;attack 2&#34;). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run (&#34;attack 1&#34;). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes (&#34;attack 3a&#34; and &#34;attack 3b&#34;). runc 1.1.12 includes patches for this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="runc" release="24.u7.fos23" version="1.1.3">
					<filename>runc-1.1.3-24.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/runc-1.1.3-24.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="runc" release="24.u7.fos23" version="1.1.3">
					<filename>runc-1.1.3-24.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/runc-1.1.3-24.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2104</id>
		<title>An update for rust is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24577" id="CVE-2024-24577" title="CVE-2024-24577" type="cve"></reference>
		</references>
		<description>CVE-2024-24577:libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Using well-crafted inputs to `git_index_add` can cause heap corruption that could be leveraged for arbitrary code execution. There is an issue in the `has_dir_name` function in `src/libgit2/index.c`, which frees an entry that should not be freed. The freed entry is later used and overwritten with potentially bad actor-controlled data leading to controlled heap corruption. Depending on the application that uses libgit2, this could lead to arbitrary code execution. This issue has been patched in version 1.6.5 and 1.7.2.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="rust" release="3.u1.fos23" version="1.60.0">
					<filename>rust-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-std-static" release="3.u1.fos23" version="1.60.0">
					<filename>rust-std-static-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-std-static-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-debugger-common" release="3.u1.fos23" version="1.60.0">
					<filename>rust-debugger-common-1.60.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-debugger-common-1.60.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-gdb" release="3.u1.fos23" version="1.60.0">
					<filename>rust-gdb-1.60.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-gdb-1.60.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-lldb" release="3.u1.fos23" version="1.60.0">
					<filename>rust-lldb-1.60.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-lldb-1.60.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cargo" release="3.u1.fos23" version="1.60.0">
					<filename>cargo-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/cargo-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rustfmt" release="3.u1.fos23" version="1.60.0">
					<filename>rustfmt-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rustfmt-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rls" release="3.u1.fos23" version="1.60.0">
					<filename>rls-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rls-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clippy" release="3.u1.fos23" version="1.60.0">
					<filename>clippy-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/clippy-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-src" release="3.u1.fos23" version="1.60.0">
					<filename>rust-src-1.60.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-src-1.60.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-analysis" release="3.u1.fos23" version="1.60.0">
					<filename>rust-analysis-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-analysis-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-help" release="3.u1.fos23" version="1.60.0">
					<filename>rust-help-1.60.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/rust-help-1.60.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust" release="3.u1.fos23" version="1.60.0">
					<filename>rust-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/rust-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-std-static" release="3.u1.fos23" version="1.60.0">
					<filename>rust-std-static-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/rust-std-static-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cargo" release="3.u1.fos23" version="1.60.0">
					<filename>cargo-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/cargo-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rustfmt" release="3.u1.fos23" version="1.60.0">
					<filename>rustfmt-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/rustfmt-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rls" release="3.u1.fos23" version="1.60.0">
					<filename>rls-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/rls-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clippy" release="3.u1.fos23" version="1.60.0">
					<filename>clippy-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/clippy-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-analysis" release="3.u1.fos23" version="1.60.0">
					<filename>rust-analysis-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/rust-analysis-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-help" release="3.u1.fos23" version="1.60.0">
					<filename>rust-help-1.60.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/rust-help-1.60.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2105</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14628" id="CVE-2018-14628" title="CVE-2018-14628" type="cve"></reference>
		</references>
		<description>CVE-2018-14628:An information leak vulnerability was discovered in Samba&#39;s LDAP server. Due to missing access control checks, an authenticated but unprivileged attacker could discover the names and preserved attributes of deleted objects in the LDAP store.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="samba" release="11.u7.fos23" version="4.17.5">
					<filename>samba-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-libs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-libs-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client" release="11.u7.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-client-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client-libs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-client-libs-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-client-libs-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common" release="11.u7.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-common-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common-tools" release="11.u7.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-common-tools-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-dc-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-provision" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-dc-provision-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-libs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-libs-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-dc-libs-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-bind-dlz" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-dc-bind-dlz-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-devel" release="11.u7.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-devel-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-vfs-glusterfs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-vfs-glusterfs-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-vfs-glusterfs-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-krb5-printing" release="11.u7.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-krb5-printing-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient" release="11.u7.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsmbclient-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient-devel" release="11.u7.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libsmbclient-devel-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient" release="11.u7.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libwbclient-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient-devel" release="11.u7.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/libwbclient-devel-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba" release="11.u7.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-samba-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-test" release="11.u7.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-samba-test-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-dc" release="11.u7.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-samba-dc-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="samba-pidl" release="11.u7.fos23" version="4.17.5">
					<filename>samba-pidl-4.17.5-11.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-pidl-4.17.5-11.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-test" release="11.u7.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-test-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-usershares" release="11.u7.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-usershares-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-winbind-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-clients" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-winbind-clients-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-krb5-locator" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-winbind-krb5-locator-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-modules" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-winbind-modules-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ctdb" release="11.u7.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/ctdb-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-help" release="11.u7.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/samba-help-4.17.5-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba" release="11.u7.fos23" version="4.17.5">
					<filename>samba-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-libs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-libs-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-libs-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client" release="11.u7.fos23" version="4.17.5">
					<filename>samba-client-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-client-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client-libs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-client-libs-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-client-libs-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common" release="11.u7.fos23" version="4.17.5">
					<filename>samba-common-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-common-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common-tools" release="11.u7.fos23" version="4.17.5">
					<filename>samba-common-tools-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-common-tools-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-dc-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-provision" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-dc-provision-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-libs" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-libs-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-dc-libs-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-bind-dlz" release="11.u7.fos23" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-dc-bind-dlz-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-devel" release="11.u7.fos23" version="4.17.5">
					<filename>samba-devel-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-devel-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-krb5-printing" release="11.u7.fos23" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-krb5-printing-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient" release="11.u7.fos23" version="4.17.5">
					<filename>libsmbclient-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libsmbclient-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient-devel" release="11.u7.fos23" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libsmbclient-devel-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient" release="11.u7.fos23" version="4.17.5">
					<filename>libwbclient-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libwbclient-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient-devel" release="11.u7.fos23" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/libwbclient-devel-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba" release="11.u7.fos23" version="4.17.5">
					<filename>python3-samba-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/python3-samba-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-test" release="11.u7.fos23" version="4.17.5">
					<filename>python3-samba-test-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/python3-samba-test-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-dc" release="11.u7.fos23" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/python3-samba-dc-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-test" release="11.u7.fos23" version="4.17.5">
					<filename>samba-test-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-test-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-usershares" release="11.u7.fos23" version="4.17.5">
					<filename>samba-usershares-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-usershares-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-winbind-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-clients" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-winbind-clients-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-krb5-locator" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-winbind-krb5-locator-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-modules" release="11.u7.fos23" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-winbind-modules-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctdb" release="11.u7.fos23" version="4.17.5">
					<filename>ctdb-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/ctdb-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-help" release="11.u7.fos23" version="4.17.5">
					<filename>samba-help-4.17.5-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/samba-help-4.17.5-11.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2106</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
		</references>
		<description>CVE-2023-0465:Applications that use a non-default option when verifying certificates may be&#xA;vulnerable to an attack from a malicious CA to circumvent certain checks.&#xA;Invalid certificate policies in leaf certificates are silently ignored by&#xA;OpenSSL and other certificate policy checks are skipped for that certificate.&#xA;A malicious CA could use this to deliberately assert invalid certificate policies&#xA;in order to circumvent policy checking on the certificate altogether.&#xA;Policy processing is disabled by default but can be enabled by passing&#xA;the `-policy&#39; argument to the command line utilities or by calling the&#xA;`X509_VERIFY_PARAM_set1_policies()&#39; function.&#xA;CVE-2023-2650:Issue summary: Processing some specially crafted ASN.1 object identifiers or&#xA;data containing them may be very slow.&#xA;Impact summary: Applications that use OBJ_obj2txt() directly, or use any of&#xA;the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message&#xA;size limit may experience notable to very long delays when processing those&#xA;messages, which may lead to a Denial of Service.&#xA;An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -&#xA;most of which have no size limit.  OBJ_obj2txt() may be used to translate&#xA;an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL&#xA;type ASN1_OBJECT) to its canonical numeric text form, which are the&#xA;sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by&#xA;periods.&#xA;When one of the sub-identifiers in the OBJECT IDENTIFIER is very large&#xA;(these are sizes that are seen as absurdly large, taking up tens or hundreds&#xA;of KiBs), the translation to a decimal number in text may take a very long&#xA;time.  The time complexity is O(n^2) with &#39;n&#39; being the size of the&#xA;sub-identifiers in bytes (*).&#xA;With OpenSSL 3.0, support to fetch cryptographic algorithms using names /&#xA;identifiers in string form was introduced.  This includes using OBJECT&#xA;IDENTIFIERs in canonical numeric text form as identifiers for fetching&#xA;algorithms.&#xA;Such OBJECT IDENTIFIERs may be received through the ASN.1 structure&#xA;AlgorithmIdentifier, which is commonly used in multiple protocols to specify&#xA;what cryptographic algorithm should be used to sign or verify, encrypt or&#xA;decrypt, or digest passed data.&#xA;Applications that call OBJ_obj2txt() directly with untrusted data are&#xA;affected, with any version of OpenSSL.  If the use is for the mere purpose&#xA;of display, the severity is considered low.&#xA;In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,&#xA;CMS, CMP/CRMF or TS.  It also impacts anything that processes X.509&#xA;certificates, including simple things like verifying its signature.&#xA;The impact on TLS is relatively low, because all versions of OpenSSL have a&#xA;100KiB limit on the peer&#39;s certificate chain.  Additionally, this only&#xA;impacts clients, or servers that have explicitly enabled client&#xA;authentication.&#xA;In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,&#xA;such as X.509 certificates.  This is assumed to not happen in such a way&#xA;that it would cause a Denial of Service, so these versions are considered&#xA;not affected by this issue in such a way that it would be cause for concern,&#xA;and the severity is therefore considered low.&#xA;CVE-2023-3446:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;The function DH_check() performs various checks on DH parameters. One of those&#xA;checks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to use&#xA;a very large modulus is slow and OpenSSL will not normally use a modulus which&#xA;is over 10,000 bits in length.&#xA;However the DH_check() function checks numerous aspects of the key or parameters&#xA;that have been supplied. Some of those checks use the supplied modulus value&#xA;even if it has already been found to be too large.&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulernable to a Denial of Service attack.&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#39;-check&#39; option.&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL&#xA;to crash leading to a potential Denial of Service attack&#xA;Impact summary: Applications loading files in the PKCS12 format from untrusted&#xA;sources might terminate abruptly.&#xA;A file in PKCS12 format can contain certificates and keys and may come from an&#xA;untrusted source. The PKCS12 specification allows certain fields to be NULL, but&#xA;OpenSSL does not correctly check for this case. This can lead to a NULL pointer&#xA;dereference that results in OpenSSL crashing. If an application processes PKCS12&#xA;files from an untrusted source using the OpenSSL APIs then that application will&#xA;be vulnerable to this issue.&#xA;OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),&#xA;PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()&#xA;and PKCS12_newpass().&#xA;We have also fixed a similar issue in SMIME_write_PKCS7(). However since this&#xA;function is related to writing data we do not consider it security significant.&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="shim" release="17.u12.fos23" version="15.6">
					<filename>shim-15.6-17.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/shim-15.6-17.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="shim" release="17.u12.fos23" version="15.6">
					<filename>shim-15.6-17.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/shim-15.6-17.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2107</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25617" id="CVE-2024-25617" title="CVE-2024-25617" type="cve"></reference>
		</references>
		<description>CVE-2024-25617:Squid is an open source caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to a Collapse of Data into Unsafe Value bug ,Squid may be vulnerable to a Denial of Service attack against HTTP header parsing. This problem allows a remote client or a remote server to perform Denial of Service when sending oversized headers in HTTP messages. In versions of Squid prior to 6.5 this can be achieved if the request_header_max_size or reply_header_max_size settings are unchanged from the default. In Squid version 6.5 and later, the default setting of these parameters is safe. Squid will emit a critical warning in cache.log if the administrator is setting these parameters to unsafe values. Squid will not at this time prevent these settings from being changed to unsafe values. Users are advised to upgrade to version 6.5. There are no known workarounds for this vulnerability. This issue is also tracked as SQUID-2024:2</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="7" name="squid" release="24.u5.fos23" version="4.9">
					<filename>squid-4.9-24.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/squid-4.9-24.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="24.u5.fos23" version="4.9">
					<filename>squid-4.9-24.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/squid-4.9-24.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2108</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1488" id="CVE-2024-1488" title="CVE-2024-1488" type="cve"></reference>
		</references>
		<description>CVE-2023-50387:Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the &#34;KeyTrap&#34; issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.&#xA;CVE-2023-50868:The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the &#34;NSEC3&#34; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.&#xA;CVE-2024-1488:A vulnerability was found in Unbound due to incorrect default permissions, allowing any process outside the unbound group to modify the unbound runtime configuration. If a process can connect over localhost to port 8953, it can alter the configuration of unbound.service. This flaw allows an unprivileged attacker to manipulate a running instance, potentially altering forwarders, allowing them to track all queries forwarded by the local resolver, and, in some cases, disrupting resolving altogether.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="unbound" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-1.13.2-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/unbound-1.13.2-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/unbound-libs-1.13.2-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/unbound-devel-1.13.2-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="11.u4.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/python3-unbound-1.13.2-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/unbound-help-1.13.2-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-1.13.2-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/unbound-1.13.2-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/unbound-libs-1.13.2-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/unbound-devel-1.13.2-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="11.u4.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/python3-unbound-1.13.2-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="11.u4.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/unbound-help-1.13.2-11.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2109</id>
		<title>An update for varnish is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45059" id="CVE-2022-45059" title="CVE-2022-45059" type="cve"></reference>
		</references>
		<description>CVE-2023-44487:The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.&#xA;CVE-2022-45059:An issue was discovered in Varnish Cache 7.x before 7.1.2 and 7.2.x before 7.2.1. A request smuggling attack can be performed on Varnish Cache servers by requesting that certain headers are made hop-by-hop, preventing the Varnish Cache servers from forwarding critical headers to the backend.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="varnish" release="1.fos23" version="7.4.2">
					<filename>varnish-7.4.2-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/varnish-7.4.2-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="varnish-devel" release="1.fos23" version="7.4.2">
					<filename>varnish-devel-7.4.2-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/varnish-devel-7.4.2-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="varnish-help" release="1.fos23" version="7.4.2">
					<filename>varnish-help-7.4.2-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/varnish-help-7.4.2-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish" release="1.fos23" version="7.4.2">
					<filename>varnish-7.4.2-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/varnish-7.4.2-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish-devel" release="1.fos23" version="7.4.2">
					<filename>varnish-devel-7.4.2-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/varnish-devel-7.4.2-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2110</id>
		<title>An update for wpa_supplicant is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52160" id="CVE-2023-52160" title="CVE-2023-52160" type="cve"></reference>
		</references>
		<description>CVE-2023-52160:The implementation of PEAP in wpa_supplicant through 2.10 allows authentication bypass. For a successful attack, wpa_supplicant must be configured to not verify the network&#39;s TLS certificate during Phase 1 authentication, and an eap_peap_decrypt vulnerability can then be abused to skip Phase 2 authentication. The attack vector is sending an EAP-TLV Success packet instead of starting Phase 2. This allows an adversary to impersonate Enterprise Wi-Fi networks.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="1" name="wpa_supplicant" release="30.u1.fos23" version="2.6">
					<filename>wpa_supplicant-2.6-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/wpa_supplicant-2.6-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-gui" release="30.u1.fos23" version="2.6">
					<filename>wpa_supplicant-gui-2.6-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/wpa_supplicant-gui-2.6-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-help" release="30.u1.fos23" version="2.6">
					<filename>wpa_supplicant-help-2.6-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/wpa_supplicant-help-2.6-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant" release="30.u1.fos23" version="2.6">
					<filename>wpa_supplicant-2.6-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/wpa_supplicant-2.6-30.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-gui" release="30.u1.fos23" version="2.6">
					<filename>wpa_supplicant-gui-2.6-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/wpa_supplicant-gui-2.6-30.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-help" release="30.u1.fos23" version="2.6">
					<filename>wpa_supplicant-help-2.6-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/wpa_supplicant-help-2.6-30.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2111</id>
		<title>An update for xerces-c is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-1311" id="CVE-2018-1311" title="CVE-2018-1311" type="cve"></reference>
		</references>
		<description>CVE-2018-1311:The Apache Xerces-C 3.0.0 to 3.2.3 XML parser contains a use-after-free error triggered during the scanning of external DTDs. This flaw has not been addressed in the maintained version of the library and has no current mitigation other than to disable DTD processing. This can be accomplished via the DOM using a standard parser feature, or via SAX using the XERCES_DISABLE_DTD environment variable.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="xerces-c" release="5.u1.fos23" version="3.2.2">
					<filename>xerces-c-3.2.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xerces-c-3.2.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xerces-c-devel" release="5.u1.fos23" version="3.2.2">
					<filename>xerces-c-devel-3.2.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xerces-c-devel-3.2.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xerces-c-help" release="5.u1.fos23" version="3.2.2">
					<filename>xerces-c-help-3.2.2-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xerces-c-help-3.2.2-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xerces-c" release="5.u1.fos23" version="3.2.2">
					<filename>xerces-c-3.2.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xerces-c-3.2.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xerces-c-devel" release="5.u1.fos23" version="3.2.2">
					<filename>xerces-c-devel-3.2.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xerces-c-devel-3.2.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2112</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"></reference>
		</references>
		<description>CVE-2023-6816:A flaw was found in X.Org server. Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Buttons can be arbitrarily mapped to any value up to 255, but the X.Org Server was only allocating space for the device&#39;s particular number of buttons, leading to a heap overflow if a bigger value was used.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-common-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-Xnest-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-Xdmx-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-Xvfb-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-Xephyr-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-devel-1.20.11-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-28.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-help-1.20.11-28.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-28.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xorg-x11-server-source-1.20.11-28.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-common-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-Xnest-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-Xdmx-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-Xvfb-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-Xephyr-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="28.u13.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/xorg-x11-server-devel-1.20.11-28.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2113</id>
		<title>An update for xstream is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-03-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40151" id="CVE-2022-40151" title="CVE-2022-40151" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41966" id="CVE-2022-41966" title="CVE-2022-41966" type="cve"></reference>
		</references>
		<description>CVE-2022-40151:Those using Xstream to seralize XML data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.&#xA;CVE-2022-41966:XStream serializes Java objects to XML and back again. Versions prior to 1.4.20 may allow a remote attacker to terminate the application with a stack overflow error, resulting in a denial of service only via manipulation the processed input stream. The attack uses the hash code implementation for collections and maps to force recursive hash calculation causing a stack overflow. This issue is patched in version 1.4.20 which handles the stack overflow and raises an InputManipulationException instead. A potential workaround for users who only use HashMap or HashSet and whose XML refers these only as default map or set, is to change the default implementation of java.util.Map and java.util per the code example in the referenced advisory. However, this implies that your application does not care about the implementation of the map and all elements are comparable.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="noarch" epoch="0" name="xstream" release="1.u3.fos23" version="1.4.20">
					<filename>xstream-1.4.20-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xstream-1.4.20-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-javadoc" release="1.u3.fos23" version="1.4.20">
					<filename>xstream-javadoc-1.4.20-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xstream-javadoc-1.4.20-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-hibernate" release="1.u3.fos23" version="1.4.20">
					<filename>xstream-hibernate-1.4.20-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xstream-hibernate-1.4.20-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-benchmark" release="1.u3.fos23" version="1.4.20">
					<filename>xstream-benchmark-1.4.20-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xstream-benchmark-1.4.20-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-parent" release="1.u3.fos23" version="1.4.20">
					<filename>xstream-parent-1.4.20-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/xstream-parent-1.4.20-1.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2114</id>
		<title>An update for LibRaw is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32142" id="CVE-2021-32142" title="CVE-2021-32142" type="cve"></reference>
		</references>
		<description>CVE-2021-32142:Buffer Overflow vulnerability in LibRaw linux/unix v0.20.0 allows attacker to escalate privileges via the LibRaw_buffer_datastream::gets(char*, int) in /src/libraw/src/libraw_datastream.cpp.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="LibRaw" release="7.u4.fos23" version="0.20.2">
					<filename>LibRaw-0.20.2-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/LibRaw-0.20.2-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="LibRaw-devel" release="7.u4.fos23" version="0.20.2">
					<filename>LibRaw-devel-0.20.2-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/LibRaw-devel-0.20.2-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="LibRaw" release="7.u4.fos23" version="0.20.2">
					<filename>LibRaw-0.20.2-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/LibRaw-0.20.2-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="LibRaw-devel" release="7.u4.fos23" version="0.20.2">
					<filename>LibRaw-devel-0.20.2-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/LibRaw-devel-0.20.2-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2115</id>
		<title>An update for OpenEXR is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31047" id="CVE-2024-31047" title="CVE-2024-31047" type="cve"></reference>
		</references>
		<description>CVE-2024-31047:An issue in Academy Software Foundation openexr v.3.2.3 and before allows a local attacker to cause a denial of service (DoS) via the convert function of exrmultipart.cpp.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="OpenEXR" release="3.u2.fos23" version="3.1.5">
					<filename>OpenEXR-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/OpenEXR-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-libs" release="3.u2.fos23" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/OpenEXR-libs-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-devel" release="3.u2.fos23" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/OpenEXR-devel-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR" release="3.u2.fos23" version="3.1.5">
					<filename>OpenEXR-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/OpenEXR-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-libs" release="3.u2.fos23" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/OpenEXR-libs-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-devel" release="3.u2.fos23" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/OpenEXR-devel-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2116</id>
		<title>An update for aspell is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-25051" id="CVE-2019-25051" title="CVE-2019-25051" type="cve"></reference>
		</references>
		<description>CVE-2019-25051:objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in acommon::ObjStack::dup_top (called from acommon::StringMap::add and acommon::Config::lookup_list).</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="12" name="aspell" release="30.u1.fos23" version="0.60.6.1">
					<filename>aspell-0.60.6.1-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/aspell-0.60.6.1-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="aspell-devel" release="30.u1.fos23" version="0.60.6.1">
					<filename>aspell-devel-0.60.6.1-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/aspell-devel-0.60.6.1-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="aspell-help" release="30.u1.fos23" version="0.60.6.1">
					<filename>aspell-help-0.60.6.1-30.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/aspell-help-0.60.6.1-30.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="aspell" release="30.u1.fos23" version="0.60.6.1">
					<filename>aspell-0.60.6.1-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/aspell-0.60.6.1-30.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="aspell-devel" release="30.u1.fos23" version="0.60.6.1">
					<filename>aspell-devel-0.60.6.1-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/aspell-devel-0.60.6.1-30.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="aspell-help" release="30.u1.fos23" version="0.60.6.1">
					<filename>aspell-help-0.60.6.1-30.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/aspell-help-0.60.6.1-30.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2117</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4408" id="CVE-2023-4408" title="CVE-2023-4408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5517" id="CVE-2023-5517" title="CVE-2023-5517" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5679" id="CVE-2023-5679" title="CVE-2023-5679" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5680" id="CVE-2023-5680" title="CVE-2023-5680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6516" id="CVE-2023-6516" title="CVE-2023-6516" type="cve"></reference>
		</references>
		<description>CVE-2023-4408:The DNS message parsing code in `named` includes a section whose computational complexity is overly high. It does not cause problems for typical DNS traffic, but crafted queries and responses may cause excessive CPU load on the affected `named` instance by exploiting this flaw. This issue affects both authoritative servers and recursive resolvers.&#xA;This issue affects BIND 9 versions 9.0.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.&#xA;CVE-2023-50868:The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the &#34;NSEC3&#34; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.&#xA;CVE-2023-5517:A flaw in query-handling code can cause `named` to exit prematurely with an assertion failure when:&#xA;  - `nxdomain-redirect &lt;domain&gt;;` is configured, and&#xA;  - the resolver receives a PTR query for an RFC 1918 address that would normally result in an authoritative NXDOMAIN response.&#xA;This issue affects BIND 9 versions 9.12.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.&#xA;CVE-2023-5679:A bad interaction between DNS64 and serve-stale may cause `named` to crash with an assertion failure during recursive resolution, when both of these features are enabled.&#xA;This issue affects BIND 9 versions 9.16.12 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.16.12-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.&#xA;CVE-2023-5680:If a resolver cache has a very large number of ECS records stored for the same name, the process of cleaning the cache database node for this name can significantly impair query performance. &#xA;This issue affects BIND 9 versions 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.&#xA;CVE-2023-6516:To keep its cache database efficient, `named` running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, `named` may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured `max-cache-size` limit to be significantly exceeded.&#xA;This issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="32" name="bind" release="22.u7.fos23" version="9.16.23">
					<filename>bind-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-pkcs11-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-pkcs11-utils-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-pkcs11-libs-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-pkcs11-devel-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="22.u7.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-libs-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="22.u7.fos23" version="9.16.23">
					<filename>bind-license-9.16.23-22.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-license-9.16.23-22.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="22.u7.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-utils-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="22.u7.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-dnssec-utils-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="22.u7.fos23" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-22.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-dnssec-doc-9.16.23-22.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="22.u7.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-devel-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="22.u7.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-22.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bind-chroot-9.16.23-22.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="22.u7.fos23" version="9.16.23">
					<filename>python3-bind-9.16.23-22.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-bind-9.16.23-22.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="22.u7.fos23" version="9.16.23">
					<filename>bind-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-pkcs11-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-pkcs11-utils-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-pkcs11-libs-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="22.u7.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-pkcs11-devel-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="22.u7.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-libs-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="22.u7.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-utils-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="22.u7.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-dnssec-utils-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="22.u7.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-devel-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="22.u7.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-22.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bind-chroot-9.16.23-22.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2118</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2398" id="CVE-2024-2398" title="CVE-2024-2398" type="cve"></reference>
		</references>
		<description>CVE-2024-2398:When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory.  Further, this error condition fails silently and is therefore not easily detected by an application.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="curl" release="28.u14.fos23" version="7.79.1">
					<filename>curl-7.79.1-28.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/curl-7.79.1-28.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="28.u14.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-28.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libcurl-7.79.1-28.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="28.u14.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-28.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libcurl-devel-7.79.1-28.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="28.u14.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-28.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/curl-help-7.79.1-28.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="28.u14.fos23" version="7.79.1">
					<filename>curl-7.79.1-28.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/curl-7.79.1-28.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="28.u14.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-28.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libcurl-7.79.1-28.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="28.u14.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-28.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libcurl-devel-7.79.1-28.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2119</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
		</references>
		<description>CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded&#xA;memory growth when processing TLSv1.3 sessions&#xA;Impact summary: An attacker may exploit certain server configurations to trigger&#xA;unbounded memory growth that would lead to a Denial of Service&#xA;This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is&#xA;being used (but not if early_data support is also configured and the default&#xA;anti-replay protection is in use). In this case, under certain conditions, the&#xA;session cache can get into an incorrect state and it will fail to flush properly&#xA;as it fills. The session cache will continue to grow in an unbounded manner. A&#xA;malicious client could deliberately create the scenario for this failure to&#xA;force a Denial of Service. It may also happen by accident in normal operation.&#xA;This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS&#xA;clients.&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL&#xA;1.0.2 is also not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="17.u6.fos23" version="202011">
					<filename>edk2-devel-202011-17.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/edk2-devel-202011-17.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="17.u6.fos23" version="202011">
					<filename>python3-edk2-devel-202011-17.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-edk2-devel-202011-17.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="17.u6.fos23" version="202011">
					<filename>edk2-help-202011-17.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/edk2-help-202011-17.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="17.u6.fos23" version="202011">
					<filename>edk2-ovmf-202011-17.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/edk2-ovmf-202011-17.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="17.u6.fos23" version="202011">
					<filename>edk2-devel-202011-17.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/edk2-devel-202011-17.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="17.u6.fos23" version="202011">
					<filename>edk2-aarch64-202011-17.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/edk2-aarch64-202011-17.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2120</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30203" id="CVE-2024-30203" title="CVE-2024-30203" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30204" id="CVE-2024-30204" title="CVE-2024-30204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30205" id="CVE-2024-30205" title="CVE-2024-30205" type="cve"></reference>
		</references>
		<description>CVE-2024-30203:In Emacs before 29.3, Gnus treats inline MIME contents as trusted.&#xA;CVE-2024-30204:In Emacs before 29.3, LaTeX preview is enabled by default for e-mail attachments.&#xA;CVE-2024-30205:In Emacs before 29.3, Org mode considers contents of remote files to be trusted. This affects Org Mode before 9.6.23.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="emacs" release="13.u5.fos23" version="27.2">
					<filename>emacs-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="13.u5.fos23" version="27.2">
					<filename>emacs-devel-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-devel-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="13.u5.fos23" version="27.2">
					<filename>emacs-lucid-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-lucid-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="13.u5.fos23" version="27.2">
					<filename>emacs-nox-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-nox-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="13.u5.fos23" version="27.2">
					<filename>emacs-common-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-common-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="13.u5.fos23" version="27.2">
					<filename>emacs-terminal-27.2-13.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-terminal-27.2-13.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="13.u5.fos23" version="27.2">
					<filename>emacs-filesystem-27.2-13.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-filesystem-27.2-13.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="13.u5.fos23" version="27.2">
					<filename>emacs-help-27.2-13.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-help-27.2-13.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="13.u5.fos23" version="27.2">
					<filename>emacs-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="13.u5.fos23" version="27.2">
					<filename>emacs-devel-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-devel-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="13.u5.fos23" version="27.2">
					<filename>emacs-lucid-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-lucid-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="13.u5.fos23" version="27.2">
					<filename>emacs-nox-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-nox-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="13.u5.fos23" version="27.2">
					<filename>emacs-common-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-common-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2121</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52426" id="CVE-2023-52426" title="CVE-2023-52426" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28757" id="CVE-2024-28757" title="CVE-2024-28757" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52425" id="CVE-2023-52425" title="CVE-2023-52425" type="cve"></reference>
		</references>
		<description>CVE-2023-52426:libexpat through 2.5.0 allows recursive XML Entity Expansion if XML_DTD is undefined at compile time.&#xA;CVE-2024-28757:libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).&#xA;CVE-2023-52425:libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="expat" release="11.u1.fos23" version="2.4.1">
					<filename>expat-2.4.1-11.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/expat-2.4.1-11.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat-devel" release="11.u1.fos23" version="2.4.1">
					<filename>expat-devel-2.4.1-11.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/expat-devel-2.4.1-11.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="expat-help" release="11.u1.fos23" version="2.4.1">
					<filename>expat-help-2.4.1-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/expat-help-2.4.1-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat" release="11.u1.fos23" version="2.4.1">
					<filename>expat-2.4.1-11.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/expat-2.4.1-11.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat-devel" release="11.u1.fos23" version="2.4.1">
					<filename>expat-devel-2.4.1-11.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/expat-devel-2.4.1-11.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2122</id>
		<title>An update for flatpak is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32462" id="CVE-2024-32462" title="CVE-2024-32462" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28100" id="CVE-2023-28100" title="CVE-2023-28100" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28101" id="CVE-2023-28101" title="CVE-2023-28101" type="cve"></reference>
		</references>
		<description>CVE-2024-32462:Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. in versions before 1.10.9, 1.12.9, 1.14.6, and 1.15.8, a malicious or compromised Flatpak app could execute arbitrary code outside its sandbox. Normally, the `--command` argument of `flatpak run` expects to be given a command to run in the specified Flatpak app, optionally along with some arguments. However it is possible to instead pass `bwrap` arguments to `--command=`, such as `--bind`. It&#39;s possible to pass an arbitrary `commandline` to the portal interface `org.freedesktop.portal.Background.RequestBackground` from within a Flatpak app. When this is converted into a `--command` and arguments, it achieves the same effect of passing arguments directly to `bwrap`, and thus can be used for a sandbox escape. The solution is to pass the `--` argument to `bwrap`, which makes it stop processing options. This has been supported since bubblewrap 0.3.0. All supported versions of Flatpak require at least that version of bubblewrap. xdg-desktop-portal version 1.18.4 will mitigate this vulnerability by only allowing Flatpak apps to create .desktop files for commands that do not start with --. The vulnerability is patched in 1.15.8, 1.10.9, 1.12.9, and 1.14.6.&#xA;CVE-2023-28100:Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. Versions prior to 1.10.8, 1.12.8, 1.14.4, and 1.15.4 contain a vulnerability similar to CVE-2017-5226, but using the `TIOCLINUX` ioctl command instead of `TIOCSTI`. If a Flatpak app is run on a Linux virtual console such as `/dev/tty1`, it can copy text from the virtual console and paste it into the command buffer, from which the command might be run after the Flatpak app has exited. Ordinary graphical terminal emulators like xterm, gnome-terminal and Konsole are unaffected. This vulnerability is specific to the Linux virtual consoles `/dev/tty1`, `/dev/tty2` and so on. A patch is available in versions 1.10.8, 1.12.8, 1.14.4, and 1.15.4. As a workaround, don&#39;t run Flatpak on a Linux virtual console. Flatpak is primarily designed to be used in a Wayland or X11 graphical environment.&#xA;CVE-2023-28101:Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. In versions prior to 1.10.8, 1.12.8, 1.14.4, and 1.15.4, if an attacker publishes a Flatpak app with elevated permissions, they can hide those permissions from users of the `flatpak(1)` command-line interface by setting other permissions to crafted values that contain non-printable control characters such as `ESC`. A fix is available in versions 1.10.8, 1.12.8, 1.14.4, and 1.15.4. As a workaround, use a GUI like GNOME Software rather than the command-line interface, or only install apps whose maintainers you trust.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="flatpak" release="8.u3.fos23" version="1.10.2">
					<filename>flatpak-1.10.2-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/flatpak-1.10.2-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="flatpak-devel" release="8.u3.fos23" version="1.10.2">
					<filename>flatpak-devel-1.10.2-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/flatpak-devel-1.10.2-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="flatpak-help" release="8.u3.fos23" version="1.10.2">
					<filename>flatpak-help-1.10.2-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/flatpak-help-1.10.2-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flatpak" release="8.u3.fos23" version="1.10.2">
					<filename>flatpak-1.10.2-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/flatpak-1.10.2-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flatpak-devel" release="8.u3.fos23" version="1.10.2">
					<filename>flatpak-devel-1.10.2-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/flatpak-devel-1.10.2-8.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2123</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2961" id="CVE-2024-2961" title="CVE-2024-2961" type="cve"></reference>
		</references>
		<description>CVE-2024-2961:The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="glibc" release="146.u21.fos23" version="2.34">
					<filename>glibc-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="146.u21.fos23" version="2.34">
					<filename>glibc-common-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-common-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="146.u21.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-all-langpacks-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="146.u21.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-locale-source-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="146.u21.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-locale-archive-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="146.u21.fos23" version="2.34">
					<filename>glibc-devel-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-devel-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="146.u21.fos23" version="2.34">
					<filename>nscd-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/nscd-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="146.u21.fos23" version="2.34">
					<filename>nss_modules-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/nss_modules-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="146.u21.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-nss-devel-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="146.u21.fos23" version="2.34">
					<filename>libnsl-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libnsl-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="146.u21.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-debugutils-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="146.u21.fos23" version="2.34">
					<filename>glibc-help-2.34-146.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-help-2.34-146.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="146.u21.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-146.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/glibc-compat-2.17-2.34-146.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="146.u21.fos23" version="2.34">
					<filename>glibc-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="146.u21.fos23" version="2.34">
					<filename>glibc-common-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-common-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="146.u21.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-all-langpacks-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="146.u21.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-locale-source-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="146.u21.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-locale-archive-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="146.u21.fos23" version="2.34">
					<filename>glibc-devel-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-devel-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="146.u21.fos23" version="2.34">
					<filename>nscd-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/nscd-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="146.u21.fos23" version="2.34">
					<filename>nss_modules-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/nss_modules-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="146.u21.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-nss-devel-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="146.u21.fos23" version="2.34">
					<filename>libnsl-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libnsl-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="146.u21.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-debugutils-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="146.u21.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-146.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/glibc-compat-2.17-2.34-146.u21.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2124</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28835" id="CVE-2024-28835" title="CVE-2024-28835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28834" id="CVE-2024-28834" title="CVE-2024-28834" type="cve"></reference>
		</references>
		<description>CVE-2024-28835:A flaw has been discovered in GnuTLS where an application crash can be induced when attempting to verify a specially crafted .pem bundle using the &#34;certtool --verify-chain&#34; command.&#xA;CVE-2024-28834:A flaw was found in GnuTLS. The Minerva attack is a cryptographic vulnerability that exploits deterministic behavior in systems like GnuTLS, leading to side-channel leaks. In specific scenarios, such as when using the GNUTLS_PRIVKEY_FLAG_REPRODUCIBLE flag, it can result in a noticeable step in nonce size from 513 to 512 bits, exposing a potential timing side-channel.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="gnutls" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/gnutls-3.7.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/gnutls-devel-3.7.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-14.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/gnutls-utils-3.7.2-14.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnutls-help" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-help-3.7.2-14.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/gnutls-help-3.7.2-14.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-3.7.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/gnutls-3.7.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-devel-3.7.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/gnutls-devel-3.7.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="14.u7.fos23" version="3.7.2">
					<filename>gnutls-utils-3.7.2-14.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/gnutls-utils-3.7.2-14.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2125</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"></reference>
		</references>
		<description>CVE-2024-27316:HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="httpd" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/httpd-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/httpd-devel-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-20.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/httpd-help-2.4.51-20.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-20.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/httpd-filesystem-2.4.51-20.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/httpd-tools-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="20.u10.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_ssl-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="20.u10.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_md-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="20.u10.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_proxy_html-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="20.u10.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_ldap-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="20.u10.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-20.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_session-2.4.51-20.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/httpd-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/httpd-devel-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="20.u10.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/httpd-tools-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="20.u10.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_ssl-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="20.u10.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_md-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="20.u10.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_proxy_html-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="20.u10.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_ldap-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="20.u10.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-20.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_session-2.4.51-20.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2126</id>
		<title>An update for iperf3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7250" id="CVE-2023-7250" title="CVE-2023-7250" type="cve"></reference>
		</references>
		<description>CVE-2023-7250:A flaw was found in iperf, a utility for testing network performance using TCP, UDP, and SCTP. A malicious or malfunctioning client can send less than the expected amount of data to the iperf server, which can cause the server to hang indefinitely waiting for the remainder or until the connection gets closed. This will prevent other connections to the server, leading to a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="iperf3" release="1.u1.fos23" version="3.16">
					<filename>iperf3-3.16-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/iperf3-3.16-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3-devel" release="1.u1.fos23" version="3.16">
					<filename>iperf3-devel-3.16-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/iperf3-devel-3.16-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="iperf3-help" release="1.u1.fos23" version="3.16">
					<filename>iperf3-help-3.16-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/iperf3-help-3.16-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3" release="1.u1.fos23" version="3.16">
					<filename>iperf3-3.16-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/iperf3-3.16-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3-devel" release="1.u1.fos23" version="3.16">
					<filename>iperf3-devel-3.16-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/iperf3-devel-3.16-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2127</id>
		<title>An update for jose is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50967" id="CVE-2023-50967" title="CVE-2023-50967" type="cve"></reference>
		</references>
		<description>CVE-2023-50967:latchset jose through version 11 allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="jose" release="2.u1.fos23" version="11">
					<filename>jose-11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/jose-11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jose-devel" release="2.u1.fos23" version="11">
					<filename>jose-devel-11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/jose-devel-11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jose-help" release="2.u1.fos23" version="11">
					<filename>jose-help-11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/jose-help-11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jose" release="2.u1.fos23" version="11">
					<filename>jose-11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/jose-11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jose-devel" release="2.u1.fos23" version="11">
					<filename>jose-devel-11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/jose-devel-11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jose-help" release="2.u1.fos23" version="11">
					<filename>jose-help-11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/jose-help-11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2128</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1151" id="CVE-2024-1151" title="CVE-2024-1151" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52443" id="CVE-2023-52443" title="CVE-2023-52443" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52463" id="CVE-2023-52463" title="CVE-2023-52463" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26598" id="CVE-2024-26598" title="CVE-2024-26598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52448" id="CVE-2023-52448" title="CVE-2023-52448" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26595" id="CVE-2024-26595" title="CVE-2024-26595" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52436" id="CVE-2023-52436" title="CVE-2023-52436" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23850" id="CVE-2024-23850" title="CVE-2024-23850" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52438" id="CVE-2023-52438" title="CVE-2023-52438" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26583" id="CVE-2024-26583" title="CVE-2024-26583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52439" id="CVE-2023-52439" title="CVE-2023-52439" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52522" id="CVE-2023-52522" title="CVE-2023-52522" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52573" id="CVE-2023-52573" title="CVE-2023-52573" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22099" id="CVE-2024-22099" title="CVE-2024-22099" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23851" id="CVE-2024-23851" title="CVE-2024-23851" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52510" id="CVE-2023-52510" title="CVE-2023-52510" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52458" id="CVE-2023-52458" title="CVE-2023-52458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47014" id="CVE-2021-47014" title="CVE-2021-47014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47036" id="CVE-2021-47036" title="CVE-2021-47036" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52566" id="CVE-2023-52566" title="CVE-2023-52566" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47028" id="CVE-2021-47028" title="CVE-2021-47028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52568" id="CVE-2023-52568" title="CVE-2023-52568" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52449" id="CVE-2023-52449" title="CVE-2023-52449" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52447" id="CVE-2023-52447" title="CVE-2023-52447" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52452" id="CVE-2023-52452" title="CVE-2023-52452" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52451" id="CVE-2023-52451" title="CVE-2023-52451" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52583" id="CVE-2023-52583" title="CVE-2023-52583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52606" id="CVE-2023-52606" title="CVE-2023-52606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52486" id="CVE-2023-52486" title="CVE-2023-52486" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46987" id="CVE-2021-46987" title="CVE-2021-46987" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52507" id="CVE-2023-52507" title="CVE-2023-52507" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52515" id="CVE-2023-52515" title="CVE-2023-52515" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26586" id="CVE-2024-26586" title="CVE-2024-26586" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47076" id="CVE-2021-47076" title="CVE-2021-47076" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52524" id="CVE-2023-52524" title="CVE-2023-52524" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52527" id="CVE-2023-52527" title="CVE-2023-52527" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52445" id="CVE-2023-52445" title="CVE-2023-52445" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52500" id="CVE-2023-52500" title="CVE-2023-52500" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52528" id="CVE-2023-52528" title="CVE-2023-52528" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52488" id="CVE-2023-52488" title="CVE-2023-52488" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52602" id="CVE-2023-52602" title="CVE-2023-52602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52603" id="CVE-2023-52603" title="CVE-2023-52603" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52593" id="CVE-2023-52593" title="CVE-2023-52593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52604" id="CVE-2023-52604" title="CVE-2023-52604" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26627" id="CVE-2024-26627" title="CVE-2024-26627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52494" id="CVE-2023-52494" title="CVE-2023-52494" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26624" id="CVE-2024-26624" title="CVE-2024-26624" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26625" id="CVE-2024-26625" title="CVE-2024-26625" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52502" id="CVE-2023-52502" title="CVE-2023-52502" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26622" id="CVE-2024-26622" title="CVE-2024-26622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52599" id="CVE-2023-52599" title="CVE-2023-52599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52600" id="CVE-2023-52600" title="CVE-2023-52600" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52622" id="CVE-2023-52622" title="CVE-2023-52622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23307" id="CVE-2024-23307" title="CVE-2024-23307" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47094" id="CVE-2021-47094" title="CVE-2021-47094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52601" id="CVE-2023-52601" title="CVE-2023-52601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46926" id="CVE-2021-46926" title="CVE-2021-46926" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52479" id="CVE-2023-52479" title="CVE-2023-52479" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52484" id="CVE-2023-52484" title="CVE-2023-52484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26593" id="CVE-2024-26593" title="CVE-2024-26593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26788" id="CVE-2024-26788" title="CVE-2024-26788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26607" id="CVE-2024-26607" title="CVE-2024-26607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26773" id="CVE-2024-26773" title="CVE-2024-26773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52469" id="CVE-2023-52469" title="CVE-2023-52469" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52475" id="CVE-2023-52475" title="CVE-2023-52475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26600" id="CVE-2024-26600" title="CVE-2024-26600" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47037" id="CVE-2021-47037" title="CVE-2021-47037" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52456" id="CVE-2023-52456" title="CVE-2023-52456" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26696" id="CVE-2024-26696" title="CVE-2024-26696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52467" id="CVE-2023-52467" title="CVE-2023-52467" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26608" id="CVE-2024-26608" title="CVE-2024-26608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26589" id="CVE-2024-26589" title="CVE-2024-26589" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26597" id="CVE-2024-26597" title="CVE-2024-26597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26606" id="CVE-2024-26606" title="CVE-2024-26606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52477" id="CVE-2023-52477" title="CVE-2023-52477" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52454" id="CVE-2023-52454" title="CVE-2023-52454" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52476" id="CVE-2023-52476" title="CVE-2023-52476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26654" id="CVE-2024-26654" title="CVE-2024-26654" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26603" id="CVE-2024-26603" title="CVE-2024-26603" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26644" id="CVE-2024-26644" title="CVE-2024-26644" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2639" id="CVE-2022-2639" title="CVE-2022-2639" type="cve"></reference>
		</references>
		<description>CVE-2024-1151:A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.&#xA;CVE-2023-52443:In the Linux kernel, the following vulnerability has been resolved:&#xA;apparmor: avoid crash when parsed profile name is empty&#xA;When processing a packed profile in unpack_profile() described like&#xA; &#34;profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}&#34;&#xA;a string &#34;:samba-dcerpcd&#34; is unpacked as a fully-qualified name and then&#xA;passed to aa_splitn_fqname().&#xA;aa_splitn_fqname() treats &#34;:samba-dcerpcd&#34; as only containing a namespace.&#xA;Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later&#xA;aa_alloc_profile() crashes as the new profile name is NULL now.&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014&#xA;RIP: 0010:strlen+0x1e/0xa0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? strlen+0x1e/0xa0&#xA; aa_policy_init+0x1bb/0x230&#xA; aa_alloc_profile+0xb1/0x480&#xA; unpack_profile+0x3bc/0x4960&#xA; aa_unpack+0x309/0x15e0&#xA; aa_replace_profiles+0x213/0x33c0&#xA; policy_update+0x261/0x370&#xA; profile_replace+0x20e/0x2a0&#xA; vfs_write+0x2af/0xe00&#xA; ksys_write+0x126/0x250&#xA; do_syscall_64+0x46/0xf0&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA; &lt;/TASK&gt;&#xA;---[ end trace 0000000000000000 ]---&#xA;RIP: 0010:strlen+0x1e/0xa0&#xA;It seems such behaviour of aa_splitn_fqname() is expected and checked in&#xA;other places where it is called (e.g. aa_remove_profiles). Well, there&#xA;is an explicit comment &#34;a ns name without a following profile is allowed&#34;&#xA;inside.&#xA;AFAICS, nothing can prevent unpacked &#34;name&#34; to be in form like&#xA;&#34;:samba-dcerpcd&#34; - it is passed from userspace.&#xA;Deny the whole profile set replacement in such case and inform user with&#xA;EPROTO and an explaining message.&#xA;Found by Linux Verification Center (linuxtesting.org).&#xA;CVE-2023-52463:In the Linux kernel, the following vulnerability has been resolved:&#xA;efivarfs: force RO when remounting if SetVariable is not supported&#xA;If SetVariable at runtime is not supported by the firmware we never assign&#xA;a callback for that function. At the same time mount the efivarfs as&#xA;RO so no one can call that.  However, we never check the permission flags&#xA;when someone remounts the filesystem as RW. As a result this leads to a&#xA;crash looking like this:&#xA;$ mount -o remount,rw /sys/firmware/efi/efivars&#xA;$ efi-updatevar -f PK.auth PK&#xA;[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000&#xA;[  303.280482] Mem abort info:&#xA;[  303.280854]   ESR = 0x0000000086000004&#xA;[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits&#xA;[  303.282016]   SET = 0, FnV = 0&#xA;[  303.282414]   EA = 0, S1PTW = 0&#xA;[  303.282821]   FSC = 0x04: level 0 translation fault&#xA;[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000&#xA;[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000&#xA;[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP&#xA;[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6&#xA;[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1&#xA;[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023&#xA;[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[  303.292123] pc : 0x0&#xA;[  303.292443] lr : efivar_set_variable_locked+0x74/0xec&#xA;[  303.293156] sp : ffff800008673c10&#xA;[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000&#xA;[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027&#xA;[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000&#xA;[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000&#xA;[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54&#xA;[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4&#xA;[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002&#xA;[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201&#xA;[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc&#xA;[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000&#xA;[  303.303341] Call trace:&#xA;[  303.303679]  0x0&#xA;[  303.303938]  efivar_entry_set_get_size+0x98/0x16c&#xA;[  303.304585]  efivarfs_file_write+0xd0/0x1a4&#xA;[  303.305148]  vfs_write+0xc4/0x2e4&#xA;[  303.305601]  ksys_write+0x70/0x104&#xA;[  303.306073]  __arm64_sys_write+0x1c/0x28&#xA;[  303.306622]  invoke_syscall+0x48/0x114&#xA;[  303.307156]  el0_svc_common.constprop.0+0x44/0xec&#xA;[  303.307803]  do_el0_svc+0x38/0x98&#xA;[  303.308268]  el0_svc+0x2c/0x84&#xA;[  303.308702]  el0t_64_sync_handler+0xf4/0x120&#xA;[  303.309293]  el0t_64_sync+0x190/0x194&#xA;[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)&#xA;[  303.310612] ---[ end trace 0000000000000000 ]---&#xA;Fix this by adding a .reconfigure() function to the fs operations which&#xA;we can use to check the requested flags and deny anything that&#39;s not RO&#xA;if the firmware doesn&#39;t implement SetVariable at runtime.&#xA;CVE-2024-26598:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache&#xA;There is a potential UAF scenario in the case of an LPI translation&#xA;cache hit racing with an operation that invalidates the cache, such&#xA;as a DISCARD ITS command. The root of the problem is that&#xA;vgic_its_check_cache() does not elevate the refcount on the vgic_irq&#xA;before dropping the lock that serializes refcount changes.&#xA;Have vgic_its_check_cache() raise the refcount on the returned vgic_irq&#xA;and add the corresponding decrement after queueing the interrupt.&#xA;CVE-2023-52448:In the Linux kernel, the following vulnerability has been resolved:&#xA;gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump&#xA;Syzkaller has reported a NULL pointer dereference when accessing&#xA;rgd-&gt;rd_rgl in gfs2_rgrp_dump().  This can happen when creating&#xA;rgd-&gt;rd_gl fails in read_rindex_entry().  Add a NULL pointer check in&#xA;gfs2_rgrp_dump() to prevent that.&#xA;CVE-2024-26595:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path&#xA;When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after&#xA;failing to attach the region to an ACL group, we hit a NULL pointer&#xA;dereference upon &#39;region-&gt;group-&gt;tcam&#39; [1].&#xA;Fix by retrieving the &#39;tcam&#39; pointer using mlxsw_sp_acl_to_tcam().&#xA;[1]&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[...]&#xA;RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0&#xA;[...]&#xA;Call Trace:&#xA; mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20&#xA; mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0&#xA; mlxsw_sp_acl_rule_add+0x47/0x240&#xA; mlxsw_sp_flower_replace+0x1a9/0x1d0&#xA; tc_setup_cb_add+0xdc/0x1c0&#xA; fl_hw_replace_filter+0x146/0x1f0&#xA; fl_change+0xc17/0x1360&#xA; tc_new_tfilter+0x472/0xb90&#xA; rtnetlink_rcv_msg+0x313/0x3b0&#xA; netlink_rcv_skb+0x58/0x100&#xA; netlink_unicast+0x244/0x390&#xA; netlink_sendmsg+0x1e4/0x440&#xA; ____sys_sendmsg+0x164/0x260&#xA; ___sys_sendmsg+0x9a/0xe0&#xA; __sys_sendmsg+0x7a/0xc0&#xA; do_syscall_64+0x40/0xe0&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;CVE-2023-52436:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: explicitly null-terminate the xattr list&#xA;When setting an xattr, explicitly null-terminate the xattr list.  This&#xA;eliminates the fragile assumption that the unused xattr space is always&#xA;zeroed.&#xA;CVE-2024-23850:In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.&#xA;CVE-2023-52438:In the Linux kernel, the following vulnerability has been resolved:&#xA;binder: fix use-after-free in shinker&#39;s callback&#xA;The mmap read lock is used during the shrinker&#39;s callback, which means&#xA;that using alloc-&gt;vma pointer isn&#39;t safe as it can race with munmap().&#xA;As of commit dd2283f2605e (&#34;mm: mmap: zap pages with read mmap_sem in&#xA;munmap&#34;) the mmap lock is downgraded after the vma has been isolated.&#xA;I was able to reproduce this issue by manually adding some delays and&#xA;triggering page reclaiming through the shrinker&#39;s debug sysfs. The&#xA;following KASAN report confirms the UAF:&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8&#xA;  Read of size 8 at addr ffff356ed50e50f0 by task bash/478&#xA;  CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70&#xA;  Hardware name: linux,dummy-virt (DT)&#xA;  Call trace:&#xA;   zap_page_range_single+0x470/0x4b8&#xA;   binder_alloc_free_page+0x608/0xadc&#xA;   __list_lru_walk_one+0x130/0x3b0&#xA;   list_lru_walk_node+0xc4/0x22c&#xA;   binder_shrink_scan+0x108/0x1dc&#xA;   shrinker_debugfs_scan_write+0x2b4/0x500&#xA;   full_proxy_write+0xd4/0x140&#xA;   vfs_write+0x1ac/0x758&#xA;   ksys_write+0xf0/0x1dc&#xA;   __arm64_sys_write+0x6c/0x9c&#xA;  Allocated by task 492:&#xA;   kmem_cache_alloc+0x130/0x368&#xA;   vm_area_alloc+0x2c/0x190&#xA;   mmap_region+0x258/0x18bc&#xA;   do_mmap+0x694/0xa60&#xA;   vm_mmap_pgoff+0x170/0x29c&#xA;   ksys_mmap_pgoff+0x290/0x3a0&#xA;   __arm64_sys_mmap+0xcc/0x144&#xA;  Freed by task 491:&#xA;   kmem_cache_free+0x17c/0x3c8&#xA;   vm_area_free_rcu_cb+0x74/0x98&#xA;   rcu_core+0xa38/0x26d4&#xA;   rcu_core_si+0x10/0x1c&#xA;   __do_softirq+0x2fc/0xd24&#xA;  Last potentially related work creation:&#xA;   __call_rcu_common.constprop.0+0x6c/0xba0&#xA;   call_rcu+0x10/0x1c&#xA;   vm_area_free+0x18/0x24&#xA;   remove_vma+0xe4/0x118&#xA;   do_vmi_align_munmap.isra.0+0x718/0xb5c&#xA;   do_vmi_munmap+0xdc/0x1fc&#xA;   __vm_munmap+0x10c/0x278&#xA;   __arm64_sys_munmap+0x58/0x7c&#xA;Fix this issue by performing instead a vma_lookup() which will fail to&#xA;find the vma that was isolated before the mmap lock downgrade. Note that&#xA;this option has better performance than upgrading to a mmap write lock&#xA;which would increase contention. Plus, mmap_write_trylock() has been&#xA;recently removed anyway.&#xA;CVE-2024-26583:In the Linux kernel, the following vulnerability has been resolved:&#xA;tls: fix race between async notify and socket close&#xA;The submitting thread (one which called recvmsg/sendmsg)&#xA;may exit as soon as the async crypto handler calls complete()&#xA;so any code past that point risks touching already freed data.&#xA;Try to avoid the locking and extra flags altogether.&#xA;Have the main thread hold an extra reference, this way&#xA;we can depend solely on the atomic ref counter for&#xA;synchronization.&#xA;Don&#39;t futz with reiniting the completion, either, we are now&#xA;tightly controlling when completion fires.&#xA;CVE-2023-52439:In the Linux kernel, the following vulnerability has been resolved:&#xA;uio: Fix use-after-free in uio_open&#xA;core-1&#x9;&#x9;&#x9;&#x9;core-2&#xA;-------------------------------------------------------&#xA;uio_unregister_device&#x9;&#x9;uio_open&#xA;&#x9;&#x9;&#x9;&#x9;idev = idr_find()&#xA;device_unregister(&amp;idev-&gt;dev)&#xA;put_device(&amp;idev-&gt;dev)&#xA;uio_device_release&#xA;&#x9;&#x9;&#x9;&#x9;get_device(&amp;idev-&gt;dev)&#xA;kfree(idev)&#xA;uio_free_minor(minor)&#xA;&#x9;&#x9;&#x9;&#x9;uio_release&#xA;&#x9;&#x9;&#x9;&#x9;put_device(&amp;idev-&gt;dev)&#xA;&#x9;&#x9;&#x9;&#x9;kfree(idev)&#xA;-------------------------------------------------------&#xA;In the core-1 uio_unregister_device(), the device_unregister will kfree&#xA;idev when the idev-&gt;dev kobject ref is 1. But after core-1&#xA;device_unregister, put_device and before doing kfree, the core-2 may&#xA;get_device. Then:&#xA;1. After core-1 kfree idev, the core-2 will do use-after-free for idev.&#xA;2. When core-2 do uio_release and put_device, the idev will be double&#xA;   freed.&#xA;To address this issue, we can get idev atomic &amp; inc idev reference with&#xA;minor_lock.&#xA;CVE-2023-52522:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: fix possible store tearing in neigh_periodic_work()&#xA;While looking at a related syzbot report involving neigh_periodic_work(),&#xA;I found that I forgot to add an annotation when deleting an&#xA;RCU protected item from a list.&#xA;Readers use rcu_deference(*np), we need to use either&#xA;rcu_assign_pointer() or WRITE_ONCE() on writer side&#xA;to prevent store tearing.&#xA;I use rcu_assign_pointer() to have lockdep support,&#xA;this was the choice made in neigh_flush_dev().&#xA;CVE-2023-52573:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: rds: Fix possible NULL-pointer dereference&#xA;In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists&#xA;before dereferencing it as rdma_set_service_type() argument&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-22099:NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.&#xA;This issue affects Linux kernel: v2.6.12-rc2.&#xA;CVE-2024-23851:copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel-&gt;data_size check. This is related to ctl_ioctl.&#xA;CVE-2023-52510:In the Linux kernel, the following vulnerability has been resolved:&#xA;ieee802154: ca8210: Fix a potential UAF in ca8210_probe&#xA;If of_clk_add_provider() fails in ca8210_register_ext_clock(),&#xA;it calls clk_unregister() to release priv-&gt;clk and returns an&#xA;error. However, the caller ca8210_probe() then calls ca8210_remove(),&#xA;where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). In&#xA;this case, a use-after-free may happen in the second time we call&#xA;clk_unregister().&#xA;Fix this by removing the first clk_unregister(). Also, priv-&gt;clk could&#xA;be an error code on failure of clk_register_fixed_rate(). Use&#xA;IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().&#xA;CVE-2023-52458:In the Linux kernel, the following vulnerability has been resolved:&#xA;block: add check that partition length needs to be aligned with block size&#xA;Before calling add partition or resize partition, there is no check&#xA;on whether the length is aligned with the logical block size.&#xA;If the logical block size of the disk is larger than 512 bytes,&#xA;then the partition size maybe not the multiple of the logical block size,&#xA;and when the last sector is read, bio_truncate() will adjust the bio size,&#xA;resulting in an IO error if the size of the read command is smaller than&#xA;the logical block size.If integrity data is supported, this will also&#xA;result in a null pointer dereference when calling bio_integrity_free.&#xA;CVE-2021-47014:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: act_ct: fix wild memory access when clearing fragments&#xA;while testing re-assembly/re-fragmentation using act_ct, it&#39;s possible to&#xA;observe a crash like the following one:&#xA; KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]&#xA; CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S                5.12.0-rc7+ #424&#xA; Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017&#xA; RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0&#xA; Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 &lt;42&gt; 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48&#xA; RSP: 0018:ffff888c31449db8 EFLAGS: 00010203&#xA; RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960&#xA; RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e&#xA; RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350&#xA; R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000&#xA; R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160&#xA; FS:  0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; Call Trace:&#xA;  &lt;IRQ&gt;&#xA;  inet_frag_destroy+0xa9/0x150&#xA;  call_timer_fn+0x2d/0x180&#xA;  run_timer_softirq+0x4fe/0xe70&#xA;  __do_softirq+0x197/0x5a0&#xA;  irq_exit_rcu+0x1de/0x200&#xA;  sysvec_apic_timer_interrupt+0x6b/0x80&#xA;  &lt;/IRQ&gt;&#xA;when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb&#xA;results in putting random data in FRAG_CB(), and this causes those &#34;wild&#34;&#xA;memory accesses later, when the rbtree is purged. Never overwrite the skb&#xA;cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.&#xA;CVE-2021-47036:In the Linux kernel, the following vulnerability has been resolved:&#xA;udp: skip L4 aggregation for UDP tunnel packets&#xA;If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there&#xA;are UDP tunnels available in the system, udp_gro_receive() could end-up&#xA;doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at&#xA;the outer UDP tunnel level for packets effectively carrying and UDP&#xA;tunnel header.&#xA;That could cause inner protocol corruption. If e.g. the relevant&#xA;packets carry a vxlan header, different vxlan ids will be ignored/&#xA;aggregated to the same GSO packet. Inner headers will be ignored, too,&#xA;so that e.g. TCP over vxlan push packets will be held in the GRO&#xA;engine till the next flush, etc.&#xA;Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the&#xA;current packet could land in a UDP tunnel, and let udp_gro_receive()&#xA;do GRO via udp_sk(sk)-&gt;gro_receive.&#xA;The check implemented in this patch is broader than what is strictly&#xA;needed, as the existing UDP tunnel could be e.g. configured on top of&#xA;a different device: we could end-up skipping GRO at-all for some packets.&#xA;Anyhow, that is a very thin corner case and covering it will add quite&#xA;a bit of complexity.&#xA;v1 -&gt; v2:&#xA; - hopefully clarify the commit message&#xA;CVE-2023-52566:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()&#xA;In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the&#xA;reference count of bh when the call to nilfs_dat_translate() fails.  If&#xA;the reference count hits 0 and its owner page gets unlocked, bh may be&#xA;freed.  However, bh-&gt;b_page is dereferenced to put the page after that,&#xA;which may result in a use-after-free bug.  This patch moves the release&#xA;operation after unlocking and putting the page.&#xA;NOTE: The function in question is only called in GC, and in combination&#xA;with current userland tools, address translation using DAT does not occur&#xA;in that function, so the code path that causes this issue will not be&#xA;executed.  However, it is possible to run that code path by intentionally&#xA;modifying the userland GC library or by calling the GC ioctl directly.&#xA;[konishi.ryusuke@gmail.com: NOTE added to the commit log]&#xA;CVE-2021-47028:In the Linux kernel, the following vulnerability has been resolved:&#xA;mt76: mt7915: fix txrate reporting&#xA;Properly check rate_info to fix unexpected reporting.&#xA;[ 1215.161863] Call trace:&#xA;[ 1215.164307]  cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]&#xA;[ 1215.170139]  ieee80211s_update_metric+0x80/0xc0 [mac80211]&#xA;[ 1215.175624]  ieee80211_tx_status_ext+0x508/0x838 [mac80211]&#xA;[ 1215.181190]  mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]&#xA;[ 1215.186580]  mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]&#xA;[ 1215.191623]  mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]&#xA;[ 1215.196582]  mt76_dma_cleanup+0x7b0/0x11d0 [mt76]&#xA;[ 1215.201276]  __napi_poll+0x38/0xf8&#xA;[ 1215.204668]  napi_workfn+0x40/0x80&#xA;[ 1215.208062]  process_one_work+0x1fc/0x390&#xA;[ 1215.212062]  worker_thread+0x48/0x4d0&#xA;[ 1215.215715]  kthread+0x120/0x128&#xA;[ 1215.218935]  ret_from_fork+0x10/0x1c&#xA;CVE-2023-52568:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race&#xA;The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an&#xA;enclave and set secs.epc_page to NULL. The SECS page is used for EAUG&#xA;and ELDU in the SGX page fault handler. However, the NULL check for&#xA;secs.epc_page is only done for ELDU, not EAUG before being used.&#xA;Fix this by doing the same NULL check and reloading of the SECS page as&#xA;needed for both EAUG and ELDU.&#xA;The SECS page holds global enclave metadata. It can only be reclaimed&#xA;when there are no other enclave pages remaining. At that point,&#xA;virtually nothing can be done with the enclave until the SECS page is&#xA;paged back in.&#xA;An enclave can not run nor generate page faults without a resident SECS&#xA;page. But it is still possible for a #PF for a non-SECS page to race&#xA;with paging out the SECS page: when the last resident non-SECS page A&#xA;triggers a #PF in a non-resident page B, and then page A and the SECS&#xA;both are paged out before the #PF on B is handled.&#xA;Hitting this bug requires that race triggered with a #PF for EAUG.&#xA;Following is a trace when it happens.&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;RIP: 0010:sgx_encl_eaug_page+0xc7/0x210&#xA;Call Trace:&#xA; ? __kmem_cache_alloc_node+0x16a/0x440&#xA; ? xa_load+0x6e/0xa0&#xA; sgx_vma_fault+0x119/0x230&#xA; __do_fault+0x36/0x140&#xA; do_fault+0x12f/0x400&#xA; __handle_mm_fault+0x728/0x1110&#xA; handle_mm_fault+0x105/0x310&#xA; do_user_addr_fault+0x1ee/0x750&#xA; ? __this_cpu_preempt_check+0x13/0x20&#xA; exc_page_fault+0x76/0x180&#xA; asm_exc_page_fault+0x27/0x30&#xA;CVE-2023-52449:In the Linux kernel, the following vulnerability has been resolved:&#xA;mtd: Fix gluebi NULL pointer dereference caused by ftl notifier&#xA;If both ftl.ko and gluebi.ko are loaded, the notifier of ftl&#xA;triggers NULL pointer dereference when trying to access&#xA;‘gluebi-&gt;desc’ in gluebi_read().&#xA;ubi_gluebi_init&#xA;  ubi_register_volume_notifier&#xA;    ubi_enumerate_volumes&#xA;      ubi_notify_all&#xA;        gluebi_notify    nb-&gt;notifier_call()&#xA;          gluebi_create&#xA;            mtd_device_register&#xA;              mtd_device_parse_register&#xA;                add_mtd_device&#xA;                  blktrans_notify_add   not-&gt;add()&#xA;                    ftl_add_mtd         tr-&gt;add_mtd()&#xA;                      scan_header&#xA;                        mtd_read&#xA;                          mtd_read_oob&#xA;                            mtd_read_oob_std&#xA;                              gluebi_read   mtd-&gt;read()&#xA;                                gluebi-&gt;desc - NULL&#xA;Detailed reproduction information available at the Link [1],&#xA;In the normal case, obtain gluebi-&gt;desc in the gluebi_get_device(),&#xA;and access gluebi-&gt;desc in the gluebi_read(). However,&#xA;gluebi_get_device() is not executed in advance in the&#xA;ftl_add_mtd() process, which leads to NULL pointer dereference.&#xA;The solution for the gluebi module is to run jffs2 on the UBI&#xA;volume without considering working with ftl or mtdblock [2].&#xA;Therefore, this problem can be avoided by preventing gluebi from&#xA;creating the mtdblock device after creating mtd partition of the&#xA;type MTD_UBIVOLUME.&#xA;CVE-2023-52447:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Defer the free of inner map when necessary&#xA;When updating or deleting an inner map in map array or map htab, the map&#xA;may still be accessed by non-sleepable program or sleepable program.&#xA;However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map&#xA;directly through bpf_map_put(), if the ref-counter is the last one&#xA;(which is true for most cases), the inner map will be freed by&#xA;ops-&gt;map_free() in a kworker. But for now, most .map_free() callbacks&#xA;don&#39;t use synchronize_rcu() or its variants to wait for the elapse of a&#xA;RCU grace period, so after the invocation of ops-&gt;map_free completes,&#xA;the bpf program which is accessing the inner map may incur&#xA;use-after-free problem.&#xA;Fix the free of inner map by invoking bpf_map_free_deferred() after both&#xA;one RCU grace period and one tasks trace RCU grace period if the inner&#xA;map has been removed from the outer map before. The deferment is&#xA;accomplished by using call_rcu() or call_rcu_tasks_trace() when&#xA;releasing the last ref-counter of bpf map. The newly-added rcu_head&#xA;field in bpf_map shares the same storage space with work field to&#xA;reduce the size of bpf_map.&#xA;CVE-2023-52452:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix accesses to uninit stack slots&#xA;Privileged programs are supposed to be able to read uninitialized stack&#xA;memory (ever since 6715df8d5) but, before this patch, these accesses&#xA;were permitted inconsistently. In particular, accesses were permitted&#xA;above state-&gt;allocated_stack, but not below it. In other words, if the&#xA;stack was already &#34;large enough&#34;, the access was permitted, but&#xA;otherwise the access was rejected instead of being allowed to &#34;grow the&#xA;stack&#34;. This undesired rejection was happening in two places:&#xA;- in check_stack_slot_within_bounds()&#xA;- in check_stack_range_initialized()&#xA;This patch arranges for these accesses to be permitted. A bunch of tests&#xA;that were relying on the old rejection had to change; all of them were&#xA;changed to add also run unprivileged, in which case the old behavior&#xA;persists. One tests couldn&#39;t be updated - global_func16 - because it&#xA;can&#39;t run unprivileged for other reasons.&#xA;This patch also fixes the tracking of the stack size for variable-offset&#xA;reads. This second fix is bundled in the same commit as the first one&#xA;because they&#39;re inter-related. Before this patch, writes to the stack&#xA;using registers containing a variable offset (as opposed to registers&#xA;with fixed, known values) were not properly contributing to the&#xA;function&#39;s needed stack size. As a result, it was possible for a program&#xA;to verify, but then to attempt to read out-of-bounds data at runtime&#xA;because a too small stack had been allocated for it.&#xA;Each function tracks the size of the stack it needs in&#xA;bpf_subprog_info.stack_depth, which is maintained by&#xA;update_stack_depth(). For regular memory accesses, check_mem_access()&#xA;was calling update_state_depth() but it was passing in only the fixed&#xA;part of the offset register, ignoring the variable offset. This was&#xA;incorrect; the minimum possible value of that register should be used&#xA;instead.&#xA;This tracking is now fixed by centralizing the tracking of stack size in&#xA;grow_stack_state(), and by lifting the calls to grow_stack_state() to&#xA;check_stack_access_within_bounds() as suggested by Andrii. The code is&#xA;now simpler and more convincingly tracks the correct maximum stack size.&#xA;check_stack_range_initialized() can now rely on enough stack having been&#xA;allocated for the access; this helps with the fix for the first issue.&#xA;A few tests were changed to also check the stack depth computation. The&#xA;one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.&#xA;CVE-2023-52451:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/pseries/memhp: Fix access beyond end of drmem array&#xA;dlpar_memory_remove_by_index() may access beyond the bounds of the&#xA;drmem lmb array when the LMB lookup fails to match an entry with the&#xA;given DRC index. When the search fails, the cursor is left pointing to&#xA;&amp;drmem_info-&gt;lmbs[drmem_info-&gt;n_lmbs], which is one element past the&#xA;last valid entry in the array. The debug message at the end of the&#xA;function then dereferences this pointer:&#xA;        pr_debug(&#34;Failed to hot-remove memory at %llx\n&#34;,&#xA;                 lmb-&gt;base_addr);&#xA;This was found by inspection and confirmed with KASAN:&#xA;  pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658&#xA;  Read of size 8 at addr c000000364e97fd0 by task bash/949&#xA;  dump_stack_lvl+0xa4/0xfc (unreliable)&#xA;  print_report+0x214/0x63c&#xA;  kasan_report+0x140/0x2e0&#xA;  __asan_load8+0xa8/0xe0&#xA;  dlpar_memory+0x298/0x1658&#xA;  handle_dlpar_errorlog+0x130/0x1d0&#xA;  dlpar_store+0x18c/0x3e0&#xA;  kobj_attr_store+0x68/0xa0&#xA;  sysfs_kf_write+0xc4/0x110&#xA;  kernfs_fop_write_iter+0x26c/0x390&#xA;  vfs_write+0x2d4/0x4e0&#xA;  ksys_write+0xac/0x1a0&#xA;  system_call_exception+0x268/0x530&#xA;  system_call_vectored_common+0x15c/0x2ec&#xA;  Allocated by task 1:&#xA;   kasan_save_stack+0x48/0x80&#xA;   kasan_set_track+0x34/0x50&#xA;   kasan_save_alloc_info+0x34/0x50&#xA;   __kasan_kmalloc+0xd0/0x120&#xA;   __kmalloc+0x8c/0x320&#xA;   kmalloc_array.constprop.0+0x48/0x5c&#xA;   drmem_init+0x2a0/0x41c&#xA;   do_one_initcall+0xe0/0x5c0&#xA;   kernel_init_freeable+0x4ec/0x5a0&#xA;   kernel_init+0x30/0x1e0&#xA;   ret_from_kernel_user_thread+0x14/0x1c&#xA;  The buggy address belongs to the object at c000000364e80000&#xA;   which belongs to the cache kmalloc-128k of size 131072&#xA;  The buggy address is located 0 bytes to the right of&#xA;   allocated 98256-byte region [c000000364e80000, c000000364e97fd0)&#xA;  ==================================================================&#xA;  pseries-hotplug-mem: Failed to hot-remove memory at 0&#xA;Log failed lookups with a separate message and dereference the&#xA;cursor only when it points to a valid entry.&#xA;CVE-2023-52583:In the Linux kernel, the following vulnerability has been resolved:&#xA;ceph: fix deadlock or deadcode of misusing dget()&#xA;The lock order is incorrect between denty and its parent, we should&#xA;always make sure that the parent get the lock first.&#xA;But since this deadcode is never used and the parent dir will always&#xA;be set from the callers, let&#39;s just remove it.&#xA;CVE-2023-52606:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/lib: Validate size for vector operations&#xA;Some of the fp/vmx code in sstep.c assume a certain maximum size for the&#xA;instructions being emulated. The size of those operations however is&#xA;determined separately in analyse_instr().&#xA;Add a check to validate the assumption on the maximum size of the&#xA;operations, so as to prevent any unintended kernel stack corruption.&#xA;CVE-2023-52486:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm: Don&#39;t unref the same fb many times by mistake due to deadlock handling&#xA;If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()&#xA;we proceed to unref the fb and then retry the whole thing from the top.&#xA;But we forget to reset the fb pointer back to NULL, and so if we then&#xA;get another error during the retry, before the fb lookup, we proceed&#xA;the unref the same fb again without having gotten another reference.&#xA;The end result is that the fb will (eventually) end up being freed&#xA;while it&#39;s still in use.&#xA;Reset fb to NULL once we&#39;ve unreffed it to avoid doing it again&#xA;until we&#39;ve done another fb lookup.&#xA;This turned out to be pretty easy to hit on a DG2 when doing async&#xA;flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I&#xA;saw that drm_closefb() simply got stuck in a busy loop while walking&#xA;the framebuffer list. Fortunately I was able to convince it to oops&#xA;instead, and from there it was easier to track down the culprit.&#xA;CVE-2021-46987:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix deadlock when cloning inline extents and using qgroups&#xA;There are a few exceptional cases where cloning an inline extent needs to&#xA;copy the inline extent data into a page of the destination inode.&#xA;When this happens, we end up starting a transaction while having a dirty&#xA;page for the destination inode and while having the range locked in the&#xA;destination&#39;s inode iotree too. Because when reserving metadata space&#xA;for a transaction we may need to flush existing delalloc in case there is&#xA;not enough free space, we have a mechanism in place to prevent a deadlock,&#xA;which was introduced in commit 3d45f221ce627d (&#34;btrfs: fix deadlock when&#xA;cloning inline extent and low on free metadata space&#34;).&#xA;However when using qgroups, a transaction also reserves metadata qgroup&#xA;space, which can also result in flushing delalloc in case there is not&#xA;enough available space at the moment. When this happens we deadlock, since&#xA;flushing delalloc requires locking the file range in the inode&#39;s iotree&#xA;and the range was already locked at the very beginning of the clone&#xA;operation, before attempting to start the transaction.&#xA;When this issue happens, stack traces like the following are reported:&#xA;  [72747.556262] task:kworker/u81:9   state:D stack:    0 pid:  225 ppid:     2 flags:0x00004000&#xA;  [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)&#xA;  [72747.556271] Call Trace:&#xA;  [72747.556273]  __schedule+0x296/0x760&#xA;  [72747.556277]  schedule+0x3c/0xa0&#xA;  [72747.556279]  io_schedule+0x12/0x40&#xA;  [72747.556284]  __lock_page+0x13c/0x280&#xA;  [72747.556287]  ? generic_file_readonly_mmap+0x70/0x70&#xA;  [72747.556325]  extent_write_cache_pages+0x22a/0x440 [btrfs]&#xA;  [72747.556331]  ? __set_page_dirty_nobuffers+0xe7/0x160&#xA;  [72747.556358]  ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]&#xA;  [72747.556362]  ? update_group_capacity+0x25/0x210&#xA;  [72747.556366]  ? cpumask_next_and+0x1a/0x20&#xA;  [72747.556391]  extent_writepages+0x44/0xa0 [btrfs]&#xA;  [72747.556394]  do_writepages+0x41/0xd0&#xA;  [72747.556398]  __writeback_single_inode+0x39/0x2a0&#xA;  [72747.556403]  writeback_sb_inodes+0x1ea/0x440&#xA;  [72747.556407]  __writeback_inodes_wb+0x5f/0xc0&#xA;  [72747.556410]  wb_writeback+0x235/0x2b0&#xA;  [72747.556414]  ? get_nr_inodes+0x35/0x50&#xA;  [72747.556417]  wb_workfn+0x354/0x490&#xA;  [72747.556420]  ? newidle_balance+0x2c5/0x3e0&#xA;  [72747.556424]  process_one_work+0x1aa/0x340&#xA;  [72747.556426]  worker_thread+0x30/0x390&#xA;  [72747.556429]  ? create_worker+0x1a0/0x1a0&#xA;  [72747.556432]  kthread+0x116/0x130&#xA;  [72747.556435]  ? kthread_park+0x80/0x80&#xA;  [72747.556438]  ret_from_fork+0x1f/0x30&#xA;  [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]&#xA;  [72747.566961] Call Trace:&#xA;  [72747.566964]  __schedule+0x296/0x760&#xA;  [72747.566968]  ? finish_wait+0x80/0x80&#xA;  [72747.566970]  schedule+0x3c/0xa0&#xA;  [72747.566995]  wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]&#xA;  [72747.566999]  ? finish_wait+0x80/0x80&#xA;  [72747.567024]  lock_extent_bits+0x37/0x90 [btrfs]&#xA;  [72747.567047]  btrfs_invalidatepage+0x299/0x2c0 [btrfs]&#xA;  [72747.567051]  ? find_get_pages_range_tag+0x2cd/0x380&#xA;  [72747.567076]  __extent_writepage+0x203/0x320 [btrfs]&#xA;  [72747.567102]  extent_write_cache_pages+0x2bb/0x440 [btrfs]&#xA;  [72747.567106]  ? update_load_avg+0x7e/0x5f0&#xA;  [72747.567109]  ? enqueue_entity+0xf4/0x6f0&#xA;  [72747.567134]  extent_writepages+0x44/0xa0 [btrfs]&#xA;  [72747.567137]  ? enqueue_task_fair+0x93/0x6f0&#xA;  [72747.567140]  do_writepages+0x41/0xd0&#xA;  [72747.567144]  __filemap_fdatawrite_range+0xc7/0x100&#xA;  [72747.567167]  btrfs_run_delalloc_work+0x17/0x40 [btrfs]&#xA;  [72747.567195]  btrfs_work_helper+0xc2/0x300 [btrfs]&#xA;  [72747.567200]  process_one_work+0x1aa/0x340&#xA;  [72747.567202]  worker_thread+0x30/0x390&#xA;  [72747.567205]  ? create_worker+0x1a0/0x1a0&#xA;  [72747.567208]  kthread+0x116/0x130&#xA;  [72747.567211]  ? kthread_park+0x80/0x80&#xA;  [72747.567214]  ret_from_fork+0x1f/0x30&#xA;  [72747.569686] task:fsstress        state:D stack:    &#xA;---truncated---&#xA;CVE-2023-52507:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: nci: assert requested protocol is valid&#xA;The protocol is used in a bit mask to determine if the protocol is&#xA;supported. Assert the provided protocol is less than the maximum&#xA;defined so it doesn&#39;t potentially perform a shift-out-of-bounds and&#xA;provide a clearer error for undefined protocols vs unsupported ones.&#xA;CVE-2023-52515:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/srp: Do not call scsi_done() from srp_abort()&#xA;After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler&#xA;callback, it performs one of the following actions:&#xA;* Call scsi_queue_insert().&#xA;* Call scsi_finish_command().&#xA;* Call scsi_eh_scmd_add().&#xA;Hence, SCSI abort handlers must not call scsi_done(). Otherwise all&#xA;the above actions would trigger a use-after-free. Hence remove the&#xA;scsi_done() call from srp_abort(). Keep the srp_free_req() call&#xA;before returning SUCCESS because we may not see the command again if&#xA;SUCCESS is returned.&#xA;CVE-2024-26586:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix stack corruption&#xA;When tc filters are first added to a net device, the corresponding local&#xA;port gets bound to an ACL group in the device. The group contains a list&#xA;of ACLs. In turn, each ACL points to a different TCAM region where the&#xA;filters are stored. During forwarding, the ACLs are sequentially&#xA;evaluated until a match is found.&#xA;One reason to place filters in different regions is when they are added&#xA;with decreasing priorities and in an alternating order so that two&#xA;consecutive filters can never fit in the same region because of their&#xA;key usage.&#xA;In Spectrum-2 and newer ASICs the firmware started to report that the&#xA;maximum number of ACLs in a group is more than 16, but the layout of the&#xA;register that configures ACL groups (PAGT) was not updated to account&#xA;for that. It is therefore possible to hit stack corruption [1] in the&#xA;rare case where more than 16 ACLs in a group are required.&#xA;Fix by limiting the maximum ACL group size to the minimum between what&#xA;the firmware reports and the maximum ACLs that fit in the PAGT register.&#xA;Add a test case to make sure the machine does not crash when this&#xA;condition is hit.&#xA;[1]&#xA;Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120&#xA;[...]&#xA; dump_stack_lvl+0x36/0x50&#xA; panic+0x305/0x330&#xA; __stack_chk_fail+0x15/0x20&#xA; mlxsw_sp_acl_tcam_group_update+0x116/0x120&#xA; mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110&#xA; mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20&#xA; mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0&#xA; mlxsw_sp_acl_rule_add+0x47/0x240&#xA; mlxsw_sp_flower_replace+0x1a9/0x1d0&#xA; tc_setup_cb_add+0xdc/0x1c0&#xA; fl_hw_replace_filter+0x146/0x1f0&#xA; fl_change+0xc17/0x1360&#xA; tc_new_tfilter+0x472/0xb90&#xA; rtnetlink_rcv_msg+0x313/0x3b0&#xA; netlink_rcv_skb+0x58/0x100&#xA; netlink_unicast+0x244/0x390&#xA; netlink_sendmsg+0x1e4/0x440&#xA; ____sys_sendmsg+0x164/0x260&#xA; ___sys_sendmsg+0x9a/0xe0&#xA; __sys_sendmsg+0x7a/0xc0&#xA; do_syscall_64+0x40/0xe0&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;CVE-2021-47076:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/rxe: Return CQE error if invalid lkey was supplied&#xA;RXE is missing update of WQE status in LOCAL_WRITE failures.  This caused&#xA;the following kernel panic if someone sent an atomic operation with an&#xA;explicitly wrong lkey.&#xA;[leonro@vm ~]$ mkt test&#xA;test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ...&#xA; WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe]&#xA; Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core&#xA; CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA; RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe]&#xA; Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff &lt;0f&gt; 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff&#xA; RSP: 0018:ffff8880158af090 EFLAGS: 00010246&#xA; RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652&#xA; RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210&#xA; RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b&#xA; R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8&#xA; R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c&#xA; FS:  00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; Call Trace:&#xA;  rxe_do_task+0x130/0x230 [rdma_rxe]&#xA;  rxe_rcv+0xb11/0x1df0 [rdma_rxe]&#xA;  rxe_loopback+0x157/0x1e0 [rdma_rxe]&#xA;  rxe_responder+0x5532/0x7620 [rdma_rxe]&#xA;  rxe_do_task+0x130/0x230 [rdma_rxe]&#xA;  rxe_rcv+0x9c8/0x1df0 [rdma_rxe]&#xA;  rxe_loopback+0x157/0x1e0 [rdma_rxe]&#xA;  rxe_requester+0x1efd/0x58c0 [rdma_rxe]&#xA;  rxe_do_task+0x130/0x230 [rdma_rxe]&#xA;  rxe_post_send+0x998/0x1860 [rdma_rxe]&#xA;  ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs]&#xA;  ib_uverbs_write+0x847/0xc80 [ib_uverbs]&#xA;  vfs_write+0x1c5/0x840&#xA;  ksys_write+0x176/0x1d0&#xA;  do_syscall_64+0x3f/0x80&#xA;  entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;CVE-2023-52524:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: nfc: llcp: Add lock when modifying device list&#xA;The device list needs its associated lock held when modifying it, or the&#xA;list could become corrupted, as syzbot discovered.&#xA;CVE-2023-52527:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()&#xA;Including the transhdrlen in length is a problem when the packet is&#xA;partially filled (e.g. something like send(MSG_MORE) happened previously)&#xA;when appending to an IPv4 or IPv6 packet as we don&#39;t want to repeat the&#xA;transport header or account for it twice.  This can happen under some&#xA;circumstances, such as splicing into an L2TP socket.&#xA;The symptom observed is a warning in __ip6_append_data():&#xA;    WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800&#xA;that occurs when MSG_SPLICE_PAGES is used to append more data to an already&#xA;partially occupied skbuff.  The warning occurs when &#39;copy&#39; is larger than&#xA;the amount of data in the message iterator.  This is because the requested&#xA;length includes the transport header length when it shouldn&#39;t.  This can be&#xA;triggered by, for example:&#xA;        sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);&#xA;        bind(sfd, ...); // ::1&#xA;        connect(sfd, ...); // ::1 port 7&#xA;        send(sfd, buffer, 4100, MSG_MORE);&#xA;        sendfile(sfd, dfd, NULL, 1024);&#xA;Fix this by only adding transhdrlen into the length if the write queue is&#xA;empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.&#xA;l2tp_ip_sendmsg() looks like it won&#39;t suffer from this problem as it builds&#xA;the UDP packet itself.&#xA;CVE-2023-52445:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: pvrusb2: fix use after free on context disconnection&#xA;Upon module load, a kthread is created targeting the&#xA;pvr2_context_thread_func function, which may call pvr2_context_destroy&#xA;and thus call kfree() on the context object. However, that might happen&#xA;before the usb hub_event handler is able to notify the driver. This&#xA;patch adds a sanity check before the invalid read reported by syzbot,&#xA;within the context disconnection call stack.&#xA;CVE-2023-52500:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command&#xA;Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed&#xA;when we receive the response.&#xA;CVE-2023-52528:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg&#xA;syzbot reported the following uninit-value access issue: =====================================================&#xA;BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]&#xA;BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482&#xA;CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;Workqueue: usb_hub_wq hub_event&#xA;Call Trace:&#xA; __dump_stack lib/dump_stack.c:77 [inline]&#xA; dump_stack+0x21c/0x280 lib/dump_stack.c:118&#xA; kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121&#xA; __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215&#xA; smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]&#xA; smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482&#xA; usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737&#xA; usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374&#xA; really_probe+0xf20/0x20b0 drivers/base/dd.c:529&#xA; driver_probe_device+0x293/0x390 drivers/base/dd.c:701&#xA; __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807&#xA; bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431&#xA; __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873&#xA; device_initial_probe+0x4a/0x60 drivers/base/dd.c:920&#xA; bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491&#xA; device_add+0x3b0e/0x40d0 drivers/base/core.c:2680&#xA; usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032&#xA; usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241&#xA; usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272&#xA; really_probe+0xf20/0x20b0 drivers/base/dd.c:529&#xA; driver_probe_device+0x293/0x390 drivers/base/dd.c:701&#xA; __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807&#xA; bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431&#xA; __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873&#xA; device_initial_probe+0x4a/0x60 drivers/base/dd.c:920&#xA; bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491&#xA; device_add+0x3b0e/0x40d0 drivers/base/core.c:2680&#xA; usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554&#xA; hub_port_connect drivers/usb/core/hub.c:5208 [inline]&#xA; hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]&#xA; port_event drivers/usb/core/hub.c:5494 [inline]&#xA; hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576&#xA; process_one_work+0x1688/0x2140 kernel/workqueue.c:2269&#xA; worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415&#xA; kthread+0x551/0x590 kernel/kthread.c:292&#xA; ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293&#xA;Local variable ----buf.i87@smsc75xx_bind created at:&#xA; __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]&#xA; smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]&#xA; smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482&#xA; __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]&#xA; smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]&#xA; smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482&#xA;This issue is caused because usbnet_read_cmd() reads less bytes than requested&#xA;(zero byte in the reproducer). In this case, &#39;buf&#39; is not properly filled.&#xA;This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads&#xA;less bytes than requested.&#xA;CVE-2023-52488:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO&#xA;The SC16IS7XX IC supports a burst mode to access the FIFOs where the&#xA;initial register address is sent ($00), followed by all the FIFO data&#xA;without having to resend the register address each time. In this mode, the&#xA;IC doesn&#39;t increment the register address for each R/W byte.&#xA;The regmap_raw_read() and regmap_raw_write() are functions which can&#xA;perform IO over multiple registers. They are currently used to read/write&#xA;from/to the FIFO, and although they operate correctly in this burst mode on&#xA;the SPI bus, they would corrupt the regmap cache if it was not disabled&#xA;manually. The reason is that when the R/W size is more than 1 byte, these&#xA;functions assume that the register address is incremented and handle the&#xA;cache accordingly.&#xA;Convert FIFO R/W functions to use the regmap _noinc_ versions in order to&#xA;remove the manual cache control which was a workaround when using the&#xA;_raw_ versions. FIFO registers are properly declared as volatile so&#xA;cache will not be used/updated for FIFO accesses.&#xA;CVE-2023-52602:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix slab-out-of-bounds Read in dtSearch&#xA;Currently while searching for current page in the sorted entry table&#xA;of the page there is a out of bound access. Added a bound check to fix&#xA;the error.&#xA;Dave:&#xA;Set return code to -EIO&#xA;CVE-2023-52603:In the Linux kernel, the following vulnerability has been resolved:&#xA;UBSAN: array-index-out-of-bounds in dtSplitRoot&#xA;Syzkaller reported the following issue:&#xA;oop0: detected capacity change from 0 to 32768&#xA;UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9&#xA;index -2 is out of range for type &#39;struct dtslot [128]&#39;&#xA;CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106&#xA; ubsan_epilogue lib/ubsan.c:151 [inline]&#xA; __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283&#xA; dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971&#xA; dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]&#xA; dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863&#xA; jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270&#xA; vfs_mkdir+0x3b3/0x590 fs/namei.c:4013&#xA; do_mkdirat+0x279/0x550 fs/namei.c:4038&#xA; __do_sys_mkdirat fs/namei.c:4053 [inline]&#xA; __se_sys_mkdirat fs/namei.c:4051 [inline]&#xA; __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;RIP: 0033:0x7fcdc0113fd9&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102&#xA;RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9&#xA;RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003&#xA;RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0&#xA;R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000&#xA;R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000&#xA; &lt;/TASK&gt;&#xA;The issue is caused when the value of fsi becomes less than -1.&#xA;The check to break the loop when fsi value becomes -1 is present&#xA;but syzbot was able to produce value less than -1 which cause the error.&#xA;This patch simply add the change for the values less than 0.&#xA;The patch is tested via syzbot.&#xA;CVE-2023-52593:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()&#xA;Since &#39;ieee80211_beacon_get()&#39; can return NULL, &#39;wfx_set_mfp_ap()&#39;&#xA;should check the return value before examining skb data. So convert&#xA;the latter to return an appropriate error code and propagate it to&#xA;return from &#39;wfx_start_ap()&#39; as well. Compile tested only.&#xA;CVE-2023-52604:In the Linux kernel, the following vulnerability has been resolved:&#xA;FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree&#xA;Syzkaller reported the following issue:&#xA;UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6&#xA;index 196694 is out of range for type &#39;s8[1365]&#39; (aka &#39;signed char[1365]&#39;)&#xA;CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106&#xA; ubsan_epilogue lib/ubsan.c:217 [inline]&#xA; __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348&#xA; dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867&#xA; dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834&#xA; dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331&#xA; dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]&#xA; dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402&#xA; txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534&#xA; txUpdateMap+0x342/0x9e0&#xA; txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]&#xA; jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732&#xA; kthread+0x2d3/0x370 kernel/kthread.c:388&#xA; ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 &lt;/TASK&gt; ================================================================================&#xA;Kernel panic - not syncing: UBSAN: panic_on_warn set ...&#xA;CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106&#xA; panic+0x30f/0x770 kernel/panic.c:340&#xA; check_panic_on_warn+0x82/0xa0 kernel/panic.c:236&#xA; ubsan_epilogue lib/ubsan.c:223 [inline]&#xA; __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348&#xA; dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867&#xA; dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834&#xA; dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331&#xA; dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]&#xA; dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402&#xA; txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534&#xA; txUpdateMap+0x342/0x9e0&#xA; txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]&#xA; jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732&#xA; kthread+0x2d3/0x370 kernel/kthread.c:388&#xA; ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304&#xA; &lt;/TASK&gt;&#xA;Kernel Offset: disabled&#xA;Rebooting in 86400 seconds..&#xA;The issue is caused when the value of lp becomes greater than&#xA;CTLTREESIZE which is the max size of stree. Adding a simple check&#xA;solves this issue.&#xA;Dave:&#xA;As the function returns a void, good error handling&#xA;would require a more intrusive code reorganization, so I modified&#xA;Osama&#39;s patch at use WARN_ON_ONCE for lack of a cleaner option.&#xA;The patch is tested via syzbot.&#xA;CVE-2024-26627:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler&#xA;Inside scsi_eh_wakeup(), scsi_host_busy() is called &amp; checked with host&#xA;lock every time for deciding if error handler kthread needs to be waken up.&#xA;This can be too heavy in case of recovery, such as:&#xA; - N hardware queues&#xA; - queue depth is M for each hardware queue&#xA; - each scsi_host_busy() iterates over (N * M) tag/requests&#xA;If recovery is triggered in case that all requests are in-flight, each&#xA;scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called&#xA;for the last in-flight request, scsi_host_busy() has been run for (N * M -&#xA;1) times, and request has been iterated for (N*M - 1) * (N * M) times.&#xA;If both N and M are big enough, hard lockup can be triggered on acquiring&#xA;host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).&#xA;Fix the issue by calling scsi_host_busy() outside the host lock. We don&#39;t&#xA;need the host lock for getting busy count because host the lock never&#xA;covers that.&#xA;[mkp: Drop unnecessary &#39;busy&#39; variables pointed out by Bart]&#xA;CVE-2023-52494:In the Linux kernel, the following vulnerability has been resolved:&#xA;bus: mhi: host: Add alignment check for event ring read pointer&#xA;Though we do check the event ring read pointer by &#34;is_valid_ring_ptr&#34;&#xA;to make sure it is in the buffer range, but there is another risk the&#xA;pointer may be not aligned.  Since we are expecting event ring elements&#xA;are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer&#xA;could lead to multiple issues like DoS or ring buffer memory corruption.&#xA;So add a alignment check for event ring read pointer.&#xA;CVE-2024-26624:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-26625:In the Linux kernel, the following vulnerability has been resolved:&#xA;llc: call sock_orphan() at release time&#xA;syzbot reported an interesting trace [1] caused by a stale sk-&gt;sk_wq&#xA;pointer in a closed llc socket.&#xA;In commit ff7b11aa481f (&#34;net: socket: set sock-&gt;sk to NULL after&#xA;calling proto_ops::release()&#34;) Eric Biggers hinted that some protocols&#xA;are missing a sock_orphan(), we need to perform a full audit.&#xA;In net-next, I plan to clear sock-&gt;sk from sock_orphan() and&#xA;amend Eric patch to add a warning.&#xA;[1]&#xA; BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]&#xA; BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]&#xA; BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]&#xA; BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468&#xA;Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27&#xA;CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0xc4/0x620 mm/kasan/report.c:488&#xA;  kasan_report+0xda/0x110 mm/kasan/report.c:601&#xA;  list_empty include/linux/list.h:373 [inline]&#xA;  waitqueue_active include/linux/wait.h:127 [inline]&#xA;  sock_def_write_space_wfree net/core/sock.c:3384 [inline]&#xA;  sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468&#xA;  skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080&#xA;  skb_release_all net/core/skbuff.c:1092 [inline]&#xA;  napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404&#xA;  e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970&#xA;  e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]&#xA;  e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801&#xA;  __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576&#xA;  napi_poll net/core/dev.c:6645 [inline]&#xA;  net_rx_action+0x956/0xe90 net/core/dev.c:6778&#xA;  __do_softirq+0x21a/0x8de kernel/softirq.c:553&#xA;  run_ksoftirqd kernel/softirq.c:921 [inline]&#xA;  run_ksoftirqd+0x31/0x60 kernel/softirq.c:913&#xA;  smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164&#xA;  kthread+0x2c6/0x3a0 kernel/kthread.c:388&#xA;  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147&#xA;  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242&#xA; &lt;/TASK&gt;&#xA;Allocated by task 5167:&#xA;  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47&#xA;  kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA;  unpoison_slab_object mm/kasan/common.c:314 [inline]&#xA;  __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340&#xA;  kasan_slab_alloc include/linux/kasan.h:201 [inline]&#xA;  slab_post_alloc_hook mm/slub.c:3813 [inline]&#xA;  slab_alloc_node mm/slub.c:3860 [inline]&#xA;  kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879&#xA;  alloc_inode_sb include/linux/fs.h:3019 [inline]&#xA;  sock_alloc_inode+0x25/0x1c0 net/socket.c:308&#xA;  alloc_inode+0x5d/0x220 fs/inode.c:260&#xA;  new_inode_pseudo+0x16/0x80 fs/inode.c:1005&#xA;  sock_alloc+0x40/0x270 net/socket.c:634&#xA;  __sock_create+0xbc/0x800 net/socket.c:1535&#xA;  sock_create net/socket.c:1622 [inline]&#xA;  __sys_socket_create net/socket.c:1659 [inline]&#xA;  __sys_socket+0x14c/0x260 net/socket.c:1706&#xA;  __do_sys_socket net/socket.c:1720 [inline]&#xA;  __se_sys_socket net/socket.c:1718 [inline]&#xA;  __x64_sys_socket+0x72/0xb0 net/socket.c:1718&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Freed by task 0:&#xA;  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47&#xA;  kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA;  kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640&#xA;  poison_slab_object mm/kasan/common.c:241 [inline]&#xA;  __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257&#xA;  kasan_slab_free include/linux/kasan.h:184 [inline]&#xA;  slab_free_hook mm/slub.c:2121 [inlin&#xA;---truncated---&#xA;CVE-2023-52502:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()&#xA;Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.&#xA;Getting a reference on the socket found in a lookup while&#xA;holding a lock should happen before releasing the lock.&#xA;nfc_llcp_sock_get_sn() has a similar problem.&#xA;Finally nfc_llcp_recv_snl() needs to make sure the socket&#xA;found by nfc_llcp_sock_from_sn() does not disappear.&#xA;CVE-2024-26622:In the Linux kernel, the following vulnerability has been resolved:&#xA;tomoyo: fix UAF write bug in tomoyo_write_control()&#xA;Since tomoyo_write_control() updates head-&gt;write_buf when write()&#xA;of long lines is requested, we need to fetch head-&gt;write_buf after&#xA;head-&gt;io_sem is held.  Otherwise, concurrent write() requests can&#xA;cause use-after-free-write and double-free problems.&#xA;CVE-2023-52599:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix array-index-out-of-bounds in diNewExt&#xA;[Syz report]&#xA;UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2&#xA;index -878706688 is out of range for type &#39;struct iagctl[128]&#39;&#xA;CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106&#xA; ubsan_epilogue lib/ubsan.c:217 [inline]&#xA; __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348&#xA; diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360&#xA; diAllocExt fs/jfs/jfs_imap.c:1949 [inline]&#xA; diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666&#xA; diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587&#xA; ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56&#xA; jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225&#xA; vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106&#xA; do_mkdirat+0x264/0x3a0 fs/namei.c:4129&#xA; __do_sys_mkdir fs/namei.c:4149 [inline]&#xA; __se_sys_mkdir fs/namei.c:4147 [inline]&#xA; __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147&#xA; do_syscall_x64 arch/x86/entry/common.c:51 [inline]&#xA; do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;RIP: 0033:0x7fcb7e6a0b57&#xA;Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053&#xA;RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57&#xA;RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140&#xA;RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;[Analysis]&#xA;When the agstart is too large, it can cause agno overflow.&#xA;[Fix]&#xA;After obtaining agno, if the value is invalid, exit the subsequent process.&#xA;Modified the test from agno &gt; MAXAG to agno &gt;= MAXAG based on linux-next&#xA;report by kernel test robot (Dan Carpenter).&#xA;CVE-2023-52600:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix uaf in jfs_evict_inode&#xA;When the execution of diMount(ipimap) fails, the object ipimap that has been&#xA;released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs&#xA;when rcu_core() calls jfs_free_node().&#xA;Therefore, when diMount(ipimap) fails, sbi-&gt;ipimap should not be initialized as&#xA;ipimap.&#xA;CVE-2023-52622:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: avoid online resizing failures due to oversized flex bg&#xA;When we online resize an ext4 filesystem with a oversized flexbg_size,&#xA;     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M&#xA;     mount $dev $dir&#xA;     resize2fs $dev 16G&#xA;the following WARN_ON is triggered: ==================================================================&#xA;WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550&#xA;Modules linked in: sg(E)&#xA;CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ #314&#xA;RIP: 0010:__alloc_pages+0x411/0x550&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __kmalloc_large_node+0xa2/0x200&#xA; __kmalloc+0x16e/0x290&#xA; ext4_resize_fs+0x481/0xd80&#xA; __ext4_ioctl+0x1616/0x1d90&#xA; ext4_ioctl+0x12/0x20&#xA; __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ==================================================================&#xA;This is because flexbg_size is too large and the size of the new_group_data&#xA;array to be allocated exceeds MAX_ORDER. Currently, the minimum value of&#xA;MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding&#xA;maximum number of groups that can be allocated is:&#xA; (PAGE_SIZE &lt;&lt; MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845&#xA;And the value that is down-aligned to the power of 2 is 16384. Therefore,&#xA;this value is defined as MAX_RESIZE_BG, and the number of groups added&#xA;each time does not exceed this value during resizing, and is added multiple&#xA;times to complete the online resizing. The difference is that the metadata&#xA;in a flex_bg may be more dispersed.&#xA;CVE-2024-23307:Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.&#xA;CVE-2021-47094:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: x86/mmu: Don&#39;t advance iterator after restart due to yielding&#xA;After dropping mmu_lock in the TDP MMU, restart the iterator during&#xA;tdp_iter_next() and do not advance the iterator.  Advancing the iterator&#xA;results in skipping the top-level SPTE and all its children, which is&#xA;fatal if any of the skipped SPTEs were not visited before yielding.&#xA;When zapping all SPTEs, i.e. when min_level == root_level, restarting the&#xA;iter and then invoking tdp_iter_next() is always fatal if the current gfn&#xA;has as a valid SPTE, as advancing the iterator results in try_step_side()&#xA;skipping the current gfn, which wasn&#39;t visited before yielding.&#xA;Sprinkle WARNs on iter-&gt;yielded being true in various helpers that are&#xA;often used in conjunction with yielding, and tag the helper with&#xA;__must_check to reduce the probabily of improper usage.&#xA;Failing to zap a top-level SPTE manifests in one of two ways.  If a valid&#xA;SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(),&#xA;the shadow page will be leaked and KVM will WARN accordingly.&#xA;  WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm]&#xA;  RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   kvm_arch_destroy_vm+0x130/0x1b0 [kvm]&#xA;   kvm_destroy_vm+0x162/0x2a0 [kvm]&#xA;   kvm_vcpu_release+0x34/0x60 [kvm]&#xA;   __fput+0x82/0x240&#xA;   task_work_run+0x5c/0x90&#xA;   do_exit+0x364/0xa10&#xA;   ? futex_unqueue+0x38/0x60&#xA;   do_group_exit+0x33/0xa0&#xA;   get_signal+0x155/0x850&#xA;   arch_do_signal_or_restart+0xed/0x750&#xA;   exit_to_user_mode_prepare+0xc5/0x120&#xA;   syscall_exit_to_user_mode+0x1d/0x40&#xA;   do_syscall_64+0x48/0xc0&#xA;   entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by&#xA;kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of&#xA;marking a struct page as dirty/accessed after it has been put back on the&#xA;free list.  This directly triggers a WARN due to encountering a page with&#xA;page_count() == 0, but it can also lead to data corruption and additional&#xA;errors in the kernel.&#xA;  WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171&#xA;  RIP: 0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   kvm_set_pfn_dirty+0x120/0x1d0 [kvm]&#xA;   __handle_changed_spte+0x92e/0xca0 [kvm]&#xA;   __handle_changed_spte+0x63c/0xca0 [kvm]&#xA;   __handle_changed_spte+0x63c/0xca0 [kvm]&#xA;   __handle_changed_spte+0x63c/0xca0 [kvm]&#xA;   zap_gfn_range+0x549/0x620 [kvm]&#xA;   kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm]&#xA;   mmu_free_root_page+0x219/0x2c0 [kvm]&#xA;   kvm_mmu_free_roots+0x1b4/0x4e0 [kvm]&#xA;   kvm_mmu_unload+0x1c/0xa0 [kvm]&#xA;   kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]&#xA;   kvm_put_kvm+0x3b1/0x8b0 [kvm]&#xA;   kvm_vcpu_release+0x4e/0x70 [kvm]&#xA;   __fput+0x1f7/0x8c0&#xA;   task_work_run+0xf8/0x1a0&#xA;   do_exit+0x97b/0x2230&#xA;   do_group_exit+0xda/0x2a0&#xA;   get_signal+0x3be/0x1e50&#xA;   arch_do_signal_or_restart+0x244/0x17f0&#xA;   exit_to_user_mode_prepare+0xcb/0x120&#xA;   syscall_exit_to_user_mode+0x1d/0x40&#xA;   do_syscall_64+0x4d/0x90&#xA;   entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;Note, the underlying bug existed even before commit 1af4a96025b3 (&#34;KVM:&#xA;x86/mmu: Yield in TDU MMU iter even if no SPTES changed&#34;) moved calls to&#xA;tdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could still&#xA;incorrectly advance past a top-level entry when yielding on a lower-level&#xA;entry.  But with respect to leaking shadow pages, the bug was introduced&#xA;by yielding before processing the current gfn.&#xA;Alternatively, tdp_mmu_iter_cond_resched() could simply fall through, or&#xA;callers could jump to their &#34;retry&#34; label.  The downside of that approach&#xA;is that tdp_mmu_iter_cond_resched() _must_ be called before anything else&#xA;in the loop, and there&#39;s no easy way to enfornce that requirement.&#xA;Ideally, KVM would handling the cond_resched() fully within the iterator&#xA;macro (the code is actually quite clean) and avoid this entire class of&#xA;bugs, but that is extremely difficult do wh&#xA;---truncated---&#xA;CVE-2023-52601:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix array-index-out-of-bounds in dbAdjTree&#xA;Currently there is a bound check missing in the dbAdjTree while&#xA;accessing the dmt_stree. To add the required check added the bool is_ctl&#xA;which is required to determine the size as suggest in the following&#xA;commit.&#xA;https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/&#xA;CVE-2021-46926:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: hda: intel-sdw-acpi: harden detection of controller&#xA;The existing code currently sets a pointer to an ACPI handle before&#xA;checking that it&#39;s actually a SoundWire controller. This can lead to&#xA;issues where the graph walk continues and eventually fails, but the&#xA;pointer was set already.&#xA;This patch changes the logic so that the information provided to&#xA;the caller is set when a controller is found.&#xA;CVE-2023-52479:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: fix uaf in smb20_oplock_break_ack&#xA;drop reference after use opinfo.&#xA;CVE-2023-52484:In the Linux kernel, the following vulnerability has been resolved:&#xA;iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range&#xA;When running an SVA case, the following soft lockup is triggered:&#xA;--------------------------------------------------------------------&#xA;watchdog: BUG: soft lockup - CPU#244 stuck for 26s!&#xA;pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)&#xA;pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50&#xA;lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50&#xA;sp : ffff8000d83ef290&#xA;x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000&#xA;x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000&#xA;x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0&#xA;x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000&#xA;x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0&#xA;x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000&#xA;x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc&#xA;x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa&#xA;x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a&#xA;x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001&#xA;Call trace:&#xA; arm_smmu_cmdq_issue_cmdlist+0x178/0xa50&#xA; __arm_smmu_tlb_inv_range+0x118/0x254&#xA; arm_smmu_tlb_inv_range_asid+0x6c/0x130&#xA; arm_smmu_mm_invalidate_range+0xa0/0xa4&#xA; __mmu_notifier_invalidate_range_end+0x88/0x120&#xA; unmap_vmas+0x194/0x1e0&#xA; unmap_region+0xb4/0x144&#xA; do_mas_align_munmap+0x290/0x490&#xA; do_mas_munmap+0xbc/0x124&#xA; __vm_munmap+0xa8/0x19c&#xA; __arm64_sys_munmap+0x28/0x50&#xA; invoke_syscall+0x78/0x11c&#xA; el0_svc_common.constprop.0+0x58/0x1c0&#xA; do_el0_svc+0x34/0x60&#xA; el0_svc+0x2c/0xd4&#xA; el0t_64_sync_handler+0x114/0x140&#xA; el0t_64_sync+0x1a4/0x1a8&#xA;--------------------------------------------------------------------&#xA;Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed&#xA;to &#34;arm_smmu_mm_arch_invalidate_secondary_tlbs&#34;, yet the problem remains.&#xA;The commit 06ff87bae8d3 (&#34;arm64: mm: remove unused functions and variable&#xA;protoypes&#34;) fixed a similar lockup on the CPU MMU side. Yet, it can occur&#xA;to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called&#xA;typically next to MMU tlb flush function, e.g.&#xA;&#x9;tlb_flush_mmu_tlbonly {&#xA;&#x9;&#x9;tlb_flush {&#xA;&#x9;&#x9;&#x9;__flush_tlb_range {&#xA;&#x9;&#x9;&#x9;&#x9;// check MAX_TLBI_OPS&#xA;&#x9;&#x9;&#x9;}&#xA;&#x9;&#x9;}&#xA;&#x9;&#x9;mmu_notifier_arch_invalidate_secondary_tlbs {&#xA;&#x9;&#x9;&#x9;arm_smmu_mm_arch_invalidate_secondary_tlbs {&#xA;&#x9;&#x9;&#x9;&#x9;// does not check MAX_TLBI_OPS&#xA;&#x9;&#x9;&#x9;}&#xA;&#x9;&#x9;}&#xA;&#x9;}&#xA;Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an&#xA;SVA case SMMU uses the CPU page table, so it makes sense to align with the&#xA;tlbflush code. Then, replace per-page TLBI commands with a single per-asid&#xA;TLBI command, if the request size hits this threshold.&#xA;CVE-2024-26593:In the Linux kernel, the following vulnerability has been resolved:&#xA;i2c: i801: Fix block process call transactions&#xA;According to the Intel datasheets, software must reset the block&#xA;buffer index twice for block process call transactions: once before&#xA;writing the outgoing data to the buffer, and once again before&#xA;reading the incoming data from the buffer.&#xA;The driver is currently missing the second reset, causing the wrong&#xA;portion of the block buffer to be read.&#xA;CVE-2024-26788:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: fsl-qdma: init irq after reg initialization&#xA;Initialize the qDMA irqs after the registers are configured so that&#xA;interrupts that may have been pending from a primary kernel don&#39;t get&#xA;processed by the irq handler before it is ready to and cause panic with&#xA;the following trace:&#xA;  Call trace:&#xA;   fsl_qdma_queue_handler+0xf8/0x3e8&#xA;   __handle_irq_event_percpu+0x78/0x2b0&#xA;   handle_irq_event_percpu+0x1c/0x68&#xA;   handle_irq_event+0x44/0x78&#xA;   handle_fasteoi_irq+0xc8/0x178&#xA;   generic_handle_irq+0x24/0x38&#xA;   __handle_domain_irq+0x90/0x100&#xA;   gic_handle_irq+0x5c/0xb8&#xA;   el1_irq+0xb8/0x180&#xA;   _raw_spin_unlock_irqrestore+0x14/0x40&#xA;   __setup_irq+0x4bc/0x798&#xA;   request_threaded_irq+0xd8/0x190&#xA;   devm_request_threaded_irq+0x74/0xe8&#xA;   fsl_qdma_probe+0x4d4/0xca8&#xA;   platform_drv_probe+0x50/0xa0&#xA;   really_probe+0xe0/0x3f8&#xA;   driver_probe_device+0x64/0x130&#xA;   device_driver_attach+0x6c/0x78&#xA;   __driver_attach+0xbc/0x158&#xA;   bus_for_each_dev+0x5c/0x98&#xA;   driver_attach+0x20/0x28&#xA;   bus_add_driver+0x158/0x220&#xA;   driver_register+0x60/0x110&#xA;   __platform_driver_register+0x44/0x50&#xA;   fsl_qdma_driver_init+0x18/0x20&#xA;   do_one_initcall+0x48/0x258&#xA;   kernel_init_freeable+0x1a4/0x23c&#xA;   kernel_init+0x10/0xf8&#xA;   ret_from_fork+0x10/0x18&#xA;CVE-2024-26607:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/bridge: sii902x: Fix probing race issue&#xA;A null pointer dereference crash has been observed rarely on TI&#xA;platforms using sii9022 bridge:&#xA;[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x]&#xA;[   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x]&#xA;[   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm]&#xA;[   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]&#xA;[   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]&#xA;[   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm]&#xA;[   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]&#xA;[   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]&#xA;[   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]&#xA;[   53.326401]  drm_client_register+0x5c/0xa0 [drm]&#xA;[   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]&#xA;[   53.336881]  tidss_probe+0x128/0x264 [tidss]&#xA;[   53.341174]  platform_probe+0x68/0xc4&#xA;[   53.344841]  really_probe+0x188/0x3c4&#xA;[   53.348501]  __driver_probe_device+0x7c/0x16c&#xA;[   53.352854]  driver_probe_device+0x3c/0x10c&#xA;[   53.357033]  __device_attach_driver+0xbc/0x158&#xA;[   53.361472]  bus_for_each_drv+0x88/0xe8&#xA;[   53.365303]  __device_attach+0xa0/0x1b4&#xA;[   53.369135]  device_initial_probe+0x14/0x20&#xA;[   53.373314]  bus_probe_device+0xb0/0xb4&#xA;[   53.377145]  deferred_probe_work_func+0xcc/0x124&#xA;[   53.381757]  process_one_work+0x1f0/0x518&#xA;[   53.385770]  worker_thread+0x1e8/0x3dc&#xA;[   53.389519]  kthread+0x11c/0x120&#xA;[   53.392750]  ret_from_fork+0x10/0x20&#xA;The issue here is as follows:&#xA;- tidss probes, but is deferred as sii902x is still missing.&#xA;- sii902x starts probing and enters sii902x_init().&#xA;- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from&#xA;  DRM&#39;s perspective.&#xA;- sii902x calls sii902x_audio_codec_init() and&#xA;  platform_device_register_data()&#xA;- The registration of the audio platform device causes probing of the&#xA;  deferred devices.&#xA;- tidss probes, which eventually causes sii902x_bridge_get_edid() to be&#xA;  called.&#xA;- sii902x_bridge_get_edid() tries to use the i2c to read the edid.&#xA;  However, the sii902x driver has not set up the i2c part yet, leading&#xA;  to the crash.&#xA;Fix this by moving the drm_bridge_add() to the end of the&#xA;sii902x_init(), which is also at the very end of sii902x_probe().&#xA;CVE-2024-26773:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()&#xA;Determine if the group block bitmap is corrupted before using ac_b_ex in&#xA;ext4_mb_try_best_found() to avoid allocating blocks from a group with a&#xA;corrupted block bitmap in the following concurrency and making the&#xA;situation worse.&#xA;ext4_mb_regular_allocator&#xA;  ext4_lock_group(sb, group)&#xA;  ext4_mb_good_group&#xA;   // check if the group bbitmap is corrupted&#xA;  ext4_mb_complex_scan_group&#xA;   // Scan group gets ac_b_ex but doesn&#39;t use it&#xA;  ext4_unlock_group(sb, group)&#xA;                           ext4_mark_group_bitmap_corrupted(group)&#xA;                           // The block bitmap was corrupted during&#xA;                           // the group unlock gap.&#xA;  ext4_mb_try_best_found&#xA;    ext4_lock_group(ac-&gt;ac_sb, group)&#xA;    ext4_mb_use_best_found&#xA;      mb_mark_used&#xA;      // Allocating blocks in block bitmap corrupted group&#xA;CVE-2023-52469:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers/amd/pm: fix a use-after-free in kv_parse_power_table&#xA;When ps allocated by kzalloc equals to NULL, kv_parse_power_table&#xA;frees adev-&gt;pm.dpm.ps that allocated before. However, after the control&#xA;flow goes through the following call chains:&#xA;kv_parse_power_table&#xA;  |-&gt; kv_dpm_init&#xA;        |-&gt; kv_dpm_sw_init&#xA;&#x9;      |-&gt; kv_dpm_fini&#xA;The adev-&gt;pm.dpm.ps is used in the for loop of kv_dpm_fini after its&#xA;first free in kv_parse_power_table and causes a use-after-free bug.&#xA;CVE-2023-52475:In the Linux kernel, the following vulnerability has been resolved:&#xA;Input: powermate - fix use-after-free in powermate_config_complete&#xA;syzbot has found a use-after-free bug [1] in the powermate driver. This&#xA;happens when the device is disconnected, which leads to a memory free from&#xA;the powermate_device struct.  When an asynchronous control message&#xA;completes after the kfree and its callback is invoked, the lock does not&#xA;exist anymore and hence the bug.&#xA;Use usb_kill_urb() on pm-&gt;config to cancel any in-progress requests upon&#xA;device disconnection.&#xA;[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e&#xA;CVE-2024-26600:In the Linux kernel, the following vulnerability has been resolved:&#xA;phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP&#xA;If the external phy working together with phy-omap-usb2 does not implement&#xA;send_srp(), we may still attempt to call it. This can happen on an idle&#xA;Ethernet gadget triggering a wakeup for example:&#xA;configfs-gadget.g1 gadget.0: ECM Suspend&#xA;configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup&#xA;...&#xA;Unable to handle kernel NULL pointer dereference at virtual address&#xA;00000000 when execute&#xA;...&#xA;PC is at 0x0&#xA;LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]&#xA;...&#xA;musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]&#xA;usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]&#xA;eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c&#xA;dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4&#xA;sch_direct_xmit from __dev_queue_xmit+0x334/0xd88&#xA;__dev_queue_xmit from arp_solicit+0xf0/0x268&#xA;arp_solicit from neigh_probe+0x54/0x7c&#xA;neigh_probe from __neigh_event_send+0x22c/0x47c&#xA;__neigh_event_send from neigh_resolve_output+0x14c/0x1c0&#xA;neigh_resolve_output from ip_finish_output2+0x1c8/0x628&#xA;ip_finish_output2 from ip_send_skb+0x40/0xd8&#xA;ip_send_skb from udp_send_skb+0x124/0x340&#xA;udp_send_skb from udp_sendmsg+0x780/0x984&#xA;udp_sendmsg from __sys_sendto+0xd8/0x158&#xA;__sys_sendto from ret_fast_syscall+0x0/0x58&#xA;Let&#39;s fix the issue by checking for send_srp() and set_vbus() before&#xA;calling them. For USB peripheral only cases these both could be NULL.&#xA;CVE-2021-47037:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: q6afe-clocks: fix reprobing of the driver&#xA;Q6afe-clocks driver can get reprobed. For example if the APR services&#xA;are restarted after the firmware crash. However currently Q6afe-clocks&#xA;driver will oops because hw.init will get cleared during first _probe&#xA;call. Rewrite the driver to fill the clock data at runtime rather than&#xA;using big static array of clocks.&#xA;CVE-2023-52456:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: imx: fix tx statemachine deadlock&#xA;When using the serial port as RS485 port, the tx statemachine is used to&#xA;control the RTS pin to drive the RS485 transceiver TX_EN pin. When the&#xA;TTY port is closed in the middle of a transmission (for instance during&#xA;userland application crash), imx_uart_shutdown disables the interface&#xA;and disables the Transmission Complete interrupt. afer that,&#xA;imx_uart_stop_tx bails on an incomplete transmission, to be retriggered&#xA;by the TC interrupt. This interrupt is disabled and therefore the tx&#xA;statemachine never transitions out of SEND. The statemachine is in&#xA;deadlock now, and the TX_EN remains low, making the interface useless.&#xA;imx_uart_stop_tx now checks for incomplete transmission AND whether TC&#xA;interrupts are enabled before bailing to be retriggered. This makes sure&#xA;the state machine handling is reached, and is properly set to&#xA;WAIT_AFTER_SEND.&#xA;CVE-2024-26696:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()&#xA;Syzbot reported a hang issue in migrate_pages_batch() called by mbind()&#xA;and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.&#xA;While migrate_pages_batch() locks a folio and waits for the writeback to&#xA;complete, the log writer thread that should bring the writeback to&#xA;completion picks up the folio being written back in&#xA;nilfs_lookup_dirty_data_buffers() that it calls for subsequent log&#xA;creation and was trying to lock the folio.  Thus causing a deadlock.&#xA;In the first place, it is unexpected that folios/pages in the middle of&#xA;writeback will be updated and become dirty.  Nilfs2 adds a checksum to&#xA;verify the validity of the log being written and uses it for recovery at&#xA;mount, so data changes during writeback are suppressed.  Since this is&#xA;broken, an unclean shutdown could potentially cause recovery to fail.&#xA;Investigation revealed that the root cause is that the wait for writeback&#xA;completion in nilfs_page_mkwrite() is conditional, and if the backing&#xA;device does not require stable writes, data may be modified without&#xA;waiting.&#xA;Fix these issues by making nilfs_page_mkwrite() wait for writeback to&#xA;finish regardless of the stable write requirement of the backing device.&#xA;CVE-2023-52467:In the Linux kernel, the following vulnerability has been resolved:&#xA;mfd: syscon: Fix null pointer dereference in of_syscon_register()&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure.&#xA;CVE-2024-26608:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: fix global oob in ksmbd_nl_policy&#xA;Similar to a reported issue (check the commit b33fb5b801c6 (&#34;net:&#xA;qualcomm: rmnet: fix global oob in rmnet_policy&#34;), my local fuzzer finds&#xA;another global out-of-bounds read for policy ksmbd_nl_policy. See bug&#xA;trace below: ==================================================================&#xA;BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]&#xA;BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600&#xA;Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810&#xA;CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G                 N 6.1.0 #3&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:284 [inline]&#xA; print_report+0x172/0x475 mm/kasan/report.c:395&#xA; kasan_report+0xbb/0x1c0 mm/kasan/report.c:495&#xA; validate_nla lib/nlattr.c:386 [inline]&#xA; __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600&#xA; __nla_parse+0x3e/0x50 lib/nlattr.c:697&#xA; __nlmsg_parse include/net/netlink.h:748 [inline]&#xA; genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565&#xA; genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734&#xA; genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]&#xA; genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850&#xA; netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540&#xA; genl_rcv+0x24/0x40 net/netlink/genetlink.c:861&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]&#xA; netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345&#xA; netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921&#xA; sock_sendmsg_nosec net/socket.c:714 [inline]&#xA; sock_sendmsg+0x154/0x190 net/socket.c:734&#xA; ____sys_sendmsg+0x6df/0x840 net/socket.c:2482&#xA; ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536&#xA; __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;RIP: 0033:0x7fdd66a8f359&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359&#xA;RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003&#xA;RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000&#xA; &lt;/TASK&gt;&#xA;The buggy address belongs to the variable:&#xA; ksmbd_nl_policy+0x100/0xa80&#xA;The buggy address belongs to the physical page:&#xA;page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b&#xA;flags: 0x200000000001000(reserved|node=0|zone=2)&#xA;raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000&#xA;raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;Memory state around the buggy address:&#xA; ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA; ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;&gt;ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9&#xA;                   ^&#xA; ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05&#xA; ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9 ==================================================================&#xA;To fix it, add a placeholder named __KSMBD_EVENT_MAX and let&#xA;KSMBD_EVENT_MAX to be its original value - 1 according to what other&#xA;netlink families do. Also change two sites that refer the&#xA;KSMBD_EVENT_MAX to correct value.&#xA;CVE-2024-26589:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS&#xA;For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off&#xA;for validation. However, variable offset ptr alu is not prohibited&#xA;for this ptr kind. So the variable offset is not checked.&#xA;The following prog is accepted:&#xA;  func#0 @0&#xA;  0: R1=ctx() R10=fp0&#xA;  0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()&#xA;  1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()&#xA;  2: (b7) r8 = 1024                     ; R8_w=1024&#xA;  3: (37) r8 /= 1                       ; R8_w=scalar()&#xA;  4: (57) r8 &amp;= 1024                    ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))&#xA;  5: (0f) r7 += r8&#xA;  mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1&#xA;  mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &amp;= 1024&#xA;  mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1&#xA;  mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024&#xA;  6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off&#xA;  =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400))&#xA;  6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()&#xA;  7: (95) exit&#xA;This prog loads flow_keys to r7, and adds the variable offset r8&#xA;to r7, and finally causes out-of-bounds access:&#xA;  BUG: unable to handle page fault for address: ffffc90014c80038&#xA;  [...]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]&#xA;   __bpf_prog_run include/linux/filter.h:651 [inline]&#xA;   bpf_prog_run include/linux/filter.h:658 [inline]&#xA;   bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]&#xA;   bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991&#xA;   bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359&#xA;   bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]&#xA;   __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475&#xA;   __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]&#xA;   __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]&#xA;   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559&#xA;   do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;   do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83&#xA;   entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Fix this by rejecting ptr alu with variable offset on flow_keys.&#xA;Applying the patch rejects the program with &#34;R7 pointer arithmetic&#xA;on flow_keys prohibited&#34;.&#xA;CVE-2024-26597:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: qualcomm: rmnet: fix global oob in rmnet_policy&#xA;The variable rmnet_link_ops assign a *bigger* maxtype which leads to a&#xA;global out-of-bounds read when parsing the netlink attributes. See bug&#xA;trace below: ==================================================================&#xA;BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]&#xA;BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600&#xA;Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207&#xA;CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:284 [inline]&#xA; print_report+0x172/0x475 mm/kasan/report.c:395&#xA; kasan_report+0xbb/0x1c0 mm/kasan/report.c:495&#xA; validate_nla lib/nlattr.c:386 [inline]&#xA; __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600&#xA; __nla_parse+0x3e/0x50 lib/nlattr.c:697&#xA; nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]&#xA; __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485&#xA; rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594&#xA; rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091&#xA; netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]&#xA; netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345&#xA; netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921&#xA; sock_sendmsg_nosec net/socket.c:714 [inline]&#xA; sock_sendmsg+0x154/0x190 net/socket.c:734&#xA; ____sys_sendmsg+0x6df/0x840 net/socket.c:2482&#xA; ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536&#xA; __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;RIP: 0033:0x7fdcf2072359&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359&#xA;RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003&#xA;RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000&#xA; &lt;/TASK&gt;&#xA;The buggy address belongs to the variable:&#xA; rmnet_policy+0x30/0xe0&#xA;The buggy address belongs to the physical page:&#xA;page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243&#xA;flags: 0x200000000001000(reserved|node=0|zone=2)&#xA;raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000&#xA;raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;Memory state around the buggy address:&#xA; ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07&#xA; ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9&#xA;&gt;ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9&#xA;                                                 ^&#xA; ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9&#xA; ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9&#xA;According to the comment of `nla_parse_nested_deprecated`, the maxtype&#xA;should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.&#xA;CVE-2024-26606:In the Linux kernel, the following vulnerability has been resolved:&#xA;binder: signal epoll threads of self-work&#xA;In (e)poll mode, threads often depend on I/O events to determine when&#xA;data is ready for consumption. Within binder, a thread may initiate a&#xA;command via BINDER_WRITE_READ without a read buffer and then make use&#xA;of epoll_wait() or similar to consume any responses afterwards.&#xA;It is then crucial that epoll threads are signaled via wakeup when they&#xA;queue their own work. Otherwise, they risk waiting indefinitely for an&#xA;event leaving their work unhandled. What is worse, subsequent commands&#xA;won&#39;t trigger a wakeup either as the thread has pending work.&#xA;CVE-2023-52477:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: hub: Guard against accesses to uninitialized BOS descriptors&#xA;Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h&#xA;access fields inside udev-&gt;bos without checking if it was allocated and&#xA;initialized. If usb_get_bos_descriptor() fails for whatever&#xA;reason, udev-&gt;bos will be NULL and those accesses will result in a&#xA;crash:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000018&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;&#xA;Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021&#xA;Workqueue: usb_hub_wq hub_event&#xA;RIP: 0010:hub_port_reset+0x193/0x788&#xA;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&#xA;RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310&#xA;RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840&#xA;RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060&#xA;R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000&#xA;R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000&#xA;FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0&#xA;Call Trace:&#xA;hub_event+0x73f/0x156e&#xA;? hub_activate+0x5b7/0x68f&#xA;process_one_work+0x1a2/0x487&#xA;worker_thread+0x11a/0x288&#xA;kthread+0x13a/0x152&#xA;? process_one_work+0x487/0x487&#xA;? kthread_associate_blkcg+0x70/0x70&#xA;ret_from_fork+0x1f/0x30&#xA;Fall back to a default behavior if the BOS descriptor isn&#39;t accessible&#xA;and skip all the functionalities that depend on it: LPM support checks,&#xA;Super Speed capabilitiy checks, U1/U2 states setup.&#xA;CVE-2023-52454:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length&#xA;If the host sends an H2CData command with an invalid DATAL,&#xA;the kernel may crash in nvmet_tcp_build_pdu_iovec().&#xA;Unable to handle kernel NULL pointer dereference at&#xA;virtual address 0000000000000000&#xA;lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]&#xA;Call trace:&#xA;  process_one_work+0x174/0x3c8&#xA;  worker_thread+0x2d0/0x3e8&#xA;  kthread+0x104/0x110&#xA;Fix the bug by raising a fatal error if DATAL isn&#39;t coherent&#xA;with the packet size.&#xA;Also, the PDU length should never exceed the MAXH2CDATA parameter which&#xA;has been communicated to the host in nvmet_tcp_handle_icreq().&#xA;CVE-2023-52476:In the Linux kernel, the following vulnerability has been resolved:&#xA;perf/x86/lbr: Filter vsyscall addresses&#xA;We found that a panic can occur when a vsyscall is made while LBR sampling&#xA;is active. If the vsyscall is interrupted (NMI) for perf sampling, this&#xA;call sequence can occur (most recent at top):&#xA;    __insn_get_emulate_prefix()&#xA;    insn_get_emulate_prefix()&#xA;    insn_get_prefixes()&#xA;    insn_get_opcode()&#xA;    decode_branch_type()&#xA;    get_branch_type()&#xA;    intel_pmu_lbr_filter()&#xA;    intel_pmu_handle_irq()&#xA;    perf_event_nmi_handler()&#xA;Within __insn_get_emulate_prefix() at frame 0, a macro is called:&#xA;    peek_nbyte_next(insn_byte_t, insn, i)&#xA;Within this macro, this dereference occurs:&#xA;    (insn)-&gt;next_byte&#xA;Inspecting registers at this point, the value of the next_byte field is the&#xA;address of the vsyscall made, for example the location of the vsyscall&#xA;version of gettimeofday() at 0xffffffffff600000. The access to an address&#xA;in the vsyscall region will trigger an oops due to an unhandled page fault.&#xA;To fix the bug, filtering for vsyscalls can be done when&#xA;determining the branch type. This patch will return&#xA;a &#34;none&#34; branch if a kernel address if found to lie in the&#xA;vsyscall region.&#xA;CVE-2024-26654:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs&#xA;The dreamcastcard-&gt;timer could schedule the spu_dma_work and the&#xA;spu_dma_work could also arm the dreamcastcard-&gt;timer.&#xA;When the snd_pcm_substream is closing, the aica_channel will be&#xA;deallocated. But it could still be dereferenced in the worker&#xA;thread. The reason is that del_timer() will return directly&#xA;regardless of whether the timer handler is running or not and&#xA;the worker could be rescheduled in the timer handler. As a result,&#xA;the UAF bug will happen. The racy situation is shown below:&#xA;      (Thread 1)                 |      (Thread 2)&#xA;snd_aicapcm_pcm_close()          |&#xA; ...                             |  run_spu_dma() //worker&#xA;                                 |    mod_timer()&#xA;  flush_work()                   |&#xA;  del_timer()                    |  aica_period_elapsed() //timer&#xA;  kfree(dreamcastcard-&gt;channel)  |    schedule_work()&#xA;                                 |  run_spu_dma() //worker&#xA;  ...                            |    dreamcastcard-&gt;channel-&gt; //USE&#xA;In order to mitigate this bug and other possible corner cases,&#xA;call mod_timer() conditionally in run_spu_dma(), then implement&#xA;PCM sync_stop op to cancel both the timer and worker. The sync_stop&#xA;op will be called from PCM core appropriately when needed.&#xA;CVE-2024-26603:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/fpu: Stop relying on userspace for info to fault in xsave buffer&#xA;Before this change, the expected size of the user space buffer was&#xA;taken from fx_sw-&gt;xstate_size. fx_sw-&gt;xstate_size can be changed&#xA;from user-space, so it is possible construct a sigreturn frame where:&#xA; * fx_sw-&gt;xstate_size is smaller than the size required by valid bits in&#xA;   fx_sw-&gt;xfeatures.&#xA; * user-space unmaps parts of the sigrame fpu buffer so that not all of&#xA;   the buffer required by xrstor is accessible.&#xA;In this case, xrstor tries to restore and accesses the unmapped area&#xA;which results in a fault. But fault_in_readable succeeds because buf +&#xA;fx_sw-&gt;xstate_size is within the still mapped area, so it goes back and&#xA;tries xrstor again. It will spin in this loop forever.&#xA;Instead, fault in the maximum size which can be touched by XRSTOR (taken&#xA;from fpstate-&gt;user_size).&#xA;[ dhansen: tweak subject / changelog ]&#xA;CVE-2024-26644:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: don&#39;t abort filesystem when attempting to snapshot deleted subvolume&#xA;If the source file descriptor to the snapshot ioctl refers to a deleted&#xA;subvolume, we get the following abort:&#xA;  BTRFS: Transaction aborted (error -2)&#xA;  WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]&#xA;  Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c&#xA;  CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014&#xA;  RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]&#xA;  RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282&#xA;  RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027&#xA;  RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840&#xA;  RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998&#xA;  R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe&#xA;  R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80&#xA;  FS:  00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? create_pending_snapshot+0x1040/0x1190 [btrfs]&#xA;   ? __warn+0x81/0x130&#xA;   ? create_pending_snapshot+0x1040/0x1190 [btrfs]&#xA;   ? report_bug+0x171/0x1a0&#xA;   ? handle_bug+0x3a/0x70&#xA;   ? exc_invalid_op+0x17/0x70&#xA;   ? asm_exc_invalid_op+0x1a/0x20&#xA;   ? create_pending_snapshot+0x1040/0x1190 [btrfs]&#xA;   ? create_pending_snapshot+0x1040/0x1190 [btrfs]&#xA;   create_pending_snapshots+0x92/0xc0 [btrfs]&#xA;   btrfs_commit_transaction+0x66b/0xf40 [btrfs]&#xA;   btrfs_mksubvol+0x301/0x4d0 [btrfs]&#xA;   btrfs_mksnapshot+0x80/0xb0 [btrfs]&#xA;   __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]&#xA;   btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]&#xA;   btrfs_ioctl+0x8a6/0x2650 [btrfs]&#xA;   ? kmem_cache_free+0x22/0x340&#xA;   ? do_sys_openat2+0x97/0xe0&#xA;   __x64_sys_ioctl+0x97/0xd0&#xA;   do_syscall_64+0x46/0xf0&#xA;   entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;  RIP: 0033:0x7fe20abe83af&#xA;  RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;  RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af&#xA;  RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003&#xA;  RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0&#xA;  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;  R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;  BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry&#xA;  BTRFS info (device vdc: state EA): forced readonly&#xA;  BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.&#xA;  BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry&#xA;This happens because create_pending_snapshot() initializes the new root&#xA;item as a copy of the source root item. This includes the refs field,&#xA;which is 0 for a deleted subvolume. The call to btrfs_insert_root()&#xA;therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then&#xA;finds the root and returns -ENOENT if refs == 0, which causes&#xA;create_pending_snapshot() to abort.&#xA;Fix it by checking the source root&#39;s refs before attempting the&#xA;snapshot, but after locking subvol_sem to avoid racing with deletion.&#xA;CVE-2022-2639:An integer coercion error was found in the openvswitch kernel module. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, the reserve_sfa_size() function does not return -EMSGSIZE as expected, potentially leading to an out-of-bounds write access. This flaw allows a local user to crash or potentially escalate their privileges on the system.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/kernel-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/kernel-headers-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/kernel-devel-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/kernel-tools-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/kernel-tools-devel-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/perf-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-perf-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/bpftool-5.10.0-136.71.0.151.u109.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/kernel-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/kernel-headers-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/kernel-devel-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/kernel-tools-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/kernel-tools-devel-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/perf-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-perf-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.71.0.151.u109.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/bpftool-5.10.0-136.71.0.151.u109.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2129</id>
		<title>An update for less is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32487" id="CVE-2024-32487" title="CVE-2024-32487" type="cve"></reference>
		</references>
		<description>CVE-2024-32487:less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="less" release="6.u3.fos23" version="590">
					<filename>less-590-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/less-590-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="less-help" release="6.u3.fos23" version="590">
					<filename>less-help-590-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/less-help-590-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="less" release="6.u3.fos23" version="590">
					<filename>less-590-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/less-590-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2130</id>
		<title>An update for libdwarf is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2002" id="CVE-2024-2002" title="CVE-2024-2002" type="cve"></reference>
		</references>
		<description>CVE-2024-2002:A double-free vulnerability was found in libdwarf. In a multiply-corrupted DWARF object, libdwarf may try to dealloc(free) an allocation twice, potentially causing unpredictable and various results.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="libdwarf" release="1.fos23" version="0.9.1">
					<filename>libdwarf-0.9.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libdwarf-0.9.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="libdwarf-devel" release="1.fos23" version="0.9.1">
					<filename>libdwarf-devel-0.9.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libdwarf-devel-0.9.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="libdwarf-tools" release="1.fos23" version="0.9.1">
					<filename>libdwarf-tools-0.9.1-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libdwarf-tools-0.9.1-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="libdwarf-help" release="1.fos23" version="0.9.1">
					<filename>libdwarf-help-0.9.1-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libdwarf-help-0.9.1-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libdwarf" release="1.fos23" version="0.9.1">
					<filename>libdwarf-0.9.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libdwarf-0.9.1-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libdwarf-devel" release="1.fos23" version="0.9.1">
					<filename>libdwarf-devel-0.9.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libdwarf-devel-0.9.1-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="libdwarf-tools" release="1.fos23" version="0.9.1">
					<filename>libdwarf-tools-0.9.1-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libdwarf-tools-0.9.1-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2131</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2357" id="CVE-2024-2357" title="CVE-2024-2357" type="cve"></reference>
		</references>
		<description>CVE-2024-2357:The Libreswan Project was notified of an issue causing libreswan to restart under some IKEv2 retransmit scenarios when a connection is configured to use PreSharedKeys (authby=secret) and the connection cannot find a matching configured secret. When such a connection is automatically added on startup using the auto= keyword, it can cause repeated crashes leading to a Denial of Service.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.14">
					<filename>libreswan-4.14-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libreswan-4.14-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.14">
					<filename>libreswan-help-4.14-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libreswan-help-4.14-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.14">
					<filename>libreswan-4.14-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libreswan-4.14-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.14">
					<filename>libreswan-help-4.14-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libreswan-help-4.14-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2132</id>
		<title>An update for libvirt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1441" id="CVE-2024-1441" title="CVE-2024-1441" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2494" id="CVE-2024-2494" title="CVE-2024-2494" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2496" id="CVE-2024-2496" title="CVE-2024-2496" type="cve"></reference>
		</references>
		<description>CVE-2024-1441:An off-by-one error flaw was found in the udevListInterfacesByStatus() function in libvirt when the number of interfaces exceeds the size of the `names` array. This issue can be reproduced by sending specially crafted data to the libvirt daemon, allowing an unprivileged client to perform a denial of service attack by causing the libvirt daemon to crash.&#xA;CVE-2024-2494:A flaw was found in the RPC library APIs of libvirt. The RPC server deserialization code allocates memory for arrays before the non-negative length check is performed by the C API entry points. Passing a negative length to the g_new0 function results in a crash due to the negative length being treated as a huge positive number. This flaw allows a local, unprivileged user to perform a denial of service attack by causing the libvirt daemon to crash.&#xA;CVE-2024-2496:A NULL pointer dereference flaw was found in the udevConnectListAllInterfaces() function in libvirt. This issue can occur when detaching a host interface while at the same time collecting the list of interfaces via virConnectListAllInterfaces API. This flaw could be used to perform a denial of service attack by causing the libvirt daemon to crash.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="libvirt" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-docs" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-docs-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-docs-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-config-network" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-network-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-config-network-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-config-nwfilter" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-nwfilter-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-config-nwfilter-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-network" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-network-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-network-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-nwfilter" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nwfilter-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-nwfilter-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-nodedev" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nodedev-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-nodedev-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-interface" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-interface-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-interface-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-secret" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-secret-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-secret-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-core" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-core-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-core-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-logical" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-logical-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-logical-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-disk" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-disk-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-disk-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-scsi" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-scsi-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-scsi-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-iscsi" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-iscsi-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-iscsi-direct" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-iscsi-direct-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-mpath" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-mpath-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-mpath-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-gluster" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-gluster-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-gluster-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-rbd" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-rbd-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-rbd-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-storage-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-qemu" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-qemu-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-driver-qemu-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-qemu" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-qemu-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-qemu-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-kvm" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-kvm-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-daemon-kvm-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-client" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-client-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-client-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-libs" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-libs-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-libs-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-admin" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-admin-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-admin-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-bash-completion" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-bash-completion-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-bash-completion-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-wireshark" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-wireshark-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-wireshark-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-devel" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-devel-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-devel-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-lock-sanlock" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-lock-sanlock-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-lock-sanlock-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-nss" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-nss-6.2.0-63.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libvirt-nss-6.2.0-63.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-docs" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-docs-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-docs-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-config-network" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-network-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-config-network-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-config-nwfilter" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-nwfilter-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-config-nwfilter-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-network" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-network-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-network-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-nwfilter" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nwfilter-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-nwfilter-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-nodedev" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nodedev-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-nodedev-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-interface" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-interface-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-interface-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-secret" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-secret-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-secret-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-core" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-core-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-core-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-logical" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-logical-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-logical-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-disk" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-disk-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-disk-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-scsi" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-scsi-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-scsi-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-iscsi" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-iscsi-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-iscsi-direct" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-iscsi-direct-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-mpath" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-mpath-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-mpath-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-gluster" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-gluster-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-gluster-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-rbd" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-rbd-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-rbd-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-storage-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-qemu" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-qemu-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-driver-qemu-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-qemu" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-qemu-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-qemu-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-kvm" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-daemon-kvm-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-daemon-kvm-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-client" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-client-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-client-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-libs" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-libs-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-libs-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-admin" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-admin-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-admin-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-bash-completion" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-bash-completion-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-bash-completion-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-wireshark" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-wireshark-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-wireshark-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-devel" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-devel-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-devel-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-lock-sanlock" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-lock-sanlock-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-lock-sanlock-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-nss" release="63.u9.fos23" version="6.2.0">
					<filename>libvirt-nss-6.2.0-63.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libvirt-nss-6.2.0-63.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2133</id>
		<title>An update for llvm is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46049" id="CVE-2023-46049" title="CVE-2023-46049" type="cve"></reference>
		</references>
		<description>CVE-2023-46049:LLVM 15.0.0 has a NULL pointer dereference in the parseOneMetadata() function via a crafted pdflatex.fmt file (or perhaps a crafted .o file) to llvm-lto. NOTE: this is disputed because the relationship between pdflatex.fmt and any LLVM language front end is not explained, and because a crash of the llvm-lto application should be categorized as a usability problem.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="llvm" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-12.0.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/llvm-12.0.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="llvm-libs" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-libs-12.0.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/llvm-libs-12.0.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="llvm-devel" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-devel-12.0.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/llvm-devel-12.0.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="llvm-help" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-help-12.0.1-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/llvm-help-12.0.1-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="llvm" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-12.0.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/llvm-12.0.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="llvm-libs" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-libs-12.0.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/llvm-libs-12.0.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="llvm-devel" release="7.u2.fos23" version="12.0.1">
					<filename>llvm-devel-12.0.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/llvm-devel-12.0.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2134</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38575" id="CVE-2023-38575" title="CVE-2023-38575" type="cve"></reference>
		</references>
		<description>CVE-2023-38575:Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="1.fos23" version="20240312">
					<filename>microcode_ctl-20240312-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/microcode_ctl-20240312-1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2135</id>
		<title>An update for mod_http2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"></reference>
		</references>
		<description>CVE-2024-27316:HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="mod_http2" release="3.u1.fos23" version="1.15.25">
					<filename>mod_http2-1.15.25-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_http2-1.15.25-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="mod_http2-help" release="3.u1.fos23" version="1.15.25">
					<filename>mod_http2-help-1.15.25-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_http2-help-1.15.25-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_http2" release="3.u1.fos23" version="1.15.25">
					<filename>mod_http2-1.15.25-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_http2-1.15.25-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2136</id>
		<title>An update for mod_security is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48279" id="CVE-2022-48279" title="CVE-2022-48279" type="cve"></reference>
		</references>
		<description>CVE-2022-48279:In ModSecurity before 2.9.6 and 3.x before 3.0.8, HTTP multipart requests were incorrectly parsed and could bypass the Web Application Firewall. NOTE: this is related to CVE-2022-39956 but can be considered independent changes to the ModSecurity (C language) codebase.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="mod_security" release="9.fos23" version="2.9.5">
					<filename>mod_security-2.9.5-9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_security-2.9.5-9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_security" release="9.fos23" version="2.9.5">
					<filename>mod_security-2.9.5-9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_security-2.9.5-9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2137</id>
		<title>An update for mozjs91 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23599" id="CVE-2023-23599" title="CVE-2023-23599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23601" id="CVE-2023-23601" title="CVE-2023-23601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23602" id="CVE-2023-23602" title="CVE-2023-23602" type="cve"></reference>
		</references>
		<description>CVE-2023-23599:When copying a network request from the developer tools panel as a curl command the output was not being properly sanitized and could allow arbitrary commands to be hidden within. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-23601:Navigations were being allowed when dragging a URL from a cross-origin iframe into the same tab which could lead to website spoofing attacks. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.&#xA;CVE-2023-23602:A mishandled security check when creating a WebSocket in a WebWorker caused the Content Security Policy connect-src header to be ignored. This could lead to connections to restricted origins from inside WebWorkers. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="mozjs91" release="4.u1.fos23" version="91.6.0">
					<filename>mozjs91-91.6.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mozjs91-91.6.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libmozjs-91-0" release="4.u1.fos23" version="91.6.0">
					<filename>libmozjs-91-0-91.6.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libmozjs-91-0-91.6.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mozjs91-devel" release="4.u1.fos23" version="91.6.0">
					<filename>mozjs91-devel-91.6.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mozjs91-devel-91.6.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mozjs91" release="4.u1.fos23" version="91.6.0">
					<filename>mozjs91-91.6.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mozjs91-91.6.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libmozjs-91-0" release="4.u1.fos23" version="91.6.0">
					<filename>libmozjs-91-0-91.6.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libmozjs-91-0-91.6.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mozjs91-devel" release="4.u1.fos23" version="91.6.0">
					<filename>mozjs91-devel-91.6.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mozjs91-devel-91.6.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2138</id>
		<title>An update for nghttp2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28182" id="CVE-2024-28182" title="CVE-2024-28182" type="cve"></reference>
		</references>
		<description>CVE-2024-28182:nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync.  This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="nghttp2" release="6.u4.fos23" version="1.46.0">
					<filename>nghttp2-1.46.0-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/nghttp2-1.46.0-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2" release="6.u4.fos23" version="1.46.0">
					<filename>libnghttp2-1.46.0-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libnghttp2-1.46.0-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2-devel" release="6.u4.fos23" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libnghttp2-devel-1.46.0-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nghttp2-help" release="6.u4.fos23" version="1.46.0">
					<filename>nghttp2-help-1.46.0-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/nghttp2-help-1.46.0-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nghttp2" release="6.u4.fos23" version="1.46.0">
					<filename>nghttp2-1.46.0-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/nghttp2-1.46.0-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2" release="6.u4.fos23" version="1.46.0">
					<filename>libnghttp2-1.46.0-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libnghttp2-1.46.0-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2-devel" release="6.u4.fos23" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libnghttp2-devel-1.46.0-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2139</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
		</references>
		<description>CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded&#xA;memory growth when processing TLSv1.3 sessions&#xA;Impact summary: An attacker may exploit certain server configurations to trigger&#xA;unbounded memory growth that would lead to a Denial of Service&#xA;This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is&#xA;being used (but not if early_data support is also configured and the default&#xA;anti-replay protection is in use). In this case, under certain conditions, the&#xA;session cache can get into an incorrect state and it will fail to flush properly&#xA;as it fills. The session cache will continue to grow in an unbounded manner. A&#xA;malicious client could deliberately create the scenario for this failure to&#xA;force a Denial of Service. It may also happen by accident in normal operation.&#xA;This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS&#xA;clients.&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL&#xA;1.0.2 is also not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="openssl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-libs-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-perl-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-devel-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-34.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-help-1.1.1m-34.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-libs-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-perl-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-devel-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2140</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2639" id="CVE-2022-2639" title="CVE-2022-2639" type="cve"></reference>
		</references>
		<description>CVE-2022-2639:An integer coercion error was found in the openvswitch kernel module. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, the reserve_sfa_size() function does not return -EMSGSIZE as expected, potentially leading to an out-of-bounds write access. This flaw allows a local user to crash or potentially escalate their privileges on the system.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="openvswitch" release="8.u6.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openvswitch-2.12.4-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-devel" release="8.u6.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openvswitch-devel-2.12.4-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-help" release="8.u6.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openvswitch-help-2.12.4-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-openvswitch" release="8.u6.fos23" version="2.12.4">
					<filename>python3-openvswitch-2.12.4-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-openvswitch-2.12.4-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch" release="8.u6.fos23" version="2.12.4">
					<filename>openvswitch-2.12.4-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openvswitch-2.12.4-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-devel" release="8.u6.fos23" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openvswitch-devel-2.12.4-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-help" release="8.u6.fos23" version="2.12.4">
					<filename>openvswitch-help-2.12.4-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openvswitch-help-2.12.4-8.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2141</id>
		<title>An update for pcp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3019" id="CVE-2024-3019" title="CVE-2024-3019" type="cve"></reference>
		</references>
		<description>CVE-2024-3019:A flaw was found in PCP. The default pmproxy configuration exposes the Redis server backend to the local network, allowing remote command execution with the privileges of the Redis user. This issue can only be exploited when pmproxy is running. By default, pmproxy is not running and needs to be started manually. The pmproxy service is usually started from the &#39;Metrics settings&#39; page of the Cockpit web interface. This flaw affects PCP versions 4.3.4 and newer.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-conf" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-conf-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-conf-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-devel" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-devel-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-devel-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pcp-help" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-help-5.3.7-4.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-help-5.3.7-4.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-PMDA" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-PMDA-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/perl-PCP-PMDA-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-MMV" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-MMV-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/perl-PCP-MMV-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-LogImport" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-LogImport-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/perl-PCP-LogImport-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-LogSummary" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-LogSummary-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/perl-PCP-LogSummary-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-sar2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-sar2pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-import-sar2pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-iostat2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-iostat2pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-import-iostat2pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-mrtg2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-mrtg2pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-import-mrtg2pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-ganglia2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-ganglia2pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-import-ganglia2pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-collectl2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-collectl2pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-import-collectl2pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-zabbix-agent" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-zabbix-agent-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-zabbix-agent-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2elasticsearch" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2elasticsearch-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2elasticsearch-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2graphite" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2graphite-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2graphite-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2influxdb" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2influxdb-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2influxdb-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2json" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2json-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2json-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2spark" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2spark-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2spark-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2xml" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2xml-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2xml-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2zabbix" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2zabbix-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-export-pcp2zabbix-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-podman" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-podman-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-podman-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-perfevent" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-perfevent-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-perfevent-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-infiniband" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-infiniband-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-infiniband-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-activemq" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-activemq-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-activemq-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bind2" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bind2-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-bind2-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-redis" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-redis-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-redis-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nutcracker" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nutcracker-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-nutcracker-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bonding" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bonding-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-bonding-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-dbping" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-dbping-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-dbping-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-ds389" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-ds389-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-ds389log" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389log-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-ds389log-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-elasticsearch" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-elasticsearch-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-elasticsearch-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gpfs" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gpfs-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-gpfs-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gpsd" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gpsd-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-gpsd-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-denki" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-denki-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-denki-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-docker" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-docker-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-docker-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lustre" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lustre-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-lustre-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lustrecomm" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lustrecomm-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-lustrecomm-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-memcache" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-memcache-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-memcache-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mysql" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mysql-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-mysql-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-named" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-named-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-named-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-netfilter" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-netfilter-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-netfilter-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-news" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-news-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-news-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nginx" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nginx-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-nginx-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nfsclient" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nfsclient-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-nfsclient-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-oracle" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-oracle-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-oracle-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-pdns" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-pdns-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-pdns-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-postfix" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-postfix-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-postfix-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-postgresql" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-postgresql-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-postgresql-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-rsyslog" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-rsyslog-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-rsyslog-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-samba" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-samba-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-samba-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-slurm" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-slurm-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-slurm-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-snmp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-snmp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-snmp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-zimbra" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-zimbra-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-zimbra-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-dm" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-dm-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-dm-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bcc" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bcc-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-bcc-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bpf" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bpf-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-bpf-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bpftrace" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bpftrace-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-bpftrace-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gluster" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gluster-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-gluster-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-zswap" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-zswap-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-zswap-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-unbound" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-unbound-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-unbound-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mic" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mic-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-mic-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-haproxy" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-haproxy-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-haproxy-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-libvirt" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-libvirt-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-libvirt-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-openvswitch" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-openvswitch-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-openvswitch-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-rabbitmq" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-rabbitmq-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-rabbitmq-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lio" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lio-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-lio-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-openmetrics" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-openmetrics-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-openmetrics-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-netcheck" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-netcheck-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-netcheck-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mongodb" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mongodb-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-mongodb-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mssql" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mssql-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-mssql-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-json" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-json-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-json-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-apache" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-apache-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-apache-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bash" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bash-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-bash-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-cifs" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-cifs-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-cifs-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-cisco" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-cisco-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-cisco-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gfs2" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gfs2-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-gfs2-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lmsensors" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lmsensors-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-lmsensors-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-logger" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-logger-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-logger-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mailq" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mailq-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-mailq-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mounts" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mounts-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-mounts-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nvidia-gpu" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nvidia-gpu-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-nvidia-gpu-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-roomtemp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-roomtemp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-roomtemp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-sendmail" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-sendmail-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-sendmail-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-shping" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-shping-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-shping-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-smart" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-smart-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-smart-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-sockets" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-sockets-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-sockets-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-hacluster" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-hacluster-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-hacluster-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-summary" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-summary-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-summary-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-systemd" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-systemd-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-systemd-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-trace" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-trace-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-trace-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-weblog" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-weblog-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-pmda-weblog-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-zeroconf" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-zeroconf-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-zeroconf-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pcp" release="4.u4.fos23" version="5.3.7">
					<filename>python3-pcp-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pcp-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-system-tools" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-system-tools-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-system-tools-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-gui" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-gui-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-gui-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-selinux" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-selinux-5.3.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/pcp-selinux-5.3.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-conf" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-conf-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-conf-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-devel" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-devel-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-devel-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-PMDA" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-PMDA-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/perl-PCP-PMDA-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-MMV" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-MMV-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/perl-PCP-MMV-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-LogImport" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-LogImport-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/perl-PCP-LogImport-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-LogSummary" release="4.u4.fos23" version="5.3.7">
					<filename>perl-PCP-LogSummary-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/perl-PCP-LogSummary-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-sar2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-sar2pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-import-sar2pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-iostat2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-iostat2pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-import-iostat2pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-mrtg2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-mrtg2pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-import-mrtg2pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-ganglia2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-ganglia2pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-import-ganglia2pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-collectl2pcp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-import-collectl2pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-import-collectl2pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-zabbix-agent" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-zabbix-agent-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-zabbix-agent-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2elasticsearch" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2elasticsearch-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2elasticsearch-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2graphite" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2graphite-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2graphite-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2influxdb" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2influxdb-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2influxdb-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2json" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2json-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2json-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2spark" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2spark-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2spark-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2xml" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2xml-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2xml-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2zabbix" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-export-pcp2zabbix-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-export-pcp2zabbix-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-podman" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-podman-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-podman-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-perfevent" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-perfevent-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-perfevent-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-infiniband" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-infiniband-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-infiniband-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-activemq" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-activemq-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-activemq-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bind2" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bind2-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-bind2-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-redis" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-redis-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-redis-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nutcracker" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nutcracker-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-nutcracker-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bonding" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bonding-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-bonding-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-dbping" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-dbping-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-dbping-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-ds389" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-ds389-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-ds389log" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389log-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-ds389log-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-elasticsearch" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-elasticsearch-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-elasticsearch-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gpfs" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gpfs-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-gpfs-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gpsd" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gpsd-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-gpsd-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-denki" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-denki-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-denki-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-docker" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-docker-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-docker-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lustre" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lustre-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-lustre-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lustrecomm" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lustrecomm-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-lustrecomm-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-memcache" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-memcache-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-memcache-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mysql" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mysql-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-mysql-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-named" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-named-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-named-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-netfilter" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-netfilter-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-netfilter-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-news" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-news-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-news-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nginx" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nginx-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-nginx-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nfsclient" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nfsclient-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-nfsclient-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-oracle" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-oracle-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-oracle-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-pdns" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-pdns-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-pdns-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-postfix" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-postfix-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-postfix-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-postgresql" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-postgresql-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-postgresql-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-rsyslog" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-rsyslog-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-rsyslog-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-samba" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-samba-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-samba-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-slurm" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-slurm-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-slurm-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-snmp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-snmp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-snmp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-zimbra" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-zimbra-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-zimbra-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-dm" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-dm-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-dm-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bpf" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bpf-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-bpf-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bpftrace" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bpftrace-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-bpftrace-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gluster" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gluster-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-gluster-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-zswap" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-zswap-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-zswap-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-unbound" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-unbound-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-unbound-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mic" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mic-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-mic-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-haproxy" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-haproxy-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-haproxy-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-libvirt" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-libvirt-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-libvirt-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-openvswitch" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-openvswitch-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-openvswitch-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-rabbitmq" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-rabbitmq-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-rabbitmq-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lio" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lio-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-lio-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-openmetrics" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-openmetrics-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-openmetrics-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-netcheck" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-netcheck-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-netcheck-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mongodb" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mongodb-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-mongodb-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-json" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-json-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-json-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-apache" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-apache-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-apache-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bash" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-bash-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-bash-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-cifs" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-cifs-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-cifs-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-cisco" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-cisco-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-cisco-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gfs2" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-gfs2-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-gfs2-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lmsensors" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-lmsensors-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-lmsensors-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-logger" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-logger-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-logger-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mailq" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mailq-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-mailq-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mounts" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-mounts-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-mounts-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nvidia-gpu" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-nvidia-gpu-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-nvidia-gpu-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-roomtemp" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-roomtemp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-roomtemp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-sendmail" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-sendmail-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-sendmail-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-shping" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-shping-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-shping-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-smart" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-smart-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-smart-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-sockets" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-sockets-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-sockets-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-hacluster" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-hacluster-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-hacluster-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-summary" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-summary-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-summary-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-systemd" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-systemd-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-systemd-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-trace" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-trace-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-trace-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-weblog" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-pmda-weblog-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-pmda-weblog-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-zeroconf" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-zeroconf-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-zeroconf-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pcp" release="4.u4.fos23" version="5.3.7">
					<filename>python3-pcp-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pcp-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-system-tools" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-system-tools-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-system-tools-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-gui" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-gui-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-gui-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-selinux" release="4.u4.fos23" version="5.3.7">
					<filename>pcp-selinux-5.3.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/pcp-selinux-5.3.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2142</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2756" id="CVE-2024-2756" title="CVE-2024-2756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3096" id="CVE-2024-3096" title="CVE-2024-3096" type="cve"></reference>
		</references>
		<description>CVE-2024-2756:An improper input validation vulnerability was found in PHP. Due to an incomplete fix to CVE-2022-31629, network and same-site attackers can set a standard insecure cookie in the victim&#39;s browser.&#xA;CVE-2024-3096:A null byte interaction error vulnerability was found in PHP. If a password stored with password_hash starts with a null byte (\x00), testing a blank string as the password via password_verify will incorrectly return true. If a user can create a password with a leading null byte (unlikely, but syntactically valid), an attacker could trivially compromise the victim&#39;s account by attempting to sign in with a blank string.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="php" release="3.u1.fos23" version="8.0.30">
					<filename>php-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="3.u1.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-cli-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="3.u1.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-dbg-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="3.u1.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-fpm-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="3.u1.fos23" version="8.0.30">
					<filename>php-common-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-common-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="3.u1.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-devel-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="3.u1.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-opcache-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="3.u1.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-ldap-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="3.u1.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-pdo-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="3.u1.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-mysqlnd-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="3.u1.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-pgsql-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="3.u1.fos23" version="8.0.30">
					<filename>php-process-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-process-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="3.u1.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-odbc-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="3.u1.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-soap-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="3.u1.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-snmp-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="3.u1.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-xml-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="3.u1.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-mbstring-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="3.u1.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-gd-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="3.u1.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-bcmath-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="3.u1.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-gmp-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="3.u1.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-dba-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="3.u1.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-tidy-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="3.u1.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-embedded-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="3.u1.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-intl-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="3.u1.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-enchant-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="3.u1.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-sodium-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="3.u1.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-ffi-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-help" release="3.u1.fos23" version="8.0.30">
					<filename>php-help-8.0.30-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/php-help-8.0.30-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="3.u1.fos23" version="8.0.30">
					<filename>php-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="3.u1.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-cli-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="3.u1.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-dbg-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="3.u1.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-fpm-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="3.u1.fos23" version="8.0.30">
					<filename>php-common-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-common-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="3.u1.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-devel-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="3.u1.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-opcache-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="3.u1.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-ldap-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="3.u1.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-pdo-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="3.u1.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-mysqlnd-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="3.u1.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-pgsql-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="3.u1.fos23" version="8.0.30">
					<filename>php-process-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-process-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="3.u1.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-odbc-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="3.u1.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-soap-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="3.u1.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-snmp-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="3.u1.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-xml-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="3.u1.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-mbstring-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="3.u1.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-gd-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="3.u1.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-bcmath-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="3.u1.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-gmp-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="3.u1.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-dba-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="3.u1.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-tidy-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="3.u1.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-embedded-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="3.u1.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-intl-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="3.u1.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-enchant-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="3.u1.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-sodium-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="3.u1.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-ffi-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-help" release="3.u1.fos23" version="8.0.30">
					<filename>php-help-8.0.30-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/php-help-8.0.30-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2143</id>
		<title>An update for python-aiosmtpd is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27305" id="CVE-2024-27305" title="CVE-2024-27305" type="cve"></reference>
		</references>
		<description>CVE-2024-27305:aiosmtpd is a reimplementation of the Python stdlib smtpd.py based on asyncio. aiosmtpd is vulnerable to inbound SMTP smuggling. SMTP smuggling is a novel vulnerability based on not so novel interpretation differences of the SMTP protocol. By exploiting SMTP smuggling, an attacker may send smuggle/spoof e-mails with fake sender addresses, allowing advanced phishing attacks. This issue is also existed in other SMTP software like Postfix. With the right SMTP server constellation, an attacker can send spoofed e-mails to inbound/receiving aiosmtpd instances. This issue has been addressed in version 1.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="noarch" epoch="0" name="python3-aiosmtpd" release="2.u1.fos23" version="1.4.2">
					<filename>python3-aiosmtpd-1.4.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-aiosmtpd-1.4.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-aiosmtpd-help" release="2.u1.fos23" version="1.4.2">
					<filename>python-aiosmtpd-help-1.4.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python-aiosmtpd-help-1.4.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2144</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28219" id="CVE-2024-28219" title="CVE-2024-28219" type="cve"></reference>
		</references>
		<description>CVE-2024-28219:In _imagingcms.c in Pillow before 10.3.0, a buffer overflow exists because strcpy is used instead of strncpy.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="python3-pillow" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pillow-9.0.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-devel" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pillow-devel-9.0.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pillow-help" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-help-9.0.1-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pillow-help-9.0.1-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-tk" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pillow-tk-9.0.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-qt" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pillow-qt-9.0.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-9.0.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pillow-9.0.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-devel" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pillow-devel-9.0.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-tk" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pillow-tk-9.0.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-qt" release="7.u4.fos23" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pillow-qt-9.0.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2145</id>
		<title>An update for python-pymongo is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21506" id="CVE-2024-21506" title="CVE-2024-21506" type="cve"></reference>
		</references>
		<description>CVE-2024-21506:Versions of the package pymongo before 4.6.3 are vulnerable to Out-of-bounds Read in the bson module. Using the crafted payload the attacker could force the parser to deserialize unmanaged memory. The parser tries to interpret bytes next to buffer and throws an exception with string. If the following bytes are not printable UTF-8 the parser throws an exception with a single byte.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="python3-bson" release="3.u2.fos23" version="3.11.3">
					<filename>python3-bson-3.11.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-bson-3.11.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pymongo" release="3.u2.fos23" version="3.11.3">
					<filename>python3-pymongo-3.11.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pymongo-3.11.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pymongo-gridfs" release="3.u2.fos23" version="3.11.3">
					<filename>python3-pymongo-gridfs-3.11.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-pymongo-gridfs-3.11.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pymongo-help" release="3.u2.fos23" version="3.11.3">
					<filename>python-pymongo-help-3.11.3-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python-pymongo-help-3.11.3-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-bson" release="3.u2.fos23" version="3.11.3">
					<filename>python3-bson-3.11.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-bson-3.11.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pymongo" release="3.u2.fos23" version="3.11.3">
					<filename>python3-pymongo-3.11.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pymongo-3.11.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pymongo-gridfs" release="3.u2.fos23" version="3.11.3">
					<filename>python3-pymongo-gridfs-3.11.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-pymongo-gridfs-3.11.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2146</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27043" id="CVE-2023-27043" title="CVE-2023-27043" type="cve"></reference>
		</references>
		<description>CVE-2023-27043:The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="python3" release="29.u11.fos23" version="3.9.9">
					<filename>python3-3.9.9-29.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-3.9.9-29.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="29.u11.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-29.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-unversioned-command-3.9.9-29.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="29.u11.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-29.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-devel-3.9.9-29.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="29.u11.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-29.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-debug-3.9.9-29.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="29.u11.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-29.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-help-3.9.9-29.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="29.u11.fos23" version="3.9.9">
					<filename>python3-3.9.9-29.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-3.9.9-29.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="29.u11.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-29.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-unversioned-command-3.9.9-29.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="29.u11.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-29.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-devel-3.9.9-29.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="29.u11.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-29.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-debug-3.9.9-29.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2147</id>
		<title>An update for tcpdump is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2397" id="CVE-2024-2397" title="CVE-2024-2397" type="cve"></reference>
		</references>
		<description>CVE-2024-2397:Due to a bug in packet data buffers management, the PPP printer in tcpdump can enter an infinite loop when reading a crafted DLT_PPP_SERIAL .pcap savefile.  This problem does not affect any tcpdump release, but it affected the git master branch from 2023-06-05 to 2024-03-21.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="14" name="tcpdump" release="8.u2.fos23" version="4.99.1">
					<filename>tcpdump-4.99.1-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/tcpdump-4.99.1-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="14" name="tcpdump-help" release="8.u2.fos23" version="4.99.1">
					<filename>tcpdump-help-4.99.1-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/tcpdump-help-4.99.1-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="tcpdump" release="8.u2.fos23" version="4.99.1">
					<filename>tcpdump-4.99.1-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/tcpdump-4.99.1-8.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="tcpdump-help" release="8.u2.fos23" version="4.99.1">
					<filename>tcpdump-help-4.99.1-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/tcpdump-help-4.99.1-8.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2148</id>
		<title>An update for telnet is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39028" id="CVE-2022-39028" title="CVE-2022-39028" type="cve"></reference>
		</references>
		<description>CVE-2022-39028:telnetd in GNU Inetutils through 2.3, MIT krb5-appl through 1.0.3, and derivative works has a NULL pointer dereference via 0xff 0xf7 or 0xff 0xf8. In a typical installation, the telnetd application would crash but the telnet service would remain available through inetd. However, if the telnetd application has many crashes within a short time interval, the telnet service would become unavailable after inetd logs a &#34;telnet/tcp server failing (looping), service terminated&#34; error. NOTE: MIT krb5-appl is not supported upstream but is shipped by a few Linux distributions. The affected code was removed from the supported MIT Kerberos 5 (aka krb5) product many years ago, at version 1.8.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="telnet" release="79.u1.fos23" version="0.17">
					<filename>telnet-0.17-79.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/telnet-0.17-79.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="telnet-help" release="79.u1.fos23" version="0.17">
					<filename>telnet-help-0.17-79.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/telnet-help-0.17-79.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="telnet" release="79.u1.fos23" version="0.17">
					<filename>telnet-0.17-79.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/telnet-0.17-79.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="telnet-help" release="79.u1.fos23" version="0.17">
					<filename>telnet-help-0.17-79.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/telnet-help-0.17-79.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2149</id>
		<title>An update for unixODBC is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1013" id="CVE-2024-1013" title="CVE-2024-1013" type="cve"></reference>
		</references>
		<description>CVE-2024-1013:An out-of-bounds stack write flaw was found in unixODBC on 64-bit architectures where the caller has 4 bytes and callee writes 8 bytes. This issue may go unnoticed on little-endian architectures, while big-endian architectures can be broken.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="unixODBC" release="3.u2.fos23" version="2.3.7">
					<filename>unixODBC-2.3.7-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/unixODBC-2.3.7-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unixODBC-devel" release="3.u2.fos23" version="2.3.7">
					<filename>unixODBC-devel-2.3.7-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/unixODBC-devel-2.3.7-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unixODBC" release="3.u2.fos23" version="2.3.7">
					<filename>unixODBC-2.3.7-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/unixODBC-2.3.7-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unixODBC-devel" release="3.u2.fos23" version="2.3.7">
					<filename>unixODBC-devel-2.3.7-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/unixODBC-devel-2.3.7-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2150</id>
		<title>An update for util-linux is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28085" id="CVE-2024-28085" title="CVE-2024-28085" type="cve"></reference>
		</references>
		<description>CVE-2024-28085:wall in util-linux through 2.40, often installed with setgid tty permissions, allows escape sequences to be sent to other users&#39; terminals through argv. (Specifically, escape sequences received from stdin are blocked, but escape sequences received from argv are not blocked.) There may be plausible scenarios where this leads to account takeover.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="util-linux" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/util-linux-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libfdisk" release="28.u13.fos23" version="2.37.2">
					<filename>libfdisk-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libfdisk-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmartcols" release="28.u13.fos23" version="2.37.2">
					<filename>libsmartcols-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libsmartcols-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libmount" release="28.u13.fos23" version="2.37.2">
					<filename>libmount-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libmount-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libblkid" release="28.u13.fos23" version="2.37.2">
					<filename>libblkid-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libblkid-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uuidd" release="28.u13.fos23" version="2.37.2">
					<filename>uuidd-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/uuidd-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libuuid" release="28.u13.fos23" version="2.37.2">
					<filename>libuuid-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/libuuid-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux-user" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-user-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/util-linux-user-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libmount" release="28.u13.fos23" version="2.37.2">
					<filename>python3-libmount-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/python3-libmount-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux-devel" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-devel-2.37.2-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/util-linux-devel-2.37.2-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="util-linux-help" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-help-2.37.2-28.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/util-linux-help-2.37.2-28.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/util-linux-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libfdisk" release="28.u13.fos23" version="2.37.2">
					<filename>libfdisk-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libfdisk-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmartcols" release="28.u13.fos23" version="2.37.2">
					<filename>libsmartcols-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libsmartcols-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libmount" release="28.u13.fos23" version="2.37.2">
					<filename>libmount-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libmount-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libblkid" release="28.u13.fos23" version="2.37.2">
					<filename>libblkid-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libblkid-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uuidd" release="28.u13.fos23" version="2.37.2">
					<filename>uuidd-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/uuidd-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libuuid" release="28.u13.fos23" version="2.37.2">
					<filename>libuuid-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/libuuid-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux-user" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-user-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/util-linux-user-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libmount" release="28.u13.fos23" version="2.37.2">
					<filename>python3-libmount-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/python3-libmount-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux-devel" release="28.u13.fos23" version="2.37.2">
					<filename>util-linux-devel-2.37.2-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/util-linux-devel-2.37.2-28.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2151</id>
		<title>An update for varnish is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30156" id="CVE-2024-30156" title="CVE-2024-30156" type="cve"></reference>
		</references>
		<description>CVE-2024-30156:Varnish Cache before 7.3.2 and 7.4.x before 7.4.3 (and before 6.0.13 LTS), and Varnish Enterprise 6 before 6.0.12r6, allows credits exhaustion for an HTTP/2 connection control flow window, aka a Broke Window Attack.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="varnish" release="1.fos23" version="7.4.3">
					<filename>varnish-7.4.3-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/varnish-7.4.3-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="varnish-devel" release="1.fos23" version="7.4.3">
					<filename>varnish-devel-7.4.3-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/varnish-devel-7.4.3-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="varnish-help" release="1.fos23" version="7.4.3">
					<filename>varnish-help-7.4.3-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/varnish-help-7.4.3-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish" release="1.fos23" version="7.4.3">
					<filename>varnish-7.4.3-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/varnish-7.4.3-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish-devel" release="1.fos23" version="7.4.3">
					<filename>varnish-devel-7.4.3-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/varnish-devel-7.4.3-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2152</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0666" id="CVE-2023-0666" title="CVE-2023-0666" type="cve"></reference>
		</references>
		<description>CVE-2023-0666:Due to failure in validating the length provided by an attacker-crafted RTPS packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="7.u10.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-7.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/wireshark-3.6.14-7.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="7.u10.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-7.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/wireshark-devel-3.6.14-7.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="7.u10.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-7.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/wireshark-help-3.6.14-7.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="7.u10.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-7.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/wireshark-3.6.14-7.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="7.u10.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-7.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/wireshark-devel-3.6.14-7.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="7.u10.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-7.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/wireshark-help-3.6.14-7.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2153</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31080" id="CVE-2024-31080" title="CVE-2024-31080" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31081" id="CVE-2024-31081" title="CVE-2024-31081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31082" id="CVE-2024-31082" title="CVE-2024-31082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"></reference>
		</references>
		<description>CVE-2024-31083:A use-after-free vulnerability was found in the ProcRenderAddGlyphs() function of Xorg servers. This issue occurs when AllocateGlyph() is called to store new glyphs sent by the client to the X server, potentially resulting in multiple entries pointing to the same non-refcounted glyphs. Consequently, ProcRenderAddGlyphs() may free a glyph, leading to a use-after-free scenario when the same glyph pointer is subsequently accessed. This flaw allows an authenticated attacker to execute arbitrary code on the system by sending a specially crafted request.&#xA;CVE-2024-31080:A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIGetSelectedEvents() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.&#xA;CVE-2024-31081:A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIPassiveGrabDevice() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.&#xA;CVE-2024-31082:A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcAppleDRICreatePixmap() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.&#xA;CVE-2024-31083:A use-after-free vulnerability was found in the ProcRenderAddGlyphs() function of Xorg servers. This issue occurs when AllocateGlyph() is called to store new glyphs sent by the client to the X server, potentially resulting in multiple entries pointing to the same non-refcounted glyphs. Consequently, ProcRenderAddGlyphs() may free a glyph, leading to a use-after-free scenario when the same glyph pointer is subsequently accessed. This flaw allows an authenticated attacker to execute arbitrary code on the system by sending a specially crafted request.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-common-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-Xnest-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-Xdmx-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-Xvfb-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-Xephyr-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-30.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-devel-1.20.11-30.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-30.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-help-1.20.11-30.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-30.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-source-1.20.11-30.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-common-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-Xnest-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-Xdmx-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-Xvfb-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-Xephyr-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="30.u15.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-30.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-devel-1.20.11-30.u15.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2154</id>
		<title>An update for xorg-x11-server-Xwayland is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-04-29"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31080" id="CVE-2024-31080" title="CVE-2024-31080" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31081" id="CVE-2024-31081" title="CVE-2024-31081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"></reference>
		</references>
		<description>CVE-2024-31080:A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIGetSelectedEvents() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.&#xA;CVE-2024-31081:A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIPassiveGrabDevice() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.&#xA;CVE-2024-31083:A use-after-free vulnerability was found in the ProcRenderAddGlyphs() function of Xorg servers. This issue occurs when AllocateGlyph() is called to store new glyphs sent by the client to the X server, potentially resulting in multiple entries pointing to the same non-refcounted glyphs. Consequently, ProcRenderAddGlyphs() may free a glyph, leading to a use-after-free scenario when the same glyph pointer is subsequently accessed. This flaw allows an authenticated attacker to execute arbitrary code on the system by sending a specially crafted request.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland" release="2.u1.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-Xwayland-22.1.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="2.u1.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/xorg-x11-server-Xwayland-devel-22.1.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland" release="2.u1.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-Xwayland-22.1.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="2.u1.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/xorg-x11-server-Xwayland-devel-22.1.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2155</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46159" id="CVE-2023-46159" title="CVE-2023-46159" type="cve"></reference>
		</references>
		<description>CVE-2023-46159:IBM Storage Ceph 5.3z1, 5.3z5, and 6.1z1 could allow an authenticated user on the network to cause a denial of service from RGW.  IBM X-Force ID:  268906.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="2" name="ceph" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-base" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-base-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephadm" release="20.u9.fos23" version="16.2.7">
					<filename>cephadm-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cephadm-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-common" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-common-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mds" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mds-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mon" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mon-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mgr" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-dashboard" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-dashboard-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-dashboard-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-diskprediction-local" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-diskprediction-local-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-diskprediction-local-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-modules-core" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-modules-core-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-modules-core-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-rook" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-rook-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-rook-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-k8sevents" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-k8sevents-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-k8sevents-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-cephadm" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-cephadm-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-mgr-cephadm-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-fuse" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-fuse-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="cephfs-mirror" release="20.u9.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cephfs-mirror-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-fuse" release="20.u9.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rbd-fuse-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-mirror" release="20.u9.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rbd-mirror-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-immutable-object-cache" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-immutable-object-cache-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-nbd" release="20.u9.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rbd-nbd-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-radosgw" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-radosgw-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephfs-top" release="20.u9.fos23" version="16.2.7">
					<filename>cephfs-top-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cephfs-top-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-resource-agents" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-resource-agents-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-osd" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-osd-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados2" release="20.u9.fos23" version="16.2.7">
					<filename>librados2-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/librados2-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados-devel" release="20.u9.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/librados-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradospp-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libradospp-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw2" release="20.u9.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/librgw2-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw-devel" release="20.u9.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/librgw-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rgw" release="20.u9.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-rgw-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rados" release="20.u9.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-rados-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite" release="20.u9.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libcephsqlite-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libcephsqlite-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper1" release="20.u9.fos23" version="16.2.7">
					<filename>libradosstriper1-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libradosstriper1-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libradosstriper-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd1" release="20.u9.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/librbd1-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd-devel" release="20.u9.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/librbd-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rbd" release="20.u9.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-rbd-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs2" release="20.u9.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libcephfs2-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libcephfs-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-cephfs" release="20.u9.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-cephfs-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-argparse" release="20.u9.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-ceph-argparse-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-common" release="20.u9.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-ceph-common-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-test" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-test-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rados-objclass-devel" release="20.u9.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rados-objclass-devel-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-selinux" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-selinux-16.2.7-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-selinux-16.2.7-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-grafana-dashboards" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-grafana-dashboards-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-grafana-dashboards-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-prometheus-alerts" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-prometheus-alerts-16.2.7-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ceph-prometheus-alerts-16.2.7-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-base" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-base-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-common" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-common-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mds" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-mds-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mon" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-mon-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mgr" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-mgr-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-fuse" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-fuse-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="cephfs-mirror" release="20.u9.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/cephfs-mirror-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-fuse" release="20.u9.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rbd-fuse-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-mirror" release="20.u9.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rbd-mirror-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-immutable-object-cache" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-immutable-object-cache-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-nbd" release="20.u9.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rbd-nbd-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-radosgw" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-radosgw-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-resource-agents" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-resource-agents-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-osd" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-osd-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados2" release="20.u9.fos23" version="16.2.7">
					<filename>librados2-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/librados2-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados-devel" release="20.u9.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/librados-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradospp-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libradospp-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw2" release="20.u9.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/librgw2-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw-devel" release="20.u9.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/librgw-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rgw" release="20.u9.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-rgw-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rados" release="20.u9.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-rados-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite" release="20.u9.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libcephsqlite-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libcephsqlite-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper1" release="20.u9.fos23" version="16.2.7">
					<filename>libradosstriper1-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libradosstriper1-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libradosstriper-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd1" release="20.u9.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/librbd1-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd-devel" release="20.u9.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/librbd-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rbd" release="20.u9.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-rbd-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs2" release="20.u9.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libcephfs2-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs-devel" release="20.u9.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libcephfs-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-cephfs" release="20.u9.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-cephfs-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-argparse" release="20.u9.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-ceph-argparse-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-common" release="20.u9.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-ceph-common-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-test" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-test-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rados-objclass-devel" release="20.u9.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rados-objclass-devel-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-selinux" release="20.u9.fos23" version="16.2.7">
					<filename>ceph-selinux-16.2.7-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ceph-selinux-16.2.7-20.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2156</id>
		<title>An update for cjson is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31755" id="CVE-2024-31755" title="CVE-2024-31755" type="cve"></reference>
		</references>
		<description>CVE-2024-31755:cJSON v1.7.17 was discovered to contain a segmentation violation, which can trigger through the second parameter of function cJSON_SetValuestring at cJSON.c.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="cjson" release="4.u2.fos23" version="1.7.15">
					<filename>cjson-1.7.15-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cjson-1.7.15-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cjson-devel" release="4.u2.fos23" version="1.7.15">
					<filename>cjson-devel-1.7.15-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cjson-devel-1.7.15-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson" release="4.u2.fos23" version="1.7.15">
					<filename>cjson-1.7.15-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/cjson-1.7.15-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson-devel" release="4.u2.fos23" version="1.7.15">
					<filename>cjson-devel-1.7.15-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/cjson-devel-1.7.15-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2157</id>
		<title>An update for cockpit is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35850" id="CVE-2020-35850" title="CVE-2020-35850" type="cve"></reference>
		</references>
		<description>CVE-2020-35850:An SSRF issue was discovered in cockpit-project.org Cockpit 234. NOTE: this is unrelated to the Agentejo Cockpit product. NOTE: the vendor states &#34;I don&#39;t think [it] is a big real-life issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="cockpit" release="14.u2.fos23" version="178">
					<filename>cockpit-178-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cockpit-178-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cockpit-devel" release="14.u2.fos23" version="178">
					<filename>cockpit-devel-178-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cockpit-devel-178-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-cockpit-machines" release="14.u2.fos23" version="178">
					<filename>cockpit-cockpit-machines-178-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cockpit-cockpit-machines-178-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-cockpit-machines-ovirt" release="14.u2.fos23" version="178">
					<filename>cockpit-cockpit-machines-ovirt-178-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cockpit-cockpit-machines-ovirt-178-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-help" release="14.u2.fos23" version="178">
					<filename>cockpit-help-178-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/cockpit-help-178-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cockpit" release="14.u2.fos23" version="178">
					<filename>cockpit-178-14.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/cockpit-178-14.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cockpit-devel" release="14.u2.fos23" version="178">
					<filename>cockpit-devel-178-14.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/cockpit-devel-178-14.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2158</id>
		<title>An update for fdupes is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48682" id="CVE-2022-48682" title="CVE-2022-48682" type="cve"></reference>
		</references>
		<description>CVE-2022-48682:In deletefiles in FDUPES before 2.2.0, a TOCTOU race condition allows arbitrary file deletion via a symlink.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="1" name="fdupes" release="1.fos23" version="2.3.0">
					<filename>fdupes-2.3.0-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/fdupes-2.3.0-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="fdupes-help" release="1.fos23" version="2.3.0">
					<filename>fdupes-help-2.3.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/fdupes-help-2.3.0-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="fdupes" release="1.fos23" version="2.3.0">
					<filename>fdupes-2.3.0-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/fdupes-2.3.0-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2159</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44488" id="CVE-2023-44488" title="CVE-2023-44488" type="cve"></reference>
		</references>
		<description>CVE-2023-44488:VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="firefox" release="6.u6.fos23" version="102.15.0">
					<filename>firefox-102.15.0-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/firefox-102.15.0-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="firefox" release="6.u6.fos23" version="102.15.0">
					<filename>firefox-102.15.0-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/firefox-102.15.0-6.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2160</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32039" id="CVE-2024-32039" title="CVE-2024-32039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32040" id="CVE-2024-32040" title="CVE-2024-32040" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32041" id="CVE-2024-32041" title="CVE-2024-32041" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32458" id="CVE-2024-32458" title="CVE-2024-32458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32459" id="CVE-2024-32459" title="CVE-2024-32459" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32460" id="CVE-2024-32460" title="CVE-2024-32460" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32658" id="CVE-2024-32658" title="CVE-2024-32658" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32659" id="CVE-2024-32659" title="CVE-2024-32659" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32660" id="CVE-2024-32660" title="CVE-2024-32660" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32661" id="CVE-2024-32661" title="CVE-2024-32661" type="cve"></reference>
		</references>
		<description>CVE-2024-32039:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients using a version of FreeRDP prior to 3.5.0 or 2.11.6 are vulnerable to integer overflow and out-of-bounds write. Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, do not use `/gfx` options (e.g. deactivate with `/bpp:32` or `/rfx` as it is on by default).&#xA;CVE-2024-32040:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients that use a version of FreeRDP prior to 3.5.0 or 2.11.6 and have connections to servers using the `NSC` codec are vulnerable to integer underflow. Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, do not use the NSC codec (e.g. use `-nsc`).&#xA;CVE-2024-32041:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients that use a version of FreeRDP prior to 3.5.0 or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, deactivate `/gfx` (on by default, set `/bpp` or `/rfx` options instead.&#xA;CVE-2024-32458:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients that use a version of FreeRDP prior to 3.5.0 or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, use `/gfx` or `/rfx` modes (on by default, require server side support).&#xA;CVE-2024-32459:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients and servers that use a version of FreeRDP prior to 3.5.0 or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and 2.11.6 patch the issue. No known workarounds are available.&#xA;CVE-2024-32460:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based based clients using `/bpp:32` legacy `GDI` drawing path with a version of FreeRDP prior to 3.5.0 or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, use modern drawing paths (e.g. `/rfx` or `/gfx` options). The workaround requires server side support.&#xA;CVE-2024-32658:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients prior to version 3.5.1 are vulnerable to out-of-bounds read. Version 3.5.1 contains a patch for the issue. No known workarounds are available.&#xA;CVE-2024-32659:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients prior to version 3.5.1 are vulnerable to out-of-bounds read if `((nWidth == 0) and (nHeight == 0))`. Version 3.5.1 contains a patch for the issue. No known workarounds are available.&#xA;CVE-2024-32660:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.5.1, a malicious server can crash the FreeRDP client by sending invalid huge allocation size. Version 3.5.1 contains a patch for the issue. No known workarounds are available.&#xA;CVE-2024-32661:FreeRDP is a free implementation of the Remote Desktop Protocol. FreeRDP based clients prior to version 3.5.1 are vulnerable to a possible `NULL` access and crash. Version 3.5.1 contains a patch for the issue. No known workarounds are available.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="2" name="freerdp" release="2.u1.fos23" version="2.11.7">
					<filename>freerdp-2.11.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/freerdp-2.11.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-devel" release="2.u1.fos23" version="2.11.7">
					<filename>freerdp-devel-2.11.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/freerdp-devel-2.11.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr" release="2.u1.fos23" version="2.11.7">
					<filename>libwinpr-2.11.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libwinpr-2.11.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr-devel" release="2.u1.fos23" version="2.11.7">
					<filename>libwinpr-devel-2.11.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libwinpr-devel-2.11.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-help" release="2.u1.fos23" version="2.11.7">
					<filename>freerdp-help-2.11.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/freerdp-help-2.11.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp" release="2.u1.fos23" version="2.11.7">
					<filename>freerdp-2.11.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/freerdp-2.11.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-devel" release="2.u1.fos23" version="2.11.7">
					<filename>freerdp-devel-2.11.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/freerdp-devel-2.11.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr" release="2.u1.fos23" version="2.11.7">
					<filename>libwinpr-2.11.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libwinpr-2.11.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr-devel" release="2.u1.fos23" version="2.11.7">
					<filename>libwinpr-devel-2.11.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libwinpr-devel-2.11.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-help" release="2.u1.fos23" version="2.11.7">
					<filename>freerdp-help-2.11.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/freerdp-help-2.11.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2161</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52722" id="CVE-2023-52722" title="CVE-2023-52722" type="cve"></reference>
		</references>
		<description>CVE-2023-52722:An issue was discovered in Artifex Ghostscript through 10.01.0. psi/zmisc1.c, when SAFER mode is used, allows eexec seeds other than the Type 1 standard.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ghostscript-9.55.0-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ghostscript-devel-9.55.0-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-7.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ghostscript-help-9.55.0-7.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ghostscript-tools-dvipdf-9.55.0-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ghostscript-9.55.0-7.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ghostscript-devel-9.55.0-7.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="7.u6.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ghostscript-tools-dvipdf-9.55.0-7.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2162</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33599" id="CVE-2024-33599" title="CVE-2024-33599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33601" id="CVE-2024-33601" title="CVE-2024-33601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33600" id="CVE-2024-33600" title="CVE-2024-33600" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33602" id="CVE-2024-33602" title="CVE-2024-33602" type="cve"></reference>
		</references>
		<description>CVE-2024-33599:nscd: Stack-based buffer overflow in netgroup cache&#xA;If the Name Service Cache Daemon&#39;s (nscd) fixed size cache is exhausted&#xA;by client requests then a subsequent client request for netgroup data&#xA;may result in a stack-based buffer overflow.  This flaw was introduced&#xA;in glibc 2.15 when the cache was added to nscd.&#xA;This vulnerability is only present in the nscd binary.&#xA;CVE-2024-33601:nscd: netgroup cache may terminate daemon on memory allocation failure&#xA;The Name Service Cache Daemon&#39;s (nscd) netgroup cache uses xmalloc or&#xA;xrealloc and these functions may terminate the process due to a memory&#xA;allocation failure resulting in a denial of service to the clients.  The&#xA;flaw was introduced in glibc 2.15 when the cache was added to nscd.&#xA;This vulnerability is only present in the nscd binary.&#xA;CVE-2024-33600:nscd: Null pointer crashes after notfound response&#xA;If the Name Service Cache Daemon&#39;s (nscd) cache fails to add a not-found&#xA;netgroup response to the cache, the client request can result in a null&#xA;pointer dereference.  This flaw was introduced in glibc 2.15 when the&#xA;cache was added to nscd.&#xA;This vulnerability is only present in the nscd binary.&#xA;CVE-2024-33602:nscd: netgroup cache assumes NSS callback uses in-buffer strings&#xA;The Name Service Cache Daemon&#39;s (nscd) netgroup cache can corrupt memory&#xA;when the NSS callback does not store all strings in the provided buffer.&#xA;The flaw was introduced in glibc 2.15 when the cache was added to nscd.&#xA;This vulnerability is only present in the nscd binary.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="glibc" release="150.u23.fos23" version="2.34">
					<filename>glibc-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="150.u23.fos23" version="2.34">
					<filename>glibc-common-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-common-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="150.u23.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-all-langpacks-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="150.u23.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-locale-source-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="150.u23.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-locale-archive-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="150.u23.fos23" version="2.34">
					<filename>glibc-devel-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-devel-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="150.u23.fos23" version="2.34">
					<filename>nscd-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/nscd-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="150.u23.fos23" version="2.34">
					<filename>nss_modules-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/nss_modules-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="150.u23.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-nss-devel-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="150.u23.fos23" version="2.34">
					<filename>libnsl-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libnsl-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="150.u23.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-debugutils-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="150.u23.fos23" version="2.34">
					<filename>glibc-help-2.34-150.u23.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-help-2.34-150.u23.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="150.u23.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-150.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/glibc-compat-2.17-2.34-150.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="150.u23.fos23" version="2.34">
					<filename>glibc-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="150.u23.fos23" version="2.34">
					<filename>glibc-common-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-common-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="150.u23.fos23" version="2.34">
					<filename>glibc-all-langpacks-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-all-langpacks-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="150.u23.fos23" version="2.34">
					<filename>glibc-locale-source-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-locale-source-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="150.u23.fos23" version="2.34">
					<filename>glibc-locale-archive-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-locale-archive-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="150.u23.fos23" version="2.34">
					<filename>glibc-devel-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-devel-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="150.u23.fos23" version="2.34">
					<filename>nscd-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/nscd-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="150.u23.fos23" version="2.34">
					<filename>nss_modules-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/nss_modules-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="150.u23.fos23" version="2.34">
					<filename>glibc-nss-devel-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-nss-devel-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="150.u23.fos23" version="2.34">
					<filename>libnsl-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libnsl-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="150.u23.fos23" version="2.34">
					<filename>glibc-debugutils-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-debugutils-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="150.u23.fos23" version="2.34">
					<filename>glibc-compat-2.17-2.34-150.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/glibc-compat-2.17-2.34-150.u23.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2163</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45289" id="CVE-2023-45289" title="CVE-2023-45289" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45290" id="CVE-2023-45290" title="CVE-2023-45290" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24783" id="CVE-2024-24783" title="CVE-2024-24783" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24785" id="CVE-2024-24785" title="CVE-2024-24785" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24784" id="CVE-2024-24784" title="CVE-2024-24784" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45288" id="CVE-2023-45288" title="CVE-2023-45288" type="cve"></reference>
		</references>
		<description>CVE-2023-45289:When following an HTTP redirect to a domain which is not a subdomain match or exact match of the initial domain, an http.Client does not forward sensitive headers such as &#34;Authorization&#34; or &#34;Cookie&#34;. For example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to bar.com will not. A maliciously crafted HTTP redirect could cause sensitive headers to be unexpectedly forwarded.&#xA;CVE-2023-45290:When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.&#xA;CVE-2024-24783:Verifying a certificate chain which contains a certificate with an unknown public key algorithm will cause Certificate.Verify to panic. This affects all crypto/tls clients, and servers that set Config.ClientAuth to VerifyClientCertIfGiven or RequireAndVerifyClientCert. The default behavior is for TLS servers to not verify client certificates.&#xA;CVE-2024-24785:If errors returned from MarshalJSON methods contain user controlled data, they may be used to break the contextual auto-escaping behavior of the html/template package, allowing for subsequent actions to inject unexpected content into templates.&#xA;CVE-2024-24784:The ParseAddressList function incorrectly handles comments (text within parentheses) within display names. Since this is a misalignment with conforming address parsers, it can result in different trust decisions being made by programs using different parsers.&#xA;CVE-2023-45288:An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request&#39;s headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u9.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-1.20.5-3.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u9.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-help-1.20.5-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u9.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-devel-1.20.5-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u9.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/golang-1.20.5-3.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2164</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38709" id="CVE-2023-38709" title="CVE-2023-38709" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24795" id="CVE-2024-24795" title="CVE-2024-24795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"></reference>
		</references>
		<description>CVE-2023-38709:Faulty input validation in the core of Apache allows malicious or exploitable backend/content generators to split HTTP responses.&#xA;This issue affects Apache HTTP Server: through 2.4.58.&#xA;CVE-2024-24795:HTTP Response splitting in multiple modules in Apache HTTP Server allows an attacker that can inject malicious response headers into backend applications to cause an HTTP desynchronization attack.&#xA;Users are recommended to upgrade to version 2.4.59, which fixes this issue.&#xA;CVE-2024-27316:HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="httpd" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-devel-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-help-2.4.51-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-filesystem-2.4.51-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-tools-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_ssl-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="21.u11.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_md-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="21.u11.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_proxy_html-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_ldap-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="21.u11.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_session-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/httpd-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/httpd-devel-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/httpd-tools-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_ssl-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="21.u11.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_md-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="21.u11.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_proxy_html-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_ldap-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="21.u11.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_session-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2165</id>
		<title>An update for iSulad is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33632" id="CVE-2021-33632" title="CVE-2021-33632" type="cve"></reference>
		</references>
		<description>CVE-2021-33632:Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in openEuler iSulad on Linux allows Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions. This vulnerability is associated with program files https://gitee.Com/openeuler/iSulad/blob/master/src/cmd/isulad/main.C.&#xA;This issue affects iSulad: 2.0.18-13, from 2.1.4-1 through 2.1.4-2.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="iSulad" release="17.u10.fos23" version="2.0.18">
					<filename>iSulad-2.0.18-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/iSulad-2.0.18-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iSulad" release="17.u10.fos23" version="2.0.18">
					<filename>iSulad-2.0.18-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/iSulad-2.0.18-17.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2166</id>
		<title>An update for iperf3 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26306" id="CVE-2024-26306" title="CVE-2024-26306" type="cve"></reference>
		</references>
		<description>CVE-2024-26306:iPerf3 before 3.17, when used with OpenSSL before 3.2.0 as a server with RSA authentication, allows a timing side channel in RSA decryption operations. This side channel could be sufficient for an attacker to recover credential plaintext. It requires the attacker to send a large number of messages for decryption, as described in &#34;Everlasting ROBOT: the Marvin Attack&#34; by Hubert Kario.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="iperf3" release="3.u2.fos23" version="3.16">
					<filename>iperf3-3.16-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/iperf3-3.16-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3-devel" release="3.u2.fos23" version="3.16">
					<filename>iperf3-devel-3.16-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/iperf3-devel-3.16-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="iperf3-help" release="3.u2.fos23" version="3.16">
					<filename>iperf3-help-3.16-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/iperf3-help-3.16-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3" release="3.u2.fos23" version="3.16">
					<filename>iperf3-3.16-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/iperf3-3.16-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3-devel" release="3.u2.fos23" version="3.16">
					<filename>iperf3-devel-3.16-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/iperf3-devel-3.16-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2167</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52530" id="CVE-2023-52530" title="CVE-2023-52530" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52504" id="CVE-2023-52504" title="CVE-2023-52504" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47070" id="CVE-2021-47070" title="CVE-2021-47070" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52561" id="CVE-2023-52561" title="CVE-2023-52561" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52594" id="CVE-2023-52594" title="CVE-2023-52594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52572" id="CVE-2023-52572" title="CVE-2023-52572" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26810" id="CVE-2024-26810" title="CVE-2024-26810" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47101" id="CVE-2021-47101" title="CVE-2021-47101" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52587" id="CVE-2023-52587" title="CVE-2023-52587" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27437" id="CVE-2024-27437" title="CVE-2024-27437" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26698" id="CVE-2024-26698" title="CVE-2024-26698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52560" id="CVE-2023-52560" title="CVE-2023-52560" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52597" id="CVE-2023-52597" title="CVE-2023-52597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52578" id="CVE-2023-52578" title="CVE-2023-52578" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52574" id="CVE-2023-52574" title="CVE-2023-52574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52595" id="CVE-2023-52595" title="CVE-2023-52595" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26656" id="CVE-2024-26656" title="CVE-2024-26656" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52516" id="CVE-2023-52516" title="CVE-2023-52516" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52464" id="CVE-2023-52464" title="CVE-2023-52464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26759" id="CVE-2024-26759" title="CVE-2024-26759" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26751" id="CVE-2024-26751" title="CVE-2024-26751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26778" id="CVE-2024-26778" title="CVE-2024-26778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26772" id="CVE-2024-26772" title="CVE-2024-26772" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52640" id="CVE-2023-52640" title="CVE-2023-52640" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26695" id="CVE-2024-26695" title="CVE-2024-26695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26736" id="CVE-2024-26736" title="CVE-2024-26736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26777" id="CVE-2024-26777" title="CVE-2024-26777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52598" id="CVE-2023-52598" title="CVE-2023-52598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26771" id="CVE-2024-26771" title="CVE-2024-26771" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52503" id="CVE-2023-52503" title="CVE-2023-52503" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52493" id="CVE-2023-52493" title="CVE-2023-52493" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26795" id="CVE-2024-26795" title="CVE-2024-26795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52607" id="CVE-2023-52607" title="CVE-2023-52607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26615" id="CVE-2024-26615" title="CVE-2024-26615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52491" id="CVE-2023-52491" title="CVE-2023-52491" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7042" id="CVE-2023-7042" title="CVE-2023-7042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52617" id="CVE-2023-52617" title="CVE-2023-52617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52608" id="CVE-2023-52608" title="CVE-2023-52608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52498" id="CVE-2023-52498" title="CVE-2023-52498" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47182" id="CVE-2021-47182" title="CVE-2021-47182" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24861" id="CVE-2024-24861" title="CVE-2024-24861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52492" id="CVE-2023-52492" title="CVE-2023-52492" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26764" id="CVE-2024-26764" title="CVE-2024-26764" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52441" id="CVE-2023-52441" title="CVE-2023-52441" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6270" id="CVE-2023-6270" title="CVE-2023-6270" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26885" id="CVE-2024-26885" title="CVE-2024-26885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26884" id="CVE-2024-26884" title="CVE-2024-26884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26883" id="CVE-2024-26883" title="CVE-2024-26883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26882" id="CVE-2024-26882" title="CVE-2024-26882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26817" id="CVE-2024-26817" title="CVE-2024-26817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47211" id="CVE-2021-47211" title="CVE-2021-47211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26843" id="CVE-2024-26843" title="CVE-2024-26843" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26840" id="CVE-2024-26840" title="CVE-2024-26840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26874" id="CVE-2024-26874" title="CVE-2024-26874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26900" id="CVE-2024-26900" title="CVE-2024-26900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26894" id="CVE-2024-26894" title="CVE-2024-26894" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52642" id="CVE-2023-52642" title="CVE-2023-52642" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26839" id="CVE-2024-26839" title="CVE-2024-26839" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26855" id="CVE-2024-26855" title="CVE-2024-26855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26893" id="CVE-2024-26893" title="CVE-2024-26893" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25739" id="CVE-2024-25739" title="CVE-2024-25739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47212" id="CVE-2021-47212" title="CVE-2021-47212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26901" id="CVE-2024-26901" title="CVE-2024-26901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26875" id="CVE-2024-26875" title="CVE-2024-26875" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48655" id="CVE-2022-48655" title="CVE-2022-48655" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26898" id="CVE-2024-26898" title="CVE-2024-26898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26669" id="CVE-2024-26669" title="CVE-2024-26669" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26680" id="CVE-2024-26680" title="CVE-2024-26680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26668" id="CVE-2024-26668" title="CVE-2024-26668" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52620" id="CVE-2023-52620" title="CVE-2023-52620" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27073" id="CVE-2024-27073" title="CVE-2024-27073" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27008" id="CVE-2024-27008" title="CVE-2024-27008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26958" id="CVE-2024-26958" title="CVE-2024-26958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26972" id="CVE-2024-26972" title="CVE-2024-26972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26811" id="CVE-2024-26811" title="CVE-2024-26811" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26828" id="CVE-2024-26828" title="CVE-2024-26828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26870" id="CVE-2024-26870" title="CVE-2024-26870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27059" id="CVE-2024-27059" title="CVE-2024-27059" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27043" id="CVE-2024-27043" title="CVE-2024-27043" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26965" id="CVE-2024-26965" title="CVE-2024-26965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26812" id="CVE-2024-26812" title="CVE-2024-26812" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26961" id="CVE-2024-26961" title="CVE-2024-26961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26931" id="CVE-2024-26931" title="CVE-2024-26931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52650" id="CVE-2023-52650" title="CVE-2023-52650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26704" id="CVE-2024-26704" title="CVE-2024-26704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26791" id="CVE-2024-26791" title="CVE-2024-26791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26689" id="CVE-2024-26689" title="CVE-2024-26689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26950" id="CVE-2024-26950" title="CVE-2024-26950" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27000" id="CVE-2024-27000" title="CVE-2024-27000" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26878" id="CVE-2024-26878" title="CVE-2024-26878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27075" id="CVE-2024-27075" title="CVE-2024-27075" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27389" id="CVE-2024-27389" title="CVE-2024-27389" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26973" id="CVE-2024-26973" title="CVE-2024-26973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26993" id="CVE-2024-26993" title="CVE-2024-26993" type="cve"></reference>
		</references>
		<description>CVE-2023-52530:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: fix potential key use-after-free&#xA;When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()&#xA;but returns 0 due to KRACK protection (identical key reinstall),&#xA;ieee80211_gtk_rekey_add() will still return a pointer into the&#xA;key, in a potential use-after-free. This normally doesn&#39;t happen&#xA;since it&#39;s only called by iwlwifi in case of WoWLAN rekey offload&#xA;which has its own KRACK protection, but still better to fix, do&#xA;that by returning an error code and converting that to success on&#xA;the cfg80211 boundary only, leaving the error for bad callers of&#xA;ieee80211_gtk_rekey_add().&#xA;CVE-2023-52504:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/alternatives: Disable KASAN in apply_alternatives()&#xA;Fei has reported that KASAN triggers during apply_alternatives() on&#xA;a 5-level paging machine:&#xA;&#x9;BUG: KASAN: out-of-bounds in rcu_is_watching()&#xA;&#x9;Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0&#xA;&#x9;...&#xA;&#x9;__asan_load4()&#xA;&#x9;rcu_is_watching()&#xA;&#x9;trace_hardirqs_on()&#xA;&#x9;text_poke_early()&#xA;&#x9;apply_alternatives()&#xA;&#x9;...&#xA;On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)&#xA;gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on&#xA;__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().&#xA;KASAN gets confused when apply_alternatives() patches the&#xA;KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START&#xA;static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.&#xA;Fix it for real by disabling KASAN while the kernel is patching alternatives.&#xA;[ mingo: updated the changelog ]&#xA;CVE-2021-47070:In the Linux kernel, the following vulnerability has been resolved:&#xA;uio_hv_generic: Fix another memory leak in error handling paths&#xA;Memory allocated by &#39;vmbus_alloc_ring()&#39; at the beginning of the probe&#xA;function is never freed in the error handling path.&#xA;Add the missing &#39;vmbus_free_ring()&#39; call.&#xA;Note that it is already freed in the .remove function.&#xA;CVE-2023-52561:In the Linux kernel, the following vulnerability has been resolved:&#xA;arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved&#xA;Adding a reserved memory region for the framebuffer memory&#xA;(the splash memory region set up by the bootloader).&#xA;It fixes a kernel panic (arm-smmu: Unhandled context fault&#xA;at this particular memory region) reported on DB845c running&#xA;v5.10.y.&#xA;CVE-2023-52594:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()&#xA;Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug&#xA;occurs when txs-&gt;cnt, data from a URB provided by a USB device, is&#xA;bigger than the size of the array txs-&gt;txstatus, which is&#xA;HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug&#xA;handling code after the check. Make the function return if that is the&#xA;case.&#xA;Found by a modified version of syzkaller.&#xA;UBSAN: array-index-out-of-bounds in htc_drv_txrx.c&#xA;index 13 is out of range for type &#39;__wmi_event_txstatus [12]&#39;&#xA;Call Trace:&#xA; ath9k_htc_txstatus&#xA; ath9k_wmi_event_tasklet&#xA; tasklet_action_common&#xA; __do_softirq&#xA; irq_exit_rxu&#xA; sysvec_apic_timer_interrupt&#xA;CVE-2023-52572:In the Linux kernel, the following vulnerability has been resolved:&#xA;cifs: Fix UAF in cifs_demultiplex_thread()&#xA;There is a UAF when xfstests on cifs:&#xA;  BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160&#xA;  Read of size 4 at addr ffff88810103fc08 by task cifsd/923&#xA;  CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45&#xA;  ...&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x34/0x44&#xA;   print_report+0x171/0x472&#xA;   kasan_report+0xad/0x130&#xA;   kasan_check_range+0x145/0x1a0&#xA;   smb2_is_network_name_deleted+0x27/0x160&#xA;   cifs_demultiplex_thread.cold+0x172/0x5a4&#xA;   kthread+0x165/0x1a0&#xA;   ret_from_fork+0x1f/0x30&#xA;   &lt;/TASK&gt;&#xA;  Allocated by task 923:&#xA;   kasan_save_stack+0x1e/0x40&#xA;   kasan_set_track+0x21/0x30&#xA;   __kasan_slab_alloc+0x54/0x60&#xA;   kmem_cache_alloc+0x147/0x320&#xA;   mempool_alloc+0xe1/0x260&#xA;   cifs_small_buf_get+0x24/0x60&#xA;   allocate_buffers+0xa1/0x1c0&#xA;   cifs_demultiplex_thread+0x199/0x10d0&#xA;   kthread+0x165/0x1a0&#xA;   ret_from_fork+0x1f/0x30&#xA;  Freed by task 921:&#xA;   kasan_save_stack+0x1e/0x40&#xA;   kasan_set_track+0x21/0x30&#xA;   kasan_save_free_info+0x2a/0x40&#xA;   ____kasan_slab_free+0x143/0x1b0&#xA;   kmem_cache_free+0xe3/0x4d0&#xA;   cifs_small_buf_release+0x29/0x90&#xA;   SMB2_negotiate+0x8b7/0x1c60&#xA;   smb2_negotiate+0x51/0x70&#xA;   cifs_negotiate_protocol+0xf0/0x160&#xA;   cifs_get_smb_ses+0x5fa/0x13c0&#xA;   mount_get_conns+0x7a/0x750&#xA;   cifs_mount+0x103/0xd00&#xA;   cifs_smb3_do_mount+0x1dd/0xcb0&#xA;   smb3_get_tree+0x1d5/0x300&#xA;   vfs_get_tree+0x41/0xf0&#xA;   path_mount+0x9b3/0xdd0&#xA;   __x64_sys_mount+0x190/0x1d0&#xA;   do_syscall_64+0x35/0x80&#xA;   entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA;The UAF is because:&#xA; mount(pid: 921)               | cifsd(pid: 923)&#xA;-------------------------------|-------------------------------&#xA;                               | cifs_demultiplex_thread&#xA;SMB2_negotiate                 |&#xA; cifs_send_recv                |&#xA;  compound_send_recv           |&#xA;   smb_send_rqst               |&#xA;    wait_for_response          |&#xA;     wait_event_state      [1] |&#xA;                               |  standard_receive3&#xA;                               |   cifs_handle_standard&#xA;                               |    handle_mid&#xA;                               |     mid-&gt;resp_buf = buf;  [2]&#xA;                               |     dequeue_mid           [3]&#xA;     KILL the process      [4] |&#xA;    resp_iov[i].iov_base = buf |&#xA; free_rsp_buf              [5] |&#xA;                               |   is_network_name_deleted [6]&#xA;                               |   callback&#xA;1. After send request to server, wait the response until&#xA;    mid-&gt;mid_state != SUBMITTED;&#xA;2. Receive response from server, and set it to mid;&#xA;3. Set the mid state to RECEIVED;&#xA;4. Kill the process, the mid state already RECEIVED, get 0;&#xA;5. Handle and release the negotiate response;&#xA;6. UAF.&#xA;It can be easily reproduce with add some delay in [3] - [6].&#xA;Only sync call has the problem since async call&#39;s callback is&#xA;executed in cifsd process.&#xA;Add an extra state to mark the mid state to READY before wakeup the&#xA;waitter, then it can get the resp safely.&#xA;CVE-2024-26810:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfio/pci: Lock external INTx masking ops&#xA;Mask operations through config space changes to DisINTx may race INTx&#xA;configuration changes via ioctl.  Create wrappers that add locking for&#xA;paths outside of the core interrupt code.&#xA;In particular, irq_type is updated holding igate, therefore testing&#xA;is_intx() requires holding igate.  For example clearing DisINTx from&#xA;config space can otherwise race changes of the interrupt configuration.&#xA;This aligns interfaces which may trigger the INTx eventfd into two&#xA;camps, one side serialized by igate and the other only enabled while&#xA;INTx is configured.  A subsequent patch introduces synchronization for&#xA;the latter flows.&#xA;CVE-2021-47101:In the Linux kernel, the following vulnerability has been resolved:&#xA;asix: fix uninit-value in asix_mdio_read()&#xA;asix_read_cmd() may read less than sizeof(smsr) bytes and in this case&#xA;smsr will be uninitialized.&#xA;Fail log:&#xA;BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]&#xA;BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497&#xA;BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497&#xA; asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]&#xA; asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497&#xA; asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497&#xA;CVE-2023-52587:In the Linux kernel, the following vulnerability has been resolved:&#xA;IB/ipoib: Fix mcast list locking&#xA;Releasing the `priv-&gt;lock` while iterating the `priv-&gt;multicast_list` in&#xA;`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to&#xA;remove the items while in the middle of iteration. If the mcast is removed&#xA;while the lock was dropped, the for loop spins forever resulting in a hard&#xA;lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):&#xA;    Task A (kworker/u72:2 below)       | Task B (kworker/u72:0 below)&#xA;    -----------------------------------+-----------------------------------&#xA;    ipoib_mcast_join_task(work)        | ipoib_ib_dev_flush_light(work)&#xA;      spin_lock_irq(&amp;priv-&gt;lock)       | __ipoib_ib_dev_flush(priv, ...)&#xA;      list_for_each_entry(mcast,       | ipoib_mcast_dev_flush(dev = priv-&gt;dev)&#xA;          &amp;priv-&gt;multicast_list, list) |&#xA;        ipoib_mcast_join(dev, mcast)   |&#xA;          spin_unlock_irq(&amp;priv-&gt;lock) |&#xA;                                       |   spin_lock_irqsave(&amp;priv-&gt;lock, flags)&#xA;                                       |   list_for_each_entry_safe(mcast, tmcast,&#xA;                                       |                  &amp;priv-&gt;multicast_list, list)&#xA;                                       |     list_del(&amp;mcast-&gt;list);&#xA;                                       |     list_add_tail(&amp;mcast-&gt;list, &amp;remove_list)&#xA;                                       |   spin_unlock_irqrestore(&amp;priv-&gt;lock, flags)&#xA;          spin_lock_irq(&amp;priv-&gt;lock)   |&#xA;                                       |   ipoib_mcast_remove_list(&amp;remove_list)&#xA;   (Here, `mcast` is no longer on the  |     list_for_each_entry_safe(mcast, tmcast,&#xA;    `priv-&gt;multicast_list` and we keep |                            remove_list, list)&#xA;    spinning on the `remove_list` of   |  &gt;&gt;&gt;  wait_for_completion(&amp;mcast-&gt;done)&#xA;    the other thread which is blocked  |&#xA;    and the list is still valid on     |&#xA;    it&#39;s stack.)&#xA;Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent&#xA;eventual sleeps.&#xA;Unfortunately we could not reproduce the lockup and confirm this fix but&#xA;based on the code review I think this fix should address such lockups.&#xA;crash&gt; bc 31&#xA;PID: 747      TASK: ff1c6a1a007e8000  CPU: 31   COMMAND: &#34;kworker/u72:2&#34;&#xA;--&#xA;    [exception RIP: ipoib_mcast_join_task+0x1b1]&#xA;    RIP: ffffffffc0944ac1  RSP: ff646f199a8c7e00  RFLAGS: 00000002&#xA;    RAX: 0000000000000000  RBX: ff1c6a1a04dc82f8  RCX: 0000000000000000&#xA;                                  work (&amp;priv-&gt;mcast_task{,.work})&#xA;    RDX: ff1c6a192d60ac68  RSI: 0000000000000286  RDI: ff1c6a1a04dc8000&#xA;           &amp;mcast-&gt;list&#xA;    RBP: ff646f199a8c7e90   R8: ff1c699980019420   R9: ff1c6a1920c9a000&#xA;    R10: ff646f199a8c7e00  R11: ff1c6a191a7d9800  R12: ff1c6a192d60ac00&#xA;                                                         mcast&#xA;    R13: ff1c6a1d82200000  R14: ff1c6a1a04dc8000  R15: ff1c6a1a04dc82d8&#xA;           dev                    priv (&amp;priv-&gt;lock)     &amp;priv-&gt;multicast_list (aka head)&#xA;    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018&#xA;--- &lt;NMI exception stack&gt; ---&#xA; #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]&#xA; #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967&#xA;crash&gt; rx ff646f199a8c7e68&#xA;ff646f199a8c7e68:  ff1c6a1a04dc82f8 &lt;&lt;&lt; work = &amp;priv-&gt;mcast_task.work&#xA;crash&gt; list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000&#xA;(empty)&#xA;crash&gt; ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000&#xA;  mcast_task.work.func = 0xffffffffc0944910 &lt;ipoib_mcast_join_task&gt;,&#xA;  mcast_mutex.owner.counter = 0xff1c69998efec000&#xA;crash&gt; b 8&#xA;PID: 8        TASK: ff1c69998efec000  CPU: 33   COMMAND: &#34;kworker/u72:0&#34;&#xA;--&#xA; #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646&#xA; #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]&#xA; #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]&#xA; #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]&#xA; #7 [ff&#xA;---truncated---&#xA;CVE-2024-27437:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfio/pci: Disable auto-enable of exclusive INTx IRQ&#xA;Currently for devices requiring masking at the irqchip for INTx, ie.&#xA;devices without DisINTx support, the IRQ is enabled in request_irq()&#xA;and subsequently disabled as necessary to align with the masked status&#xA;flag.  This presents a window where the interrupt could fire between&#xA;these events, resulting in the IRQ incrementing the disable depth twice.&#xA;This would be unrecoverable for a user since the masked flag prevents&#xA;nested enables through vfio.&#xA;Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx&#xA;is never auto-enabled, then unmask as required.&#xA;CVE-2024-26698:In the Linux kernel, the following vulnerability has been resolved:&#xA;hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove&#xA;In commit ac5047671758 (&#34;hv_netvsc: Disable NAPI before closing the&#xA;VMBus channel&#34;), napi_disable was getting called for all channels,&#xA;including all subchannels without confirming if they are enabled or not.&#xA;This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()&#xA;has finished running but nvdev-&gt;subchan_work has not started yet.&#xA;netvsc_subchan_work() -&gt; rndis_set_subchannel() has not created the&#xA;sub-channels and because of that netvsc_sc_open() is not running.&#xA;netvsc_remove() calls cancel_work_sync(&amp;nvdev-&gt;subchan_work), for which&#xA;netvsc_subchan_work did not run.&#xA;netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI&#xA;cannot be scheduled. Then netvsc_sc_open() -&gt; napi_enable will clear the&#xA;NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the&#xA;opposite.&#xA;Now during netvsc_device_remove(), when napi_disable is called for those&#xA;subchannels, napi_disable gets stuck on infinite msleep.&#xA;This fix addresses this problem by ensuring that napi_disable() is not&#xA;getting called for non-enabled NAPI struct.&#xA;But netif_napi_del() is still necessary for these non-enabled NAPI struct&#xA;for cleanup purpose.&#xA;Call trace:&#xA;[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002&#xA;[  654.568030] Call Trace:&#xA;[  654.571221]  &lt;TASK&gt;&#xA;[  654.573790]  __schedule+0x2d6/0x960&#xA;[  654.577733]  schedule+0x69/0xf0&#xA;[  654.581214]  schedule_timeout+0x87/0x140&#xA;[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20&#xA;[  654.590291]  msleep+0x2d/0x40&#xA;[  654.593625]  napi_disable+0x2b/0x80&#xA;[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]&#xA;[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]&#xA;[  654.611101]  ? do_wait_intr+0xb0/0xb0&#xA;[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]&#xA;[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]&#xA;CVE-2023-52560:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()&#xA;When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y&#xA;and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.&#xA;Since commit 9f86d624292c (&#34;mm/damon/vaddr-test: remove unnecessary&#xA;variables&#34;), the damon_destroy_ctx() is removed, but still call&#xA;damon_new_target() and damon_new_region(), the damon_region which is&#xA;allocated by kmem_cache_alloc() in damon_new_region() and the damon_target&#xA;which is allocated by kmalloc in damon_new_target() are not freed.  And&#xA;the damon_region which is allocated in damon_new_region() in&#xA;damon_set_regions() is also not freed.&#xA;So use damon_destroy_target to free all the damon_regions and damon_target.&#xA;    unreferenced object 0xffff888107c9a940 (size 64):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1069, jiffies 4294670592 (age 732.761s)&#xA;      hex dump (first 32 bytes):&#xA;        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk&#xA;        60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff  `...............&#xA;      backtrace:&#xA;        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0&#xA;        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0&#xA;        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0&#xA;        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20&#xA;    unreferenced object 0xffff8881079cc740 (size 56):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1069, jiffies 4294670592 (age 732.761s)&#xA;      hex dump (first 32 bytes):&#xA;        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................&#xA;        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk&#xA;      backtrace:&#xA;        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0&#xA;        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0&#xA;        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20&#xA;    unreferenced object 0xffff888107c9ac40 (size 64):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1071, jiffies 4294670595 (age 732.843s)&#xA;      hex dump (first 32 bytes):&#xA;        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk&#xA;        a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff  ........x.v.....&#xA;      backtrace:&#xA;        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0&#xA;        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0&#xA;        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0&#xA;        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20&#xA;    unreferenced object 0xffff8881079ccc80 (size 56):&#xA;      comm &#34;kunit_try_catch&#34;, pid 1071, jiffies 4294670595 (age 732.843s)&#xA;      hex dump (first 32 bytes):&#xA;        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................&#xA;        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk&#xA;      backtrace:&#xA;        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0&#xA;        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0&#xA;        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260&#xA;        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90&#xA;        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380&#xA;        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70&#xA;        [&lt;ffff&#xA;---truncated---&#xA;CVE-2023-52597:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: s390: fix setting of fpc register&#xA;kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control&#xA;(fpc) register of a guest cpu. The new value is tested for validity by&#xA;temporarily loading it into the fpc register.&#xA;This may lead to corruption of the fpc register of the host process:&#xA;if an interrupt happens while the value is temporarily loaded into the fpc&#xA;register, and within interrupt context floating point or vector registers&#xA;are used, the current fp/vx registers are saved with save_fpu_regs()&#xA;assuming they belong to user space and will be loaded into fp/vx registers&#xA;when returning to user space.&#xA;test_fp_ctl() restores the original user space / host process fpc register&#xA;value, however it will be discarded, when returning to user space.&#xA;In result the host process will incorrectly continue to run with the value&#xA;that was supposed to be used for a guest cpu.&#xA;Fix this by simply removing the test. There is another test right before&#xA;the SIE context is entered which will handles invalid values.&#xA;This results in a change of behaviour: invalid values will now be accepted&#xA;instead of that the ioctl fails with -EINVAL. This seems to be acceptable,&#xA;given that this interface is most likely not used anymore, and this is in&#xA;addition the same behaviour implemented with the memory mapped interface&#xA;(replace invalid values with zero) - see sync_regs() in kvm-s390.c.&#xA;CVE-2023-52578:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: bridge: use DEV_STATS_INC()&#xA;syzbot/KCSAN reported data-races in br_handle_frame_finish() [1]&#xA;This function can run from multiple cpus without mutual exclusion.&#xA;Adopt SMP safe DEV_STATS_INC() to update dev-&gt;stats fields.&#xA;Handles updates to dev-&gt;stats.tx_dropped while we are at it.&#xA;[1]&#xA;BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish&#xA;read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:&#xA;br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189&#xA;br_nf_hook_thresh+0x1ed/0x220&#xA;br_nf_pre_routing_finish_ipv6+0x50f/0x540&#xA;NF_HOOK include/linux/netfilter.h:304 [inline]&#xA;br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178&#xA;br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508&#xA;nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]&#xA;nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]&#xA;br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417&#xA;__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417&#xA;__netif_receive_skb_one_core net/core/dev.c:5521 [inline]&#xA;__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637&#xA;process_backlog+0x21f/0x380 net/core/dev.c:5965&#xA;__napi_poll+0x60/0x3b0 net/core/dev.c:6527&#xA;napi_poll net/core/dev.c:6594 [inline]&#xA;net_rx_action+0x32b/0x750 net/core/dev.c:6727&#xA;__do_softirq+0xc1/0x265 kernel/softirq.c:553&#xA;run_ksoftirqd+0x17/0x20 kernel/softirq.c:921&#xA;smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164&#xA;kthread+0x1d7/0x210 kernel/kthread.c:388&#xA;ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147&#xA;ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304&#xA;read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:&#xA;br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189&#xA;br_nf_hook_thresh+0x1ed/0x220&#xA;br_nf_pre_routing_finish_ipv6+0x50f/0x540&#xA;NF_HOOK include/linux/netfilter.h:304 [inline]&#xA;br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178&#xA;br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508&#xA;nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]&#xA;nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]&#xA;br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417&#xA;__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417&#xA;__netif_receive_skb_one_core net/core/dev.c:5521 [inline]&#xA;__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637&#xA;process_backlog+0x21f/0x380 net/core/dev.c:5965&#xA;__napi_poll+0x60/0x3b0 net/core/dev.c:6527&#xA;napi_poll net/core/dev.c:6594 [inline]&#xA;net_rx_action+0x32b/0x750 net/core/dev.c:6727&#xA;__do_softirq+0xc1/0x265 kernel/softirq.c:553&#xA;do_softirq+0x5e/0x90 kernel/softirq.c:454&#xA;__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381&#xA;__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]&#xA;_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210&#xA;spin_unlock_bh include/linux/spinlock.h:396 [inline]&#xA;batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356&#xA;batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560&#xA;process_one_work kernel/workqueue.c:2630 [inline]&#xA;process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703&#xA;worker_thread+0x525/0x730 kernel/workqueue.c:2784&#xA;kthread+0x1d7/0x210 kernel/kthread.c:388&#xA;ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147&#xA;ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304&#xA;value changed: 0x00000000000d7190 -&gt; 0x00000000000d7191&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0&#xA;CVE-2023-52574:In the Linux kernel, the following vulnerability has been resolved:&#xA;team: fix null-ptr-deref when team device type is changed&#xA;Get a null-ptr-deref bug as follows with reproducer [1].&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000228&#xA;...&#xA;RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die+0x24/0x70&#xA; ? page_fault_oops+0x82/0x150&#xA; ? exc_page_fault+0x69/0x150&#xA; ? asm_exc_page_fault+0x26/0x30&#xA; ? vlan_dev_hard_header+0x35/0x140 [8021q]&#xA; ? vlan_dev_hard_header+0x8e/0x140 [8021q]&#xA; neigh_connected_output+0xb2/0x100&#xA; ip6_finish_output2+0x1cb/0x520&#xA; ? nf_hook_slow+0x43/0xc0&#xA; ? ip6_mtu+0x46/0x80&#xA; ip6_finish_output+0x2a/0xb0&#xA; mld_sendpack+0x18f/0x250&#xA; mld_ifc_work+0x39/0x160&#xA; process_one_work+0x1e6/0x3f0&#xA; worker_thread+0x4d/0x2f0&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0xe5/0x120&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x34/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1b/0x30&#xA;[1]&#xA;$ teamd -t team0 -d -c &#39;{&#34;runner&#34;: {&#34;name&#34;: &#34;loadbalance&#34;}}&#39;&#xA;$ ip link add name t-dummy type dummy&#xA;$ ip link add link t-dummy name t-dummy.100 type vlan id 100&#xA;$ ip link add name t-nlmon type nlmon&#xA;$ ip link set t-nlmon master team0&#xA;$ ip link set t-nlmon nomaster&#xA;$ ip link set t-dummy up&#xA;$ ip link set team0 up&#xA;$ ip link set t-dummy.100 down&#xA;$ ip link set t-dummy.100 master team0&#xA;When enslave a vlan device to team device and team device type is changed&#xA;from non-ether to ether, header_ops of team device is changed to&#xA;vlan_header_ops. That is incorrect and will trigger null-ptr-deref&#xA;for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not&#xA;a vlan device.&#xA;Cache eth_header_ops in team_setup(), then assign cached header_ops to&#xA;header_ops of team net device when its type is changed from non-ether&#xA;to ether to fix the bug.&#xA;CVE-2023-52595:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: rt2x00: restart beacon queue when hardware reset&#xA;When a hardware reset is triggered, all registers are reset, so all&#xA;queues are forced to stop in hardware interface. However, mac80211&#xA;will not automatically stop the queue. If we don&#39;t manually stop the&#xA;beacon queue, the queue will be deadlocked and unable to start again.&#xA;This patch fixes the issue where Apple devices cannot connect to the&#xA;AP after calling ieee80211_restart_hw().&#xA;CVE-2024-26656:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: fix use-after-free bug&#xA;The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl&#xA;to the AMDGPU DRM driver on any ASICs with an invalid address and size.&#xA;The bug was reported by Joonkyo Jung &lt;joonkyoj@yonsei.ac.kr&gt;.&#xA;For example the following code:&#xA;static void Syzkaller1(int fd)&#xA;{&#xA;&#x9;struct drm_amdgpu_gem_userptr arg;&#xA;&#x9;int ret;&#xA;&#x9;arg.addr = 0xffffffffffff0000;&#xA;&#x9;arg.size = 0x80000000; /*2 Gb*/&#xA;&#x9;arg.flags = 0x7;&#xA;&#x9;ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg);&#xA;}&#xA;Due to the address and size are not valid there is a failure in&#xA;amdgpu_hmm_register-&gt;mmu_interval_notifier_insert-&gt;__mmu_interval_notifier_insert-&gt;&#xA;check_shl_overflow, but we even the amdgpu_hmm_register failure we still call&#xA;amdgpu_hmm_unregister into  amdgpu_gem_object_free which causes access to a bad address.&#xA;The following stack is below when the issue is reproduced when Kazan is enabled:&#xA;[  +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020&#xA;[  +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340&#xA;[  +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff &lt;0f&gt; 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80&#xA;[  +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246&#xA;[  +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b&#xA;[  +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260&#xA;[  +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25&#xA;[  +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00&#xA;[  +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260&#xA;[  +0.000011] FS:  00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000&#xA;[  +0.000012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0&#xA;[  +0.000010] Call Trace:&#xA;[  +0.000006]  &lt;TASK&gt;&#xA;[  +0.000007]  ? show_regs+0x6a/0x80&#xA;[  +0.000018]  ? __warn+0xa5/0x1b0&#xA;[  +0.000019]  ? mmu_interval_notifier_remove+0x327/0x340&#xA;[  +0.000018]  ? report_bug+0x24a/0x290&#xA;[  +0.000022]  ? handle_bug+0x46/0x90&#xA;[  +0.000015]  ? exc_invalid_op+0x19/0x50&#xA;[  +0.000016]  ? asm_exc_invalid_op+0x1b/0x20&#xA;[  +0.000017]  ? kasan_save_stack+0x26/0x50&#xA;[  +0.000017]  ? mmu_interval_notifier_remove+0x23b/0x340&#xA;[  +0.000019]  ? mmu_interval_notifier_remove+0x327/0x340&#xA;[  +0.000019]  ? mmu_interval_notifier_remove+0x23b/0x340&#xA;[  +0.000020]  ? __pfx_mmu_interval_notifier_remove+0x10/0x10&#xA;[  +0.000017]  ? kasan_save_alloc_info+0x1e/0x30&#xA;[  +0.000018]  ? srso_return_thunk+0x5/0x5f&#xA;[  +0.000014]  ? __kasan_kmalloc+0xb1/0xc0&#xA;[  +0.000018]  ? srso_return_thunk+0x5/0x5f&#xA;[  +0.000013]  ? __kasan_check_read+0x11/0x20&#xA;[  +0.000020]  amdgpu_hmm_unregister+0x34/0x50 [amdgpu]&#xA;[  +0.004695]  amdgpu_gem_object_free+0x66/0xa0 [amdgpu]&#xA;[  +0.004534]  ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]&#xA;[  +0.004291]  ? do_syscall_64+0x5f/0xe0&#xA;[  +0.000023]  ? srso_return_thunk+0x5/0x5f&#xA;[  +0.000017]  drm_gem_object_free+0x3b/0x50 [drm]&#xA;[  +0.000489]  amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]&#xA;[  +0.004295]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]&#xA;[  +0.004270]  ? srso_return_thunk+0x5/0x5f&#xA;[  +0.000014]  ? __this_cpu_preempt_check+0x13/0x20&#xA;[  +0.000015]  ? srso_return_thunk+0x5/0x5f&#xA;[  +0.000013]  ? sysvec_apic_timer_interrupt+0x57/0xc0&#xA;[  +0.000020]  ? srso_return_thunk+0x5/0x5f&#xA;[  +0.000014]  ? asm_sysvec_apic_timer_interrupt+0x1b/0x20&#xA;[  +0.000022]  ? drm_ioctl_kernel+0x17b/0x1f0 [drm]&#xA;[  +0.000496]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]&#xA;[  +0.004272]  ? drm_ioctl_kernel+0x190/0x1f0 [drm]&#xA;[  +0.000492]  drm_ioctl_kernel+0x140/0x1f0 [drm]&#xA;[  +0.000497]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]&#xA;[  +0.004297]  ? __pfx_drm_ioctl_kernel+0x10/0x10 [d&#xA;---truncated---&#xA;CVE-2023-52516:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma-debug: don&#39;t call __dma_entry_alloc_check_leak() under free_entries_lock&#xA;__dma_entry_alloc_check_leak() calls into printk -&gt; serial console&#xA;output (qcom geni) and grabs port-&gt;lock under free_entries_lock&#xA;spin lock, which is a reverse locking dependency chain as qcom_geni&#xA;IRQ handler can call into dma-debug code and grab free_entries_lock&#xA;under port-&gt;lock.&#xA;Move __dma_entry_alloc_check_leak() call out of free_entries_lock&#xA;scope so that we don&#39;t acquire serial console&#39;s port-&gt;lock under it.&#xA;Trimmed-down lockdep splat:&#xA; The existing dependency chain (in reverse order) is:&#xA;               -&gt; #2 (free_entries_lock){-.-.}-{2:2}:&#xA;        _raw_spin_lock_irqsave+0x60/0x80&#xA;        dma_entry_alloc+0x38/0x110&#xA;        debug_dma_map_page+0x60/0xf8&#xA;        dma_map_page_attrs+0x1e0/0x230&#xA;        dma_map_single_attrs.constprop.0+0x6c/0xc8&#xA;        geni_se_rx_dma_prep+0x40/0xcc&#xA;        qcom_geni_serial_isr+0x310/0x510&#xA;        __handle_irq_event_percpu+0x110/0x244&#xA;        handle_irq_event_percpu+0x20/0x54&#xA;        handle_irq_event+0x50/0x88&#xA;        handle_fasteoi_irq+0xa4/0xcc&#xA;        handle_irq_desc+0x28/0x40&#xA;        generic_handle_domain_irq+0x24/0x30&#xA;        gic_handle_irq+0xc4/0x148&#xA;        do_interrupt_handler+0xa4/0xb0&#xA;        el1_interrupt+0x34/0x64&#xA;        el1h_64_irq_handler+0x18/0x24&#xA;        el1h_64_irq+0x64/0x68&#xA;        arch_local_irq_enable+0x4/0x8&#xA;        ____do_softirq+0x18/0x24&#xA;        ...&#xA;               -&gt; #1 (&amp;port_lock_key){-.-.}-{2:2}:&#xA;        _raw_spin_lock_irqsave+0x60/0x80&#xA;        qcom_geni_serial_console_write+0x184/0x1dc&#xA;        console_flush_all+0x344/0x454&#xA;        console_unlock+0x94/0xf0&#xA;        vprintk_emit+0x238/0x24c&#xA;        vprintk_default+0x3c/0x48&#xA;        vprintk+0xb4/0xbc&#xA;        _printk+0x68/0x90&#xA;        register_console+0x230/0x38c&#xA;        uart_add_one_port+0x338/0x494&#xA;        qcom_geni_serial_probe+0x390/0x424&#xA;        platform_probe+0x70/0xc0&#xA;        really_probe+0x148/0x280&#xA;        __driver_probe_device+0xfc/0x114&#xA;        driver_probe_device+0x44/0x100&#xA;        __device_attach_driver+0x64/0xdc&#xA;        bus_for_each_drv+0xb0/0xd8&#xA;        __device_attach+0xe4/0x140&#xA;        device_initial_probe+0x1c/0x28&#xA;        bus_probe_device+0x44/0xb0&#xA;        device_add+0x538/0x668&#xA;        of_device_add+0x44/0x50&#xA;        of_platform_device_create_pdata+0x94/0xc8&#xA;        of_platform_bus_create+0x270/0x304&#xA;        of_platform_populate+0xac/0xc4&#xA;        devm_of_platform_populate+0x60/0xac&#xA;        geni_se_probe+0x154/0x160&#xA;        platform_probe+0x70/0xc0&#xA;        ...&#xA;               -&gt; #0 (console_owner){-...}-{0:0}:&#xA;        __lock_acquire+0xdf8/0x109c&#xA;        lock_acquire+0x234/0x284&#xA;        console_flush_all+0x330/0x454&#xA;        console_unlock+0x94/0xf0&#xA;        vprintk_emit+0x238/0x24c&#xA;        vprintk_default+0x3c/0x48&#xA;        vprintk+0xb4/0xbc&#xA;        _printk+0x68/0x90&#xA;        dma_entry_alloc+0xb4/0x110&#xA;        debug_dma_map_sg+0xdc/0x2f8&#xA;        __dma_map_sg_attrs+0xac/0xe4&#xA;        dma_map_sgtable+0x30/0x4c&#xA;        get_pages+0x1d4/0x1e4 [msm]&#xA;        msm_gem_pin_pages_locked+0x38/0xac [msm]&#xA;        msm_gem_pin_vma_locked+0x58/0x88 [msm]&#xA;        msm_ioctl_gem_submit+0xde4/0x13ac [msm]&#xA;        drm_ioctl_kernel+0xe0/0x15c&#xA;        drm_ioctl+0x2e8/0x3f4&#xA;        vfs_ioctl+0x30/0x50&#xA;        ...&#xA; Chain exists of:&#xA;   console_owner --&gt; &amp;port_lock_key --&gt; free_entries_lock&#xA;  Possible unsafe locking scenario:&#xA;        CPU0                    CPU1&#xA;        ----                    ----&#xA;   lock(free_entries_lock);&#xA;                                lock(&amp;port_lock_key);&#xA;                                lock(free_entries_lock);&#xA;   lock(console_owner);&#xA;                *** DEADLOCK ***&#xA; Call trace:&#xA;  dump_backtrace+0xb4/0xf0&#xA;  show_stack+0x20/0x30&#xA;  dump_stack_lvl+0x60/0x84&#xA;  dump_stack+0x18/0x24&#xA;  print_circular_bug+0x1cc/0x234&#xA;  check_noncircular+0x78/0xac&#xA;  __lock_acquire+0xdf8/0x109c&#xA;  lock_acquire+0x234/0x284&#xA;  console_flush_all+0x330/0x454&#xA;  consol&#xA;---truncated---&#xA;CVE-2023-52464:In the Linux kernel, the following vulnerability has been resolved:&#xA;EDAC/thunderx: Fix possible out-of-bounds string access&#xA;Enabling -Wstringop-overflow globally exposes a warning for a common bug&#xA;in the usage of strncat():&#xA;  drivers/edac/thunderx_edac.c: In function &#39;thunderx_ocx_com_threaded_isr&#39;:&#xA;  drivers/edac/thunderx_edac.c:1136:17: error: &#39;strncat&#39; specified bound 1024 equals destination size [-Werror=stringop-overflow=]&#xA;   1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);&#xA;        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~&#xA;   ...&#xA;   1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);&#xA;   ...&#xA;   1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);&#xA;   ...&#xA;Apparently the author of this driver expected strncat() to behave the&#xA;way that strlcat() does, which uses the size of the destination buffer&#xA;as its third argument rather than the length of the source buffer. The&#xA;result is that there is no check on the size of the allocated buffer.&#xA;Change it to strlcat().&#xA;  [ bp: Trim compiler output, fixup commit message. ]&#xA;CVE-2024-26759:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/swap: fix race when skipping swapcache&#xA;When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads&#xA;swapin the same entry at the same time, they get different pages (A, B). &#xA;Before one thread (T0) finishes the swapin and installs page (A) to the&#xA;PTE, another thread (T1) could finish swapin of page (B), swap_free the&#xA;entry, then swap out the possibly modified page reusing the same entry. &#xA;It breaks the pte_same check in (T0) because PTE value is unchanged,&#xA;causing ABA problem.  Thread (T0) will install a stalled page (A) into the&#xA;PTE and cause data corruption.&#xA;One possible callstack is like this:&#xA;CPU0                                 CPU1&#xA;----                                 ----&#xA;do_swap_page()                       do_swap_page() with same entry&#xA;&lt;direct swapin path&gt;                 &lt;direct swapin path&gt;&#xA;&lt;alloc page A&gt;                       &lt;alloc page B&gt;&#xA;swap_read_folio() &lt;- read to page A  swap_read_folio() &lt;- read to page B&#xA;&lt;slow on later locks or interrupt&gt;   &lt;finished swapin first&gt;&#xA;...                                  set_pte_at()&#xA;                                     swap_free() &lt;- entry is free&#xA;                                     &lt;write to page B, now page A stalled&gt;&#xA;                                     &lt;swap out page B to same swap entry&gt;&#xA;pte_same() &lt;- Check pass, PTE seems&#xA;              unchanged, but page A&#xA;              is stalled!&#xA;swap_free() &lt;- page B content lost!&#xA;set_pte_at() &lt;- staled page A installed!&#xA;And besides, for ZRAM, swap_free() allows the swap device to discard the&#xA;entry content, so even if page (B) is not modified, if swap_read_folio()&#xA;on CPU0 happens later than swap_free() on CPU1, it may also cause data&#xA;loss.&#xA;To fix this, reuse swapcache_prepare which will pin the swap entry using&#xA;the cache flag, and allow only one thread to swap it in, also prevent any&#xA;parallel code from putting the entry in the cache.  Release the pin after&#xA;PT unlocked.&#xA;Racers just loop and wait since it&#39;s a rare and very short event.  A&#xA;schedule_timeout_uninterruptible(1) call is added to avoid repeated page&#xA;faults wasting too much CPU, causing livelock or adding too much noise to&#xA;perf statistics.  A similar livelock issue was described in commit&#xA;029c4628b2eb (&#34;mm: swap: get rid of livelock in swapin readahead&#34;)&#xA;Reproducer:&#xA;This race issue can be triggered easily using a well constructed&#xA;reproducer and patched brd (with a delay in read path) [1]:&#xA;With latest 6.8 mainline, race caused data loss can be observed easily:&#xA;$ gcc -g -lpthread test-thread-swap-race.c &amp;&amp; ./a.out&#xA;  Polulating 32MB of memory region...&#xA;  Keep swapping out...&#xA;  Starting round 0...&#xA;  Spawning 65536 workers...&#xA;  32746 workers spawned, wait for done...&#xA;  Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!&#xA;  Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!&#xA;  Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!&#xA;  Round 0 Failed, 15 data loss!&#xA;This reproducer spawns multiple threads sharing the same memory region&#xA;using a small swap device.  Every two threads updates mapped pages one by&#xA;one in opposite direction trying to create a race, with one dedicated&#xA;thread keep swapping out the data out using madvise.&#xA;The reproducer created a reproduce rate of about once every 5 minutes, so&#xA;the race should be totally possible in production.&#xA;After this patch, I ran the reproducer for over a few hundred rounds and&#xA;no data loss observed.&#xA;Performance overhead is minimal, microbenchmark swapin 10G from 32G&#xA;zram:&#xA;Before:     10934698 us&#xA;After:      11157121 us&#xA;Cached:     13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)&#xA;[kasong@tencent.com: v4]&#xA;  Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com&#xA;CVE-2024-26751:In the Linux kernel, the following vulnerability has been resolved:&#xA;ARM: ep93xx: Add terminator to gpiod_lookup_table&#xA;Without the terminator, if a con_id is passed to gpio_find() that&#xA;does not exist in the lookup table the function will not stop looping&#xA;correctly, and eventually cause an oops.&#xA;CVE-2024-26778:In the Linux kernel, the following vulnerability has been resolved:&#xA;fbdev: savage: Error out if pixclock equals zero&#xA;The userspace program could pass any values to the driver through&#xA;ioctl() interface. If the driver doesn&#39;t check the value of pixclock,&#xA;it may cause divide-by-zero error.&#xA;Although pixclock is checked in savagefb_decode_var(), but it is not&#xA;checked properly in savagefb_probe(). Fix this by checking whether&#xA;pixclock is zero in the function savagefb_check_var() before&#xA;info-&gt;var.pixclock is used as the divisor.&#xA;This is similar to CVE-2022-3061 in i740fb which was fixed by&#xA;commit 15cf0b8.&#xA;CVE-2024-26772:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()&#xA;Places the logic for checking if the group&#39;s block bitmap is corrupt under&#xA;the protection of the group lock to avoid allocating blocks from the group&#xA;with a corrupted block bitmap.&#xA;CVE-2023-52640:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Fix oob in ntfs_listxattr&#xA;The length of name cannot exceed the space occupied by ea.&#xA;CVE-2024-26695:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked&#xA;The SEV platform device can be shutdown with a null psp_master,&#xA;e.g., using DEBUG_TEST_DRIVER_REMOVE.  Found using KASAN:&#xA;[  137.148210] ccp 0000:23:00.1: enabling device (0000 -&gt; 0002)&#xA;[  137.162647] ccp 0000:23:00.1: no command queues available&#xA;[  137.170598] ccp 0000:23:00.1: sev enabled&#xA;[  137.174645] ccp 0000:23:00.1: psp enabled&#xA;[  137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI&#xA;[  137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]&#xA;[  137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311&#xA;[  137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180&#xA;[  137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 &lt;80&gt; 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c&#xA;[  137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216&#xA;[  137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e&#xA;[  137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0&#xA;[  137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66&#xA;[  137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28&#xA;[  137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8&#xA;[  137.182693] FS:  0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000&#xA;[  137.182693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0&#xA;[  137.182693] Call Trace:&#xA;[  137.182693]  &lt;TASK&gt;&#xA;[  137.182693]  ? show_regs+0x6c/0x80&#xA;[  137.182693]  ? __die_body+0x24/0x70&#xA;[  137.182693]  ? die_addr+0x4b/0x80&#xA;[  137.182693]  ? exc_general_protection+0x126/0x230&#xA;[  137.182693]  ? asm_exc_general_protection+0x2b/0x30&#xA;[  137.182693]  ? __sev_platform_shutdown_locked+0x51/0x180&#xA;[  137.182693]  sev_firmware_shutdown.isra.0+0x1e/0x80&#xA;[  137.182693]  sev_dev_destroy+0x49/0x100&#xA;[  137.182693]  psp_dev_destroy+0x47/0xb0&#xA;[  137.182693]  sp_destroy+0xbb/0x240&#xA;[  137.182693]  sp_pci_remove+0x45/0x60&#xA;[  137.182693]  pci_device_remove+0xaa/0x1d0&#xA;[  137.182693]  device_remove+0xc7/0x170&#xA;[  137.182693]  really_probe+0x374/0xbe0&#xA;[  137.182693]  ? srso_return_thunk+0x5/0x5f&#xA;[  137.182693]  __driver_probe_device+0x199/0x460&#xA;[  137.182693]  driver_probe_device+0x4e/0xd0&#xA;[  137.182693]  __driver_attach+0x191/0x3d0&#xA;[  137.182693]  ? __pfx___driver_attach+0x10/0x10&#xA;[  137.182693]  bus_for_each_dev+0x100/0x190&#xA;[  137.182693]  ? __pfx_bus_for_each_dev+0x10/0x10&#xA;[  137.182693]  ? __kasan_check_read+0x15/0x20&#xA;[  137.182693]  ? srso_return_thunk+0x5/0x5f&#xA;[  137.182693]  ? _raw_spin_unlock+0x27/0x50&#xA;[  137.182693]  driver_attach+0x41/0x60&#xA;[  137.182693]  bus_add_driver+0x2a8/0x580&#xA;[  137.182693]  driver_register+0x141/0x480&#xA;[  137.182693]  __pci_register_driver+0x1d6/0x2a0&#xA;[  137.182693]  ? srso_return_thunk+0x5/0x5f&#xA;[  137.182693]  ? esrt_sysfs_init+0x1cd/0x5d0&#xA;[  137.182693]  ? __pfx_sp_mod_init+0x10/0x10&#xA;[  137.182693]  sp_pci_init+0x22/0x30&#xA;[  137.182693]  sp_mod_init+0x14/0x30&#xA;[  137.182693]  ? __pfx_sp_mod_init+0x10/0x10&#xA;[  137.182693]  do_one_initcall+0xd1/0x470&#xA;[  137.182693]  ? __pfx_do_one_initcall+0x10/0x10&#xA;[  137.182693]  ? parameq+0x80/0xf0&#xA;[  137.182693]  ? srso_return_thunk+0x5/0x5f&#xA;[  137.182693]  ? __kmalloc+0x3b0/0x4e0&#xA;[  137.182693]  ? kernel_init_freeable+0x92d/0x1050&#xA;[  137.182693]  ? kasan_populate_vmalloc_pte+0x171/0x190&#xA;[  137.182693]  ? srso_return_thunk+0x5/0x5f&#xA;[  137.182693]  kernel_init_freeable+0xa64/0x1050&#xA;[  137.182693]  ? __pfx_kernel_init+0x10/0x10&#xA;[  137.182693]  kernel_init+0x24/0x160&#xA;[  137.182693]  ? __switch_to_asm+0x3e/0x70&#xA;[  137.182693]  ret_from_fork+0x40/0x80&#xA;[  137.182693]  ? __pfx_kernel_init+0x1&#xA;---truncated---&#xA;CVE-2024-26736:In the Linux kernel, the following vulnerability has been resolved:&#xA;afs: Increase buffer size in afs_update_volume_status()&#xA;The max length of volume-&gt;vid value is 20 characters.&#xA;So increase idbuf[] size up to 24 to avoid overflow.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;[DH: Actually, it&#39;s 20 + NUL, so increase it to 24 and use snprintf()]&#xA;CVE-2024-26777:In the Linux kernel, the following vulnerability has been resolved:&#xA;fbdev: sis: Error out if pixclock equals zero&#xA;The userspace program could pass any values to the driver through&#xA;ioctl() interface. If the driver doesn&#39;t check the value of pixclock,&#xA;it may cause divide-by-zero error.&#xA;In sisfb_check_var(), var-&gt;pixclock is used as a divisor to caculate&#xA;drate before it is checked against zero. Fix this by checking it&#xA;at the beginning.&#xA;This is similar to CVE-2022-3061 in i740fb which was fixed by&#xA;commit 15cf0b8.&#xA;CVE-2023-52598:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/ptrace: handle setting of fpc register correctly&#xA;If the content of the floating point control (fpc) register of a traced&#xA;process is modified with the ptrace interface the new value is tested for&#xA;validity by temporarily loading it into the fpc register.&#xA;This may lead to corruption of the fpc register of the tracing process:&#xA;if an interrupt happens while the value is temporarily loaded into the&#xA;fpc register, and within interrupt context floating point or vector&#xA;registers are used, the current fp/vx registers are saved with&#xA;save_fpu_regs() assuming they belong to user space and will be loaded into&#xA;fp/vx registers when returning to user space.&#xA;test_fp_ctl() restores the original user space fpc register value, however&#xA;it will be discarded, when returning to user space.&#xA;In result the tracer will incorrectly continue to run with the value that&#xA;was supposed to be used for the traced process.&#xA;Fix this by saving fpu register contents with save_fpu_regs() before using&#xA;test_fp_ctl().&#xA;CVE-2024-26771:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: ti: edma: Add some null pointer checks to the edma_probe&#xA;devm_kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure. Ensure the allocation was successful&#xA;by checking the pointer validity.&#xA;CVE-2023-52503:In the Linux kernel, the following vulnerability has been resolved:&#xA;tee: amdtee: fix use-after-free vulnerability in amdtee_close_session&#xA;There is a potential race condition in amdtee_close_session that may&#xA;cause use-after-free in amdtee_open_session. For instance, if a session&#xA;has refcount == 1, and one thread tries to free this session via:&#xA;    kref_put(&amp;sess-&gt;refcount, destroy_session);&#xA;the reference count will get decremented, and the next step would be to&#xA;call destroy_session(). However, if in another thread,&#xA;amdtee_open_session() is called before destroy_session() has completed&#xA;execution, alloc_session() may return &#39;sess&#39; that will be freed up&#xA;later in destroy_session() leading to use-after-free in&#xA;amdtee_open_session.&#xA;To fix this issue, treat decrement of sess-&gt;refcount and removal of&#xA;&#39;sess&#39; from session list in destroy_session() as a critical section, so&#xA;that it is executed atomically.&#xA;CVE-2023-52493:In the Linux kernel, the following vulnerability has been resolved:&#xA;bus: mhi: host: Drop chan lock before queuing buffers&#xA;Ensure read and write locks for the channel are not taken in succession by&#xA;dropping the read lock from parse_xfer_event() such that a callback given&#xA;to client can potentially queue buffers and acquire the write lock in that&#xA;process. Any queueing of buffers should be done without channel read lock&#xA;acquired as it can result in multiple locks and a soft lockup.&#xA;[mani: added fixes tag and cc&#39;ed stable]&#xA;CVE-2024-26795:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: Sparse-Memory/vmemmap out-of-bounds fix&#xA;Offset vmemmap so that the first page of vmemmap will be mapped&#xA;to the first page of physical memory in order to ensure that&#xA;vmemmap’s bounds will be respected during&#xA;pfn_to_page()/page_to_pfn() operations.&#xA;The conversion macros will produce correct SV39/48/57 addresses&#xA;for every possible/valid DRAM_BASE inside the physical memory limits.&#xA;v2:Address Alex&#39;s comments&#xA;CVE-2023-52607:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/mm: Fix null-pointer dereference in pgtable_cache_add&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure. Ensure the allocation was successful&#xA;by checking the pointer validity.&#xA;CVE-2024-26615:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/smc: fix illegal rmb_desc access in SMC-D connection dump&#xA;A crash was found when dumping SMC-D connections. It can be reproduced&#xA;by following steps:&#xA;- run nginx/wrk test:&#xA;  smc_run nginx&#xA;  smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H &#39;Connection: Close&#39; &lt;URL&gt;&#xA;- continuously dump SMC-D connections in parallel:&#xA;  watch -n 1 &#39;smcss -D&#39;&#xA; BUG: kernel NULL pointer dereference, address: 0000000000000030&#xA; CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G&#x9;E      6.7.0+ #55&#xA; RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? __die+0x24/0x70&#xA;  ? page_fault_oops+0x66/0x150&#xA;  ? exc_page_fault+0x69/0x140&#xA;  ? asm_exc_page_fault+0x26/0x30&#xA;  ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]&#xA;  ? __kmalloc_node_track_caller+0x35d/0x430&#xA;  ? __alloc_skb+0x77/0x170&#xA;  smc_diag_dump_proto+0xd0/0xf0 [smc_diag]&#xA;  smc_diag_dump+0x26/0x60 [smc_diag]&#xA;  netlink_dump+0x19f/0x320&#xA;  __netlink_dump_start+0x1dc/0x300&#xA;  smc_diag_handler_dump+0x6a/0x80 [smc_diag]&#xA;  ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]&#xA;  sock_diag_rcv_msg+0x121/0x140&#xA;  ? __pfx_sock_diag_rcv_msg+0x10/0x10&#xA;  netlink_rcv_skb+0x5a/0x110&#xA;  sock_diag_rcv+0x28/0x40&#xA;  netlink_unicast+0x22a/0x330&#xA;  netlink_sendmsg+0x1f8/0x420&#xA;  __sock_sendmsg+0xb0/0xc0&#xA;  ____sys_sendmsg+0x24e/0x300&#xA;  ? copy_msghdr_from_user+0x62/0x80&#xA;  ___sys_sendmsg+0x7c/0xd0&#xA;  ? __do_fault+0x34/0x160&#xA;  ? do_read_fault+0x5f/0x100&#xA;  ? do_fault+0xb0/0x110&#xA;  ? __handle_mm_fault+0x2b0/0x6c0&#xA;  __sys_sendmsg+0x4d/0x80&#xA;  do_syscall_64+0x69/0x180&#xA;  entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;It is possible that the connection is in process of being established&#xA;when we dump it. Assumed that the connection has been registered in a&#xA;link group by smc_conn_create() but the rmb_desc has not yet been&#xA;initialized by smc_buf_create(), thus causing the illegal access to&#xA;conn-&gt;rmb_desc. So fix it by checking before dump.&#xA;CVE-2023-52491:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run&#xA;In mtk_jpeg_probe, &amp;jpeg-&gt;job_timeout_work is bound with&#xA;mtk_jpeg_job_timeout_work.&#xA;In mtk_jpeg_dec_device_run, if error happens in&#xA;mtk_jpeg_set_dec_dst, it will finally start the worker while&#xA;mark the job as finished by invoking v4l2_m2m_job_finish.&#xA;There are two methods to trigger the bug. If we remove the&#xA;module, it which will call mtk_jpeg_remove to make cleanup.&#xA;The possible sequence is as follows, which will cause a&#xA;use-after-free bug.&#xA;CPU0                  CPU1&#xA;mtk_jpeg_dec_...    |&#xA;  start worker&#x9;    |&#xA;                    |mtk_jpeg_job_timeout_work&#xA;mtk_jpeg_remove     |&#xA;  v4l2_m2m_release  |&#xA;    kfree(m2m_dev); |&#xA;                    |&#xA;                    | v4l2_m2m_get_curr_priv&#xA;                    |   m2m_dev-&gt;curr_ctx //use&#xA;If we close the file descriptor, which will call mtk_jpeg_release,&#xA;it will have a similar sequence.&#xA;Fix this bug by starting timeout worker only if started jpegdec worker&#xA;successfully. Then v4l2_m2m_job_finish will only be called in&#xA;either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.&#xA;CVE-2023-7042:A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.&#xA;CVE-2023-52617:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: switchtec: Fix stdev_release() crash after surprise hot remove&#xA;A PCI device hot removal may occur while stdev-&gt;cdev is held open. The call&#xA;to stdev_release() then happens during close or exit, at a point way past&#xA;switchtec_pci_remove(). Otherwise the last ref would vanish with the&#xA;trailing put_device(), just before return.&#xA;At that later point in time, the devm cleanup has already removed the&#xA;stdev-&gt;mmio_mrpc mapping. Also, the stdev-&gt;pdev reference was not a counted&#xA;one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause&#xA;a fatal page fault, and the subsequent dma_free_coherent(), if reached,&#xA;would pass a stale &amp;stdev-&gt;pdev-&gt;dev pointer.&#xA;Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after&#xA;stdev_kill(). Counting the stdev-&gt;pdev ref is now optional, but may prevent&#xA;future accidents.&#xA;Reproducible via the script at&#xA;https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com&#xA;CVE-2023-52608:In the Linux kernel, the following vulnerability has been resolved:&#xA;firmware: arm_scmi: Check mailbox/SMT channel for consistency&#xA;On reception of a completion interrupt the shared memory area is accessed&#xA;to retrieve the message header at first and then, if the message sequence&#xA;number identifies a transaction which is still pending, the related&#xA;payload is fetched too.&#xA;When an SCMI command times out the channel ownership remains with the&#xA;platform until eventually a late reply is received and, as a consequence,&#xA;any further transmission attempt remains pending, waiting for the channel&#xA;to be relinquished by the platform.&#xA;Once that late reply is received the channel ownership is given back&#xA;to the agent and any pending request is then allowed to proceed and&#xA;overwrite the SMT area of the just delivered late reply; then the wait&#xA;for the reply to the new request starts.&#xA;It has been observed that the spurious IRQ related to the late reply can&#xA;be wrongly associated with the freshly enqueued request: when that happens&#xA;the SCMI stack in-flight lookup procedure is fooled by the fact that the&#xA;message header now present in the SMT area is related to the new pending&#xA;transaction, even though the real reply has still to arrive.&#xA;This race-condition on the A2P channel can be detected by looking at the&#xA;channel status bits: a genuine reply from the platform will have set the&#xA;channel free bit before triggering the completion IRQ.&#xA;Add a consistency check to validate such condition in the A2P ISR.&#xA;CVE-2023-52498:In the Linux kernel, the following vulnerability has been resolved:&#xA;PM: sleep: Fix possible deadlocks in core system-wide PM code&#xA;It is reported that in low-memory situations the system-wide resume core&#xA;code deadlocks, because async_schedule_dev() executes its argument&#xA;function synchronously if it cannot allocate memory (and not only in&#xA;that case) and that function attempts to acquire a mutex that is already&#xA;held.  Executing the argument function synchronously from within&#xA;dpm_async_fn() may also be problematic for ordering reasons (it may&#xA;cause a consumer device&#39;s resume callback to be invoked before a&#xA;requisite supplier device&#39;s one, for example).&#xA;Address this by changing the code in question to use&#xA;async_schedule_dev_nocall() for scheduling the asynchronous&#xA;execution of device suspend and resume functions and to directly&#xA;run them synchronously if async_schedule_dev_nocall() returns false.&#xA;CVE-2021-47182:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: core: Fix scsi_mode_sense() buffer length handling&#xA;Several problems exist with scsi_mode_sense() buffer length handling:&#xA; 1) The allocation length field of the MODE SENSE(10) command is 16-bits,&#xA;    occupying bytes 7 and 8 of the CDB. With this command, access to mode&#xA;    pages larger than 255 bytes is thus possible. However, the CDB&#xA;    allocation length field is set by assigning len to byte 8 only, thus&#xA;    truncating buffer length larger than 255.&#xA; 2) If scsi_mode_sense() is called with len smaller than 8 with&#xA;    sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length&#xA;    is increased to 8 and 4 respectively, and the buffer is zero filled&#xA;    with these increased values, thus corrupting the memory following the&#xA;    buffer.&#xA;Fix these 2 problems by using put_unaligned_be16() to set the allocation&#xA;length field of MODE SENSE(10) CDB and by returning an error when len is&#xA;too small.&#xA;Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,&#xA;even if the device driver did not set sdev-&gt;use_10_for_ms. In case of&#xA;invalid opcode error for MODE SENSE(10), access to mode pages larger than&#xA;255 bytes are not retried using MODE SENSE(6). To avoid buffer length&#xA;overflows for the MODE_SENSE(10) case, check that len is smaller than 65535&#xA;bytes.&#xA;While at it, also fix the folowing:&#xA; * Use get_unaligned_be16() to retrieve the mode data length and block&#xA;   descriptor length fields of the mode sense reply header instead of using&#xA;   an open coded calculation.&#xA; * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable&#xA;   Block Descriptor, which is the opposite of what the dbd argument&#xA;   description was.&#xA;CVE-2024-24861:A race condition was found in the Linux kernel&#39;s media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.&#xA;CVE-2023-52492:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: fix NULL pointer in channel unregistration function&#xA;__dma_async_device_channel_register() can fail. In case of failure,&#xA;chan-&gt;local is freed (with free_percpu()), and chan-&gt;local is nullified.&#xA;When dma_async_device_unregister() is called (because of managed API or&#xA;intentionally by DMA controller driver), channels are unconditionally&#xA;unregistered, leading to this NULL pointer:&#xA;[    1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0&#xA;[...]&#xA;[    1.484499] Call trace:&#xA;[    1.486930]  device_del+0x40/0x394&#xA;[    1.490314]  device_unregister+0x20/0x7c&#xA;[    1.494220]  __dma_async_device_channel_unregister+0x68/0xc0&#xA;Look at dma_async_device_register() function error path, channel device&#xA;unregistration is done only if chan-&gt;local is not NULL.&#xA;Then add the same condition at the beginning of&#xA;__dma_async_device_channel_unregister() function, to avoid NULL pointer&#xA;issue whatever the API used to reach this function.&#xA;CVE-2024-26764:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio&#xA;If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the&#xA;following kernel warning appears:&#xA;WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8&#xA;Call trace:&#xA; kiocb_set_cancel_fn+0x9c/0xa8&#xA; ffs_epfile_read_iter+0x144/0x1d0&#xA; io_read+0x19c/0x498&#xA; io_issue_sqe+0x118/0x27c&#xA; io_submit_sqes+0x25c/0x5fc&#xA; __arm64_sys_io_uring_enter+0x104/0xab0&#xA; invoke_syscall+0x58/0x11c&#xA; el0_svc_common+0xb4/0xf4&#xA; do_el0_svc+0x2c/0xb0&#xA; el0_svc+0x2c/0xa4&#xA; el0t_64_sync_handler+0x68/0xb4&#xA; el0t_64_sync+0x1a4/0x1a8&#xA;Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is&#xA;submitted by libaio.&#xA;CVE-2023-52441:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: fix out of bounds in init_smb2_rsp_hdr()&#xA;If client send smb2 negotiate request and then send smb1 negotiate&#xA;request, init_smb2_rsp_hdr is called for smb1 negotiate request since&#xA;need_neg is set to false. This patch ignore smb1 packets after -&gt;need_neg&#xA;is set to false.&#xA;CVE-2023-6270:A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.&#xA;CVE-2024-26885:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix DEVMAP_HASH overflow check on 32-bit arches&#xA;The devmap code allocates a number hash buckets equal to the next power&#xA;of two of the max_entries value provided when creating the map. When&#xA;rounding up to the next power of two, the 32-bit variable storing the&#xA;number of buckets can overflow, and the code checks for overflow by&#xA;checking if the truncated 32-bit value is equal to 0. However, on 32-bit&#xA;arches the rounding up itself can overflow mid-way through, because it&#xA;ends up doing a left-shift of 32 bits on an unsigned long value. If the&#xA;size of an unsigned long is four bytes, this is undefined behaviour, so&#xA;there is no guarantee that we&#39;ll end up with a nice and tidy 0-value at&#xA;the end.&#xA;Syzbot managed to turn this into a crash on arm32 by creating a&#xA;DEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.&#xA;Fix this by moving the overflow check to before the rounding up&#xA;operation.&#xA;CVE-2024-26884:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix hashtab overflow check on 32-bit arches&#xA;The hashtab code relies on roundup_pow_of_two() to compute the number of&#xA;hash buckets, and contains an overflow check by checking if the&#xA;resulting value is 0. However, on 32-bit arches, the roundup code itself&#xA;can overflow by doing a 32-bit left-shift of an unsigned long value,&#xA;which is undefined behaviour, so it is not guaranteed to truncate&#xA;neatly. This was triggered by syzbot on the DEVMAP_HASH type, which&#xA;contains the same check, copied from the hashtab code. So apply the same&#xA;fix to hashtab, by moving the overflow check to before the roundup.&#xA;CVE-2024-26883:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix stackmap overflow check on 32-bit arches&#xA;The stackmap code relies on roundup_pow_of_two() to compute the number&#xA;of hash buckets, and contains an overflow check by checking if the&#xA;resulting value is 0. However, on 32-bit arches, the roundup code itself&#xA;can overflow by doing a 32-bit left-shift of an unsigned long value,&#xA;which is undefined behaviour, so it is not guaranteed to truncate&#xA;neatly. This was triggered by syzbot on the DEVMAP_HASH type, which&#xA;contains the same check, copied from the hashtab code.&#xA;The commit in the fixes tag actually attempted to fix this, but the fix&#xA;did not account for the UB, so the fix only works on CPUs where an&#xA;overflow does result in a neat truncation to zero, which is not&#xA;guaranteed. Checking the value before rounding does not have this&#xA;problem.&#xA;CVE-2024-26882:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()&#xA;Apply the same fix than ones found in :&#xA;8d975c15c0cd (&#34;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()&#34;)&#xA;1ca1ba465e55 (&#34;geneve: make sure to pull inner header in geneve_rx()&#34;)&#xA;We have to save skb-&gt;network_header in a temporary variable&#xA;in order to be able to recompute the network_header pointer&#xA;after a pskb_inet_may_pull() call.&#xA;pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.&#xA;syzbot reported:&#xA;BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]&#xA; BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]&#xA; BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]&#xA; BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409&#xA;  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]&#xA;  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]&#xA;  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]&#xA;  ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409&#xA;  __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389&#xA;  ipgre_rcv net/ipv4/ip_gre.c:411 [inline]&#xA;  gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447&#xA;  gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163&#xA;  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205&#xA;  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254&#xA;  dst_input include/net/dst.h:461 [inline]&#xA;  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569&#xA;  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]&#xA;  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648&#xA;  netif_receive_skb_internal net/core/dev.c:5734 [inline]&#xA;  netif_receive_skb+0x58/0x660 net/core/dev.c:5793&#xA;  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556&#xA;  tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009&#xA;  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055&#xA;  call_write_iter include/linux/fs.h:2087 [inline]&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0xb6b/0x1520 fs/read_write.c:590&#xA;  ksys_write+0x20f/0x4c0 fs/read_write.c:643&#xA;  __do_sys_write fs/read_write.c:655 [inline]&#xA;  __se_sys_write fs/read_write.c:652 [inline]&#xA;  __x64_sys_write+0x93/0xd0 fs/read_write.c:652&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA;  __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590&#xA;  alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133&#xA;  alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204&#xA;  skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909&#xA;  tun_build_skb drivers/net/tun.c:1686 [inline]&#xA;  tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826&#xA;  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055&#xA;  call_write_iter include/linux/fs.h:2087 [inline]&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0xb6b/0x1520 fs/read_write.c:590&#xA;  ksys_write+0x20f/0x4c0 fs/read_write.c:643&#xA;  __do_sys_write fs/read_write.c:655 [inline]&#xA;  __se_sys_write fs/read_write.c:652 [inline]&#xA;  __x64_sys_write+0x93/0xd0 fs/read_write.c:652&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;CVE-2024-26817:In the Linux kernel, the following vulnerability has been resolved:&#xA;amdkfd: use calloc instead of kzalloc to avoid integer overflow&#xA;This uses calloc instead of doing the multiplication which might&#xA;overflow.&#xA;CVE-2021-47211:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: usb-audio: fix null pointer dereference on pointer cs_desc&#xA;The pointer cs_desc return from snd_usb_find_clock_source could&#xA;be null, so there is a potential null pointer dereference issue.&#xA;Fix this by adding a null check before dereference.&#xA;CVE-2024-26843:In the Linux kernel, the following vulnerability has been resolved:&#xA;efi: runtime: Fix potential overflow of soft-reserved region size&#xA;md_size will have been narrowed if we have &gt;= 4GB worth of pages in a&#xA;soft-reserved region.&#xA;CVE-2024-26840:In the Linux kernel, the following vulnerability has been resolved:&#xA;cachefiles: fix memory leak in cachefiles_add_cache()&#xA;The following memory leak was reported after unbinding /dev/cachefiles: ==================================================================&#xA;unreferenced object 0xffff9b674176e3c0 (size 192):&#xA;  comm &#34;cachefilesd2&#34;, pid 680, jiffies 4294881224&#xA;  hex dump (first 32 bytes):&#xA;    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace (crc ea38a44b):&#xA;    [&lt;ffffffff8eb8a1a5&gt;] kmem_cache_alloc+0x2d5/0x370&#xA;    [&lt;ffffffff8e917f86&gt;] prepare_creds+0x26/0x2e0&#xA;    [&lt;ffffffffc002eeef&gt;] cachefiles_determine_cache_security+0x1f/0x120&#xA;    [&lt;ffffffffc00243ec&gt;] cachefiles_add_cache+0x13c/0x3a0&#xA;    [&lt;ffffffffc0025216&gt;] cachefiles_daemon_write+0x146/0x1c0&#xA;    [&lt;ffffffff8ebc4a3b&gt;] vfs_write+0xcb/0x520&#xA;    [&lt;ffffffff8ebc5069&gt;] ksys_write+0x69/0xf0&#xA;    [&lt;ffffffff8f6d4662&gt;] do_syscall_64+0x72/0x140&#xA;    [&lt;ffffffff8f8000aa&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ==================================================================&#xA;Put the reference count of cache_cred in cachefiles_daemon_unbind() to&#xA;fix the problem. And also put cache_cred in cachefiles_add_cache() error&#xA;branch to avoid memory leaks.&#xA;CVE-2024-26874:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip&#xA;It&#39;s possible that mtk_crtc-&gt;event is NULL in&#xA;mtk_drm_crtc_finish_page_flip().&#xA;pending_needs_vblank value is set by mtk_crtc-&gt;event, but in&#xA;mtk_drm_crtc_atomic_flush(), it&#39;s is not guarded by the same&#xA;lock in mtk_drm_finish_page_flip(), thus a race condition happens.&#xA;Consider the following case:&#xA;CPU1                              CPU2&#xA;step 1:&#xA;mtk_drm_crtc_atomic_begin()&#xA;mtk_crtc-&gt;event is not null,&#xA;                                  step 1:&#xA;                                  mtk_drm_crtc_atomic_flush:&#xA;                                  mtk_drm_crtc_update_config(&#xA;                                      !!mtk_crtc-&gt;event)&#xA;step 2:&#xA;mtk_crtc_ddp_irq -&gt;&#xA;mtk_drm_finish_page_flip:&#xA;lock&#xA;mtk_crtc-&gt;event set to null,&#xA;pending_needs_vblank set to false&#xA;unlock&#xA;                                  pending_needs_vblank set to true,&#xA;                                  step 2:&#xA;                                  mtk_crtc_ddp_irq -&gt;&#xA;                                  mtk_drm_finish_page_flip called again,&#xA;                                  pending_needs_vblank is still true&#xA;                                  //null pointer&#xA;Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it&#39;s more&#xA;efficient to just check if mtk_crtc-&gt;event is null before use.&#xA;CVE-2024-26900:In the Linux kernel, the following vulnerability has been resolved:&#xA;md: fix kmemleak of rdev-&gt;serial&#xA;If kobject_add() is fail in bind_rdev_to_array(), &#39;rdev-&gt;serial&#39; will be&#xA;alloc not be freed, and kmemleak occurs.&#xA;unreferenced object 0xffff88815a350000 (size 49152):&#xA;  comm &#34;mdadm&#34;, pid 789, jiffies 4294716910&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace (crc f773277a):&#xA;    [&lt;0000000058b0a453&gt;] kmemleak_alloc+0x61/0xe0&#xA;    [&lt;00000000366adf14&gt;] __kmalloc_large_node+0x15e/0x270&#xA;    [&lt;000000002e82961b&gt;] __kmalloc_node.cold+0x11/0x7f&#xA;    [&lt;00000000f206d60a&gt;] kvmalloc_node+0x74/0x150&#xA;    [&lt;0000000034bf3363&gt;] rdev_init_serial+0x67/0x170&#xA;    [&lt;0000000010e08fe9&gt;] mddev_create_serial_pool+0x62/0x220&#xA;    [&lt;00000000c3837bf0&gt;] bind_rdev_to_array+0x2af/0x630&#xA;    [&lt;0000000073c28560&gt;] md_add_new_disk+0x400/0x9f0&#xA;    [&lt;00000000770e30ff&gt;] md_ioctl+0x15bf/0x1c10&#xA;    [&lt;000000006cfab718&gt;] blkdev_ioctl+0x191/0x3f0&#xA;    [&lt;0000000085086a11&gt;] vfs_ioctl+0x22/0x60&#xA;    [&lt;0000000018b656fe&gt;] __x64_sys_ioctl+0xba/0xe0&#xA;    [&lt;00000000e54e675e&gt;] do_syscall_64+0x71/0x150&#xA;    [&lt;000000008b0ad622&gt;] entry_SYSCALL_64_after_hwframe+0x6c/0x74&#xA;CVE-2024-26894:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()&#xA;After unregistering the CPU idle device, the memory associated with&#xA;it is not freed, leading to a memory leak:&#xA;unreferenced object 0xffff896282f6c000 (size 1024):&#xA;  comm &#34;swapper/0&#34;, pid 1, jiffies 4294893170&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace (crc 8836a742):&#xA;    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340&#xA;    [&lt;ffffffff9972f3b3&gt;] acpi_processor_power_init+0xf3/0x1c0&#xA;    [&lt;ffffffff9972d263&gt;] __acpi_processor_start+0xd3/0xf0&#xA;    [&lt;ffffffff9972d2bc&gt;] acpi_processor_start+0x2c/0x50&#xA;    [&lt;ffffffff99805872&gt;] really_probe+0xe2/0x480&#xA;    [&lt;ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160&#xA;    [&lt;ffffffff99805daf&gt;] driver_probe_device+0x1f/0x90&#xA;    [&lt;ffffffff9980601e&gt;] __driver_attach+0xce/0x1c0&#xA;    [&lt;ffffffff99803170&gt;] bus_for_each_dev+0x70/0xc0&#xA;    [&lt;ffffffff99804822&gt;] bus_add_driver+0x112/0x210&#xA;    [&lt;ffffffff99807245&gt;] driver_register+0x55/0x100&#xA;    [&lt;ffffffff9aee4acb&gt;] acpi_processor_driver_init+0x3b/0xc0&#xA;    [&lt;ffffffff990012d1&gt;] do_one_initcall+0x41/0x300&#xA;    [&lt;ffffffff9ae7c4b0&gt;] kernel_init_freeable+0x320/0x470&#xA;    [&lt;ffffffff99b231f6&gt;] kernel_init+0x16/0x1b0&#xA;    [&lt;ffffffff99042e6d&gt;] ret_from_fork+0x2d/0x50&#xA;Fix this by freeing the CPU idle device after unregistering it.&#xA;CVE-2023-52642:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: rc: bpf attach/detach requires write permission&#xA;Note that bpf attach/detach also requires CAP_NET_ADMIN.&#xA;CVE-2024-26839:In the Linux kernel, the following vulnerability has been resolved:&#xA;IB/hfi1: Fix a memleak in init_credit_return&#xA;When dma_alloc_coherent fails to allocate dd-&gt;cr_base[i].va,&#xA;init_credit_return should deallocate dd-&gt;cr_base and&#xA;dd-&gt;cr_base[i] that allocated before. Or those resources&#xA;would be never freed and a memleak is triggered.&#xA;CVE-2024-26855:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()&#xA;The function ice_bridge_setlink() may encounter a NULL pointer dereference&#xA;if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently&#xA;in nla_for_each_nested(). To address this issue, add a check to ensure that&#xA;br_spec is not NULL before proceeding with the nested attribute iteration.&#xA;CVE-2024-26893:In the Linux kernel, the following vulnerability has been resolved:&#xA;firmware: arm_scmi: Fix double free in SMC transport cleanup path&#xA;When the generic SCMI code tears down a channel, it calls the chan_free&#xA;callback function, defined by each transport. Since multiple protocols&#xA;might share the same transport_info member, chan_free() might want to&#xA;clean up the same member multiple times within the given SCMI transport&#xA;implementation. In this case, it is SMC transport. This will lead to a NULL&#xA;pointer dereference at the second time:&#xA;    | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16&#xA;    | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.&#xA;    | arm-scmi firmware:scmi: unable to communicate with SCMI&#xA;    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000&#xA;    | Mem abort info:&#xA;    |   ESR = 0x0000000096000004&#xA;    |   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;    |   SET = 0, FnV = 0&#xA;    |   EA = 0, S1PTW = 0&#xA;    |   FSC = 0x04: level 0 translation fault&#xA;    | Data abort info:&#xA;    |   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000&#xA;    |   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;    |   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;    | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000&#xA;    | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000&#xA;    | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP&#xA;    | Modules linked in:&#xA;    | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793&#xA;    | Hardware name: FVP Base RevC (DT)&#xA;    | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)&#xA;    | pc : smc_chan_free+0x3c/0x6c&#xA;    | lr : smc_chan_free+0x3c/0x6c&#xA;    | Call trace:&#xA;    |  smc_chan_free+0x3c/0x6c&#xA;    |  idr_for_each+0x68/0xf8&#xA;    |  scmi_cleanup_channels.isra.0+0x2c/0x58&#xA;    |  scmi_probe+0x434/0x734&#xA;    |  platform_probe+0x68/0xd8&#xA;    |  really_probe+0x110/0x27c&#xA;    |  __driver_probe_device+0x78/0x12c&#xA;    |  driver_probe_device+0x3c/0x118&#xA;    |  __driver_attach+0x74/0x128&#xA;    |  bus_for_each_dev+0x78/0xe0&#xA;    |  driver_attach+0x24/0x30&#xA;    |  bus_add_driver+0xe4/0x1e8&#xA;    |  driver_register+0x60/0x128&#xA;    |  __platform_driver_register+0x28/0x34&#xA;    |  scmi_driver_init+0x84/0xc0&#xA;    |  do_one_initcall+0x78/0x33c&#xA;    |  kernel_init_freeable+0x2b8/0x51c&#xA;    |  kernel_init+0x24/0x130&#xA;    |  ret_from_fork+0x10/0x20&#xA;    | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)&#xA;    | ---[ end trace 0000000000000000 ]---&#xA;Simply check for the struct pointer being NULL before trying to access&#xA;its members, to avoid this situation.&#xA;This was found when a transport doesn&#39;t really work (for instance no SMC&#xA;service), the probe routines then tries to clean up, and triggers a crash.&#xA;CVE-2024-25739:create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi-&gt;leb_size.&#xA;CVE-2021-47212:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Update error handler for UCTX and UMEM&#xA;In the fast unload flow, the device state is set to internal error,&#xA;which indicates that the driver started the destroy process.&#xA;In this case, when a destroy command is being executed, it should return&#xA;MLX5_CMD_STAT_OK.&#xA;Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK&#xA;instead of EIO.&#xA;This fixes a call trace in the umem release process -&#xA;[ 2633.536695] Call Trace:&#xA;[ 2633.537518]  ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]&#xA;[ 2633.538596]  remove_client_context+0x8b/0xd0 [ib_core]&#xA;[ 2633.539641]  disable_device+0x8c/0x130 [ib_core]&#xA;[ 2633.540615]  __ib_unregister_device+0x35/0xa0 [ib_core]&#xA;[ 2633.541640]  ib_unregister_device+0x21/0x30 [ib_core]&#xA;[ 2633.542663]  __mlx5_ib_remove+0x38/0x90 [mlx5_ib]&#xA;[ 2633.543640]  auxiliary_bus_remove+0x1e/0x30 [auxiliary]&#xA;[ 2633.544661]  device_release_driver_internal+0x103/0x1f0&#xA;[ 2633.545679]  bus_remove_device+0xf7/0x170&#xA;[ 2633.546640]  device_del+0x181/0x410&#xA;[ 2633.547606]  mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]&#xA;[ 2633.548777]  mlx5_unregister_device+0x27/0x40 [mlx5_core]&#xA;[ 2633.549841]  mlx5_uninit_one+0x21/0xc0 [mlx5_core]&#xA;[ 2633.550864]  remove_one+0x69/0xe0 [mlx5_core]&#xA;[ 2633.551819]  pci_device_remove+0x3b/0xc0&#xA;[ 2633.552731]  device_release_driver_internal+0x103/0x1f0&#xA;[ 2633.553746]  unbind_store+0xf6/0x130&#xA;[ 2633.554657]  kernfs_fop_write+0x116/0x190&#xA;[ 2633.555567]  vfs_write+0xa5/0x1a0&#xA;[ 2633.556407]  ksys_write+0x4f/0xb0&#xA;[ 2633.557233]  do_syscall_64+0x5b/0x1a0&#xA;[ 2633.558071]  entry_SYSCALL_64_after_hwframe+0x65/0xca&#xA;[ 2633.559018] RIP: 0033:0x7f9977132648&#xA;[ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55&#xA;[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648&#xA;[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001&#xA;[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740&#xA;[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0&#xA;[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c&#xA;[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---&#xA;CVE-2024-26901:In the Linux kernel, the following vulnerability has been resolved:&#xA;do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak&#xA;syzbot identified a kernel information leak vulnerability in&#xA;do_sys_name_to_handle() and issued the following report [1].&#xA;[1]&#xA;&#34;BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40&#xA; instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA; _copy_to_user+0xbc/0x100 lib/usercopy.c:40&#xA; copy_to_user include/linux/uaccess.h:191 [inline]&#xA; do_sys_name_to_handle fs/fhandle.c:73 [inline]&#xA; __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]&#xA; __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94&#xA; __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94&#xA; ...&#xA;Uninit was created at:&#xA; slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768&#xA; slab_alloc_node mm/slub.c:3478 [inline]&#xA; __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517&#xA; __do_kmalloc_node mm/slab_common.c:1006 [inline]&#xA; __kmalloc+0x121/0x3c0 mm/slab_common.c:1020&#xA; kmalloc include/linux/slab.h:604 [inline]&#xA; do_sys_name_to_handle fs/fhandle.c:39 [inline]&#xA; __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]&#xA; __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94&#xA; __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94&#xA; ...&#xA;Bytes 18-19 of 20 are uninitialized&#xA;Memory access of size 20 starts at ffff888128a46380&#xA;Data copied to user address 0000000020000240&#34;&#xA;Per Chuck Lever&#39;s suggestion, use kzalloc() instead of kmalloc() to&#xA;solve the problem.&#xA;CVE-2024-26875:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: pvrusb2: fix uaf in pvr2_context_set_notify&#xA;[Syzbot reported]&#xA;BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35&#xA;Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26&#xA;CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024&#xA;Workqueue: usb_hub_wq hub_event&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0xc4/0x620 mm/kasan/report.c:488&#xA; kasan_report+0xda/0x110 mm/kasan/report.c:601&#xA; pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35&#xA; pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]&#xA; pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272&#xA;Freed by task 906:&#xA;kasan_save_stack+0x33/0x50 mm/kasan/common.c:47&#xA;kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA;kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640&#xA;poison_slab_object mm/kasan/common.c:241 [inline]&#xA;__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257&#xA;kasan_slab_free include/linux/kasan.h:184 [inline]&#xA;slab_free_hook mm/slub.c:2121 [inline]&#xA;slab_free mm/slub.c:4299 [inline]&#xA;kfree+0x105/0x340 mm/slub.c:4409&#xA;pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]&#xA;pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158&#xA;[Analyze]&#xA;Task A set disconnect_flag = !0, which resulted in Task B&#39;s condition being met&#xA;and releasing mp, leading to this issue.&#xA;[Fix]&#xA;Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()&#xA;to avoid this issue.&#xA;CVE-2022-48655:In the Linux kernel, the following vulnerability has been resolved:&#xA;firmware: arm_scmi: Harden accesses to the reset domains&#xA;Accessing reset domains descriptors by the index upon the SCMI drivers&#xA;requests through the SCMI reset operations interface can potentially&#xA;lead to out-of-bound violations if the SCMI driver misbehave.&#xA;Add an internal consistency check before any such domains descriptors&#xA;accesses.&#xA;CVE-2024-26898:In the Linux kernel, the following vulnerability has been resolved:&#xA;aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts&#xA;This patch is against CVE-2023-6270. The description of cve is:&#xA;  A flaw was found in the ATA over Ethernet (AoE) driver in the Linux&#xA;  kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on&#xA;  `struct net_device`, and a use-after-free can be triggered by racing&#xA;  between the free on the struct and the access through the `skbtxq`&#xA;  global queue. This could lead to a denial of service condition or&#xA;  potential code execution.&#xA;In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial&#xA;code is finished. But the net_device ifp will still be used in&#xA;later tx()-&gt;dev_queue_xmit() in kthread. Which means that the&#xA;dev_put(ifp) should NOT be called in the success path of skb&#xA;initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into&#xA;use-after-free because the net_device is freed.&#xA;This patch removed the dev_put(ifp) in the success path in&#xA;aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().&#xA;CVE-2024-26669:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: flower: Fix chain template offload&#xA;When a qdisc is deleted from a net device the stack instructs the&#xA;underlying driver to remove its flow offload callback from the&#xA;associated filter block using the &#39;FLOW_BLOCK_UNBIND&#39; command. The stack&#xA;then continues to replay the removal of the filters in the block for&#xA;this driver by iterating over the chains in the block and invoking the&#xA;&#39;reoffload&#39; operation of the classifier being used. In turn, the&#xA;classifier in its &#39;reoffload&#39; operation prepares and emits a&#xA;&#39;FLOW_CLS_DESTROY&#39; command for each filter.&#xA;However, the stack does not do the same for chain templates and the&#xA;underlying driver never receives a &#39;FLOW_CLS_TMPLT_DESTROY&#39; command when&#xA;a qdisc is deleted. This results in a memory leak [1] which can be&#xA;reproduced using [2].&#xA;Fix by introducing a &#39;tmplt_reoffload&#39; operation and have the stack&#xA;invoke it with the appropriate arguments as part of the replay.&#xA;Implement the operation in the sole classifier that supports chain&#xA;templates (flower) by emitting the &#39;FLOW_CLS_TMPLT_{CREATE,DESTROY}&#39;&#xA;command based on whether a flow offload callback is being bound to a&#xA;filter block or being unbound from one.&#xA;As far as I can tell, the issue happens since cited commit which&#xA;reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()&#xA;in __tcf_block_put(). The order cannot be reversed as the filter block&#xA;is expected to be freed after flushing all the chains.&#xA;[1]&#xA;unreferenced object 0xffff888107e28800 (size 2048):&#xA;  comm &#34;tc&#34;, pid 1079, jiffies 4294958525 (age 3074.287s)&#xA;  hex dump (first 32 bytes):&#xA;    b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff  ..|......[......&#xA;    01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff  ................&#xA;  backtrace:&#xA;    [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320&#xA;    [&lt;ffffffff81ab374e&gt;] __kmalloc+0x4e/0x90&#xA;    [&lt;ffffffff832aec6d&gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0&#xA;    [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180&#xA;    [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280&#xA;    [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340&#xA;    [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0&#xA;    [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170&#xA;    [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0&#xA;    [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440&#xA;    [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820&#xA;    [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0&#xA;    [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80&#xA;    [&lt;ffffffff8379d29a&gt;] ___sys_sendmsg+0x13a/0x1e0&#xA;    [&lt;ffffffff8379d50c&gt;] __sys_sendmsg+0x11c/0x1f0&#xA;    [&lt;ffffffff843b9ce0&gt;] do_syscall_64+0x40/0xe0&#xA;unreferenced object 0xffff88816d2c0400 (size 1024):&#xA;  comm &#34;tc&#34;, pid 1079, jiffies 4294958525 (age 3074.287s)&#xA;  hex dump (first 32 bytes):&#xA;    40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00  @.......W.8.....&#xA;    10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff  ..,m......,m....&#xA;  backtrace:&#xA;    [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320&#xA;    [&lt;ffffffff81ab36c1&gt;] __kmalloc_node+0x51/0x90&#xA;    [&lt;ffffffff81a8ed96&gt;] kvmalloc_node+0xa6/0x1f0&#xA;    [&lt;ffffffff82827d03&gt;] bucket_table_alloc.isra.0+0x83/0x460&#xA;    [&lt;ffffffff82828d2b&gt;] rhashtable_init+0x43b/0x7c0&#xA;    [&lt;ffffffff832aed48&gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0&#xA;    [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180&#xA;    [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280&#xA;    [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340&#xA;    [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0&#xA;    [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170&#xA;    [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0&#xA;    [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440&#xA;    [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820&#xA;    [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0&#xA;    [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80&#xA;[2]&#xA; # tc qdisc add dev swp1 clsact&#xA; # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32&#xA; # tc qdisc del dev&#xA;---truncated---&#xA;CVE-2024-26680:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: atlantic: Fix DMA mapping for PTP hwts ring&#xA;Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes&#xA;for PTP HWTS ring but then generic aq_ring_free() does not take this&#xA;into account.&#xA;Create and use a specific function to free HWTS ring to fix this&#xA;issue.&#xA;Trace:&#xA;[  215.351607] ------------[ cut here ]------------&#xA;[  215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]&#xA;[  215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360&#xA;...&#xA;[  215.581176] Call Trace:&#xA;[  215.583632]  &lt;TASK&gt;&#xA;[  215.585745]  ? show_trace_log_lvl+0x1c4/0x2df&#xA;[  215.590114]  ? show_trace_log_lvl+0x1c4/0x2df&#xA;[  215.594497]  ? debug_dma_free_coherent+0x196/0x210&#xA;[  215.599305]  ? check_unmap+0xa6f/0x2360&#xA;[  215.603147]  ? __warn+0xca/0x1d0&#xA;[  215.606391]  ? check_unmap+0xa6f/0x2360&#xA;[  215.610237]  ? report_bug+0x1ef/0x370&#xA;[  215.613921]  ? handle_bug+0x3c/0x70&#xA;[  215.617423]  ? exc_invalid_op+0x14/0x50&#xA;[  215.621269]  ? asm_exc_invalid_op+0x16/0x20&#xA;[  215.625480]  ? check_unmap+0xa6f/0x2360&#xA;[  215.629331]  ? mark_lock.part.0+0xca/0xa40&#xA;[  215.633445]  debug_dma_free_coherent+0x196/0x210&#xA;[  215.638079]  ? __pfx_debug_dma_free_coherent+0x10/0x10&#xA;[  215.643242]  ? slab_free_freelist_hook+0x11d/0x1d0&#xA;[  215.648060]  dma_free_attrs+0x6d/0x130&#xA;[  215.651834]  aq_ring_free+0x193/0x290 [atlantic]&#xA;[  215.656487]  aq_ptp_ring_free+0x67/0x110 [atlantic]&#xA;...&#xA;[  216.127540] ---[ end trace 6467e5964dd2640b ]---&#xA;[  216.132160] DMA-API: Mapped at:&#xA;[  216.132162]  debug_dma_alloc_coherent+0x66/0x2f0&#xA;[  216.132165]  dma_alloc_attrs+0xf5/0x1b0&#xA;[  216.132168]  aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]&#xA;[  216.132193]  aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]&#xA;[  216.132213]  aq_nic_init+0x4a1/0x760 [atlantic]&#xA;CVE-2024-26668:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_limit: reject configurations that cause integer overflow&#xA;Reject bogus configs where internal token counter wraps around.&#xA;This only occurs with very very large requests, such as 17gbyte/s.&#xA;Its better to reject this rather than having incorrect ratelimit.&#xA;CVE-2023-52620:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: disallow timeout for anonymous sets&#xA;Never used from userspace, disallow these parameters.&#xA;CVE-2024-27073:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: ttpci: fix two memleaks in budget_av_attach&#xA;When saa7146_register_device and saa7146_vv_init fails, budget_av_attach&#xA;should free the resources it allocates, like the error-handling of&#xA;ttpci_budget_init does. Besides, there are two fixme comment refers to&#xA;such deallocations.&#xA;CVE-2024-27008:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm: nv04: Fix out of bounds access&#xA;When Output Resource (dcb-&gt;or) value is assigned in&#xA;fabricate_dcb_output(), there may be out of bounds access to&#xA;dac_users array in case dcb-&gt;or is zero because ffs(dcb-&gt;or) is&#xA;used as index there.&#xA;The &#39;or&#39; argument of fabricate_dcb_output() must be interpreted as a&#xA;number of bit to set, not value.&#xA;Utilize macros from &#39;enum nouveau_or&#39; in calls instead of hardcoding.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-26958:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfs: fix UAF in direct writes&#xA;In production we have been hitting the following warning consistently&#xA;------------[ cut here ]------------&#xA;refcount_t: underflow; use-after-free.&#xA;WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0&#xA;Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]&#xA;RIP: 0010:refcount_warn_saturate+0x9c/0xe0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __warn+0x9f/0x130&#xA; ? refcount_warn_saturate+0x9c/0xe0&#xA; ? report_bug+0xcc/0x150&#xA; ? handle_bug+0x3d/0x70&#xA; ? exc_invalid_op+0x16/0x40&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? refcount_warn_saturate+0x9c/0xe0&#xA; nfs_direct_write_schedule_work+0x237/0x250 [nfs]&#xA; process_one_work+0x12f/0x4a0&#xA; worker_thread+0x14e/0x3b0&#xA; ? ZSTD_getCParams_internal+0x220/0x220&#xA; kthread+0xdc/0x120&#xA; ? __btf_name_valid+0xa0/0xa0&#xA; ret_from_fork+0x1f/0x30&#xA;This is because we&#39;re completing the nfs_direct_request twice in a row.&#xA;The source of this is when we have our commit requests to submit, we&#xA;process them and send them off, and then in the completion path for the&#xA;commit requests we have&#xA;if (nfs_commit_end(cinfo.mds))&#xA;&#x9;nfs_direct_write_complete(dreq);&#xA;However since we&#39;re submitting asynchronous requests we sometimes have&#xA;one that completes before we submit the next one, so we end up calling&#xA;complete on the nfs_direct_request twice.&#xA;The only other place we use nfs_generic_commit_list() is in&#xA;__nfs_commit_inode, which wraps this call in a&#xA;nfs_commit_begin();&#xA;nfs_commit_end();&#xA;Which is a common pattern for this style of completion handling, one&#xA;that is also repeated in the direct code with get_dreq()/put_dreq()&#xA;calls around where we process events as well as in the completion paths.&#xA;Fix this by using the same pattern for the commit requests.&#xA;Before with my 200 node rocksdb stress running this warning would pop&#xA;every 10ish minutes.  With my patch the stress test has been running for&#xA;several hours without popping.&#xA;CVE-2024-26972:In the Linux kernel, the following vulnerability has been resolved:&#xA;ubifs: ubifs_symlink: Fix memleak of inode-&gt;i_link in error path&#xA;For error handling path in ubifs_symlink(), inode will be marked as&#xA;bad first, then iput() is invoked. If inode-&gt;i_link is initialized by&#xA;fscrypt_encrypt_symlink() in encryption scenario, inode-&gt;i_link won&#39;t&#xA;be freed by callchain ubifs_free_inode -&gt; fscrypt_free_inode in error&#xA;handling path, because make_bad_inode() has changed &#39;inode-&gt;i_mode&#39; as&#xA;&#39;S_IFREG&#39;.&#xA;Following kmemleak is easy to be reproduced by injecting error in&#xA;ubifs_jnl_update() when doing symlink in encryption scenario:&#xA; unreferenced object 0xffff888103da3d98 (size 8):&#xA;  comm &#34;ln&#34;, pid 1692, jiffies 4294914701 (age 12.045s)&#xA;  backtrace:&#xA;   kmemdup+0x32/0x70&#xA;   __fscrypt_encrypt_symlink+0xed/0x1c0&#xA;   ubifs_symlink+0x210/0x300 [ubifs]&#xA;   vfs_symlink+0x216/0x360&#xA;   do_symlinkat+0x11a/0x190&#xA;   do_syscall_64+0x3b/0xe0&#xA;There are two ways fixing it:&#xA; 1. Remove make_bad_inode() in error handling path. We can do that&#xA;    because ubifs_evict_inode() will do same processes for good&#xA;    symlink inode and bad symlink inode, for inode-&gt;i_nlink checking&#xA;    is before is_bad_inode().&#xA; 2. Free inode-&gt;i_link before marking inode bad.&#xA;Method 2 is picked, it has less influence, personally, I think.&#xA;CVE-2024-26811:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: validate payload size in ipc response&#xA;If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc&#xA;response to ksmbd kernel server. ksmbd should validate payload size of&#xA;ipc response from ksmbd.mountd to avoid memory overrun or&#xA;slab-out-of-bounds. This patch validate 3 ipc response that has payload.&#xA;CVE-2024-26828:In the Linux kernel, the following vulnerability has been resolved:&#xA;cifs: fix underflow in parse_server_interfaces()&#xA;In this loop, we step through the buffer and after each item we check&#xA;if the size_left is greater than the minimum size we need.  However,&#xA;the problem is that &#34;bytes_left&#34; is type ssize_t while sizeof() is type&#xA;size_t.  That means that because of type promotion, the comparison is&#xA;done as an unsigned and if we have negative bytes left the loop&#xA;continues instead of ending.&#xA;CVE-2024-26870:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102&#xA;A call to listxattr() with a buffer size = 0 returns the actual&#xA;size of the buffer needed for a subsequent call. When size &gt; 0,&#xA;nfs4_listxattr() does not return an error because either&#xA;generic_listxattr() or nfs4_listxattr_nfs4_label() consumes&#xA;exactly all the bytes then size is 0 when calling&#xA;nfs4_listxattr_nfs4_user() which then triggers the following&#xA;kernel BUG:&#xA;  [   99.403778] kernel BUG at mm/usercopy.c:102!&#xA;  [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP&#xA;  [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1&#xA;  [   99.415827] Call trace:&#xA;  [   99.415985]  usercopy_abort+0x70/0xa0&#xA;  [   99.416227]  __check_heap_object+0x134/0x158&#xA;  [   99.416505]  check_heap_object+0x150/0x188&#xA;  [   99.416696]  __check_object_size.part.0+0x78/0x168&#xA;  [   99.416886]  __check_object_size+0x28/0x40&#xA;  [   99.417078]  listxattr+0x8c/0x120&#xA;  [   99.417252]  path_listxattr+0x78/0xe0&#xA;  [   99.417476]  __arm64_sys_listxattr+0x28/0x40&#xA;  [   99.417723]  invoke_syscall+0x78/0x100&#xA;  [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0&#xA;  [   99.418186]  do_el0_svc+0x24/0x38&#xA;  [   99.418376]  el0_svc+0x3c/0x110&#xA;  [   99.418554]  el0t_64_sync_handler+0x120/0x130&#xA;  [   99.418788]  el0t_64_sync+0x194/0x198&#xA;  [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)&#xA;Issue is reproduced when generic_listxattr() returns &#39;system.nfs4_acl&#39;,&#xA;thus calling lisxattr() with size = 16 will trigger the bug.&#xA;Add check on nfs4_listxattr() to return ERANGE error when it is&#xA;called with size &gt; 0 and the return value is greater than size.&#xA;CVE-2024-27059:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command&#xA;The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values&#xA;in the ATA ID information to calculate cylinder and head values when&#xA;creating a CDB for READ or WRITE commands.  The calculation involves&#xA;division and modulus operations, which will cause a crash if either of&#xA;these values is 0.  While this never happens with a genuine device, it&#xA;could happen with a flawed or subversive emulation, as reported by the&#xA;syzbot fuzzer.&#xA;Protect against this possibility by refusing to bind to the device if&#xA;either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device&#39;s ID&#xA;information is 0.  This requires isd200_Initialization() to return a&#xA;negative error code when initialization fails; currently it always&#xA;returns 0 (even when there is an error).&#xA;CVE-2024-27043:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: edia: dvbdev: fix a use-after-free&#xA;In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed&#xA;in several error-handling paths. However, *pdvbdev is not set to NULL&#xA;after dvbdev&#39;s deallocation, causing use-after-frees in many places,&#xA;for example, in the following call chain:&#xA;budget_register&#xA;  |-&gt; dvb_dmxdev_init&#xA;        |-&gt; dvb_register_device&#xA;  |-&gt; dvb_dmxdev_release&#xA;        |-&gt; dvb_unregister_device&#xA;              |-&gt; dvb_remove_device&#xA;                    |-&gt; dvb_device_put&#xA;                          |-&gt; kref_put&#xA;When calling dvb_unregister_device, dmxdev-&gt;dvbdev (i.e. *pdvbdev in&#xA;dvb_register_device) could point to memory that had been freed in&#xA;dvb_register_device. Thereafter, this pointer is transferred to&#xA;kref_put and triggering a use-after-free.&#xA;CVE-2024-26965:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays&#xA;The frequency table arrays are supposed to be terminated with an&#xA;empty element. Add such entry to the end of the arrays where it&#xA;is missing in order to avoid possible out-of-bound access when&#xA;the table is traversed by functions like qcom_find_freq() or&#xA;qcom_find_freq_floor().&#xA;Only compile tested.&#xA;CVE-2024-26812:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfio/pci: Create persistent INTx handler&#xA;A vulnerability exists where the eventfd for INTx signaling can be&#xA;deconfigured, which unregisters the IRQ handler but still allows&#xA;eventfds to be signaled with a NULL context through the SET_IRQS ioctl&#xA;or through unmask irqfd if the device interrupt is pending.&#xA;Ideally this could be solved with some additional locking; the igate&#xA;mutex serializes the ioctl and config space accesses, and the interrupt&#xA;handler is unregistered relative to the trigger, but the irqfd path&#xA;runs asynchronous to those.  The igate mutex cannot be acquired from the&#xA;atomic context of the eventfd wake function.  Disabling the irqfd&#xA;relative to the eventfd registration is potentially incompatible with&#xA;existing userspace.&#xA;As a result, the solution implemented here moves configuration of the&#xA;INTx interrupt handler to track the lifetime of the INTx context object&#xA;and irq_type configuration, rather than registration of a particular&#xA;trigger eventfd.  Synchronization is added between the ioctl path and&#xA;eventfd_signal() wrapper such that the eventfd trigger can be&#xA;dynamically updated relative to in-flight interrupts or irqfd callbacks.&#xA;CVE-2024-26961:In the Linux kernel, the following vulnerability has been resolved:&#xA;mac802154: fix llsec key resources release in mac802154_llsec_key_del&#xA;mac802154_llsec_key_del() can free resources of a key directly without&#xA;following the RCU rules for waiting before the end of a grace period. This&#xA;may lead to use-after-free in case llsec_lookup_key() is traversing the&#xA;list of keys in parallel with a key deletion:&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0&#xA;Modules linked in:&#xA;CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014&#xA;RIP: 0010:refcount_warn_saturate+0x162/0x2a0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; llsec_lookup_key.isra.0+0x890/0x9e0&#xA; mac802154_llsec_encrypt+0x30c/0x9c0&#xA; ieee802154_subif_start_xmit+0x24/0x1e0&#xA; dev_hard_start_xmit+0x13e/0x690&#xA; sch_direct_xmit+0x2ae/0xbc0&#xA; __dev_queue_xmit+0x11dd/0x3c20&#xA; dgram_sendmsg+0x90b/0xd60&#xA; __sys_sendto+0x466/0x4c0&#xA; __x64_sys_sendto+0xe0/0x1c0&#xA; do_syscall_64+0x45/0xf0&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;Also, ieee802154_llsec_key_entry structures are not freed by&#xA;mac802154_llsec_key_del():&#xA;unreferenced object 0xffff8880613b6980 (size 64):&#xA;  comm &#34;iwpan&#34;, pid 2176, jiffies 4294761134 (age 60.475s)&#xA;  hex dump (first 32 bytes):&#xA;    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......&#34;.......&#xA;    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................&#xA;  backtrace:&#xA;    [&lt;ffffffff81dcfa62&gt;] __kmem_cache_alloc_node+0x1e2/0x2d0&#xA;    [&lt;ffffffff81c43865&gt;] kmalloc_trace+0x25/0xc0&#xA;    [&lt;ffffffff88968b09&gt;] mac802154_llsec_key_add+0xac9/0xcf0&#xA;    [&lt;ffffffff8896e41a&gt;] ieee802154_add_llsec_key+0x5a/0x80&#xA;    [&lt;ffffffff8892adc6&gt;] nl802154_add_llsec_key+0x426/0x5b0&#xA;    [&lt;ffffffff86ff293e&gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0&#xA;    [&lt;ffffffff86ff46d1&gt;] genl_rcv_msg+0x531/0x7d0&#xA;    [&lt;ffffffff86fee7a9&gt;] netlink_rcv_skb+0x169/0x440&#xA;    [&lt;ffffffff86ff1d88&gt;] genl_rcv+0x28/0x40&#xA;    [&lt;ffffffff86fec15c&gt;] netlink_unicast+0x53c/0x820&#xA;    [&lt;ffffffff86fecd8b&gt;] netlink_sendmsg+0x93b/0xe60&#xA;    [&lt;ffffffff86b91b35&gt;] ____sys_sendmsg+0xac5/0xca0&#xA;    [&lt;ffffffff86b9c3dd&gt;] ___sys_sendmsg+0x11d/0x1c0&#xA;    [&lt;ffffffff86b9c65a&gt;] __sys_sendmsg+0xfa/0x1d0&#xA;    [&lt;ffffffff88eadbf5&gt;] do_syscall_64+0x45/0xf0&#xA;    [&lt;ffffffff890000ea&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;Handle the proper resource release in the RCU callback function&#xA;mac802154_llsec_key_del_rcu().&#xA;Note that if llsec_lookup_key() finds a key, it gets a refcount via&#xA;llsec_key_get() and locally copies key id from key_entry (which is a&#xA;list element). So it&#39;s safe to call llsec_key_put() and free the list&#xA;entry after the RCU grace period elapses.&#xA;Found by Linux Verification Center (linuxtesting.org).&#xA;CVE-2024-26931:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qla2xxx: Fix command flush on cable pull&#xA;System crash due to command failed to flush back to SCSI layer.&#xA; BUG: unable to handle kernel NULL pointer dereference at 0000000000000000&#xA; PGD 0 P4D 0&#xA; Oops: 0000 [#1] SMP NOPTI&#xA; CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1&#xA; Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021&#xA; Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]&#xA; RIP: 0010:__wake_up_common+0x4c/0x190&#xA; Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 &lt;49&gt; 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75&#xA; RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086&#xA; RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000&#xA; RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320&#xA; RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8&#xA; R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20&#xA; R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000&#xA; FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; PKRU: 55555554&#xA; Call Trace:&#xA;  __wake_up_common_lock+0x7c/0xc0&#xA;  qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]&#xA; qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0&#xA; ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]&#xA; qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.&#xA;  ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]&#xA; qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1&#xA; ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]&#xA; qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0&#xA;  ? __switch_to+0x10c/0x450&#xA; ? process_one_work+0x1a7/0x360&#xA; qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.&#xA;  ? worker_thread+0x1ce/0x390&#xA;  ? create_worker+0x1a0/0x1a0&#xA; qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70&#xA;  ? kthread+0x10a/0x120&#xA; qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8&#xA;  ? set_kthread_struct+0x40/0x40&#xA; qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.&#xA;  ? ret_from_fork+0x1f/0x40&#xA; qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout&#xA;The system was under memory stress where driver was not able to allocate an&#xA;SRB to carry out error recovery of cable pull.  The failure to flush causes&#xA;upper layer to start modifying scsi_cmnd.  When the system frees up some&#xA;memory, the subsequent cable pull trigger another command flush. At this&#xA;point the driver access a null pointer when attempting to DMA unmap the&#xA;SGL.&#xA;Add a check to make sure commands are flush back on session tear down to&#xA;prevent the null pointer access.&#xA;CVE-2023-52650:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/tegra: dsi: Add missing check for of_find_device_by_node&#xA;Add check for the return value of of_find_device_by_node() and return&#xA;the error if it fails in order to avoid NULL pointer dereference.&#xA;CVE-2024-26704:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix double-free of blocks due to wrong extents moved_len&#xA;In ext4_move_extents(), moved_len is only updated when all moves are&#xA;successfully executed, and only discards orig_inode and donor_inode&#xA;preallocations when moved_len is not zero. When the loop fails to exit&#xA;after successfully moving some extents, moved_len is not updated and&#xA;remains at 0, so it does not discard the preallocations.&#xA;If the moved extents overlap with the preallocated extents, the&#xA;overlapped extents are freed twice in ext4_mb_release_inode_pa() and&#xA;ext4_process_freed_data() (as described in commit 94d7c16cbbbd (&#34;ext4:&#xA;Fix double-free of blocks with EXT4_IOC_MOVE_EXT&#34;)), and bb_free is&#xA;incremented twice. Hence when trim is executed, a zero-division bug is&#xA;triggered in mb_update_avg_fragment_size() because bb_free is not zero&#xA;and bb_fragments is zero.&#xA;Therefore, update move_len after each extent move to avoid the issue.&#xA;CVE-2024-26791:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: dev-replace: properly validate device names&#xA;There&#39;s a syzbot report that device name buffers passed to device&#xA;replace are not properly checked for string termination which could lead&#xA;to a read out of bounds in getname_kernel().&#xA;Add a helper that validates both source and target device name buffers.&#xA;For devid as the source initialize the buffer to empty string in case&#xA;something tries to read it later.&#xA;This was originally analyzed and fixed in a different way by Edward Adam&#xA;Davis (see links).&#xA;CVE-2024-26689:In the Linux kernel, the following vulnerability has been resolved:&#xA;ceph: prevent use-after-free in encode_cap_msg()&#xA;In fs/ceph/caps.c, in encode_cap_msg(), &#34;use after free&#34; error was&#xA;caught by KASAN at this line - &#39;ceph_buffer_get(arg-&gt;xattr_buf);&#39;. This&#xA;implies before the refcount could be increment here, it was freed.&#xA;In same file, in &#34;handle_cap_grant()&#34; refcount is decremented by this&#xA;line - &#39;ceph_buffer_put(ci-&gt;i_xattrs.blob);&#39;. It appears that a race&#xA;occurred and resource was freed by the latter line before the former&#xA;line could increment it.&#xA;encode_cap_msg() is called by __send_cap() and __send_cap() is called by&#xA;ceph_check_caps() after calling __prep_cap(). __prep_cap() is where&#xA;arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where&#xA;the refcount must be increased to prevent &#34;use after free&#34; error.&#xA;CVE-2024-26950:In the Linux kernel, the following vulnerability has been resolved:&#xA;wireguard: netlink: access device through ctx instead of peer&#xA;The previous commit fixed a bug that led to a NULL peer-&gt;device being&#xA;dereferenced. It&#39;s actually easier and faster performance-wise to&#xA;instead get the device from ctx-&gt;wg. This semantically makes more sense&#xA;too, since ctx-&gt;wg-&gt;peer_allowedips.seq is compared with&#xA;ctx-&gt;allowedips_seq, basing them both in ctx. This also acts as a&#xA;defence in depth provision against freed peers.&#xA;CVE-2024-27000:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: mxs-auart: add spinlock around changing cts state&#xA;The uart_handle_cts_change() function in serial_core expects the caller&#xA;to hold uport-&gt;lock. For example, I have seen the below kernel splat,&#xA;when the Bluetooth driver is loaded on an i.MX28 board.&#xA;    [   85.119255] ------------[ cut here ]------------&#xA;    [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec&#xA;    [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs&#xA;    [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1&#xA;    [   85.151396] Hardware name: Freescale MXS (Device Tree)&#xA;    [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]&#xA;    (...)&#xA;    [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4&#xA;    [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210&#xA;    (...)&#xA;CVE-2024-26878:In the Linux kernel, the following vulnerability has been resolved:&#xA;quota: Fix potential NULL pointer dereference&#xA;Below race may cause NULL pointer dereference&#xA;P1&#x9;&#x9;&#x9;&#x9;&#x9;P2&#xA;dquot_free_inode&#x9;&#x9;&#x9;quota_off&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  drop_dquot_ref&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;   remove_dquot_ref&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;   dquots = i_dquot(inode)&#xA;  dquots = i_dquot(inode)&#xA;  srcu_read_lock&#xA;  dquots[cnt]) != NULL (1)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;     dquots[type] = NULL (2)&#xA;  spin_lock(&amp;dquots[cnt]-&gt;dq_dqb_lock) (3)&#xA;   ....&#xA;If dquot_free_inode(or other routines) checks inode&#39;s quota pointers (1)&#xA;before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer&#xA;dereference will be triggered.&#xA;So let&#39;s fix it by using a temporary pointer to avoid this issue.&#xA;CVE-2024-27075:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: dvb-frontends: avoid stack overflow warnings with clang&#xA;A previous patch worked around a KASAN issue in stv0367, now a similar&#xA;problem showed up with clang:&#xA;drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in &#39;stv0367ter_set_frontend&#39; [-Werror,-Wframe-larger-than]&#xA; 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)&#xA;Rework the stv0367_writereg() function to be simpler and mark both&#xA;register access functions as noinline_for_stack so the temporary&#xA;i2c_msg structures do not get duplicated on the stack when KASAN_STACK&#xA;is enabled.&#xA;CVE-2024-27389:In the Linux kernel, the following vulnerability has been resolved:&#xA;pstore: inode: Only d_invalidate() is needed&#xA;Unloading a modular pstore backend with records in pstorefs would&#xA;trigger the dput() double-drop warning:&#xA;  WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410&#xA;Using the combo of d_drop()/dput() (as mentioned in&#xA;Documentation/filesystems/vfs.rst) isn&#39;t the right approach here, and&#xA;leads to the reference counting problem seen above. Use d_invalidate()&#xA;and update the code to not bother checking for error codes that can&#xA;never happen.&#xA;---&#xA;CVE-2024-26973:In the Linux kernel, the following vulnerability has been resolved:&#xA;fat: fix uninitialized field in nostale filehandles&#xA;When fat_encode_fh_nostale() encodes file handle without a parent it&#xA;stores only first 10 bytes of the file handle. However the length of the&#xA;file handle must be a multiple of 4 so the file handle is actually 12&#xA;bytes long and the last two bytes remain uninitialized. This is not&#xA;great at we potentially leak uninitialized information with the handle&#xA;to userspace. Properly initialize the full handle length.&#xA;CVE-2024-26993:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs: sysfs: Fix reference leak in sysfs_break_active_protection()&#xA;The sysfs_break_active_protection() routine has an obvious reference&#xA;leak in its error path.  If the call to kernfs_find_and_get() fails then&#xA;kn will be NULL, so the companion sysfs_unbreak_active_protection()&#xA;routine won&#39;t get called (and would only cause an access violation by&#xA;trying to dereference kn-&gt;parent if it was called).  As a result, the&#xA;reference to kobj acquired at the start of the function will never be&#xA;released.&#xA;Fix the leak by adding an explicit kobject_put() call when kn is NULL.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/kernel-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/kernel-headers-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/kernel-devel-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/kernel-tools-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/kernel-tools-devel-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/perf-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-perf-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/bpftool-5.10.0-136.75.0.155.u110.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/kernel-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/kernel-headers-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/kernel-devel-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/kernel-tools-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/kernel-tools-devel-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/perf-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-perf-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.75.0.155.u110.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/bpftool-5.10.0-136.75.0.155.u110.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2168</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3652" id="CVE-2024-3652" title="CVE-2024-3652" type="cve"></reference>
		</references>
		<description>CVE-2024-3652:The Libreswan Project was notified of an issue causing libreswan to restart when using IKEv1 without specifying an esp= line. When the peer requests AES-GMAC, libreswan&#39;s default proposal handler causes an assertion failure and crashes and restarts. IKEv2 connections are not affected.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.15">
					<filename>libreswan-4.15-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libreswan-4.15-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.15">
					<filename>libreswan-help-4.15-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libreswan-help-4.15-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan" release="1.u1.fos23" version="4.15">
					<filename>libreswan-4.15-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libreswan-4.15-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libreswan-help" release="1.u1.fos23" version="4.15">
					<filename>libreswan-help-4.15-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libreswan-help-4.15-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2169</id>
		<title>An update for libyaml is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3205" id="CVE-2024-3205" title="CVE-2024-3205" type="cve"></reference>
		</references>
		<description>CVE-2024-3205:A vulnerability was found in yaml libyaml up to 0.2.5 and classified as critical. Affected by this issue is the function yaml_emitter_emit_flow_sequence_item of the file /src/libyaml/src/emitter.c. The manipulation leads to heap-based buffer overflow. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-259052. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="libyaml" release="6.u2.fos23" version="0.2.5">
					<filename>libyaml-0.2.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libyaml-0.2.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libyaml-devel" release="6.u2.fos23" version="0.2.5">
					<filename>libyaml-devel-0.2.5-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libyaml-devel-0.2.5-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libyaml-help" release="6.u2.fos23" version="0.2.5">
					<filename>libyaml-help-0.2.5-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/libyaml-help-0.2.5-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libyaml" release="6.u2.fos23" version="0.2.5">
					<filename>libyaml-0.2.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libyaml-0.2.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libyaml-devel" release="6.u2.fos23" version="0.2.5">
					<filename>libyaml-devel-0.2.5-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/libyaml-devel-0.2.5-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2170</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20964" id="CVE-2024-20964" title="CVE-2024-20964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20971" id="CVE-2024-20971" title="CVE-2024-20971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20976" id="CVE-2024-20976" title="CVE-2024-20976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20973" id="CVE-2024-20973" title="CVE-2024-20973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20978" id="CVE-2024-20978" title="CVE-2024-20978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20981" id="CVE-2024-20981" title="CVE-2024-20981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20962" id="CVE-2024-20962" title="CVE-2024-20962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20977" id="CVE-2024-20977" title="CVE-2024-20977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20963" id="CVE-2024-20963" title="CVE-2024-20963" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20965" id="CVE-2024-20965" title="CVE-2024-20965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20972" id="CVE-2024-20972" title="CVE-2024-20972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20961" id="CVE-2024-20961" title="CVE-2024-20961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20982" id="CVE-2024-20982" title="CVE-2024-20982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20970" id="CVE-2024-20970" title="CVE-2024-20970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20967" id="CVE-2024-20967" title="CVE-2024-20967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20984" id="CVE-2024-20984" title="CVE-2024-20984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20974" id="CVE-2024-20974" title="CVE-2024-20974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20966" id="CVE-2024-20966" title="CVE-2024-20966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20960" id="CVE-2024-20960" title="CVE-2024-20960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20985" id="CVE-2024-20985" title="CVE-2024-20985" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20969" id="CVE-2024-20969" title="CVE-2024-20969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21000" id="CVE-2024-21000" title="CVE-2024-21000" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21069" id="CVE-2024-21069" title="CVE-2024-21069" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21009" id="CVE-2024-21009" title="CVE-2024-21009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21087" id="CVE-2024-21087" title="CVE-2024-21087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21047" id="CVE-2024-21047" title="CVE-2024-21047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20998" id="CVE-2024-20998" title="CVE-2024-20998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21013" id="CVE-2024-21013" title="CVE-2024-21013" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21060" id="CVE-2024-21060" title="CVE-2024-21060" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21008" id="CVE-2024-21008" title="CVE-2024-21008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21102" id="CVE-2024-21102" title="CVE-2024-21102" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21054" id="CVE-2024-21054" title="CVE-2024-21054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21062" id="CVE-2024-21062" title="CVE-2024-21062" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20994" id="CVE-2024-20994" title="CVE-2024-20994" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21096" id="CVE-2024-21096" title="CVE-2024-21096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21061" id="CVE-2024-21061" title="CVE-2024-21061" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20993" id="CVE-2024-20993" title="CVE-2024-20993" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21055" id="CVE-2024-21055" title="CVE-2024-21055" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21057" id="CVE-2024-21057" title="CVE-2024-21057" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6129" id="CVE-2023-6129" title="CVE-2023-6129" type="cve"></reference>
		</references>
		<description>CVE-2024-20964:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20971:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20976:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20973:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20978:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20981:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20962:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20977:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20963:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20965:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20972:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20961:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20982:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20970:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20967:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2024-20984:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server : Security : Firewall).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20974:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20966:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20960:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: RAPID).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20985:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: UDF).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20969:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2024-21000:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 3.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21069:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21009:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21087:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21047:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20998:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21013:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21060:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Data Dictionary).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21008:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21102:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21054:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21062:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20994:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21096:Vulnerability in the MySQL Server product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).&#xA;CVE-2024-21061:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Audit Plug-in).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20993:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior and  8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21055:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21057:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2023-6129:Issue summary: The POLY1305 MAC (message authentication code) implementation&#xA;contains a bug that might corrupt the internal state of applications running&#xA;on PowerPC CPU based platforms if the CPU provides vector instructions.&#xA;Impact summary: If an attacker can influence whether the POLY1305 MAC&#xA;algorithm is used, the application state might be corrupted with various&#xA;application dependent consequences.&#xA;The POLY1305 MAC (message authentication code) implementation in OpenSSL for&#xA;PowerPC CPUs restores the contents of vector registers in a different order&#xA;than they are saved. Thus the contents of some of these vector registers&#xA;are corrupted when returning to the caller. The vulnerable code is used only&#xA;on newer PowerPC processors supporting the PowerISA 2.07 instructions.&#xA;The consequences of this kind of internal application state corruption can&#xA;be various - from no consequences, if the calling application does not&#xA;depend on the contents of non-volatile XMM registers at all, to the worst&#xA;consequences, where the attacker could get complete control of the application&#xA;process. However unless the compiler uses the vector registers for storing&#xA;pointers, the most likely consequence, if any, would be an incorrect result&#xA;of some application dependent calculations or a crash leading to a denial of&#xA;service.&#xA;The POLY1305 MAC algorithm is most frequently used as part of the&#xA;CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)&#xA;algorithm. The most common usage of this AEAD cipher is with TLS protocol&#xA;versions 1.2 and 1.3. If this cipher is enabled on the server a malicious&#xA;client can influence whether this AEAD cipher is used. This implies that&#xA;TLS server applications using OpenSSL can be potentially impacted. However&#xA;we are currently not aware of any concrete application that would be affected&#xA;by this issue therefore we consider this a Low severity security issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-libs-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-libs-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-config-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-config-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-common-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-common-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-errmsg-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-errmsg-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-server-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-server-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-devel-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-devel-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-test-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-test-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-help-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-help-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-libs-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-libs-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-config-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-config-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-common-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-common-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-errmsg-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-errmsg-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-server-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-server-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-devel-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-devel-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-test-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-test-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-help-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-help-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2171</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6129" id="CVE-2023-6129" title="CVE-2023-6129" type="cve"></reference>
		</references>
		<description>CVE-2023-6129:Issue summary: The POLY1305 MAC (message authentication code) implementation&#xA;contains a bug that might corrupt the internal state of applications running&#xA;on PowerPC CPU based platforms if the CPU provides vector instructions.&#xA;Impact summary: If an attacker can influence whether the POLY1305 MAC&#xA;algorithm is used, the application state might be corrupted with various&#xA;application dependent consequences.&#xA;The POLY1305 MAC (message authentication code) implementation in OpenSSL for&#xA;PowerPC CPUs restores the contents of vector registers in a different order&#xA;than they are saved. Thus the contents of some of these vector registers&#xA;are corrupted when returning to the caller. The vulnerable code is used only&#xA;on newer PowerPC processors supporting the PowerISA 2.07 instructions.&#xA;The consequences of this kind of internal application state corruption can&#xA;be various - from no consequences, if the calling application does not&#xA;depend on the contents of non-volatile XMM registers at all, to the worst&#xA;consequences, where the attacker could get complete control of the application&#xA;process. However unless the compiler uses the vector registers for storing&#xA;pointers, the most likely consequence, if any, would be an incorrect result&#xA;of some application dependent calculations or a crash leading to a denial of&#xA;service.&#xA;The POLY1305 MAC algorithm is most frequently used as part of the&#xA;CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)&#xA;algorithm. The most common usage of this AEAD cipher is with TLS protocol&#xA;versions 1.2 and 1.3. If this cipher is enabled on the server a malicious&#xA;client can influence whether this AEAD cipher is used. This implies that&#xA;TLS server applications using OpenSSL can be potentially impacted. However&#xA;we are currently not aware of any concrete application that would be affected&#xA;by this issue therefore we consider this a Low severity security issue.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="openssl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-libs-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-perl-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-34.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/openssl-devel-1.1.1m-34.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-34.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-help-1.1.1m-34.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-libs-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-perl-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="34.u16.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-34.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/openssl-devel-1.1.1m-34.u16.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2172</id>
		<title>An update for python-idna is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3651" id="CVE-2024-3651" title="CVE-2024-3651" type="cve"></reference>
		</references>
		<description>CVE-2024-3651:A flaw was found in the python-idna library. A malicious argument was sent to the idna.encode() function can trigger an uncontrolled resource consumption, resulting in a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="noarch" epoch="0" name="python3-idna" release="3.u1.fos23" version="3.2">
					<filename>python3-idna-3.2-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-idna-3.2-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2173</id>
		<title>An update for python-jinja2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34064" id="CVE-2024-34064" title="CVE-2024-34064" type="cve"></reference>
		</references>
		<description>CVE-2024-34064:Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `&gt;`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="noarch" epoch="0" name="python3-jinja2" release="4.u2.fos23" version="3.0.3">
					<filename>python3-jinja2-3.0.3-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-jinja2-3.0.3-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-jinja2-help" release="4.u2.fos23" version="3.0.3">
					<filename>python-jinja2-help-3.0.3-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python-jinja2-help-3.0.3-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2174</id>
		<title>An update for python-tqdm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34062" id="CVE-2024-34062" title="CVE-2024-34062" type="cve"></reference>
		</references>
		<description>CVE-2024-34062:tqdm is an open source progress bar for Python and CLI. Any optional non-boolean CLI arguments (e.g. `--delim`, `--buf-size`, `--manpath`) are passed through python&#39;s `eval`, allowing arbitrary code execution. This issue is only locally exploitable and had been addressed in release version 4.66.3. All users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="python3-tqdm" release="4.u1.fos23" version="4.56.0">
					<filename>python3-tqdm-4.56.0-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-tqdm-4.56.0-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-tqdm-help" release="4.u1.fos23" version="4.56.0">
					<filename>python-tqdm-help-4.56.0-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python-tqdm-help-4.56.0-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-tqdm" release="4.u1.fos23" version="4.56.0">
					<filename>python3-tqdm-4.56.0-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-tqdm-4.56.0-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2175</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3447" id="CVE-2024-3447" title="CVE-2024-3447" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3446" id="CVE-2024-3446" title="CVE-2024-3446" type="cve"></reference>
		</references>
		<description>CVE-2024-3447:A heap-based buffer overflow was found in the SDHCI device emulation of QEMU. The bug is triggered when both `s-&gt;data_count` and the size of  `s-&gt;fifo_buffer` are set to 0x200, leading to an out-of-bound access. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.&#xA;CVE-2024-3446:A double free vulnerability was found in QEMU virtio devices (virtio-gpu, virtio-serial-bus, virtio-crypto), where the mem_reentrancy_guard flag insufficiently protects against DMA reentrancy issues. This issue could allow a malicious privileged guest user to crash the QEMU process on the host, resulting in a denial of service or allow arbitrary code execution within the context of the QEMU process on the host.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="10" name="qemu" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-guest-agent-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-91.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-help-6.2.0-91.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-img-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-block-rbd-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-block-ssh-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-block-iscsi-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-block-curl-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-hw-usb-host-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-seabios-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-system-aarch64-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-system-arm-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-system-x86_64-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-91.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qemu-system-riscv-6.2.0-91.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-guest-agent-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-img-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-block-rbd-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-block-ssh-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-block-iscsi-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-block-curl-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-hw-usb-host-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-system-aarch64-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-system-arm-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-system-x86_64-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="91.u16.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-91.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qemu-system-riscv-6.2.0-91.u16.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2176</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45935" id="CVE-2023-45935" title="CVE-2023-45935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25580" id="CVE-2024-25580" title="CVE-2024-25580" type="cve"></reference>
		</references>
		<description>CVE-2023-45935:Qt 6 through 6.6 was discovered to contain a NULL pointer dereference via the function QXcbConnection::initializeAllAtoms(). NOTE: this is disputed because it is not expected that an X application should continue to run when there is arbitrary anomalous behavior from the X server.&#xA;CVE-2024-25580:An issue was discovered in gui/util/qktxhandler.cpp in Qt before 5.15.17, 6.x before 6.2.12, 6.3.x through 6.5.x before 6.5.5, and 6.6.x before 6.6.2. A buffer overflow and application crash can occur via a crafted KTX image file.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-16.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-common-5.15.2-16.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-devel-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-private-devel-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-examples-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-static-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-mysql-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-odbc-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-postgresql-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-16.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/qt5-qtbase-gui-5.15.2-16.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-devel-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-private-devel-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-examples-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-static-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-mysql-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-odbc-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-postgresql-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="16.u9.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-16.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/qt5-qtbase-gui-5.15.2-16.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2177</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27282" id="CVE-2024-27282" title="CVE-2024-27282" type="cve"></reference>
		</references>
		<description>CVE-2024-27282:An issue was discovered in Ruby 3.x through 3.3.0. If attacker-supplied data is provided to the Ruby regex compiler, it is possible to extract arbitrary heap data relative to the start of the text, including pointers and sensitive strings. The fixed versions are 3.0.7, 3.1.5, 3.2.4, and 3.3.1.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="ruby" release="133.u7.fos23" version="3.0.3">
					<filename>ruby-3.0.3-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ruby-3.0.3-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="133.u7.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ruby-devel-3.0.3-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="133.u7.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygems-3.2.32-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="133.u7.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygems-devel-3.2.32-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="133.u7.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-rake-13.0.3-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="133.u7.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-rbs-1.4.0-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="133.u7.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ruby-irb-3.0.3-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="133.u7.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-rdoc-6.3.3-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="133.u7.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/ruby-help-3.0.3-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="133.u7.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-bigdecimal-3.0.0-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="133.u7.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-did_you_mean-1.5.0-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="133.u7.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-io-console-0.5.7-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="133.u7.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-json-2.5.1-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="133.u7.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-minitest-5.14.2-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="133.u7.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-openssl-2.2.1-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="133.u7.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-133.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-psych-3.3.2-133.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="133.u7.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-test-unit-3.3.7-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="133.u7.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-rexml-3.2.5-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="133.u7.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-rss-0.2.9-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="133.u7.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-133.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/rubygem-typeprof-0.15.2-133.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="133.u7.fos23" version="3.0.3">
					<filename>ruby-3.0.3-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ruby-3.0.3-133.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="133.u7.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/ruby-devel-3.0.3-133.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="133.u7.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rubygem-bigdecimal-3.0.0-133.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="133.u7.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rubygem-io-console-0.5.7-133.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="133.u7.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rubygem-json-2.5.1-133.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="133.u7.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rubygem-openssl-2.2.1-133.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="133.u7.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-133.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/rubygem-psych-3.3.2-133.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2178</id>
		<title>An update for sane-backends is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46047" id="CVE-2023-46047" title="CVE-2023-46047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46052" id="CVE-2023-46052" title="CVE-2023-46052" type="cve"></reference>
		</references>
		<description>CVE-2023-46047:An issue in Sane 1.2.1 allows a local attacker to execute arbitrary code via a crafted file to the sanei_configure_attach() function. NOTE: this is disputed because there is no expectation that the product should be starting with an attacker-controlled configuration file.&#xA;CVE-2023-46052:Sane 1.2.1 heap bounds overwrite in init_options() from backend/test.c via a long init_mode string in a configuration file. NOTE: this is disputed because there is no expectation that test.c code should be executed with an attacker-controlled configuration file.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="sane-backends" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-1.0.28-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-1.0.28-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sane-backends-help" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-help-1.0.28-12.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-help-1.0.28-12.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sane-backends-libs" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-libs-1.0.28-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-libs-1.0.28-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sane-backends-devel" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-devel-1.0.28-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-devel-1.0.28-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sane-backends-drivers-scanners" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-drivers-scanners-1.0.28-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-drivers-scanners-1.0.28-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sane-backends-drivers-cameras" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-drivers-cameras-1.0.28-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-drivers-cameras-1.0.28-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sane-backends-daemon" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-daemon-1.0.28-12.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sane-backends-daemon-1.0.28-12.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sane-backends" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-1.0.28-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sane-backends-1.0.28-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sane-backends-libs" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-libs-1.0.28-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sane-backends-libs-1.0.28-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sane-backends-devel" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-devel-1.0.28-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sane-backends-devel-1.0.28-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sane-backends-drivers-scanners" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-drivers-scanners-1.0.28-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sane-backends-drivers-scanners-1.0.28-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sane-backends-drivers-cameras" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-drivers-cameras-1.0.28-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sane-backends-drivers-cameras-1.0.28-12.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sane-backends-daemon" release="12.u1.fos23" version="1.0.28">
					<filename>sane-backends-daemon-1.0.28-12.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sane-backends-daemon-1.0.28-12.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2179</id>
		<title>An update for skopeo is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28180" id="CVE-2024-28180" title="CVE-2024-28180" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29406" id="CVE-2023-29406" title="CVE-2023-29406" type="cve"></reference>
		</references>
		<description>CVE-2022-41723:A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.&#xA;CVE-2024-28180:Package jose aims to provide an implementation of the Javascript Object Signing and Encryption set of standards. An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). This vulnerability has been patched in versions 4.0.1, 3.0.3 and 2.6.3.&#xA;CVE-2023-29406:The HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host header can inject additional headers or entire requests. With fix, the HTTP/1 client now refuses to send requests containing an invalid Request.Host or Request.URL.Host value.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="1" name="skopeo" release="7.u2.fos23" version="1.5.2">
					<filename>skopeo-1.5.2-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/skopeo-1.5.2-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="containers-common" release="7.u2.fos23" version="1.5.2">
					<filename>containers-common-1.5.2-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/containers-common-1.5.2-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="skopeo" release="7.u2.fos23" version="1.5.2">
					<filename>skopeo-1.5.2-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/skopeo-1.5.2-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="containers-common" release="7.u2.fos23" version="1.5.2">
					<filename>containers-common-1.5.2-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/containers-common-1.5.2-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2180</id>
		<title>An update for sssd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3758" id="CVE-2023-3758" title="CVE-2023-3758" type="cve"></reference>
		</references>
		<description>CVE-2023-3758:A race condition flaw was found in sssd where the GPO policy is not consistently applied for authenticated users. This may lead to improper authorization issues, granting or denying access to resources inappropriately.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="sssd" release="14.u6.fos23" version="2.6.1">
					<filename>sssd-2.6.1-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sssd-2.6.1-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sssd-devel" release="14.u6.fos23" version="2.6.1">
					<filename>sssd-devel-2.6.1-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sssd-devel-2.6.1-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-sssd" release="14.u6.fos23" version="2.6.1">
					<filename>python3-sssd-2.6.1-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/python3-sssd-2.6.1-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sssd-help" release="14.u6.fos23" version="2.6.1">
					<filename>sssd-help-2.6.1-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/sssd-help-2.6.1-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sssd" release="14.u6.fos23" version="2.6.1">
					<filename>sssd-2.6.1-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sssd-2.6.1-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sssd-devel" release="14.u6.fos23" version="2.6.1">
					<filename>sssd-devel-2.6.1-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/sssd-devel-2.6.1-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-sssd" release="14.u6.fos23" version="2.6.1">
					<filename>python3-sssd-2.6.1-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/python3-sssd-2.6.1-14.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2181</id>
		<title>An update for systemd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"></reference>
		</references>
		<description>CVE-2023-50387:Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the &#34;KeyTrap&#34; issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.&#xA;CVE-2023-50868:The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the &#34;NSEC3&#34; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="systemd" release="76.u17.fos23" version="249">
					<filename>systemd-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-devel" release="76.u17.fos23" version="249">
					<filename>systemd-devel-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-devel-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-libs" release="76.u17.fos23" version="249">
					<filename>systemd-libs-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-libs-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-udev" release="76.u17.fos23" version="249">
					<filename>systemd-udev-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-udev-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-container" release="76.u17.fos23" version="249">
					<filename>systemd-container-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-container-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-resolved" release="76.u17.fos23" version="249">
					<filename>systemd-resolved-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-resolved-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-nspawn" release="76.u17.fos23" version="249">
					<filename>systemd-nspawn-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-nspawn-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-networkd" release="76.u17.fos23" version="249">
					<filename>systemd-networkd-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-networkd-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-timesyncd" release="76.u17.fos23" version="249">
					<filename>systemd-timesyncd-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-timesyncd-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-pam" release="76.u17.fos23" version="249">
					<filename>systemd-pam-249-76.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-pam-249-76.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="systemd-help" release="76.u17.fos23" version="249">
					<filename>systemd-help-249-76.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/systemd-help-249-76.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="76.u17.fos23" version="249">
					<filename>systemd-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-devel" release="76.u17.fos23" version="249">
					<filename>systemd-devel-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-devel-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-libs" release="76.u17.fos23" version="249">
					<filename>systemd-libs-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-libs-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-udev" release="76.u17.fos23" version="249">
					<filename>systemd-udev-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-udev-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-container" release="76.u17.fos23" version="249">
					<filename>systemd-container-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-container-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-resolved" release="76.u17.fos23" version="249">
					<filename>systemd-resolved-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-resolved-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-nspawn" release="76.u17.fos23" version="249">
					<filename>systemd-nspawn-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-nspawn-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-networkd" release="76.u17.fos23" version="249">
					<filename>systemd-networkd-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-networkd-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-timesyncd" release="76.u17.fos23" version="249">
					<filename>systemd-timesyncd-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-timesyncd-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-pam" release="76.u17.fos23" version="249">
					<filename>systemd-pam-249-76.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/systemd-pam-249-76.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2182</id>
		<title>An update for tcpdump is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2397" id="CVE-2024-2397" title="CVE-2024-2397" type="cve"></reference>
		</references>
		<description>CVE-2024-2397:Due to a bug in packet data buffers management, the PPP printer in tcpdump can enter an infinite loop when reading a crafted DLT_PPP_SERIAL .pcap savefile.  This problem does not affect any tcpdump release, but it affected the git master branch from 2023-06-05 to 2024-03-21.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="14" name="tcpdump" release="9.u3.fos23" version="4.99.1">
					<filename>tcpdump-4.99.1-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tcpdump-4.99.1-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="14" name="tcpdump-help" release="9.u3.fos23" version="4.99.1">
					<filename>tcpdump-help-4.99.1-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tcpdump-help-4.99.1-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="tcpdump" release="9.u3.fos23" version="4.99.1">
					<filename>tcpdump-4.99.1-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/tcpdump-4.99.1-9.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="tcpdump-help" release="9.u3.fos23" version="4.99.1">
					<filename>tcpdump-help-4.99.1-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/tcpdump-help-4.99.1-9.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2183</id>
		<title>An update for tpm2-tools is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29038" id="CVE-2024-29038" title="CVE-2024-29038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29039" id="CVE-2024-29039" title="CVE-2024-29039" type="cve"></reference>
		</references>
		<description>CVE-2024-29038:A flaw was found in the tpm2-tools package. This issue occurs due to a missing check whether the magic number in attest is equal to TPM2_GENERATED_VALUE, which can allow an attacker to generate arbitrary quote data that may not be detected by tpm2_checkquote.&#xA;CVE-2024-29039:A flaw was found in tpm2-tools. The PCR selection, which is passed with the --pcr parameter, is not compared with the attest, making it possible for an attacker to fake a valid attestation.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="tpm2-tools" release="6.u1.fos23" version="5.0">
					<filename>tpm2-tools-5.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tpm2-tools-5.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tpm2-tools-help" release="6.u1.fos23" version="5.0">
					<filename>tpm2-tools-help-5.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tpm2-tools-help-5.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tpm2-tools" release="6.u1.fos23" version="5.0">
					<filename>tpm2-tools-5.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/tpm2-tools-5.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2184</id>
		<title>An update for tpm2-tss is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29040" id="CVE-2024-29040" title="CVE-2024-29040" type="cve"></reference>
		</references>
		<description>CVE-2024-29040:A flaw was found in the tpm2-tss package, where it was not checked to see if the magic number in the attest is equal to the TPM2_GENERATED_VALUE. This flaw allows an attacker to generate arbitrary quote data, which may not be detected by Fapi_VerifyQuote.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="tpm2-tss" release="5.u2.fos23" version="3.1.0">
					<filename>tpm2-tss-3.1.0-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tpm2-tss-3.1.0-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tpm2-tss-devel" release="5.u2.fos23" version="3.1.0">
					<filename>tpm2-tss-devel-3.1.0-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tpm2-tss-devel-3.1.0-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tpm2-tss-help" release="5.u2.fos23" version="3.1.0">
					<filename>tpm2-tss-help-3.1.0-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/tpm2-tss-help-3.1.0-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tpm2-tss" release="5.u2.fos23" version="3.1.0">
					<filename>tpm2-tss-3.1.0-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/tpm2-tss-3.1.0-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tpm2-tss-devel" release="5.u2.fos23" version="3.1.0">
					<filename>tpm2-tss-devel-3.1.0-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/tpm2-tss-devel-3.1.0-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2185</id>
		<title>An update for uriparser is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34402" id="CVE-2024-34402" title="CVE-2024-34402" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34403" id="CVE-2024-34403" title="CVE-2024-34403" type="cve"></reference>
		</references>
		<description>CVE-2024-34402:An issue was discovered in uriparser through 0.9.7. ComposeQueryEngine in UriQuery.c has an integer overflow via long keys or values, with a resultant buffer overflow.&#xA;CVE-2024-34403:An issue was discovered in uriparser through 0.9.7. ComposeQueryMallocExMm in UriQuery.c has an integer overflow via a long string.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="uriparser" release="2.u1.fos23" version="0.9.6">
					<filename>uriparser-0.9.6-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/uriparser-0.9.6-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uriparser-devel" release="2.u1.fos23" version="0.9.6">
					<filename>uriparser-devel-0.9.6-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/uriparser-devel-0.9.6-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uriparser-help" release="2.u1.fos23" version="0.9.6">
					<filename>uriparser-help-0.9.6-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/uriparser-help-0.9.6-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uriparser" release="2.u1.fos23" version="0.9.6">
					<filename>uriparser-0.9.6-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/uriparser-0.9.6-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uriparser-devel" release="2.u1.fos23" version="0.9.6">
					<filename>uriparser-devel-0.9.6-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/uriparser-devel-0.9.6-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2186</id>
		<title>An update for webkit2gtk3 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-30294" id="CVE-2022-30294" title="CVE-2022-30294" type="cve"></reference>
		</references>
		<description>CVE-2022-30294:In WebKitGTK through 2.36.0 (and WPE WebKit), there is a use-after-free in WebCore::TextureMapperLayer::setContentsLayer in WebCore/platform/graphics/texmap/TextureMapperLayer.cpp.</description>
		<pkglist>
			<collection>
				<name>23.0.2</name>
				<package arch="x86_64" epoch="0" name="webkit2gtk3" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-devel-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-devel-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-jsc" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-jsc-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-jsc-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2/webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-devel-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-devel-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-jsc" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-jsc-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-jsc-devel" release="4.u1.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2/webkit2gtk3-jsc-devel-2.36.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2187</id>
		<title>An update for xorg-x11-server-Xwayland is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0229" id="CVE-2024-0229" title="CVE-2024-0229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6377" id="CVE-2023-6377" title="CVE-2023-6377" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6478" id="CVE-2023-6478" title="CVE-2023-6478" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0408" id="CVE-2024-0408" title="CVE-2024-0408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0409" id="CVE-2024-0409" title="CVE-2024-0409" type="cve"></reference>
		</references>
		<description>CVE-2024-0229:An out-of-bounds memory access flaw was found in the X.Org server. This issue can be triggered when a device frozen by a sync grab is reattached to a different master device. This issue may lead to an application crash, local privilege escalation (if the server runs with extended privileges), or remote code execution in SSH X11 forwarding environments.&#xA;CVE-2023-6377:A flaw was found in xorg-server. Querying or changing XKB button actions such as moving from a touchpad to a mouse can result in out-of-bounds memory reads and writes. This may allow local privilege escalation or possible remote code execution in cases where X11 forwarding is involved.&#xA;CVE-2023-6478:A flaw was found in xorg-server. A specially crafted request to RRChangeProviderProperty or RRChangeOutputProperty can trigger an integer overflow which may lead to a disclosure of sensitive information.&#xA;CVE-2023-6816:A flaw was found in X.Org server. Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Buttons can be arbitrarily mapped to any value up to 255, but the X.Org Server was only allocating space for the device&#39;s particular number of buttons, leading to a heap overflow if a bigger value was used.&#xA;CVE-2024-0408:A flaw was found in the X.Org server. The GLX PBuffer code does not call the XACE hook when creating the buffer, leaving it unlabeled. When the client issues another request to access that resource (as with a GetGeometry) or when it creates another resource that needs to access that buffer, such as a GC, the XSELINUX code will try to use an object that was never labeled and crash because the SID is NULL.&#xA;CVE-2024-0409:A flaw was found in the X.Org server. The cursor code in both Xephyr and Xwayland uses the wrong type of private at creation. It uses the cursor bits type with the cursor as private, and when initiating the cursor, that overwrites the XSELINUX context.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland" release="5.u3.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/xorg-x11-server-Xwayland-22.1.2-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="5.u3.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/xorg-x11-server-Xwayland-devel-22.1.2-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland" release="5.u3.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/xorg-x11-server-Xwayland-22.1.2-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="5.u3.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/xorg-x11-server-Xwayland-devel-22.1.2-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2188</id>
		<title>An update for apache-poi is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26336" id="CVE-2022-26336" title="CVE-2022-26336" type="cve"></reference>
		</references>
		<description>CVE-2022-26336:A shortcoming in the HMEF package of poi-scratchpad (Apache POI) allows an attacker to cause an Out of Memory exception. This package is used to read TNEF files (Microsoft Outlook and Microsoft Exchange Server). If an application uses poi-scratchpad to parse TNEF files and the application allows untrusted users to supply them, then a carefully crafted file can cause an Out of Memory exception. This issue affects poi-scratchpad version 5.2.0 and prior versions. Users are recommended to upgrade to poi-scratchpad 5.2.1.</description>
		<pkglist>
			<collection>
				<name>23.0.4</name>
				<package arch="noarch" epoch="0" name="apache-poi" release="2.u2.fos23" version="3.17">
					<filename>apache-poi-3.17-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/apache-poi-3.17-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-poi-javadoc" release="2.u2.fos23" version="3.17">
					<filename>apache-poi-javadoc-3.17-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4/apache-poi-javadoc-3.17-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2189</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48339" id="CVE-2022-48339" title="CVE-2022-48339" type="cve"></reference>
		</references>
		<description>CVE-2022-48339:An issue was discovered in GNU Emacs through 28.2. htmlfontify.el has a command injection vulnerability. In the hfy-istext-command function, the parameter file and parameter srcdir come from external input, and parameters are not escaped. If a file name or directory name contains shell metacharacters, code may be executed.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="1" name="emacs" release="13.u5.fos23" version="27.2">
					<filename>emacs-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="13.u5.fos23" version="27.2">
					<filename>emacs-devel-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-devel-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="13.u5.fos23" version="27.2">
					<filename>emacs-lucid-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-lucid-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="13.u5.fos23" version="27.2">
					<filename>emacs-nox-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-nox-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="13.u5.fos23" version="27.2">
					<filename>emacs-common-27.2-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/emacs-common-27.2-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="13.u5.fos23" version="27.2">
					<filename>emacs-terminal-27.2-13.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-terminal-27.2-13.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="13.u5.fos23" version="27.2">
					<filename>emacs-filesystem-27.2-13.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-filesystem-27.2-13.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="13.u5.fos23" version="27.2">
					<filename>emacs-help-27.2-13.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-help-27.2-13.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="13.u5.fos23" version="27.2">
					<filename>emacs-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="13.u5.fos23" version="27.2">
					<filename>emacs-devel-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-devel-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="13.u5.fos23" version="27.2">
					<filename>emacs-lucid-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-lucid-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="13.u5.fos23" version="27.2">
					<filename>emacs-nox-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-nox-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="13.u5.fos23" version="27.2">
					<filename>emacs-common-27.2-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/emacs-common-27.2-13.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2190</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39318" id="CVE-2023-39318" title="CVE-2023-39318" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39319" id="CVE-2023-39319" title="CVE-2023-39319" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39323" id="CVE-2023-39323" title="CVE-2023-39323" type="cve"></reference>
		</references>
		<description>CVE-2023-39318:The html/template package does not properly handle HTML-like &#34;&#34; comment tokens, nor hashbang &#34;#!&#34; comment tokens, in &lt;script&gt; contexts. This may cause the template parser to improperly interpret the contents of &lt;script&gt; contexts, causing actions to be improperly escaped. This may be leveraged to perform an XSS attack.&#xA;CVE-2023-39319:The html/template package does not apply the proper rules for handling occurrences of &#34;&lt;script&#34;, &#34;&lt;!--&#34;, and &#34;&lt;/script&#34; within JS literals in &lt;script&gt; contexts. This may cause the template parser to improperly consider script contexts to be terminated early, causing actions to be improperly escaped. This could be leveraged to perform an XSS attack.&#xA;CVE-2023-39323:Line directives (&#34;//line&#34;) can be used to bypass the restrictions on &#34;//go:cgo_&#34; directives, allowing blocked linker and compiler flags to be passed during compilation. This can result in unexpected execution of arbitrary code when running &#34;go build&#34;. The line directive requires the absolute path of the file in which the directive lives, which makes exploiting this issue significantly more complex.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u9.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-1.20.5-3.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u9.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-help-1.20.5-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u9.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-devel-1.20.5-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u9.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/golang-1.20.5-3.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2191</id>
		<title>An update for gperftools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13420" id="CVE-2018-13420" title="CVE-2018-13420" type="cve"></reference>
		</references>
		<description>CVE-2018-13420:Google gperftools 2.7 has a memory leak in malloc_extension.cc, related to MallocExtension::Register and InitModule. NOTE: the software maintainer indicates that this is not a bug; it is only a false-positive report from the LeakSanitizer program</description>
		<pkglist>
			<collection>
				<name>23.0.2.6</name>
				<package arch="x86_64" epoch="0" name="gperftools" release="2.u2.fos23" version="2.10">
					<filename>gperftools-2.10-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gperftools-2.10-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gperftools-libs" release="2.u2.fos23" version="2.10">
					<filename>gperftools-libs-2.10-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gperftools-libs-2.10-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gperftools-devel" release="2.u2.fos23" version="2.10">
					<filename>gperftools-devel-2.10-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.0.2.6/gperftools-devel-2.10-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pprof" release="2.u2.fos23" version="2.10">
					<filename>pprof-2.10-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/pprof-2.10-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gperftools" release="2.u2.fos23" version="2.10">
					<filename>gperftools-2.10-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gperftools-2.10-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gperftools-libs" release="2.u2.fos23" version="2.10">
					<filename>gperftools-libs-2.10-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gperftools-libs-2.10-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gperftools-devel" release="2.u2.fos23" version="2.10">
					<filename>gperftools-devel-2.10-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.2.6/gperftools-devel-2.10-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2192</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2002-20001" id="CVE-2002-20001" title="CVE-2002-20001" type="cve"></reference>
		</references>
		<description>CVE-2002-20001:The Diffie-Hellman Key Agreement Protocol allows remote attackers (from the client side) to send arbitrary numbers that are actually not public keys, and trigger expensive server-side DHE modular-exponentiation calculations, aka a D(HE)at or D(HE)ater attack. The client needs very little CPU resources and network bandwidth. The attack may be more disruptive in cases where a client can require a server to select its largest supported key size. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="httpd" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-devel-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-help-2.4.51-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-filesystem-2.4.51-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/httpd-tools-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_ssl-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="21.u11.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_md-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="21.u11.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_proxy_html-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_ldap-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="21.u11.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mod_session-2.4.51-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/httpd-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/httpd-devel-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="21.u11.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/httpd-tools-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_ssl-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="21.u11.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_md-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="21.u11.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_proxy_html-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="21.u11.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_ldap-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="21.u11.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mod_session-2.4.51-21.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2193</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2002-20001" id="CVE-2002-20001" title="CVE-2002-20001" type="cve"></reference>
		</references>
		<description>CVE-2002-20001:The Diffie-Hellman Key Agreement Protocol allows remote attackers (from the client side) to send arbitrary numbers that are actually not public keys, and trigger expensive server-side DHE modular-exponentiation calculations, aka a D(HE)at or D(HE)ater attack. The client needs very little CPU resources and network bandwidth. The attack may be more disruptive in cases where a client can require a server to select its largest supported key size. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="openssh" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-8.8p1-29.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/openssh-8.8p1-29.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-29.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/openssh-clients-8.8p1-29.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-29.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/openssh-server-8.8p1-29.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-29.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/openssh-keycat-8.8p1-29.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-29.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/openssh-askpass-8.8p1-29.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.29.u19.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.29.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/pam_ssh_agent_auth-0.10.4-4.29.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-help-8.8p1-29.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/openssh-help-8.8p1-29.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-8.8p1-29.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/openssh-8.8p1-29.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-29.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/openssh-clients-8.8p1-29.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-29.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/openssh-server-8.8p1-29.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-29.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/openssh-keycat-8.8p1-29.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="29.u19.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-29.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/openssh-askpass-8.8p1-29.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.29.u19.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.29.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/pam_ssh_agent_auth-0.10.4-4.29.u19.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2194</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25762" id="CVE-2022-25762" title="CVE-2022-25762" type="cve"></reference>
		</references>
		<description>CVE-2022-25762:If a web application sends a WebSocket message concurrently with the WebSocket connection closing when running on Apache Tomcat 8.5.0 to 8.5.75 or Apache Tomcat 9.0.0.M1 to 9.0.20, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors.</description>
		<pkglist>
			<collection>
				<name>23.0.4.3</name>
				<package arch="noarch" epoch="1" name="tomcat" release="33.u13.fos23" version="9.0.10">
					<filename>tomcat-9.0.10-33.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/tomcat-9.0.10-33.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="33.u13.fos23" version="9.0.10">
					<filename>tomcat-jsvc-9.0.10-33.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/tomcat-jsvc-9.0.10-33.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="33.u13.fos23" version="9.0.10">
					<filename>tomcat-help-9.0.10-33.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.0.4.3/tomcat-help-9.0.10-33.u13.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2195</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-05-28"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2426" id="CVE-2023-2426" title="CVE-2023-2426" type="cve"></reference>
		</references>
		<description>CVE-2023-2426:Use of Out-of-range Pointer Offset in GitHub repository vim/vim prior to 9.0.1499.</description>
		<pkglist>
			<collection>
				<name>23.1.1</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="23.u14.fos23" version="9.0">
					<filename>vim-common-9.0-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/vim-common-9.0-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="23.u14.fos23" version="9.0">
					<filename>vim-minimal-9.0-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/vim-minimal-9.0-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="23.u14.fos23" version="9.0">
					<filename>vim-enhanced-9.0-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/vim-enhanced-9.0-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="23.u14.fos23" version="9.0">
					<filename>vim-filesystem-9.0-23.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/vim-filesystem-9.0-23.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="23.u14.fos23" version="9.0">
					<filename>vim-X11-9.0-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1/vim-X11-9.0-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="23.u14.fos23" version="9.0">
					<filename>vim-common-9.0-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/vim-common-9.0-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="23.u14.fos23" version="9.0">
					<filename>vim-minimal-9.0-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/vim-minimal-9.0-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="23.u14.fos23" version="9.0">
					<filename>vim-enhanced-9.0-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/vim-enhanced-9.0-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="23.u14.fos23" version="9.0">
					<filename>vim-X11-9.0-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1/vim-X11-9.0-23.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2196</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40633" id="CVE-2021-40633" title="CVE-2021-40633" type="cve"></reference>
		</references>
		<description>CVE-2021-40633:A memory leak (out-of-memory) in gif2rgb in util/gif2rgb.c in giflib 5.1.4 allows remote attackers trigger an out of memory exception or denial of service via a gif format file.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="giflib" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-5.2.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/giflib-5.2.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-devel" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/giflib-devel-5.2.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-utils" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/giflib-utils-5.2.1-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="giflib-help" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-help-5.2.1-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/giflib-help-5.2.1-8.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-5.2.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/giflib-5.2.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-devel" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-devel-5.2.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/giflib-devel-5.2.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-utils" release="8.u4.fos23" version="5.2.1">
					<filename>giflib-utils-5.2.1-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/giflib-utils-5.2.1-8.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2197</id>
		<title>An update for git is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32004" id="CVE-2024-32004" title="CVE-2024-32004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32020" id="CVE-2024-32020" title="CVE-2024-32020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32021" id="CVE-2024-32021" title="CVE-2024-32021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32465" id="CVE-2024-32465" title="CVE-2024-32465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32002" id="CVE-2024-32002" title="CVE-2024-32002" type="cve"></reference>
		</references>
		<description>CVE-2024-32004:Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare a local repository in such a way that, when cloned, will execute arbitrary code during the operation. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid cloning repositories from untrusted sources.&#xA;CVE-2024-32020:Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository&#39;s object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a &#34;proper&#34; clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.&#xA;CVE-2024-32021:Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the `objects/` directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository&#39;s `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloning&#xA;will be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.&#xA;CVE-2024-32465:Git is a revision control system. The Git project recommends to avoid working in untrusted repositories, and instead to clone it first with `git clone --no-local` to obtain a clean copy. Git has specific protections to make that a safe operation even with an untrusted source repository, but vulnerabilities allow those protections to be bypassed. In the context of cloning local repositories owned by other users, this vulnerability has been covered in CVE-2024-32004. But there are circumstances where the fixes for CVE-2024-32004 are not enough: For example, when obtaining a `.zip` file containing a full copy of a Git repository, it should not be trusted by default to be safe, as e.g. hooks could be configured to run within the context of that repository. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid using Git in repositories that have been obtained via archives from untrusted sources.&#xA;CVE-2024-32002:Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule&#39;s worktree but into a `.git/` directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is disabled in Git (e.g. via `git config --global core.symlinks false`), the described attack won&#39;t work. As always, it is best to avoid cloning repositories from untrusted sources.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="git" release="15.u6.fos23" version="2.33.0">
					<filename>git-2.33.0-15.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/git-2.33.0-15.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-core" release="15.u6.fos23" version="2.33.0">
					<filename>git-core-2.33.0-15.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/git-core-2.33.0-15.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-daemon" release="15.u6.fos23" version="2.33.0">
					<filename>git-daemon-2.33.0-15.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/git-daemon-2.33.0-15.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-gui" release="15.u6.fos23" version="2.33.0">
					<filename>git-gui-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-gui-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gitk" release="15.u6.fos23" version="2.33.0">
					<filename>gitk-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/gitk-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-web" release="15.u6.fos23" version="2.33.0">
					<filename>git-web-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-web-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-svn" release="15.u6.fos23" version="2.33.0">
					<filename>git-svn-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-svn-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-email" release="15.u6.fos23" version="2.33.0">
					<filename>git-email-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-email-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git" release="15.u6.fos23" version="2.33.0">
					<filename>perl-Git-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/perl-Git-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git-SVN" release="15.u6.fos23" version="2.33.0">
					<filename>perl-Git-SVN-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/perl-Git-SVN-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-help" release="15.u6.fos23" version="2.33.0">
					<filename>git-help-2.33.0-15.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-help-2.33.0-15.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git" release="15.u6.fos23" version="2.33.0">
					<filename>git-2.33.0-15.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-2.33.0-15.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-core" release="15.u6.fos23" version="2.33.0">
					<filename>git-core-2.33.0-15.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-core-2.33.0-15.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-daemon" release="15.u6.fos23" version="2.33.0">
					<filename>git-daemon-2.33.0-15.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/git-daemon-2.33.0-15.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2198</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24787" id="CVE-2024-24787" title="CVE-2024-24787" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24788" id="CVE-2024-24788" title="CVE-2024-24788" type="cve"></reference>
		</references>
		<description>CVE-2024-24787:On Darwin, building a Go module which contains CGO can trigger arbitrary code execution when using the Apple version of ld, due to usage of the -lto_library flag in a &#34;#cgo LDFLAGS&#34; directive.&#xA;CVE-2024-24788:A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an &#xA;infinite loop.</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u9.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/golang-1.20.5-3.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u9.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/golang-help-1.20.5-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u9.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/golang-devel-1.20.5-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u9.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/golang-1.20.5-3.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2199</id>
		<title>An update for infinispan is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10174" id="CVE-2019-10174" title="CVE-2019-10174" type="cve"></reference>
		</references>
		<description>CVE-2019-10174:A vulnerability was found in Infinispan such that the invokeAccessibly method from the public class ReflectionUtil allows any application class to invoke private methods in any class with Infinispan&#39;s privileges. The attacker can use reflection to introduce new, malicious behavior into the application.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="noarch" epoch="0" name="infinispan" release="13.u1.fos23" version="8.2.4">
					<filename>infinispan-8.2.4-13.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/infinispan-8.2.4-13.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="infinispan-help" release="13.u1.fos23" version="8.2.4">
					<filename>infinispan-help-8.2.4-13.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/infinispan-help-8.2.4-13.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2200</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47193" id="CVE-2021-47193" title="CVE-2021-47193" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47199" id="CVE-2021-47199" title="CVE-2021-47199" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48645" id="CVE-2022-48645" title="CVE-2022-48645" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48673" id="CVE-2022-48673" title="CVE-2022-48673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48674" id="CVE-2022-48674" title="CVE-2022-48674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48703" id="CVE-2022-48703" title="CVE-2022-48703" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52434" id="CVE-2023-52434" title="CVE-2023-52434" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52444" id="CVE-2023-52444" title="CVE-2023-52444" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52457" id="CVE-2023-52457" title="CVE-2023-52457" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52610" id="CVE-2023-52610" title="CVE-2023-52610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52612" id="CVE-2023-52612" title="CVE-2023-52612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52614" id="CVE-2023-52614" title="CVE-2023-52614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52627" id="CVE-2023-52627" title="CVE-2023-52627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52646" id="CVE-2023-52646" title="CVE-2023-52646" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52652" id="CVE-2023-52652" title="CVE-2023-52652" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52686" id="CVE-2023-52686" title="CVE-2023-52686" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52753" id="CVE-2023-52753" title="CVE-2023-52753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52802" id="CVE-2023-52802" title="CVE-2023-52802" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52806" id="CVE-2023-52806" title="CVE-2023-52806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52814" id="CVE-2023-52814" title="CVE-2023-52814" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52817" id="CVE-2023-52817" title="CVE-2023-52817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52821" id="CVE-2023-52821" title="CVE-2023-52821" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52843" id="CVE-2023-52843" title="CVE-2023-52843" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52845" id="CVE-2023-52845" title="CVE-2023-52845" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52846" id="CVE-2023-52846" title="CVE-2023-52846" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52853" id="CVE-2023-52853" title="CVE-2023-52853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52855" id="CVE-2023-52855" title="CVE-2023-52855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52858" id="CVE-2023-52858" title="CVE-2023-52858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52864" id="CVE-2023-52864" title="CVE-2023-52864" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52865" id="CVE-2023-52865" title="CVE-2023-52865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52868" id="CVE-2023-52868" title="CVE-2023-52868" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52871" id="CVE-2023-52871" title="CVE-2023-52871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52873" id="CVE-2023-52873" title="CVE-2023-52873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52875" id="CVE-2023-52875" title="CVE-2023-52875" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52876" id="CVE-2023-52876" title="CVE-2023-52876" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24855" id="CVE-2024-24855" title="CVE-2024-24855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26594" id="CVE-2024-26594" title="CVE-2024-26594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26602" id="CVE-2024-26602" title="CVE-2024-26602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26663" id="CVE-2024-26663" title="CVE-2024-26663" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26673" id="CVE-2024-26673" title="CVE-2024-26673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26813" id="CVE-2024-26813" title="CVE-2024-26813" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26825" id="CVE-2024-26825" title="CVE-2024-26825" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26829" id="CVE-2024-26829" title="CVE-2024-26829" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26830" id="CVE-2024-26830" title="CVE-2024-26830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26857" id="CVE-2024-26857" title="CVE-2024-26857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26862" id="CVE-2024-26862" title="CVE-2024-26862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26863" id="CVE-2024-26863" title="CVE-2024-26863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26865" id="CVE-2024-26865" title="CVE-2024-26865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26869" id="CVE-2024-26869" title="CVE-2024-26869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26872" id="CVE-2024-26872" title="CVE-2024-26872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26876" id="CVE-2024-26876" title="CVE-2024-26876" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26877" id="CVE-2024-26877" title="CVE-2024-26877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26889" id="CVE-2024-26889" title="CVE-2024-26889" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26895" id="CVE-2024-26895" title="CVE-2024-26895" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26896" id="CVE-2024-26896" title="CVE-2024-26896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26897" id="CVE-2024-26897" title="CVE-2024-26897" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26904" id="CVE-2024-26904" title="CVE-2024-26904" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26910" id="CVE-2024-26910" title="CVE-2024-26910" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26915" id="CVE-2024-26915" title="CVE-2024-26915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26922" id="CVE-2024-26922" title="CVE-2024-26922" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26924" id="CVE-2024-26924" title="CVE-2024-26924" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26925" id="CVE-2024-26925" title="CVE-2024-26925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26926" id="CVE-2024-26926" title="CVE-2024-26926" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26934" id="CVE-2024-26934" title="CVE-2024-26934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26955" id="CVE-2024-26955" title="CVE-2024-26955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26956" id="CVE-2024-26956" title="CVE-2024-26956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26960" id="CVE-2024-26960" title="CVE-2024-26960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26966" id="CVE-2024-26966" title="CVE-2024-26966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26969" id="CVE-2024-26969" title="CVE-2024-26969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26974" id="CVE-2024-26974" title="CVE-2024-26974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26979" id="CVE-2024-26979" title="CVE-2024-26979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26981" id="CVE-2024-26981" title="CVE-2024-26981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26984" id="CVE-2024-26984" title="CVE-2024-26984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26988" id="CVE-2024-26988" title="CVE-2024-26988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26994" id="CVE-2024-26994" title="CVE-2024-26994" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26996" id="CVE-2024-26996" title="CVE-2024-26996" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26999" id="CVE-2024-26999" title="CVE-2024-26999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27001" id="CVE-2024-27001" title="CVE-2024-27001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27004" id="CVE-2024-27004" title="CVE-2024-27004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27010" id="CVE-2024-27010" title="CVE-2024-27010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27011" id="CVE-2024-27011" title="CVE-2024-27011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27014" id="CVE-2024-27014" title="CVE-2024-27014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27019" id="CVE-2024-27019" title="CVE-2024-27019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27020" id="CVE-2024-27020" title="CVE-2024-27020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27028" id="CVE-2024-27028" title="CVE-2024-27028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27030" id="CVE-2024-27030" title="CVE-2024-27030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27032" id="CVE-2024-27032" title="CVE-2024-27032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27034" id="CVE-2024-27034" title="CVE-2024-27034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27035" id="CVE-2024-27035" title="CVE-2024-27035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27037" id="CVE-2024-27037" title="CVE-2024-27037" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27038" id="CVE-2024-27038" title="CVE-2024-27038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27046" id="CVE-2024-27046" title="CVE-2024-27046" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27051" id="CVE-2024-27051" title="CVE-2024-27051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27053" id="CVE-2024-27053" title="CVE-2024-27053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27054" id="CVE-2024-27054" title="CVE-2024-27054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27074" id="CVE-2024-27074" title="CVE-2024-27074" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27077" id="CVE-2024-27077" title="CVE-2024-27077" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35935" id="CVE-2024-35935" title="CVE-2024-35935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35973" id="CVE-2024-35973" title="CVE-2024-35973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35978" id="CVE-2024-35978" title="CVE-2024-35978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35982" id="CVE-2024-35982" title="CVE-2024-35982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35984" id="CVE-2024-35984" title="CVE-2024-35984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35990" id="CVE-2024-35990" title="CVE-2024-35990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36008" id="CVE-2024-36008" title="CVE-2024-36008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36954" id="CVE-2024-36954" title="CVE-2024-36954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47421" id="CVE-2021-47421" title="CVE-2021-47421" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47455" id="CVE-2021-47455" title="CVE-2021-47455" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48659" id="CVE-2022-48659" title="CVE-2022-48659" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48660" id="CVE-2022-48660" title="CVE-2022-48660" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48708" id="CVE-2022-48708" title="CVE-2022-48708" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52609" id="CVE-2023-52609" title="CVE-2023-52609" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52615" id="CVE-2023-52615" title="CVE-2023-52615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52616" id="CVE-2023-52616" title="CVE-2023-52616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52618" id="CVE-2023-52618" title="CVE-2023-52618" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52621" id="CVE-2023-52621" title="CVE-2023-52621" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52623" id="CVE-2023-52623" title="CVE-2023-52623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52629" id="CVE-2023-52629" title="CVE-2023-52629" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52630" id="CVE-2023-52630" title="CVE-2023-52630" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52633" id="CVE-2023-52633" title="CVE-2023-52633" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52635" id="CVE-2023-52635" title="CVE-2023-52635" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52637" id="CVE-2023-52637" title="CVE-2023-52637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52639" id="CVE-2023-52639" title="CVE-2023-52639" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52644" id="CVE-2023-52644" title="CVE-2023-52644" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52656" id="CVE-2023-52656" title="CVE-2023-52656" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52664" id="CVE-2023-52664" title="CVE-2023-52664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52675" id="CVE-2023-52675" title="CVE-2023-52675" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52676" id="CVE-2023-52676" title="CVE-2023-52676" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52683" id="CVE-2023-52683" title="CVE-2023-52683" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52685" id="CVE-2023-52685" title="CVE-2023-52685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52690" id="CVE-2023-52690" title="CVE-2023-52690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52694" id="CVE-2023-52694" title="CVE-2023-52694" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52698" id="CVE-2023-52698" title="CVE-2023-52698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52809" id="CVE-2023-52809" title="CVE-2023-52809" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52835" id="CVE-2023-52835" title="CVE-2023-52835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52840" id="CVE-2023-52840" title="CVE-2023-52840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52841" id="CVE-2023-52841" title="CVE-2023-52841" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52844" id="CVE-2023-52844" title="CVE-2023-52844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52847" id="CVE-2023-52847" title="CVE-2023-52847" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52854" id="CVE-2023-52854" title="CVE-2023-52854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52860" id="CVE-2023-52860" title="CVE-2023-52860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52863" id="CVE-2023-52863" title="CVE-2023-52863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52869" id="CVE-2023-52869" title="CVE-2023-52869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52870" id="CVE-2023-52870" title="CVE-2023-52870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24860" id="CVE-2024-24860" title="CVE-2024-24860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26610" id="CVE-2024-26610" title="CVE-2024-26610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26633" id="CVE-2024-26633" title="CVE-2024-26633" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26635" id="CVE-2024-26635" title="CVE-2024-26635" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26636" id="CVE-2024-26636" title="CVE-2024-26636" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26640" id="CVE-2024-26640" title="CVE-2024-26640" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26641" id="CVE-2024-26641" title="CVE-2024-26641" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26642" id="CVE-2024-26642" title="CVE-2024-26642" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26645" id="CVE-2024-26645" title="CVE-2024-26645" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26661" id="CVE-2024-26661" title="CVE-2024-26661" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26665" id="CVE-2024-26665" title="CVE-2024-26665" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26675" id="CVE-2024-26675" title="CVE-2024-26675" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26679" id="CVE-2024-26679" title="CVE-2024-26679" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26684" id="CVE-2024-26684" title="CVE-2024-26684" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26685" id="CVE-2024-26685" title="CVE-2024-26685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26686" id="CVE-2024-26686" title="CVE-2024-26686" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26697" id="CVE-2024-26697" title="CVE-2024-26697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26702" id="CVE-2024-26702" title="CVE-2024-26702" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26706" id="CVE-2024-26706" title="CVE-2024-26706" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26707" id="CVE-2024-26707" title="CVE-2024-26707" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26712" id="CVE-2024-26712" title="CVE-2024-26712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26720" id="CVE-2024-26720" title="CVE-2024-26720" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26726" id="CVE-2024-26726" title="CVE-2024-26726" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26733" id="CVE-2024-26733" title="CVE-2024-26733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26734" id="CVE-2024-26734" title="CVE-2024-26734" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26735" id="CVE-2024-26735" title="CVE-2024-26735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26740" id="CVE-2024-26740" title="CVE-2024-26740" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26743" id="CVE-2024-26743" title="CVE-2024-26743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26744" id="CVE-2024-26744" title="CVE-2024-26744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26754" id="CVE-2024-26754" title="CVE-2024-26754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26763" id="CVE-2024-26763" title="CVE-2024-26763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26776" id="CVE-2024-26776" title="CVE-2024-26776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26782" id="CVE-2024-26782" title="CVE-2024-26782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26787" id="CVE-2024-26787" title="CVE-2024-26787" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26801" id="CVE-2024-26801" title="CVE-2024-26801" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26805" id="CVE-2024-26805" title="CVE-2024-26805" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26808" id="CVE-2024-26808" title="CVE-2024-26808" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26809" id="CVE-2024-26809" title="CVE-2024-26809" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26814" id="CVE-2024-26814" title="CVE-2024-26814" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26851" id="CVE-2024-26851" title="CVE-2024-26851" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26881" id="CVE-2024-26881" title="CVE-2024-26881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26900" id="CVE-2024-26900" title="CVE-2024-26900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26901" id="CVE-2024-26901" title="CVE-2024-26901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26903" id="CVE-2024-26903" title="CVE-2024-26903" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26907" id="CVE-2024-26907" title="CVE-2024-26907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26908" id="CVE-2024-26908" title="CVE-2024-26908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26923" id="CVE-2024-26923" title="CVE-2024-26923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26937" id="CVE-2024-26937" title="CVE-2024-26937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26970" id="CVE-2024-26970" title="CVE-2024-26970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26976" id="CVE-2024-26976" title="CVE-2024-26976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26982" id="CVE-2024-26982" title="CVE-2024-26982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27002" id="CVE-2024-27002" title="CVE-2024-27002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27072" id="CVE-2024-27072" title="CVE-2024-27072" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27395" id="CVE-2024-27395" title="CVE-2024-27395" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27396" id="CVE-2024-27396" title="CVE-2024-27396" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27398" id="CVE-2024-27398" title="CVE-2024-27398" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27401" id="CVE-2024-27401" title="CVE-2024-27401" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27407" id="CVE-2024-27407" title="CVE-2024-27407" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27419" id="CVE-2024-27419" title="CVE-2024-27419" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27426" id="CVE-2024-27426" title="CVE-2024-27426" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27427" id="CVE-2024-27427" title="CVE-2024-27427" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27431" id="CVE-2024-27431" title="CVE-2024-27431" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34459" id="CVE-2024-34459" title="CVE-2024-34459" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35791" id="CVE-2024-35791" title="CVE-2024-35791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35801" id="CVE-2024-35801" title="CVE-2024-35801" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35805" id="CVE-2024-35805" title="CVE-2024-35805" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35806" id="CVE-2024-35806" title="CVE-2024-35806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35807" id="CVE-2024-35807" title="CVE-2024-35807" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35818" id="CVE-2024-35818" title="CVE-2024-35818" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35835" id="CVE-2024-35835" title="CVE-2024-35835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35844" id="CVE-2024-35844" title="CVE-2024-35844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35845" id="CVE-2024-35845" title="CVE-2024-35845" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35848" id="CVE-2024-35848" title="CVE-2024-35848" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35849" id="CVE-2024-35849" title="CVE-2024-35849" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35898" id="CVE-2024-35898" title="CVE-2024-35898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35922" id="CVE-2024-35922" title="CVE-2024-35922" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35934" id="CVE-2024-35934" title="CVE-2024-35934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35936" id="CVE-2024-35936" title="CVE-2024-35936" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35938" id="CVE-2024-35938" title="CVE-2024-35938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35940" id="CVE-2024-35940" title="CVE-2024-35940" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35943" id="CVE-2024-35943" title="CVE-2024-35943" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35997" id="CVE-2024-35997" title="CVE-2024-35997" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36006" id="CVE-2024-36006" title="CVE-2024-36006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36039" id="CVE-2024-36039" title="CVE-2024-36039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4853" id="CVE-2024-4853" title="CVE-2024-4853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4855" id="CVE-2024-4855" title="CVE-2024-4855" type="cve"></reference>
		</references>
		<description>CVE-2021-47193:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: pm80xx: Fix memory leak during rmmod&#xA;Driver failed to release all memory allocated. This would lead to memory&#xA;leak during driver removal.&#xA;Properly free memory when the module is removed.&#xA;CVE-2021-47199:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: CT, Fix multiple allocations and memleak of mod acts&#xA;CT clear action offload adds additional mod hdr actions to the&#xA;flow&#39;s original mod actions in order to clear the registers which&#xA;hold ct_state.&#xA;When such flow also includes encap action, a neigh update event&#xA;can cause the driver to unoffload the flow and then reoffload it.&#xA;Each time this happens, the ct clear handling adds that same set&#xA;of mod hdr actions to reset ct_state until the max of mod hdr&#xA;actions is reached.&#xA;Also the driver never releases the allocated mod hdr actions and&#xA;causing a memleak.&#xA;Fix above two issues by moving CT clear mod acts allocation&#xA;into the parsing actions phase and only use it when offloading the rule.&#xA;The release of mod acts will be done in the normal flow_put().&#xA; backtrace:&#xA;    [&lt;000000007316e2f3&gt;] krealloc+0x83/0xd0&#xA;    [&lt;00000000ef157de1&gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]&#xA;    [&lt;00000000970ce4ae&gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]&#xA;    [&lt;0000000067c5fa17&gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]&#xA;    [&lt;00000000d032eb98&gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]&#xA;    [&lt;00000000fd23b869&gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]&#xA;    [&lt;000000004fc24acc&gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]&#xA;    [&lt;00000000dc741c17&gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]&#xA;    [&lt;00000000e92e49d7&gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]&#xA;    [&lt;00000000f60f5602&gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]&#xA;CVE-2022-48645:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: enetc: deny offload of tc-based TSN features on VF interfaces&#xA;TSN features on the ENETC (taprio, cbs, gate, police) are configured&#xA;through a mix of command BD ring messages and port registers:&#xA;enetc_port_rd(), enetc_port_wr().&#xA;Port registers are a region of the ENETC memory map which are only&#xA;accessible from the PCIe Physical Function. They are not accessible from&#xA;the Virtual Functions.&#xA;Moreover, attempting to access these registers crashes the kernel:&#xA;$ echo 1 &gt; /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs&#xA;pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001&#xA;fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15&#xA;fsl_enetc_vf 0000:00:01.0: enabling device (0000 -&gt; 0002)&#xA;fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0&#xA;$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \&#xA;&#x9;queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \&#xA;&#x9;sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2&#xA;Unable to handle kernel paging request at virtual address ffff800009551a08&#xA;Internal error: Oops: 96000007 [#1] PREEMPT SMP&#xA;pc : enetc_setup_tc_taprio+0x170/0x47c&#xA;lr : enetc_setup_tc_taprio+0x16c/0x47c&#xA;Call trace:&#xA; enetc_setup_tc_taprio+0x170/0x47c&#xA; enetc_setup_tc+0x38/0x2dc&#xA; taprio_change+0x43c/0x970&#xA; taprio_init+0x188/0x1e0&#xA; qdisc_create+0x114/0x470&#xA; tc_modify_qdisc+0x1fc/0x6c0&#xA; rtnetlink_rcv_msg+0x12c/0x390&#xA;Split enetc_setup_tc() into separate functions for the PF and for the&#xA;VF drivers. Also remove enetc_qos.o from being included into&#xA;enetc-vf.ko, since it serves absolutely no purpose there.&#xA;CVE-2022-48673:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/smc: Fix possible access to freed memory in link clear&#xA;After modifying the QP to the Error state, all RX WR would be completed&#xA;with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not&#xA;wait for it is done, but destroy the QP and free the link group directly.&#xA;So there is a risk that accessing the freed memory in tasklet context.&#xA;Here is a crash example:&#xA; BUG: unable to handle page fault for address: ffffffff8f220860&#xA; #PF: supervisor write access in kernel mode&#xA; #PF: error_code(0x0002) - not-present page&#xA; PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060&#xA; Oops: 0002 [#1] SMP PTI&#xA; CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23&#xA; Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018&#xA; RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0&#xA; Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &lt;48&gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32&#xA; RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086&#xA; RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000&#xA; RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00&#xA; RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b&#xA; R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010&#xA; R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040&#xA; FS:  0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; Call Trace:&#xA;  &lt;IRQ&gt;&#xA;  _raw_spin_lock_irqsave+0x30/0x40&#xA;  mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]&#xA;  smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]&#xA;  tasklet_action_common.isra.21+0x66/0x100&#xA;  __do_softirq+0xd5/0x29c&#xA;  asm_call_irq_on_stack+0x12/0x20&#xA;  &lt;/IRQ&gt;&#xA;  do_softirq_own_stack+0x37/0x40&#xA;  irq_exit_rcu+0x9d/0xa0&#xA;  sysvec_call_function_single+0x34/0x80&#xA;  asm_sysvec_call_function_single+0x12/0x20&#xA;CVE-2022-48674:In the Linux kernel, the following vulnerability has been resolved:&#xA;erofs: fix pcluster use-after-free on UP platforms&#xA;During stress testing with CONFIG_SMP disabled, KASAN reports as below: ==================================================================&#xA;BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30&#xA;Read of size 8 at addr ffff8881094223f8 by task stress/7789&#xA;CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3&#xA;Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;..&#xA; __mutex_lock+0xe5/0xc30&#xA;..&#xA; z_erofs_do_read_page+0x8ce/0x1560&#xA;..&#xA; z_erofs_readahead+0x31c/0x580&#xA;..&#xA;Freed by task 7787&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_set_track+0x20/0x30&#xA; kasan_set_free_info+0x20/0x40&#xA; __kasan_slab_free+0x10c/0x190&#xA; kmem_cache_free+0xed/0x380&#xA; rcu_core+0x3d5/0xc90&#xA; __do_softirq+0x12d/0x389&#xA;Last potentially related work creation:&#xA; kasan_save_stack+0x1e/0x40&#xA; __kasan_record_aux_stack+0x97/0xb0&#xA; call_rcu+0x3d/0x3f0&#xA; erofs_shrink_workstation+0x11f/0x210&#xA; erofs_shrink_scan+0xdc/0x170&#xA; shrink_slab.constprop.0+0x296/0x530&#xA; drop_slab+0x1c/0x70&#xA; drop_caches_sysctl_handler+0x70/0x80&#xA; proc_sys_call_handler+0x20a/0x2f0&#xA; vfs_write+0x555/0x6c0&#xA; ksys_write+0xbe/0x160&#xA; do_syscall_64+0x3b/0x90&#xA;The root cause is that erofs_workgroup_unfreeze() doesn&#39;t reset to&#xA;orig_val thus it causes a race that the pcluster reuses unexpectedly&#xA;before freeing.&#xA;Since UP platforms are quite rare now, such path becomes unnecessary.&#xA;Let&#39;s drop such specific-designed path directly instead.&#xA;CVE-2022-48703:In the Linux kernel, the following vulnerability has been resolved:&#xA;thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR&#xA;In some case, the GDDV returns a package with a buffer which has&#xA;zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).&#xA;Then the data_vault_read() got NULL point dereference problem when&#xA;accessing the 0x10 value in data_vault.&#xA;[   71.024560] BUG: kernel NULL pointer dereference, address:&#xA;0000000000000010&#xA;This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or&#xA;NULL value in data_vault.&#xA;CVE-2023-52434:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix potential OOBs in smb2_parse_contexts()&#xA;Validate offsets and lengths before dereferencing create contexts in&#xA;smb2_parse_contexts().&#xA;This fixes following oops when accessing invalid create contexts from&#xA;server:&#xA;  BUG: unable to handle page fault for address: ffff8881178d8cc3&#xA;  #PF: supervisor read access in kernel mode&#xA;  #PF: error_code(0x0000) - not-present page&#xA;  PGD 4a01067 P4D 4a01067 PUD 0&#xA;  Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;  CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1&#xA;  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS&#xA;  rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014&#xA;  RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]&#xA;  Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00&#xA;  00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 &lt;0f&gt; b7&#xA;  7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00&#xA;  RSP: 0018:ffffc900007939e0 EFLAGS: 00010216&#xA;  RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90&#xA;  RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000&#xA;  RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000&#xA;  R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000&#xA;  R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22&#xA;  FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)&#xA;  knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0&#xA;  PKRU: 55555554&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? __die+0x23/0x70&#xA;   ? page_fault_oops+0x181/0x480&#xA;   ? search_module_extables+0x19/0x60&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? exc_page_fault+0x1b6/0x1c0&#xA;   ? asm_exc_page_fault+0x26/0x30&#xA;   ? smb2_parse_contexts+0xa0/0x3a0 [cifs]&#xA;   SMB2_open+0x38d/0x5f0 [cifs]&#xA;   ? smb2_is_path_accessible+0x138/0x260 [cifs]&#xA;   smb2_is_path_accessible+0x138/0x260 [cifs]&#xA;   cifs_is_path_remote+0x8d/0x230 [cifs]&#xA;   cifs_mount+0x7e/0x350 [cifs]&#xA;   cifs_smb3_do_mount+0x128/0x780 [cifs]&#xA;   smb3_get_tree+0xd9/0x290 [cifs]&#xA;   vfs_get_tree+0x2c/0x100&#xA;   ? capable+0x37/0x70&#xA;   path_mount+0x2d7/0xb80&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? _raw_spin_unlock_irqrestore+0x44/0x60&#xA;   __x64_sys_mount+0x11a/0x150&#xA;   do_syscall_64+0x47/0xf0&#xA;   entry_SYSCALL_64_after_hwframe+0x6f/0x77&#xA;  RIP: 0033:0x7f8737657b1e&#xA;CVE-2023-52444:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to avoid dirent corruption&#xA;As Al reported in link[1]:&#xA;f2fs_rename()&#xA;...&#xA;&#x9;if (old_dir != new_dir &amp;&amp; !whiteout)&#xA;&#x9;&#x9;f2fs_set_link(old_inode, old_dir_entry,&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;old_dir_page, new_dir);&#xA;&#x9;else&#xA;&#x9;&#x9;f2fs_put_page(old_dir_page, 0);&#xA;You want correct inumber in the &#34;..&#34; link.  And cross-directory&#xA;rename does move the source to new parent, even if you&#39;d been asked&#xA;to leave a whiteout in the old place.&#xA;[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&#xA;With below testcase, it may cause dirent corruption, due to it missed&#xA;to call f2fs_set_link() to update &#34;..&#34; link to new directory.&#xA;- mkdir -p dir/foo&#xA;- renameat2 -w dir/foo bar&#xA;[ASSERT] (__chk_dots_dentries:1421)  --&gt; Bad inode number[0x4] for &#39;..&#39;, parent parent ino is [0x3]&#xA;[FSCK] other corrupted bugs                           [Fail]&#xA;CVE-2023-52457:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: 8250: omap: Don&#39;t skip resource freeing if pm_runtime_resume_and_get() failed&#xA;Returning an error code from .remove() makes the driver core emit the&#xA;little helpful error message:&#xA;&#x9;remove callback returned a non-zero value. This will be ignored.&#xA;and then remove the device anyhow. So all resources that were not freed&#xA;are leaked in this case. Skipping serial8250_unregister_port() has the&#xA;potential to keep enough of the UART around to trigger a use-after-free.&#xA;So replace the error return (and with it the little helpful error&#xA;message) by a more useful error message and continue to cleanup.&#xA;CVE-2023-52610:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: act_ct: fix skb leak and crash on ooo frags&#xA;act_ct adds skb-&gt;users before defragmentation. If frags arrive in order,&#xA;the last frag&#39;s reference is reset in:&#xA;  inet_frag_reasm_prepare&#xA;    skb_morph&#xA;which is not straightforward.&#xA;However when frags arrive out of order, nobody unref the last frag, and&#xA;all frags are leaked. The situation is even worse, as initiating packet&#xA;capture can lead to a crash[0] when skb has been cloned and shared at the&#xA;same time.&#xA;Fix the issue by removing skb_get() before defragmentation. act_ct&#xA;returns TC_ACT_CONSUMED when defrag failed or in progress.&#xA;[0]:&#xA;[  843.804823] ------------[ cut here ]------------&#xA;[  843.809659] kernel BUG at net/core/skbuff.c:2091!&#xA;[  843.814516] invalid opcode: 0000 [#1] PREEMPT SMP&#xA;[  843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2&#xA;[  843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022&#xA;[  843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300&#xA;[  843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b &lt;0f&gt; 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89&#xA;[  843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202&#xA;[  843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820&#xA;[  843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00&#xA;[  843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000&#xA;[  843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880&#xA;[  843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900&#xA;[  843.871680] FS:  0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000&#xA;[  843.876242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0&#xA;[  843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  843.894229] PKRU: 55555554&#xA;[  843.898539] Call Trace:&#xA;[  843.902772]  &lt;IRQ&gt;&#xA;[  843.906922]  ? __die_body+0x1e/0x60&#xA;[  843.911032]  ? die+0x3c/0x60&#xA;[  843.915037]  ? do_trap+0xe2/0x110&#xA;[  843.918911]  ? pskb_expand_head+0x2ac/0x300&#xA;[  843.922687]  ? do_error_trap+0x65/0x80&#xA;[  843.926342]  ? pskb_expand_head+0x2ac/0x300&#xA;[  843.929905]  ? exc_invalid_op+0x50/0x60&#xA;[  843.933398]  ? pskb_expand_head+0x2ac/0x300&#xA;[  843.936835]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[  843.940226]  ? pskb_expand_head+0x2ac/0x300&#xA;[  843.943580]  inet_frag_reasm_prepare+0xd1/0x240&#xA;[  843.946904]  ip_defrag+0x5d4/0x870&#xA;[  843.950132]  nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]&#xA;[  843.953334]  tcf_ct_act+0x252/0xd90 [act_ct]&#xA;[  843.956473]  ? tcf_mirred_act+0x516/0x5a0 [act_mirred]&#xA;[  843.959657]  tcf_action_exec+0xa1/0x160&#xA;[  843.962823]  fl_classify+0x1db/0x1f0 [cls_flower]&#xA;[  843.966010]  ? skb_clone+0x53/0xc0&#xA;[  843.969173]  tcf_classify+0x24d/0x420&#xA;[  843.972333]  tc_run+0x8f/0xf0&#xA;[  843.975465]  __netif_receive_skb_core+0x67a/0x1080&#xA;[  843.978634]  ? dev_gro_receive+0x249/0x730&#xA;[  843.981759]  __netif_receive_skb_list_core+0x12d/0x260&#xA;[  843.984869]  netif_receive_skb_list_internal+0x1cb/0x2f0&#xA;[  843.987957]  ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]&#xA;[  843.991170]  napi_complete_done+0x72/0x1a0&#xA;[  843.994305]  mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]&#xA;[  843.997501]  __napi_poll+0x25/0x1b0&#xA;[  844.000627]  net_rx_action+0x256/0x330&#xA;[  844.003705]  __do_softirq+0xb3/0x29b&#xA;[  844.006718]  irq_exit_rcu+0x9e/0xc0&#xA;[  844.009672]  common_interrupt+0x86/0xa0&#xA;[  844.012537]  &lt;/IRQ&gt;&#xA;[  844.015285]  &lt;TASK&gt;&#xA;[  844.017937]  asm_common_interrupt+0x26/0x40&#xA;[  844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20&#xA;[  844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb&#xA;---truncated---&#xA;CVE-2023-52612:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: scomp - fix req-&gt;dst buffer overflow&#xA;The req-&gt;dst buffer size should be checked before copying from the&#xA;scomp_scratch-&gt;dst to avoid req-&gt;dst buffer overflow problem.&#xA;CVE-2023-52614:In the Linux kernel, the following vulnerability has been resolved:&#xA;PM / devfreq: Fix buffer overflow in trans_stat_show&#xA;Fix buffer overflow in trans_stat_show().&#xA;Convert simple snprintf to the more secure scnprintf with size of&#xA;PAGE_SIZE.&#xA;Add condition checking if we are exceeding PAGE_SIZE and exit early from&#xA;loop. Also add at the end a warning that we exceeded PAGE_SIZE and that&#xA;stats is disabled.&#xA;Return -EFBIG in the case where we don&#39;t have enough space to write the&#xA;full transition table.&#xA;Also document in the ABI that this function can return -EFBIG error.&#xA;CVE-2023-52627:In the Linux kernel, the following vulnerability has been resolved:&#xA;iio: adc: ad7091r: Allow users to configure device events&#xA;AD7091R-5 devices are supported by the ad7091r-5 driver together with&#xA;the ad7091r-base driver. Those drivers declared iio events for notifying&#xA;user space when ADC readings fall bellow the thresholds of low limit&#xA;registers or above the values set in high limit registers.&#xA;However, to configure iio events and their thresholds, a set of callback&#xA;functions must be implemented and those were not present until now.&#xA;The consequence of trying to configure ad7091r-5 events without the&#xA;proper callback functions was a null pointer dereference in the kernel&#xA;because the pointers to the callback functions were not set.&#xA;Implement event configuration callbacks allowing users to read/write&#xA;event thresholds and enable/disable event generation.&#xA;Since the event spec structs are generic to AD7091R devices, also move&#xA;those from the ad7091r-5 driver the base driver so they can be reused&#xA;when support for ad7091r-2/-4/-8 be added.&#xA;CVE-2023-52646:In the Linux kernel, the following vulnerability has been resolved:&#xA;aio: fix mremap after fork null-deref&#xA;Commit e4a0d3e720e7 (&#34;aio: Make it possible to remap aio ring&#34;) introduced&#xA;a null-deref if mremap is called on an old aio mapping after fork as&#xA;mm-&gt;ioctx_table will be set to NULL.&#xA;[jmoyer@redhat.com: fix 80 column issue]&#xA;CVE-2023-52652:In the Linux kernel, the following vulnerability has been resolved:&#xA;NTB: fix possible name leak in ntb_register_device()&#xA;If device_register() fails in ntb_register_device(), the device name&#xA;allocated by dev_set_name() should be freed. As per the comment in&#xA;device_register(), callers should use put_device() to give up the&#xA;reference in the error path. So fix this by calling put_device() in the&#xA;error path so that the name can be freed in kobject_cleanup().&#xA;As a result of this, put_device() in the error path of&#xA;ntb_register_device() is removed and the actual error is returned.&#xA;[mani: reworded commit message]&#xA;CVE-2023-52686:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/powernv: Add a null pointer check in opal_event_init()&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure.&#xA;CVE-2023-52753:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Avoid NULL dereference of timing generator&#xA;[Why &amp; How]&#xA;Check whether assigned timing generator is NULL or not before&#xA;accessing its funcs to prevent NULL dereference.&#xA;CVE-2023-52802:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2023-52806:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: hda: Fix possible null-ptr-deref when assigning a stream&#xA;While AudioDSP drivers assign streams exclusively of HOST or LINK type,&#xA;nothing blocks a user to attempt to assign a COUPLED stream. As&#xA;supplied substream instance may be a stub, what is the case when&#xA;code-loading, such scenario ends with null-ptr-deref.&#xA;CVE-2023-52814:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix potential null pointer derefernce&#xA;The amdgpu_ras_get_context may return NULL if device&#xA;not support ras feature, so add check before using.&#xA;CVE-2023-52817:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL&#xA;In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:&#xA;1. Navigate to the directory: /sys/kernel/debug/dri/0&#xA;2. Execute command: cat amdgpu_regs_smc&#xA;3. Exception Log::&#xA;[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[4005007.702562] #PF: supervisor instruction fetch in kernel mode&#xA;[4005007.702567] #PF: error_code(0x0010) - not-present page&#xA;[4005007.702570] PGD 0 P4D 0&#xA;[4005007.702576] Oops: 0010 [#1] SMP NOPTI&#xA;[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G           OE     5.15.0-43-generic #46-Ubunt       u&#xA;[4005007.702590] RIP: 0010:0x0&#xA;[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.&#xA;[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206&#xA;[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68&#xA;[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000&#xA;[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980&#xA;[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000&#xA;[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000&#xA;[4005007.702622] FS:  00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000&#xA;[4005007.702626] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0&#xA;[4005007.702633] Call Trace:&#xA;[4005007.702636]  &lt;TASK&gt;&#xA;[4005007.702640]  amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]&#xA;[4005007.703002]  full_proxy_read+0x5c/0x80&#xA;[4005007.703011]  vfs_read+0x9f/0x1a0&#xA;[4005007.703019]  ksys_read+0x67/0xe0&#xA;[4005007.703023]  __x64_sys_read+0x19/0x20&#xA;[4005007.703028]  do_syscall_64+0x5c/0xc0&#xA;[4005007.703034]  ? do_user_addr_fault+0x1e3/0x670&#xA;[4005007.703040]  ? exit_to_user_mode_prepare+0x37/0xb0&#xA;[4005007.703047]  ? irqentry_exit_to_user_mode+0x9/0x20&#xA;[4005007.703052]  ? irqentry_exit+0x19/0x30&#xA;[4005007.703057]  ? exc_page_fault+0x89/0x160&#xA;[4005007.703062]  ? asm_exc_page_fault+0x8/0x30&#xA;[4005007.703068]  entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;[4005007.703075] RIP: 0033:0x7f5e07672992&#xA;[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f        1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e       c 28 48 89 54 24&#xA;[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000&#xA;[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992&#xA;[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003&#xA;[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010&#xA;[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000&#xA;[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000&#xA;[4005007.703105]  &lt;/TASK&gt;&#xA;[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_       iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t       tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm       i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo       mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v       2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core        drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca&#xA;[4005007.703184] CR2: 0000000000000000&#xA;[4005007.703188] ---[ en&#xA;---truncated---&#xA;CVE-2023-52821:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/panel: fix a possible null pointer dereference&#xA;In versatile_panel_get_modes(), the return value of drm_mode_duplicate()&#xA;is assigned to mode, which will lead to a NULL pointer dereference&#xA;on failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2023-52843:In the Linux kernel, the following vulnerability has been resolved:&#xA;llc: verify mac len before reading mac header&#xA;LLC reads the mac header with eth_hdr without verifying that the skb&#xA;has an Ethernet header.&#xA;Syzbot was able to enter llc_rcv on a tun device. Tun can insert&#xA;packets without mac len and with user configurable skb-&gt;protocol&#xA;(passing a tun_pi header when not configuring IFF_NO_PI).&#xA;    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]&#xA;    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111&#xA;    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]&#xA;    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111&#xA;    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218&#xA;    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]&#xA;    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637&#xA;    netif_receive_skb_internal net/core/dev.c:5723 [inline]&#xA;    netif_receive_skb+0x58/0x660 net/core/dev.c:5782&#xA;    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555&#xA;    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002&#xA;Add a mac_len test before all three eth_hdr(skb) calls under net/llc.&#xA;There are further uses in include/net/llc_pdu.h. All these are&#xA;protected by a test skb-&gt;protocol == ETH_P_802_2. Which does not&#xA;protect against this tun scenario.&#xA;But the mac_len test added in this patch in llc_fixup_skb will&#xA;indirectly protect those too. That is called from llc_rcv before any&#xA;other LLC code.&#xA;It is tempting to just add a blanket mac_len check in llc_rcv, but&#xA;not sure whether that could break valid LLC paths that do not assume&#xA;an Ethernet header. 802.2 LLC may be used on top of non-802.3&#xA;protocols in principle. The below referenced commit shows that used&#xA;to, on top of Token Ring.&#xA;At least one of the three eth_hdr uses goes back to before the start&#xA;of git history. But the one that syzbot exercises is introduced in&#xA;this commit. That commit is old enough (2008), that effectively all&#xA;stable kernels should receive this.&#xA;CVE-2023-52845:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING&#xA;syzbot reported the following uninit-value access issue [1]: =====================================================&#xA;BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]&#xA;BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756&#xA; strlen lib/string.c:418 [inline]&#xA; strstr+0xb8/0x2f0 lib/string.c:756&#xA; tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595&#xA; genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]&#xA; genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]&#xA; genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066&#xA; netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545&#xA; genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]&#xA; netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368&#xA; netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; sock_sendmsg net/socket.c:753 [inline]&#xA; ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595&#xA; __sys_sendmsg net/socket.c:2624 [inline]&#xA; __do_sys_sendmsg net/socket.c:2633 [inline]&#xA; __se_sys_sendmsg net/socket.c:2631 [inline]&#xA; __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;Uninit was created at:&#xA; slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767&#xA; slab_alloc_node mm/slub.c:3478 [inline]&#xA; kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523&#xA; kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559&#xA; __alloc_skb+0x318/0x740 net/core/skbuff.c:650&#xA; alloc_skb include/linux/skbuff.h:1286 [inline]&#xA; netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]&#xA; netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; sock_sendmsg net/socket.c:753 [inline]&#xA; ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595&#xA; __sys_sendmsg net/socket.c:2624 [inline]&#xA; __do_sys_sendmsg net/socket.c:2633 [inline]&#xA; __se_sys_sendmsg net/socket.c:2631 [inline]&#xA; __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;TIPC bearer-related names including link names must be null-terminated&#xA;strings. If a link name which is not null-terminated is passed through&#xA;netlink, strstr() and similar functions can cause buffer overrun. This&#xA;causes the above issue.&#xA;This patch changes the nla_policy for bearer-related names from NLA_STRING&#xA;to NLA_NUL_STRING. This resolves the issue by ensuring that only&#xA;null-terminated strings are accepted as bearer-related names.&#xA;syzbot reported similar uninit-value issue related to bearer names [2]. The&#xA;root cause of this issue is that a non-null-terminated bearer name was&#xA;passed. This patch also resolved this issue.&#xA;CVE-2023-52846:In the Linux kernel, the following vulnerability has been resolved:&#xA;hsr: Prevent use after free in prp_create_tagged_frame()&#xA;The prp_fill_rct() function can fail.  In that situation, it frees the&#xA;skb and returns NULL.  Meanwhile on the success path, it returns the&#xA;original skb.  So it&#39;s straight forward to fix bug by using the returned&#xA;value.&#xA;CVE-2023-52853:In the Linux kernel, the following vulnerability has been resolved:&#xA;hid: cp2112: Fix duplicate workqueue initialization&#xA;Previously the cp2112 driver called INIT_DELAYED_WORK within&#xA;cp2112_gpio_irq_startup, resulting in duplicate initilizations of the&#xA;workqueue on subsequent IRQ startups following an initial request. This&#xA;resulted in a warning in set_work_data in workqueue.c, as well as a rare&#xA;NULL dereference within process_one_work in workqueue.c.&#xA;Initialize the workqueue within _probe instead.&#xA;CVE-2023-52855:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency&#xA;In _dwc2_hcd_urb_enqueue(), &#34;urb-&gt;hcpriv = NULL&#34; is executed without&#xA;holding the lock &#34;hsotg-&gt;lock&#34;. In _dwc2_hcd_urb_dequeue():&#xA;    spin_lock_irqsave(&amp;hsotg-&gt;lock, flags);&#xA;    ...&#xA;&#x9;if (!urb-&gt;hcpriv) {&#xA;&#x9;&#x9;dev_dbg(hsotg-&gt;dev, &#34;## urb-&gt;hcpriv is NULL ##\n&#34;);&#xA;&#x9;&#x9;goto out;&#xA;&#x9;}&#xA;    rc = dwc2_hcd_urb_dequeue(hsotg, urb-&gt;hcpriv); // Use urb-&gt;hcpriv&#xA;    ...&#xA;out:&#xA;    spin_unlock_irqrestore(&amp;hsotg-&gt;lock, flags);&#xA;When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are&#xA;concurrently executed, the NULL check of &#34;urb-&gt;hcpriv&#34; can be executed&#xA;before &#34;urb-&gt;hcpriv = NULL&#34;. After urb-&gt;hcpriv is NULL, it can be used&#xA;in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL&#xA;pointer dereference.&#xA;This possible bug is found by an experimental static analysis tool&#xA;developed by myself. This tool analyzes the locking APIs to extract&#xA;function pairs that can be concurrently executed, and then analyzes the&#xA;instructions in the paired functions to identify possible concurrency&#xA;bugs including data races and atomicity violations. The above possible&#xA;bug is reported, when my tool analyzes the source code of Linux 6.5.&#xA;To fix this possible bug, &#34;urb-&gt;hcpriv = NULL&#34; should be executed with&#xA;holding the lock &#34;hsotg-&gt;lock&#34;. After using this patch, my tool never&#xA;reports the possible bug, with the kernelconfiguration allyesconfig for&#xA;x86_64. Because I have no associated hardware, I cannot test the patch&#xA;in runtime testing, and just verify it according to the code logic.&#xA;CVE-2023-52858:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data&#xA;Add the check for the return value of mtk_alloc_clk_data() in order to&#xA;avoid NULL pointer dereference.&#xA;CVE-2023-52864:In the Linux kernel, the following vulnerability has been resolved:&#xA;platform/x86: wmi: Fix opening of char device&#xA;Since commit fa1f68db6ca7 (&#34;drivers: misc: pass miscdevice pointer via&#xA;file private data&#34;), the miscdevice stores a pointer to itself inside&#xA;filp-&gt;private_data, which means that private_data will not be NULL when&#xA;wmi_char_open() is called. This might cause memory corruption should&#xA;wmi_char_open() be unable to find its driver, something which can&#xA;happen when the associated WMI device is deleted in wmi_free_devices().&#xA;Fix the problem by using the miscdevice pointer to retrieve the WMI&#xA;device data associated with a char device using container_of(). This&#xA;also avoids wmi_char_open() picking a wrong WMI device bound to a&#xA;driver with the same name as the original driver.&#xA;CVE-2023-52865:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data&#xA;Add the check for the return value of mtk_alloc_clk_data() in order to&#xA;avoid NULL pointer dereference.&#xA;CVE-2023-52868:In the Linux kernel, the following vulnerability has been resolved:&#xA;thermal: core: prevent potential string overflow&#xA;The dev-&gt;id value comes from ida_alloc() so it&#39;s a number between zero&#xA;and INT_MAX.  If it&#39;s too high then these sprintf()s will overflow.&#xA;CVE-2023-52871:In the Linux kernel, the following vulnerability has been resolved:&#xA;soc: qcom: llcc: Handle a second device without data corruption&#xA;Usually there is only one llcc device. But if there were a second, even&#xA;a failed probe call would modify the global drv_data pointer. So check&#xA;if drv_data is valid before overwriting it.&#xA;CVE-2023-52873:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data&#xA;Add the check for the return value of mtk_alloc_clk_data() in order to&#xA;avoid NULL pointer dereference.&#xA;CVE-2023-52875:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data&#xA;Add the check for the return value of mtk_alloc_clk_data() in order to&#xA;avoid NULL pointer dereference.&#xA;CVE-2023-52876:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data&#xA;Add the check for the return value of mtk_alloc_clk_data() in order to&#xA;avoid NULL pointer dereference.&#xA;CVE-2024-24855:A race condition was found in the Linux kernel&#39;s scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.&#xA;CVE-2024-26594:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: validate mech token in session setup&#xA;If client send invalid mech token in session setup request, ksmbd&#xA;validate and make the error if it is invalid.&#xA;CVE-2024-26602:In the Linux kernel, the following vulnerability has been resolved:&#xA;sched/membarrier: reduce the ability to hammer on sys_membarrier&#xA;On some systems, sys_membarrier can be very expensive, causing overall&#xA;slowdowns for everything.  So put a lock on the path in order to&#xA;serialize the accesses to prevent the ability for this to be called at&#xA;too high of a frequency and saturate the machine.&#xA;CVE-2024-26663:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()&#xA;syzbot reported the following general protection fault [1]:&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN&#xA;KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]&#xA;...&#xA;RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646&#xA; tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089&#xA; genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972&#xA; genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]&#xA; genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067&#xA; netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544&#xA; genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]&#xA; netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367&#xA; netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0xd5/0x180 net/socket.c:745&#xA; ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584&#xA; ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638&#xA; __sys_sendmsg+0x117/0x1e0 net/socket.c:2667&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;The cause of this issue is that when tipc_nl_bearer_add() is called with&#xA;the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called&#xA;even if the bearer is not UDP.&#xA;tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that&#xA;the media_ptr field of the tipc_bearer has an udp_bearer type object, so&#xA;the function goes crazy for non-UDP bearers.&#xA;This patch fixes the issue by checking the bearer type before calling&#xA;tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().&#xA;CVE-2024-26673:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations&#xA;- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.&#xA;- Disallow layer 4 protocol with no ports, since destination port is a&#xA;  mandatory attribute for this object.&#xA;CVE-2024-26813:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfio/platform: Create persistent IRQ handlers&#xA;The vfio-platform SET_IRQS ioctl currently allows loopback triggering of&#xA;an interrupt before a signaling eventfd has been configured by the user,&#xA;which thereby allows a NULL pointer dereference.&#xA;Rather than register the IRQ relative to a valid trigger, register all&#xA;IRQs in a disabled state in the device open path.  This allows mask&#xA;operations on the IRQ to nest within the overall enable state governed&#xA;by a valid eventfd signal.  This decouples @masked, protected by the&#xA;@locked spinlock from @trigger, protected via the @igate mutex.&#xA;In doing so, it&#39;s guaranteed that changes to @trigger cannot race the&#xA;IRQ handlers because the IRQ handler is synchronously disabled before&#xA;modifying the trigger, and loopback triggering of the IRQ via ioctl is&#xA;safe due to serialization with trigger changes via igate.&#xA;For compatibility, request_irq() failures are maintained to be local to&#xA;the SET_IRQS ioctl rather than a fatal error in the open device path.&#xA;This allows, for example, a userspace driver with polling mode support&#xA;to continue to work regardless of moving the request_irq() call site.&#xA;This necessarily blocks all SET_IRQS access to the failed index.&#xA;CVE-2024-26825:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: nci: free rx_data_reassembly skb on NCI device cleanup&#xA;rx_data_reassembly skb is stored during NCI data exchange for processing&#xA;fragmented packets. It is dropped only when the last fragment is processed&#xA;or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.&#xA;However, the NCI device may be deallocated before that which leads to skb&#xA;leak.&#xA;As by design the rx_data_reassembly skb is bound to the NCI device and&#xA;nothing prevents the device to be freed before the skb is processed in&#xA;some way and cleaned, free it on the NCI device cleanup.&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2024-26829:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: ir_toy: fix a memleak in irtoy_tx&#xA;When irtoy_command fails, buf should be freed since it is allocated by&#xA;irtoy_tx, or there is a memleak.&#xA;CVE-2024-26830:In the Linux kernel, the following vulnerability has been resolved:&#xA;i40e: Do not allow untrusted VF to remove administratively set MAC&#xA;Currently when PF administratively sets VF&#39;s MAC address and the VF&#xA;is put down (VF tries to delete all MACs) then the MAC is removed&#xA;from MAC filters and primary VF MAC is zeroed.&#xA;Do not allow untrusted VF to remove primary MAC when it was set&#xA;administratively by PF.&#xA;Reproducer:&#xA;1) Create VF&#xA;2) Set VF interface up&#xA;3) Administratively set the VF&#39;s MAC&#xA;4) Put VF interface down&#xA;[root@host ~]# echo 1 &gt; /sys/class/net/enp2s0f0/device/sriov_numvfs&#xA;[root@host ~]# ip link set enp2s0f0v0 up&#xA;[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d&#xA;[root@host ~]# ip link show enp2s0f0&#xA;23: enp2s0f0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000&#xA;    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff&#xA;    vf 0     link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off&#xA;[root@host ~]# ip link set enp2s0f0v0 down&#xA;[root@host ~]# ip link show enp2s0f0&#xA;23: enp2s0f0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000&#xA;    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff&#xA;    vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off&#xA;CVE-2024-26857:In the Linux kernel, the following vulnerability has been resolved:&#xA;geneve: make sure to pull inner header in geneve_rx()&#xA;syzbot triggered a bug in geneve_rx() [1]&#xA;Issue is similar to the one I fixed in commit 8d975c15c0cd&#xA;(&#34;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()&#34;)&#xA;We have to save skb-&gt;network_header in a temporary variable&#xA;in order to be able to recompute the network_header pointer&#xA;after a pskb_inet_may_pull() call.&#xA;pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.&#xA;[1]&#xA;BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]&#xA; BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]&#xA; BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391&#xA;  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]&#xA;  geneve_rx drivers/net/geneve.c:279 [inline]&#xA;  geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391&#xA;  udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108&#xA;  udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186&#xA;  udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346&#xA;  __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422&#xA;  udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604&#xA;  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205&#xA;  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254&#xA;  dst_input include/net/dst.h:461 [inline]&#xA;  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569&#xA;  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]&#xA;  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648&#xA;  process_backlog+0x480/0x8b0 net/core/dev.c:5976&#xA;  __napi_poll+0xe3/0x980 net/core/dev.c:6576&#xA;  napi_poll net/core/dev.c:6645 [inline]&#xA;  net_rx_action+0x8b8/0x1870 net/core/dev.c:6778&#xA;  __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553&#xA;  do_softirq+0x9a/0xf0 kernel/softirq.c:454&#xA;  __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381&#xA;  local_bh_enable include/linux/bottom_half.h:33 [inline]&#xA;  rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]&#xA;  __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378&#xA;  dev_queue_xmit include/linux/netdevice.h:3171 [inline]&#xA;  packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276&#xA;  packet_snd net/packet/af_packet.c:3081 [inline]&#xA;  packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg net/socket.c:745 [inline]&#xA;  __sys_sendto+0x735/0xa10 net/socket.c:2191&#xA;  __do_sys_sendto net/socket.c:2203 [inline]&#xA;  __se_sys_sendto net/socket.c:2199 [inline]&#xA;  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:3819 [inline]&#xA;  slab_alloc_node mm/slub.c:3860 [inline]&#xA;  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560&#xA;  __alloc_skb+0x352/0x790 net/core/skbuff.c:651&#xA;  alloc_skb include/linux/skbuff.h:1296 [inline]&#xA;  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394&#xA;  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783&#xA;  packet_alloc_skb net/packet/af_packet.c:2930 [inline]&#xA;  packet_snd net/packet/af_packet.c:3024 [inline]&#xA;  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg net/socket.c:745 [inline]&#xA;  __sys_sendto+0x735/0xa10 net/socket.c:2191&#xA;  __do_sys_sendto net/socket.c:2203 [inline]&#xA;  __se_sys_sendto net/socket.c:2199 [inline]&#xA;  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;CVE-2024-26862:In the Linux kernel, the following vulnerability has been resolved:&#xA;packet: annotate data-races around ignore_outgoing&#xA;ignore_outgoing is read locklessly from dev_queue_xmit_nit()&#xA;and packet_getsockopt()&#xA;Add appropriate READ_ONCE()/WRITE_ONCE() annotations.&#xA;syzbot reported:&#xA;BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt&#xA;write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:&#xA; packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003&#xA; do_sock_setsockopt net/socket.c:2311 [inline]&#xA; __sys_setsockopt+0x1d8/0x250 net/socket.c:2334&#xA; __do_sys_setsockopt net/socket.c:2343 [inline]&#xA; __se_sys_setsockopt net/socket.c:2340 [inline]&#xA; __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340&#xA; do_syscall_64+0xd3/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:&#xA; dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248&#xA; xmit_one net/core/dev.c:3527 [inline]&#xA; dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547&#xA; __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335&#xA; dev_queue_xmit include/linux/netdevice.h:3091 [inline]&#xA; batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108&#xA; batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127&#xA; batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]&#xA; batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]&#xA; batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700&#xA; process_one_work kernel/workqueue.c:3254 [inline]&#xA; process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335&#xA; worker_thread+0x526/0x730 kernel/workqueue.c:3416&#xA; kthread+0x1d1/0x210 kernel/kthread.c:388&#xA; ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243&#xA;value changed: 0x00 -&gt; 0x01&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024&#xA;Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet&#xA;CVE-2024-26863:In the Linux kernel, the following vulnerability has been resolved:&#xA;hsr: Fix uninit-value access in hsr_get_node()&#xA;KMSAN reported the following uninit-value access issue [1]: =====================================================&#xA;BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246&#xA; hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246&#xA; fill_frame_info net/hsr/hsr_forward.c:577 [inline]&#xA; hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615&#xA; hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223&#xA; __netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA; xmit_one net/core/dev.c:3548 [inline]&#xA; dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564&#xA; __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349&#xA; dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA; packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276&#xA; packet_snd net/packet/af_packet.c:3087 [inline]&#xA; packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; __sys_sendto+0x735/0xa10 net/socket.c:2191&#xA; __do_sys_sendto net/socket.c:2203 [inline]&#xA; __se_sys_sendto net/socket.c:2199 [inline]&#xA; __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA; slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768&#xA; slab_alloc_node mm/slub.c:3478 [inline]&#xA; kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523&#xA; kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560&#xA; __alloc_skb+0x318/0x740 net/core/skbuff.c:651&#xA; alloc_skb include/linux/skbuff.h:1286 [inline]&#xA; alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334&#xA; sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787&#xA; packet_alloc_skb net/packet/af_packet.c:2936 [inline]&#xA; packet_snd net/packet/af_packet.c:3030 [inline]&#xA; packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; __sys_sendto+0x735/0xa10 net/socket.c:2191&#xA; __do_sys_sendto net/socket.c:2203 [inline]&#xA; __se_sys_sendto net/socket.c:2199 [inline]&#xA; __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================&#xA;If the packet type ID field in the Ethernet header is either ETH_P_PRP or&#xA;ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()&#xA;reads an invalid value as a sequence number. This causes the above issue.&#xA;This patch fixes the issue by returning NULL if the Ethernet header is not&#xA;followed by an HSR tag.&#xA;CVE-2024-26865:In the Linux kernel, the following vulnerability has been resolved:&#xA;rds: tcp: Fix use-after-free of net in reqsk_timer_handler().&#xA;syzkaller reported a warning of netns tracker [0] followed by KASAN&#xA;splat [1] and another ref tracker warning [1].&#xA;syzkaller could not find a repro, but in the log, the only suspicious&#xA;sequence was as follows:&#xA;  18:26:22 executing program 1:&#xA;  r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)&#xA;  ...&#xA;  connect$inet6(r0, &amp;(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)&#xA;The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.&#xA;So, the scenario would be:&#xA;  1. unshare(CLONE_NEWNET) creates a per netns tcp listener in&#xA;      rds_tcp_listen_init().&#xA;  2. syz-executor connect()s to it and creates a reqsk.&#xA;  3. syz-executor exit()s immediately.&#xA;  4. netns is dismantled.  [0]&#xA;  5. reqsk timer is fired, and UAF happens while freeing reqsk.  [1]&#xA;  6. listener is freed after RCU grace period.  [2]&#xA;Basically, reqsk assumes that the listener guarantees netns safety&#xA;until all reqsk timers are expired by holding the listener&#39;s refcount.&#xA;However, this was not the case for kernel sockets.&#xA;Commit 740ea3c4a0b2 (&#34;tcp: Clean up kernel listener&#39;s reqsk in&#xA;inet_twsk_purge()&#34;) fixed this issue only for per-netns ehash.&#xA;Let&#39;s apply the same fix for the global ehash.&#xA;[0]:&#xA;ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at&#xA;     sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)&#xA;     inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)&#xA;     __sock_create (net/socket.c:1572)&#xA;     rds_tcp_listen_init (net/rds/tcp_listen.c:279)&#xA;     rds_tcp_init_net (net/rds/tcp.c:577)&#xA;     ops_init (net/core/net_namespace.c:137)&#xA;     setup_net (net/core/net_namespace.c:340)&#xA;     copy_net_ns (net/core/net_namespace.c:497)&#xA;     create_new_namespaces (kernel/nsproxy.c:110)&#xA;     unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))&#xA;     ksys_unshare (kernel/fork.c:3429)&#xA;     __x64_sys_unshare (kernel/fork.c:3496)&#xA;     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)&#xA;     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)&#xA;...&#xA;WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)&#xA;[1]:&#xA;BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)&#xA;Read of size 8 at addr ffff88801b370400 by task swapper/0/0&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))&#xA; print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)&#xA; kasan_report (mm/kasan/report.c:603)&#xA; inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)&#xA; reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)&#xA; call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)&#xA; __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)&#xA; run_timer_softirq (kernel/time/timer.c:2053)&#xA; __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)&#xA; irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)&#xA; sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))&#xA; &lt;/IRQ&gt;&#xA;Allocated by task 258 on cpu 0 at 83.612050s:&#xA; kasan_save_stack (mm/kasan/common.c:48)&#xA; kasan_save_track (mm/kasan/common.c:68)&#xA; __kasan_slab_alloc (mm/kasan/common.c:343)&#xA; kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)&#xA; copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)&#xA; create_new_namespaces (kernel/nsproxy.c:110)&#xA; unshare_nsproxy_name&#xA;---truncated---&#xA;CVE-2024-26869:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to truncate meta inode pages forcely&#xA;Below race case can cause data corruption:&#xA;Thread A&#x9;&#x9;&#x9;&#x9;GC thread&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;- gc_data_segment&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; - ra_data_block&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  - locked meta_inode page&#xA;- f2fs_inplace_write_data&#xA; - invalidate_mapping_pages&#xA; : fail to invalidate meta_inode page&#xA;   due to lock failure or dirty|writeback&#xA;   status&#xA; - f2fs_submit_page_bio&#xA; : write last dirty data to old blkaddr&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; - move_data_block&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  - load old data from meta_inode page&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  - f2fs_submit_page_write&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  : write old data to new blkaddr&#xA;Because invalidate_mapping_pages() will skip invalidating page which&#xA;has unclear status including locked, dirty, writeback and so on, so&#xA;we need to use truncate_inode_pages_range() instead of&#xA;invalidate_mapping_pages() to make sure meta_inode page will be dropped.&#xA;CVE-2024-26872:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/srpt: Do not register event handler until srpt device is fully setup&#xA;Upon rare occasions, KASAN reports a use-after-free Write&#xA;in srpt_refresh_port().&#xA;This seems to be because an event handler is registered before the&#xA;srpt device is fully setup and a race condition upon error may leave a&#xA;partially setup event handler in place.&#xA;Instead, only register the event handler after srpt device initialization&#xA;is complete.&#xA;CVE-2024-26876:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/bridge: adv7511: fix crash on irq during probe&#xA;Moved IRQ registration down to end of adv7511_probe().&#xA;If an IRQ already is pending during adv7511_probe&#xA;(before adv7511_cec_init) then cec_received_msg_ts&#xA;could crash using uninitialized data:&#xA;    Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5&#xA;    Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP&#xA;    Call trace:&#xA;     cec_received_msg_ts+0x48/0x990 [cec]&#xA;     adv7511_cec_irq_process+0x1cc/0x308 [adv7511]&#xA;     adv7511_irq_process+0xd8/0x120 [adv7511]&#xA;     adv7511_irq_handler+0x1c/0x30 [adv7511]&#xA;     irq_thread_fn+0x30/0xa0&#xA;     irq_thread+0x14c/0x238&#xA;     kthread+0x190/0x1a8&#xA;CVE-2024-26877:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: xilinx - call finalize with bh disabled&#xA;When calling crypto_finalize_request, BH should be disabled to avoid&#xA;triggering the following calltrace:&#xA;    ------------[ cut here ]------------&#xA;    WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118&#xA;    Modules linked in: cryptodev(O)&#xA;    CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G           O       6.8.0-rc1-yocto-standard #323&#xA;    Hardware name: ZynqMP ZCU102 Rev1.0 (DT)&#xA;    pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;    pc : crypto_finalize_request+0xa0/0x118&#xA;    lr : crypto_finalize_request+0x104/0x118&#xA;    sp : ffffffc085353ce0&#xA;    x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688&#xA;    x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00&#xA;    x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000&#xA;    x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450&#xA;    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;    x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0&#xA;    x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8&#xA;    x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001&#xA;    x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000&#xA;    x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000&#xA;    Call trace:&#xA;     crypto_finalize_request+0xa0/0x118&#xA;     crypto_finalize_aead_request+0x18/0x30&#xA;     zynqmp_handle_aes_req+0xcc/0x388&#xA;     crypto_pump_work+0x168/0x2d8&#xA;     kthread_worker_fn+0xfc/0x3a0&#xA;     kthread+0x118/0x138&#xA;     ret_from_fork+0x10/0x20&#xA;    irq event stamp: 40&#xA;    hardirqs last  enabled at (39): [&lt;ffffffc0812416f8&gt;] _raw_spin_unlock_irqrestore+0x70/0xb0&#xA;    hardirqs last disabled at (40): [&lt;ffffffc08122d208&gt;] el1_dbg+0x28/0x90&#xA;    softirqs last  enabled at (36): [&lt;ffffffc080017dec&gt;] kernel_neon_begin+0x8c/0xf0&#xA;    softirqs last disabled at (34): [&lt;ffffffc080017dc0&gt;] kernel_neon_begin+0x60/0xf0&#xA;    ---[ end trace 0000000000000000 ]---&#xA;CVE-2024-26889:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: hci_core: Fix possible buffer overflow&#xA;struct hci_dev_info has a fixed size name[8] field so in the event that&#xA;hdev-&gt;name is bigger than that strcpy would attempt to write past its&#xA;size, so this fixes this problem by switching to use strscpy.&#xA;CVE-2024-26895:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces&#xA;wilc_netdev_cleanup currently triggers a KASAN warning, which can be&#xA;observed on interface registration error path, or simply by&#xA;removing the module/unbinding device from driver:&#xA;echo spi0.1 &gt; /sys/bus/spi/drivers/wilc1000_spi/unbind ==================================================================&#xA;BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc&#xA;Read of size 4 at addr c54d1ce8 by task sh/86&#xA;CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117&#xA;Hardware name: Atmel SAMA5&#xA; unwind_backtrace from show_stack+0x18/0x1c&#xA; show_stack from dump_stack_lvl+0x34/0x58&#xA; dump_stack_lvl from print_report+0x154/0x500&#xA; print_report from kasan_report+0xac/0xd8&#xA; kasan_report from wilc_netdev_cleanup+0x508/0x5cc&#xA; wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec&#xA; wilc_bus_remove from spi_remove+0x8c/0xac&#xA; spi_remove from device_release_driver_internal+0x434/0x5f8&#xA; device_release_driver_internal from unbind_store+0xbc/0x108&#xA; unbind_store from kernfs_fop_write_iter+0x398/0x584&#xA; kernfs_fop_write_iter from vfs_write+0x728/0xf88&#xA; vfs_write from ksys_write+0x110/0x1e4&#xA; ksys_write from ret_fast_syscall+0x0/0x1c&#xA;[...]&#xA;Allocated by task 1:&#xA; kasan_save_track+0x30/0x5c&#xA; __kasan_kmalloc+0x8c/0x94&#xA; __kmalloc_node+0x1cc/0x3e4&#xA; kvmalloc_node+0x48/0x180&#xA; alloc_netdev_mqs+0x68/0x11dc&#xA; alloc_etherdev_mqs+0x28/0x34&#xA; wilc_netdev_ifc_init+0x34/0x8ec&#xA; wilc_cfg80211_init+0x690/0x910&#xA; wilc_bus_probe+0xe0/0x4a0&#xA; spi_probe+0x158/0x1b0&#xA; really_probe+0x270/0xdf4&#xA; __driver_probe_device+0x1dc/0x580&#xA; driver_probe_device+0x60/0x140&#xA; __driver_attach+0x228/0x5d4&#xA; bus_for_each_dev+0x13c/0x1a8&#xA; bus_add_driver+0x2a0/0x608&#xA; driver_register+0x24c/0x578&#xA; do_one_initcall+0x180/0x310&#xA; kernel_init_freeable+0x424/0x484&#xA; kernel_init+0x20/0x148&#xA; ret_from_fork+0x14/0x28&#xA;Freed by task 86:&#xA; kasan_save_track+0x30/0x5c&#xA; kasan_save_free_info+0x38/0x58&#xA; __kasan_slab_free+0xe4/0x140&#xA; kfree+0xb0/0x238&#xA; device_release+0xc0/0x2a8&#xA; kobject_put+0x1d4/0x46c&#xA; netdev_run_todo+0x8fc/0x11d0&#xA; wilc_netdev_cleanup+0x1e4/0x5cc&#xA; wilc_bus_remove+0xc8/0xec&#xA; spi_remove+0x8c/0xac&#xA; device_release_driver_internal+0x434/0x5f8&#xA; unbind_store+0xbc/0x108&#xA; kernfs_fop_write_iter+0x398/0x584&#xA; vfs_write+0x728/0xf88&#xA; ksys_write+0x110/0x1e4&#xA; ret_fast_syscall+0x0/0x1c&#xA; [...]&#xA;David Mosberger-Tan initial investigation [1] showed that this&#xA;use-after-free is due to netdevice unregistration during vif list&#xA;traversal. When unregistering a net device, since the needs_free_netdev has&#xA;been set to true during registration, the netdevice object is also freed,&#xA;and as a consequence, the corresponding vif object too, since it is&#xA;attached to it as private netdevice data. The next occurrence of the loop&#xA;then tries to access freed vif pointer to the list to move forward in the&#xA;list.&#xA;Fix this use-after-free thanks to two mechanisms:&#xA;- navigate in the list with list_for_each_entry_safe, which allows to&#xA;  safely modify the list as we go through each element. For each element,&#xA;  remove it from the list with list_del_rcu&#xA;- make sure to wait for RCU grace period end after each vif removal to make&#xA;  sure it is safe to free the corresponding vif too (through&#xA;  unregister_netdev)&#xA;Since we are in a RCU &#34;modifier&#34; path (not a &#34;reader&#34; path), and because&#xA;such path is expected not to be concurrent to any other modifier (we are&#xA;using the vif_mutex lock), we do not need to use RCU list API, that&#39;s why&#xA;we can benefit from list_for_each_entry_safe.&#xA;[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/&#xA;CVE-2024-26896:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: wfx: fix memory leak when starting AP&#xA;Kmemleak reported this error:&#xA;    unreferenced object 0xd73d1180 (size 184):&#xA;      comm &#34;wpa_supplicant&#34;, pid 1559, jiffies 13006305 (age 964.245s)&#xA;      hex dump (first 32 bytes):&#xA;        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;        00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00  ................&#xA;      backtrace:&#xA;        [&lt;5ca11420&gt;] kmem_cache_alloc+0x20c/0x5ac&#xA;        [&lt;127bdd74&gt;] __alloc_skb+0x144/0x170&#xA;        [&lt;fb8a5e38&gt;] __netdev_alloc_skb+0x50/0x180&#xA;        [&lt;0f9fa1d5&gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]&#xA;        [&lt;7accd02d&gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]&#xA;        [&lt;41e25cc3&gt;] wfx_start_ap+0xc8/0x234 [wfx]&#xA;        [&lt;93a70356&gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]&#xA;        [&lt;a4a661cd&gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]&#xA;        [&lt;47bd8b68&gt;] genl_rcv_msg+0x198/0x378&#xA;        [&lt;453ef796&gt;] netlink_rcv_skb+0xd0/0x130&#xA;        [&lt;6b7c977a&gt;] genl_rcv+0x34/0x44&#xA;        [&lt;66b2d04d&gt;] netlink_unicast+0x1b4/0x258&#xA;        [&lt;f965b9b6&gt;] netlink_sendmsg+0x1e8/0x428&#xA;        [&lt;aadb8231&gt;] ____sys_sendmsg+0x1e0/0x274&#xA;        [&lt;d2b5212d&gt;] ___sys_sendmsg+0x80/0xb4&#xA;        [&lt;69954f45&gt;] __sys_sendmsg+0x64/0xa8&#xA;    unreferenced object 0xce087000 (size 1024):&#xA;      comm &#34;wpa_supplicant&#34;, pid 1559, jiffies 13006305 (age 964.246s)&#xA;      hex dump (first 32 bytes):&#xA;        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;        10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............&#xA;      backtrace:&#xA;        [&lt;9a993714&gt;] __kmalloc_track_caller+0x230/0x600&#xA;        [&lt;f83ea192&gt;] kmalloc_reserve.constprop.0+0x30/0x74&#xA;        [&lt;a2c61343&gt;] __alloc_skb+0xa0/0x170&#xA;        [&lt;fb8a5e38&gt;] __netdev_alloc_skb+0x50/0x180&#xA;        [&lt;0f9fa1d5&gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]&#xA;        [&lt;7accd02d&gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]&#xA;        [&lt;41e25cc3&gt;] wfx_start_ap+0xc8/0x234 [wfx]&#xA;        [&lt;93a70356&gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]&#xA;        [&lt;a4a661cd&gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]&#xA;        [&lt;47bd8b68&gt;] genl_rcv_msg+0x198/0x378&#xA;        [&lt;453ef796&gt;] netlink_rcv_skb+0xd0/0x130&#xA;        [&lt;6b7c977a&gt;] genl_rcv+0x34/0x44&#xA;        [&lt;66b2d04d&gt;] netlink_unicast+0x1b4/0x258&#xA;        [&lt;f965b9b6&gt;] netlink_sendmsg+0x1e8/0x428&#xA;        [&lt;aadb8231&gt;] ____sys_sendmsg+0x1e0/0x274&#xA;        [&lt;d2b5212d&gt;] ___sys_sendmsg+0x80/0xb4&#xA;However, since the kernel is build optimized, it seems the stack is not&#xA;accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue&#xA;is obvious in this function: memory allocated by ieee80211_beacon_get()&#xA;is never released. Fixing this leak makes kmemleak happy.&#xA;CVE-2024-26897:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete&#xA;The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data&#xA;structures have been fully initialised by the time it runs. However, because of&#xA;the order in which things are initialised, this is not guaranteed to be the&#xA;case, because the device is exposed to the USB subsystem before the ath9k driver&#xA;initialisation is completed.&#xA;We already committed a partial fix for this in commit:&#xA;8b3046abc99e (&#34;ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()&#34;)&#xA;However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event&#xA;tasklet, pairing it with an &#34;initialisation complete&#34; bit in the TX struct. It&#xA;seems syzbot managed to trigger the race for one of the other commands as well,&#xA;so let&#39;s just move the existing synchronisation bit to cover the whole&#xA;tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside&#xA;ath9k_tx_init()).&#xA;CVE-2024-26904:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-26910:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: ipset: fix performance regression in swap operation&#xA;The patch &#34;netfilter: ipset: fix race condition between swap/destroy&#xA;and kernel side add/del/test&#34;, commit 28628fa9 fixes a race condition.&#xA;But the synchronize_rcu() added to the swap function unnecessarily slows&#xA;it down: it can safely be moved to destroy and use call_rcu() instead.&#xA;Eric Dumazet pointed out that simply calling the destroy functions as&#xA;rcu callback does not work: sets with timeout use garbage collectors&#xA;which need cancelling at destroy which can wait. Therefore the destroy&#xA;functions are split into two: cancelling garbage collectors safely at&#xA;executing the command received by netlink and moving the remaining&#xA;part only into the rcu callback.&#xA;CVE-2024-26915:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Reset IH OVERFLOW_CLEAR bit&#xA;Allows us to detect subsequent IH ring buffer overflows as well.&#xA;CVE-2024-26922:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: validate the parameters of bo mapping operations more clearly&#xA;Verify the parameters of&#xA;amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.&#xA;CVE-2024-26924:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_set_pipapo: do not free live element&#xA;Pablo reports a crash with large batches of elements with a&#xA;back-to-back add/remove pattern.  Quoting Pablo:&#xA;  add_elem(&#34;00000000&#34;) timeout 100 ms&#xA;  ...&#xA;  add_elem(&#34;0000000X&#34;) timeout 100 ms&#xA;  del_elem(&#34;0000000X&#34;) &lt;---------------- delete one that was just added&#xA;  ...&#xA;  add_elem(&#34;00005000&#34;) timeout 100 ms&#xA;  1) nft_pipapo_remove() removes element 0000000X&#xA;  Then, KASAN shows a splat.&#xA;Looking at the remove function there is a chance that we will drop a&#xA;rule that maps to a non-deactivated element.&#xA;Removal happens in two steps, first we do a lookup for key k and return the&#xA;to-be-removed element and mark it as inactive in the next generation.&#xA;Then, in a second step, the element gets removed from the set/map.&#xA;The _remove function does not work correctly if we have more than one&#xA;element that share the same key.&#xA;This can happen if we insert an element into a set when the set already&#xA;holds an element with same key, but the element mapping to the existing&#xA;key has timed out or is not active in the next generation.&#xA;In such case its possible that removal will unmap the wrong element.&#xA;If this happens, we will leak the non-deactivated element, it becomes&#xA;unreachable.&#xA;The element that got deactivated (and will be freed later) will&#xA;remain reachable in the set data structure, this can result in&#xA;a crash when such an element is retrieved during lookup (stale&#xA;pointer).&#xA;Add a check that the fully matching key does in fact map to the element&#xA;that we have marked as inactive in the deactivation step.&#xA;If not, we need to continue searching.&#xA;Add a bug/warn trap at the end of the function as well, the remove&#xA;function must not ever be called with an invisible/unreachable/non-existent&#xA;element.&#xA;v2: avoid uneeded temporary variable (Stefano)&#xA;CVE-2024-26925:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path&#xA;The commit mutex should not be released during the critical section&#xA;between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC&#xA;worker could collect expired objects and get the released commit lock&#xA;within the same GC sequence.&#xA;nf_tables_module_autoload() temporarily releases the mutex to load&#xA;module dependencies, then it goes back to replay the transaction again.&#xA;Move it at the end of the abort phase after nft_gc_seq_end() is called.&#xA;CVE-2024-26926:In the Linux kernel, the following vulnerability has been resolved:&#xA;binder: check offset alignment in binder_get_object()&#xA;Commit 6d98eb95b450 (&#34;binder: avoid potential data leakage when copying&#xA;txn&#34;) introduced changes to how binder objects are copied. In doing so,&#xA;it unintentionally removed an offset alignment check done through calls&#xA;to binder_alloc_copy_from_buffer() -&gt; check_buffer().&#xA;These calls were replaced in binder_get_object() with copy_from_user(),&#xA;so now an explicit offset alignment check is needed here. This avoids&#xA;later complications when unwinding the objects gets harder.&#xA;It is worth noting this check existed prior to commit 7a67a39320df&#xA;(&#34;binder: add function to copy binder object from buffer&#34;), likely&#xA;removed due to redundancy at the time.&#xA;CVE-2024-26934:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: core: Fix deadlock in usb_deauthorize_interface()&#xA;Among the attribute file callback routines in&#xA;drivers/usb/core/sysfs.c, the interface_authorized_store() function is&#xA;the only one which acquires a device lock on an ancestor device: It&#xA;calls usb_deauthorize_interface(), which locks the interface&#39;s parent&#xA;USB device.&#xA;The will lead to deadlock if another process already owns that lock&#xA;and tries to remove the interface, whether through a configuration&#xA;change or because the device has been disconnected.  As part of the&#xA;removal procedure, device_del() waits for all ongoing sysfs attribute&#xA;callbacks to complete.  But usb_deauthorize_interface() can&#39;t complete&#xA;until the device lock has been released, and the lock won&#39;t be&#xA;released until the removal has finished.&#xA;The mechanism provided by sysfs to prevent this kind of deadlock is&#xA;to use the sysfs_break_active_protection() function, which tells sysfs&#xA;not to wait for the attribute callback.&#xA;Reported-and-tested by: Yue Sun &lt;samsun1006219@gmail.com&gt;&#xA;Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;&#xA;CVE-2024-26955:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: prevent kernel bug at submit_bh_wbc()&#xA;Fix a bug where nilfs_get_block() returns a successful status when&#xA;searching and inserting the specified block both fail inconsistently.  If&#xA;this inconsistent behavior is not due to a previously fixed bug, then an&#xA;unexpected race is occurring, so return a temporary error -EAGAIN instead.&#xA;This prevents callers such as __block_write_begin_int() from requesting a&#xA;read into a buffer that is not mapped, which would cause the BUG_ON check&#xA;for the BH_Mapped flag in submit_bh_wbc() to fail.&#xA;CVE-2024-26956:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix failure to detect DAT corruption in btree and direct mappings&#xA;Patch series &#34;nilfs2: fix kernel bug at submit_bh_wbc()&#34;.&#xA;This resolves a kernel BUG reported by syzbot.  Since there are two&#xA;flaws involved, I&#39;ve made each one a separate patch.&#xA;The first patch alone resolves the syzbot-reported bug, but I think&#xA;both fixes should be sent to stable, so I&#39;ve tagged them as such.&#xA;This patch (of 2):&#xA;Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data&#xA;to a nilfs2 file system whose metadata is corrupted.&#xA;There are two flaws involved in this issue.&#xA;The first flaw is that when nilfs_get_block() locates a data block using&#xA;btree or direct mapping, if the disk address translation routine&#xA;nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata&#xA;corruption, it can be passed back to nilfs_get_block().  This causes&#xA;nilfs_get_block() to misidentify an existing block as non-existent,&#xA;causing both data block lookup and insertion to fail inconsistently.&#xA;The second flaw is that nilfs_get_block() returns a successful status in&#xA;this inconsistent state.  This causes the caller __block_write_begin_int()&#xA;or others to request a read even though the buffer is not mapped,&#xA;resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()&#xA;failing.&#xA;This fixes the first issue by changing the return value to code -EINVAL&#xA;when a conversion using DAT fails with code -ENOENT, avoiding the&#xA;conflicting condition that leads to the kernel bug described above.  Here,&#xA;code -EINVAL indicates that metadata corruption was detected during the&#xA;block lookup, which will be properly handled as a file system error and&#xA;converted to -EIO when passing through the nilfs2 bmap layer.&#xA;CVE-2024-26960:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm: swap: fix race between free_swap_and_cache() and swapoff()&#xA;There was previously a theoretical window where swapoff() could run and&#xA;teardown a swap_info_struct while a call to free_swap_and_cache() was&#xA;running in another thread.  This could cause, amongst other bad&#xA;possibilities, swap_page_trans_huge_swapped() (called by&#xA;free_swap_and_cache()) to access the freed memory for swap_map.&#xA;This is a theoretical problem and I haven&#39;t been able to provoke it from a&#xA;test case.  But there has been agreement based on code review that this is&#xA;possible (see link below).&#xA;Fix it by using get_swap_device()/put_swap_device(), which will stall&#xA;swapoff().  There was an extra check in _swap_info_get() to confirm that&#xA;the swap entry was not free.  This isn&#39;t present in get_swap_device()&#xA;because it doesn&#39;t make sense in general due to the race between getting&#xA;the reference and swapoff.  So I&#39;ve added an equivalent check directly in&#xA;free_swap_and_cache().&#xA;Details of how to provoke one possible issue (thanks to David Hildenbrand&#xA;for deriving this):&#xA;--8&lt;-----&#xA;__swap_entry_free() might be the last user and result in&#xA;&#34;count == SWAP_HAS_CACHE&#34;.&#xA;swapoff-&gt;try_to_unuse() will stop as soon as soon as si-&gt;inuse_pages==0.&#xA;So the question is: could someone reclaim the folio and turn si-&gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().&#xA;Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are&#xA;still references by swap entries.&#xA;Process 1 still references subpage 0 via swap entry.&#xA;Process 2 still references subpage 1 via swap entry.&#xA;Process 1 quits. Calls free_swap_and_cache().&#xA;-&gt; count == SWAP_HAS_CACHE&#xA;[then, preempted in the hypervisor etc.]&#xA;Process 2 quits. Calls free_swap_and_cache().&#xA;-&gt; count == SWAP_HAS_CACHE&#xA;Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls&#xA;__try_to_reclaim_swap().&#xA;__try_to_reclaim_swap()-&gt;folio_free_swap()-&gt;delete_from_swap_cache()-&gt;&#xA;put_swap_folio()-&gt;free_swap_slot()-&gt;swapcache_free_entries()-&gt;&#xA;swap_entry_free()-&gt;swap_range_free()-&gt;&#xA;...&#xA;WRITE_ONCE(si-&gt;inuse_pages, si-&gt;inuse_pages - nr_entries);&#xA;What stops swapoff to succeed after process 2 reclaimed the swap cache&#xA;but before process1 finished its call to swap_page_trans_huge_swapped()?&#xA;--8&lt;-----&#xA;CVE-2024-26966:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays&#xA;The frequency table arrays are supposed to be terminated with an&#xA;empty element. Add such entry to the end of the arrays where it&#xA;is missing in order to avoid possible out-of-bound access when&#xA;the table is traversed by functions like qcom_find_freq() or&#xA;qcom_find_freq_floor().&#xA;Only compile tested.&#xA;CVE-2024-26969:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays&#xA;The frequency table arrays are supposed to be terminated with an&#xA;empty element. Add such entry to the end of the arrays where it&#xA;is missing in order to avoid possible out-of-bound access when&#xA;the table is traversed by functions like qcom_find_freq() or&#xA;qcom_find_freq_floor().&#xA;Only compile tested.&#xA;CVE-2024-26974:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: qat - resolve race condition during AER recovery&#xA;During the PCI AER system&#39;s error recovery process, the kernel driver&#xA;may encounter a race condition with freeing the reset_data structure&#39;s&#xA;memory. If the device restart will take more than 10 seconds the function&#xA;scheduling that restart will exit due to a timeout, and the reset_data&#xA;structure will be freed. However, this data structure is used for&#xA;completion notification after the restart is completed, which leads&#xA;to a UAF bug.&#xA;This results in a KFENCE bug notice.&#xA;  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]&#xA;  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):&#xA;  adf_device_reset_worker+0x38/0xa0 [intel_qat]&#xA;  process_one_work+0x173/0x340&#xA;To resolve this race condition, the memory associated to the container&#xA;of the work_struct is freed on the worker if the timeout expired,&#xA;otherwise on the function that schedules the worker.&#xA;The timeout detection can be done by checking if the caller is&#xA;still waiting for completion or not by using completion_done() function.&#xA;CVE-2024-26979:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vmwgfx: Fix possible null pointer derefence with invalid contexts&#xA;vmw_context_cotable can return either an error or a null pointer and its&#xA;usage sometimes went unchecked. Subsequent code would then try to access&#xA;either a null pointer or an error value.&#xA;The invalid dereferences were only possible with malformed userspace&#xA;apps which never properly initialized the rendering contexts.&#xA;Check the results of vmw_context_cotable to fix the invalid derefs.&#xA;Thanks:&#xA;ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab&#xA;who was the first person to discover it.&#xA;Niels De Graef who reported it and helped to track down the poc.&#xA;CVE-2024-26981:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix OOB in nilfs_set_de_type&#xA;The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is&#xA;defined as &#34;S_IFMT &gt;&gt; S_SHIFT&#34;, but the nilfs_set_de_type() function,&#xA;which uses this array, specifies the index to read from the array in the&#xA;same way as &#34;(mode &amp; S_IFMT) &gt;&gt; S_SHIFT&#34;.&#xA;static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode&#xA; *inode)&#xA;{&#xA;&#x9;umode_t mode = inode-&gt;i_mode;&#xA;&#x9;de-&gt;file_type = nilfs_type_by_mode[(mode &amp; S_IFMT)&gt;&gt;S_SHIFT]; // oob&#xA;}&#xA;However, when the index is determined this way, an out-of-bounds (OOB)&#xA;error occurs by referring to an index that is 1 larger than the array size&#xA;when the condition &#34;mode &amp; S_IFMT == S_IFMT&#34; is satisfied.  Therefore, a&#xA;patch to resize the nilfs_type_by_mode array should be applied to prevent&#xA;OOB errors.&#xA;CVE-2024-26984:In the Linux kernel, the following vulnerability has been resolved:&#xA;nouveau: fix instmem race condition around ptr stores&#xA;Running a lot of VK CTS in parallel against nouveau, once every&#xA;few hours you might see something like this crash.&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000008&#xA;PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0&#xA;Oops: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27&#xA;Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021&#xA;RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]&#xA;Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee &lt;48&gt; 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1&#xA;RSP: 0000:ffffac20c5857838 EFLAGS: 00010202&#xA;RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001&#xA;RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180&#xA;RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10&#xA;R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c&#xA;R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c&#xA;FS:  00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA;...&#xA; ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]&#xA; ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]&#xA; nvkm_vmm_iter+0x351/0xa20 [nouveau]&#xA; ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]&#xA; ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]&#xA; ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]&#xA; ? __lock_acquire+0x3ed/0x2170&#xA; ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]&#xA; nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]&#xA; ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]&#xA; ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]&#xA; nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]&#xA;Adding any sort of useful debug usually makes it go away, so I hand&#xA;wrote the function in a line, and debugged the asm.&#xA;Every so often pt-&gt;memory-&gt;ptrs is NULL. This ptrs ptr is set in&#xA;the nv50_instobj_acquire called from nvkm_kmap.&#xA;If Thread A and Thread B both get to nv50_instobj_acquire around&#xA;the same time, and Thread A hits the refcount_set line, and in&#xA;lockstep thread B succeeds at refcount_inc_not_zero, there is a&#xA;chance the ptrs value won&#39;t have been stored since refcount_set&#xA;is unordered. Force a memory barrier here, I picked smp_mb, since&#xA;we want it on all CPUs and it&#39;s write followed by a read.&#xA;v2: use paired smp_rmb/smp_wmb.&#xA;CVE-2024-26988:In the Linux kernel, the following vulnerability has been resolved:&#xA;init/main.c: Fix potential static_command_line memory overflow&#xA;We allocate memory of size &#39;xlen + strlen(boot_command_line) + 1&#39; for&#xA;static_command_line, but the strings copied into static_command_line are&#xA;extra_command_line and command_line, rather than extra_command_line and&#xA;boot_command_line.&#xA;When strlen(command_line) &gt; strlen(boot_command_line), static_command_line&#xA;will overflow.&#xA;This patch just recovers strlen(command_line) which was miss-consolidated&#xA;with strlen(boot_command_line) in the commit f5c7310ac73e (&#34;init/main: add&#xA;checks for the return value of memblock_alloc*()&#34;)&#xA;CVE-2024-26994:In the Linux kernel, the following vulnerability has been resolved:&#xA;speakup: Avoid crash on very long word&#xA;In case a console is set up really large and contains a really long word&#xA;(&gt; 256 characters), we have to stop before the length of the word buffer.&#xA;CVE-2024-26996:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error&#xA;When ncm function is working and then stop usb0 interface for link down,&#xA;eth_stop() is called. At this piont, accidentally if usb transport error&#xA;should happen in usb_ep_enable(), &#39;in_ep&#39; and/or &#39;out_ep&#39; may not be enabled.&#xA;After that, ncm_disable() is called to disable for ncm unbind&#xA;but gether_disconnect() is never called since &#39;in_ep&#39; is not enabled.&#xA;As the result, ncm object is released in ncm unbind&#xA;but &#39;dev-&gt;port_usb&#39; associated to &#39;ncm-&gt;port&#39; is not NULL.&#xA;And when ncm bind again to recover netdev, ncm object is reallocated&#xA;but usb0 interface is already associated to previous released ncm object.&#xA;Therefore, once usb0 interface is up and eth_start_xmit() is called,&#xA;released ncm object is dereferrenced and it might cause use-after-free memory.&#xA;[function unlink via configfs]&#xA;  usb0: eth_stop dev-&gt;port_usb=ffffff9b179c3200&#xA;  --&gt; error happens in usb_ep_enable().&#xA;  NCM: ncm_disable: ncm=ffffff9b179c3200&#xA;  --&gt; no gether_disconnect() since ncm-&gt;port.in_ep-&gt;enabled is false.&#xA;  NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200&#xA;  NCM: ncm_free: ncm free ncm=ffffff9b179c3200   &lt;-- released ncm&#xA;[function link via configfs]&#xA;  NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000&#xA;  NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000&#xA;  NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0&#xA;  usb0: eth_open dev-&gt;port_usb=ffffff9b179c3200  &lt;-- previous released ncm&#xA;  usb0: eth_start dev-&gt;port_usb=ffffff9b179c3200 &lt;--&#xA;  eth_start_xmit()&#xA;  --&gt; dev-&gt;wrap()&#xA;  Unable to handle kernel paging request at virtual address dead00000000014f&#xA;This patch addresses the issue by checking if &#39;ncm-&gt;netdev&#39; is not NULL at&#xA;ncm_disable() to call gether_disconnect() to deassociate &#39;dev-&gt;port_usb&#39;.&#xA;It&#39;s more reasonable to check &#39;ncm-&gt;netdev&#39; to call gether_connect/disconnect&#xA;rather than check &#39;ncm-&gt;port.in_ep-&gt;enabled&#39; since it might not be enabled&#xA;but the gether connection might be established.&#xA;CVE-2024-26999:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial/pmac_zilog: Remove flawed mitigation for rx irq flood&#xA;The mitigation was intended to stop the irq completely. That may be&#xA;better than a hard lock-up but it turns out that you get a crash anyway&#xA;if you&#39;re using pmac_zilog as a serial console:&#xA;ttyPZ0: pmz: rx irq flood !&#xA;BUG: spinlock recursion on CPU#0, swapper/0&#xA;That&#39;s because the pr_err() call in pmz_receive_chars() results in&#xA;pmz_console_write() attempting to lock a spinlock already locked in&#xA;pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal&#xA;BUG splat. The spinlock in question is the one in struct uart_port.&#xA;Even when it&#39;s not fatal, the serial port rx function ceases to work.&#xA;Also, the iteration limit doesn&#39;t play nicely with QEMU, as can be&#xA;seen in the bug report linked below.&#xA;A web search for other reports of the error message &#34;pmz: rx irq flood&#34;&#xA;didn&#39;t produce anything. So I don&#39;t think this code is needed any more.&#xA;Remove it.&#xA;CVE-2024-27001:In the Linux kernel, the following vulnerability has been resolved:&#xA;comedi: vmk80xx: fix incomplete endpoint checking&#xA;While vmk80xx does have endpoint checking implemented, some things&#xA;can fall through the cracks. Depending on the hardware model,&#xA;URBs can have either bulk or interrupt type, and current version&#xA;of vmk80xx_find_usb_endpoints() function does not take that fully&#xA;into account. While this warning does not seem to be too harmful,&#xA;at the very least it will crash systems with &#39;panic_on_warn&#39; set on&#xA;them.&#xA;Fix the issue found by Syzkaller [1] by somewhat simplifying the&#xA;endpoint checking process with usb_find_common_endpoints() and&#xA;ensuring that only expected endpoint types are present.&#xA;This patch has not been tested on real hardware.&#xA;[1] Syzkaller report:&#xA;usb 1-1: BOGUS urb xfer, pipe 1 != type 3&#xA;WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59&#xA; vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]&#xA; vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818&#xA; comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067&#xA; usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399&#xA;...&#xA;Similar issue also found by Syzkaller:&#xA;CVE-2024-27004:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: Get runtime PM before walking tree during disable_unused&#xA;Doug reported [1] the following hung task:&#xA; INFO: task swapper/0:1 blocked for more than 122 seconds.&#xA;       Not tainted 5.15.149-21875-gf795ebc40eb8 #1&#xA; &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA; task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008&#xA; Call trace:&#xA;  __switch_to+0xf4/0x1f4&#xA;  __schedule+0x418/0xb80&#xA;  schedule+0x5c/0x10c&#xA;  rpm_resume+0xe0/0x52c&#xA;  rpm_resume+0x178/0x52c&#xA;  __pm_runtime_resume+0x58/0x98&#xA;  clk_pm_runtime_get+0x30/0xb0&#xA;  clk_disable_unused_subtree+0x58/0x208&#xA;  clk_disable_unused_subtree+0x38/0x208&#xA;  clk_disable_unused_subtree+0x38/0x208&#xA;  clk_disable_unused_subtree+0x38/0x208&#xA;  clk_disable_unused_subtree+0x38/0x208&#xA;  clk_disable_unused+0x4c/0xe4&#xA;  do_one_initcall+0xcc/0x2d8&#xA;  do_initcall_level+0xa4/0x148&#xA;  do_initcalls+0x5c/0x9c&#xA;  do_basic_setup+0x24/0x30&#xA;  kernel_init_freeable+0xec/0x164&#xA;  kernel_init+0x28/0x120&#xA;  ret_from_fork+0x10/0x20&#xA; INFO: task kworker/u16:0:9 blocked for more than 122 seconds.&#xA;       Not tainted 5.15.149-21875-gf795ebc40eb8 #1&#xA; &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA; task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008&#xA; Workqueue: events_unbound deferred_probe_work_func&#xA; Call trace:&#xA;  __switch_to+0xf4/0x1f4&#xA;  __schedule+0x418/0xb80&#xA;  schedule+0x5c/0x10c&#xA;  schedule_preempt_disabled+0x2c/0x48&#xA;  __mutex_lock+0x238/0x488&#xA;  __mutex_lock_slowpath+0x1c/0x28&#xA;  mutex_lock+0x50/0x74&#xA;  clk_prepare_lock+0x7c/0x9c&#xA;  clk_core_prepare_lock+0x20/0x44&#xA;  clk_prepare+0x24/0x30&#xA;  clk_bulk_prepare+0x40/0xb0&#xA;  mdss_runtime_resume+0x54/0x1c8&#xA;  pm_generic_runtime_resume+0x30/0x44&#xA;  __genpd_runtime_resume+0x68/0x7c&#xA;  genpd_runtime_resume+0x108/0x1f4&#xA;  __rpm_callback+0x84/0x144&#xA;  rpm_callback+0x30/0x88&#xA;  rpm_resume+0x1f4/0x52c&#xA;  rpm_resume+0x178/0x52c&#xA;  __pm_runtime_resume+0x58/0x98&#xA;  __device_attach+0xe0/0x170&#xA;  device_initial_probe+0x1c/0x28&#xA;  bus_probe_device+0x3c/0x9c&#xA;  device_add+0x644/0x814&#xA;  mipi_dsi_device_register_full+0xe4/0x170&#xA;  devm_mipi_dsi_device_register_full+0x28/0x70&#xA;  ti_sn_bridge_probe+0x1dc/0x2c0&#xA;  auxiliary_bus_probe+0x4c/0x94&#xA;  really_probe+0xcc/0x2c8&#xA;  __driver_probe_device+0xa8/0x130&#xA;  driver_probe_device+0x48/0x110&#xA;  __device_attach_driver+0xa4/0xcc&#xA;  bus_for_each_drv+0x8c/0xd8&#xA;  __device_attach+0xf8/0x170&#xA;  device_initial_probe+0x1c/0x28&#xA;  bus_probe_device+0x3c/0x9c&#xA;  deferred_probe_work_func+0x9c/0xd8&#xA;  process_one_work+0x148/0x518&#xA;  worker_thread+0x138/0x350&#xA;  kthread+0x138/0x1e0&#xA;  ret_from_fork+0x10/0x20&#xA;The first thread is walking the clk tree and calling&#xA;clk_pm_runtime_get() to power on devices required to read the clk&#xA;hardware via struct clk_ops::is_enabled(). This thread holds the clk&#xA;prepare_lock, and is trying to runtime PM resume a device, when it finds&#xA;that the device is in the process of resuming so the thread schedule()s&#xA;away waiting for the device to finish resuming before continuing. The&#xA;second thread is runtime PM resuming the same device, but the runtime&#xA;resume callback is calling clk_prepare(), trying to grab the&#xA;prepare_lock waiting on the first thread.&#xA;This is a classic ABBA deadlock. To properly fix the deadlock, we must&#xA;never runtime PM resume or suspend a device with the clk prepare_lock&#xA;held. Actually doing that is near impossible today because the global&#xA;prepare_lock would have to be dropped in the middle of the tree, the&#xA;device runtime PM resumed/suspended, and then the prepare_lock grabbed&#xA;again to ensure consistency of the clk tree topology. If anything&#xA;changes with the clk tree in the meantime, we&#39;ve lost and will need to&#xA;start the operation all over again.&#xA;Luckily, most of the time we&#39;re simply incrementing or decrementing the&#xA;runtime PM count on an active device, so we don&#39;t have the chance to&#xA;schedule away with the prepare_lock held. Let&#39;s fix this immediate&#xA;problem that can be&#xA;---truncated---&#xA;CVE-2024-27010:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: Fix mirred deadlock on device recursion&#xA;When the mirred action is used on a classful egress qdisc and a packet is&#xA;mirrored or redirected to self we hit a qdisc lock deadlock.&#xA;See trace below.&#xA;[..... other info removed for brevity....]&#xA;[   82.890906]&#xA;[   82.890906] ============================================&#xA;[   82.890906] WARNING: possible recursive locking detected&#xA;[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W&#xA;[   82.890906] --------------------------------------------&#xA;[   82.890906] ping/418 is trying to acquire lock:&#xA;[   82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:&#xA;__dev_queue_xmit+0x1778/0x3550&#xA;[   82.890906]&#xA;[   82.890906] but task is already holding lock:&#xA;[   82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:&#xA;__dev_queue_xmit+0x1778/0x3550&#xA;[   82.890906]&#xA;[   82.890906] other info that might help us debug this:&#xA;[   82.890906]  Possible unsafe locking scenario:&#xA;[   82.890906]&#xA;[   82.890906]        CPU0&#xA;[   82.890906]        ----&#xA;[   82.890906]   lock(&amp;sch-&gt;q.lock);&#xA;[   82.890906]   lock(&amp;sch-&gt;q.lock);&#xA;[   82.890906]&#xA;[   82.890906]  *** DEADLOCK ***&#xA;[   82.890906]&#xA;[..... other info removed for brevity....]&#xA;Example setup (eth0-&gt;eth0) to recreate&#xA;tc qdisc add dev eth0 root handle 1: htb default 30&#xA;tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \&#xA;     action mirred egress redirect dev eth0&#xA;Another example(eth0-&gt;eth1-&gt;eth0) to recreate&#xA;tc qdisc add dev eth0 root handle 1: htb default 30&#xA;tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \&#xA;     action mirred egress redirect dev eth1&#xA;tc qdisc add dev eth1 root handle 1: htb default 30&#xA;tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \&#xA;     action mirred egress redirect dev eth0&#xA;We fix this by adding an owner field (CPU id) to struct Qdisc set after&#xA;root qdisc is entered. When the softirq enters it a second time, if the&#xA;qdisc owner is the same CPU, the packet is dropped to break the loop.&#xA;CVE-2024-27011:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: fix memleak in map from abort path&#xA;The delete set command does not rely on the transaction object for&#xA;element removal, therefore, a combination of delete element + delete set&#xA;from the abort path could result in restoring twice the refcount of the&#xA;mapping.&#xA;Check for inactive element in the next generation for the delete element&#xA;command in the abort path, skip restoring state if next generation bit&#xA;has been already cleared. This is similar to the activate logic using&#xA;the set walk iterator.&#xA;[ 6170.286929] ------------[ cut here ]------------&#xA;[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]&#xA;[ 6170.287071] Modules linked in: [...]&#xA;[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365&#xA;[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]&#xA;[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 &lt;0f&gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f&#xA;[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202&#xA;[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000&#xA;[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750&#xA;[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55&#xA;[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10&#xA;[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100&#xA;[ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000&#xA;[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0&#xA;[ 6170.287962] Call Trace:&#xA;[ 6170.287967]  &lt;TASK&gt;&#xA;[ 6170.287973]  ? __warn+0x9f/0x1a0&#xA;[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]&#xA;[ 6170.288092]  ? report_bug+0x1b1/0x1e0&#xA;[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]&#xA;[ 6170.288092]  ? report_bug+0x1b1/0x1e0&#xA;[ 6170.288104]  ? handle_bug+0x3c/0x70&#xA;[ 6170.288112]  ? exc_invalid_op+0x17/0x40&#xA;[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]&#xA;[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]&#xA;[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]&#xA;[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]&#xA;CVE-2024-27014:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: Prevent deadlock while disabling aRFS&#xA;When disabling aRFS under the `priv-&gt;state_lock`, any scheduled&#xA;aRFS works are canceled using the `cancel_work_sync` function,&#xA;which waits for the work to end if it has already started.&#xA;However, while waiting for the work handler, the handler will&#xA;try to acquire the `state_lock` which is already acquired.&#xA;The worker acquires the lock to delete the rules if the state&#xA;is down, which is not the worker&#39;s responsibility since&#xA;disabling aRFS deletes the rules.&#xA;Add an aRFS state variable, which indicates whether the aRFS is&#xA;enabled and prevent adding rules when the aRFS is disabled.&#xA;Kernel log: ======================================================&#xA;WARNING: possible circular locking dependency detected&#xA;6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I&#xA;------------------------------------------------------&#xA;ethtool/386089 is trying to acquire lock:&#xA;ffff88810f21ce68 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0&#xA;but task is already holding lock:&#xA;ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]&#xA;which lock already depends on the new lock.&#xA;the existing dependency chain (in reverse order) is:&#xA;-&gt; #1 (&amp;priv-&gt;state_lock){+.+.}-{3:3}:&#xA;       __mutex_lock+0x80/0xc90&#xA;       arfs_handle_work+0x4b/0x3b0 [mlx5_core]&#xA;       process_one_work+0x1dc/0x4a0&#xA;       worker_thread+0x1bf/0x3c0&#xA;       kthread+0xd7/0x100&#xA;       ret_from_fork+0x2d/0x50&#xA;       ret_from_fork_asm+0x11/0x20&#xA;-&gt; #0 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}:&#xA;       __lock_acquire+0x17b4/0x2c80&#xA;       lock_acquire+0xd0/0x2b0&#xA;       __flush_work+0x7a/0x4e0&#xA;       __cancel_work_timer+0x131/0x1c0&#xA;       arfs_del_rules+0x143/0x1e0 [mlx5_core]&#xA;       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]&#xA;       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]&#xA;       ethnl_set_channels+0x28f/0x3b0&#xA;       ethnl_default_set_doit+0xec/0x240&#xA;       genl_family_rcv_msg_doit+0xd0/0x120&#xA;       genl_rcv_msg+0x188/0x2c0&#xA;       netlink_rcv_skb+0x54/0x100&#xA;       genl_rcv+0x24/0x40&#xA;       netlink_unicast+0x1a1/0x270&#xA;       netlink_sendmsg+0x214/0x460&#xA;       __sock_sendmsg+0x38/0x60&#xA;       __sys_sendto+0x113/0x170&#xA;       __x64_sys_sendto+0x20/0x30&#xA;       do_syscall_64+0x40/0xe0&#xA;       entry_SYSCALL_64_after_hwframe+0x46/0x4e&#xA;other info that might help us debug this:&#xA; Possible unsafe locking scenario:&#xA;       CPU0                    CPU1&#xA;       ----                    ----&#xA;  lock(&amp;priv-&gt;state_lock);&#xA;                               lock((work_completion)(&amp;rule-&gt;arfs_work));&#xA;                               lock(&amp;priv-&gt;state_lock);&#xA;  lock((work_completion)(&amp;rule-&gt;arfs_work));&#xA; *** DEADLOCK ***&#xA;3 locks held by ethtool/386089:&#xA; #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40&#xA; #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240&#xA; #2: ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]&#xA;stack backtrace:&#xA;CPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x60/0xa0&#xA; check_noncircular+0x144/0x160&#xA; __lock_acquire+0x17b4/0x2c80&#xA; lock_acquire+0xd0/0x2b0&#xA; ? __flush_work+0x74/0x4e0&#xA; ? save_trace+0x3e/0x360&#xA; ? __flush_work+0x74/0x4e0&#xA; __flush_work+0x7a/0x4e0&#xA; ? __flush_work+0x74/0x4e0&#xA; ? __lock_acquire+0xa78/0x2c80&#xA; ? lock_acquire+0xd0/0x2b0&#xA; ? mark_held_locks+0x49/0x70&#xA; __cancel_work_timer+0x131/0x1c0&#xA; ? mark_held_locks+0x49/0x70&#xA; arfs_del_rules+0x143/0x1e0 [mlx5_core]&#xA; mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]&#xA; mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]&#xA; ethnl_set_channels+0x28f/0x3b0&#xA; ethnl_default_set_doit+0xec/0x240&#xA; genl_family_rcv_msg_doit+0xd0/0x120&#xA; genl_rcv_msg+0x188/0x2c0&#xA; ? ethn&#xA;---truncated---&#xA;CVE-2024-27019:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()&#xA;nft_unregister_obj() can concurrent with __nft_obj_type_get(),&#xA;and there is not any protection when iterate over nf_tables_objects&#xA;list in __nft_obj_type_get(). Therefore, there is potential data-race&#xA;of nf_tables_objects list entry.&#xA;Use list_for_each_entry_rcu() to iterate over nf_tables_objects&#xA;list in __nft_obj_type_get(), and use rcu_read_lock() in the caller&#xA;nft_obj_type_get() to protect the entire type query process.&#xA;CVE-2024-27020:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()&#xA;nft_unregister_expr() can concurrent with __nft_expr_type_get(),&#xA;and there is not any protection when iterate over nf_tables_expressions&#xA;list in __nft_expr_type_get(). Therefore, there is potential data-race&#xA;of nf_tables_expressions list entry.&#xA;Use list_for_each_entry_rcu() to iterate over nf_tables_expressions&#xA;list in __nft_expr_type_get(), and use rcu_read_lock() in the caller&#xA;nft_expr_type_get() to protect the entire type query process.&#xA;CVE-2024-27028:In the Linux kernel, the following vulnerability has been resolved:&#xA;spi: spi-mt65xx: Fix NULL pointer access in interrupt handler&#xA;The TX buffer in spi_transfer can be a NULL pointer, so the interrupt&#xA;handler may end up writing to the invalid memory and cause crashes.&#xA;Add a check to trans-&gt;tx_buf before using it.&#xA;CVE-2024-27030:In the Linux kernel, the following vulnerability has been resolved:&#xA;octeontx2-af: Use separate handlers for interrupts&#xA;For PF to AF interrupt vector and VF to AF vector same&#xA;interrupt handler is registered which is causing race condition.&#xA;When two interrupts are raised to two CPUs at same time&#xA;then two cores serve same event corrupting the data.&#xA;CVE-2024-27032:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to avoid potential panic during recovery&#xA;During recovery, if FAULT_BLOCK is on, it is possible that&#xA;f2fs_reserve_new_block() will return -ENOSPC during recovery,&#xA;then it may trigger panic.&#xA;Also, if fault injection rate is 1 and only FAULT_BLOCK fault&#xA;type is on, it may encounter deadloop in loop of block reservation.&#xA;Let&#39;s change as below to fix these issues:&#xA;- remove bug_on() to avoid panic.&#xA;- limit the loop count of block reservation to avoid potential&#xA;deadloop.&#xA;CVE-2024-27034:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: compress: fix to cover normal cluster write with cp_rwsem&#xA;When we overwrite compressed cluster w/ normal cluster, we should&#xA;not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data&#xA;will be corrupted if partial blocks were persisted before CP &amp; SPOR,&#xA;due to cluster metadata wasn&#39;t updated atomically.&#xA;CVE-2024-27035:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: compress: fix to guarantee persisting compressed blocks by CP&#xA;If data block in compressed cluster is not persisted with metadata&#xA;during checkpoint, after SPOR, the data may be corrupted, let&#39;s&#xA;guarantee to write compressed page by checkpoint.&#xA;CVE-2024-27037:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: zynq: Prevent null pointer dereference caused by kmalloc failure&#xA;The kmalloc() in zynq_clk_setup() will return null if the&#xA;physical memory has run out. As a result, if we use snprintf()&#xA;to write data to the null address, the null pointer dereference&#xA;bug will happen.&#xA;This patch uses a stack variable to replace the kmalloc().&#xA;CVE-2024-27038:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: Fix clk_core_get NULL dereference&#xA;It is possible for clk_core_get to dereference a NULL in the following&#xA;sequence:&#xA;clk_core_get()&#xA;    of_clk_get_hw_from_clkspec()&#xA;        __of_clk_get_hw_from_provider()&#xA;            __clk_get_hw()&#xA;__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at&#xA;hw-&gt;core.&#xA;Prior to commit dde4eff47c82 (&#34;clk: Look for parents with clkdev based&#xA;clk_lookups&#34;) the check IS_ERR_OR_NULL() was performed which would have&#xA;caught the NULL.&#xA;Reading the description of this function it talks about returning NULL but&#xA;that cannot be so at the moment.&#xA;Update the function to check for hw before dereferencing it and return NULL&#xA;if hw is NULL.&#xA;CVE-2024-27046:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfp: flower: handle acti_netdevs allocation failure&#xA;The kmalloc_array() in nfp_fl_lag_do_work() will return null, if&#xA;the physical memory has run out. As a result, if we dereference&#xA;the acti_netdevs, the null pointer dereference bugs will happen.&#xA;This patch adds a check to judge whether allocation failure occurs.&#xA;If it happens, the delayed work will be rescheduled and try again.&#xA;CVE-2024-27051:In the Linux kernel, the following vulnerability has been resolved:&#xA;cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get&#39;s return value&#xA;cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it&#xA;and return 0 in case of error.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-27053:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: wilc1000: fix RCU usage in connect path&#xA;With lockdep enabled, calls to the connect function from cfg802.11 layer&#xA;lead to the following warning: =============================&#xA;WARNING: suspicious RCU usage&#xA;6.7.0-rc1-wt+ #333 Not tainted&#xA;-----------------------------&#xA;drivers/net/wireless/microchip/wilc1000/hif.c:386&#xA;suspicious rcu_dereference_check() usage!&#xA;[...]&#xA;stack backtrace:&#xA;CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333&#xA;Hardware name: Atmel SAMA5&#xA; unwind_backtrace from show_stack+0x18/0x1c&#xA; show_stack from dump_stack_lvl+0x34/0x48&#xA; dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4&#xA; wilc_parse_join_bss_param from connect+0x2c4/0x648&#xA; connect from cfg80211_connect+0x30c/0xb74&#xA; cfg80211_connect from nl80211_connect+0x860/0xa94&#xA; nl80211_connect from genl_rcv_msg+0x3fc/0x59c&#xA; genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8&#xA; netlink_rcv_skb from genl_rcv+0x2c/0x3c&#xA; genl_rcv from netlink_unicast+0x3b0/0x550&#xA; netlink_unicast from netlink_sendmsg+0x368/0x688&#xA; netlink_sendmsg from ____sys_sendmsg+0x190/0x430&#xA; ____sys_sendmsg from ___sys_sendmsg+0x110/0x158&#xA; ___sys_sendmsg from sys_sendmsg+0xe8/0x150&#xA; sys_sendmsg from ret_fast_syscall+0x0/0x1c&#xA;This warning is emitted because in the connect path, when trying to parse&#xA;target BSS parameters, we dereference a RCU pointer whithout being in RCU&#xA;critical section.&#xA;Fix RCU dereference usage by moving it to a RCU read critical section. To&#xA;avoid wrapping the whole wilc_parse_join_bss_param under the critical&#xA;section, just use the critical section to copy ies data&#xA;CVE-2024-27054:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/dasd: fix double module refcount decrement&#xA;Once the discipline is associated with the device, deleting the device&#xA;takes care of decrementing the module&#39;s refcount.  Doing it manually on&#xA;this error path causes refcount to artificially decrease on each error&#xA;while it should just stay the same.&#xA;CVE-2024-27074:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: go7007: fix a memleak in go7007_load_encoder&#xA;In go7007_load_encoder, bounce(i.e. go-&gt;boot_fw), is allocated without&#xA;a deallocation thereafter. After the following call chain:&#xA;saa7134_go7007_init&#xA;  |-&gt; go7007_boot_encoder&#xA;        |-&gt; go7007_load_encoder&#xA;  |-&gt; kfree(go)&#xA;go is freed and thus bounce is leaked.&#xA;CVE-2024-27077:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity&#xA;The entity-&gt;name (i.e. name) is allocated in v4l2_m2m_register_entity&#xA;but isn&#39;t freed in its following error-handling paths. This patch&#xA;adds such deallocation to prevent memleak of entity-&gt;name.&#xA;CVE-2024-35935:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: send: handle path ref underflow in header iterate_inode_ref()&#xA;Change BUG_ON to proper error handling if building the path buffer&#xA;fails. The pointers are not printed so we don&#39;t accidentally leak kernel&#xA;addresses.&#xA;CVE-2024-35973:In the Linux kernel, the following vulnerability has been resolved:&#xA;geneve: fix header validation in geneve[6]_xmit_skb&#xA;syzbot is able to trigger an uninit-value in geneve_xmit() [1]&#xA;Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())&#xA;uses skb_protocol(skb, true), pskb_inet_may_pull() is only using&#xA;skb-&gt;protocol.&#xA;If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&gt;protocol,&#xA;pskb_inet_may_pull() does nothing at all.&#xA;If a vlan tag was provided by the caller (af_packet in the syzbot case),&#xA;the network header might not point to the correct location, and skb&#xA;linear part could be smaller than expected.&#xA;Add skb_vlan_inet_prepare() to perform a complete mac validation.&#xA;Use this in geneve for the moment, I suspect we need to adopt this&#xA;more broadly.&#xA;v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest&#xA;   - Only call __vlan_get_protocol() for vlan types.&#xA;v2,v3 - Addressed Sabrina comments on v1 and v2&#xA;[1]&#xA;BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]&#xA; BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030&#xA;  geneve_xmit_skb drivers/net/geneve.c:910 [inline]&#xA;  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030&#xA;  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:4917 [inline]&#xA;  xmit_one net/core/dev.c:3531 [inline]&#xA;  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547&#xA;  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335&#xA;  dev_queue_xmit include/linux/netdevice.h:3091 [inline]&#xA;  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276&#xA;  packet_snd net/packet/af_packet.c:3081 [inline]&#xA;  packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:745&#xA;  __sys_sendto+0x685/0x830 net/socket.c:2191&#xA;  __do_sys_sendto net/socket.c:2203 [inline]&#xA;  __se_sys_sendto net/socket.c:2199 [inline]&#xA;  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:3804 [inline]&#xA;  slab_alloc_node mm/slub.c:3845 [inline]&#xA;  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577&#xA;  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668&#xA;  alloc_skb include/linux/skbuff.h:1318 [inline]&#xA;  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504&#xA;  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795&#xA;  packet_alloc_skb net/packet/af_packet.c:2930 [inline]&#xA;  packet_snd net/packet/af_packet.c:3024 [inline]&#xA;  packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:745&#xA;  __sys_sendto+0x685/0x830 net/socket.c:2191&#xA;  __do_sys_sendto net/socket.c:2203 [inline]&#xA;  __se_sys_sendto net/socket.c:2199 [inline]&#xA;  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024&#xA;CVE-2024-35978:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: Fix memory leak in hci_req_sync_complete()&#xA;In &#39;hci_req_sync_complete()&#39;, always free the previous sync&#xA;request state before assigning reference to a new one.&#xA;CVE-2024-35982:In the Linux kernel, the following vulnerability has been resolved:&#xA;batman-adv: Avoid infinite loop trying to resize local TT&#xA;If the MTU of one of an attached interface becomes too small to transmit&#xA;the local translation table then it must be resized to fit inside all&#xA;fragments (when enabled) or a single packet.&#xA;But if the MTU becomes too low to transmit even the header + the VLAN&#xA;specific part then the resizing of the local TT will never succeed. This&#xA;can for example happen when the usable space is 110 bytes and 11 VLANs are&#xA;on top of batman-adv. In this case, at least 116 byte would be needed.&#xA;There will just be an endless spam of&#xA;   batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)&#xA;in the log but the function will never finish. Problem here is that the&#xA;timeout will be halved all the time and will then stagnate at 0 and&#xA;therefore never be able to reduce the table even more.&#xA;There are other scenarios possible with a similar result. The number of&#xA;BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too&#xA;high to fit inside a packet. Such a scenario can therefore happen also with&#xA;only a single VLAN + 7 non-purgable addresses - requiring at least 120&#xA;bytes.&#xA;While this should be handled proactively when:&#xA;* interface with too low MTU is added&#xA;* VLAN is added&#xA;* non-purgeable local mac is added&#xA;* MTU of an attached interface is reduced&#xA;* fragmentation setting gets disabled (which most likely requires dropping&#xA;  attached interfaces)&#xA;not all of these scenarios can be prevented because batman-adv is only&#xA;consuming events without the the possibility to prevent these actions&#xA;(non-purgable MAC address added, MTU of an attached interface is reduced).&#xA;It is therefore necessary to also make sure that the code is able to handle&#xA;also the situations when there were already incompatible system&#xA;configuration are present.&#xA;CVE-2024-35984:In the Linux kernel, the following vulnerability has been resolved:&#xA;i2c: smbus: fix NULL function pointer dereference&#xA;Baruch reported an OOPS when using the designware controller as target&#xA;only. Target-only modes break the assumption of one transfer function&#xA;always being available. Fix this by always checking the pointer in&#xA;__i2c_transfer.&#xA;[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]&#xA;CVE-2024-35990:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma: xilinx_dpdma: Fix locking&#xA;There are several places where either chan-&gt;lock or chan-&gt;vchan.lock was&#xA;not held. Add appropriate locking. This fixes lockdep warnings like&#xA;[   31.077578] ------------[ cut here ]------------&#xA;[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0&#xA;[   31.077953] Modules linked in:&#xA;[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98&#xA;[   31.078102] Hardware name: xlnx,zynqmp (DT)&#xA;[   31.078169] Workqueue: events_unbound deferred_probe_work_func&#xA;[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0&#xA;[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0&#xA;[   31.078550] sp : ffffffc083bb2e10&#xA;[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168&#xA;[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480&#xA;[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000&#xA;[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000&#xA;[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001&#xA;[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def&#xA;[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516&#xA;[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff&#xA;[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000&#xA;[   31.080307] Call trace:&#xA;[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0&#xA;[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120&#xA;[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac&#xA;[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c&#xA;[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684&#xA;[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0&#xA;[   31.081139]  commit_tail+0x234/0x294&#xA;[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210&#xA;[   31.081363]  drm_atomic_commit+0x100/0x140&#xA;[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384&#xA;[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c&#xA;[   31.081725]  drm_client_modeset_commit+0x34/0x5c&#xA;[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168&#xA;[   31.081899]  drm_fb_helper_set_par+0x50/0x70&#xA;[   31.081971]  fbcon_init+0x538/0xc48&#xA;[   31.082047]  visual_init+0x16c/0x23c&#xA;[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634&#xA;[   31.082320]  do_take_over_console+0x24c/0x33c&#xA;[   31.082429]  do_fbcon_takeover+0xbc/0x1b0&#xA;[   31.082503]  fbcon_fb_registered+0x2d0/0x34c&#xA;[   31.082663]  register_framebuffer+0x27c/0x38c&#xA;[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c&#xA;[   31.082939]  drm_fb_helper_initial_config+0x50/0x74&#xA;[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108&#xA;[   31.083115]  drm_client_register+0xa0/0xf4&#xA;[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc&#xA;[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0&#xA;[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0&#xA;[   31.083616]  platform_probe+0x8c/0x13c&#xA;[   31.083713]  really_probe+0x258/0x59c&#xA;[   31.083793]  __driver_probe_device+0xc4/0x224&#xA;[   31.083878]  driver_probe_device+0x70/0x1c0&#xA;[   31.083961]  __device_attach_driver+0x108/0x1e0&#xA;[   31.084052]  bus_for_each_drv+0x9c/0x100&#xA;[   31.084125]  __device_attach+0x100/0x298&#xA;[   31.084207]  device_initial_probe+0x14/0x20&#xA;[   31.084292]  bus_probe_device+0xd8/0xdc&#xA;[   31.084368]  deferred_probe_work_func+0x11c/0x180&#xA;[   31.084451]  process_one_work+0x3ac/0x988&#xA;[   31.084643]  worker_thread+0x398/0x694&#xA;[   31.084752]  kthread+0x1bc/0x1c0&#xA;[   31.084848]  ret_from_fork+0x10/0x20&#xA;[   31.084932] irq event stamp: 64549&#xA;[   31.084970] hardirqs last  enabled at (64548): [&lt;ffffffc081adf35c&gt;] _raw_spin_unlock_irqrestore+0x80/0x90&#xA;[   31.085157]&#xA;---truncated---&#xA;CVE-2024-36008:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv4: check for NULL idev in ip_route_use_hint()&#xA;syzbot was able to trigger a NULL deref in fib_validate_source()&#xA;in an old tree [1].&#xA;It appears the bug exists in latest trees.&#xA;All calls to __in_dev_get_rcu() must be checked for a NULL result.&#xA;[1]&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA; RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425&#xA;Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 &lt;42&gt; 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf&#xA;RSP: 0018:ffffc900015fee40 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0&#xA;RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0&#xA;RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000&#xA;R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000&#xA;FS:  00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA;  ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231&#xA;  ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327&#xA;  ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]&#xA;  ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638&#xA;  ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673&#xA;  __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]&#xA;  __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620&#xA;  __netif_receive_skb_list net/core/dev.c:5672 [inline]&#xA;  netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764&#xA;  netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816&#xA;  xdp_recv_frames net/bpf/test_run.c:257 [inline]&#xA;  xdp_test_run_batch net/bpf/test_run.c:335 [inline]&#xA;  bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363&#xA;  bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376&#xA;  bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736&#xA;  __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115&#xA;  __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]&#xA;  __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]&#xA;  __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199&#xA;CVE-2024-36954:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: fix a possible memleak in tipc_buf_append&#xA;__skb_linearize() doesn&#39;t free the skb when it fails, so move&#xA;&#39;*buf = NULL&#39; after __skb_linearize(), so that the skb can be&#xA;freed on the err path.&#xA;CVE-2021-47421:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume&#xA;In current code, when a PCI error state pci_channel_io_normal is detectd,&#xA;it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI&#xA;driver will continue the execution of PCI resume callback report_resume by&#xA;pci_walk_bridge, and the callback will go into amdgpu_pci_resume&#xA;finally, where write lock is releasd unconditionally without acquiring&#xA;such lock first. In this case, a deadlock will happen when other threads&#xA;start to acquire the read lock.&#xA;To fix this, add a member in amdgpu_device strucutre to cache&#xA;pci_channel_state, and only continue the execution in amdgpu_pci_resume&#xA;when it&#39;s pci_channel_io_frozen.&#xA;CVE-2021-47455:In the Linux kernel, the following vulnerability has been resolved:&#xA;ptp: Fix possible memory leak in ptp_clock_register()&#xA;I got memory leak as follows when doing fault injection test:&#xA;unreferenced object 0xffff88800906c618 (size 8):&#xA;  comm &#34;i2c-idt82p33931&#34;, pid 4421, jiffies 4294948083 (age 13.188s)&#xA;  hex dump (first 8 bytes):&#xA;    70 74 70 30 00 00 00 00                          ptp0....&#xA;  backtrace:&#xA;    [&lt;00000000312ed458&gt;] __kmalloc_track_caller+0x19f/0x3a0&#xA;    [&lt;0000000079f6e2ff&gt;] kvasprintf+0xb5/0x150&#xA;    [&lt;0000000026aae54f&gt;] kvasprintf_const+0x60/0x190&#xA;    [&lt;00000000f323a5f7&gt;] kobject_set_name_vargs+0x56/0x150&#xA;    [&lt;000000004e35abdd&gt;] dev_set_name+0xc0/0x100&#xA;    [&lt;00000000f20cfe25&gt;] ptp_clock_register+0x9f4/0xd30 [ptp]&#xA;    [&lt;000000008bb9f0de&gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]&#xA;When posix_clock_register() returns an error, the name allocated&#xA;in dev_set_name() will be leaked, the put_device() should be used&#xA;to give up the device reference, then the name will be freed in&#xA;kobject_cleanup() and other memory will be freed in ptp_clock_release().&#xA;CVE-2022-48659:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/slub: fix to return errno if kmalloc() fails&#xA;In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to&#xA;out-of-memory, if it fails, return errno correctly rather than&#xA;triggering panic via BUG_ON();&#xA;kernel BUG at mm/slub.c:5893!&#xA;Internal error: Oops - BUG: 0 [#1] PREEMPT SMP&#xA;Call trace:&#xA; sysfs_slab_add+0x258/0x260 mm/slub.c:5973&#xA; __kmem_cache_create+0x60/0x118 mm/slub.c:4899&#xA; create_cache mm/slab_common.c:229 [inline]&#xA; kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335&#xA; kmem_cache_create+0x1c/0x28 mm/slab_common.c:390&#xA; f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]&#xA; f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808&#xA; f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149&#xA; mount_bdev+0x1b8/0x210 fs/super.c:1400&#xA; f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512&#xA; legacy_get_tree+0x30/0x74 fs/fs_context.c:610&#xA; vfs_get_tree+0x40/0x140 fs/super.c:1530&#xA; do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040&#xA; path_mount+0x358/0x914 fs/namespace.c:3370&#xA; do_mount fs/namespace.c:3383 [inline]&#xA; __do_sys_mount fs/namespace.c:3591 [inline]&#xA; __se_sys_mount fs/namespace.c:3568 [inline]&#xA; __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568&#xA;CVE-2022-48660:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully&#xA;When running gpio test on nxp-ls1028 platform with below command&#xA;gpiomon --num-events=3 --rising-edge gpiochip1 25&#xA;There will be a warning trace as below:&#xA;Call trace:&#xA;free_irq+0x204/0x360&#xA;lineevent_free+0x64/0x70&#xA;gpio_ioctl+0x598/0x6a0&#xA;__arm64_sys_ioctl+0xb4/0x100&#xA;invoke_syscall+0x5c/0x130&#xA;......&#xA;el0t_64_sync+0x1a0/0x1a4&#xA;The reason of this issue is that calling request_threaded_irq()&#xA;function failed, and then lineevent_free() is invoked to release&#xA;the resource. Since the lineevent_state::irq was already set, so&#xA;the subsequent invocation of free_irq() would trigger the above&#xA;warning call trace. To fix this issue, set the lineevent_state::irq&#xA;after the IRQ register successfully.&#xA;CVE-2022-48708:In the Linux kernel, the following vulnerability has been resolved:&#xA;pinctrl: single: fix potential NULL dereference&#xA;Added checking of pointer &#34;function&#34; in pcs_set_mux().&#xA;pinmux_generic_get_function() can return NULL and the pointer&#xA;&#34;function&#34; was dereferenced without checking against NULL.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2023-52609:In the Linux kernel, the following vulnerability has been resolved:&#xA;binder: fix race between mmput() and do_exit()&#xA;Task A calls binder_update_page_range() to allocate and insert pages on&#xA;a remote address space from Task B. For this, Task A pins the remote mm&#xA;via mmget_not_zero() first. This can race with Task B do_exit() and the&#xA;final mmput() refcount decrement will come from Task A.&#xA;  Task A            | Task B&#xA;  ------------------+------------------&#xA;  mmget_not_zero()  |&#xA;                    |  do_exit()&#xA;                    |    exit_mm()&#xA;                    |      mmput()&#xA;  mmput()           |&#xA;    exit_mmap()     |&#xA;      remove_vma()  |&#xA;        fput()      |&#xA;In this case, the work of ____fput() from Task B is queued up in Task A&#xA;as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup&#xA;work gets executed. However, Task A instead sleep, waiting for a reply&#xA;from Task B that never comes (it&#39;s dead).&#xA;This means the binder_deferred_release() is blocked until an unrelated&#xA;binder event forces Task A to go back to userspace. All the associated&#xA;death notifications will also be delayed until then.&#xA;In order to fix this use mmput_async() that will schedule the work in&#xA;the corresponding mm-&gt;async_put_work WQ instead of Task A.&#xA;CVE-2023-52615:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwrng: core - Fix page fault dead lock on mmap-ed hwrng&#xA;There is a dead-lock in the hwrng device read path.  This triggers&#xA;when the user reads from /dev/hwrng into memory also mmap-ed from&#xA;/dev/hwrng.  The resulting page fault triggers a recursive read&#xA;which then dead-locks.&#xA;Fix this by using a stack buffer when calling copy_to_user.&#xA;CVE-2023-52616:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init&#xA;When the mpi_ec_ctx structure is initialized, some fields are not&#xA;cleared, causing a crash when referencing the field when the&#xA;structure was released. Initially, this issue was ignored because&#xA;memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.&#xA;For example, this error will be triggered when calculating the&#xA;Za value for SM2 separately.&#xA;CVE-2023-52618:In the Linux kernel, the following vulnerability has been resolved:&#xA;block/rnbd-srv: Check for unlikely string overflow&#xA;Since &#34;dev_search_path&#34; can technically be as large as PATH_MAX,&#xA;there was a risk of truncation when copying it and a second string&#xA;into &#34;full_path&#34; since it was also PATH_MAX sized. The W=1 builds were&#xA;reporting this warning:&#xA;drivers/block/rnbd/rnbd-srv.c: In function &#39;process_msg_open.isra&#39;:&#xA;drivers/block/rnbd/rnbd-srv.c:616:51: warning: &#39;%s&#39; directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]&#xA;  616 |                 snprintf(full_path, PATH_MAX, &#34;%s/%s&#34;,&#xA;      |                                                   ^~&#xA;In function &#39;rnbd_srv_get_full_path&#39;,&#xA;    inlined from &#39;process_msg_open.isra&#39; at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: &#39;snprintf&#39; output between 2 and 4351 bytes into a destination of size 4096&#xA;  616 |                 snprintf(full_path, PATH_MAX, &#34;%s/%s&#34;,&#xA;      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~&#xA;  617 |                          dev_search_path, dev_name);&#xA;      |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~&#xA;To fix this, unconditionally check for truncation (as was already done&#xA;for the case where &#34;%SESSNAME%&#34; was present).&#xA;CVE-2023-52621:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers&#xA;These three bpf_map_{lookup,update,delete}_elem() helpers are also&#xA;available for sleepable bpf program, so add the corresponding lock&#xA;assertion for sleepable bpf program, otherwise the following warning&#xA;will be reported when a sleepable bpf program manipulates bpf map under&#xA;interpreter mode (aka bpf_jit_enable=0):&#xA;  WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......&#xA;  CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......&#xA;  RIP: 0010:bpf_map_lookup_elem+0x54/0x60&#xA;  ......&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? __warn+0xa5/0x240&#xA;   ? bpf_map_lookup_elem+0x54/0x60&#xA;   ? report_bug+0x1ba/0x1f0&#xA;   ? handle_bug+0x40/0x80&#xA;   ? exc_invalid_op+0x18/0x50&#xA;   ? asm_exc_invalid_op+0x1b/0x20&#xA;   ? __pfx_bpf_map_lookup_elem+0x10/0x10&#xA;   ? rcu_lockdep_current_cpu_online+0x65/0xb0&#xA;   ? rcu_is_watching+0x23/0x50&#xA;   ? bpf_map_lookup_elem+0x54/0x60&#xA;   ? __pfx_bpf_map_lookup_elem+0x10/0x10&#xA;   ___bpf_prog_run+0x513/0x3b70&#xA;   __bpf_prog_run32+0x9d/0xd0&#xA;   ? __bpf_prog_enter_sleepable_recur+0xad/0x120&#xA;   ? __bpf_prog_enter_sleepable_recur+0x3e/0x120&#xA;   bpf_trampoline_6442580665+0x4d/0x1000&#xA;   __x64_sys_getpgid+0x5/0x30&#xA;   ? do_syscall_64+0x36/0xb0&#xA;   entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;   &lt;/TASK&gt;&#xA;CVE-2023-52623:In the Linux kernel, the following vulnerability has been resolved:&#xA;SUNRPC: Fix a suspicious RCU usage warning&#xA;I received the following warning while running cthon against an ontap&#xA;server running pNFS:&#xA;[   57.202521] =============================&#xA;[   57.202522] WARNING: suspicious RCU usage&#xA;[   57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted&#xA;[   57.202525] -----------------------------&#xA;[   57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!&#xA;[   57.202527]&#xA;               other info that might help us debug this:&#xA;[   57.202528]&#xA;               rcu_scheduler_active = 2, debug_locks = 1&#xA;[   57.202529] no locks held by test5/3567.&#xA;[   57.202530]&#xA;               stack backtrace:&#xA;[   57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e&#xA;[   57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022&#xA;[   57.202536] Call Trace:&#xA;[   57.202537]  &lt;TASK&gt;&#xA;[   57.202540]  dump_stack_lvl+0x77/0xb0&#xA;[   57.202551]  lockdep_rcu_suspicious+0x154/0x1a0&#xA;[   57.202556]  rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]&#xA;[   57.202596]  rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]&#xA;[   57.202621]  ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]&#xA;[   57.202646]  rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]&#xA;[   57.202671]  ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]&#xA;[   57.202696]  nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]&#xA;[   57.202728]  ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]&#xA;[   57.202754]  nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]&#xA;[   57.202760]  filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]&#xA;[   57.202765]  pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]&#xA;[   57.202788]  __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202813]  nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202831]  nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202849]  nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202866]  write_cache_pages+0x265/0x450&#xA;[   57.202870]  ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202891]  nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202913]  do_writepages+0xd2/0x230&#xA;[   57.202917]  ? filemap_fdatawrite_wbc+0x5c/0x80&#xA;[   57.202921]  filemap_fdatawrite_wbc+0x67/0x80&#xA;[   57.202924]  filemap_write_and_wait_range+0xd9/0x170&#xA;[   57.202930]  nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]&#xA;[   57.202947]  nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]&#xA;[   57.202969]  __se_sys_close+0x46/0xd0&#xA;[   57.202972]  do_syscall_64+0x68/0x100&#xA;[   57.202975]  ? do_syscall_64+0x77/0x100&#xA;[   57.202976]  ? do_syscall_64+0x77/0x100&#xA;[   57.202979]  entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;[   57.202982] RIP: 0033:0x7fe2b12e4a94&#xA;[   57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3&#xA;[   57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003&#xA;[   57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94&#xA;[   57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003&#xA;[   57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49&#xA;[   57.202993] R10: 00007f&#xA;---truncated---&#xA;CVE-2023-52629:In the Linux kernel, the following vulnerability has been resolved:&#xA;sh: push-switch: Reorder cleanup operations to avoid use-after-free bug&#xA;The original code puts flush_work() before timer_shutdown_sync()&#xA;in switch_drv_remove(). Although we use flush_work() to stop&#xA;the worker, it could be rescheduled in switch_timer(). As a result,&#xA;a use-after-free bug can occur. The details are shown below:&#xA;      (cpu 0)                    |      (cpu 1)&#xA;switch_drv_remove()              |&#xA; flush_work()                    |&#xA;  ...                            |  switch_timer // timer&#xA;                                 |   schedule_work(&amp;psw-&gt;work)&#xA; timer_shutdown_sync()           |&#xA; ...                             |  switch_work_handler // worker&#xA; kfree(psw) // free              |&#xA;                                 |   psw-&gt;state = 0 // use&#xA;This patch puts timer_shutdown_sync() before flush_work() to&#xA;mitigate the bugs. As a result, the worker and timer will be&#xA;stopped safely before the deallocate operations.&#xA;CVE-2023-52630:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2023-52633:In the Linux kernel, the following vulnerability has been resolved:&#xA;um: time-travel: fix time corruption&#xA;In &#39;basic&#39; time-travel mode (without =inf-cpu or =ext), we&#xA;still get timer interrupts. These can happen at arbitrary&#xA;points in time, i.e. while in timer_read(), which pushes&#xA;time forward just a little bit. Then, if we happen to get&#xA;the interrupt after calculating the new time to push to,&#xA;but before actually finishing that, the interrupt will set&#xA;the time to a value that&#39;s incompatible with the forward,&#xA;and we&#39;ll crash because time goes backwards when we do the&#xA;forwarding.&#xA;Fix this by reading the time_travel_time, calculating the&#xA;adjustment, and doing the adjustment all with interrupts&#xA;disabled.&#xA;CVE-2023-52635:In the Linux kernel, the following vulnerability has been resolved:&#xA;PM / devfreq: Synchronize devfreq_monitor_[start/stop]&#xA;There is a chance if a frequent switch of the governor&#xA;done in a loop result in timer list corruption where&#xA;timer cancel being done from two place one from&#xA;cancel_delayed_work_sync() and followed by expire_timers()&#xA;can be seen from the traces[1].&#xA;while true&#xA;do&#xA;        echo &#34;simple_ondemand&#34; &gt; /sys/class/devfreq/1d84000.ufshc/governor&#xA;        echo &#34;performance&#34; &gt; /sys/class/devfreq/1d84000.ufshc/governor&#xA;done&#xA;It looks to be issue with devfreq driver where&#xA;device_monitor_[start/stop] need to synchronized so that&#xA;delayed work should get corrupted while it is either&#xA;being queued or running or being cancelled.&#xA;Let&#39;s use polling flag and devfreq lock to synchronize the&#xA;queueing the timer instance twice and work data being&#xA;corrupted.&#xA;[1]&#xA;...&#xA;..&#xA;&lt;idle&gt;-0    [003]   9436.209662:  timer_cancel timer=0xffffff80444f0428&#xA;&lt;idle&gt;-0    [003]   9436.209664:  timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c&#xA;&lt;idle&gt;-0    [003]   9436.209718:  timer_expire_exit timer=0xffffff80444f0428&#xA;kworker/u16:6-14217    [003]   9436.209863:  timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227&#xA;vendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel timer=0xffffff80444f0428&#xA;vendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init timer=0xffffff80444f0428&#xA;vendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532&#xA;vendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel timer=0xffffff80444f0428&#xA;xxxyyyTraceManag-7795    [004]   9436.261641:  timer_cancel timer=0xffffff80444f0428&#xA;[2]&#xA; 9436.261653][    C4] Unable to handle kernel paging request at virtual address dead00000000012a&#xA;[ 9436.261664][    C4] Mem abort info:&#xA;[ 9436.261666][    C4]   ESR = 0x96000044&#xA;[ 9436.261669][    C4]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[ 9436.261671][    C4]   SET = 0, FnV = 0&#xA;[ 9436.261673][    C4]   EA = 0, S1PTW = 0&#xA;[ 9436.261675][    C4] Data abort info:&#xA;[ 9436.261677][    C4]   ISV = 0, ISS = 0x00000044&#xA;[ 9436.261680][    C4]   CM = 0, WnR = 1&#xA;[ 9436.261682][    C4] [dead00000000012a] address between user and kernel address ranges&#xA;[ 9436.261685][    C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP&#xA;[ 9436.261701][    C4] Skip md ftrace buffer dump for: 0x3a982d0&#xA;...&#xA;[ 9436.262138][    C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S      W  O      5.10.149-android12-9-o-g17f915d29d0c #1&#xA;[ 9436.262141][    C4] Hardware name: Qualcomm Technologies, Inc.  (DT)&#xA;[ 9436.262144][    C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)&#xA;[ 9436.262161][    C4] pc : expire_timers+0x9c/0x438&#xA;[ 9436.262164][    C4] lr : expire_timers+0x2a4/0x438&#xA;[ 9436.262168][    C4] sp : ffffffc010023dd0&#xA;[ 9436.262171][    C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18&#xA;[ 9436.262178][    C4] x27: ffffffd063569dd0 x26: ffffffd063536008&#xA;[ 9436.262182][    C4] x25: 0000000000000001 x24: ffffff88f7c69280&#xA;[ 9436.262185][    C4] x23: 00000000000000e0 x22: dead000000000122&#xA;[ 9436.262188][    C4] x21: 000000010022da29 x20: ffffff8af72b4e80&#xA;[ 9436.262191][    C4] x19: ffffffc010023e50 x18: ffffffc010025038&#xA;[ 9436.262195][    C4] x17: 0000000000000240 x16: 0000000000000201&#xA;[ 9436.262199][    C4] x15: ffffffffffffffff x14: ffffff889f3c3100&#xA;[ 9436.262203][    C4] x13: ffffff889f3c3100 x12: 00000000049f56b8&#xA;[ 9436.262207][    C4] x11: 00000000049f56b8 x10: 00000000ffffffff&#xA;[ 9436.262212][    C4] x9 : ffffffc010023e50 x8 : dead000000000122&#xA;[ 9436.262216][    C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8&#xA;[ 9436.262220][    C4] x5 : 0000000000000000 x4 : 0000000000000101&#xA;[ 9436.262223][    C4] x3 : 0000000000000080 x2 : ffffff8&#xA;---truncated---&#xA;CVE-2023-52637:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)&#xA;Lock jsk-&gt;sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)&#xA;modifies jsk-&gt;filters while receiving packets.&#xA;Following trace was seen on affected system:&#xA; ==================================================================&#xA; BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]&#xA; Read of size 4 at addr ffff888012144014 by task j1939/350&#xA; CPU: 0 PID: 350 Comm: j1939 Tainted: G        W  OE      6.5.0-rc5 #1&#xA; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014&#xA; Call Trace:&#xA;  print_report+0xd3/0x620&#xA;  ? kasan_complete_mode_report_info+0x7d/0x200&#xA;  ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]&#xA;  kasan_report+0xc2/0x100&#xA;  ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]&#xA;  __asan_load4+0x84/0xb0&#xA;  j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]&#xA;  j1939_sk_recv+0x20b/0x320 [can_j1939]&#xA;  ? __kasan_check_write+0x18/0x20&#xA;  ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]&#xA;  ? j1939_simple_recv+0x69/0x280 [can_j1939]&#xA;  ? j1939_ac_recv+0x5e/0x310 [can_j1939]&#xA;  j1939_can_recv+0x43f/0x580 [can_j1939]&#xA;  ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]&#xA;  ? raw_rcv+0x42/0x3c0 [can_raw]&#xA;  ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]&#xA;  can_rcv_filter+0x11f/0x350 [can]&#xA;  can_receive+0x12f/0x190 [can]&#xA;  ? __pfx_can_rcv+0x10/0x10 [can]&#xA;  can_rcv+0xdd/0x130 [can]&#xA;  ? __pfx_can_rcv+0x10/0x10 [can]&#xA;  __netif_receive_skb_one_core+0x13d/0x150&#xA;  ? __pfx___netif_receive_skb_one_core+0x10/0x10&#xA;  ? __kasan_check_write+0x18/0x20&#xA;  ? _raw_spin_lock_irq+0x8c/0xe0&#xA;  __netif_receive_skb+0x23/0xb0&#xA;  process_backlog+0x107/0x260&#xA;  __napi_poll+0x69/0x310&#xA;  net_rx_action+0x2a1/0x580&#xA;  ? __pfx_net_rx_action+0x10/0x10&#xA;  ? __pfx__raw_spin_lock+0x10/0x10&#xA;  ? handle_irq_event+0x7d/0xa0&#xA;  __do_softirq+0xf3/0x3f8&#xA;  do_softirq+0x53/0x80&#xA;  &lt;/IRQ&gt;&#xA;  &lt;TASK&gt;&#xA;  __local_bh_enable_ip+0x6e/0x70&#xA;  netif_rx+0x16b/0x180&#xA;  can_send+0x32b/0x520 [can]&#xA;  ? __pfx_can_send+0x10/0x10 [can]&#xA;  ? __check_object_size+0x299/0x410&#xA;  raw_sendmsg+0x572/0x6d0 [can_raw]&#xA;  ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]&#xA;  ? apparmor_socket_sendmsg+0x2f/0x40&#xA;  ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]&#xA;  sock_sendmsg+0xef/0x100&#xA;  sock_write_iter+0x162/0x220&#xA;  ? __pfx_sock_write_iter+0x10/0x10&#xA;  ? __rtnl_unlock+0x47/0x80&#xA;  ? security_file_permission+0x54/0x320&#xA;  vfs_write+0x6ba/0x750&#xA;  ? __pfx_vfs_write+0x10/0x10&#xA;  ? __fget_light+0x1ca/0x1f0&#xA;  ? __rcu_read_unlock+0x5b/0x280&#xA;  ksys_write+0x143/0x170&#xA;  ? __pfx_ksys_write+0x10/0x10&#xA;  ? __kasan_check_read+0x15/0x20&#xA;  ? fpregs_assert_state_consistent+0x62/0x70&#xA;  __x64_sys_write+0x47/0x60&#xA;  do_syscall_64+0x60/0x90&#xA;  ? do_syscall_64+0x6d/0x90&#xA;  ? irqentry_exit+0x3f/0x50&#xA;  ? exc_page_fault+0x79/0xf0&#xA;  entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA; Allocated by task 348:&#xA;  kasan_save_stack+0x2a/0x50&#xA;  kasan_set_track+0x29/0x40&#xA;  kasan_save_alloc_info+0x1f/0x30&#xA;  __kasan_kmalloc+0xb5/0xc0&#xA;  __kmalloc_node_track_caller+0x67/0x160&#xA;  j1939_sk_setsockopt+0x284/0x450 [can_j1939]&#xA;  __sys_setsockopt+0x15c/0x2f0&#xA;  __x64_sys_setsockopt+0x6b/0x80&#xA;  do_syscall_64+0x60/0x90&#xA;  entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA; Freed by task 349:&#xA;  kasan_save_stack+0x2a/0x50&#xA;  kasan_set_track+0x29/0x40&#xA;  kasan_save_free_info+0x2f/0x50&#xA;  __kasan_slab_free+0x12e/0x1c0&#xA;  __kmem_cache_free+0x1b9/0x380&#xA;  kfree+0x7a/0x120&#xA;  j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]&#xA;  __sys_setsockopt+0x15c/0x2f0&#xA;  __x64_sys_setsockopt+0x6b/0x80&#xA;  do_syscall_64+0x60/0x90&#xA;  entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;CVE-2023-52639:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: s390: vsie: fix race during shadow creation&#xA;Right now it is possible to see gmap-&gt;private being zero in&#xA;kvm_s390_vsie_gmap_notifier resulting in a crash.  This is due to the&#xA;fact that we add gmap-&gt;private == kvm after creation:&#xA;static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,&#xA;                               struct vsie_page *vsie_page)&#xA;{&#xA;[...]&#xA;        gmap = gmap_shadow(vcpu-&gt;arch.gmap, asce, edat);&#xA;        if (IS_ERR(gmap))&#xA;                return PTR_ERR(gmap);&#xA;        gmap-&gt;private = vcpu-&gt;kvm;&#xA;Let children inherit the private field of the parent.&#xA;CVE-2023-52644:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled&#xA;When QoS is disabled, the queue priority value will not map to the correct&#xA;ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS&#xA;is disabled to prevent trying to stop/wake a non-existent queue and failing&#xA;to stop/wake the actual queue instantiated.&#xA;Log of issue before change (with kernel parameter qos=0):&#xA;    [  +5.112651] ------------[ cut here ]------------&#xA;    [  +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]&#xA;    [  +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3&#xA;    [  +0.000044]  videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common&#xA;    [  +0.000055]  usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]&#xA;    [  +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G        W  O       6.6.7 #1-NixOS&#xA;    [  +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019&#xA;    [  +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]&#xA;    [  +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 &lt;0f&gt; 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00&#xA;    [  +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097&#xA;    [  +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000&#xA;    [  +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900&#xA;    [  +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0&#xA;    [  +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000&#xA;    [  +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40&#xA;    [  +0.000001] FS:  0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000&#xA;    [  +0.000001] CS:  0010 DS: 0&#xA;---truncated---&#xA;CVE-2023-52656:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring: drop any code related to SCM_RIGHTS&#xA;This is dead code after we dropped support for passing io_uring fds&#xA;over SCM_RIGHTS, get rid of it.&#xA;CVE-2023-52664:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: atlantic: eliminate double free in error handling logic&#xA;Driver has a logic leak in ring data allocation/free,&#xA;where aq_ring_free could be called multiple times on same ring,&#xA;if system is under stress and got memory allocation error.&#xA;Ring pointer was used as an indicator of failure, but this is&#xA;not correct since only ring data is allocated/deallocated.&#xA;Ring itself is an array member.&#xA;Changing ring allocation functions to return error code directly.&#xA;This simplifies error handling and eliminates aq_ring_free&#xA;on higher layer.&#xA;CVE-2023-52675:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/imc-pmu: Add a null pointer check in update_events_in_group()&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure.&#xA;CVE-2023-52676:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Guard stack limits against 32bit overflow&#xA;This patch promotes the arithmetic around checking stack bounds to be&#xA;done in the 64-bit domain, instead of the current 32bit. The arithmetic&#xA;implies adding together a 64-bit register with a int offset. The&#xA;register was checked to be below 1&lt;&lt;29 when it was variable, but not&#xA;when it was fixed. The offset either comes from an instruction (in which&#xA;case it is 16 bit), from another register (in which case the caller&#xA;checked it to be below 1&lt;&lt;29 [1]), or from the size of an argument to a&#xA;kfunc (in which case it can be a u32 [2]). Between the register being&#xA;inconsistently checked to be below 1&lt;&lt;29, and the offset being up to an&#xA;u32, it appears that we were open to overflowing the `int`s which were&#xA;currently used for arithmetic.&#xA;[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498&#xA;[2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904&#xA;CVE-2023-52683:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPI: LPIT: Avoid u32 multiplication overflow&#xA;In lpit_update_residency() there is a possibility of overflow&#xA;in multiplication, if tsc_khz is large enough (&gt; UINT_MAX/1000).&#xA;Change multiplication to mul_u32_u32().&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2023-52685:In the Linux kernel, the following vulnerability has been resolved:&#xA;pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()&#xA;In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return&#xA;64-bit value since persistent_ram_zone::buffer_size has type size_t which&#xA;is derived from the 64-bit *unsigned long*, while the ecc_blocks variable&#xA;this value gets assigned to has (always 32-bit) *int* type.  Even if that&#xA;value fits into *int* type, an overflow is still possible when calculating&#xA;the size_t typed ecc_total variable further below since there&#39;s no cast to&#xA;any 64-bit type before multiplication.  Declaring the ecc_blocks variable&#xA;as *size_t* should fix this mess...&#xA;Found by Linux Verification Center (linuxtesting.org) with the SVACE static&#xA;analysis tool.&#xA;CVE-2023-52690:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/powernv: Add a null pointer check to scom_debug_init_one()&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure.&#xA;Add a null pointer check, and release &#39;ent&#39; to avoid memory leaks.&#xA;CVE-2023-52694:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function&#xA;With tpd12s015_remove() marked with __exit this function is discarded&#xA;when the driver is compiled as a built-in. The result is that when the&#xA;driver unbinds there is no cleanup done which results in resource&#xA;leakage or worse.&#xA;CVE-2023-52698:In the Linux kernel, the following vulnerability has been resolved:&#xA;calipso: fix memory leak in netlbl_calipso_add_pass()&#xA;If IPv6 support is disabled at boot (ipv6.disable=1),&#xA;the calipso_init() -&gt; netlbl_calipso_ops_register() function isn&#39;t called,&#xA;and the netlbl_calipso_ops_get() function always returns NULL.&#xA;In this case, the netlbl_calipso_add_pass() function allocates memory&#xA;for the doi_def variable but doesn&#39;t free it with the calipso_doi_free().&#xA;BUG: memory leak&#xA;unreferenced object 0xffff888011d68180 (size 64):&#xA;  comm &#34;syz-executor.1&#34;, pid 10746, jiffies 4295410986 (age 17.928s)&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace:&#xA;    [&lt;...&gt;] kmalloc include/linux/slab.h:552 [inline]&#xA;    [&lt;...&gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]&#xA;    [&lt;...&gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111&#xA;    [&lt;...&gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739&#xA;    [&lt;...&gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]&#xA;    [&lt;...&gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800&#xA;    [&lt;...&gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515&#xA;    [&lt;...&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811&#xA;    [&lt;...&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]&#xA;    [&lt;...&gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339&#xA;    [&lt;...&gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934&#xA;    [&lt;...&gt;] sock_sendmsg_nosec net/socket.c:651 [inline]&#xA;    [&lt;...&gt;] sock_sendmsg+0x157/0x190 net/socket.c:671&#xA;    [&lt;...&gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342&#xA;    [&lt;...&gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396&#xA;    [&lt;...&gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429&#xA;    [&lt;...&gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46&#xA;    [&lt;...&gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6&#xA;Found by InfoTeCS on behalf of Linux Verification Center&#xA;(linuxtesting.org) with Syzkaller&#xA;[PM: merged via the LSM tree at Jakub Kicinski request]&#xA;CVE-2023-52809:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()&#xA;fc_lport_ptp_setup() did not check the return value of fc_rport_create()&#xA;which can return NULL and would cause a NULL pointer dereference. Address&#xA;this issue by checking return value of fc_rport_create() and log error&#xA;message on fc_rport_create() failed.&#xA;CVE-2023-52835:In the Linux kernel, the following vulnerability has been resolved:&#xA;perf/core: Bail out early if the request AUX area is out of bound&#xA;When perf-record with a large AUX area, e.g 4GB, it fails with:&#xA;    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1&#xA;    failed to mmap with 12 (Cannot allocate memory)&#xA;and it reveals a WARNING with __alloc_pages():&#xA;&#x9;------------[ cut here ]------------&#xA;&#x9;WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248&#xA;&#x9;Call trace:&#xA;&#x9; __alloc_pages+0x1ec/0x248&#xA;&#x9; __kmalloc_large_node+0xc0/0x1f8&#xA;&#x9; __kmalloc_node+0x134/0x1e8&#xA;&#x9; rb_alloc_aux+0xe0/0x298&#xA;&#x9; perf_mmap+0x440/0x660&#xA;&#x9; mmap_region+0x308/0x8a8&#xA;&#x9; do_mmap+0x3c0/0x528&#xA;&#x9; vm_mmap_pgoff+0xf4/0x1b8&#xA;&#x9; ksys_mmap_pgoff+0x18c/0x218&#xA;&#x9; __arm64_sys_mmap+0x38/0x58&#xA;&#x9; invoke_syscall+0x50/0x128&#xA;&#x9; el0_svc_common.constprop.0+0x58/0x188&#xA;&#x9; do_el0_svc+0x34/0x50&#xA;&#x9; el0_svc+0x34/0x108&#xA;&#x9; el0t_64_sync_handler+0xb8/0xc0&#xA;&#x9; el0t_64_sync+0x1a4/0x1a8&#xA;&#39;rb-&gt;aux_pages&#39; allocated by kcalloc() is a pointer array which is used to&#xA;maintains AUX trace pages. The allocated page for this array is physically&#xA;contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the&#xA;size of pointer array crosses the limitation set by MAX_ORDER, it reveals a&#xA;WARNING.&#xA;So bail out early with -ENOMEM if the request AUX area is out of bound,&#xA;e.g.:&#xA;    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1&#xA;    failed to mmap with 12 (Cannot allocate memory)&#xA;CVE-2023-52840:In the Linux kernel, the following vulnerability has been resolved:&#xA;Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()&#xA;The put_device() calls rmi_release_function() which frees &#34;fn&#34; so the&#xA;dereference on the next line &#34;fn-&gt;num_of_irqs&#34; is a use after free.&#xA;Move the put_device() to the end to fix this.&#xA;CVE-2023-52841:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: vidtv: mux: Add check and kfree for kstrdup&#xA;Add check for the return value of kstrdup() and return the error&#xA;if it fails in order to avoid NULL pointer dereference.&#xA;Moreover, use kfree() in the later error handling in order to avoid&#xA;memory leak.&#xA;CVE-2023-52844:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: vidtv: psi: Add check for kstrdup&#xA;Add check for the return value of kstrdup() and return the error&#xA;if it fails in order to avoid NULL pointer dereference.&#xA;CVE-2023-52847:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: bttv: fix use after free error due to btv-&gt;timeout timer&#xA;There may be some a race condition between timer function&#xA;bttv_irq_timeout and bttv_remove. The timer is setup in&#xA;probe and there is no timer_delete operation in remove&#xA;function. When it hit kfree btv, the function might still be&#xA;invoked, which will cause use after free bug.&#xA;This bug is found by static analysis, it may be false positive.&#xA;Fix it by adding del_timer_sync invoking to the remove function.&#xA;cpu0                cpu1&#xA;                  bttv_probe&#xA;                    -&gt;timer_setup&#xA;                      -&gt;bttv_set_dma&#xA;                        -&gt;mod_timer;&#xA;bttv_remove&#xA;  -&gt;kfree(btv);&#xA;                  -&gt;bttv_irq_timeout&#xA;                    -&gt;USE btv&#xA;CVE-2023-52854:In the Linux kernel, the following vulnerability has been resolved:&#xA;padata: Fix refcnt handling in padata_free_shell()&#xA;In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead&#xA;to system UAF (Use-After-Free) issues. Due to the lengthy analysis of&#xA;the pcrypt_aead01 function call, I&#39;ll describe the problem scenario&#xA;using a simplified model:&#xA;Suppose there&#39;s a user of padata named `user_function` that adheres to&#xA;the padata requirement of calling `padata_free_shell` after `serial()`&#xA;has been invoked, as demonstrated in the following code:&#xA;```c&#xA;struct request {&#xA;    struct padata_priv padata;&#xA;    struct completion *done;&#xA;};&#xA;void parallel(struct padata_priv *padata) {&#xA;    do_something();&#xA;}&#xA;void serial(struct padata_priv *padata) {&#xA;    struct request *request = container_of(padata,&#xA;    &#x9;&#x9;&#x9;&#x9;struct request,&#xA;&#x9;&#x9;&#x9;&#x9;padata);&#xA;    complete(request-&gt;done);&#xA;}&#xA;void user_function() {&#xA;    DECLARE_COMPLETION(done)&#xA;    padata-&gt;parallel = parallel;&#xA;    padata-&gt;serial = serial;&#xA;    padata_do_parallel();&#xA;    wait_for_completion(&amp;done);&#xA;    padata_free_shell();&#xA;}&#xA;```&#xA;In the corresponding padata.c file, there&#39;s the following code:&#xA;```c&#xA;static void padata_serial_worker(struct work_struct *serial_work) {&#xA;    ...&#xA;    cnt = 0;&#xA;    while (!list_empty(&amp;local_list)) {&#xA;        ...&#xA;        padata-&gt;serial(padata);&#xA;        cnt++;&#xA;    }&#xA;    local_bh_enable();&#xA;    if (refcount_sub_and_test(cnt, &amp;pd-&gt;refcnt))&#xA;        padata_free_pd(pd);&#xA;}&#xA;```&#xA;Because of the high system load and the accumulation of unexecuted&#xA;softirq at this moment, `local_bh_enable()` in padata takes longer&#xA;to execute than usual. Subsequently, when accessing `pd-&gt;refcnt`,&#xA;`pd` has already been released by `padata_free_shell()`, resulting&#xA;in a UAF issue with `pd-&gt;refcnt`.&#xA;The fix is straightforward: add `refcount_dec_and_test` before calling&#xA;`padata_free_pd` in `padata_free_shell`.&#xA;CVE-2023-52860:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process&#xA;When tearing down a &#39;hisi_hns3&#39; PMU, we mistakenly run the CPU hotplug&#xA;callbacks after the device has been unregistered, leading to fireworks&#xA;when we try to execute empty function callbacks within the driver:&#xA;  | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000&#xA;  | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G        W  O      5.12.0-rc4+ #1&#xA;  | Hardware name:  , BIOS KpxxxFPGA 1P B600 V143 04/22/2021&#xA;  | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)&#xA;  | pc : perf_pmu_migrate_context+0x98/0x38c&#xA;  | lr : perf_pmu_migrate_context+0x94/0x38c&#xA;  |&#xA;  | Call trace:&#xA;  |  perf_pmu_migrate_context+0x98/0x38c&#xA;  |  hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]&#xA;Use cpuhp_state_remove_instance_nocalls() instead of&#xA;cpuhp_state_remove_instance() so that the notifiers don&#39;t execute after&#xA;the PMU device has been unregistered.&#xA;[will: Rewrote commit message]&#xA;CVE-2023-52863:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (axi-fan-control) Fix possible NULL pointer dereference&#xA;axi_fan_control_irq_handler(), dependent on the private&#xA;axi_fan_control_data structure, might be called before the hwmon&#xA;device is registered. That will cause an &#34;Unable to handle kernel&#xA;NULL pointer dereference&#34; error.&#xA;CVE-2023-52869:In the Linux kernel, the following vulnerability has been resolved:&#xA;pstore/platform: Add check for kstrdup&#xA;Add check for the return value of kstrdup() and return the error&#xA;if it fails in order to avoid NULL pointer dereference.&#xA;CVE-2023-52870:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data&#xA;Add the check for the return value of mtk_alloc_clk_data() in order to&#xA;avoid NULL pointer dereference.&#xA;CVE-2024-24860:A race condition was found in the Linux kernel&#39;s bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.&#xA;CVE-2024-26610:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: fix a memory corruption&#xA;iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that&#xA;if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in&#xA;bytes, we&#39;ll write past the buffer.&#xA;CVE-2024-26633:In the Linux kernel, the following vulnerability has been resolved:&#xA;ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()&#xA;syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.&#xA;Reading frag_off can only be done if we pulled enough bytes&#xA;to skb-&gt;head. Currently we might access garbage.&#xA;[1]&#xA;BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0&#xA;ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0&#xA;ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]&#xA;ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432&#xA;__netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA;netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA;xmit_one net/core/dev.c:3548 [inline]&#xA;dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564&#xA;__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349&#xA;dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA;neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592&#xA;neigh_output include/net/neighbour.h:542 [inline]&#xA;ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137&#xA;ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222&#xA;NF_HOOK_COND include/linux/netfilter.h:303 [inline]&#xA;ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243&#xA;dst_output include/net/dst.h:451 [inline]&#xA;ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155&#xA;ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]&#xA;ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972&#xA;rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582&#xA;rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920&#xA;inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847&#xA;sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;__sock_sendmsg net/socket.c:745 [inline]&#xA;____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584&#xA;___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA;__sys_sendmsg net/socket.c:2667 [inline]&#xA;__do_sys_sendmsg net/socket.c:2676 [inline]&#xA;__se_sys_sendmsg net/socket.c:2674 [inline]&#xA;__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674&#xA;do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83&#xA;entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA;slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768&#xA;slab_alloc_node mm/slub.c:3478 [inline]&#xA;__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517&#xA;__do_kmalloc_node mm/slab_common.c:1006 [inline]&#xA;__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027&#xA;kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582&#xA;pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098&#xA;__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655&#xA;pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]&#xA;pskb_may_pull include/linux/skbuff.h:2681 [inline]&#xA;ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408&#xA;ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]&#xA;ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432&#xA;__netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA;netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA;xmit_one net/core/dev.c:3548 [inline]&#xA;dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564&#xA;__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349&#xA;dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA;neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592&#xA;neigh_output include/net/neighbour.h:542 [inline]&#xA;ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137&#xA;ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222&#xA;NF_HOOK_COND include/linux/netfilter.h:303 [inline]&#xA;ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243&#xA;dst_output include/net/dst.h:451 [inline]&#xA;ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155&#xA;ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]&#xA;ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972&#xA;rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582&#xA;rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920&#xA;inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847&#xA;sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;__sock_sendmsg net/socket.c:745 [inline]&#xA;____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584&#xA;___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA;__sys_sendmsg net/socket.c:2667 [inline]&#xA;__do_sys_sendms&#xA;---truncated---&#xA;CVE-2024-26635:In the Linux kernel, the following vulnerability has been resolved:&#xA;llc: Drop support for ETH_P_TR_802_2.&#xA;syzbot reported an uninit-value bug below. [0]&#xA;llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2&#xA;(0x0011), and syzbot abused the latter to trigger the bug.&#xA;  write$tun(r0, &amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &#39;)&#39;, &#34;90e5dd&#34;}}}}, 0x16)&#xA;llc_conn_handler() initialises local variables {saddr,daddr}.mac&#xA;based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes&#xA;them to __llc_lookup().&#xA;However, the initialisation is done only when skb-&gt;protocol is&#xA;htons(ETH_P_802_2), otherwise, __llc_lookup_established() and&#xA;__llc_lookup_listener() will read garbage.&#xA;The missing initialisation existed prior to commit 211ed865108e&#xA;(&#34;net: delete all instances of special processing for token ring&#34;).&#xA;It removed the part to kick out the token ring stuff but forgot to&#xA;close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().&#xA;Let&#39;s remove llc_tr_packet_type and complete the deprecation.&#xA;[0]:&#xA;BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90&#xA; __llc_lookup_established+0xe9d/0xf90&#xA; __llc_lookup net/llc/llc_conn.c:611 [inline]&#xA; llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791&#xA; llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206&#xA; __netif_receive_skb_one_core net/core/dev.c:5527 [inline]&#xA; __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641&#xA; netif_receive_skb_internal net/core/dev.c:5727 [inline]&#xA; netif_receive_skb+0x58/0x660 net/core/dev.c:5786&#xA; tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555&#xA; tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002&#xA; tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA; call_write_iter include/linux/fs.h:2020 [inline]&#xA; new_sync_write fs/read_write.c:491 [inline]&#xA; vfs_write+0x8ef/0x1490 fs/read_write.c:584&#xA; ksys_write+0x20f/0x4c0 fs/read_write.c:637&#xA; __do_sys_write fs/read_write.c:649 [inline]&#xA; __se_sys_write fs/read_write.c:646 [inline]&#xA; __x64_sys_write+0x93/0xd0 fs/read_write.c:646&#xA; do_syscall_x64 arch/x86/entry/common.c:51 [inline]&#xA; do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Local variable daddr created at:&#xA; llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783&#xA; llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206&#xA;CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023&#xA;CVE-2024-26636:In the Linux kernel, the following vulnerability has been resolved:&#xA;llc: make llc_ui_sendmsg() more robust against bonding changes&#xA;syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no&#xA;headroom, but subsequently trying to push 14 bytes of Ethernet header [1]&#xA;Like some others, llc_ui_sendmsg() releases the socket lock before&#xA;calling sock_alloc_send_skb().&#xA;Then it acquires it again, but does not redo all the sanity checks&#xA;that were performed.&#xA;This fix:&#xA;- Uses LL_RESERVED_SPACE() to reserve space.&#xA;- Check all conditions again after socket lock is held again.&#xA;- Do not account Ethernet header for mtu limitation.&#xA;[1]&#xA;skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0&#xA; kernel BUG at net/core/skbuff.c:193 !&#xA;Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP&#xA;Modules linked in:&#xA;CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023&#xA;pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : skb_panic net/core/skbuff.c:189 [inline]&#xA; pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203&#xA; lr : skb_panic net/core/skbuff.c:189 [inline]&#xA; lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203&#xA;sp : ffff800096f97000&#xA;x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000&#xA;x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2&#xA;x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0&#xA;x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce&#xA;x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001&#xA;x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000&#xA;x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400&#xA;x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000&#xA;x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714&#xA;x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089&#xA;Call trace:&#xA;  skb_panic net/core/skbuff.c:189 [inline]&#xA;  skb_under_panic+0x13c/0x140 net/core/skbuff.c:203&#xA;  skb_push+0xf0/0x108 net/core/skbuff.c:2451&#xA;  eth_header+0x44/0x1f8 net/ethernet/eth.c:83&#xA;  dev_hard_header include/linux/netdevice.h:3188 [inline]&#xA;  llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33&#xA;  llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85&#xA;  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]&#xA;  llc_sap_next_state net/llc/llc_sap.c:182 [inline]&#xA;  llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209&#xA;  llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270&#xA;  llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg net/socket.c:745 [inline]&#xA;  sock_sendmsg+0x194/0x274 net/socket.c:767&#xA;  splice_to_socket+0x7cc/0xd58 fs/splice.c:881&#xA;  do_splice_from fs/splice.c:933 [inline]&#xA;  direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142&#xA;  splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088&#xA;  do_splice_direct+0x20c/0x348 fs/splice.c:1194&#xA;  do_sendfile+0x4bc/0xc70 fs/read_write.c:1254&#xA;  __do_sys_sendfile64 fs/read_write.c:1322 [inline]&#xA;  __se_sys_sendfile64 fs/read_write.c:1308 [inline]&#xA;  __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308&#xA;  __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]&#xA;  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51&#xA;  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136&#xA;  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155&#xA;  el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678&#xA;  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696&#xA;  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595&#xA;Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)&#xA;CVE-2024-26640:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: add sanity checks to rx zerocopy&#xA;TCP rx zerocopy intent is to map pages initially allocated&#xA;from NIC drivers, not pages owned by a fs.&#xA;This patch adds to can_map_frag() these additional checks:&#xA;- Page must not be a compound one.&#xA;- page-&gt;mapping must be NULL.&#xA;This fixes the panic reported by ZhangPeng.&#xA;syzbot was able to loopback packets built with sendfile(),&#xA;mapping pages owned by an ext4 file to TCP rx zerocopy.&#xA;r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)&#xA;r4 = socket$inet_tcp(0x2, 0x1, 0x0)&#xA;bind$inet(r4, &amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)&#xA;connect$inet(r4, &amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)&#xA;r5 = openat$dir(0xffffffffffffff9c, &amp;(0x7f00000000c0)=&#39;./file0\x00&#39;,&#xA;    0x181e42, 0x0)&#xA;fallocate(r5, 0x0, 0x0, 0x85b8)&#xA;sendfile(r4, r5, 0x0, 0x8ba0)&#xA;getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &amp;(0x7f00000001c0)={&amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,&#xA;    0x0, 0x0, 0x0, 0x0}, &amp;(0x7f0000000440)=0x40)&#xA;r6 = openat$dir(0xffffffffffffff9c, &amp;(0x7f00000000c0)=&#39;./file0\x00&#39;,&#xA;    0x181e42, 0x0)&#xA;CVE-2024-26641:In the Linux kernel, the following vulnerability has been resolved:&#xA;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()&#xA;syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].&#xA;Call pskb_inet_may_pull() to fix this, and initialize ipv6h&#xA;variable after this call as it can change skb-&gt;head.&#xA;[1]&#xA; BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]&#xA; BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]&#xA; BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321&#xA;  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]&#xA;  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]&#xA;  IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321&#xA;  ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727&#xA;  __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845&#xA;  ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888&#xA; gre_rcv+0x143f/0x1870&#xA;  ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438&#xA;  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492&#xA;  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586&#xA;  dst_input include/net/dst.h:461 [inline]&#xA;  ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310&#xA;  __netif_receive_skb_one_core net/core/dev.c:5532 [inline]&#xA;  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646&#xA;  netif_receive_skb_internal net/core/dev.c:5732 [inline]&#xA;  netif_receive_skb+0x58/0x660 net/core/dev.c:5791&#xA;  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555&#xA;  tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002&#xA;  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA;  call_write_iter include/linux/fs.h:2084 [inline]&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0x786/0x1200 fs/read_write.c:590&#xA;  ksys_write+0x20f/0x4c0 fs/read_write.c:643&#xA;  __do_sys_write fs/read_write.c:655 [inline]&#xA;  __se_sys_write fs/read_write.c:652 [inline]&#xA;  __x64_sys_write+0x93/0xd0 fs/read_write.c:652&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768&#xA;  slab_alloc_node mm/slub.c:3478 [inline]&#xA;  kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560&#xA;  __alloc_skb+0x318/0x740 net/core/skbuff.c:651&#xA;  alloc_skb include/linux/skbuff.h:1286 [inline]&#xA;  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334&#xA;  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787&#xA;  tun_alloc_skb drivers/net/tun.c:1531 [inline]&#xA;  tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846&#xA;  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA;  call_write_iter include/linux/fs.h:2084 [inline]&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0x786/0x1200 fs/read_write.c:590&#xA;  ksys_write+0x20f/0x4c0 fs/read_write.c:643&#xA;  __do_sys_write fs/read_write.c:655 [inline]&#xA;  __se_sys_write fs/read_write.c:652 [inline]&#xA;  __x64_sys_write+0x93/0xd0 fs/read_write.c:652&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023&#xA;CVE-2024-26642:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: disallow anonymous set with timeout flag&#xA;Anonymous sets are never used with timeout from userspace, reject this.&#xA;Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.&#xA;CVE-2024-26645:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing: Ensure visibility when inserting an element into tracing_map&#xA;Running the following two commands in parallel on a multi-processor&#xA;AArch64 machine can sporadically produce an unexpected warning about&#xA;duplicate histogram entries:&#xA; $ while true; do&#xA;     echo hist:key=id.syscall:val=hitcount &gt; \&#xA;       /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger&#xA;     cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist&#xA;     sleep 0.001&#xA;   done&#xA; $ stress-ng --sysbadaddr $(nproc)&#xA;The warning looks as follows:&#xA;[ 2911.172474] ------------[ cut here ]------------&#xA;[ 2911.173111] Duplicates detected: 1&#xA;[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408&#xA;[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)&#xA;[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1&#xA;[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G            E      6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01&#xA;[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018&#xA;[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)&#xA;[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408&#xA;[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408&#xA;[ 2911.185310] sp : ffff8000a1513900&#xA;[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001&#xA;[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008&#xA;[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180&#xA;[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff&#xA;[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8&#xA;[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731&#xA;[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c&#xA;[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8&#xA;[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000&#xA;[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480&#xA;[ 2911.194259] Call trace:&#xA;[ 2911.194626]  tracing_map_sort_entries+0x3e0/0x408&#xA;[ 2911.195220]  hist_show+0x124/0x800&#xA;[ 2911.195692]  seq_read_iter+0x1d4/0x4e8&#xA;[ 2911.196193]  seq_read+0xe8/0x138&#xA;[ 2911.196638]  vfs_read+0xc8/0x300&#xA;[ 2911.197078]  ksys_read+0x70/0x108&#xA;[ 2911.197534]  __arm64_sys_read+0x24/0x38&#xA;[ 2911.198046]  invoke_syscall+0x78/0x108&#xA;[ 2911.198553]  el0_svc_common.constprop.0+0xd0/0xf8&#xA;[ 2911.199157]  do_el0_svc+0x28/0x40&#xA;[ 2911.199613]  el0_svc+0x40/0x178&#xA;[ 2911.200048]  el0t_64_sync_handler+0x13c/0x158&#xA;[ 2911.200621]  el0t_64_sync+0x1a8/0x1b0&#xA;[ 2911.201115] ---[ end trace 0000000000000000 ]---&#xA;The problem appears to be caused by CPU reordering of writes issued from&#xA;__tracing_map_insert().&#xA;The check for the presence of an element with a given key in this&#xA;function is:&#xA; val = READ_ONCE(entry-&gt;val);&#xA; if (val &amp;&amp; keys_match(key, val-&gt;key, map-&gt;key_size)) ...&#xA;The write of a new entry is:&#xA; elt = get_free_elt(map);&#xA; memcpy(elt-&gt;key, key, map-&gt;key_size);&#xA; entry-&gt;val = elt;&#xA;The &#34;memcpy(elt-&gt;key, key, map-&gt;key_size);&#34; and &#34;entry-&gt;val = elt;&#34;&#xA;stores may become visible in the reversed order on another CPU. This&#xA;second CPU might then incorrectly determine that a new key doesn&#39;t match&#xA;an already present val-&gt;key and subse&#xA;---truncated---&#xA;CVE-2024-26661:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add NULL test for &#39;timing generator&#39; in &#39;dcn21_set_pipe()&#39;&#xA;In &#34;u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;&#34;&#xA;pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller to&#xA;ensure the tg is not NULL.&#xA;CVE-2024-26665:In the Linux kernel, the following vulnerability has been resolved:&#xA;tunnels: fix out of bounds access when building IPv6 PMTU error&#xA;If the ICMPv6 error is built from a non-linear skb we get the following&#xA;splat,&#xA;  BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240&#xA;  Read of size 4 at addr ffff88811d402c80 by task netperf/820&#xA;  CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543&#xA;  ...&#xA;   kasan_report+0xd8/0x110&#xA;   do_csum+0x220/0x240&#xA;   csum_partial+0xc/0x20&#xA;   skb_tunnel_check_pmtu+0xeb9/0x3280&#xA;   vxlan_xmit_one+0x14c2/0x4080&#xA;   vxlan_xmit+0xf61/0x5c00&#xA;   dev_hard_start_xmit+0xfb/0x510&#xA;   __dev_queue_xmit+0x7cd/0x32a0&#xA;   br_dev_queue_push_xmit+0x39d/0x6a0&#xA;Use skb_checksum instead of csum_partial who cannot deal with non-linear&#xA;SKBs.&#xA;CVE-2024-26675:In the Linux kernel, the following vulnerability has been resolved:&#xA;ppp_async: limit MRU to 64K&#xA;syzbot triggered a warning [1] in __alloc_pages():&#xA;WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp)&#xA;Willem fixed a similar issue in commit c0a2a1b0d631 (&#34;ppp: limit MRU to 64K&#34;)&#xA;Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)&#xA;[1]:&#xA; WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543&#xA;Modules linked in:&#xA;CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023&#xA;Workqueue: events_unbound flush_to_ldisc&#xA;pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543&#xA; lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537&#xA;sp : ffff800093967580&#xA;x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000&#xA;x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0&#xA;x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8&#xA;x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120&#xA;x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005&#xA;x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000&#xA;x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001&#xA;x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f&#xA;x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020&#xA;x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0&#xA;Call trace:&#xA;  __alloc_pages+0x308/0x698 mm/page_alloc.c:4543&#xA;  __alloc_pages_node include/linux/gfp.h:238 [inline]&#xA;  alloc_pages_node include/linux/gfp.h:261 [inline]&#xA;  __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926&#xA;  __do_kmalloc_node mm/slub.c:3969 [inline]&#xA;  __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001&#xA;  kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590&#xA;  __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651&#xA;  __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715&#xA;  netdev_alloc_skb include/linux/skbuff.h:3235 [inline]&#xA;  dev_alloc_skb include/linux/skbuff.h:3248 [inline]&#xA;  ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]&#xA;  ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341&#xA;  tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390&#xA;  tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37&#xA;  receive_buf drivers/tty/tty_buffer.c:444 [inline]&#xA;  flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494&#xA;  process_one_work+0x694/0x1204 kernel/workqueue.c:2633&#xA;  process_scheduled_works kernel/workqueue.c:2706 [inline]&#xA;  worker_thread+0x938/0xef4 kernel/workqueue.c:2787&#xA;  kthread+0x288/0x310 kernel/kthread.c:388&#xA;  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860&#xA;CVE-2024-26679:In the Linux kernel, the following vulnerability has been resolved:&#xA;inet: read sk-&gt;sk_family once in inet_recv_error()&#xA;inet_recv_error() is called without holding the socket lock.&#xA;IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM&#xA;socket option and trigger a KCSAN warning.&#xA;CVE-2024-26684:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: stmmac: xgmac: fix handling of DPP safety error for DMA channels&#xA;Commit 56e58d6c8a56 (&#34;net: stmmac: Implement Safety Features in&#xA;XGMAC core&#34;) checks and reports safety errors, but leaves the&#xA;Data Path Parity Errors for each channel in DMA unhandled at all, lead to&#xA;a storm of interrupt.&#xA;Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.&#xA;CVE-2024-26685:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential bug in end_buffer_async_write&#xA;According to a syzbot report, end_buffer_async_write(), which handles the&#xA;completion of block device writes, may detect abnormal condition of the&#xA;buffer async_write flag and cause a BUG_ON failure when using nilfs2.&#xA;Nilfs2 itself does not use end_buffer_async_write().  But, the async_write&#xA;flag is now used as a marker by commit 7f42ec394156 (&#34;nilfs2: fix issue&#xA;with race condition of competition between segments for dirty blocks&#34;) as&#xA;a means of resolving double list insertion of dirty blocks in&#xA;nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the&#xA;resulting crash.&#xA;This modification is safe as long as it is used for file data and b-tree&#xA;node blocks where the page caches are independent.  However, it was&#xA;irrelevant and redundant to also introduce async_write for segment summary&#xA;and super root blocks that share buffers with the backing device.  This&#xA;led to the possibility that the BUG_ON check in end_buffer_async_write&#xA;would fail as described above, if independent writebacks of the backing&#xA;device occurred in parallel.&#xA;The use of async_write for segment summary buffers has already been&#xA;removed in a previous change.&#xA;Fix this issue by removing the manipulation of the async_write flag for&#xA;the remaining super root block buffer.&#xA;CVE-2024-26686:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/proc: do_task_stat: use sig-&gt;stats_lock to gather the threads/children stats&#xA;lock_task_sighand() can trigger a hard lockup.  If NR_CPUS threads call&#xA;do_task_stat() at the same time and the process has NR_THREADS, it will&#xA;spin with irqs disabled O(NR_CPUS * NR_THREADS) time.&#xA;Change do_task_stat() to use sig-&gt;stats_lock to gather the statistics&#xA;outside of -&gt;siglock protected section, in the likely case this code will&#xA;run lockless.&#xA;CVE-2024-26697:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix data corruption in dsync block recovery for small block sizes&#xA;The helper function nilfs_recovery_copy_block() of&#xA;nilfs_recovery_dsync_blocks(), which recovers data from logs created by&#xA;data sync writes during a mount after an unclean shutdown, incorrectly&#xA;calculates the on-page offset when copying repair data to the file&#39;s page&#xA;cache.  In environments where the block size is smaller than the page&#xA;size, this flaw can cause data corruption and leak uninitialized memory&#xA;bytes during the recovery process.&#xA;Fix these issues by correcting this byte offset calculation on the page.&#xA;CVE-2024-26702:In the Linux kernel, the following vulnerability has been resolved:&#xA;iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC&#xA;Recently, we encounter kernel crash in function rm3100_common_probe&#xA;caused by out of bound access of array rm3100_samp_rates (because of&#xA;underlying hardware failures). Add boundary check to prevent out of&#xA;bound access.&#xA;CVE-2024-26706:In the Linux kernel, the following vulnerability has been resolved:&#xA;parisc: Fix random data corruption from exception handler&#xA;The current exception handler implementation, which assists when accessing&#xA;user space memory, may exhibit random data corruption if the compiler decides&#xA;to use a different register than the specified register %r29 (defined in&#xA;ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another&#xA;register, the fault handler will nevertheless store -EFAULT into %r29 and thus&#xA;trash whatever this register is used for.&#xA;Looking at the assembly I found that this happens sometimes in emulate_ldd().&#xA;To solve the issue, the easiest solution would be if it somehow is&#xA;possible to tell the fault handler which register is used to hold the error&#xA;code. Using %0 or %1 in the inline assembly is not posssible as it will show&#xA;up as e.g. %r29 (with the &#34;%r&#34; prefix), which the GNU assembler can not&#xA;convert to an integer.&#xA;This patch takes another, better and more flexible approach:&#xA;We extend the __ex_table (which is out of the execution path) by one 32-word.&#xA;In this word we tell the compiler to insert the assembler instruction&#xA;&#34;or %r0,%r0,%reg&#34;, where %reg references the register which the compiler&#xA;choosed for the error return code.&#xA;In case of an access failure, the fault handler finds the __ex_table entry and&#xA;can examine the opcode. The used register is encoded in the lowest 5 bits, and&#xA;the fault handler can then store -EFAULT into this register.&#xA;Since we extend the __ex_table to 3 words we can&#39;t use the BUILDTIME_TABLE_SORT&#xA;config option any longer.&#xA;CVE-2024-26707:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()&#xA;Syzkaller reported [1] hitting a warning after failing to allocate&#xA;resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will&#xA;not help much in this case, it might be prudent to switch to&#xA;netdev_warn_once(). At the very least it will suppress syzkaller&#xA;reports such as [1].&#xA;Just in case, use netdev_warn_once() in send_prp_supervision_frame()&#xA;for similar reasons.&#xA;[1]&#xA;HSR: Could not send supervision frame&#xA;WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294&#xA;RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294&#xA;...&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382&#xA; call_timer_fn+0x193/0x590 kernel/time/timer.c:1700&#xA; expire_timers kernel/time/timer.c:1751 [inline]&#xA; __run_timers+0x764/0xb20 kernel/time/timer.c:2022&#xA; run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035&#xA; __do_softirq+0x21a/0x8de kernel/softirq.c:553&#xA; invoke_softirq kernel/softirq.c:427 [inline]&#xA; __irq_exit_rcu kernel/softirq.c:632 [inline]&#xA; irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644&#xA; sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649&#xA;...&#xA;This issue is also found in older kernels (at least up to 5.10).&#xA;CVE-2024-26712:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/kasan: Fix addr error caused by page alignment&#xA;In kasan_init_region, when k_start is not page aligned, at the begin of&#xA;for loop, k_cur = k_start &amp; PAGE_MASK is less than k_start, and then&#xA;`va = block + k_cur - k_start` is less than block, the addr va is invalid,&#xA;because the memory address space from va to block is not alloced by&#xA;memblock_alloc, which will not be reserved by memblock_reserve later, it&#xA;will be used by other places.&#xA;As a result, memory overwriting occurs.&#xA;for example:&#xA;int __init __weak kasan_init_region(void *start, size_t size)&#xA;{&#xA;[...]&#xA;&#x9;/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */&#xA;&#x9;block = memblock_alloc(k_end - k_start, PAGE_SIZE);&#xA;&#x9;[...]&#xA;&#x9;for (k_cur = k_start &amp; PAGE_MASK; k_cur &lt; k_end; k_cur += PAGE_SIZE) {&#xA;&#x9;&#x9;/* at the begin of for loop&#xA;&#x9;&#x9; * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)&#xA;&#x9;&#x9; * va(dcd96c00) is less than block(dcd97000), va is invalid&#xA;&#x9;&#x9; */&#xA;&#x9;&#x9;void *va = block + k_cur - k_start;&#xA;&#x9;&#x9;[...]&#xA;&#x9;}&#xA;[...]&#xA;}&#xA;Therefore, page alignment is performed on k_start before&#xA;memblock_alloc() to ensure the validity of the VA address.&#xA;CVE-2024-26720:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&#xA;(struct dirty_throttle_control *)-&gt;thresh is an unsigned long, but is&#xA;passed as the u32 divisor argument to div_u64().  On architectures where&#xA;unsigned long is 64 bytes, the argument will be implicitly truncated.&#xA;Use div64_u64() instead of div_u64() so that the value used in the &#34;is&#xA;this a safe division&#34; check is the same as the divisor.&#xA;Also, remove redundant cast of the numerator to u64, as that should happen&#xA;implicitly.&#xA;This would be difficult to exploit in memcg domain, given the ratio-based&#xA;arithmetic domain_drity_limits() uses, but is much easier in global&#xA;writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1&lt;&lt;32)*PAGE_SIZE so that dtc-&gt;thresh == (1&lt;&lt;32)&#xA;CVE-2024-26726:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: don&#39;t drop extent_map for free space inode on write error&#xA;While running the CI for an unrelated change I hit the following panic&#xA;with generic/648 on btrfs_holes_spacecache.&#xA;assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385&#xA;------------[ cut here ]------------&#xA;kernel BUG at fs/btrfs/extent_io.c:1385!&#xA;invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1&#xA;RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; extent_write_cache_pages+0x2ac/0x8f0&#xA; extent_writepages+0x87/0x110&#xA; do_writepages+0xd5/0x1f0&#xA; filemap_fdatawrite_wbc+0x63/0x90&#xA; __filemap_fdatawrite_range+0x5c/0x80&#xA; btrfs_fdatawrite_range+0x1f/0x50&#xA; btrfs_write_out_cache+0x507/0x560&#xA; btrfs_write_dirty_block_groups+0x32a/0x420&#xA; commit_cowonly_roots+0x21b/0x290&#xA; btrfs_commit_transaction+0x813/0x1360&#xA; btrfs_sync_file+0x51a/0x640&#xA; __x64_sys_fdatasync+0x52/0x90&#xA; do_syscall_64+0x9c/0x190&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;This happens because we fail to write out the free space cache in one&#xA;instance, come back around and attempt to write it again.  However on&#xA;the second pass through we go to call btrfs_get_extent() on the inode to&#xA;get the extent mapping.  Because this is a new block group, and with the&#xA;free space inode we always search the commit root to avoid deadlocking&#xA;with the tree, we find nothing and return a EXTENT_MAP_HOLE for the&#xA;requested range.&#xA;This happens because the first time we try to write the space cache out&#xA;we hit an error, and on an error we drop the extent mapping.  This is&#xA;normal for normal files, but the free space cache inode is special.  We&#xA;always expect the extent map to be correct.  Thus the second time&#xA;through we end up with a bogus extent map.&#xA;Since we&#39;re deprecating this feature, the most straightforward way to&#xA;fix this is to simply skip dropping the extent map range for this failed&#xA;range.&#xA;I shortened the test by using error injection to stress the area to make&#xA;it easier to reproduce.  With this patch in place we no longer panic&#xA;with my error injection test.&#xA;CVE-2024-26733:In the Linux kernel, the following vulnerability has been resolved:&#xA;arp: Prevent overflow in arp_req_get().&#xA;syzkaller reported an overflown write in arp_req_get(). [0]&#xA;When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour&#xA;entry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.&#xA;The arp_ha here is struct sockaddr, not struct sockaddr_storage, so&#xA;the sa_data buffer is just 14 bytes.&#xA;In the splat below, 2 bytes are overflown to the next int field,&#xA;arp_flags.  We initialise the field just after the memcpy(), so it&#39;s&#xA;not a problem.&#xA;However, when dev-&gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),&#xA;arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)&#xA;in arp_ioctl() before calling arp_req_get().&#xA;To avoid the overflow, let&#39;s limit the max length of memcpy().&#xA;Note that commit b5f0de6df6dc (&#34;net: dev: Convert sa_data to flexible&#xA;array in struct sockaddr&#34;) just silenced syzkaller.&#xA;[0]:&#xA;memcpy: detected field-spanning write (size 16) of single field &#34;r-&gt;arp_ha.sa_data&#34; at net/ipv4/arp.c:1128 (size 14)&#xA;WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128&#xA;Modules linked in:&#xA;CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014&#xA;RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128&#xA;Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb &lt;0f&gt; 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6&#xA;RSP: 0018:ffffc900050b7998 EFLAGS: 00010286&#xA;RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001&#xA;RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000&#xA;R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010&#xA;FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261&#xA; inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981&#xA; sock_do_ioctl+0xdf/0x260 net/socket.c:1204&#xA; sock_ioctl+0x3ef/0x650 net/socket.c:1321&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:870 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:856 [inline]&#xA; __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856&#xA; do_syscall_x64 arch/x86/entry/common.c:51 [inline]&#xA; do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81&#xA; entry_SYSCALL_64_after_hwframe+0x64/0xce&#xA;RIP: 0033:0x7f172b262b8d&#xA;Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d&#xA;RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003&#xA;RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000&#xA; &lt;/TASK&gt;&#xA;CVE-2024-26734:In the Linux kernel, the following vulnerability has been resolved:&#xA;devlink: fix possible use-after-free and memory leaks in devlink_init()&#xA;The pernet operations structure for the subsystem must be registered&#xA;before registering the generic netlink family.&#xA;Make an unregister in case of unsuccessful registration.&#xA;CVE-2024-26735:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: sr: fix possible use-after-free and null-ptr-deref&#xA;The pernet operations structure for the subsystem must be registered&#xA;before registering the generic netlink family.&#xA;CVE-2024-26740:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: act_mirred: use the backlog for mirred ingress&#xA;The test Davide added in commit ca22da2fbd69 (&#34;act_mirred: use the backlog&#xA;for nested calls to mirred ingress&#34;) hangs our testing VMs every 10 or so&#xA;runs, with the familiar tcp_v4_rcv -&gt; tcp_v4_rcv deadlock reported by&#xA;lockdep.&#xA;The problem as previously described by Davide (see Link) is that&#xA;if we reverse flow of traffic with the redirect (egress -&gt; ingress)&#xA;we may reach the same socket which generated the packet. And we may&#xA;still be holding its socket lock. The common solution to such deadlocks&#xA;is to put the packet in the Rx backlog, rather than run the Rx path&#xA;inline. Do that for all egress -&gt; ingress reversals, not just once&#xA;we started to nest mirred calls.&#xA;In the past there was a concern that the backlog indirection will&#xA;lead to loss of error reporting / less accurate stats. But the current&#xA;workaround does not seem to address the issue.&#xA;CVE-2024-26743:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/qedr: Fix qedr_create_user_qp error flow&#xA;Avoid the following warning by making sure to free the allocated&#xA;resources in case that qedr_init_user_queue() fail.&#xA;-----------[ cut here ]-----------&#xA;WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]&#xA;Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3&#xA;ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]&#xA;CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1&#xA;Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022&#xA;RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]&#xA;Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 &lt;0f&gt; 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff&#xA;RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286&#xA;RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016&#xA;RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600&#xA;RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80&#xA;R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000&#xA;FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;? show_trace_log_lvl+0x1c4/0x2df&#xA;? show_trace_log_lvl+0x1c4/0x2df&#xA;? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]&#xA;? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]&#xA;? __warn+0x81/0x110&#xA;? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]&#xA;? report_bug+0x10a/0x140&#xA;? handle_bug+0x3c/0x70&#xA;? exc_invalid_op+0x14/0x70&#xA;? asm_exc_invalid_op+0x16/0x20&#xA;? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]&#xA;ib_uverbs_close+0x1f/0xb0 [ib_uverbs]&#xA;__fput+0x94/0x250&#xA;task_work_run+0x5c/0x90&#xA;do_exit+0x270/0x4a0&#xA;do_group_exit+0x2d/0x90&#xA;get_signal+0x87c/0x8c0&#xA;arch_do_signal_or_restart+0x25/0x100&#xA;? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]&#xA;exit_to_user_mode_loop+0x9c/0x130&#xA;exit_to_user_mode_prepare+0xb6/0x100&#xA;syscall_exit_to_user_mode+0x12/0x40&#xA;do_syscall_64+0x69/0x90&#xA;? syscall_exit_work+0x103/0x130&#xA;? syscall_exit_to_user_mode+0x22/0x40&#xA;? do_syscall_64+0x69/0x90&#xA;? syscall_exit_work+0x103/0x130&#xA;? syscall_exit_to_user_mode+0x22/0x40&#xA;? do_syscall_64+0x69/0x90&#xA;? do_syscall_64+0x69/0x90&#xA;? common_interrupt+0x43/0xa0&#xA;entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;RIP: 0033:0x1470abe3ec6b&#xA;Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.&#xA;RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b&#xA;RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004&#xA;RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00&#xA;R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358&#xA;R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470&#xA;&lt;/TASK&gt;&#xA;--[ end trace 888a9b92e04c5c97 ]--&#xA;CVE-2024-26744:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/srpt: Support specifying the srpt_service_guid parameter&#xA;Make loading ib_srpt with this parameter set work. The current behavior is&#xA;that setting that parameter while loading the ib_srpt kernel module&#xA;triggers the following kernel crash:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; parse_one+0x18c/0x1d0&#xA; parse_args+0xe1/0x230&#xA; load_module+0x8de/0xa60&#xA; init_module_from_file+0x8b/0xd0&#xA; idempotent_init_module+0x181/0x240&#xA; __x64_sys_finit_module+0x5a/0xb0&#xA; do_syscall_64+0x5f/0xe0&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;CVE-2024-26754:In the Linux kernel, the following vulnerability has been resolved:&#xA;gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()&#xA;The gtp_net_ops pernet operations structure for the subsystem must be&#xA;registered before registering the generic netlink family.&#xA;Syzkaller hit &#39;general protection fault in gtp_genl_dump_pdp&#39; bug:&#xA;general protection fault, probably for non-canonical address&#xA;0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]&#xA;CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014&#xA;RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]&#xA;Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86&#xA;      df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt;&#xA;      3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74&#xA;RSP: 0018:ffff888014107220 EFLAGS: 00010202&#xA;RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000&#xA;RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000&#xA;R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000&#xA;FS:  00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_regs+0x90/0xa0&#xA; ? die_addr+0x50/0xd0&#xA; ? exc_general_protection+0x148/0x220&#xA; ? asm_exc_general_protection+0x22/0x30&#xA; ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]&#xA; ? __alloc_skb+0x1dd/0x350&#xA; ? __pfx___alloc_skb+0x10/0x10&#xA; genl_dumpit+0x11d/0x230&#xA; netlink_dump+0x5b9/0xce0&#xA; ? lockdep_hardirqs_on_prepare+0x253/0x430&#xA; ? __pfx_netlink_dump+0x10/0x10&#xA; ? kasan_save_track+0x10/0x40&#xA; ? __kasan_kmalloc+0x9b/0xa0&#xA; ? genl_start+0x675/0x970&#xA; __netlink_dump_start+0x6fc/0x9f0&#xA; genl_family_rcv_msg_dumpit+0x1bb/0x2d0&#xA; ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10&#xA; ? genl_op_from_small+0x2a/0x440&#xA; ? cap_capable+0x1d0/0x240&#xA; ? __pfx_genl_start+0x10/0x10&#xA; ? __pfx_genl_dumpit+0x10/0x10&#xA; ? __pfx_genl_done+0x10/0x10&#xA; ? security_capable+0x9d/0xe0&#xA;CVE-2024-26763:In the Linux kernel, the following vulnerability has been resolved:&#xA;dm-crypt: don&#39;t modify the data when using authenticated encryption&#xA;It was said that authenticated encryption could produce invalid tag when&#xA;the data that is being encrypted is modified [1]. So, fix this problem by&#xA;copying the data into the clone bio first and then encrypt them inside the&#xA;clone bio.&#xA;This may reduce performance, but it is needed to prevent the user from&#xA;corrupting the device by writing data with O_DIRECT and modifying them at&#xA;the same time.&#xA;[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/&#xA;CVE-2024-26776:In the Linux kernel, the following vulnerability has been resolved:&#xA;spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected&#xA;Return IRQ_NONE from the interrupt handler when no interrupt was&#xA;detected. Because an empty interrupt will cause a null pointer error:&#xA;    Unable to handle kernel NULL pointer dereference at virtual&#xA;  address 0000000000000008&#xA;    Call trace:&#xA;        complete+0x54/0x100&#xA;        hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]&#xA;        __handle_irq_event_percpu+0x64/0x1e0&#xA;        handle_irq_event+0x7c/0x1cc&#xA;CVE-2024-26782:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: fix double-free on socket dismantle&#xA;when MPTCP server accepts an incoming connection, it clones its listener&#xA;socket. However, the pointer to &#39;inet_opt&#39; for the new socket has the same&#xA;value as the original one: as a consequence, on program exit it&#39;s possible&#xA;to observe the following splat:&#xA;  BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0&#xA;  Free of addr ffff888485950880 by task swapper/25/0&#xA;  CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609&#xA;  Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0  07/26/2013&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   dump_stack_lvl+0x32/0x50&#xA;   print_report+0xca/0x620&#xA;   kasan_report_invalid_free+0x64/0x90&#xA;   __kasan_slab_free+0x1aa/0x1f0&#xA;   kfree+0xed/0x2e0&#xA;   inet_sock_destruct+0x54f/0x8b0&#xA;   __sk_destruct+0x48/0x5b0&#xA;   rcu_do_batch+0x34e/0xd90&#xA;   rcu_core+0x559/0xac0&#xA;   __do_softirq+0x183/0x5a4&#xA;   irq_exit_rcu+0x12d/0x170&#xA;   sysvec_apic_timer_interrupt+0x6b/0x80&#xA;   &lt;/IRQ&gt;&#xA;   &lt;TASK&gt;&#xA;   asm_sysvec_apic_timer_interrupt+0x16/0x20&#xA;  RIP: 0010:cpuidle_enter_state+0x175/0x300&#xA;  Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed &lt;0f&gt; 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b&#xA;  RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202&#xA;  RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000&#xA;  RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588&#xA;  RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080&#xA;  R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0&#xA;  R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80&#xA;   cpuidle_enter+0x4a/0xa0&#xA;   do_idle+0x310/0x410&#xA;   cpu_startup_entry+0x51/0x60&#xA;   start_secondary+0x211/0x270&#xA;   secondary_startup_64_no_verify+0x184/0x18b&#xA;   &lt;/TASK&gt;&#xA;  Allocated by task 6853:&#xA;   kasan_save_stack+0x1c/0x40&#xA;   kasan_save_track+0x10/0x30&#xA;   __kasan_kmalloc+0xa6/0xb0&#xA;   __kmalloc+0x1eb/0x450&#xA;   cipso_v4_sock_setattr+0x96/0x360&#xA;   netlbl_sock_setattr+0x132/0x1f0&#xA;   selinux_netlbl_socket_post_create+0x6c/0x110&#xA;   selinux_socket_post_create+0x37b/0x7f0&#xA;   security_socket_post_create+0x63/0xb0&#xA;   __sock_create+0x305/0x450&#xA;   __sys_socket_create.part.23+0xbd/0x130&#xA;   __sys_socket+0x37/0xb0&#xA;   __x64_sys_socket+0x6f/0xb0&#xA;   do_syscall_64+0x83/0x160&#xA;   entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;  Freed by task 6858:&#xA;   kasan_save_stack+0x1c/0x40&#xA;   kasan_save_track+0x10/0x30&#xA;   kasan_save_free_info+0x3b/0x60&#xA;   __kasan_slab_free+0x12c/0x1f0&#xA;   kfree+0xed/0x2e0&#xA;   inet_sock_destruct+0x54f/0x8b0&#xA;   __sk_destruct+0x48/0x5b0&#xA;   subflow_ulp_release+0x1f0/0x250&#xA;   tcp_cleanup_ulp+0x6e/0x110&#xA;   tcp_v4_destroy_sock+0x5a/0x3a0&#xA;   inet_csk_destroy_sock+0x135/0x390&#xA;   tcp_fin+0x416/0x5c0&#xA;   tcp_data_queue+0x1bc8/0x4310&#xA;   tcp_rcv_state_process+0x15a3/0x47b0&#xA;   tcp_v4_do_rcv+0x2c1/0x990&#xA;   tcp_v4_rcv+0x41fb/0x5ed0&#xA;   ip_protocol_deliver_rcu+0x6d/0x9f0&#xA;   ip_local_deliver_finish+0x278/0x360&#xA;   ip_local_deliver+0x182/0x2c0&#xA;   ip_rcv+0xb5/0x1c0&#xA;   __netif_receive_skb_one_core+0x16e/0x1b0&#xA;   process_backlog+0x1e3/0x650&#xA;   __napi_poll+0xa6/0x500&#xA;   net_rx_action+0x740/0xbb0&#xA;   __do_softirq+0x183/0x5a4&#xA;  The buggy address belongs to the object at ffff888485950880&#xA;   which belongs to the cache kmalloc-64 of size 64&#xA;  The buggy address is located 0 bytes inside of&#xA;   64-byte region [ffff888485950880, ffff8884859508c0)&#xA;  The buggy address belongs to the physical page:&#xA;  page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950&#xA;  flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)&#xA;  page_type: 0xffffffff()&#xA;  raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006&#xA;  raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000&#xA;  page dumped because: kasan: bad access detected&#xA;  Memory state around the buggy address:&#xA;   ffff888485950780: fa fb fb&#xA;---truncated---&#xA;CVE-2024-26787:In the Linux kernel, the following vulnerability has been resolved:&#xA;mmc: mmci: stm32: fix DMA API overlapping mappings warning&#xA;Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:&#xA;DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,&#xA;overlapping mappings aren&#39;t supported&#xA;WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568&#xA;add_dma_entry+0x234/0x2f4&#xA;Modules linked in:&#xA;CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1&#xA;Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)&#xA;Workqueue: events_freezable mmc_rescan&#xA;Call trace:&#xA;add_dma_entry+0x234/0x2f4&#xA;debug_dma_map_sg+0x198/0x350&#xA;__dma_map_sg_attrs+0xa0/0x110&#xA;dma_map_sg_attrs+0x10/0x2c&#xA;sdmmc_idma_prep_data+0x80/0xc0&#xA;mmci_prep_data+0x38/0x84&#xA;mmci_start_data+0x108/0x2dc&#xA;mmci_request+0xe4/0x190&#xA;__mmc_start_request+0x68/0x140&#xA;mmc_start_request+0x94/0xc0&#xA;mmc_wait_for_req+0x70/0x100&#xA;mmc_send_tuning+0x108/0x1ac&#xA;sdmmc_execute_tuning+0x14c/0x210&#xA;mmc_execute_tuning+0x48/0xec&#xA;mmc_sd_init_uhs_card.part.0+0x208/0x464&#xA;mmc_sd_init_card+0x318/0x89c&#xA;mmc_attach_sd+0xe4/0x180&#xA;mmc_rescan+0x244/0x320&#xA;DMA API debug brings to light leaking dma-mappings as dma_map_sg and&#xA;dma_unmap_sg are not correctly balanced.&#xA;If an error occurs in mmci_cmd_irq function, only mmci_dma_error&#xA;function is called and as this API is not managed on stm32 variant,&#xA;dma_unmap_sg is never called in this error path.&#xA;CVE-2024-26801:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: Avoid potential use-after-free in hci_error_reset&#xA;While handling the HCI_EV_HARDWARE_ERROR event, if the underlying&#xA;BT controller is not responding, the GPIO reset mechanism would&#xA;free the hci_dev and lead to a use-after-free in hci_error_reset.&#xA;Here&#39;s the call trace observed on a ChromeOS device with Intel AX201:&#xA;   queue_work_on+0x3e/0x6c&#xA;   __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth &lt;HASH:3b4a6&gt;]&#xA;   ? init_wait_entry+0x31/0x31&#xA;   __hci_cmd_sync+0x16/0x20 [bluetooth &lt;HASH:3b4a 6&gt;]&#xA;   hci_error_reset+0x4f/0xa4 [bluetooth &lt;HASH:3b4a 6&gt;]&#xA;   process_one_work+0x1d8/0x33f&#xA;   worker_thread+0x21b/0x373&#xA;   kthread+0x13a/0x152&#xA;   ? pr_cont_work+0x54/0x54&#xA;   ? kthread_blkcg+0x31/0x31&#xA;    ret_from_fork+0x1f/0x30&#xA;This patch holds the reference count on the hci_dev while processing&#xA;a HCI_EV_HARDWARE_ERROR event to avoid potential crash.&#xA;CVE-2024-26805:In the Linux kernel, the following vulnerability has been resolved:&#xA;netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter&#xA;syzbot reported the following uninit-value access issue [1]:&#xA;netlink_to_full_skb() creates a new `skb` and puts the `skb-&gt;data`&#xA;passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data&#xA;size is specified as `len` and passed to skb_put_data(). This `len`&#xA;is based on `skb-&gt;end` that is not data offset but buffer offset. The&#xA;`skb-&gt;end` contains data and tailroom. Since the tailroom is not&#xA;initialized when the new `skb` created, KMSAN detects uninitialized&#xA;memory area when copying the data.&#xA;This patch resolved this issue by correct the len from `skb-&gt;end` to&#xA;`skb-&gt;len`, which is the actual data offset.&#xA;BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]&#xA;BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]&#xA;BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]&#xA;BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]&#xA;BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186&#xA; instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA; copy_to_user_iter lib/iov_iter.c:24 [inline]&#xA; iterate_ubuf include/linux/iov_iter.h:29 [inline]&#xA; iterate_and_advance2 include/linux/iov_iter.h:245 [inline]&#xA; iterate_and_advance include/linux/iov_iter.h:271 [inline]&#xA; _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186&#xA; copy_to_iter include/linux/uio.h:197 [inline]&#xA; simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532&#xA; __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420&#xA; skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546&#xA; skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]&#xA; packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482&#xA; sock_recvmsg_nosec net/socket.c:1044 [inline]&#xA; sock_recvmsg net/socket.c:1066 [inline]&#xA; sock_read_iter+0x467/0x580 net/socket.c:1136&#xA; call_read_iter include/linux/fs.h:2014 [inline]&#xA; new_sync_read fs/read_write.c:389 [inline]&#xA; vfs_read+0x8f6/0xe00 fs/read_write.c:470&#xA; ksys_read+0x20f/0x4c0 fs/read_write.c:613&#xA; __do_sys_read fs/read_write.c:623 [inline]&#xA; __se_sys_read fs/read_write.c:621 [inline]&#xA; __x64_sys_read+0x93/0xd0 fs/read_write.c:621&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was stored to memory at:&#xA; skb_put_data include/linux/skbuff.h:2622 [inline]&#xA; netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]&#xA; __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]&#xA; __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325&#xA; netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]&#xA; netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]&#xA; netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368&#xA; netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA; __sys_sendmsg net/socket.c:2667 [inline]&#xA; __do_sys_sendmsg net/socket.c:2676 [inline]&#xA; __se_sys_sendmsg net/socket.c:2674 [inline]&#xA; __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA; free_pages_prepare mm/page_alloc.c:1087 [inline]&#xA; free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347&#xA; free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533&#xA; release_pages+0x23d3/0x2410 mm/swap.c:1042&#xA; free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316&#xA; tlb_batch_pages&#xA;---truncated---&#xA;CVE-2024-26808:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain&#xA;Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER&#xA;event is reported, otherwise a stale reference to netdevice remains in&#xA;the hook list.&#xA;CVE-2024-26809:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_set_pipapo: release elements in clone only from destroy path&#xA;Clone already always provides a current view of the lookup table, use it&#xA;to destroy the set, otherwise it is possible to destroy elements twice.&#xA;This fix requires:&#xA; 212ed75dc5fb (&#34;netfilter: nf_tables: integrate pipapo into commit protocol&#34;)&#xA;which came after:&#xA; 9827a0e6e23b (&#34;netfilter: nft_set_pipapo: release elements in clone from abort path&#34;).&#xA;CVE-2024-26814:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfio/fsl-mc: Block calling interrupt handler without trigger&#xA;The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is&#xA;initially NULL and may become NULL if the user sets the trigger&#xA;eventfd to -1.  The interrupt handler itself is guaranteed that&#xA;trigger is always valid between request_irq() and free_irq(), but&#xA;the loopback testing mechanisms to invoke the handler function&#xA;need to test the trigger.  The triggering and setting ioctl paths&#xA;both make use of igate and are therefore mutually exclusive.&#xA;The vfio-fsl-mc driver does not make use of irqfds, nor does it&#xA;support any sort of masking operations, therefore unlike vfio-pci&#xA;and vfio-platform, the flow can remain essentially unchanged.&#xA;CVE-2024-26851:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_conntrack_h323: Add protection for bmp length out of range&#xA;UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts&#xA;that are out of bounds for their data type.&#xA;vmlinux get_bitmap(b=75) + 712&#xA;&lt;net/netfilter/nf_conntrack_h323_asn1.c:0&gt;&#xA;vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956&#xA;&lt;net/netfilter/nf_conntrack_h323_asn1.c:592&gt;&#xA;vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216&#xA;&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;&#xA;vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812&#xA;&lt;net/netfilter/nf_conntrack_h323_asn1.c:576&gt;&#xA;vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216&#xA;&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;&#xA;vmlinux   DecodeRasMessage() + 304&#xA;&lt;net/netfilter/nf_conntrack_h323_asn1.c:833&gt;&#xA;vmlinux   ras_help() + 684&#xA;&lt;net/netfilter/nf_conntrack_h323_main.c:1728&gt;&#xA;vmlinux   nf_confirm() + 188&#xA;&lt;net/netfilter/nf_conntrack_proto.c:137&gt;&#xA;Due to abnormal data in skb-&gt;data, the extension bitmap length&#xA;exceeds 32 when decoding ras message then uses the length to make&#xA;a shift operation. It will change into negative after several loop.&#xA;UBSAN load could detect a negative shift as an undefined behaviour&#xA;and reports exception.&#xA;So we add the protection to avoid the length exceeding 32. Or else&#xA;it will return out of range error and stop decoding.&#xA;CVE-2024-26881:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hns3: fix kernel crash when 1588 is received on HIP08 devices&#xA;The HIP08 devices does not register the ptp devices, so the&#xA;hdev-&gt;ptp is NULL, but the hardware can receive 1588 messages,&#xA;and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the&#xA;access of hdev-&gt;ptp-&gt;flags will cause a kernel crash:&#xA;[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018&#xA;[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018&#xA;...&#xA;[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]&#xA;[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]&#xA;[ 5889.279101] sp : ffff800012c3bc50&#xA;[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040&#xA;[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500&#xA;[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000&#xA;[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000&#xA;[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080&#xA;[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000&#xA;[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000&#xA;[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000&#xA;[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df&#xA;[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000&#xA;[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d&#xA;[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480&#xA;[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000&#xA;[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000&#xA;[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080&#xA;[ 5889.378857] Call trace:&#xA;[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]&#xA;[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]&#xA;[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]&#xA;[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]&#xA;[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]&#xA;[ 5889.411084] napi_poll+0xcc/0x264&#xA;[ 5889.415329] net_rx_action+0xd4/0x21c&#xA;[ 5889.419911] __do_softirq+0x130/0x358&#xA;[ 5889.424484] irq_exit+0x134/0x154&#xA;[ 5889.428700] __handle_domain_irq+0x88/0xf0&#xA;[ 5889.433684] gic_handle_irq+0x78/0x2c0&#xA;[ 5889.438319] el1_irq+0xb8/0x140&#xA;[ 5889.442354] arch_cpu_idle+0x18/0x40&#xA;[ 5889.446816] default_idle_call+0x5c/0x1c0&#xA;[ 5889.451714] cpuidle_idle_call+0x174/0x1b0&#xA;[ 5889.456692] do_idle+0xc8/0x160&#xA;[ 5889.460717] cpu_startup_entry+0x30/0xfc&#xA;[ 5889.465523] secondary_start_kernel+0x158/0x1ec&#xA;[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)&#xA;[ 5889.477950] SMP: stopping secondary CPUs&#xA;[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95&#xA;[ 5890.522951] Starting crashdump kernel...&#xA;CVE-2024-26900:In the Linux kernel, the following vulnerability has been resolved:&#xA;md: fix kmemleak of rdev-&gt;serial&#xA;If kobject_add() is fail in bind_rdev_to_array(), &#39;rdev-&gt;serial&#39; will be&#xA;alloc not be freed, and kmemleak occurs.&#xA;unreferenced object 0xffff88815a350000 (size 49152):&#xA;  comm &#34;mdadm&#34;, pid 789, jiffies 4294716910&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace (crc f773277a):&#xA;    [&lt;0000000058b0a453&gt;] kmemleak_alloc+0x61/0xe0&#xA;    [&lt;00000000366adf14&gt;] __kmalloc_large_node+0x15e/0x270&#xA;    [&lt;000000002e82961b&gt;] __kmalloc_node.cold+0x11/0x7f&#xA;    [&lt;00000000f206d60a&gt;] kvmalloc_node+0x74/0x150&#xA;    [&lt;0000000034bf3363&gt;] rdev_init_serial+0x67/0x170&#xA;    [&lt;0000000010e08fe9&gt;] mddev_create_serial_pool+0x62/0x220&#xA;    [&lt;00000000c3837bf0&gt;] bind_rdev_to_array+0x2af/0x630&#xA;    [&lt;0000000073c28560&gt;] md_add_new_disk+0x400/0x9f0&#xA;    [&lt;00000000770e30ff&gt;] md_ioctl+0x15bf/0x1c10&#xA;    [&lt;000000006cfab718&gt;] blkdev_ioctl+0x191/0x3f0&#xA;    [&lt;0000000085086a11&gt;] vfs_ioctl+0x22/0x60&#xA;    [&lt;0000000018b656fe&gt;] __x64_sys_ioctl+0xba/0xe0&#xA;    [&lt;00000000e54e675e&gt;] do_syscall_64+0x71/0x150&#xA;    [&lt;000000008b0ad622&gt;] entry_SYSCALL_64_after_hwframe+0x6c/0x74&#xA;CVE-2024-26901:In the Linux kernel, the following vulnerability has been resolved:&#xA;do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak&#xA;syzbot identified a kernel information leak vulnerability in&#xA;do_sys_name_to_handle() and issued the following report [1].&#xA;[1]&#xA;&#34;BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40&#xA; instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA; _copy_to_user+0xbc/0x100 lib/usercopy.c:40&#xA; copy_to_user include/linux/uaccess.h:191 [inline]&#xA; do_sys_name_to_handle fs/fhandle.c:73 [inline]&#xA; __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]&#xA; __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94&#xA; __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94&#xA; ...&#xA;Uninit was created at:&#xA; slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768&#xA; slab_alloc_node mm/slub.c:3478 [inline]&#xA; __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517&#xA; __do_kmalloc_node mm/slab_common.c:1006 [inline]&#xA; __kmalloc+0x121/0x3c0 mm/slab_common.c:1020&#xA; kmalloc include/linux/slab.h:604 [inline]&#xA; do_sys_name_to_handle fs/fhandle.c:39 [inline]&#xA; __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]&#xA; __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94&#xA; __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94&#xA; ...&#xA;Bytes 18-19 of 20 are uninitialized&#xA;Memory access of size 20 starts at ffff888128a46380&#xA;Data copied to user address 0000000020000240&#34;&#xA;Per Chuck Lever&#39;s suggestion, use kzalloc() instead of kmalloc() to&#xA;solve the problem.&#xA;CVE-2024-26903:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security&#xA;During our fuzz testing of the connection and disconnection process at the&#xA;RFCOMM layer, we discovered this bug. By comparing the packets from a&#xA;normal connection and disconnection process with the testcase that&#xA;triggered a KASAN report. We analyzed the cause of this bug as follows:&#xA;1. In the packets captured during a normal connection, the host sends a&#xA;`Read Encryption Key Size` type of `HCI_CMD` packet&#xA;(Command Opcode: 0x1408) to the controller to inquire the length of&#xA;encryption key.After receiving this packet, the controller immediately&#xA;replies with a Command Completepacket (Event Code: 0x0e) to return the&#xA;Encryption Key Size.&#xA;2. In our fuzz test case, the timing of the controller&#39;s response to this&#xA;packet was delayed to an unexpected point: after the RFCOMM and L2CAP&#xA;layers had disconnected but before the HCI layer had disconnected.&#xA;3. After receiving the Encryption Key Size Response at the time described&#xA;in point 2, the host still called the rfcomm_check_security function.&#xA;However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)-&gt;chan-&gt;conn;`&#xA;had already been released, and when the function executed&#xA;`return hci_conn_security(conn-&gt;hcon, d-&gt;sec_level, auth_type, d-&gt;out);`,&#xA;specifically when accessing `conn-&gt;hcon`, a null-ptr-deref error occurred.&#xA;To fix this bug, check if `sk-&gt;sk_state` is BT_CLOSED before calling&#xA;rfcomm_recv_frame in rfcomm_process_rx.&#xA;CVE-2024-26907:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/mlx5: Fix fortify source warning while accessing Eth segment&#xA; ------------[ cut here ]------------&#xA; memcpy: detected field-spanning write (size 56) of single field &#34;eseg-&gt;inline_hdr.start&#34; at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)&#xA; WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]&#xA; Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy&#xA;  [last unloaded: mlx_compat(OE)]&#xA; CPU: 0 PID: 293779 Comm: ssh Tainted: G           OE      6.2.0-32-generic #32~22.04.1-Ubuntu&#xA; Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011&#xA; RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]&#xA; Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da &lt;0f&gt; 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7&#xA; RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046&#xA; RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000&#xA; RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA; RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000&#xA; R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8&#xA; R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80&#xA; FS:  00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? show_regs+0x72/0x90&#xA;  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]&#xA;  ? __warn+0x8d/0x160&#xA;  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]&#xA;  ? report_bug+0x1bb/0x1d0&#xA;  ? handle_bug+0x46/0x90&#xA;  ? exc_invalid_op+0x19/0x80&#xA;  ? asm_exc_invalid_op+0x1b/0x20&#xA;  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]&#xA;  mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]&#xA;  ipoib_send+0x2ec/0x770 [ib_ipoib]&#xA;  ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]&#xA;  dev_hard_start_xmit+0x8e/0x1e0&#xA;  ? validate_xmit_skb_list+0x4d/0x80&#xA;  sch_direct_xmit+0x116/0x3a0&#xA;  __dev_xmit_skb+0x1fd/0x580&#xA;  __dev_queue_xmit+0x284/0x6b0&#xA;  ? _raw_spin_unlock_irq+0xe/0x50&#xA;  ? __flush_work.isra.0+0x20d/0x370&#xA;  ? push_pseudo_header+0x17/0x40 [ib_ipoib]&#xA;  neigh_connected_output+0xcd/0x110&#xA;  ip_finish_output2+0x179/0x480&#xA;  ? __smp_call_single_queue+0x61/0xa0&#xA;  __ip_finish_output+0xc3/0x190&#xA;  ip_finish_output+0x2e/0xf0&#xA;  ip_output+0x78/0x110&#xA;  ? __pfx_ip_finish_output+0x10/0x10&#xA;  ip_local_out+0x64/0x70&#xA;  __ip_queue_xmit+0x18a/0x460&#xA;  ip_queue_xmit+0x15/0x30&#xA;  __tcp_transmit_skb+0x914/0x9c0&#xA;  tcp_write_xmit+0x334/0x8d0&#xA;  tcp_push_one+0x3c/0x60&#xA;  tcp_sendmsg_locked+0x2e1/0xac0&#xA;  tcp_sendmsg+0x2d/0x50&#xA;  inet_sendmsg+0x43/0x90&#xA;  sock_sendmsg+0x68/0x80&#xA;  sock_write_iter+0x93/0x100&#xA;  vfs_write+0x326/0x3c0&#xA;  ksys_write+0xbd/0xf0&#xA;  ? do_syscall_64+0x69/0x90&#xA;  __x64_sys_write+0x19/0x30&#xA;  do_syscall_&#xA;---truncated---&#xA;CVE-2024-26908:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-26923:In the Linux kernel, the following vulnerability has been resolved:&#xA;af_unix: Fix garbage collector racing against connect()&#xA;Garbage collector does not take into account the risk of embryo getting&#xA;enqueued during the garbage collection. If such embryo has a peer that&#xA;carries SCM_RIGHTS, two consecutive passes of scan_children() may see a&#xA;different set of children. Leading to an incorrectly elevated inflight&#xA;count, and then a dangling pointer within the gc_inflight_list.&#xA;sockets are AF_UNIX/SOCK_STREAM&#xA;S is an unconnected socket&#xA;L is a listening in-flight socket bound to addr, not in fdtable&#xA;V&#39;s fd will be passed via sendmsg(), gets inflight count bumped&#xA;connect(S, addr)&#x9;sendmsg(S, [V]); close(V)&#x9;__unix_gc()&#xA;----------------&#x9;-------------------------&#x9;-----------&#xA;NS = unix_create1()&#xA;skb1 = sock_wmalloc(NS)&#xA;L = unix_find_other(addr)&#xA;unix_state_lock(L)&#xA;unix_peer(S) = NS&#xA;&#x9;&#x9;&#x9;// V count=1 inflight=0&#xA; &#x9;&#x9;&#x9;NS = unix_peer(S)&#xA; &#x9;&#x9;&#x9;skb2 = sock_alloc()&#xA;&#x9;&#x9;&#x9;skb_queue_tail(NS, skb2[V])&#xA;&#x9;&#x9;&#x9;// V became in-flight&#xA;&#x9;&#x9;&#x9;// V count=2 inflight=1&#xA;&#x9;&#x9;&#x9;close(V)&#xA;&#x9;&#x9;&#x9;// V count=1 inflight=1&#xA;&#x9;&#x9;&#x9;// GC candidate condition met&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;for u in gc_inflight_list:&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  if (total_refs == inflight_refs)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;    add u to gc_candidates&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// gc_candidates={L, V}&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;for u in gc_candidates:&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  scan_children(u, dec_inflight)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// embryo (skb1) was not&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// reachable from L yet, so V&#39;s&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// inflight remains unchanged&#xA;__skb_queue_tail(L, skb1)&#xA;unix_state_unlock(L)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;for u in gc_candidates:&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  if (u.inflight)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;    scan_children(u, inc_inflight_move_tail)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// V count=1 inflight=2 (!)&#xA;If there is a GC-candidate listening socket, lock/unlock its state. This&#xA;makes GC wait until the end of any ongoing connect() to that socket. After&#xA;flipping the lock, a possibly SCM-laden embryo is already enqueued. And if&#xA;there is another embryo coming, it can not possibly carry SCM_RIGHTS. At&#xA;this point, unix_inflight() can not happen because unix_gc_lock is already&#xA;taken. Inflight graph remains unaffected.&#xA;CVE-2024-26937:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/i915/gt: Reset queue_priority_hint on parking&#xA;Originally, with strict in order execution, we could complete execution&#xA;only when the queue was empty. Preempt-to-busy allows replacement of an&#xA;active request that may complete before the preemption is processed by&#xA;HW. If that happens, the request is retired from the queue, but the&#xA;queue_priority_hint remains set, preventing direct submission until&#xA;after the next CS interrupt is processed.&#xA;This preempt-to-busy race can be triggered by the heartbeat, which will&#xA;also act as the power-management barrier and upon completion allow us to&#xA;idle the HW. We may process the completion of the heartbeat, and begin&#xA;parking the engine before the CS event that restores the&#xA;queue_priority_hint, causing us to fail the assertion that it is MIN.&#xA;&lt;3&gt;[  166.210729] __engine_park:283 GEM_BUG_ON(engine-&gt;sched_engine-&gt;queue_priority_hint != (-((int)(~0U &gt;&gt; 1)) - 1))&#xA;&lt;0&gt;[  166.210781] Dumping ftrace buffer:&#xA;&lt;0&gt;[  166.210795] ---------------------------------&#xA;...&#xA;&lt;0&gt;[  167.302811] drm_fdin-1097      2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }&#xA;&lt;0&gt;[  167.302861] drm_fdin-1097      2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646&#xA;&lt;0&gt;[  167.302928] drm_fdin-1097      2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0&#xA;&lt;0&gt;[  167.302992] drm_fdin-1097      2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659&#xA;&lt;0&gt;[  167.303044] drm_fdin-1097      2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40&#xA;&lt;0&gt;[  167.303095] drm_fdin-1097      2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }&#xA;&lt;0&gt;[  167.303159] kworker/-89       11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2&#xA;&lt;0&gt;[  167.303208] kworker/-89       11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin&#xA;&lt;0&gt;[  167.303272] kworker/-89       11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2&#xA;&lt;0&gt;[  167.303321] kworker/-89       11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin&#xA;&lt;0&gt;[  167.303384] kworker/-89       11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660&#xA;&lt;0&gt;[  167.303434] kworker/-89       11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }&#xA;&lt;0&gt;[  167.303484] kworker/-89       11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked&#xA;&lt;0&gt;[  167.303534]   &lt;idle&gt;-0         5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040&#xA;&lt;0&gt;[  167.303583] kworker/-89       11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }&#xA;&lt;0&gt;[  167.303756] kworker/-89       11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }&#xA;&lt;0&gt;[  167.303806] kworker/-89       11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine-&gt;sched_engine-&gt;queue_priority_hint != (-((int)(~0U &gt;&gt; 1)) - 1))&#xA;&lt;0&gt;[  167.303811] ---------------------------------&#xA;&lt;4&gt;[  167.304722] ------------[ cut here ]------------&#xA;&lt;2&gt;[  167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!&#xA;&lt;4&gt;[  167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;&lt;4&gt;[  167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G        W          6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1&#xA;&lt;4&gt;[  167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022&#xA;&lt;4&gt;[  167.304738] Workqueue: i915-unordered retire_work_handler [i915]&#xA;&lt;4&gt;[  16&#xA;---truncated---&#xA;CVE-2024-26970:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays&#xA;The frequency table arrays are supposed to be terminated with an&#xA;empty element. Add such entry to the end of the arrays where it&#xA;is missing in order to avoid possible out-of-bound access when&#xA;the table is traversed by functions like qcom_find_freq() or&#xA;qcom_find_freq_floor().&#xA;Only compile tested.&#xA;CVE-2024-26976:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: Always flush async #PF workqueue when vCPU is being destroyed&#xA;Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its&#xA;completion queue, e.g. when a VM and all its vCPUs is being destroyed.&#xA;KVM must ensure that none of its workqueue callbacks is running when the&#xA;last reference to the KVM _module_ is put.  Gifting a reference to the&#xA;associated VM prevents the workqueue callback from dereferencing freed&#xA;vCPU/VM memory, but does not prevent the KVM module from being unloaded&#xA;before the callback completes.&#xA;Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from&#xA;async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will&#xA;result in deadlock.  async_pf_execute() can&#39;t return until kvm_put_kvm()&#xA;finishes, and kvm_put_kvm() can&#39;t return until async_pf_execute() finishes:&#xA; WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]&#xA; Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass&#xA; CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015&#xA; Workqueue: events async_pf_execute [kvm]&#xA; RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  async_pf_execute+0x198/0x260 [kvm]&#xA;  process_one_work+0x145/0x2d0&#xA;  worker_thread+0x27e/0x3a0&#xA;  kthread+0xba/0xe0&#xA;  ret_from_fork+0x2d/0x50&#xA;  ret_from_fork_asm+0x11/0x20&#xA;  &lt;/TASK&gt;&#xA; ---[ end trace 0000000000000000 ]---&#xA; INFO: task kworker/8:1:251 blocked for more than 120 seconds.&#xA;       Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119&#xA; &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA; task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000&#xA; Workqueue: events async_pf_execute [kvm]&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  __schedule+0x33f/0xa40&#xA;  schedule+0x53/0xc0&#xA;  schedule_timeout+0x12a/0x140&#xA;  __wait_for_common+0x8d/0x1d0&#xA;  __flush_work.isra.0+0x19f/0x2c0&#xA;  kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]&#xA;  kvm_arch_destroy_vm+0x78/0x1b0 [kvm]&#xA;  kvm_put_kvm+0x1c1/0x320 [kvm]&#xA;  async_pf_execute+0x198/0x260 [kvm]&#xA;  process_one_work+0x145/0x2d0&#xA;  worker_thread+0x27e/0x3a0&#xA;  kthread+0xba/0xe0&#xA;  ret_from_fork+0x2d/0x50&#xA;  ret_from_fork_asm+0x11/0x20&#xA;  &lt;/TASK&gt;&#xA;If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,&#xA;then there&#39;s no need to gift async_pf_execute() a reference because all&#xA;invocations of async_pf_execute() will be forced to complete before the&#xA;vCPU and its VM are destroyed/freed.  And that in turn fixes the module&#xA;unloading bug as __fput() won&#39;t do module_put() on the last vCPU reference&#xA;until the vCPU has been freed, e.g. if closing the vCPU file also puts the&#xA;last reference to the KVM module.&#xA;Note that kvm_check_async_pf_completion() may also take the work item off&#xA;the completion queue and so also needs to flush the work queue, as the&#xA;work will not be seen by kvm_clear_async_pf_completion_queue().  Waiting&#xA;on the workqueue could theoretically delay a vCPU due to waiting for the&#xA;work to complete, but that&#39;s a very, very small chance, and likely a very&#xA;small delay.  kvm_arch_async_page_present_queued() unconditionally makes a&#xA;new request, i.e. will effectively delay entering the guest, so the&#xA;remaining work is really just:&#xA;        trace_kvm_async_pf_completed(addr, cr2_or_gpa);&#xA;        __kvm_vcpu_wake_up(vcpu);&#xA;        mmput(mm);&#xA;and mmput() can&#39;t drop the last reference to the page tables if the vCPU is&#xA;still alive, i.e. the vCPU won&#39;t get stuck tearing down page tables.&#xA;Add a helper to do the flushing, specifically to deal with &#34;wakeup all&#34;&#xA;work items, as they aren&#39;t actually work items, i.e. are never placed in a&#xA;workqueue.  Trying to flush a bogus workqueue entry rightly makes&#xA;__flush_work() complain (kudos to whoever added that sanity check).&#xA;Note, commit 5f6de5cbebee (&#34;KVM: Prevent module exit until al&#xA;---truncated---&#xA;CVE-2024-26982:In the Linux kernel, the following vulnerability has been resolved:&#xA;Squashfs: check the inode number is not the invalid value of zero&#xA;Syskiller has produced an out of bounds access in fill_meta_index().&#xA;That out of bounds access is ultimately caused because the inode&#xA;has an inode number with the invalid value of zero, which was not checked.&#xA;The reason this causes the out of bounds access is due to following&#xA;sequence of events:&#xA;1. Fill_meta_index() is called to allocate (via empty_meta_index())&#xA;   and fill a metadata index.  It however suffers a data read error&#xA;   and aborts, invalidating the newly returned empty metadata index.&#xA;   It does this by setting the inode number of the index to zero,&#xA;   which means unused (zero is not a valid inode number).&#xA;2. When fill_meta_index() is subsequently called again on another&#xA;   read operation, locate_meta_index() returns the previous index&#xA;   because it matches the inode number of 0.  Because this index&#xA;   has been returned it is expected to have been filled, and because&#xA;   it hasn&#39;t been, an out of bounds access is performed.&#xA;This patch adds a sanity check which checks that the inode number&#xA;is not zero when the inode is created and returns -EINVAL if it is.&#xA;[phillip@squashfs.org.uk: whitespace fix]&#xA;  Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk&#xA;CVE-2024-27002:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: mediatek: Do a runtime PM get on controllers during probe&#xA;mt8183-mfgcfg has a mutual dependency with genpd during the probing&#xA;stage, which leads to a deadlock in the following call stack:&#xA;CPU0:  genpd_lock --&gt; clk_prepare_lock&#xA;genpd_power_off_work_fn()&#xA; genpd_lock()&#xA; generic_pm_domain::power_off()&#xA;    clk_unprepare()&#xA;      clk_prepare_lock()&#xA;CPU1: clk_prepare_lock --&gt; genpd_lock&#xA;clk_register()&#xA;  __clk_core_init()&#xA;    clk_prepare_lock()&#xA;    clk_pm_runtime_get()&#xA;      genpd_lock()&#xA;Do a runtime PM get at the probe function to make sure clk_register()&#xA;won&#39;t acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,&#xA;do this on all mediatek clock controller probings because we don&#39;t&#xA;believe this would cause any regression.&#xA;Verified on MT8183 and MT8192 Chromebooks.&#xA;CVE-2024-27072:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: usbtv: Remove useless locks in usbtv_video_free()&#xA;Remove locks calls in usbtv_video_free() because&#xA;are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000&#xA;Also remove usbtv_stop() call since it will be called when&#xA;unregistering the device.&#xA;Before &#39;c838530d230b&#39; this issue would only be noticed if you&#xA;disconnect while streaming and now it is noticeable even when&#xA;disconnecting while not streaming.&#xA;[hverkuil: fix minor spelling mistake in log message]&#xA;CVE-2024-27395:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: openvswitch: Fix Use-After-Free in ovs_ct_exit&#xA;Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal&#xA;of ovs_ct_limit_exit, is not part of the RCU read critical section, it&#xA;is possible that the RCU grace period will pass during the traversal and&#xA;the key will be free.&#xA;To prevent this, it should be changed to hlist_for_each_entry_safe.&#xA;CVE-2024-27396:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: gtp: Fix Use-After-Free in gtp_dellink&#xA;Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal&#xA;of gtp_dellink, is not part of the RCU read critical section, it&#xA;is possible that the RCU grace period will pass during the traversal and&#xA;the key will be free.&#xA;To prevent this, it should be changed to hlist_for_each_entry_safe.&#xA;CVE-2024-27398:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout&#xA;When the sco connection is established and then, the sco socket&#xA;is releasing, timeout_work will be scheduled to judge whether&#xA;the sco disconnection is timeout. The sock will be deallocated&#xA;later, but it is dereferenced again in sco_sock_timeout. As a&#xA;result, the use-after-free bugs will happen. The root cause is&#xA;shown below:&#xA;    Cleanup Thread               |      Worker Thread&#xA;sco_sock_release                 |&#xA;  sco_sock_close                 |&#xA;    __sco_sock_close             |&#xA;      sco_sock_set_timer         |&#xA;        schedule_delayed_work    |&#xA;  sco_sock_kill                  |    (wait a time)&#xA;    sock_put(sk) //FREE          |  sco_sock_timeout&#xA;                                 |    sock_hold(sk) //USE&#xA;The KASAN report triggered by POC is shown below:&#xA;[   95.890016] ==================================================================&#xA;[   95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0&#xA;[   95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7&#xA;...&#xA;[   95.890755] Workqueue: events sco_sock_timeout&#xA;[   95.890755] Call Trace:&#xA;[   95.890755]  &lt;TASK&gt;&#xA;[   95.890755]  dump_stack_lvl+0x45/0x110&#xA;[   95.890755]  print_address_description+0x78/0x390&#xA;[   95.890755]  print_report+0x11b/0x250&#xA;[   95.890755]  ? __virt_addr_valid+0xbe/0xf0&#xA;[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0&#xA;[   95.890755]  kasan_report+0x139/0x170&#xA;[   95.890755]  ? update_load_avg+0xe5/0x9f0&#xA;[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0&#xA;[   95.890755]  kasan_check_range+0x2c3/0x2e0&#xA;[   95.890755]  sco_sock_timeout+0x5e/0x1c0&#xA;[   95.890755]  process_one_work+0x561/0xc50&#xA;[   95.890755]  worker_thread+0xab2/0x13c0&#xA;[   95.890755]  ? pr_cont_work+0x490/0x490&#xA;[   95.890755]  kthread+0x279/0x300&#xA;[   95.890755]  ? pr_cont_work+0x490/0x490&#xA;[   95.890755]  ? kthread_blkcg+0xa0/0xa0&#xA;[   95.890755]  ret_from_fork+0x34/0x60&#xA;[   95.890755]  ? kthread_blkcg+0xa0/0xa0&#xA;[   95.890755]  ret_from_fork_asm+0x11/0x20&#xA;[   95.890755]  &lt;/TASK&gt;&#xA;[   95.890755]&#xA;[   95.890755] Allocated by task 506:&#xA;[   95.890755]  kasan_save_track+0x3f/0x70&#xA;[   95.890755]  __kasan_kmalloc+0x86/0x90&#xA;[   95.890755]  __kmalloc+0x17f/0x360&#xA;[   95.890755]  sk_prot_alloc+0xe1/0x1a0&#xA;[   95.890755]  sk_alloc+0x31/0x4e0&#xA;[   95.890755]  bt_sock_alloc+0x2b/0x2a0&#xA;[   95.890755]  sco_sock_create+0xad/0x320&#xA;[   95.890755]  bt_sock_create+0x145/0x320&#xA;[   95.890755]  __sock_create+0x2e1/0x650&#xA;[   95.890755]  __sys_socket+0xd0/0x280&#xA;[   95.890755]  __x64_sys_socket+0x75/0x80&#xA;[   95.890755]  do_syscall_64+0xc4/0x1b0&#xA;[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f&#xA;[   95.890755]&#xA;[   95.890755] Freed by task 506:&#xA;[   95.890755]  kasan_save_track+0x3f/0x70&#xA;[   95.890755]  kasan_save_free_info+0x40/0x50&#xA;[   95.890755]  poison_slab_object+0x118/0x180&#xA;[   95.890755]  __kasan_slab_free+0x12/0x30&#xA;[   95.890755]  kfree+0xb2/0x240&#xA;[   95.890755]  __sk_destruct+0x317/0x410&#xA;[   95.890755]  sco_sock_release+0x232/0x280&#xA;[   95.890755]  sock_close+0xb2/0x210&#xA;[   95.890755]  __fput+0x37f/0x770&#xA;[   95.890755]  task_work_run+0x1ae/0x210&#xA;[   95.890755]  get_signal+0xe17/0xf70&#xA;[   95.890755]  arch_do_signal_or_restart+0x3f/0x520&#xA;[   95.890755]  syscall_exit_to_user_mode+0x55/0x120&#xA;[   95.890755]  do_syscall_64+0xd1/0x1b0&#xA;[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f&#xA;[   95.890755]&#xA;[   95.890755] The buggy address belongs to the object at ffff88800c388000&#xA;[   95.890755]  which belongs to the cache kmalloc-1k of size 1024&#xA;[   95.890755] The buggy address is located 128 bytes inside of&#xA;[   95.890755]  freed 1024-byte region [ffff88800c388000, ffff88800c388400)&#xA;[   95.890755]&#xA;[   95.890755] The buggy address belongs to the physical page:&#xA;[   95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388&#xA;[   95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0&#xA;[   95.890755] ano&#xA;---truncated---&#xA;CVE-2024-27401:In the Linux kernel, the following vulnerability has been resolved:&#xA;firewire: nosy: ensure user_length is taken into account when fetching packet contents&#xA;Ensure that packet_buffer_get respects the user_length provided. If&#xA;the length of the head packet exceeds the user_length, packet_buffer_get&#xA;will now return 0 to signify to the user that no data were read&#xA;and a larger buffer size is required. Helps prevent user space overflows.&#xA;CVE-2024-27407:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Fixed overflow check in mi_enum_attr()&#xA;CVE-2024-27419:In the Linux kernel, the following vulnerability has been resolved:&#xA;netrom: Fix data-races around sysctl_net_busy_read&#xA;We need to protect the reader reading the sysctl value because the&#xA;value can be changed concurrently.&#xA;CVE-2024-27426:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-27427:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-27431:In the Linux kernel, the following vulnerability has been resolved:&#xA;cpumap: Zero-initialise xdp_rxq_info struct before running XDP program&#xA;When running an XDP program that is attached to a cpumap entry, we don&#39;t&#xA;initialise the xdp_rxq_info data structure being used in the xdp_buff&#xA;that backs the XDP program invocation. Tobias noticed that this leads to&#xA;random values being returned as the xdp_md-&gt;rx_queue_index value for XDP&#xA;programs running in a cpumap.&#xA;This means we&#39;re basically returning the contents of the uninitialised&#xA;memory, which is bad. Fix this by zero-initialising the rxq data&#xA;structure before running the XDP program.&#xA;CVE-2024-34459:An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.&#xA;CVE-2024-35791:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: SVM: Flush pages under kvm-&gt;lock to fix UAF in svm_register_enc_region()&#xA;Do the cache flush of converted pages in svm_register_enc_region() before&#xA;dropping kvm-&gt;lock to fix use-after-free issues where region and/or its&#xA;array of pages could be freed by a different task, e.g. if userspace has&#xA;__unregister_enc_region_locked() already queued up for the region.&#xA;Note, the &#34;obvious&#34; alternative of using local variables doesn&#39;t fully&#xA;resolve the bug, as region-&gt;pages is also dynamically allocated.  I.e. the&#xA;region structure itself would be fine, but region-&gt;pages could be freed.&#xA;Flushing multiple pages under kvm-&gt;lock is unfortunate, but the entire&#xA;flow is a rare slow path, and the manual flush is only needed on CPUs that&#xA;lack coherency for encrypted memory.&#xA;CVE-2024-35801:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD&#xA;Commit 672365477ae8 (&#34;x86/fpu: Update XFD state where required&#34;) and&#xA;commit 8bf26758ca96 (&#34;x86/fpu: Add XFD state to fpstate&#34;) introduced a&#xA;per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in&#xA;order to avoid unnecessary writes to the MSR.&#xA;On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which&#xA;wipes out any stale state. But the per CPU cached xfd value is not&#xA;reset, which brings them out of sync.&#xA;As a consequence a subsequent xfd_update_state() might fail to update&#xA;the MSR which in turn can result in XRSTOR raising a #NM in kernel&#xA;space, which crashes the kernel.&#xA;To fix this, introduce xfd_set_state() to write xfd_state together&#xA;with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.&#xA;CVE-2024-35805:In the Linux kernel, the following vulnerability has been resolved:&#xA;dm snapshot: fix lockup in dm_exception_table_exit&#xA;There was reported lockup when we exit a snapshot with many exceptions.&#xA;Fix this by adding &#34;cond_resched&#34; to the loop that frees the exceptions.&#xA;CVE-2024-35806:In the Linux kernel, the following vulnerability has been resolved:&#xA;soc: fsl: qbman: Always disable interrupts when taking cgr_lock&#xA;smp_call_function_single disables IRQs when executing the callback. To&#xA;prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.&#xA;This is already done by qman_update_cgr and qman_delete_cgr; fix the&#xA;other lockers.&#xA;CVE-2024-35807:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix corruption during on-line resize&#xA;We observed a corruption during on-line resize of a file system that is&#xA;larger than 16 TiB with 4k block size. With having more then 2^32 blocks&#xA;resize_inode is turned off by default by mke2fs. The issue can be&#xA;reproduced on a smaller file system for convenience by explicitly&#xA;turning off resize_inode. An on-line resize across an 8 GiB boundary (the&#xA;size of a meta block group in this setup) then leads to a corruption: dev=/dev/&lt;some_dev&gt; # should be &gt;= 16 GiB&#xA;  mkdir -p /corruption&#xA;  /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))&#xA;  mount -t ext4 $dev /corruption&#xA;  dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))&#xA;  sha1sum /corruption/test&#xA;  # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test&#xA;  /sbin/resize2fs $dev $((2*2**21))&#xA;  # drop page cache to force reload the block from disk&#xA;  echo 1 &gt; /proc/sys/vm/drop_caches&#xA;  sha1sum /corruption/test&#xA;  # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test&#xA;2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per&#xA;block group and 2^6 are the number of block groups that make a meta&#xA;block group.&#xA;The last checksum might be different depending on how the file is laid&#xA;out across the physical blocks. The actual corruption occurs at physical&#xA;block 63*2^15 = 2064384 which would be the location of the backup of the&#xA;meta block group&#39;s block descriptor. During the on-line resize the file&#xA;system will be converted to meta_bg starting at s_first_meta_bg which is&#xA;2 in the example - meaning all block groups after 16 GiB. However, in&#xA;ext4_flex_group_add we might add block groups that are not part of the&#xA;first meta block group yet. In the reproducer we achieved this by&#xA;substracting the size of a whole block group from the point where the&#xA;meta block group would start. This must be considered when updating the&#xA;backup block group descriptors to follow the non-meta_bg layout. The fix&#xA;is to add a test whether the group to add is already part of the meta&#xA;block group or not.&#xA;CVE-2024-35818:In the Linux kernel, the following vulnerability has been resolved:&#xA;LoongArch: Define the __io_aw() hook as mmiowb()&#xA;Commit fb24ea52f78e0d595852e (&#34;drivers: Remove explicit invocations of&#xA;mmiowb()&#34;) remove all mmiowb() in drivers, but it says:&#xA;&#34;NOTE: mmiowb() has only ever guaranteed ordering in conjunction with&#xA;spin_unlock(). However, pairing each mmiowb() removal in this patch with&#xA;the corresponding call to spin_unlock() is not at all trivial, so there&#xA;is a small chance that this change may regress any drivers incorrectly&#xA;relying on mmiowb() to order MMIO writes between CPUs using lock-free&#xA;synchronisation.&#34;&#xA;The mmio in radeon_ring_commit() is protected by a mutex rather than a&#xA;spinlock, but in the mutex fastpath it behaves similar to spinlock. We&#xA;can add mmiowb() calls in the radeon driver but the maintainer says he&#xA;doesn&#39;t like such a workaround, and radeon is not the only example of&#xA;mutex protected mmio.&#xA;So we should extend the mmiowb tracking system from spinlock to mutex,&#xA;and maybe other locking primitives. This is not easy and error prone, so&#xA;we solve it in the architectural code, by simply defining the __io_aw()&#xA;hook as mmiowb(). And we no longer need to override queued_spin_unlock()&#xA;so use the generic definition.&#xA;Without this, we get such an error when run &#39;glxgears&#39; on weak ordering&#xA;architectures such as LoongArch:&#xA;radeon 0000:04:00.0: ring 0 stalled for more than 10324msec&#xA;radeon 0000:04:00.0: ring 3 stalled for more than 10240msec&#xA;radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)&#xA;radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;radeon 0000:04:00.0: scheduling IB failed (-35).&#xA;[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)&#xA;CVE-2024-35835:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: fix a double-free in arfs_create_groups&#xA;When `in` allocated by kvzalloc fails, arfs_create_groups will free&#xA;ft-&gt;g and return an error. However, arfs_create_table, the only caller of&#xA;arfs_create_groups, will hold this error and call to&#xA;mlx5e_destroy_flow_table, in which the ft-&gt;g will be freed again.&#xA;CVE-2024-35844:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: compress: fix reserve_cblocks counting error when out of space&#xA;When a file only needs one direct_node, performing the following&#xA;operations will cause the file to be unrepairable:&#xA;unisoc # ./f2fs_io compress test.apk&#xA;unisoc #df -h | grep dm-48&#xA;/dev/block/dm-48 112G 112G 1.2M 100% /data&#xA;unisoc # ./f2fs_io release_cblocks test.apk&#xA;924&#xA;unisoc # df -h | grep dm-48&#xA;/dev/block/dm-48 112G 112G 4.8M 100% /data&#xA;unisoc # dd if=/dev/random of=file4 bs=1M count=3&#xA;3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s&#xA;unisoc # df -h | grep dm-48&#xA;/dev/block/dm-48 112G 112G 1.8M 100% /data&#xA;unisoc # ./f2fs_io reserve_cblocks test.apk&#xA;F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device&#xA;adb reboot&#xA;unisoc # df -h  | grep dm-48&#xA;/dev/block/dm-48             112G 112G   11M 100% /data&#xA;unisoc # ./f2fs_io reserve_cblocks test.apk&#xA;0&#xA;This is because the file has only one direct_node. After returning&#xA;to -ENOSPC, reserved_blocks += ret will not be executed. As a result,&#xA;the reserved_blocks at this time is still 0, which is not the real&#xA;number of reserved blocks. Therefore, fsck cannot be set to repair&#xA;the file.&#xA;After this patch, the fsck flag will be set to fix this problem.&#xA;unisoc # df -h | grep dm-48&#xA;/dev/block/dm-48             112G 112G  1.8M 100% /data&#xA;unisoc # ./f2fs_io reserve_cblocks test.apk&#xA;F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device&#xA;adb reboot then fsck will be executed&#xA;unisoc # df -h  | grep dm-48&#xA;/dev/block/dm-48             112G 112G   11M 100% /data&#xA;unisoc # ./f2fs_io reserve_cblocks test.apk&#xA;924&#xA;CVE-2024-35845:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: dbg-tlv: ensure NUL termination&#xA;The iwl_fw_ini_debug_info_tlv is used as a string, so we must&#xA;ensure the string is terminated correctly before using it.&#xA;CVE-2024-35848:In the Linux kernel, the following vulnerability has been resolved:&#xA;eeprom: at24: fix memory corruption race condition&#xA;If the eeprom is not accessible, an nvmem device will be registered, the&#xA;read will fail, and the device will be torn down. If another driver&#xA;accesses the nvmem device after the teardown, it will reference&#xA;invalid memory.&#xA;Move the failure point before registering the nvmem device.&#xA;CVE-2024-35849:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix information leak in btrfs_ioctl_logical_to_ino()&#xA;Syzbot reported the following information leak for in&#xA;btrfs_ioctl_logical_to_ino():&#xA;  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;  BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40&#xA;   instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;   _copy_to_user+0xbc/0x110 lib/usercopy.c:40&#xA;   copy_to_user include/linux/uaccess.h:191 [inline]&#xA;   btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499&#xA;   btrfs_ioctl+0x714/0x1260&#xA;   vfs_ioctl fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl fs/ioctl.c:904 [inline]&#xA;   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890&#xA;   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890&#xA;   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17&#xA;   do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;  Uninit was created at:&#xA;   __kmalloc_large_node+0x231/0x370 mm/slub.c:3921&#xA;   __do_kmalloc_node mm/slub.c:3954 [inline]&#xA;   __kmalloc_node+0xb07/0x1060 mm/slub.c:3973&#xA;   kmalloc_node include/linux/slab.h:648 [inline]&#xA;   kvmalloc_node+0xc0/0x2d0 mm/util.c:634&#xA;   kvmalloc include/linux/slab.h:766 [inline]&#xA;   init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779&#xA;   btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480&#xA;   btrfs_ioctl+0x714/0x1260&#xA;   vfs_ioctl fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl fs/ioctl.c:904 [inline]&#xA;   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890&#xA;   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890&#xA;   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17&#xA;   do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;  Bytes 40-65535 of 65536 are uninitialized&#xA;  Memory access of size 65536 starts at ffff888045a40000&#xA;This happens, because we&#39;re copying a &#39;struct btrfs_data_container&#39; back&#xA;to user-space. This btrfs_data_container is allocated in&#xA;&#39;init_data_container()&#39; via kvmalloc(), which does not zero-fill the&#xA;memory.&#xA;Fix this by using kvzalloc() which zeroes out the memory on allocation.&#xA;CVE-2024-35898:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()&#xA;nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can&#xA;concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().&#xA;And thhere is not any protection when iterate over nf_tables_flowtables&#xA;list in __nft_flowtable_type_get(). Therefore, there is pertential&#xA;data-race of nf_tables_flowtables list entry.&#xA;Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list&#xA;in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller&#xA;nft_flowtable_type_get() to protect the entire type query process.&#xA;CVE-2024-35922:In the Linux kernel, the following vulnerability has been resolved:&#xA;fbmon: prevent division by zero in fb_videomode_from_videomode()&#xA;The expression htotal * vtotal can have a zero value on&#xA;overflow. It is necessary to prevent division by zero like in&#xA;fb_var_to_videomode().&#xA;Found by Linux Verification Center (linuxtesting.org) with Svace.&#xA;CVE-2024-35934:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()&#xA;Many syzbot reports show extreme rtnl pressure, and many of them hint&#xA;that smc acquires rtnl in netns creation for no good reason [1]&#xA;This patch returns early from smc_pnet_net_init()&#xA;if there is no netdevice yet.&#xA;I am not even sure why smc_pnet_create_pnetids_list() even exists,&#xA;because smc_pnet_netdev_event() is also calling&#xA;smc_pnet_add_base_pnetid() when handling NETDEV_UP event.&#xA;[1] extract of typical syzbot reports&#xA;2 locks held by syz-executor.3/12252:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.4/12253:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.1/12257:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.2/12261:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.0/12265:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.3/12268:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.4/12271:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.1/12274:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;2 locks held by syz-executor.2/12280:&#xA;  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]&#xA;  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878&#xA;CVE-2024-35936:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()&#xA;The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,&#xA;as it could be caused only by two impossible conditions:&#xA;- at first the search key is set up to look for a chunk tree item, with&#xA;  offset -1, this is an inexact search and the key-&gt;offset will contain&#xA;  the correct offset upon a successful search, a valid chunk tree item&#xA;  cannot have an offset -1&#xA;- after first successful search, the found_key corresponds to a chunk&#xA;  item, the offset is decremented by 1 before the next loop, it&#39;s&#xA;  impossible to find a chunk item there due to alignment and size&#xA;  constraints&#xA;CVE-2024-35938:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath11k: decrease MHI channel buffer length to 8KB&#xA;Currently buf_len field of ath11k_mhi_config_qca6390 is assigned&#xA;with 0, making MHI use a default size, 64KB, to allocate channel&#xA;buffers. This is likely to fail in some scenarios where system&#xA;memory is highly fragmented and memory compaction or reclaim is&#xA;not allowed.&#xA;There is a fail report which is caused by it:&#xA;kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0&#xA;CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb&#xA;Workqueue: events_unbound async_run_entry_fn&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x47/0x60&#xA; warn_alloc+0x13a/0x1b0&#xA; ? srso_alias_return_thunk+0x5/0xfbef5&#xA; ? __alloc_pages_direct_compact+0xab/0x210&#xA; __alloc_pages_slowpath.constprop.0+0xd3e/0xda0&#xA; __alloc_pages+0x32d/0x350&#xA; ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]&#xA; __kmalloc_large_node+0x72/0x110&#xA; __kmalloc+0x37c/0x480&#xA; ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]&#xA; ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]&#xA; mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]&#xA; __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]&#xA; ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]&#xA; device_for_each_child+0x5c/0xa0&#xA; ? __pfx_pci_pm_resume+0x10/0x10&#xA; ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]&#xA; ? srso_alias_return_thunk+0x5/0xfbef5&#xA; ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]&#xA; ? srso_alias_return_thunk+0x5/0xfbef5&#xA; dpm_run_callback+0x8c/0x1e0&#xA; device_resume+0x104/0x340&#xA; ? __pfx_dpm_watchdog_handler+0x10/0x10&#xA; async_resume+0x1d/0x30&#xA; async_run_entry_fn+0x32/0x120&#xA; process_one_work+0x168/0x330&#xA; worker_thread+0x2f5/0x410&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0xe8/0x120&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x34/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1b/0x30&#xA; &lt;/TASK&gt;&#xA;Actually those buffers are used only by QMI target -&gt; host communication.&#xA;And for WCN6855 and QCA6390, the largest packet size for that is less&#xA;than 6KB. So change buf_len field to 8KB, which results in order 1&#xA;allocation if page size is 4KB. In this way, we can at least save some&#xA;memory, and as well as decrease the possibility of allocation failure&#xA;in those scenarios.&#xA;Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30&#xA;CVE-2024-35940:In the Linux kernel, the following vulnerability has been resolved:&#xA;pstore/zone: Add a null pointer check to the psz_kmsg_read&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure. Ensure the allocation was successful&#xA;by checking the pointer validity.&#xA;CVE-2024-35943:In the Linux kernel, the following vulnerability has been resolved:&#xA;pmdomain: ti: Add a null pointer check to the omap_prm_domain_init&#xA;devm_kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure. Ensure the allocation was successful&#xA;by checking the pointer validity.&#xA;CVE-2024-35997:In the Linux kernel, the following vulnerability has been resolved:&#xA;HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up&#xA;The flag I2C_HID_READ_PENDING is used to serialize I2C operations.&#xA;However, this is not necessary, because I2C core already has its own&#xA;locking for that.&#xA;More importantly, this flag can cause a lock-up: if the flag is set in&#xA;i2c_hid_xfer() and an interrupt happens, the interrupt handler&#xA;(i2c_hid_irq) will check this flag and return immediately without doing&#xA;anything, then the interrupt handler will be invoked again in an&#xA;infinite loop.&#xA;Since interrupt handler is an RT task, it takes over the CPU and the&#xA;flag-clearing task never gets scheduled, thus we have a lock-up.&#xA;Delete this unnecessary flag.&#xA;CVE-2024-36006:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix incorrect list API usage&#xA;Both the function that migrates all the chunks within a region and the&#xA;function that migrates all the entries within a chunk call&#xA;list_first_entry() on the respective lists without checking that the&#xA;lists are not empty. This is incorrect usage of the API, which leads to&#xA;the following warning [1].&#xA;Fix by returning if the lists are empty as there is nothing to migrate&#xA;in this case.&#xA;[1]&#xA;WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0&gt;&#xA;Modules linked in:&#xA;CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work&#xA;RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0&#xA; process_one_work+0x151/0x370&#xA; worker_thread+0x2cb/0x3e0&#xA; kthread+0xd0/0x100&#xA; ret_from_fork+0x34/0x50&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;CVE-2024-36039:PyMySQL through 1.1.0 allows SQL injection if used with untrusted JSON input because keys are not escaped by escape_dict.&#xA;CVE-2024-4853:Memory handling issue in editcap could cause denial of service via crafted capture file&#xA;CVE-2024-4855:Use after free issue in editcap could cause denial of service via crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/kernel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/kernel-headers-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/kernel-devel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/kernel-tools-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/kernel-tools-devel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/perf-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/python3-perf-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/bpftool-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/kernel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/kernel-headers-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/kernel-devel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/kernel-tools-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/kernel-tools-devel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/perf-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/python3-perf-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/bpftool-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2201</id>
		<title>An update for libsndfile is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33065" id="CVE-2022-33065" title="CVE-2022-33065" type="cve"></reference>
		</references>
		<description>CVE-2022-33065:Atril is a simple multi-page document viewer. Atril is vulnerable to a critical Command Injection Vulnerability. This vulnerability gives the attacker immediate access to the target system when the target user opens a crafted document or clicks on a crafted link/URL using a maliciously crafted CBT document which is a TAR archive. A patch is available at commit ce41df6.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="libsndfile" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-1.0.31-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libsndfile-1.0.31-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsndfile-devel" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-devel-1.0.31-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libsndfile-devel-1.0.31-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsndfile-utils" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-utils-1.0.31-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libsndfile-utils-1.0.31-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libsndfile-utils-help" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-utils-help-1.0.31-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libsndfile-utils-help-1.0.31-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-1.0.31-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libsndfile-1.0.31-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile-devel" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-devel-1.0.31-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libsndfile-devel-1.0.31-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile-utils" release="4.u3.fos23" version="1.0.31">
					<filename>libsndfile-utils-1.0.31-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libsndfile-utils-1.0.31-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2202</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1916" id="CVE-2023-1916" title="CVE-2023-1916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3164" id="CVE-2023-3164" title="CVE-2023-3164" type="cve"></reference>
		</references>
		<description>CVE-2023-1916:A flaw was found in tiffcrop, a program distributed by the libtiff package. A specially crafted tiff file can lead to an out-of-bounds read in the extractImageSection function in tools/tiffcrop.c, resulting in a denial of service and limited information disclosure. This issue affects libtiff versions 4.x.&#xA;CVE-2023-3164:A heap-buffer-overflow vulnerability was found in LibTIFF, in extractImageSection() at tools/tiffcrop.c:7916 and tools/tiffcrop.c:7801. This flaw allows attackers to cause a denial of service via a crafted tiff file.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-37.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libtiff-4.3.0-37.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-37.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libtiff-devel-4.3.0-37.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-37.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libtiff-static-4.3.0-37.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-37.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libtiff-tools-4.3.0-37.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-37.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libtiff-help-4.3.0-37.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-37.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libtiff-4.3.0-37.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-37.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libtiff-devel-4.3.0-37.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-37.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libtiff-static-4.3.0-37.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="37.u13.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-37.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libtiff-tools-4.3.0-37.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2203</id>
		<title>An update for libvirt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4418" id="CVE-2024-4418" title="CVE-2024-4418" type="cve"></reference>
		</references>
		<description>CVE-2024-4418:A race condition leading to a stack use-after-free flaw was found in libvirt. Due to a bad assumption in the virNetClientIOEventLoop() method, the `data` pointer to a stack-allocated virNetClientIOEventData structure ended up being used in the virNetClientIOEventFD callback while the data pointer&#39;s stack frame was concurrently being &#34;freed&#34; when returning from virNetClientIOEventLoop(). The &#39;virtproxyd&#39; daemon can be used to trigger requests. If libvirt is configured with fine-grained access control, this issue, in theory, allows a user to escape their otherwise limited access. This flaw allows a local, unprivileged user to access virtproxyd without authenticating. Remote users would need to authenticate before they could access it.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="libvirt" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-docs" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-docs-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-docs-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-config-network" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-network-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-config-network-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-config-nwfilter" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-nwfilter-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-config-nwfilter-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-network" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-network-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-network-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-nwfilter" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nwfilter-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-nwfilter-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-nodedev" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nodedev-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-nodedev-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-interface" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-interface-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-interface-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-secret" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-secret-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-secret-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-core" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-core-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-core-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-logical" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-logical-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-logical-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-disk" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-disk-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-disk-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-scsi" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-scsi-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-scsi-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-iscsi" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-iscsi-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-iscsi-direct" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-iscsi-direct-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-mpath" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-mpath-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-mpath-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-gluster" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-gluster-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-gluster-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-rbd" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-rbd-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-rbd-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-storage-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-qemu" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-qemu-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-driver-qemu-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-qemu" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-qemu-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-qemu-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-kvm" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-kvm-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-daemon-kvm-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-client" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-client-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-client-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-libs" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-libs-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-libs-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-admin" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-admin-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-admin-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-bash-completion" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-bash-completion-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-bash-completion-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-wireshark" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-wireshark-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-wireshark-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-devel" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-devel-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-devel-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-lock-sanlock" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-lock-sanlock-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-lock-sanlock-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-nss" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-nss-6.2.0-64.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libvirt-nss-6.2.0-64.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-docs" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-docs-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-docs-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-config-network" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-network-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-config-network-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-config-nwfilter" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-config-nwfilter-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-config-nwfilter-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-network" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-network-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-network-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-nwfilter" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nwfilter-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-nwfilter-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-nodedev" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-nodedev-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-nodedev-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-interface" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-interface-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-interface-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-secret" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-secret-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-secret-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-core" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-core-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-core-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-logical" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-logical-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-logical-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-disk" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-disk-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-disk-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-scsi" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-scsi-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-scsi-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-iscsi" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-iscsi-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-iscsi-direct" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-iscsi-direct-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-mpath" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-mpath-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-mpath-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-gluster" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-gluster-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-gluster-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-rbd" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-rbd-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-rbd-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-storage-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-qemu" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-driver-qemu-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-driver-qemu-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-qemu" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-qemu-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-qemu-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-kvm" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-daemon-kvm-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-daemon-kvm-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-client" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-client-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-client-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-libs" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-libs-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-libs-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-admin" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-admin-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-admin-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-bash-completion" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-bash-completion-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-bash-completion-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-wireshark" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-wireshark-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-wireshark-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-devel" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-devel-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-devel-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-lock-sanlock" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-lock-sanlock-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-lock-sanlock-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-nss" release="64.u10.fos23" version="6.2.0">
					<filename>libvirt-nss-6.2.0-64.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libvirt-nss-6.2.0-64.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2204</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34459" id="CVE-2024-34459" title="CVE-2024-34459" type="cve"></reference>
		</references>
		<description>CVE-2024-34459:An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="libxml2" release="13.u8.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-13.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libxml2-2.9.14-13.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="13.u8.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-13.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/libxml2-devel-2.9.14-13.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="13.u8.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-13.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/python3-libxml2-2.9.14-13.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="13.u8.fos23" version="2.9.14">
					<filename>libxml2-help-2.9.14-13.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libxml2-help-2.9.14-13.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="13.u8.fos23" version="2.9.14">
					<filename>libxml2-2.9.14-13.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libxml2-2.9.14-13.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="13.u8.fos23" version="2.9.14">
					<filename>libxml2-devel-2.9.14-13.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/libxml2-devel-2.9.14-13.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="13.u8.fos23" version="2.9.14">
					<filename>python3-libxml2-2.9.14-13.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/python3-libxml2-2.9.14-13.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2205</id>
		<title>An update for nautilus is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37290" id="CVE-2022-37290" title="CVE-2022-37290" type="cve"></reference>
		</references>
		<description>CVE-2022-37290:GNOME Nautilus 42.2 allows a NULL pointer dereference and get_basename application crash via a pasted ZIP archive.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="nautilus" release="2.u5.fos23" version="3.38.2">
					<filename>nautilus-3.38.2-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/nautilus-3.38.2-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nautilus-devel" release="2.u5.fos23" version="3.38.2">
					<filename>nautilus-devel-3.38.2-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/nautilus-devel-3.38.2-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nautilus-help" release="2.u5.fos23" version="3.38.2">
					<filename>nautilus-help-3.38.2-2.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/nautilus-help-3.38.2-2.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nautilus" release="2.u5.fos23" version="3.38.2">
					<filename>nautilus-3.38.2-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/nautilus-3.38.2-2.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nautilus-devel" release="2.u5.fos23" version="3.38.2">
					<filename>nautilus-devel-3.38.2-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/nautilus-devel-3.38.2-2.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2206</id>
		<title>An update for python-PyMySQL is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36039" id="CVE-2024-36039" title="CVE-2024-36039" type="cve"></reference>
		</references>
		<description>CVE-2024-36039:PyMySQL through 1.1.0 allows SQL injection if used with untrusted JSON input because keys are not escaped by escape_dict.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="noarch" epoch="0" name="python3-PyMySQL" release="4.u1.fos23" version="0.9.3">
					<filename>python3-PyMySQL-0.9.3-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/python3-PyMySQL-0.9.3-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2207</id>
		<title>An update for python-gunicorn is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1135" id="CVE-2024-1135" title="CVE-2024-1135" type="cve"></reference>
		</references>
		<description>CVE-2024-1135:Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn&#39;s handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="noarch" epoch="0" name="python3-gunicorn" release="2.fos23" version="20.1.0">
					<filename>python3-gunicorn-20.1.0-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/python3-gunicorn-20.1.0-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-gunicorn-help" release="2.fos23" version="20.1.0">
					<filename>python-gunicorn-help-20.1.0-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/python-gunicorn-help-20.1.0-2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2208</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45935" id="CVE-2023-45935" title="CVE-2023-45935" type="cve"></reference>
		</references>
		<description>CVE-2023-45935:Qt 6 through 6.6 was discovered to contain a NULL pointer dereference via the function QXcbConnection::initializeAllAtoms(). NOTE: this is disputed because it is not expected that an X application should continue to run when there is arbitrary anomalous behavior from the X server.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="1" name="qt" release="58.u8.fos23" version="4.8.7">
					<filename>qt-4.8.7-58.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/qt-4.8.7-58.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="qt-devel" release="58.u8.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-58.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/qt-devel-4.8.7-58.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt" release="58.u8.fos23" version="4.8.7">
					<filename>qt-4.8.7-58.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt-4.8.7-58.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt-devel" release="58.u8.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-58.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt-devel-4.8.7-58.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2209</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27280" id="CVE-2024-27280" title="CVE-2024-27280" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27281" id="CVE-2024-27281" title="CVE-2024-27281" type="cve"></reference>
		</references>
		<description>CVE-2024-27280:A buffer-overread issue was discovered in StringIO 3.0.1, as distributed in Ruby 3.0.x through 3.0.6 and 3.1.x through 3.1.4. The ungetbyte and ungetc methods on a StringIO can read past the end of a string, and a subsequent call to StringIO.gets may return the memory value. 3.0.3 is the main fixed version; however, for Ruby 3.0 users, a fixed version is stringio 3.0.1.1, and for Ruby 3.1 users, a fixed version is stringio 3.0.1.2.&#xA;CVE-2024-27281:An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0. When parsing .rdoc_options (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can be restored. (When loading the documentation cache, object injection and resultant remote code execution are also possible if there were a crafted cache.) The main fixed version is 6.6.3.1. For Ruby 3.0 users, a fixed version is rdoc 6.3.4.1. For Ruby 3.1 users, a fixed version is rdoc 6.4.1.1. For Ruby 3.2 users, a fixed version is rdoc 6.5.1.1.</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="0" name="ruby" release="134.u9.fos23" version="3.0.3">
					<filename>ruby-3.0.3-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/ruby-3.0.3-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="134.u9.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/ruby-devel-3.0.3-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="134.u9.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygems-3.2.32-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="134.u9.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygems-devel-3.2.32-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="134.u9.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-rake-13.0.3-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="134.u9.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-rbs-1.4.0-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="134.u9.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/ruby-irb-3.0.3-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="134.u9.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-rdoc-6.3.3-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="134.u9.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/ruby-help-3.0.3-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="134.u9.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/rubygem-bigdecimal-3.0.0-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="134.u9.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-did_you_mean-1.5.0-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="134.u9.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/rubygem-io-console-0.5.7-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="134.u9.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/rubygem-json-2.5.1-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="134.u9.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-minitest-5.14.2-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="134.u9.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/rubygem-openssl-2.2.1-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="134.u9.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-134.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/rubygem-psych-3.3.2-134.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="134.u9.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-test-unit-3.3.7-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="134.u9.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-rexml-3.2.5-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="134.u9.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-rss-0.2.9-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="134.u9.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-134.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-typeprof-0.15.2-134.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="134.u9.fos23" version="3.0.3">
					<filename>ruby-3.0.3-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/ruby-3.0.3-134.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="134.u9.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/ruby-devel-3.0.3-134.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="134.u9.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-bigdecimal-3.0.0-134.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="134.u9.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-io-console-0.5.7-134.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="134.u9.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-json-2.5.1-134.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="134.u9.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-openssl-2.2.1-134.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="134.u9.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-134.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/rubygem-psych-3.3.2-134.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2210</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-06-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4853" id="CVE-2024-4853" title="CVE-2024-4853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4854" id="CVE-2024-4854" title="CVE-2024-4854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4855" id="CVE-2024-4855" title="CVE-2024-4855" type="cve"></reference>
		</references>
		<description>CVE-2024-4853:Memory handling issue in editcap could cause denial of service via crafted capture file&#xA;CVE-2024-4854:MONGO and ZigBee TLV dissector infinite loops in Wireshark 4.2.0 to 4.2.4, 4.0.0 to 4.0.14, and 3.6.0 to 3.6.22 allow denial of service via packet injection or crafted capture file&#xA;CVE-2024-4855:Use after free issue in editcap could cause denial of service via crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="8.u11.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-8.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/wireshark-3.6.14-8.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="8.u11.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-8.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/wireshark-devel-3.6.14-8.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="8.u11.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-8.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/wireshark-help-3.6.14-8.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="8.u11.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-8.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/wireshark-3.6.14-8.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="8.u11.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-8.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/wireshark-devel-3.6.14-8.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="8.u11.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-8.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/wireshark-help-3.6.14-8.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2211</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-07-05"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6387" id="CVE-2024-6387" title="CVE-2024-6387" type="cve"></reference>
		</references>
		<description>CVE-2024-6387:A security regression (CVE-2006-5051) was discovered in OpenSSH&#39;s server (sshd). There is a race condition which can lead to sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.</description>
		<pkglist>
			<collection>
				<name>23.1.2.2</name>
				<package arch="x86_64" epoch="0" name="openssh" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-8.8p1-29.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/openssh-8.8p1-29.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-29.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/openssh-clients-8.8p1-29.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-29.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/openssh-server-8.8p1-29.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-29.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/openssh-keycat-8.8p1-29.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-29.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/openssh-askpass-8.8p1-29.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.29.u21.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.29.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/pam_ssh_agent_auth-0.10.4-4.29.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-help-8.8p1-29.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.2/openssh-help-8.8p1-29.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-8.8p1-29.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.2/openssh-8.8p1-29.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-29.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.2/openssh-clients-8.8p1-29.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-29.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.2/openssh-server-8.8p1-29.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-29.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.2/openssh-keycat-8.8p1-29.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="29.u21.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-29.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.2/openssh-askpass-8.8p1-29.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.29.u21.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.29.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.2/pam_ssh_agent_auth-0.10.4-4.29.u21.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2212</id>
		<title>An update for 389-ds-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2199" id="CVE-2024-2199" title="CVE-2024-2199" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3657" id="CVE-2024-3657" title="CVE-2024-3657" type="cve"></reference>
		</references>
		<description>CVE-2024-2199:A denial of service vulnerability was found in 389-ds-base ldap server. This issue may allow an authenticated user to cause a server crash while modifying `userPassword` using malformed input.&#xA;CVE-2024-3657:A flaw was found in 389-ds-base. A specially-crafted LDAP query can potentially cause a failure on the directory server, leading to a denial of service</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="389-ds-base" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/389-ds-base-1.4.3.36-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-legacy-tools" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/389-ds-base-legacy-tools-1.4.3.36-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-devel" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/389-ds-base-devel-1.4.3.36-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-snmp" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/389-ds-base-snmp-1.4.3.36-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-lib389" release="6.u3.fos23" version="1.4.3.36">
					<filename>python3-lib389-1.4.3.36-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-lib389-1.4.3.36-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-389-ds" release="6.u3.fos23" version="1.4.3.36">
					<filename>cockpit-389-ds-1.4.3.36-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cockpit-389-ds-1.4.3.36-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-help" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/389-ds-base-help-1.4.3.36-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/389-ds-base-1.4.3.36-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-legacy-tools" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/389-ds-base-legacy-tools-1.4.3.36-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-devel" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/389-ds-base-devel-1.4.3.36-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-snmp" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/389-ds-base-snmp-1.4.3.36-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-help" release="6.u3.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/389-ds-base-help-1.4.3.36-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2213</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40724" id="CVE-2024-40724" title="CVE-2024-40724" type="cve"></reference>
		</references>
		<description>CVE-2024-40724:Heap-based buffer overflow vulnerability in Assimp versions prior to 5.4.2 allows a local attacker to execute arbitrary code by inputting a specially crafted file into the product.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="assimp" release="2.u1.fos23" version="5.2.4">
					<filename>assimp-5.2.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/assimp-5.2.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="2.u1.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/assimp-devel-5.2.4-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-assimp" release="2.u1.fos23" version="5.2.4">
					<filename>python3-assimp-5.2.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-assimp-5.2.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="assimp-help" release="2.u1.fos23" version="5.2.4">
					<filename>assimp-help-5.2.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/assimp-help-5.2.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp" release="2.u1.fos23" version="5.2.4">
					<filename>assimp-5.2.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/assimp-5.2.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="2.u1.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/assimp-devel-5.2.4-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2214</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1975" id="CVE-2024-1975" title="CVE-2024-1975" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4076" id="CVE-2024-4076" title="CVE-2024-4076" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1737" id="CVE-2024-1737" title="CVE-2024-1737" type="cve"></reference>
		</references>
		<description>CVE-2024-1975:If a server hosts a zone containing a &#34;KEY&#34; Resource Record, or a resolver DNSSEC-validates a &#34;KEY&#34; Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.&#xA;This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.&#xA;CVE-2024-4076:Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure.&#xA;This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.&#xA;CVE-2024-1737:Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="32" name="bind" release="23.u8.fos23" version="9.16.23">
					<filename>bind-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-pkcs11-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-pkcs11-utils-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-pkcs11-libs-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-pkcs11-devel-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="23.u8.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-libs-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="23.u8.fos23" version="9.16.23">
					<filename>bind-license-9.16.23-23.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-license-9.16.23-23.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="23.u8.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-utils-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="23.u8.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-dnssec-utils-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="23.u8.fos23" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-23.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-dnssec-doc-9.16.23-23.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="23.u8.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-devel-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="23.u8.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-23.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bind-chroot-9.16.23-23.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="23.u8.fos23" version="9.16.23">
					<filename>python3-bind-9.16.23-23.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-bind-9.16.23-23.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="23.u8.fos23" version="9.16.23">
					<filename>bind-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-pkcs11-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-pkcs11-utils-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-pkcs11-libs-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="23.u8.fos23" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-pkcs11-devel-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="23.u8.fos23" version="9.16.23">
					<filename>bind-libs-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-libs-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="23.u8.fos23" version="9.16.23">
					<filename>bind-utils-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-utils-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="23.u8.fos23" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-dnssec-utils-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="23.u8.fos23" version="9.16.23">
					<filename>bind-devel-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-devel-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="23.u8.fos23" version="9.16.23">
					<filename>bind-chroot-9.16.23-23.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bind-chroot-9.16.23-23.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2215</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42363" id="CVE-2023-42363" title="CVE-2023-42363" type="cve"></reference>
		</references>
		<description>CVE-2023-42363:A use-after-free vulnerability was discovered in xasprintf function in xfuncs_printf.c:344 in BusyBox v.1.36.1.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="busybox" release="22.u2.fos23" version="1.34.1">
					<filename>busybox-1.34.1-22.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/busybox-1.34.1-22.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-petitboot" release="22.u2.fos23" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-22.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/busybox-petitboot-1.34.1-22.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-help" release="22.u2.fos23" version="1.34.1">
					<filename>busybox-help-1.34.1-22.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/busybox-help-1.34.1-22.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox" release="22.u2.fos23" version="1.34.1">
					<filename>busybox-1.34.1-22.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/busybox-1.34.1-22.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-petitboot" release="22.u2.fos23" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-22.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/busybox-petitboot-1.34.1-22.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-help" release="22.u2.fos23" version="1.34.1">
					<filename>busybox-help-1.34.1-22.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/busybox-help-1.34.1-22.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2216</id>
		<title>An update for cockpit is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6126" id="CVE-2024-6126" title="CVE-2024-6126" type="cve"></reference>
		</references>
		<description>CVE-2024-6126:A flaw was found in the cockpit package. This flaw allows an authenticated user to kill any process when enabling the pam_env&#39;s user_readenv option, which leads to a denial of service (DoS) attack.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="cockpit" release="16.u4.fos23" version="178">
					<filename>cockpit-178-16.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cockpit-178-16.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cockpit-devel" release="16.u4.fos23" version="178">
					<filename>cockpit-devel-178-16.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cockpit-devel-178-16.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-cockpit-machines" release="16.u4.fos23" version="178">
					<filename>cockpit-cockpit-machines-178-16.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cockpit-cockpit-machines-178-16.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-cockpit-machines-ovirt" release="16.u4.fos23" version="178">
					<filename>cockpit-cockpit-machines-ovirt-178-16.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cockpit-cockpit-machines-ovirt-178-16.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-help" release="16.u4.fos23" version="178">
					<filename>cockpit-help-178-16.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cockpit-help-178-16.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cockpit" release="16.u4.fos23" version="178">
					<filename>cockpit-178-16.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cockpit-178-16.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cockpit-devel" release="16.u4.fos23" version="178">
					<filename>cockpit-devel-178-16.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cockpit-devel-178-16.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2217</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35235" id="CVE-2024-35235" title="CVE-2024-35235" type="cve"></reference>
		</references>
		<description>CVE-2024-35235:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="cups" release="11.u5.fos23" version="2.4.0">
					<filename>cups-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="11.u5.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-client-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="11.u5.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-devel-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="11.u5.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-libs-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="11.u5.fos23" version="2.4.0">
					<filename>cups-filesystem-2.4.0-11.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-filesystem-2.4.0-11.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="11.u5.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-lpd-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="11.u5.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-ipptool-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="11.u5.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-11.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-printerapp-2.4.0-11.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="11.u5.fos23" version="2.4.0">
					<filename>cups-help-2.4.0-11.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cups-help-2.4.0-11.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="11.u5.fos23" version="2.4.0">
					<filename>cups-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="11.u5.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-client-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="11.u5.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-devel-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="11.u5.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-libs-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="11.u5.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-lpd-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="11.u5.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-ipptool-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="11.u5.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-11.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cups-printerapp-2.4.0-11.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2218</id>
		<title>An update for dnsjava is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25638" id="CVE-2024-25638" title="CVE-2024-25638" type="cve"></reference>
		</references>
		<description>CVE-2024-25638:dnsjava is an implementation of DNS in Java. Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. This vulnerability is fixed in 3.6.0.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="noarch" epoch="0" name="dnsjava" release="1.fos23" version="2.1.9">
					<filename>dnsjava-2.1.9-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/dnsjava-2.1.9-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="dnsjava-javadoc" release="1.fos23" version="2.1.9">
					<filename>dnsjava-javadoc-2.1.9-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/dnsjava-javadoc-2.1.9-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2219</id>
		<title>An update for dnsmasq is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49441" id="CVE-2023-49441" title="CVE-2023-49441" type="cve"></reference>
		</references>
		<description>CVE-2023-49441:dnsmasq 2.9 is vulnerable to Integer Overflow via forward_query.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="dnsmasq" release="8.u4.fos23" version="2.86">
					<filename>dnsmasq-2.86-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/dnsmasq-2.86-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="dnsmasq-help" release="8.u4.fos23" version="2.86">
					<filename>dnsmasq-help-2.86-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/dnsmasq-help-2.86-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dnsmasq" release="8.u4.fos23" version="2.86">
					<filename>dnsmasq-2.86-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/dnsmasq-2.86-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dnsmasq-help" release="8.u4.fos23" version="2.86">
					<filename>dnsmasq-help-2.86-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/dnsmasq-help-2.86-8.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2220</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1298" id="CVE-2024-1298" title="CVE-2024-1298" type="cve"></reference>
		</references>
		<description>CVE-2024-1298:EDK2 contains a vulnerability when S3 sleep is activated where an Attacker may cause a Division-By-Zero due to a UNIT32 overflow via local access. A successful exploit of this vulnerability may lead to a loss of Availability.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="18.u7.fos23" version="202011">
					<filename>edk2-devel-202011-18.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/edk2-devel-202011-18.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="18.u7.fos23" version="202011">
					<filename>python3-edk2-devel-202011-18.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-edk2-devel-202011-18.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="18.u7.fos23" version="202011">
					<filename>edk2-help-202011-18.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/edk2-help-202011-18.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="18.u7.fos23" version="202011">
					<filename>edk2-ovmf-202011-18.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/edk2-ovmf-202011-18.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="18.u7.fos23" version="202011">
					<filename>edk2-devel-202011-18.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/edk2-devel-202011-18.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="18.u7.fos23" version="202011">
					<filename>edk2-aarch64-202011-18.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/edk2-aarch64-202011-18.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2221</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39331" id="CVE-2024-39331" title="CVE-2024-39331" type="cve"></reference>
		</references>
		<description>CVE-2024-39331:In Emacs before 29.4, org-link-expand-abbrev in lisp/ol.el expands a %(...) link abbrev even when it specifies an unsafe function, such as shell-command-to-string. This affects Org Mode before 9.7.5.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="emacs" release="14.u6.fos23" version="27.2">
					<filename>emacs-27.2-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-27.2-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="14.u6.fos23" version="27.2">
					<filename>emacs-devel-27.2-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-devel-27.2-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="14.u6.fos23" version="27.2">
					<filename>emacs-lucid-27.2-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-lucid-27.2-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="14.u6.fos23" version="27.2">
					<filename>emacs-nox-27.2-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-nox-27.2-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="14.u6.fos23" version="27.2">
					<filename>emacs-common-27.2-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-common-27.2-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="14.u6.fos23" version="27.2">
					<filename>emacs-terminal-27.2-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-terminal-27.2-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="14.u6.fos23" version="27.2">
					<filename>emacs-filesystem-27.2-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-filesystem-27.2-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="14.u6.fos23" version="27.2">
					<filename>emacs-help-27.2-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/emacs-help-27.2-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="14.u6.fos23" version="27.2">
					<filename>emacs-27.2-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/emacs-27.2-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="14.u6.fos23" version="27.2">
					<filename>emacs-devel-27.2-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/emacs-devel-27.2-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="14.u6.fos23" version="27.2">
					<filename>emacs-lucid-27.2-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/emacs-lucid-27.2-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="14.u6.fos23" version="27.2">
					<filename>emacs-nox-27.2-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/emacs-nox-27.2-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="14.u6.fos23" version="27.2">
					<filename>emacs-common-27.2-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/emacs-common-27.2-14.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2222</id>
		<title>An update for exiv2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39695" id="CVE-2024-39695" title="CVE-2024-39695" type="cve"></reference>
		</references>
		<description>CVE-2024-39695:Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. An out-of-bounds read was found in Exiv2 version v0.28.2. The vulnerability is in the parser for the ASF video format, which was a new feature in v0.28.0. The out-of-bounds read is triggered when Exiv2 is used to read the metadata of a crafted video file. The bug is fixed in version v0.28.3.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="exiv2" release="3.fos23" version="0.27.5">
					<filename>exiv2-0.27.5-3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/exiv2-0.27.5-3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="exiv2-devel" release="3.fos23" version="0.27.5">
					<filename>exiv2-devel-0.27.5-3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/exiv2-devel-0.27.5-3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="exiv2-help" release="3.fos23" version="0.27.5">
					<filename>exiv2-help-0.27.5-3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/exiv2-help-0.27.5-3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="exiv2" release="3.fos23" version="0.27.5">
					<filename>exiv2-0.27.5-3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/exiv2-0.27.5-3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="exiv2-devel" release="3.fos23" version="0.27.5">
					<filename>exiv2-devel-0.27.5-3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/exiv2-devel-0.27.5-3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2223</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31578" id="CVE-2024-31578" title="CVE-2024-31578" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51794" id="CVE-2023-51794" title="CVE-2023-51794" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51798" id="CVE-2023-51798" title="CVE-2023-51798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3341" id="CVE-2022-3341" title="CVE-2022-3341" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3109" id="CVE-2022-3109" title="CVE-2022-3109" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51793" id="CVE-2023-51793" title="CVE-2023-51793" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50010" id="CVE-2023-50010" title="CVE-2023-50010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38171" id="CVE-2021-38171" title="CVE-2021-38171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28429" id="CVE-2021-28429" title="CVE-2021-28429" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32230" id="CVE-2024-32230" title="CVE-2024-32230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1475" id="CVE-2022-1475" title="CVE-2022-1475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48434" id="CVE-2022-48434" title="CVE-2022-48434" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49528" id="CVE-2023-49528" title="CVE-2023-49528" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51791" id="CVE-2023-51791" title="CVE-2023-51791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51797" id="CVE-2023-51797" title="CVE-2023-51797" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32229" id="CVE-2024-32229" title="CVE-2024-32229" type="cve"></reference>
		</references>
		<description>CVE-2024-31578:FFmpeg version n6.1.1 was discovered to contain a heap use-after-free via the av_hwframe_ctx_init function.&#xA;CVE-2023-51794:Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavfilter/af_stereowiden.c:120:69.&#xA;CVE-2023-51798:Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via a floating point exception (FPE) error at libavfilter/vf_minterpolate.c:1078:60 in interpolate.&#xA;CVE-2022-3341:A null pointer dereference issue was discovered in &#39;FFmpeg&#39; in decode_main_header() function of libavformat/nutdec.c file. The flaw occurs because the function lacks check of the return value of avformat_new_stream() and triggers the null pointer dereference error, causing an application to crash.&#xA;CVE-2022-3109:An issue was discovered in the FFmpeg package, where vp3_decode_frame in libavcodec/vp3.c lacks check of the return value of av_malloc() and will cause a null pointer dereference, impacting availability.&#xA;CVE-2023-51793:Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavutil/imgutils.c:353:9 in image_copy_plane.&#xA;CVE-2023-50010:Buffer Overflow vulnerability in Ffmpeg v.n6.1-3-g466799d4f5 allows a local attacker to execute arbitrary code via the set_encoder_id function in /fftools/ffmpeg_enc.c component.&#xA;CVE-2021-38171:adts_decode_extradata in libavformat/adtsenc.c in FFmpeg 4.4 does not check the init_get_bits return value, which is a necessary step because the second argument to init_get_bits can be crafted.&#xA;CVE-2021-28429:Integer overflow vulnerability in av_timecode_make_string in libavutil/timecode.c in FFmpeg version 4.3.2, allows local attackers to cause a denial of service (DoS) via crafted .mov file.&#xA;CVE-2024-32230:FFmpeg 7.0 is vulnerable to Buffer Overflow. There is a negative-size-param bug at libavcodec/mpegvideo_enc.c:1216:21 in load_input_picture in FFmpeg7.0&#xA;CVE-2022-1475:An integer overflow vulnerability was found in FFmpeg versions before 4.4.2 and before 5.0.1 in g729_parse() in llibavcodec/g729_parser.c when processing a specially crafted file.&#xA;CVE-2022-48434:libavcodec/pthread_frame.c in FFmpeg before 5.1.2, as used in VLC and other products, leaves stale hwaccel state in worker threads, which allows attackers to trigger a use-after-free and execute arbitrary code in some circumstances (e.g., hardware re-initialization upon a mid-video SPS change when Direct3D11 is used).&#xA;CVE-2023-49528:Buffer Overflow vulnerability in FFmpeg version n6.1-3-g466799d4f5, allows a local attacker to execute arbitrary code and cause a denial of service (DoS) via the af_dialoguenhance.c:261:5 in the de_stereo component.&#xA;CVE-2023-51791:Buffer Overflow vulenrability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavcodec/jpegxl_parser.c in gen_alias_map.&#xA;CVE-2023-51797:Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavfilter/avf_showwaves.c:722:24 in showwaves_filter_frame&#xA;CVE-2024-32229:FFmpeg 7.0 contains a heap-buffer-overflow at libavfilter/vf_tiltandshift.c:189:5 in copy_column.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="17.u1.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-17.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ffmpeg-4.2.4-17.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="17.u1.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-17.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ffmpeg-libs-4.2.4-17.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="17.u1.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-17.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libavdevice-4.2.4-17.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="17.u1.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-17.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ffmpeg-devel-4.2.4-17.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="17.u1.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-17.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ffmpeg-4.2.4-17.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="17.u1.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-17.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ffmpeg-libs-4.2.4-17.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="17.u1.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-17.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libavdevice-4.2.4-17.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="17.u1.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-17.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ffmpeg-devel-4.2.4-17.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2224</id>
		<title>An update for freeradius is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3596" id="CVE-2024-3596" title="CVE-2024-3596" type="cve"></reference>
		</references>
		<description>CVE-2024-3596:RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="freeradius" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-utils" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-utils-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-utils-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-devel" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-devel-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-devel-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-ldap" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-ldap-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-ldap-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-krb5" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-krb5-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-krb5-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-perl" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-perl-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-perl-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-freeradius" release="3.u2.fos23" version="3.0.25">
					<filename>python3-freeradius-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-freeradius-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-mysql" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-mysql-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-mysql-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-postgresql" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-postgresql-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-postgresql-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-sqlite" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-sqlite-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-sqlite-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freeradius-help" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-help-3.0.25-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/freeradius-help-3.0.25-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-utils" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-utils-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-utils-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-devel" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-devel-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-devel-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-ldap" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-ldap-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-ldap-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-krb5" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-krb5-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-krb5-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-perl" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-perl-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-perl-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-freeradius" release="3.u2.fos23" version="3.0.25">
					<filename>python3-freeradius-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/python3-freeradius-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-mysql" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-mysql-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-mysql-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-postgresql" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-postgresql-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-postgresql-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-sqlite" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-sqlite-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-sqlite-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freeradius-help" release="3.u2.fos23" version="3.0.25">
					<filename>freeradius-help-3.0.25-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/freeradius-help-3.0.25-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2225</id>
		<title>An update for gdk-pixbuf2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48622" id="CVE-2022-48622" title="CVE-2022-48622" type="cve"></reference>
		</references>
		<description>CVE-2022-48622:In GNOME GdkPixbuf (aka gdk-pixbuf) through 2.42.10, the ANI (Windows animated cursor) decoder encounters heap memory corruption (in ani_load_chunk in io-ani.c) when parsing chunks in a crafted .ani file. A crafted file could allow an attacker to overwrite heap metadata, leading to a denial of service or code execution attack. This occurs in gdk_pixbuf_set_option() in gdk-pixbuf.c.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gdk-pixbuf2-2.42.6-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-modules" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gdk-pixbuf2-modules-2.42.6-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-devel" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gdk-pixbuf2-devel-2.42.6-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-tests" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gdk-pixbuf2-tests-2.42.6-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdk-pixbuf2-help" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-help-2.42.6-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gdk-pixbuf2-help-2.42.6-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gdk-pixbuf2-2.42.6-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-modules" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gdk-pixbuf2-modules-2.42.6-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-devel" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gdk-pixbuf2-devel-2.42.6-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-tests" release="7.u2.fos23" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gdk-pixbuf2-tests-2.42.6-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2226</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29510" id="CVE-2024-29510" title="CVE-2024-29510" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33869" id="CVE-2024-33869" title="CVE-2024-33869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33870" id="CVE-2024-33870" title="CVE-2024-33870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29506" id="CVE-2024-29506" title="CVE-2024-29506" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29507" id="CVE-2024-29507" title="CVE-2024-29507" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29508" id="CVE-2024-29508" title="CVE-2024-29508" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29509" id="CVE-2024-29509" title="CVE-2024-29509" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29511" id="CVE-2024-29511" title="CVE-2024-29511" type="cve"></reference>
		</references>
		<description>CVE-2024-29510:Artifex Ghostscript before 10.03.1 allows memory corruption, and SAFER sandbox bypass, via format string injection with a uniprint device.&#xA;CVE-2024-33869:An issue was discovered in Artifex Ghostscript before 10.03.1. Path traversal and command execution can occur (via a crafted PostScript document) because of path reduction in base/gpmisc.c. For example, restrictions on use of %pipe% can be bypassed via the aa/../%pipe%command# output filename.&#xA;CVE-2024-33870:An issue was discovered in Artifex Ghostscript before 10.03.1. There is path traversal (via a crafted PostScript document) to arbitrary files if the current directory is in the permitted paths. For example, there can be a transformation of ../../foo to ./../../foo and this will grant access if ./ is permitted.&#xA;CVE-2024-29506:Artifex Ghostscript before 10.03.0 has a stack-based buffer overflow in the pdfi_apply_filter() function via a long PDF filter name.&#xA;CVE-2024-29507:Artifex Ghostscript before 10.03.0 sometimes has a stack-based buffer overflow via the CIDFSubstPath and CIDFSubstFont parameters.&#xA;CVE-2024-29508:Artifex Ghostscript before 10.03.0 has a heap-based pointer disclosure (observable in a constructed BaseFont name) in the function pdf_base_font_alloc.&#xA;CVE-2024-29509:Artifex Ghostscript before 10.03.0 has a heap-based overflow when PDFPassword (e.g., for runpdf) has a \000 byte in the middle.&#xA;CVE-2024-29511:Artifex Ghostscript before 10.03.1, when Tesseract is used for OCR, has a directory traversal issue that allows arbitrary file reading (and writing of error messages to arbitrary files) via OCRLanguage. For example, exploitation can use debug_file /tmp/out and user_patterns_file /etc/passwd.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ghostscript-9.55.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ghostscript-devel-9.55.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ghostscript-help-9.55.0-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ghostscript-tools-dvipdf-9.55.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ghostscript-9.55.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ghostscript-devel-9.55.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="10.u7.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ghostscript-tools-dvipdf-9.55.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2227</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34397" id="CVE-2024-34397" title="CVE-2024-34397" type="cve"></reference>
		</references>
		<description>CVE-2024-34397:An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="glib2" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-2.72.2-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/glib2-2.72.2-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-devel-2.72.2-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/glib2-devel-2.72.2-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-static" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-static-2.72.2-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/glib2-static-2.72.2-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-tests-2.72.2-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/glib2-tests-2.72.2-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-help-2.72.2-15.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/glib2-help-2.72.2-15.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-2.72.2-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/glib2-2.72.2-15.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-devel-2.72.2-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/glib2-devel-2.72.2-15.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-static" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-static-2.72.2-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/glib2-static-2.72.2-15.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="15.u10.fos23" version="2.72.2">
					<filename>glib2-tests-2.72.2-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/glib2-tests-2.72.2-15.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2228</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24789" id="CVE-2024-24789" title="CVE-2024-24789" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24790" id="CVE-2024-24790" title="CVE-2024-24790" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45283" id="CVE-2023-45283" title="CVE-2023-45283" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-27664" id="CVE-2022-27664" title="CVE-2022-27664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29804" id="CVE-2022-29804" title="CVE-2022-29804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32189" id="CVE-2022-32189" title="CVE-2022-32189" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-30630" id="CVE-2022-30630" title="CVE-2022-30630" type="cve"></reference>
		</references>
		<description>CVE-2024-24789:The archive/zip package&#39;s handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors.&#xA;CVE-2024-24790:The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.&#xA;CVE-2023-45283:The filepath package does not recognize paths with a \??\ prefix as special. On Windows, a path beginning with \??\ is a Root Local Device path equivalent to a path beginning with \\?\. Paths with a \??\ prefix may be used to access arbitrary locations on the system. For example, the path \??\c:\x is equivalent to the more common path c:\x. Before fix, Clean could convert a rooted path such as \a\..\??\b into the root local device path \??\b. Clean will now convert this to .\??\b. Similarly, Join(\, ??, b) could convert a seemingly innocent sequence of path elements into the root local device path \??\b. Join will now convert this to \.\??\b. In addition, with fix, IsAbs now correctly reports paths beginning with \??\ as absolute, and VolumeName correctly reports the \??\ prefix as a volume name. UPDATE: Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the volume name in Windows paths starting with \?, resulting in filepath.Clean(\?\c:) returning \?\c: rather than \?\c:\ (among other effects). The previous behavior has been restored.&#xA;CVE-2022-27664:In net/http in Go before 1.18.6 and 1.19.x before 1.19.1, attackers can cause a denial of service because an HTTP/2 connection can hang during closing if shutdown were preempted by a fatal error.&#xA;CVE-2022-29804:Incorrect conversion of certain invalid paths to valid, absolute paths in Clean in path/filepath before Go 1.17.11 and Go 1.18.3 on Windows allows potential directory traversal attack.&#xA;CVE-2022-32189:A too-short encoded message can cause a panic in Float.GobDecode and Rat GobDecode in math/big in Go before 1.17.13 and 1.18.5, potentially allowing a denial of service.&#xA;CVE-2022-30630:Uncontrolled recursion in Glob in io/fs before Go 1.17.12 and Go 1.18.4 allows an attacker to cause a panic due to stack exhaustion via a path which contains a large number of path separators.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u11.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/golang-1.20.5-3.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u11.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/golang-help-1.20.5-3.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u11.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/golang-devel-1.20.5-3.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u11.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/golang-1.20.5-3.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2229</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46848" id="CVE-2021-46848" title="CVE-2021-46848" type="cve"></reference>
		</references>
		<description>CVE-2021-46848:GNU Libtasn1 before 4.19.0 has an ETYPE_OK off-by-one array size check that affects asn1_encode_simple_der.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="1" name="grub2-common" release="44.u14.fos23" version="2.06">
					<filename>grub2-common-2.06-44.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/grub2-common-2.06-44.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-2.06-44.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/grub2-tools-2.06-44.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-minimal" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-minimal-2.06-44.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/grub2-tools-minimal-2.06-44.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-extra" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-extra-2.06-44.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/grub2-tools-extra-2.06-44.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-efi" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-efi-2.06-44.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/grub2-tools-efi-2.06-44.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-help" release="44.u14.fos23" version="2.06">
					<filename>grub2-help-2.06-44.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/grub2-help-2.06-44.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-2.06-44.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/grub2-tools-2.06-44.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-minimal" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-minimal-2.06-44.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/grub2-tools-minimal-2.06-44.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-extra" release="44.u14.fos23" version="2.06">
					<filename>grub2-tools-extra-2.06-44.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/grub2-tools-extra-2.06-44.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2230</id>
		<title>An update for gtk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"></reference>
		</references>
		<description>CVE-2024-6655:A flaw was found in the GTK library. Under certain conditions, it is possible for a library to be injected into a GTK application from the current working directory.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="gtk-doc" release="5.fos23" version="1.33.2">
					<filename>gtk-doc-1.33.2-5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/gtk-doc-1.33.2-5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk-doc" release="5.fos23" version="1.33.2">
					<filename>gtk-doc-1.33.2-5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/gtk-doc-1.33.2-5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2231</id>
		<title>An update for gtk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"></reference>
		</references>
		<description>CVE-2024-6655:A flaw was found in the GTK library. Under certain conditions, it is possible for a library to be injected into a GTK application from the current working directory.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="gtk2" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-2.24.33-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk2-2.24.33-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk2-immodule-xim" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-immodule-xim-2.24.33-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk2-immodule-xim-2.24.33-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk2-devel" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-devel-2.24.33-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk2-devel-2.24.33-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk2-help" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-help-2.24.33-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk2-help-2.24.33-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk2" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-2.24.33-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk2-2.24.33-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk2-immodule-xim" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-immodule-xim-2.24.33-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk2-immodule-xim-2.24.33-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk2-devel" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-devel-2.24.33-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk2-devel-2.24.33-9.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk2-help" release="9.u1.fos23" version="2.24.33">
					<filename>gtk2-help-2.24.33-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk2-help-2.24.33-9.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2232</id>
		<title>An update for gtk3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"></reference>
		</references>
		<description>CVE-2024-6655:A flaw was found in the GTK library. Under certain conditions, it is possible for a library to be injected into a GTK application from the current working directory.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="gtk3" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-3.24.30-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk3-3.24.30-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk3-immodule-xim" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-immodule-xim-3.24.30-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk3-immodule-xim-3.24.30-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk-update-icon-cache" release="11.u4.fos23" version="3.24.30">
					<filename>gtk-update-icon-cache-3.24.30-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk-update-icon-cache-3.24.30-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk3-devel" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-devel-3.24.30-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk3-devel-3.24.30-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gtk3-help" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-help-3.24.30-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/gtk3-help-3.24.30-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk3" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-3.24.30-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk3-3.24.30-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk3-immodule-xim" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-immodule-xim-3.24.30-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk3-immodule-xim-3.24.30-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk-update-icon-cache" release="11.u4.fos23" version="3.24.30">
					<filename>gtk-update-icon-cache-3.24.30-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk-update-icon-cache-3.24.30-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk3-devel" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-devel-3.24.30-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk3-devel-3.24.30-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gtk3-help" release="11.u4.fos23" version="3.24.30">
					<filename>gtk3-help-3.24.30-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/gtk3-help-3.24.30-11.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2233</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38473" id="CVE-2024-38473" title="CVE-2024-38473" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38474" id="CVE-2024-38474" title="CVE-2024-38474" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38475" id="CVE-2024-38475" title="CVE-2024-38475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38476" id="CVE-2024-38476" title="CVE-2024-38476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38477" id="CVE-2024-38477" title="CVE-2024-38477" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39884" id="CVE-2024-39884" title="CVE-2024-39884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39573" id="CVE-2024-39573" title="CVE-2024-39573" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38472" id="CVE-2024-38472" title="CVE-2024-38472" type="cve"></reference>
		</references>
		<description>CVE-2024-38473:Encoding problem in mod_proxy in Apache HTTP Server 2.4.59 and earlier allows request URLs with incorrect encoding to be sent to backend services, potentially bypassing authentication via crafted requests.&#xA;Users are recommended to upgrade to version 2.4.60, which fixes this issue.&#xA;CVE-2024-38474:Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts in&#xA;directories permitted by the configuration but not directly reachable by any URL or source disclosure of scripts meant to only to be executed as CGI.&#xA;Users are recommended to upgrade to version 2.4.60, which fixes this issue.&#xA;Some RewriteRules that capture and substitute unsafely will now fail unless rewrite flag &#34;UnsafeAllow3F&#34; is specified.&#xA;CVE-2024-38475:Improper escaping of output in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to map URLs to filesystem locations that are permitted to be served by the server but are not intentionally/directly reachable by any URL, resulting in code execution or source code disclosure. &#xA;Substitutions in server context that use a backreferences or variables as the first segment of the substitution are affected.  Some unsafe RewiteRules will be broken by this change and the rewrite flag &#34;UnsafePrefixStat&#34; can be used to opt back in once ensuring the substitution is appropriately constrained.&#xA;CVE-2024-38476:Vulnerability in core of Apache HTTP Server 2.4.59 and earlier are vulnerably to information disclosure, SSRF or local script execution via backend applications whose response headers are malicious or exploitable.&#xA;Users are recommended to upgrade to version 2.4.60, which fixes this issue.&#xA;CVE-2024-38477:null pointer dereference in mod_proxy in Apache HTTP Server 2.4.59 and earlier allows an attacker to crash the server via a malicious request.&#xA;Users are recommended to upgrade to version 2.4.60, which fixes this issue.&#xA;CVE-2024-39884:A regression in the core of Apache HTTP Server 2.4.60 ignores some use of the legacy content-type based configuration of handlers.   &#34;AddType&#34; and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted.&#xA;Users are recommended to upgrade to version 2.4.61, which fixes this issue.&#xA;CVE-2024-39573:Potential SSRF in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to cause unsafe RewriteRules to unexpectedly setup URL&#39;s to be handled by mod_proxy.&#xA;Users are recommended to upgrade to version 2.4.60, which fixes this issue.&#xA;CVE-2024-38472:SSRF in Apache HTTP Server on Windows allows to potentially leak NTML hashes to a malicious server via SSRF and malicious requests or content &#xA;Users are recommended to upgrade to version 2.4.60 which fixes this issue.  Note: Existing configurations that access UNC paths will have to configure new directive &#34;UNCList&#34; to allow access during request processing.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="httpd" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/httpd-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/httpd-devel-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-22.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/httpd-help-2.4.51-22.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-22.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/httpd-filesystem-2.4.51-22.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/httpd-tools-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="22.u13.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/mod_ssl-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="22.u13.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/mod_md-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="22.u13.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/mod_proxy_html-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="22.u13.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/mod_ldap-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="22.u13.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-22.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/mod_session-2.4.51-22.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/httpd-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/httpd-devel-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="22.u13.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/httpd-tools-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="22.u13.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/mod_ssl-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="22.u13.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/mod_md-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="22.u13.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/mod_proxy_html-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="22.u13.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/mod_ldap-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="22.u13.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-22.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/mod_session-2.4.51-22.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2234</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"></reference>
		</references>
		<description>CVE-2024-21011:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22;   Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21068:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2 and  22; Oracle GraalVM Enterprise Edition: 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21094:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21085:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-headless-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-headless-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-headless-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-devel-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-devel-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-demo-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-demo-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-demo-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-src-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-src-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-src-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.412.b08-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-javadoc-1.8.0.412.b08-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.412.b08-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-javadoc-zip-1.8.0.412.b08-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-accessibility-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-devel-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-headless-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-headless-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-headless-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-devel-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-devel-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-demo-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-demo-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-demo-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-src-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-src-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-src-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-accessibility-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-devel-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="6.u2.fos23" version="1.8.0.412.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.412.b08-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2235</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"></reference>
		</references>
		<description>CVE-2024-21011:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22;   Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21068:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2 and  22; Oracle GraalVM Enterprise Edition: 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21094:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21085:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-headless-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-headless-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-headless-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-headless-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-devel-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-devel-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-devel-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-devel-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-jmods-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-jmods-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-jmods-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-demo-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-demo-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-demo-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-demo-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-src-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-src-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-src-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-src-slowdebug-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-javadoc-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-javadoc-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-javadoc-zip-11.0.23.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-11-openjdk-javadoc-zip-11.0.23.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-headless-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-headless-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-headless-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-headless-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-devel-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-devel-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-devel-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-devel-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-jmods-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-jmods-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-jmods-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-demo-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-demo-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-demo-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-demo-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-src-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-src-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-src-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-src-slowdebug-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-javadoc-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-javadoc-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="2.fos23" version="11.0.23.9">
					<filename>java-11-openjdk-javadoc-zip-11.0.23.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-11-openjdk-javadoc-zip-11.0.23.9-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2236</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20932" id="CVE-2024-20932" title="CVE-2024-20932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21012" id="CVE-2024-21012" title="CVE-2024-21012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"></reference>
		</references>
		<description>CVE-2024-20932:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 17.0.9; Oracle GraalVM for JDK: 17.0.9; Oracle GraalVM Enterprise Edition: 21.3.8 and  22.3.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N).&#xA;CVE-2024-21012:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21011:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22;   Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21068:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2 and  22; Oracle GraalVM Enterprise Edition: 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21094:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-headless-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-headless-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-headless-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-headless-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-devel-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-devel-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-devel-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-devel-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-jmods-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-jmods-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-jmods-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-demo-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-demo-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-demo-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-demo-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-src-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-src-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-src-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-src-slowdebug-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-javadoc-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-javadoc-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-javadoc-zip-17.0.11.9-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/java-17-openjdk-javadoc-zip-17.0.11.9-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-headless-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-headless-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-headless-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-headless-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-devel-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-devel-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-devel-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-devel-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-jmods-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-jmods-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-jmods-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-demo-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-demo-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-demo-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-demo-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-src-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-src-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-src-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-src-slowdebug-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-javadoc-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-javadoc-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="1.u3.fos23" version="17.0.11.9">
					<filename>java-17-openjdk-javadoc-zip-17.0.11.9-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/java-17-openjdk-javadoc-zip-17.0.11.9-1.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2237</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26852" id="CVE-2024-26852" title="CVE-2024-26852" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52655" id="CVE-2023-52655" title="CVE-2023-52655" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35847" id="CVE-2024-35847" title="CVE-2024-35847" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35905" id="CVE-2024-35905" title="CVE-2024-35905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35886" id="CVE-2024-35886" title="CVE-2024-35886" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35817" id="CVE-2024-35817" title="CVE-2024-35817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35976" id="CVE-2024-35976" title="CVE-2024-35976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52730" id="CVE-2023-52730" title="CVE-2023-52730" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52805" id="CVE-2023-52805" title="CVE-2023-52805" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52750" id="CVE-2023-52750" title="CVE-2023-52750" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52804" id="CVE-2023-52804" title="CVE-2023-52804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52669" id="CVE-2023-52669" title="CVE-2023-52669" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35995" id="CVE-2024-35995" title="CVE-2024-35995" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35956" id="CVE-2024-35956" title="CVE-2024-35956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52878" id="CVE-2023-52878" title="CVE-2023-52878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52818" id="CVE-2023-52818" title="CVE-2023-52818" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52736" id="CVE-2023-52736" title="CVE-2023-52736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35822" id="CVE-2024-35822" title="CVE-2024-35822" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47265" id="CVE-2021-47265" title="CVE-2021-47265" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52826" id="CVE-2023-52826" title="CVE-2023-52826" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52735" id="CVE-2023-52735" title="CVE-2023-52735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52819" id="CVE-2023-52819" title="CVE-2023-52819" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52703" id="CVE-2023-52703" title="CVE-2023-52703" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52699" id="CVE-2023-52699" title="CVE-2023-52699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52832" id="CVE-2023-52832" title="CVE-2023-52832" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52759" id="CVE-2023-52759" title="CVE-2023-52759" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52705" id="CVE-2023-52705" title="CVE-2023-52705" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52859" id="CVE-2023-52859" title="CVE-2023-52859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27413" id="CVE-2024-27413" title="CVE-2024-27413" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52836" id="CVE-2023-52836" title="CVE-2023-52836" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47370" id="CVE-2021-47370" title="CVE-2021-47370" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35877" id="CVE-2024-35877" title="CVE-2024-35877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52796" id="CVE-2023-52796" title="CVE-2023-52796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52795" id="CVE-2023-52795" title="CVE-2023-52795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36940" id="CVE-2024-36940" title="CVE-2024-36940" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47489" id="CVE-2021-47489" title="CVE-2021-47489" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35960" id="CVE-2024-35960" title="CVE-2024-35960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47427" id="CVE-2021-47427" title="CVE-2021-47427" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36924" id="CVE-2024-36924" title="CVE-2024-36924" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35939" id="CVE-2024-35939" title="CVE-2024-35939" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36000" id="CVE-2024-36000" title="CVE-2024-36000" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52670" id="CVE-2023-52670" title="CVE-2023-52670" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35823" id="CVE-2024-35823" title="CVE-2024-35823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36015" id="CVE-2024-36015" title="CVE-2024-36015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35958" id="CVE-2024-35958" title="CVE-2024-35958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52789" id="CVE-2023-52789" title="CVE-2023-52789" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36898" id="CVE-2024-36898" title="CVE-2024-36898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52808" id="CVE-2023-52808" title="CVE-2023-52808" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52774" id="CVE-2023-52774" title="CVE-2023-52774" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35950" id="CVE-2024-35950" title="CVE-2024-35950" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35989" id="CVE-2024-35989" title="CVE-2024-35989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36906" id="CVE-2024-36906" title="CVE-2024-36906" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52799" id="CVE-2023-52799" title="CVE-2023-52799" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52746" id="CVE-2023-52746" title="CVE-2023-52746" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47558" id="CVE-2021-47558" title="CVE-2021-47558" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48689" id="CVE-2022-48689" title="CVE-2022-48689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52752" id="CVE-2023-52752" title="CVE-2023-52752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35895" id="CVE-2024-35895" title="CVE-2024-35895" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35896" id="CVE-2024-35896" title="CVE-2024-35896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36964" id="CVE-2024-36964" title="CVE-2024-36964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27399" id="CVE-2024-27399" title="CVE-2024-27399" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35855" id="CVE-2024-35855" title="CVE-2024-35855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35888" id="CVE-2024-35888" title="CVE-2024-35888" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52677" id="CVE-2023-52677" title="CVE-2023-52677" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52800" id="CVE-2023-52800" title="CVE-2023-52800" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35790" id="CVE-2024-35790" title="CVE-2024-35790" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27402" id="CVE-2024-27402" title="CVE-2024-27402" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52798" id="CVE-2023-52798" title="CVE-2023-52798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35854" id="CVE-2024-35854" title="CVE-2024-35854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36021" id="CVE-2024-36021" title="CVE-2024-36021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36900" id="CVE-2024-36900" title="CVE-2024-36900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36017" id="CVE-2024-36017" title="CVE-2024-36017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35853" id="CVE-2024-35853" title="CVE-2024-35853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35910" id="CVE-2024-35910" title="CVE-2024-35910" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35937" id="CVE-2024-35937" title="CVE-2024-35937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35925" id="CVE-2024-35925" title="CVE-2024-35925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35821" id="CVE-2024-35821" title="CVE-2024-35821" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36029" id="CVE-2024-36029" title="CVE-2024-36029" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52739" id="CVE-2023-52739" title="CVE-2023-52739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35887" id="CVE-2024-35887" title="CVE-2024-35887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36904" id="CVE-2024-36904" title="CVE-2024-36904" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36889" id="CVE-2024-36889" title="CVE-2024-36889" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36957" id="CVE-2024-36957" title="CVE-2024-36957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52756" id="CVE-2023-52756" title="CVE-2023-52756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36886" id="CVE-2024-36886" title="CVE-2024-36886" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35870" id="CVE-2024-35870" title="CVE-2024-35870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27393" id="CVE-2024-27393" title="CVE-2024-27393" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35967" id="CVE-2024-35967" title="CVE-2024-35967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52807" id="CVE-2023-52807" title="CVE-2023-52807" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35951" id="CVE-2024-35951" title="CVE-2024-35951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36916" id="CVE-2024-36916" title="CVE-2024-36916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52745" id="CVE-2023-52745" title="CVE-2023-52745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36902" id="CVE-2024-36902" title="CVE-2024-36902" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35809" id="CVE-2024-35809" title="CVE-2024-35809" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52775" id="CVE-2023-52775" title="CVE-2023-52775" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36908" id="CVE-2024-36908" title="CVE-2024-36908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36901" id="CVE-2024-36901" title="CVE-2024-36901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36960" id="CVE-2024-36960" title="CVE-2024-36960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36929" id="CVE-2024-36929" title="CVE-2024-36929" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36952" id="CVE-2024-36952" title="CVE-2024-36952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36933" id="CVE-2024-36933" title="CVE-2024-36933" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36883" id="CVE-2024-36883" title="CVE-2024-36883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52680" id="CVE-2023-52680" title="CVE-2023-52680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47247" id="CVE-2021-47247" title="CVE-2021-47247" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36899" id="CVE-2024-36899" title="CVE-2024-36899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52672" id="CVE-2023-52672" title="CVE-2023-52672" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52732" id="CVE-2023-52732" title="CVE-2023-52732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52882" id="CVE-2023-52882" title="CVE-2023-52882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35924" id="CVE-2024-35924" title="CVE-2024-35924" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48652" id="CVE-2022-48652" title="CVE-2022-48652" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52693" id="CVE-2023-52693" title="CVE-2023-52693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35915" id="CVE-2024-35915" title="CVE-2024-35915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36949" id="CVE-2024-36949" title="CVE-2024-36949" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52708" id="CVE-2023-52708" title="CVE-2023-52708" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52762" id="CVE-2023-52762" title="CVE-2023-52762" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36905" id="CVE-2024-36905" title="CVE-2024-36905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36928" id="CVE-2024-36928" title="CVE-2024-36928" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36919" id="CVE-2024-36919" title="CVE-2024-36919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35830" id="CVE-2024-35830" title="CVE-2024-35830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35828" id="CVE-2024-35828" title="CVE-2024-35828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36016" id="CVE-2024-36016" title="CVE-2024-36016" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36938" id="CVE-2024-36938" title="CVE-2024-36938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52747" id="CVE-2023-52747" title="CVE-2023-52747" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36914" id="CVE-2024-36914" title="CVE-2024-36914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35796" id="CVE-2024-35796" title="CVE-2024-35796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35966" id="CVE-2024-35966" title="CVE-2024-35966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35932" id="CVE-2024-35932" title="CVE-2024-35932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36953" id="CVE-2024-36953" title="CVE-2024-36953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35965" id="CVE-2024-35965" title="CVE-2024-35965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36923" id="CVE-2024-36923" title="CVE-2024-36923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26936" id="CVE-2024-26936" title="CVE-2024-26936" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39179" id="CVE-2023-39179" title="CVE-2023-39179" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26947" id="CVE-2024-26947" title="CVE-2024-26947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52810" id="CVE-2023-52810" title="CVE-2023-52810" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52791" id="CVE-2023-52791" title="CVE-2023-52791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26935" id="CVE-2024-26935" title="CVE-2024-26935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35947" id="CVE-2024-35947" title="CVE-2024-35947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36969" id="CVE-2024-36969" title="CVE-2024-36969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38601" id="CVE-2024-38601" title="CVE-2024-38601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38549" id="CVE-2024-38549" title="CVE-2024-38549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35811" id="CVE-2024-35811" title="CVE-2024-35811" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36978" id="CVE-2024-36978" title="CVE-2024-36978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38569" id="CVE-2024-38569" title="CVE-2024-38569" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38538" id="CVE-2024-38538" title="CVE-2024-38538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38596" id="CVE-2024-38596" title="CVE-2024-38596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36974" id="CVE-2024-36974" title="CVE-2024-36974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52696" id="CVE-2023-52696" title="CVE-2023-52696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26661" id="CVE-2024-26661" title="CVE-2024-26661" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38634" id="CVE-2024-38634" title="CVE-2024-38634" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38605" id="CVE-2024-38605" title="CVE-2024-38605" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38545" id="CVE-2024-38545" title="CVE-2024-38545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38633" id="CVE-2024-38633" title="CVE-2024-38633" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38632" id="CVE-2024-38632" title="CVE-2024-38632" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38591" id="CVE-2024-38591" title="CVE-2024-38591" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31076" id="CVE-2024-31076" title="CVE-2024-31076" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35955" id="CVE-2024-35955" title="CVE-2024-35955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47381" id="CVE-2021-47381" title="CVE-2021-47381" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38555" id="CVE-2024-38555" title="CVE-2024-38555" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38577" id="CVE-2024-38577" title="CVE-2024-38577" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38599" id="CVE-2024-38599" title="CVE-2024-38599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38564" id="CVE-2024-38564" title="CVE-2024-38564" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38630" id="CVE-2024-38630" title="CVE-2024-38630" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38624" id="CVE-2024-38624" title="CVE-2024-38624" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38589" id="CVE-2024-38589" title="CVE-2024-38589" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35969" id="CVE-2024-35969" title="CVE-2024-35969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38544" id="CVE-2024-38544" title="CVE-2024-38544" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48772" id="CVE-2022-48772" title="CVE-2022-48772" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39276" id="CVE-2024-39276" title="CVE-2024-39276" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38625" id="CVE-2024-38625" title="CVE-2024-38625" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38552" id="CVE-2024-38552" title="CVE-2024-38552" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37354" id="CVE-2024-37354" title="CVE-2024-37354" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38541" id="CVE-2024-38541" title="CVE-2024-38541" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38661" id="CVE-2024-38661" title="CVE-2024-38661" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38597" id="CVE-2024-38597" title="CVE-2024-38597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39292" id="CVE-2024-39292" title="CVE-2024-39292" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47618" id="CVE-2021-47618" title="CVE-2021-47618" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36014" id="CVE-2024-36014" title="CVE-2024-36014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38590" id="CVE-2024-38590" title="CVE-2024-38590" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38620" id="CVE-2024-38620" title="CVE-2024-38620" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48761" id="CVE-2022-48761" title="CVE-2022-48761" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39461" id="CVE-2024-39461" title="CVE-2024-39461" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47441" id="CVE-2021-47441" title="CVE-2021-47441" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39462" id="CVE-2024-39462" title="CVE-2024-39462" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48720" id="CVE-2022-48720" title="CVE-2022-48720" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52884" id="CVE-2023-52884" title="CVE-2023-52884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48748" id="CVE-2022-48748" title="CVE-2022-48748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36481" id="CVE-2024-36481" title="CVE-2024-36481" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38384" id="CVE-2024-38384" title="CVE-2024-38384" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39470" id="CVE-2024-39470" title="CVE-2024-39470" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39465" id="CVE-2024-39465" title="CVE-2024-39465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39466" id="CVE-2024-39466" title="CVE-2024-39466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35785" id="CVE-2024-35785" title="CVE-2024-35785" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35949" id="CVE-2024-35949" title="CVE-2024-35949" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36931" id="CVE-2024-36931" title="CVE-2024-36931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36937" id="CVE-2024-36937" title="CVE-2024-36937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36028" id="CVE-2024-36028" title="CVE-2024-36028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27405" id="CVE-2024-27405" title="CVE-2024-27405" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47568" id="CVE-2021-47568" title="CVE-2021-47568" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39492" id="CVE-2024-39492" title="CVE-2024-39492" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47598" id="CVE-2021-47598" title="CVE-2021-47598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36965" id="CVE-2024-36965" title="CVE-2024-36965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47187" id="CVE-2021-47187" title="CVE-2021-47187" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52657" id="CVE-2023-52657" title="CVE-2023-52657" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35786" id="CVE-2024-35786" title="CVE-2024-35786" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27432" id="CVE-2024-27432" title="CVE-2024-27432" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52684" id="CVE-2023-52684" title="CVE-2023-52684" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35850" id="CVE-2024-35850" title="CVE-2024-35850" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52689" id="CVE-2023-52689" title="CVE-2023-52689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52673" id="CVE-2023-52673" title="CVE-2023-52673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52692" id="CVE-2023-52692" title="CVE-2023-52692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47349" id="CVE-2021-47349" title="CVE-2021-47349" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47230" id="CVE-2021-47230" title="CVE-2021-47230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35857" id="CVE-2024-35857" title="CVE-2024-35857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47311" id="CVE-2021-47311" title="CVE-2021-47311" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47611" id="CVE-2021-47611" title="CVE-2021-47611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47596" id="CVE-2021-47596" title="CVE-2021-47596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47605" id="CVE-2021-47605" title="CVE-2021-47605" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48712" id="CVE-2022-48712" title="CVE-2022-48712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48724" id="CVE-2022-48724" title="CVE-2022-48724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48771" id="CVE-2022-48771" title="CVE-2022-48771" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48730" id="CVE-2022-48730" title="CVE-2022-48730" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48768" id="CVE-2022-48768" title="CVE-2022-48768" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38388" id="CVE-2024-38388" title="CVE-2024-38388" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48757" id="CVE-2022-48757" title="CVE-2022-48757" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47612" id="CVE-2021-47612" title="CVE-2021-47612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38551" id="CVE-2024-38551" title="CVE-2024-38551" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38581" id="CVE-2024-38581" title="CVE-2024-38581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38614" id="CVE-2024-38614" title="CVE-2024-38614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39464" id="CVE-2024-39464" title="CVE-2024-39464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39463" id="CVE-2024-39463" title="CVE-2024-39463" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39479" id="CVE-2024-39479" title="CVE-2024-39479" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39478" id="CVE-2024-39478" title="CVE-2024-39478" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39502" id="CVE-2024-39502" title="CVE-2024-39502" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40997" id="CVE-2024-40997" title="CVE-2024-40997" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40964" id="CVE-2024-40964" title="CVE-2024-40964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48732" id="CVE-2022-48732" title="CVE-2022-48732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38628" id="CVE-2024-38628" title="CVE-2024-38628" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38572" id="CVE-2024-38572" title="CVE-2024-38572" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27416" id="CVE-2024-27416" title="CVE-2024-27416" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48822" id="CVE-2022-48822" title="CVE-2022-48822" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36935" id="CVE-2024-36935" title="CVE-2024-36935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36955" id="CVE-2024-36955" title="CVE-2024-36955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36956" id="CVE-2024-36956" title="CVE-2024-36956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48807" id="CVE-2022-48807" title="CVE-2022-48807" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36973" id="CVE-2024-36973" title="CVE-2024-36973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48837" id="CVE-2022-48837" title="CVE-2022-48837" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36951" id="CVE-2024-36951" title="CVE-2024-36951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26978" id="CVE-2024-26978" title="CVE-2024-26978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36967" id="CVE-2024-36967" title="CVE-2024-36967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36031" id="CVE-2024-36031" title="CVE-2024-36031" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36979" id="CVE-2024-36979" title="CVE-2024-36979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36881" id="CVE-2024-36881" title="CVE-2024-36881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34030" id="CVE-2024-34030" title="CVE-2024-34030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38385" id="CVE-2024-38385" title="CVE-2024-38385" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39485" id="CVE-2024-39485" title="CVE-2024-39485" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40957" id="CVE-2024-40957" title="CVE-2024-40957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40923" id="CVE-2024-40923" title="CVE-2024-40923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40918" id="CVE-2024-40918" title="CVE-2024-40918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40936" id="CVE-2024-40936" title="CVE-2024-40936" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40975" id="CVE-2024-40975" title="CVE-2024-40975" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40951" id="CVE-2024-40951" title="CVE-2024-40951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40977" id="CVE-2024-40977" title="CVE-2024-40977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48775" id="CVE-2022-48775" title="CVE-2022-48775" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48788" id="CVE-2022-48788" title="CVE-2022-48788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48865" id="CVE-2022-48865" title="CVE-2022-48865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48856" id="CVE-2022-48856" title="CVE-2022-48856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48838" id="CVE-2022-48838" title="CVE-2022-48838" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38593" id="CVE-2024-38593" title="CVE-2024-38593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36962" id="CVE-2024-36962" title="CVE-2024-36962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38557" id="CVE-2024-38557" title="CVE-2024-38557" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38562" id="CVE-2024-38562" title="CVE-2024-38562" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38604" id="CVE-2024-38604" title="CVE-2024-38604" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38584" id="CVE-2024-38584" title="CVE-2024-38584" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38616" id="CVE-2024-38616" title="CVE-2024-38616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47610" id="CVE-2021-47610" title="CVE-2021-47610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52883" id="CVE-2023-52883" title="CVE-2023-52883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38622" id="CVE-2024-38622" title="CVE-2024-38622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38664" id="CVE-2024-38664" title="CVE-2024-38664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39371" id="CVE-2024-39371" title="CVE-2024-39371" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39468" id="CVE-2024-39468" title="CVE-2024-39468" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47583" id="CVE-2021-47583" title="CVE-2021-47583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48743" id="CVE-2022-48743" title="CVE-2022-48743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35885" id="CVE-2024-35885" title="CVE-2024-35885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35912" id="CVE-2024-35912" title="CVE-2024-35912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35911" id="CVE-2024-35911" title="CVE-2024-35911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35907" id="CVE-2024-35907" title="CVE-2024-35907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35920" id="CVE-2024-35920" title="CVE-2024-35920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35959" id="CVE-2024-35959" title="CVE-2024-35959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35952" id="CVE-2024-35952" title="CVE-2024-35952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47299" id="CVE-2021-47299" title="CVE-2021-47299" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47304" id="CVE-2021-47304" title="CVE-2021-47304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47364" id="CVE-2021-47364" title="CVE-2021-47364" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47464" id="CVE-2021-47464" title="CVE-2021-47464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47517" id="CVE-2021-47517" title="CVE-2021-47517" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47519" id="CVE-2021-47519" title="CVE-2021-47519" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47570" id="CVE-2021-47570" title="CVE-2021-47570" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47536" id="CVE-2021-47536" title="CVE-2021-47536" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36026" id="CVE-2024-36026" title="CVE-2024-36026" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36882" id="CVE-2024-36882" title="CVE-2024-36882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36022" id="CVE-2024-36022" title="CVE-2024-36022" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36033" id="CVE-2024-36033" title="CVE-2024-36033" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36892" id="CVE-2024-36892" title="CVE-2024-36892" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36943" id="CVE-2024-36943" title="CVE-2024-36943" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36932" id="CVE-2024-36932" title="CVE-2024-36932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4440" id="CVE-2021-4440" title="CVE-2021-4440" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48738" id="CVE-2022-48738" title="CVE-2022-48738" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47351" id="CVE-2021-47351" title="CVE-2021-47351" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36030" id="CVE-2024-36030" title="CVE-2024-36030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47430" id="CVE-2021-47430" title="CVE-2021-47430" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38610" id="CVE-2024-38610" title="CVE-2024-38610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47296" id="CVE-2021-47296" title="CVE-2021-47296" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38580" id="CVE-2024-38580" title="CVE-2024-38580" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48760" id="CVE-2022-48760" title="CVE-2022-48760" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36965" id="CVE-2024-36965" title="CVE-2024-36965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38629" id="CVE-2024-38629" title="CVE-2024-38629" type="cve"></reference>
		</references>
		<description>CVE-2024-26852:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/ipv6: avoid possible UAF in ip6_route_mpath_notify()&#xA;syzbot found another use-after-free in ip6_route_mpath_notify() [1]&#xA;Commit f7225172f25a (&#34;net/ipv6: prevent use after free in&#xA;ip6_route_mpath_notify&#34;) was not able to fix the root cause.&#xA;We need to defer the fib6_info_release() calls after&#xA;ip6_route_mpath_notify(), in the cleanup phase.&#xA;[1]&#xA;BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0&#xA;Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037&#xA;CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0x167/0x540 mm/kasan/report.c:488&#xA;  kasan_report+0x142/0x180 mm/kasan/report.c:601&#xA; rt6_fill_node+0x1460/0x1ac0&#xA;  inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184&#xA;  ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]&#xA;  ip6_route_multipath_add net/ipv6/route.c:5404 [inline]&#xA;  inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517&#xA;  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597&#xA;  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543&#xA;  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]&#xA;  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367&#xA;  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x221/0x270 net/socket.c:745&#xA;  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584&#xA;  ___sys_sendmsg net/socket.c:2638 [inline]&#xA;  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667&#xA; do_syscall_64+0xf9/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x6f/0x77&#xA;RIP: 0033:0x7f73dd87dda9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9&#xA;RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005&#xA;RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858&#xA; &lt;/TASK&gt;&#xA;Allocated by task 23037:&#xA;  kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;  poison_kmalloc_redzone mm/kasan/common.c:372 [inline]&#xA;  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389&#xA;  kasan_kmalloc include/linux/kasan.h:211 [inline]&#xA;  __do_kmalloc_node mm/slub.c:3981 [inline]&#xA;  __kmalloc+0x22e/0x490 mm/slub.c:3994&#xA;  kmalloc include/linux/slab.h:594 [inline]&#xA;  kzalloc include/linux/slab.h:711 [inline]&#xA;  fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155&#xA;  ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758&#xA;  ip6_route_multipath_add net/ipv6/route.c:5298 [inline]&#xA;  inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517&#xA;  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597&#xA;  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543&#xA;  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]&#xA;  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367&#xA;  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x221/0x270 net/socket.c:745&#xA;  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584&#xA;  ___sys_sendmsg net/socket.c:2638 [inline]&#xA;  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667&#xA; do_syscall_64+0xf9/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x6f/0x77&#xA;Freed by task 16:&#xA;  kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;  kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640&#xA;  poison_slab_object+0xa6/0xe0 m&#xA;---truncated---&#xA;CVE-2023-52655:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: aqc111: check packet for fixup for true limit&#xA;If a device sends a packet that is inbetween 0&#xA;and sizeof(u64) the value passed to skb_trim()&#xA;as length will wrap around ending up as some very&#xA;large value.&#xA;The driver will then proceed to parse the header&#xA;located at that position, which will either oops or&#xA;process some random value.&#xA;The fix is to check against sizeof(u64) rather than&#xA;0, which the driver currently does. The issue exists&#xA;since the introduction of the driver.&#xA;CVE-2024-35847:In the Linux kernel, the following vulnerability has been resolved:&#xA;irqchip/gic-v3-its: Prevent double free on error&#xA;The error handling path in its_vpe_irq_domain_alloc() causes a double free&#xA;when its_vpe_init() fails after successfully allocating at least one&#xA;interrupt. This happens because its_vpe_irq_domain_free() frees the&#xA;interrupts along with the area bitmap and the vprop_page and&#xA;its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the&#xA;vprop_page again.&#xA;Fix this by unconditionally invoking its_vpe_irq_domain_free() which&#xA;handles all cases correctly and by removing the bitmap/vprop_page freeing&#xA;from its_vpe_irq_domain_alloc().&#xA;[ tglx: Massaged change log ]&#xA;CVE-2024-35905:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Protect against int overflow for stack access size&#xA;This patch re-introduces protection against the size of access to stack&#xA;memory being negative; the access size can appear negative as a result&#xA;of overflowing its signed int representation. This should not actually&#xA;happen, as there are other protections along the way, but we should&#xA;protect against it anyway. One code path was missing such protections&#xA;(fixed in the previous patch in the series), causing out-of-bounds array&#xA;accesses in check_stack_range_initialized(). This patch causes the&#xA;verification of a program with such a non-sensical access size to fail.&#xA;This check used to exist in a more indirect way, but was inadvertendly&#xA;removed in a833a17aeac7.&#xA;CVE-2024-35886:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: Fix infinite recursion in fib6_dump_done().&#xA;syzkaller reported infinite recursive calls of fib6_dump_done() during&#xA;netlink socket destruction.  [1]&#xA;From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then&#xA;the response was generated.  The following recvmmsg() resumed the dump&#xA;for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due&#xA;to the fault injection.  [0]&#xA;  12:01:34 executing program 3:&#xA;  r0 = socket$nl_route(0x10, 0x3, 0x0)&#xA;  sendmsg$nl_route(r0, ... snip ...)&#xA;  recvmmsg(r0, ... snip ...) (fail_nth: 8)&#xA;Here, fib6_dump_done() was set to nlk_sk(sk)-&gt;cb.done, and the next call&#xA;of inet6_dump_fib() set it to nlk_sk(sk)-&gt;cb.args[3].  syzkaller stopped&#xA;receiving the response halfway through, and finally netlink_sock_destruct()&#xA;called nlk_sk(sk)-&gt;cb.done().&#xA;fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-&gt;cb.done() if it&#xA;is still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)-&gt;cb.done() by&#xA;nlk_sk(sk)-&gt;cb.args[3], but it has the same function, not NULL, calling&#xA;itself recursively and hitting the stack guard page.&#xA;To avoid the issue, let&#39;s set the destructor after kzalloc().&#xA;[0]:&#xA;FAULT_INJECTION: forcing a failure.&#xA;name failslab, interval 1, probability 0, space 0, times 0&#xA;CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl (lib/dump_stack.c:117)&#xA; should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)&#xA; should_failslab (mm/slub.c:3733)&#xA; kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)&#xA; inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)&#xA; rtnl_dump_all (net/core/rtnetlink.c:4029)&#xA; netlink_dump (net/netlink/af_netlink.c:2269)&#xA; netlink_recvmsg (net/netlink/af_netlink.c:1988)&#xA; ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)&#xA; ___sys_recvmsg (net/socket.c:2846)&#xA; do_recvmmsg (net/socket.c:2943)&#xA; __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)&#xA;[1]:&#xA;BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)&#xA;stack guard page: 0000 [#1] PREEMPT SMP KASAN&#xA;CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;Workqueue: events netlink_sock_destruct_work&#xA;RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)&#xA;Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd &lt;53&gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff&#xA;RSP: 0018:ffffc9000d980000 EFLAGS: 00010293&#xA;RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3&#xA;RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358&#xA;RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000&#xA;R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68&#xA;FS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;#DF&gt;&#xA; &lt;/#DF&gt;&#xA; &lt;TASK&gt;&#xA; fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))&#xA; fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))&#xA; ...&#xA; fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))&#xA; fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))&#xA; netlink_sock_destruct (net/netlink/af_netlink.c:401)&#xA; __sk_destruct (net/core/sock.c:2177 (discriminator 2))&#xA; sk_destruct (net/core/sock.c:2224)&#xA; __sk_free (net/core/sock.c:2235)&#xA; sk_free (net/core/sock.c:2246)&#xA; process_one_work (kernel/workqueue.c:3259)&#xA; worker_thread (kernel/workqueue.c:3329 kernel/workqueue.&#xA;---truncated---&#xA;CVE-2024-35817:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag&#xA;Otherwise after the GTT bo is released, the GTT and gart space is freed&#xA;but amdgpu_ttm_backend_unbind will not clear the gart page table entry&#xA;and leave valid mapping entry pointing to the stale system page. Then&#xA;if GPU access the gart address mistakely, it will read undefined value&#xA;instead page fault, harder to debug and reproduce the real issue.&#xA;CVE-2024-35976:In the Linux kernel, the following vulnerability has been resolved:&#xA;xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING&#xA;syzbot reported an illegal copy in xsk_setsockopt() [1]&#xA;Make sure to validate setsockopt() @optlen parameter.&#xA;[1]&#xA; BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420&#xA;Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549&#xA;CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0x169/0x550 mm/kasan/report.c:488&#xA;  kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA;  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]&#xA;  copy_from_sockptr include/linux/sockptr.h:55 [inline]&#xA;  xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420&#xA;  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311&#xA;  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334&#xA;  __do_sys_setsockopt net/socket.c:2343 [inline]&#xA;  __se_sys_setsockopt net/socket.c:2340 [inline]&#xA;  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340&#xA; do_syscall_64+0xfb/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;RIP: 0033:0x7fb40587de69&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036&#xA;RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69&#xA;RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006&#xA;RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000&#xA;R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08&#xA; &lt;/TASK&gt;&#xA;Allocated by task 7549:&#xA;  kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]&#xA;  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387&#xA;  kasan_kmalloc include/linux/kasan.h:211 [inline]&#xA;  __do_kmalloc_node mm/slub.c:3966 [inline]&#xA;  __kmalloc+0x233/0x4a0 mm/slub.c:3979&#xA;  kmalloc include/linux/slab.h:632 [inline]&#xA;  __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869&#xA;  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293&#xA;  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334&#xA;  __do_sys_setsockopt net/socket.c:2343 [inline]&#xA;  __se_sys_setsockopt net/socket.c:2340 [inline]&#xA;  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340&#xA; do_syscall_64+0xfb/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;The buggy address belongs to the object at ffff888028c6cde0&#xA; which belongs to the cache kmalloc-8 of size 8&#xA;The buggy address is located 1 bytes to the right of&#xA; allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)&#xA;The buggy address belongs to the physical page:&#xA;page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c&#xA;anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)&#xA;page_type: 0xffffffff()&#xA;raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001&#xA;raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;page_owner tracks the page as allocated&#xA;page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223&#xA;  set_page_owner include/linux/page_owner.h:31 [inline]&#xA;  post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533&#xA;  prep_new_page mm/page_alloc.c:&#xA;---truncated---&#xA;CVE-2023-52730:In the Linux kernel, the following vulnerability has been resolved:&#xA;mmc: sdio: fix possible resource leaks in some error paths&#xA;If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can&#xA;not release the resources, because the sdio function is not presented&#xA;in these two cases, it won&#39;t call of_node_put() or put_device().&#xA;To fix these leaks, make sdio_func_present() only control whether&#xA;device_del() needs to be called or not, then always call of_node_put()&#xA;and put_device().&#xA;In error case in sdio_init_func(), the reference of &#39;card-&gt;dev&#39; is&#xA;not get, to avoid redundant put in sdio_free_func_cis(), move the&#xA;get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),&#xA;it can keep the get/put function be balanced.&#xA;Without this patch, while doing fault inject test, it can get the&#xA;following leak reports, after this fix, the leak is gone.&#xA;unreferenced object 0xffff888112514000 (size 2048):&#xA;  comm &#34;kworker/3:2&#34;, pid 65, jiffies 4294741614 (age 124.774s)&#xA;  hex dump (first 32 bytes):&#xA;    00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff  ..o.....`X......&#xA;    10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff  .@Q......@Q.....&#xA;  backtrace:&#xA;    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110&#xA;    [&lt;000000002f839ccb&gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]&#xA;    [&lt;0000000004adcbf6&gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]&#xA;    [&lt;000000007538fea0&gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]&#xA;    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]&#xA;unreferenced object 0xffff888112511000 (size 2048):&#xA;  comm &#34;kworker/3:2&#34;, pid 65, jiffies 4294741623 (age 124.766s)&#xA;  hex dump (first 32 bytes):&#xA;    00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff  .@Q......X......&#xA;    10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff  ..Q.......Q.....&#xA;  backtrace:&#xA;    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110&#xA;    [&lt;00000000fcbe706c&gt;] sdio_alloc_func+0x35/0x100 [mmc_core]&#xA;    [&lt;00000000c68f4b50&gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]&#xA;    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]&#xA;CVE-2023-52805:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix array-index-out-of-bounds in diAlloc&#xA;Currently there is not check against the agno of the iag while&#xA;allocating new inodes to avoid fragmentation problem. Added the check&#xA;which is required.&#xA;CVE-2023-52750:In the Linux kernel, the following vulnerability has been resolved:&#xA;arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer&#xA;Prior to LLVM 15.0.0, LLVM&#39;s integrated assembler would incorrectly&#xA;byte-swap NOP when compiling for big-endian, and the resulting series of&#xA;bytes happened to match the encoding of FNMADD S21, S30, S0, S0.&#xA;This went unnoticed until commit:&#xA;  34f66c4c4d5518c1 (&#34;arm64: Use a positive cpucap for FP/SIMD&#34;)&#xA;Prior to that commit, the kernel would always enable the use of FPSIMD&#xA;early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of&#xA;FNMADD within the kernel was not detected, but could result in the&#xA;corruption of user or kernel FPSIMD state.&#xA;After that commit, the instructions happen to trap during boot prior to&#xA;FPSIMD being detected and enabled, e.g.&#xA;| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD&#xA;| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1&#xA;| Hardware name: linux,dummy-virt (DT)&#xA;| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;| pc : __pi_strcmp+0x1c/0x150&#xA;| lr : populate_properties+0xe4/0x254&#xA;| sp : ffffd014173d3ad0&#xA;| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000&#xA;| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008&#xA;| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044&#xA;| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005&#xA;| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000&#xA;| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000&#xA;| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000&#xA;| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000&#xA;| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a&#xA;| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8&#xA;| Kernel panic - not syncing: Unhandled exception&#xA;| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1&#xA;| Hardware name: linux,dummy-virt (DT)&#xA;| Call trace:&#xA;|  dump_backtrace+0xec/0x108&#xA;|  show_stack+0x18/0x2c&#xA;|  dump_stack_lvl+0x50/0x68&#xA;|  dump_stack+0x18/0x24&#xA;|  panic+0x13c/0x340&#xA;|  el1t_64_irq_handler+0x0/0x1c&#xA;|  el1_abort+0x0/0x5c&#xA;|  el1h_64_sync+0x64/0x68&#xA;|  __pi_strcmp+0x1c/0x150&#xA;|  unflatten_dt_nodes+0x1e8/0x2d8&#xA;|  __unflatten_device_tree+0x5c/0x15c&#xA;|  unflatten_device_tree+0x38/0x50&#xA;|  setup_arch+0x164/0x1e0&#xA;|  start_kernel+0x64/0x38c&#xA;|  __primary_switched+0xbc/0xc4&#xA;Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is&#xA;either GNU as or LLVM&#39;s IAS 15.0.0 and newer, which contains the linked&#xA;commit.&#xA;CVE-2023-52804:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/jfs: Add validity check for db_maxag and db_agpref&#xA;Both db_maxag and db_agpref are used as the index of the&#xA;db_agfree array, but there is currently no validity check for&#xA;db_maxag and db_agpref, which can lead to errors.&#xA;The following is related bug reported by Syzbot:&#xA;UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20&#xA;index 7936 is out of range for type &#39;atomic_t[128]&#39;&#xA;Add checking that the values of db_maxag and db_agpref are valid&#xA;indexes for the db_agfree array.&#xA;CVE-2023-52669:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: s390/aes - Fix buffer overread in CTR mode&#xA;When processing the last block, the s390 ctr code will always read&#xA;a whole block, even if there isn&#39;t a whole block of data left.  Fix&#xA;this by using the actual length left and copy it into a buffer first&#xA;for processing.&#xA;CVE-2024-35995:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPI: CPPC: Use access_width over bit_width for system memory accesses&#xA;To align with ACPI 6.3+, since bit_width can be any 8-bit value, it&#xA;cannot be depended on to be always on a clean 8b boundary. This was&#xA;uncovered on the Cobalt 100 platform.&#xA;SError Interrupt on CPU26, code 0xbe000011 -- SError&#xA; CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1&#xA; Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION&#xA; pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)&#xA; pc : cppc_get_perf_caps+0xec/0x410&#xA; lr : cppc_get_perf_caps+0xe8/0x410&#xA; sp : ffff8000155ab730&#xA; x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078&#xA; x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff&#xA; x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000&#xA; x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff&#xA; x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008&#xA; x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006&#xA; x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec&#xA; x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028&#xA; x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff&#xA; x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000&#xA; Kernel panic - not syncing: Asynchronous SError Interrupt&#xA; CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted&#xA;5.15.2.1-13 #1&#xA; Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION&#xA; Call trace:&#xA;  dump_backtrace+0x0/0x1e0&#xA;  show_stack+0x24/0x30&#xA;  dump_stack_lvl+0x8c/0xb8&#xA;  dump_stack+0x18/0x34&#xA;  panic+0x16c/0x384&#xA;  add_taint+0x0/0xc0&#xA;  arm64_serror_panic+0x7c/0x90&#xA;  arm64_is_fatal_ras_serror+0x34/0xa4&#xA;  do_serror+0x50/0x6c&#xA;  el1h_64_error_handler+0x40/0x74&#xA;  el1h_64_error+0x7c/0x80&#xA;  cppc_get_perf_caps+0xec/0x410&#xA;  cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]&#xA;  cpufreq_online+0x2dc/0xa30&#xA;  cpufreq_add_dev+0xc0/0xd4&#xA;  subsys_interface_register+0x134/0x14c&#xA;  cpufreq_register_driver+0x1b0/0x354&#xA;  cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]&#xA;  do_one_initcall+0x50/0x250&#xA;  do_init_module+0x60/0x27c&#xA;  load_module+0x2300/0x2570&#xA;  __do_sys_finit_module+0xa8/0x114&#xA;  __arm64_sys_finit_module+0x2c/0x3c&#xA;  invoke_syscall+0x78/0x100&#xA;  el0_svc_common.constprop.0+0x180/0x1a0&#xA;  do_el0_svc+0x84/0xa0&#xA;  el0_svc+0x2c/0xc0&#xA;  el0t_64_sync_handler+0xa4/0x12c&#xA;  el0t_64_sync+0x1a4/0x1a8&#xA;Instead, use access_width to determine the size and use the offset and&#xA;width to shift and mask the bits to read/write out. Make sure to add a&#xA;check for system memory since pcc redefines the access_width to&#xA;subspace id.&#xA;If access_width is not set, then fall back to using bit_width.&#xA;[ rjw: Subject and changelog edits, comment adjustments ]&#xA;CVE-2024-35956:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations&#xA;Create subvolume, create snapshot and delete subvolume all use&#xA;btrfs_subvolume_reserve_metadata() to reserve metadata for the changes&#xA;done to the parent subvolume&#39;s fs tree, which cannot be mediated in the&#xA;normal way via start_transaction. When quota groups (squota or qgroups)&#xA;are enabled, this reserves qgroup metadata of type PREALLOC. Once the&#xA;operation is associated to a transaction, we convert PREALLOC to&#xA;PERTRANS, which gets cleared in bulk at the end of the transaction.&#xA;However, the error paths of these three operations were not implementing&#xA;this lifecycle correctly. They unconditionally converted the PREALLOC to&#xA;PERTRANS in a generic cleanup step regardless of errors or whether the&#xA;operation was fully associated to a transaction or not. This resulted in&#xA;error paths occasionally converting this rsv to PERTRANS without calling&#xA;record_root_in_trans successfully, which meant that unless that root got&#xA;recorded in the transaction by some other thread, the end of the&#xA;transaction would not free that root&#39;s PERTRANS, leaking it. Ultimately,&#xA;this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount&#xA;for the leaked reservation.&#xA;The fix is to ensure that every qgroup PREALLOC reservation observes the&#xA;following properties:&#xA;1. any failure before record_root_in_trans is called successfully&#xA;   results in freeing the PREALLOC reservation.&#xA;2. after record_root_in_trans, we convert to PERTRANS, and now the&#xA;   transaction owns freeing the reservation.&#xA;This patch enforces those properties on the three operations. Without&#xA;it, generic/269 with squotas enabled at mkfs time would fail in ~5-10&#xA;runs on my system. With this patch, it ran successfully 1000 times in a&#xA;row.&#xA;CVE-2023-52878:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: dev: can_put_echo_skb(): don&#39;t crash kernel if can_priv::echo_skb is accessed out of bounds&#xA;If the &#34;struct can_priv::echoo_skb&#34; is accessed out of bounds, this&#xA;would cause a kernel crash. Instead, issue a meaningful warning&#xA;message and return with an error.&#xA;CVE-2023-52818:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7&#xA;For pptable structs that use flexible array sizes, use flexible arrays.&#xA;CVE-2023-52736:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: hda: Do not unset preset when cleaning up codec&#xA;Several functions that take part in codec&#39;s initialization and removal&#xA;are re-used by ASoC codec drivers implementations. Drivers mimic the&#xA;behavior of hda_codec_driver_probe/remove() found in&#xA;sound/pci/hda/hda_bind.c with their component-&gt;probe/remove() instead.&#xA;One of the reasons for that is the expectation of&#xA;snd_hda_codec_device_new() to receive a valid pointer to an instance of&#xA;struct snd_card. This expectation can be met only once sound card&#xA;components probing commences.&#xA;As ASoC sound card may be unbound without codec device being actually&#xA;removed from the system, unsetting -&gt;preset in&#xA;snd_hda_codec_cleanup_for_unbind() interferes with module unload -&gt; load&#xA;scenario causing null-ptr-deref. Preset is assigned only once, during&#xA;device/driver matching whereas ASoC codec driver&#39;s module reloading may&#xA;occur several times throughout the lifetime of an audio stack.&#xA;CVE-2024-35822:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: udc: remove warning when queue disabled ep&#xA;It is possible trigger below warning message from mass storage function,&#xA;WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104&#xA;pc : usb_ep_queue+0x7c/0x104&#xA;lr : fsg_main_thread+0x494/0x1b3c&#xA;Root cause is mass storage function try to queue request from main thread,&#xA;but other thread may already disable ep when function disable.&#xA;As there is no function failure in the driver, in order to avoid effort&#xA;to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().&#xA;CVE-2021-47265:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA: Verify port when creating flow rule&#xA;Validate port value provided by the user and with that remove no longer&#xA;needed validation by the driver.  The missing check in the mlx5_ib driver&#xA;could cause to the below oops.&#xA;Call trace:&#xA;  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]&#xA;  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]&#xA;  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]&#xA;  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]&#xA;  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]&#xA;  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]&#xA;  do_vfs_ioctl+0xd0/0xaf0&#xA;  ksys_ioctl+0x84/0xb4&#xA;  __arm64_sys_ioctl+0x28/0xc4&#xA;  el0_svc_common.constprop.3+0xa4/0x254&#xA;  el0_svc_handler+0x84/0xa0&#xA;  el0_svc+0x10/0x26c&#xA; Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)&#xA;CVE-2023-52826:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference&#xA;In tpg110_get_modes(), the return value of drm_mode_duplicate() is&#xA;assigned to mode, which will lead to a NULL pointer dereference on&#xA;failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2023-52735:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf, sockmap: Don&#39;t let sock_map_{close,destroy,unhash} call itself&#xA;sock_map proto callbacks should never call themselves by design. Protect&#xA;against bugs like [1] and break out of the recursive loop to avoid a stack&#xA;overflow in favor of a resource leak.&#xA;[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/&#xA;CVE-2023-52819:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga&#xA;For pptable structs that use flexible array sizes, use flexible arrays.&#xA;CVE-2023-52703:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/usb: kalmia: Don&#39;t pass act_len in usb_bulk_msg error path&#xA;syzbot reported that act_len in kalmia_send_init_packet() is&#xA;uninitialized when passing it to the first usb_bulk_msg error path. Jiri&#xA;Pirko noted that it&#39;s pointless to pass it in the error path, and that&#xA;the value that would be printed in the second error path would be the&#xA;value of act_len from the first call to usb_bulk_msg.[1]&#xA;With this in mind, let&#39;s just not pass act_len to the usb_bulk_msg error&#xA;paths.&#xA;1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/&#xA;CVE-2023-52699:In the Linux kernel, the following vulnerability has been resolved:&#xA;sysv: don&#39;t call sb_bread() with pointers_lock held&#xA;syzbot is reporting sleep in atomic context in SysV filesystem [1], for&#xA;sb_bread() is called with rw_spinlock held.&#xA;A &#34;write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock&#34; bug&#xA;and a &#34;sb_bread() with write_lock(&amp;pointers_lock)&#34; bug were introduced by&#xA;&#34;Replace BKL for chain locking with sysvfs-private rwlock&#34; in Linux 2.5.12.&#xA;Then, &#34;[PATCH] err1-40: sysvfs locking fix&#34; in Linux 2.6.8 fixed the&#xA;former bug by moving pointers_lock lock to the callers, but instead&#xA;introduced a &#34;sb_bread() with read_lock(&amp;pointers_lock)&#34; bug (which made&#xA;this problem easier to hit).&#xA;Al Viro suggested that why not to do like get_branch()/get_block()/&#xA;find_shared() in Minix filesystem does. And doing like that is almost a&#xA;revert of &#34;[PATCH] err1-40: sysvfs locking fix&#34; except that get_branch()&#xA; from with find_shared() is called without write_lock(&amp;pointers_lock).&#xA;CVE-2023-52832:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: don&#39;t return unset power in ieee80211_get_tx_power()&#xA;We can get a UBSAN warning if ieee80211_get_tx_power() returns the&#xA;INT_MIN value mac80211 internally uses for &#34;unset power level&#34;.&#xA; UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5&#xA; -2147483648 * 100 cannot be represented in type &#39;int&#39;&#xA; CPU: 0 PID: 20433 Comm: insmod Tainted: G        WC OE&#xA; Call Trace:&#xA;  dump_stack+0x74/0x92&#xA;  ubsan_epilogue+0x9/0x50&#xA;  handle_overflow+0x8d/0xd0&#xA;  __ubsan_handle_mul_overflow+0xe/0x10&#xA;  nl80211_send_iface+0x688/0x6b0 [cfg80211]&#xA;  [...]&#xA;  cfg80211_register_wdev+0x78/0xb0 [cfg80211]&#xA;  cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]&#xA;  [...]&#xA;  ieee80211_if_add+0x60e/0x8f0 [mac80211]&#xA;  ieee80211_register_hw+0xda5/0x1170 [mac80211]&#xA;In this case, simply return an error instead, to indicate&#xA;that no data is available.&#xA;CVE-2023-52759:In the Linux kernel, the following vulnerability has been resolved:&#xA;gfs2: ignore negated quota changes&#xA;When lots of quota changes are made, there may be cases in which an&#xA;inode&#39;s quota information is increased and then decreased, such as when&#xA;blocks are added to a file, then deleted from it. If the timing is&#xA;right, function do_qc can add pending quota changes to a transaction,&#xA;then later, another call to do_qc can negate those changes, resulting&#xA;in a net gain of 0. The quota_change information is recorded in the qc&#xA;buffer (and qd element of the inode as well). The buffer is added to the&#xA;transaction by the first call to do_qc, but a subsequent call changes&#xA;the value from non-zero back to zero. At that point it&#39;s too late to&#xA;remove the buffer_head from the transaction. Later, when the quota sync&#xA;code is called, the zero-change qd element is discovered and flagged as&#xA;an assert warning. If the fs is mounted with errors=panic, the kernel&#xA;will panic.&#xA;This is usually seen when files are truncated and the quota changes are&#xA;negated by punch_hole/truncate which uses gfs2_quota_hold and&#xA;gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock&#xA;and gfs2_quota_unlock which automatically do quota sync.&#xA;This patch solves the problem by adding a check to qd_check_sync such&#xA;that net-zero quota changes already added to the transaction are no&#xA;longer deemed necessary to be synced, and skipped.&#xA;In this case references are taken for the qd and the slot from do_qc&#xA;so those need to be put. The normal sequence of events for a normal&#xA;non-zero quota change is as follows:&#xA;gfs2_quota_change&#xA;   do_qc&#xA;      qd_hold&#xA;      slot_hold&#xA;Later, when the changes are to be synced:&#xA;gfs2_quota_sync&#xA;   qd_fish&#xA;      qd_check_sync&#xA;         gets qd ref via lockref_get_not_dead&#xA;   do_sync&#xA;      do_qc(QC_SYNC)&#xA;         qd_put&#xA;&#x9;    lockref_put_or_lock&#xA;   qd_unlock&#xA;      qd_put&#xA;         lockref_put_or_lock&#xA;In the net-zero change case, we add a check to qd_check_sync so it puts&#xA;the qd and slot references acquired in gfs2_quota_change and skip the&#xA;unneeded sync.&#xA;CVE-2023-52705:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix underflow in second superblock position calculations&#xA;Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second&#xA;superblock, underflows when the argument device size is less than 4096&#xA;bytes.  Therefore, when using this macro, it is necessary to check in&#xA;advance that the device size is not less than a lower limit, or at least&#xA;that underflow does not occur.&#xA;The current nilfs2 implementation lacks this check, causing out-of-bound&#xA;block access when mounting devices smaller than 4096 bytes:&#xA; I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0&#xA; phys_seg 1 prio class 2&#xA; NILFS (loop0): unable to read secondary superblock (blocksize = 1024)&#xA;In addition, when trying to resize the filesystem to a size below 4096&#xA;bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number&#xA;of segments to nilfs_sufile_resize(), corrupting parameters such as the&#xA;number of segments in superblocks.  This causes excessive loop iterations&#xA;in nilfs_sufile_resize() during a subsequent resize ioctl, causing&#xA;semaphore ns_segctor_sem to block for a long time and hang the writer&#xA;thread:&#xA; INFO: task segctord:5067 blocked for more than 143 seconds.&#xA;      Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0&#xA; &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA; task:segctord        state:D stack:23456 pid:5067  ppid:2&#xA; flags:0x00004000&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  context_switch kernel/sched/core.c:5293 [inline]&#xA;  __schedule+0x1409/0x43f0 kernel/sched/core.c:6606&#xA;  schedule+0xc3/0x190 kernel/sched/core.c:6682&#xA;  rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190&#xA;  nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357&#xA;  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]&#xA;  nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570&#xA;  kthread+0x270/0x300 kernel/kthread.c:376&#xA;  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308&#xA;  &lt;/TASK&gt;&#xA; ...&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  folio_mark_accessed+0x51c/0xf00 mm/swap.c:515&#xA;  __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]&#xA;  nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61&#xA;  nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121&#xA;  nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176&#xA;  nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251&#xA;  nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]&#xA;  nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]&#xA;  nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777&#xA;  nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422&#xA;  nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]&#xA;  nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301&#xA;  ...&#xA;This fixes these issues by inserting appropriate minimum device size&#xA;checks or anti-underflow checks, depending on where the macro is used.&#xA;CVE-2023-52859:In the Linux kernel, the following vulnerability has been resolved:&#xA;perf: hisi: Fix use-after-free when register pmu fails&#xA;When we fail to register the uncore pmu, the pmu context may not been&#xA;allocated. The error handing will call cpuhp_state_remove_instance()&#xA;to call uncore pmu offline callback, which migrate the pmu context.&#xA;Since that&#39;s liable to lead to some kind of use-after-free.&#xA;Use cpuhp_state_remove_instance_nocalls() instead of&#xA;cpuhp_state_remove_instance() so that the notifiers don&#39;t execute after&#xA;the PMU device has been failed to register.&#xA;CVE-2024-27413:In the Linux kernel, the following vulnerability has been resolved:&#xA;efi/capsule-loader: fix incorrect allocation size&#xA;gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures&#xA;is not enough for a 64-bit phys_addr_t:&#xA;drivers/firmware/efi/capsule-loader.c: In function &#39;efi_capsule_open&#39;:&#xA;drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size &#39;4&#39; for type &#39;phys_addr_t&#39; {aka &#39;long long unsigned int&#39;} with size &#39;8&#39; [-Werror=alloc-size]&#xA;  295 |         cap_info-&gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);&#xA;      |                        ^&#xA;Use the correct type instead here.&#xA;CVE-2023-52836:In the Linux kernel, the following vulnerability has been resolved:&#xA;locking/ww_mutex/test: Fix potential workqueue corruption&#xA;In some cases running with the test-ww_mutex code, I was seeing&#xA;odd behavior where sometimes it seemed flush_workqueue was&#xA;returning before all the work threads were finished.&#xA;Often this would cause strange crashes as the mutexes would be&#xA;freed while they were being used.&#xA;Looking at the code, there is a lifetime problem as the&#xA;controlling thread that spawns the work allocates the&#xA;&#34;struct stress&#34; structures that are passed to the workqueue&#xA;threads. Then when the workqueue threads are finished,&#xA;they free the stress struct that was passed to them.&#xA;Unfortunately the workqueue work_struct node is in the stress&#xA;struct. Which means the work_struct is freed before the work&#xA;thread returns and while flush_workqueue is waiting.&#xA;It seems like a better idea to have the controlling thread&#xA;both allocate and free the stress structures, so that we can&#xA;be sure we don&#39;t corrupt the workqueue by freeing the structure&#xA;prematurely.&#xA;So this patch reworks the test to do so, and with this change&#xA;I no longer see the early flush_workqueue returns.&#xA;CVE-2021-47370:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: ensure tx skbs always have the MPTCP ext&#xA;Due to signed/unsigned comparison, the expression:&#xA;&#x9;info-&gt;size_goal - skb-&gt;len &gt; 0&#xA;evaluates to true when the size goal is smaller than the&#xA;skb size. That results in lack of tx cache refill, so that&#xA;the skb allocated by the core TCP code lacks the required&#xA;MPTCP skb extensions.&#xA;Due to the above, syzbot is able to trigger the following WARN_ON():&#xA;WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366&#xA;Modules linked in:&#xA;CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366&#xA;Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 &lt;0f&gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9&#xA;RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216&#xA;RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000&#xA;RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003&#xA;RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280&#xA;R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0&#xA;FS:  00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547&#xA; mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003&#xA; release_sock+0xb4/0x1b0 net/core/sock.c:3206&#xA; sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145&#xA; mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749&#xA; inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643&#xA; sock_sendmsg_nosec net/socket.c:704 [inline]&#xA; sock_sendmsg+0xcf/0x120 net/socket.c:724&#xA; sock_write_iter+0x2a0/0x3e0 net/socket.c:1057&#xA; call_write_iter include/linux/fs.h:2163 [inline]&#xA; new_sync_write+0x40b/0x640 fs/read_write.c:507&#xA; vfs_write+0x7cf/0xae0 fs/read_write.c:594&#xA; ksys_write+0x1ee/0x250 fs/read_write.c:647&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;RIP: 0033:0x4665f9&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9&#xA;RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003&#xA;RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038&#xA;R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000&#xA;Fix the issue rewriting the relevant expression to avoid&#xA;sign-related problems - note: size_goal is always &gt;= 0.&#xA;Additionally, ensure that the skb in the tx cache always carries&#xA;the relevant extension.&#xA;CVE-2024-35877:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/mm/pat: fix VM_PAT handling in COW mappings&#xA;PAT handling won&#39;t do the right thing in COW mappings: the first PTE (or,&#xA;in fact, all PTEs) can be replaced during write faults to point at anon&#xA;folios.  Reliably recovering the correct PFN and cachemode using&#xA;follow_phys() from PTEs will not work in COW mappings.&#xA;Using follow_phys(), we might just get the address+protection of the anon&#xA;folio (which is very wrong), or fail on swap/nonswap entries, failing&#xA;follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and&#xA;track_pfn_copy(), not properly calling free_pfn_range().&#xA;In free_pfn_range(), we either wouldn&#39;t call memtype_free() or would call&#xA;it with the wrong range, possibly leaking memory.&#xA;To fix that, let&#39;s update follow_phys() to refuse returning anon folios,&#xA;and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings&#xA;if we run into that.&#xA;We will now properly handle untrack_pfn() with COW mappings, where we&#xA;don&#39;t need the cachemode.  We&#39;ll have to fail fork()-&gt;track_pfn_copy() if&#xA;the first page was replaced by an anon folio, though: we&#39;d have to store&#xA;the cachemode in the VMA to make this work, likely growing the VMA size.&#xA;For now, lets keep it simple and let track_pfn_copy() just fail in that&#xA;case: it would have failed in the past with swap/nonswap entries already,&#xA;and it would have done the wrong thing with anon folios.&#xA;Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():&#xA;&lt;--- C reproducer ---&gt;&#xA; #include &lt;stdio.h&gt;&#xA; #include &lt;sys/mman.h&gt;&#xA; #include &lt;unistd.h&gt;&#xA; #include &lt;liburing.h&gt;&#xA; int main(void)&#xA; {&#xA;         struct io_uring_params p = {};&#xA;         int ring_fd;&#xA;         size_t size;&#xA;         char *map;&#xA;         ring_fd = io_uring_setup(1, &amp;p);&#xA;         if (ring_fd &lt; 0) {&#xA;                 perror(&#34;io_uring_setup&#34;);&#xA;                 return 1;&#xA;         }&#xA;         size = p.sq_off.array + p.sq_entries * sizeof(unsigned);&#xA;         /* Map the submission queue ring MAP_PRIVATE */&#xA;         map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,&#xA;                    ring_fd, IORING_OFF_SQ_RING);&#xA;         if (map == MAP_FAILED) {&#xA;                 perror(&#34;mmap&#34;);&#xA;                 return 1;&#xA;         }&#xA;         /* We have at least one page. Let&#39;s COW it. */&#xA;         *map = 0;&#xA;         pause();&#xA;         return 0;&#xA; }&#xA;&lt;--- C reproducer ---&gt;&#xA;On a system with 16 GiB RAM and swap configured:&#xA; # ./iouring &amp;&#xA; # memhog 16G&#xA; # killall iouring&#xA;[  301.552930] ------------[ cut here ]------------&#xA;[  301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100&#xA;[  301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g&#xA;[  301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1&#xA;[  301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4&#xA;[  301.559569] RIP: 0010:untrack_pfn+0xf4/0x100&#xA;[  301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000&#xA;[  301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282&#xA;[  301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047&#xA;[  301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200&#xA;[  301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000&#xA;[  301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000&#xA;[  301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000&#xA;[  301.564186] FS:  0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000&#xA;[  301.564773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0&#xA;[  301.565725] PKRU: 55555554&#xA;[  301.565944] Call Trace:&#xA;[  301.566148]  &lt;TASK&gt;&#xA;[  301.566325]  ? untrack_pfn+0xf4/0x100&#xA;[  301.566618]  ? __warn+0x81/0x130&#xA;[  301.566876]  ? untrack_pfn+0xf4/0x100&#xA;[  3&#xA;---truncated---&#xA;CVE-2023-52796:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipvlan: add ipvlan_route_v6_outbound() helper&#xA;Inspired by syzbot reports using a stack of multiple ipvlan devices.&#xA;Reduce stack size needed in ipvlan_process_v6_outbound() by moving&#xA;the flowi6 struct used for the route lookup in an non inlined&#xA;helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,&#xA;immediately reclaimed.&#xA;Also make sure ipvlan_process_v4_outbound() is not inlined.&#xA;We might also have to lower MAX_NEST_DEV, because only syzbot uses&#xA;setups with more than four stacked devices.&#xA;BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)&#xA;stack guard page: 0000 [#1] SMP KASAN&#xA;CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023&#xA;RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188&#xA;Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 &lt;41&gt; 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89&#xA;RSP: 0018:ffffc9000e804000 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2&#xA;RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568&#xA;RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c&#xA;R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000&#xA;FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA;&lt;#DF&gt;&#xA;&lt;/#DF&gt;&#xA;&lt;TASK&gt;&#xA;[&lt;ffffffff81f281d1&gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31&#xA;[&lt;ffffffff817e5bf2&gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]&#xA;[&lt;ffffffff817e5bf2&gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]&#xA;[&lt;ffffffff817e5bf2&gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]&#xA;[&lt;ffffffff817e5bf2&gt;] cpu_online include/linux/cpumask.h:1092 [inline]&#xA;[&lt;ffffffff817e5bf2&gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]&#xA;[&lt;ffffffff817e5bf2&gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632&#xA;[&lt;ffffffff8563221e&gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306&#xA;[&lt;ffffffff8561464d&gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]&#xA;[&lt;ffffffff8561464d&gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221&#xA;[&lt;ffffffff85618120&gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606&#xA;[&lt;ffffffff856f65b5&gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]&#xA;[&lt;ffffffff856f65b5&gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116&#xA;[&lt;ffffffff85618009&gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638&#xA;[&lt;ffffffff8561821a&gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651&#xA;[&lt;ffffffff838bd5a3&gt;] ip6_route_output include/net/ip6_route.h:100 [inline]&#xA;[&lt;ffffffff838bd5a3&gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]&#xA;[&lt;ffffffff838bd5a3&gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]&#xA;[&lt;ffffffff838bd5a3&gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]&#xA;[&lt;ffffffff838bd5a3&gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677&#xA;[&lt;ffffffff838c2909&gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229&#xA;[&lt;ffffffff84d03900&gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]&#xA;[&lt;ffffffff84d03900&gt;] xmit_one net/core/dev.c:3644 [inline]&#xA;[&lt;ffffffff84d03900&gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660&#xA;[&lt;ffffffff84d080e2&gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324&#xA;[&lt;ffffffff855ce4cd&gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]&#xA;[&lt;ffffffff855ce4cd&gt;] neigh_hh_output include/net/neighbour.h:529 [inline]&#xA;[&lt;f&#xA;---truncated---&#xA;CVE-2023-52795:In the Linux kernel, the following vulnerability has been resolved:&#xA;vhost-vdpa: fix use after free in vhost_vdpa_probe()&#xA;The put_device() calls vhost_vdpa_release_dev() which calls&#xA;ida_simple_remove() and frees &#34;v&#34;.  So this call to&#xA;ida_simple_remove() is a use after free and a double free.&#xA;CVE-2024-36940:In the Linux kernel, the following vulnerability has been resolved:&#xA;pinctrl: core: delete incorrect free in pinctrl_enable()&#xA;The &#34;pctldev&#34; struct is allocated in devm_pinctrl_register_and_init().&#xA;It&#39;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),&#xA;so freeing it in pinctrl_enable() will lead to a double free.&#xA;The devm_pinctrl_dev_release() function frees the pindescs and destroys&#xA;the mutex as well.&#xA;CVE-2021-47489:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix even more out of bound writes from debugfs&#xA;CVE-2021-42327 was fixed by:&#xA;commit f23750b5b3d98653b31d4469592935ef6364ad67&#xA;Author: Thelford Williams &lt;tdwilliamsiv@gmail.com&gt;&#xA;Date:   Wed Oct 13 16:04:13 2021 -0400&#xA;    drm/amdgpu: fix out of bounds write&#xA;but amdgpu_dm_debugfs.c contains more of the same issue so fix the&#xA;remaining ones.&#xA;v2:&#xA;&#x9;* Add missing fix in dp_max_bpc_write (Harry Wentland)&#xA;CVE-2024-35960:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Properly link new fs rules into the tree&#xA;Previously, add_rule_fg would only add newly created rules from the&#xA;handle into the tree when they had a refcount of 1. On the other hand,&#xA;create_flow_handle tries hard to find and reference already existing&#xA;identical rules instead of creating new ones.&#xA;These two behaviors can result in a situation where create_flow_handle&#xA;1) creates a new rule and references it, then&#xA;2) in a subsequent step during the same handle creation references it&#xA;   again,&#xA;resulting in a rule with a refcount of 2 that is not linked into the&#xA;tree, will have a NULL parent and root and will result in a crash when&#xA;the flow group is deleted because del_sw_hw_rule, invoked on rule&#xA;deletion, assumes node-&gt;parent is != NULL.&#xA;This happened in the wild, due to another bug related to incorrect&#xA;handling of duplicate pkt_reformat ids, which lead to the code in&#xA;create_flow_handle incorrectly referencing a just-added rule in the same&#xA;flow handle, resulting in the problem described above. Full details are&#xA;at [1].&#xA;This patch changes add_rule_fg to add new rules without parents into&#xA;the tree, properly initializing them and avoiding the crash. This makes&#xA;it more consistent with how rules are added to an FTE in&#xA;create_flow_handle.&#xA;CVE-2021-47427:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: iscsi: Fix iscsi_task use after free&#xA;Commit d39df158518c (&#34;scsi: iscsi: Have abort handler get ref to conn&#34;)&#xA;added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but&#xA;then also changed the handling of the case where we detect an already&#xA;completed task where we now end up doing a goto to the common put/cleanup&#xA;code. This results in a iscsi_task use after free, because the common&#xA;cleanup code will do a put on the iscsi_task.&#xA;This reverts the goto and moves the iscsi_get_conn() to after we&#39;ve checked&#xA;if the iscsi_task is valid.&#xA;CVE-2024-36924:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()&#xA;lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the&#xA;hbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the&#xA;hbalock to avoid potential deadlock.&#xA;CVE-2024-35939:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma-direct: Leak pages on dma_set_decrypted() failure&#xA;On TDX it is possible for the untrusted host to cause&#xA;set_memory_encrypted() or set_memory_decrypted() to fail such that an&#xA;error is returned and the resulting memory is shared. Callers need to&#xA;take care to handle these errors to avoid returning decrypted (shared)&#xA;memory to the page allocator, which could lead to functional or security&#xA;issues.&#xA;DMA could free decrypted/shared pages if dma_set_decrypted() fails. This&#xA;should be a rare case. Just leak the pages in this case instead of&#xA;freeing them.&#xA;CVE-2024-36000:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/hugetlb: fix missing hugetlb_lock for resv uncharge&#xA;There is a recent report on UFFDIO_COPY over hugetlb:&#xA;https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/&#xA;350:&#x9;lockdep_assert_held(&amp;hugetlb_lock);&#xA;Should be an issue in hugetlb but triggered in an userfault context, where&#xA;it goes into the unlikely path where two threads modifying the resv map&#xA;together.  Mike has a fix in that path for resv uncharge but it looks like&#xA;the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()&#xA;will update the cgroup pointer, so it requires to be called with the lock&#xA;held.&#xA;CVE-2023-52670:In the Linux kernel, the following vulnerability has been resolved:&#xA;rpmsg: virtio: Free driver_override when rpmsg_remove()&#xA;Free driver_override when rpmsg_remove(), otherwise&#xA;the following memory leak will occur:&#xA;unreferenced object 0xffff0000d55d7080 (size 128):&#xA;  comm &#34;kworker/u8:2&#34;, pid 56, jiffies 4294893188 (age 214.272s)&#xA;  hex dump (first 32 bytes):&#xA;    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace:&#xA;    [&lt;000000009c94c9c1&gt;] __kmem_cache_alloc_node+0x1f8/0x320&#xA;    [&lt;000000002300d89b&gt;] __kmalloc_node_track_caller+0x44/0x70&#xA;    [&lt;00000000228a60c3&gt;] kstrndup+0x4c/0x90&#xA;    [&lt;0000000077158695&gt;] driver_set_override+0xd0/0x164&#xA;    [&lt;000000003e9c4ea5&gt;] rpmsg_register_device_override+0x98/0x170&#xA;    [&lt;000000001c0c89a8&gt;] rpmsg_ns_register_device+0x24/0x30&#xA;    [&lt;000000008bbf8fa2&gt;] rpmsg_probe+0x2e0/0x3ec&#xA;    [&lt;00000000e65a68df&gt;] virtio_dev_probe+0x1c0/0x280&#xA;    [&lt;00000000443331cc&gt;] really_probe+0xbc/0x2dc&#xA;    [&lt;00000000391064b1&gt;] __driver_probe_device+0x78/0xe0&#xA;    [&lt;00000000a41c9a5b&gt;] driver_probe_device+0xd8/0x160&#xA;    [&lt;000000009c3bd5df&gt;] __device_attach_driver+0xb8/0x140&#xA;    [&lt;0000000043cd7614&gt;] bus_for_each_drv+0x7c/0xd4&#xA;    [&lt;000000003b929a36&gt;] __device_attach+0x9c/0x19c&#xA;    [&lt;00000000a94e0ba8&gt;] device_initial_probe+0x14/0x20&#xA;    [&lt;000000003c999637&gt;] bus_probe_device+0xa0/0xac&#xA;CVE-2024-35823:In the Linux kernel, the following vulnerability has been resolved:&#xA;vt: fix unicode buffer corruption when deleting characters&#xA;This is the same issue that was fixed for the VGA text buffer in commit&#xA;39cdb68c64d8 (&#34;vt: fix memory overlapping when deleting chars in the&#xA;buffer&#34;). The cure is also the same i.e. replace memcpy() with memmove()&#xA;due to the overlaping buffers.&#xA;CVE-2024-36015:In the Linux kernel, the following vulnerability has been resolved:&#xA;ppdev: Add an error check in register_device&#xA;In register_device, the return value of ida_simple_get is unchecked,&#xA;in witch ida_simple_get will use an invalid index value.&#xA;To address this issue, index should be checked after ida_simple_get. When&#xA;the index value is abnormal, a warning message should be printed, the port&#xA;should be dropped, and the value should be recorded.&#xA;CVE-2024-35958:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ena: Fix incorrect descriptor free behavior&#xA;ENA has two types of TX queues:&#xA;- queues which only process TX packets arriving from the network stack&#xA;- queues which only process TX packets forwarded to it by XDP_REDIRECT&#xA;  or XDP_TX instructions&#xA;The ena_free_tx_bufs() cycles through all descriptors in a TX queue&#xA;and unmaps + frees every descriptor that hasn&#39;t been acknowledged yet&#xA;by the device (uncompleted TX transactions).&#xA;The function assumes that the processed TX queue is necessarily from&#xA;the first category listed above and ends up using napi_consume_skb()&#xA;for descriptors belonging to an XDP specific queue.&#xA;This patch solves a bug in which, in case of a VF reset, the&#xA;descriptors aren&#39;t freed correctly, leading to crashes.&#xA;CVE-2023-52789:In the Linux kernel, the following vulnerability has been resolved:&#xA;tty: vcc: Add check for kstrdup() in vcc_probe()&#xA;Add check for the return value of kstrdup() and return the error, if it&#xA;fails in order to avoid NULL pointer dereference.&#xA;CVE-2024-36898:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpiolib: cdev: fix uninitialised kfifo&#xA;If a line is requested with debounce, and that results in debouncing&#xA;in software, and the line is subsequently reconfigured to enable edge&#xA;detection then the allocation of the kfifo to contain edge events is&#xA;overlooked.  This results in events being written to and read from an&#xA;uninitialised kfifo.  Read events are returned to userspace.&#xA;Initialise the kfifo in the case where the software debounce is&#xA;already active.&#xA;CVE-2023-52808:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs&#xA;If init debugfs failed during device registration due to memory allocation&#xA;failure, debugfs_remove_recursive() is called, after which debugfs_dir is&#xA;not set to NULL. debugfs_remove_recursive() will be called again during&#xA;device removal. As a result, illegal pointer is accessed.&#xA;[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!&#xA;...&#xA;[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0&#xA;[ 1669.872669] pc : down_write+0x24/0x70&#xA;[ 1669.876315] lr : down_write+0x1c/0x70&#xA;[ 1669.879961] sp : ffff000036f53a30&#xA;[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8&#xA;[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000&#xA;[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270&#xA;[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8&#xA;[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310&#xA;[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10&#xA;[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000&#xA;[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870&#xA;[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228&#xA;[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0&#xA;[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10&#xA;[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff&#xA;[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00&#xA;[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000&#xA;[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001&#xA;[ 1669.962563] Call trace:&#xA;[ 1669.965000]  down_write+0x24/0x70&#xA;[ 1669.968301]  debugfs_remove_recursive+0x5c/0x1b0&#xA;[ 1669.972905]  hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]&#xA;[ 1669.978541]  hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]&#xA;[ 1669.984175]  pci_device_remove+0x48/0xd8&#xA;[ 1669.988082]  device_release_driver_internal+0x1b4/0x250&#xA;[ 1669.993282]  device_release_driver+0x28/0x38&#xA;[ 1669.997534]  pci_stop_bus_device+0x84/0xb8&#xA;[ 1670.001611]  pci_stop_and_remove_bus_device_locked+0x24/0x40&#xA;[ 1670.007244]  remove_store+0xfc/0x140&#xA;[ 1670.010802]  dev_attr_store+0x44/0x60&#xA;[ 1670.014448]  sysfs_kf_write+0x58/0x80&#xA;[ 1670.018095]  kernfs_fop_write+0xe8/0x1f0&#xA;[ 1670.022000]  __vfs_write+0x60/0x190&#xA;[ 1670.025472]  vfs_write+0xac/0x1c0&#xA;[ 1670.028771]  ksys_write+0x6c/0xd8&#xA;[ 1670.032071]  __arm64_sys_write+0x24/0x30&#xA;[ 1670.035977]  el0_svc_common+0x78/0x130&#xA;[ 1670.039710]  el0_svc_handler+0x38/0x78&#xA;[ 1670.043442]  el0_svc+0x8/0xc&#xA;To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().&#xA;CVE-2023-52774:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/dasd: protect device queue against concurrent access&#xA;In dasd_profile_start() the amount of requests on the device queue are&#xA;counted. The access to the device queue is unprotected against&#xA;concurrent access. With a lot of parallel I/O, especially with alias&#xA;devices enabled, the device queue can change while dasd_profile_start()&#xA;is accessing the queue. In the worst case this leads to a kernel panic&#xA;due to incorrect pointer accesses.&#xA;Fix this by taking the device lock before accessing the queue and&#xA;counting the requests. Additionally the check for a valid profile data&#xA;pointer can be done earlier to avoid unnecessary locking in a hot path.&#xA;CVE-2024-35950:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/client: Fully protect modes[] with dev-&gt;mode_config.mutex&#xA;The modes[] array contains pointers to modes on the connectors&#39;&#xA;mode lists, which are protected by dev-&gt;mode_config.mutex.&#xA;Thus we need to extend modes[] the same protection or by the&#xA;time we use it the elements may already be pointing to&#xA;freed/reused memory.&#xA;CVE-2024-35989:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: idxd: Fix oops during rmmod on single-CPU platforms&#xA;During the removal of the idxd driver, registered offline callback is&#xA;invoked as part of the clean up process. However, on systems with only&#xA;one CPU online, no valid target is available to migrate the&#xA;perf context, resulting in a kernel oops:&#xA;    BUG: unable to handle page fault for address: 000000000002a2b8&#xA;    #PF: supervisor write access in kernel mode&#xA;    #PF: error_code(0x0002) - not-present page&#xA;    PGD 1470e1067 P4D 0&#xA;    Oops: 0002 [#1] PREEMPT SMP NOPTI&#xA;    CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57&#xA;    Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023&#xA;    RIP: 0010:mutex_lock+0x2e/0x50&#xA;    ...&#xA;    Call Trace:&#xA;    &lt;TASK&gt;&#xA;    __die+0x24/0x70&#xA;    page_fault_oops+0x82/0x160&#xA;    do_user_addr_fault+0x65/0x6b0&#xA;    __pfx___rdmsr_safe_on_cpu+0x10/0x10&#xA;    exc_page_fault+0x7d/0x170&#xA;    asm_exc_page_fault+0x26/0x30&#xA;    mutex_lock+0x2e/0x50&#xA;    mutex_lock+0x1e/0x50&#xA;    perf_pmu_migrate_context+0x87/0x1f0&#xA;    perf_event_cpu_offline+0x76/0x90 [idxd]&#xA;    cpuhp_invoke_callback+0xa2/0x4f0&#xA;    __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]&#xA;    cpuhp_thread_fun+0x98/0x150&#xA;    smpboot_thread_fn+0x27/0x260&#xA;    smpboot_thread_fn+0x1af/0x260&#xA;    __pfx_smpboot_thread_fn+0x10/0x10&#xA;    kthread+0x103/0x140&#xA;    __pfx_kthread+0x10/0x10&#xA;    ret_from_fork+0x31/0x50&#xA;    __pfx_kthread+0x10/0x10&#xA;    ret_from_fork_asm+0x1b/0x30&#xA;    &lt;TASK&gt;&#xA;Fix the issue by preventing the migration of the perf context to an&#xA;invalid target.&#xA;CVE-2024-36906:In the Linux kernel, the following vulnerability has been resolved:&#xA;ARM: 9381/1: kasan: clear stale stack poison&#xA;We found below OOB crash:&#xA;[   33.452494] ==================================================================&#xA;[   33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec&#xA;[   33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0&#xA;[   33.455515]&#xA;[   33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O       6.1.25-mainline #1&#xA;[   33.456880] Hardware name: Generic DT based system&#xA;[   33.457555]  unwind_backtrace from show_stack+0x18/0x1c&#xA;[   33.458326]  show_stack from dump_stack_lvl+0x40/0x4c&#xA;[   33.459072]  dump_stack_lvl from print_report+0x158/0x4a4&#xA;[   33.459863]  print_report from kasan_report+0x9c/0x148&#xA;[   33.460616]  kasan_report from kasan_check_range+0x94/0x1a0&#xA;[   33.461424]  kasan_check_range from memset+0x20/0x3c&#xA;[   33.462157]  memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec&#xA;[   33.463064]  refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c&#xA;[   33.464181]  tick_nohz_idle_stop_tick from do_idle+0x264/0x354&#xA;[   33.465029]  do_idle from cpu_startup_entry+0x20/0x24&#xA;[   33.465769]  cpu_startup_entry from rest_init+0xf0/0xf4&#xA;[   33.466528]  rest_init from arch_post_acpi_subsys_init+0x0/0x18&#xA;[   33.467397]&#xA;[   33.467644] The buggy address belongs to stack of task swapper/0/0&#xA;[   33.468493]  and is located at offset 112 in frame:&#xA;[   33.469172]  refresh_cpu_vm_stats.constprop.0+0x0/0x2ec&#xA;[   33.469917]&#xA;[   33.470165] This frame has 2 objects:&#xA;[   33.470696]  [32, 76) &#39;global_zone_diff&#39;&#xA;[   33.470729]  [112, 276) &#39;global_node_diff&#39;&#xA;[   33.471294]&#xA;[   33.472095] The buggy address belongs to the physical page:&#xA;[   33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03&#xA;[   33.473944] flags: 0x1000(reserved|zone=0)&#xA;[   33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001&#xA;[   33.475656] raw: 00000000&#xA;[   33.476050] page dumped because: kasan: bad access detected&#xA;[   33.476816]&#xA;[   33.477061] Memory state around the buggy address:&#xA;[   33.477732]  c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;[   33.478630]  c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00&#xA;[   33.479526] &gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1&#xA;[   33.480415]                                                ^&#xA;[   33.481195]  c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3&#xA;[   33.482088]  c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00&#xA;[   33.482978] ==================================================================&#xA;We find the root cause of this OOB is that arm does not clear stale stack&#xA;poison in the case of cpuidle.&#xA;This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.&#xA;From cited commit [1] that explain the problem&#xA;Functions which the compiler has instrumented for KASAN place poison on&#xA;the stack shadow upon entry and remove this poison prior to returning.&#xA;In the case of cpuidle, CPUs exit the kernel a number of levels deep in&#xA;C code.  Any instrumented functions on this critical path will leave&#xA;portions of the stack shadow poisoned.&#xA;If CPUs lose context and return to the kernel via a cold path, we&#xA;restore a prior context saved in __cpu_suspend_enter are forgotten, and&#xA;we never remove the poison they placed in the stack shadow area by&#xA;functions calls between this and the actual exit of the kernel.&#xA;Thus, (depending on stackframe layout) subsequent calls to instrumented&#xA;functions may hit this stale poison, resulting in (spurious) KASAN&#xA;splats to the console.&#xA;To avoid this, clear any stale poison from the idle thread for a CPU&#xA;prior to bringing a CPU online.&#xA;From cited commit [2]&#xA;Extend to check for CONFIG_KASAN_STACK&#xA;[1] commit 0d97e6d8024c (&#34;arm64: kasan: clear stale stack poison&#34;)&#xA;[2] commit d56a9ef84bd0 (&#34;kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK&#34;)&#xA;CVE-2023-52799:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix array-index-out-of-bounds in dbFindLeaf&#xA;Currently while searching for dmtree_t for sufficient free blocks there&#xA;is an array out of bounds while getting element in tp-&gt;dm_stree. To add&#xA;the required check for out of bound we first need to determine the type&#xA;of dmtree. Thus added an extra parameter to dbFindLeaf so that the type&#xA;of tree can be determined and the required check can be applied.&#xA;CVE-2023-52746:In the Linux kernel, the following vulnerability has been resolved:&#xA;xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()&#xA;  int type = nla_type(nla);&#xA;  if (type &gt; XFRMA_MAX) {&#xA;            return -EOPNOTSUPP;&#xA;  }&#xA;@type is then used as an array index and can be used&#xA;as a Spectre v1 gadget.&#xA;  if (nla_len(nla) &lt; compat_policy[type].len) {&#xA;array_index_nospec() can be used to prevent leaking&#xA;content of kernel memory to malicious users.&#xA;CVE-2021-47558:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: stmmac: Disable Tx queues when reconfiguring the interface&#xA;The Tx queues were not disabled in situations where the driver needed to&#xA;stop the interface to apply a new configuration. This could result in a&#xA;kernel panic when doing any of the 3 following actions:&#xA;* reconfiguring the number of queues (ethtool -L)&#xA;* reconfiguring the size of the ring buffers (ethtool -G)&#xA;* installing/removing an XDP program (ip l set dev ethX xdp)&#xA;Prevent the panic by making sure netif_tx_disable is called when stopping&#xA;an interface.&#xA;Without this patch, the following kernel panic can be observed when doing&#xA;any of the actions above:&#xA;Unable to handle kernel paging request at virtual address ffff80001238d040&#xA;[....]&#xA; Call trace:&#xA;  dwmac4_set_addr+0x8/0x10&#xA;  dev_hard_start_xmit+0xe4/0x1ac&#xA;  sch_direct_xmit+0xe8/0x39c&#xA;  __dev_queue_xmit+0x3ec/0xaf0&#xA;  dev_queue_xmit+0x14/0x20&#xA;[...]&#xA;[ end trace 0000000000000002 ]---&#xA;CVE-2022-48689:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: TX zerocopy should not sense pfmemalloc status&#xA;We got a recent syzbot report [1] showing a possible misuse&#xA;of pfmemalloc page status in TCP zerocopy paths.&#xA;Indeed, for pages coming from user space or other layers,&#xA;using page_is_pfmemalloc() is moot, and possibly could give&#xA;false positives.&#xA;There has been attempts to make page_is_pfmemalloc() more robust,&#xA;but not using it in the first place in this context is probably better,&#xA;removing cpu cycles.&#xA;Note to stable teams :&#xA;You need to backport 84ce071e38a6 (&#34;net: introduce&#xA;__skb_fill_page_desc_noacc&#34;) as a prereq.&#xA;Race is more probable after commit c07aea3ef4d4&#xA;(&#34;mm: add a signature in struct page&#34;) because page_is_pfmemalloc()&#xA;is now using low order bit from page-&gt;lru.next, which can change&#xA;more often than page-&gt;index.&#xA;Low order bit should never be set for lru.next (when used as an anchor&#xA;in LRU list), so KCSAN report is mostly a false positive.&#xA;Backporting to older kernel versions seems not necessary.&#xA;[1]&#xA;BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag&#xA;write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:&#xA;__list_add include/linux/list.h:73 [inline]&#xA;list_add include/linux/list.h:88 [inline]&#xA;lruvec_add_folio include/linux/mm_inline.h:105 [inline]&#xA;lru_add_fn+0x440/0x520 mm/swap.c:228&#xA;folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246&#xA;folio_batch_add_and_move mm/swap.c:263 [inline]&#xA;folio_add_lru+0xf1/0x140 mm/swap.c:490&#xA;filemap_add_folio+0xf8/0x150 mm/filemap.c:948&#xA;__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981&#xA;pagecache_get_page+0x26/0x190 mm/folio-compat.c:104&#xA;grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116&#xA;ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988&#xA;generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738&#xA;ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270&#xA;ext4_file_write_iter+0x2e3/0x1210&#xA;call_write_iter include/linux/fs.h:2187 [inline]&#xA;new_sync_write fs/read_write.c:491 [inline]&#xA;vfs_write+0x468/0x760 fs/read_write.c:578&#xA;ksys_write+0xe8/0x1a0 fs/read_write.c:631&#xA;__do_sys_write fs/read_write.c:643 [inline]&#xA;__se_sys_write fs/read_write.c:640 [inline]&#xA;__x64_sys_write+0x3e/0x50 fs/read_write.c:640&#xA;do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80&#xA;entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:&#xA;page_is_pfmemalloc include/linux/mm.h:1740 [inline]&#xA;__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]&#xA;skb_fill_page_desc include/linux/skbuff.h:2443 [inline]&#xA;tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018&#xA;do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075&#xA;tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]&#xA;tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150&#xA;inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833&#xA;kernel_sendpage+0x184/0x300 net/socket.c:3561&#xA;sock_sendpage+0x5a/0x70 net/socket.c:1054&#xA;pipe_to_sendpage+0x128/0x160 fs/splice.c:361&#xA;splice_from_pipe_feed fs/splice.c:415 [inline]&#xA;__splice_from_pipe+0x222/0x4d0 fs/splice.c:559&#xA;splice_from_pipe fs/splice.c:594 [inline]&#xA;generic_splice_sendpage+0x89/0xc0 fs/splice.c:743&#xA;do_splice_from fs/splice.c:764 [inline]&#xA;direct_splice_actor+0x80/0xa0 fs/splice.c:931&#xA;splice_direct_to_actor+0x305/0x620 fs/splice.c:886&#xA;do_splice_direct+0xfb/0x180 fs/splice.c:974&#xA;do_sendfile+0x3bf/0x910 fs/read_write.c:1249&#xA;__do_sys_sendfile64 fs/read_write.c:1317 [inline]&#xA;__se_sys_sendfile64 fs/read_write.c:1303 [inline]&#xA;__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303&#xA;do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80&#xA;entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;value changed: 0x0000000000000000 -&gt; 0xffffea0004a1d288&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022&#xA;CVE-2023-52752:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix use-after-free bug in cifs_debug_data_proc_show()&#xA;Skip SMB sessions that are being teared down&#xA;(e.g. @ses-&gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()&#xA;to avoid use-after-free in @ses.&#xA;This fixes the following GPF when reading from /proc/fs/cifs/DebugData&#xA;while mounting and umounting&#xA;  [ 816.251274] general protection fault, probably for non-canonical&#xA;  address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI&#xA;  ...&#xA;  [  816.260138] Call Trace:&#xA;  [  816.260329]  &lt;TASK&gt;&#xA;  [  816.260499]  ? die_addr+0x36/0x90&#xA;  [  816.260762]  ? exc_general_protection+0x1b3/0x410&#xA;  [  816.261126]  ? asm_exc_general_protection+0x26/0x30&#xA;  [  816.261502]  ? cifs_debug_tcon+0xbd/0x240 [cifs]&#xA;  [  816.261878]  ? cifs_debug_tcon+0xab/0x240 [cifs]&#xA;  [  816.262249]  cifs_debug_data_proc_show+0x516/0xdb0 [cifs]&#xA;  [  816.262689]  ? seq_read_iter+0x379/0x470&#xA;  [  816.262995]  seq_read_iter+0x118/0x470&#xA;  [  816.263291]  proc_reg_read_iter+0x53/0x90&#xA;  [  816.263596]  ? srso_alias_return_thunk+0x5/0x7f&#xA;  [  816.263945]  vfs_read+0x201/0x350&#xA;  [  816.264211]  ksys_read+0x75/0x100&#xA;  [  816.264472]  do_syscall_64+0x3f/0x90&#xA;  [  816.264750]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;  [  816.265135] RIP: 0033:0x7fd5e669d381&#xA;CVE-2024-35895:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf, sockmap: Prevent lock inversion deadlock in map delete elem&#xA;syzkaller started using corpuses where a BPF tracing program deletes&#xA;elements from a sockmap/sockhash map. Because BPF tracing programs can be&#xA;invoked from any interrupt context, locks taken during a map_delete_elem&#xA;operation must be hardirq-safe. Otherwise a deadlock due to lock inversion&#xA;is possible, as reported by lockdep:&#xA;       CPU0                    CPU1&#xA;       ----                    ----&#xA;  lock(&amp;htab-&gt;buckets[i].lock);&#xA;                               local_irq_disable();&#xA;                               lock(&amp;host-&gt;lock);&#xA;                               lock(&amp;htab-&gt;buckets[i].lock);&#xA;  &lt;Interrupt&gt;&#xA;    lock(&amp;host-&gt;lock);&#xA;Locks in sockmap are hardirq-unsafe by design. We expects elements to be&#xA;deleted from sockmap/sockhash only in task (normal) context with interrupts&#xA;enabled, or in softirq context.&#xA;Detect when map_delete_elem operation is invoked from a context which is&#xA;_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an&#xA;error.&#xA;Note that map updates are not affected by this issue. BPF verifier does not&#xA;allow updating sockmap/sockhash from a BPF tracing program today.&#xA;CVE-2024-35896:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: validate user input for expected length&#xA;I got multiple syzbot reports showing old bugs exposed&#xA;by BPF after commit 20f2505fb436 (&#34;bpf: Try to avoid kzalloc&#xA;in cgroup/{s,g}etsockopt&#34;)&#xA;setsockopt() @optlen argument should be taken into account&#xA;before copying data.&#xA; BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627&#xA;Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238&#xA;CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0x169/0x550 mm/kasan/report.c:488&#xA;  kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA;  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189&#xA;  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105&#xA;  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]&#xA;  copy_from_sockptr include/linux/sockptr.h:55 [inline]&#xA;  do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]&#xA;  do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627&#xA;  nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101&#xA;  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311&#xA;  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334&#xA;  __do_sys_setsockopt net/socket.c:2343 [inline]&#xA;  __se_sys_setsockopt net/socket.c:2340 [inline]&#xA;  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340&#xA; do_syscall_64+0xfb/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x72/0x7a&#xA;RIP: 0033:0x7fd22067dde9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036&#xA;RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9&#xA;RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003&#xA;RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8&#xA; &lt;/TASK&gt;&#xA;Allocated by task 7238:&#xA;  kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]&#xA;  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387&#xA;  kasan_kmalloc include/linux/kasan.h:211 [inline]&#xA;  __do_kmalloc_node mm/slub.c:4069 [inline]&#xA;  __kmalloc_noprof+0x200/0x410 mm/slub.c:4082&#xA;  kmalloc_noprof include/linux/slab.h:664 [inline]&#xA;  __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869&#xA;  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293&#xA;  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334&#xA;  __do_sys_setsockopt net/socket.c:2343 [inline]&#xA;  __se_sys_setsockopt net/socket.c:2340 [inline]&#xA;  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340&#xA; do_syscall_64+0xfb/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x72/0x7a&#xA;The buggy address belongs to the object at ffff88802cd73da0&#xA; which belongs to the cache kmalloc-8 of size 8&#xA;The buggy address is located 0 bytes inside of&#xA; allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)&#xA;The buggy address belongs to the physical page:&#xA;page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73&#xA;flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)&#xA;page_type: 0xffffefff(slab)&#xA;raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122&#xA;raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00&#xA;---truncated---&#xA;CVE-2024-36964:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/9p: only translate RWX permissions for plain 9P2000&#xA;Garbage in plain 9P2000&#39;s perm bits is allowed through, which causes it&#xA;to be able to set (among others) the suid bit. This was presumably not&#xA;the intent since the unix extended bits are handled explicitly and&#xA;conditionally on .u.&#xA;CVE-2024-27399:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout&#xA;There is a race condition between l2cap_chan_timeout() and&#xA;l2cap_chan_del(). When we use l2cap_chan_del() to delete the&#xA;channel, the chan-&gt;conn will be set to null. But the conn could&#xA;be dereferenced again in the mutex_lock() of l2cap_chan_timeout().&#xA;As a result the null pointer dereference bug will happen. The&#xA;KASAN report triggered by POC is shown below:&#xA;[  472.074580] ==================================================================&#xA;[  472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0&#xA;[  472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7&#xA;[  472.075308]&#xA;[  472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36&#xA;[  472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4&#xA;[  472.075308] Workqueue: events l2cap_chan_timeout&#xA;[  472.075308] Call Trace:&#xA;[  472.075308]  &lt;TASK&gt;&#xA;[  472.075308]  dump_stack_lvl+0x137/0x1a0&#xA;[  472.075308]  print_report+0x101/0x250&#xA;[  472.075308]  ? __virt_addr_valid+0x77/0x160&#xA;[  472.075308]  ? mutex_lock+0x68/0xc0&#xA;[  472.075308]  kasan_report+0x139/0x170&#xA;[  472.075308]  ? mutex_lock+0x68/0xc0&#xA;[  472.075308]  kasan_check_range+0x2c3/0x2e0&#xA;[  472.075308]  mutex_lock+0x68/0xc0&#xA;[  472.075308]  l2cap_chan_timeout+0x181/0x300&#xA;[  472.075308]  process_one_work+0x5d2/0xe00&#xA;[  472.075308]  worker_thread+0xe1d/0x1660&#xA;[  472.075308]  ? pr_cont_work+0x5e0/0x5e0&#xA;[  472.075308]  kthread+0x2b7/0x350&#xA;[  472.075308]  ? pr_cont_work+0x5e0/0x5e0&#xA;[  472.075308]  ? kthread_blkcg+0xd0/0xd0&#xA;[  472.075308]  ret_from_fork+0x4d/0x80&#xA;[  472.075308]  ? kthread_blkcg+0xd0/0xd0&#xA;[  472.075308]  ret_from_fork_asm+0x11/0x20&#xA;[  472.075308]  &lt;/TASK&gt;&#xA;[  472.075308] ==================================================================&#xA;[  472.094860] Disabling lock debugging due to kernel taint&#xA;[  472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158&#xA;[  472.096136] #PF: supervisor write access in kernel mode&#xA;[  472.096136] #PF: error_code(0x0002) - not-present page&#xA;[  472.096136] PGD 0 P4D 0&#xA;[  472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI&#xA;[  472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G    B              6.9.0-rc5-00356-g78c0094a146b #36&#xA;[  472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4&#xA;[  472.096136] Workqueue: events l2cap_chan_timeout&#xA;[  472.096136] RIP: 0010:mutex_lock+0x88/0xc0&#xA;[  472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88&#xA;[  472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246&#xA;[  472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865&#xA;[  472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78&#xA;[  472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f&#xA;[  472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000&#xA;[  472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00&#xA;[  472.096136] FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000&#xA;[  472.096136] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0&#xA;[  472.096136] Call Trace:&#xA;[  472.096136]  &lt;TASK&gt;&#xA;[  472.096136]  ? __die_body+0x8d/0xe0&#xA;[  472.096136]  ? page_fault_oops+0x6b8/0x9a0&#xA;[  472.096136]  ? kernelmode_fixup_or_oops+0x20c/0x2a0&#xA;[  472.096136]  ? do_user_addr_fault+0x1027/0x1340&#xA;[  472.096136]  ? _printk+0x7a/0xa0&#xA;[  472.096136]  ? mutex_lock+0x68/0xc0&#xA;[  472.096136]  ? add_taint+0x42/0xd0&#xA;[  472.096136]  ? exc_page_fault+0x6a/0x1b0&#xA;[  472.096136]  ? asm_exc_page_fault+0x26/0x30&#xA;[  472.096136]  ? mutex_lock+0x75/0xc0&#xA;[  472.096136]  ? mutex_lock+0x88/0xc0&#xA;[  472.096136]  ? mutex_lock+0x75/0xc0&#xA;[  472.096136]  l2cap_chan_timeo&#xA;---truncated---&#xA;CVE-2024-35855:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update&#xA;The rule activity update delayed work periodically traverses the list of&#xA;configured rules and queries their activity from the device.&#xA;As part of this task it accesses the entry pointed by &#39;ventry-&gt;entry&#39;,&#xA;but this entry can be changed concurrently by the rehash delayed work,&#xA;leading to a use-after-free [1].&#xA;Fix by closing the race and perform the activity query under the&#xA;&#39;vregion-&gt;lock&#39; mutex.&#xA;[1]&#xA;BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140&#xA;Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181&#xA;CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0xc6/0x120&#xA; print_report+0xce/0x670&#xA; kasan_report+0xd7/0x110&#xA; mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140&#xA; mlxsw_sp_acl_rule_activity_update_work+0x219/0x400&#xA; process_one_work+0x8eb/0x19b0&#xA; worker_thread+0x6c9/0xf70&#xA; kthread+0x2c9/0x3b0&#xA; ret_from_fork+0x4d/0x80&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;Allocated by task 1039:&#xA; kasan_save_stack+0x33/0x60&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0x8f/0xa0&#xA; __kmalloc+0x19c/0x360&#xA; mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0&#xA; mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300&#xA; process_one_work+0x8eb/0x19b0&#xA; worker_thread+0x6c9/0xf70&#xA; kthread+0x2c9/0x3b0&#xA; ret_from_fork+0x4d/0x80&#xA; ret_from_fork_asm+0x1a/0x30&#xA;Freed by task 1039:&#xA; kasan_save_stack+0x33/0x60&#xA; kasan_save_track+0x14/0x30&#xA; kasan_save_free_info+0x3b/0x60&#xA; poison_slab_object+0x102/0x170&#xA; __kasan_slab_free+0x14/0x30&#xA; kfree+0xc1/0x290&#xA; mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300&#xA; process_one_work+0x8eb/0x19b0&#xA; worker_thread+0x6c9/0xf70&#xA; kthread+0x2c9/0x3b0&#xA; ret_from_fork+0x4d/0x80&#xA; ret_from_fork_asm+0x1a/0x30&#xA;CVE-2024-35888:In the Linux kernel, the following vulnerability has been resolved:&#xA;erspan: make sure erspan_base_hdr is present in skb-&gt;head&#xA;syzbot reported a problem in ip6erspan_rcv() [1]&#xA;Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make&#xA;sure erspan_base_hdr is present in skb linear part (skb-&gt;head)&#xA;before getting @ver field from it.&#xA;Add the missing pskb_may_pull() calls.&#xA;v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()&#xA;    because skb-&gt;head might have changed.&#xA;[1]&#xA; BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]&#xA; BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]&#xA; BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]&#xA; BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610&#xA;  pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]&#xA;  pskb_may_pull include/linux/skbuff.h:2756 [inline]&#xA;  ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]&#xA;  gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610&#xA;  ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438&#xA;  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492&#xA;  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586&#xA;  dst_input include/net/dst.h:460 [inline]&#xA;  ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310&#xA;  __netif_receive_skb_one_core net/core/dev.c:5538 [inline]&#xA;  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652&#xA;  netif_receive_skb_internal net/core/dev.c:5738 [inline]&#xA;  netif_receive_skb+0x58/0x660 net/core/dev.c:5798&#xA;  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549&#xA;  tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002&#xA;  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA;  call_write_iter include/linux/fs.h:2108 [inline]&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0xb63/0x1520 fs/read_write.c:590&#xA;  ksys_write+0x20f/0x4c0 fs/read_write.c:643&#xA;  __do_sys_write fs/read_write.c:655 [inline]&#xA;  __se_sys_write fs/read_write.c:652 [inline]&#xA;  __x64_sys_write+0x93/0xe0 fs/read_write.c:652&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:3804 [inline]&#xA;  slab_alloc_node mm/slub.c:3845 [inline]&#xA;  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577&#xA;  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668&#xA;  alloc_skb include/linux/skbuff.h:1318 [inline]&#xA;  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504&#xA;  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795&#xA;  tun_alloc_skb drivers/net/tun.c:1525 [inline]&#xA;  tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846&#xA;  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA;  call_write_iter include/linux/fs.h:2108 [inline]&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0xb63/0x1520 fs/read_write.c:590&#xA;  ksys_write+0x20f/0x4c0 fs/read_write.c:643&#xA;  __do_sys_write fs/read_write.c:655 [inline]&#xA;  __se_sys_write fs/read_write.c:652 [inline]&#xA;  __x64_sys_write+0x93/0xe0 fs/read_write.c:652&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0&#xA;CVE-2023-52677:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: Check if the code to patch lies in the exit section&#xA;Otherwise we fall through to vmalloc_to_page() which panics since the&#xA;address does not lie in the vmalloc region.&#xA;CVE-2023-52800:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath11k: fix htt pktlog locking&#xA;The ath11k active pdevs are protected by RCU but the htt pktlog handling&#xA;code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a&#xA;read-side critical section.&#xA;Mark the code in question as an RCU read-side critical section to avoid&#xA;any potential use-after-free issues.&#xA;Compile tested only.&#xA;CVE-2024-35790:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: typec: altmodes/displayport: create sysfs nodes as driver&#39;s default device attribute group&#xA;The DisplayPort driver&#39;s sysfs nodes may be present to the userspace before&#xA;typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that&#xA;a sysfs read can trigger a NULL pointer error by deferencing dp-&gt;hpd in&#xA;hpd_show or dp-&gt;lock in pin_assignment_show, as dev_get_drvdata() returns&#xA;NULL in those cases.&#xA;Remove manual sysfs node creation in favor of adding attribute group as&#xA;default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is&#xA;not used here otherwise the path to the sysfs nodes is no longer compliant&#xA;with the ABI.&#xA;CVE-2024-27402:In the Linux kernel, the following vulnerability has been resolved:&#xA;phonet/pep: fix racy skb_queue_empty() use&#xA;The receive queues are protected by their respective spin-lock, not&#xA;the socket lock. This could lead to skb_peek() unexpectedly&#xA;returning NULL or a pointer to an already dequeued socket buffer.&#xA;CVE-2023-52798:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath11k: fix dfs radar event locking&#xA;The ath11k active pdevs are protected by RCU but the DFS radar event&#xA;handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a&#xA;read-side critical section.&#xA;Mark the code in question as an RCU read-side critical section to avoid&#xA;any potential use-after-free issues.&#xA;Compile tested only.&#xA;CVE-2024-35854:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash&#xA;The rehash delayed work migrates filters from one region to another&#xA;according to the number of available credits.&#xA;The migrated from region is destroyed at the end of the work if the&#xA;number of credits is non-negative as the assumption is that this is&#xA;indicative of migration being complete. This assumption is incorrect as&#xA;a non-negative number of credits can also be the result of a failed&#xA;migration.&#xA;The destruction of a region that still has filters referencing it can&#xA;result in a use-after-free [1].&#xA;Fix by not destroying the region if migration failed.&#xA;[1]&#xA;BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230&#xA;Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858&#xA;CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G        W          6.9.0-rc2-custom-00782-gf2275c2157d8 #5&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0xc6/0x120&#xA; print_report+0xce/0x670&#xA; kasan_report+0xd7/0x110&#xA; mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230&#xA; mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70&#xA; mlxsw_sp_acl_atcam_entry_del+0x81/0x210&#xA; mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300&#xA; process_one_work+0x8eb/0x19b0&#xA; worker_thread+0x6c9/0xf70&#xA; kthread+0x2c9/0x3b0&#xA; ret_from_fork+0x4d/0x80&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;Allocated by task 174:&#xA; kasan_save_stack+0x33/0x60&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0x8f/0xa0&#xA; __kmalloc+0x19c/0x360&#xA; mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300&#xA; process_one_work+0x8eb/0x19b0&#xA; worker_thread+0x6c9/0xf70&#xA; kthread+0x2c9/0x3b0&#xA; ret_from_fork+0x4d/0x80&#xA; ret_from_fork_asm+0x1a/0x30&#xA;Freed by task 7:&#xA; kasan_save_stack+0x33/0x60&#xA; kasan_save_track+0x14/0x30&#xA; kasan_save_free_info+0x3b/0x60&#xA; poison_slab_object+0x102/0x170&#xA; __kasan_slab_free+0x14/0x30&#xA; kfree+0xc1/0x290&#xA; mlxsw_sp_acl_tcam_region_destroy+0x272/0x310&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300&#xA; process_one_work+0x8eb/0x19b0&#xA; worker_thread+0x6c9/0xf70&#xA; kthread+0x2c9/0x3b0&#xA; ret_from_fork+0x4d/0x80&#xA; ret_from_fork_asm+0x1a/0x30&#xA;CVE-2024-36021:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hns3: fix kernel crash when devlink reload during pf initialization&#xA;The devlink reload process will access the hardware resources,&#xA;but the register operation is done before the hardware is initialized.&#xA;So, processing the devlink reload during initialization may lead to kernel&#xA;crash. This patch fixes this by taking devl_lock during initialization.&#xA;CVE-2024-36900:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hns3: fix kernel crash when devlink reload during initialization&#xA;The devlink reload process will access the hardware resources,&#xA;but the register operation is done before the hardware is initialized.&#xA;So, processing the devlink reload during initialization may lead to kernel&#xA;crash.&#xA;This patch fixes this by registering the devlink after&#xA;hardware initialization.&#xA;CVE-2024-36017:In the Linux kernel, the following vulnerability has been resolved:&#xA;rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation&#xA;Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a&#xA;struct ifla_vf_vlan_info so the size of such attribute needs to be at least&#xA;of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.&#xA;The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)&#xA;which is less than sizeof(struct ifla_vf_vlan_info) so this validation&#xA;is not enough and a too small attribute might be cast to a&#xA;struct ifla_vf_vlan_info, this might result in an out of bands&#xA;read access when accessing the saved (casted) entry in ivvl.&#xA;CVE-2024-35853:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix memory leak during rehash&#xA;The rehash delayed work migrates filters from one region to another.&#xA;This is done by iterating over all chunks (all the filters with the same&#xA;priority) in the region and in each chunk iterating over all the&#xA;filters.&#xA;If the migration fails, the code tries to migrate the filters back to&#xA;the old region. However, the rollback itself can also fail in which case&#xA;another migration will be erroneously performed. Besides the fact that&#xA;this ping pong is not a very good idea, it also creates a problem.&#xA;Each virtual chunk references two chunks: The currently used one&#xA;(&#39;vchunk-&gt;chunk&#39;) and a backup (&#39;vchunk-&gt;chunk2&#39;). During migration the&#xA;first holds the chunk we want to migrate filters to and the second holds&#xA;the chunk we are migrating filters from.&#xA;The code currently assumes - but does not verify - that the backup chunk&#xA;does not exist (NULL) if the currently used chunk does not reference the&#xA;target region. This assumption breaks when we are trying to rollback a&#xA;rollback, resulting in the backup chunk being overwritten and leaked&#xA;[1].&#xA;Fix by not rolling back a failed rollback and add a warning to avoid&#xA;future cases.&#xA;[1]&#xA;WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20&#xA;Modules linked in:&#xA;CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G        W          6.9.0-rc2-custom-00784-gc6a05c468a0b #14&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work&#xA;RIP: 0010:parman_destroy+0x17/0x20&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; mlxsw_sp_acl_atcam_region_fini+0x19/0x60&#xA; mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470&#xA; process_one_work+0x151/0x370&#xA; worker_thread+0x2cb/0x3e0&#xA; kthread+0xd0/0x100&#xA; ret_from_fork+0x34/0x50&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;CVE-2024-35910:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: properly terminate timers for kernel sockets&#xA;We had various syzbot reports about tcp timers firing after&#xA;the corresponding netns has been dismantled.&#xA;Fortunately Josef Bacik could trigger the issue more often,&#xA;and could test a patch I wrote two years ago.&#xA;When TCP sockets are closed, we call inet_csk_clear_xmit_timers()&#xA;to &#39;stop&#39; the timers.&#xA;inet_csk_clear_xmit_timers() can be called from any context,&#xA;including when socket lock is held.&#xA;This is the reason it uses sk_stop_timer(), aka del_timer().&#xA;This means that ongoing timers might finish much later.&#xA;For user sockets, this is fine because each running timer&#xA;holds a reference on the socket, and the user socket holds&#xA;a reference on the netns.&#xA;For kernel sockets, we risk that the netns is freed before&#xA;timer can complete, because kernel sockets do not hold&#xA;reference on the netns.&#xA;This patch adds inet_csk_clear_xmit_timers_sync() function&#xA;that using sk_stop_timer_sync() to make sure all timers&#xA;are terminated before the kernel socket is released.&#xA;Modules using kernel sockets close them in their netns exit()&#xA;handler.&#xA;Also add sock_not_owned_by_me() helper to get LOCKDEP&#xA;support : inet_csk_clear_xmit_timers_sync() must not be called&#xA;while socket lock is held.&#xA;It is very possible we can revert in the future commit&#xA;3a58f13a881e (&#34;net: rds: acquire refcount on TCP sockets&#34;)&#xA;which attempted to solve the issue in rds only.&#xA;(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)&#xA;We probably can remove the check_net() tests from&#xA;tcp_out_of_resources() and __tcp_close() in the future.&#xA;CVE-2024-35937:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: cfg80211: check A-MSDU format more carefully&#xA;If it looks like there&#39;s another subframe in the A-MSDU&#xA;but the header isn&#39;t fully there, we can end up reading&#xA;data out of bounds, only to discard later. Make this a&#xA;bit more careful and check if the subframe header can&#xA;even be present.&#xA;CVE-2024-35925:In the Linux kernel, the following vulnerability has been resolved:&#xA;block: prevent division by zero in blk_rq_stat_sum()&#xA;The expression dst-&gt;nr_samples + src-&gt;nr_samples may&#xA;have zero value on overflow. It is necessary to add&#xA;a check to avoid division by zero.&#xA;Found by Linux Verification Center (linuxtesting.org) with Svace.&#xA;CVE-2024-35821:In the Linux kernel, the following vulnerability has been resolved:&#xA;ubifs: Set page uptodate in the correct place&#xA;Page cache reads are lockless, so setting the freshly allocated page&#xA;uptodate before we&#39;ve overwritten it with the data it&#39;s supposed to have&#xA;in it will allow a simultaneous reader to see old data.  Move the call&#xA;to SetPageUptodate into ubifs_write_end(), which is after we copied the&#xA;new data into the page.&#xA;CVE-2024-36029:In the Linux kernel, the following vulnerability has been resolved:&#xA;mmc: sdhci-msm: pervent access to suspended controller&#xA;Generic sdhci code registers LED device and uses host-&gt;runtime_suspended&#xA;flag to protect access to it. The sdhci-msm driver doesn&#39;t set this flag,&#xA;which causes a crash when LED is accessed while controller is runtime&#xA;suspended. Fix this by setting the flag correctly.&#xA;CVE-2023-52739:In the Linux kernel, the following vulnerability has been resolved:&#xA;Fix page corruption caused by racy check in __free_pages&#xA;When we upgraded our kernel, we started seeing some page corruption like&#xA;the following consistently:&#xA;  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca&#xA;  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca&#xA;  flags: 0x17ffffc0000000()&#xA;  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000&#xA;  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000&#xA;  page dumped because: nonzero mapcount&#xA;  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1&#xA;  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016&#xA;  Call Trace:&#xA;   dump_stack+0x74/0x96&#xA;   bad_page.cold+0x63/0x94&#xA;   check_new_page_bad+0x6d/0x80&#xA;   rmqueue+0x46e/0x970&#xA;   get_page_from_freelist+0xcb/0x3f0&#xA;   ? _cond_resched+0x19/0x40&#xA;   __alloc_pages_nodemask+0x164/0x300&#xA;   alloc_pages_current+0x87/0xf0&#xA;   skb_page_frag_refill+0x84/0x110&#xA;   ...&#xA;Sometimes, it would also show up as corruption in the free list pointer&#xA;and cause crashes.&#xA;After bisecting the issue, we found the issue started from commit&#xA;e320d3012d25 (&#34;mm/page_alloc.c: fix freeing non-compound pages&#34;):&#xA;&#x9;if (put_page_testzero(page))&#xA;&#x9;&#x9;free_the_page(page, order);&#xA;&#x9;else if (!PageHead(page))&#xA;&#x9;&#x9;while (order-- &gt; 0)&#xA;&#x9;&#x9;&#x9;free_the_page(page + (1 &lt;&lt; order), order);&#xA;So the problem is the check PageHead is racy because at this point we&#xA;already dropped our reference to the page.  So even if we came in with&#xA;compound page, the page can already be freed and PageHead can return&#xA;false and we will end up freeing all the tail pages causing double free.&#xA;CVE-2024-35887:In the Linux kernel, the following vulnerability has been resolved:&#xA;ax25: fix use-after-free bugs caused by ax25_ds_del_timer&#xA;When the ax25 device is detaching, the ax25_dev_device_down()&#xA;calls ax25_ds_del_timer() to cleanup the slave_timer. When&#xA;the timer handler is running, the ax25_ds_del_timer() that&#xA;calls del_timer() in it will return directly. As a result,&#xA;the use-after-free bugs could happen, one of the scenarios&#xA;is shown below:&#xA;      (Thread 1)          |      (Thread 2)&#xA;                          | ax25_ds_timeout()&#xA;ax25_dev_device_down()    |&#xA;  ax25_ds_del_timer()     |&#xA;    del_timer()           |&#xA;  ax25_dev_put() //FREE   |&#xA;                          |  ax25_dev-&gt; //USE&#xA;In order to mitigate bugs, when the device is detaching, use&#xA;timer_shutdown_sync() to stop the timer.&#xA;CVE-2024-36904:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().&#xA;Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()&#xA;with nice analysis.&#xA;Since commit ec94c2696f0b (&#34;tcp/dccp: avoid one atomic operation for&#xA;timewait hashdance&#34;), inet_twsk_hashdance() sets TIME-WAIT socket&#39;s&#xA;sk_refcnt after putting it into ehash and releasing the bucket lock.&#xA;Thus, there is a small race window where other threads could try to&#xA;reuse the port during connect() and call sock_hold() in tcp_twsk_unique()&#xA;for the TIME-WAIT socket with zero refcnt.&#xA;If that happens, the refcnt taken by tcp_twsk_unique() is overwritten&#xA;and sock_put() will cause underflow, triggering a real use-after-free&#xA;somewhere else.&#xA;To avoid the use-after-free, we need to use refcount_inc_not_zero() in&#xA;tcp_twsk_unique() and give up on reusing the port if it returns false.&#xA;[0]:&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110&#xA;CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1&#xA;Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023&#xA;RIP: 0010:refcount_warn_saturate+0xe5/0x110&#xA;Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff &lt;0f&gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8&#xA;RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027&#xA;RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0&#xA;RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0&#xA;R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84&#xA;R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0&#xA;FS:  00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? refcount_warn_saturate+0xe5/0x110&#xA; ? __warn+0x81/0x130&#xA; ? refcount_warn_saturate+0xe5/0x110&#xA; ? report_bug+0x171/0x1a0&#xA; ? refcount_warn_saturate+0xe5/0x110&#xA; ? handle_bug+0x3c/0x80&#xA; ? exc_invalid_op+0x17/0x70&#xA; ? asm_exc_invalid_op+0x1a/0x20&#xA; ? refcount_warn_saturate+0xe5/0x110&#xA; tcp_twsk_unique+0x186/0x190&#xA; __inet_check_established+0x176/0x2d0&#xA; __inet_hash_connect+0x74/0x7d0&#xA; ? __pfx___inet_check_established+0x10/0x10&#xA; tcp_v4_connect+0x278/0x530&#xA; __inet_stream_connect+0x10f/0x3d0&#xA; inet_stream_connect+0x3a/0x60&#xA; __sys_connect+0xa8/0xd0&#xA; __x64_sys_connect+0x18/0x20&#xA; do_syscall_64+0x83/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x78/0x80&#xA;RIP: 0033:0x7f62c11a885d&#xA;Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48&#xA;RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a&#xA;RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d&#xA;RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003&#xA;RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0&#xA;R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0&#xA; &lt;/TASK&gt;&#xA;CVE-2024-36889:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: ensure snd_nxt is properly initialized on connect&#xA;Christoph reported a splat hinting at a corrupted snd_una:&#xA;  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005&#xA;  Modules linked in:&#xA;  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014&#xA;  Workqueue: events mptcp_worker&#xA;  RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005&#xA;  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8&#xA;  &#x9;8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe&#xA;  &#x9;&lt;0f&gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9&#xA;  RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293&#xA;  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4&#xA;  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001&#xA;  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000&#xA;  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000&#xA;  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000&#xA;  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]&#xA;   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]&#xA;   __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615&#xA;   mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767&#xA;   process_one_work+0x1e0/0x560 kernel/workqueue.c:3254&#xA;   process_scheduled_works kernel/workqueue.c:3335 [inline]&#xA;   worker_thread+0x3c7/0x640 kernel/workqueue.c:3416&#xA;   kthread+0x121/0x170 kernel/kthread.c:388&#xA;   ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147&#xA;   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243&#xA;   &lt;/TASK&gt;&#xA;When fallback to TCP happens early on a client socket, snd_nxt&#xA;is not yet initialized and any incoming ack will copy such value&#xA;into snd_una. If the mptcp worker (dumbly) tries mptcp-level&#xA;re-injection after such ack, that would unconditionally trigger a send&#xA;buffer cleanup using &#39;bad&#39; snd_una values.&#xA;We could easily disable re-injection for fallback sockets, but such&#xA;dumb behavior already helped catching a few subtle issues and a very&#xA;low to zero impact in practice.&#xA;Instead address the issue always initializing snd_nxt (and write_seq,&#xA;for consistency) at connect time.&#xA;CVE-2024-36957:In the Linux kernel, the following vulnerability has been resolved:&#xA;octeontx2-af: avoid off-by-one read from userspace&#xA;We try to access count + 1 byte from userspace with memdup_user(buffer,&#xA;count + 1). However, the userspace only provides buffer of count bytes and&#xA;only these count bytes are verified to be okay to access. To ensure the&#xA;copied buffer is NUL terminated, we use memdup_user_nul instead.&#xA;CVE-2023-52756:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-36886:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: fix UAF in error path&#xA;Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported&#xA;a UAF in the tipc_buf_append() error path:&#xA;BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0&#xA;linux/net/core/skbuff.c:1183&#xA;Read of size 8 at addr ffff88804d2a7c80 by task poc/8034&#xA;CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;1.16.0-debian-1.16.0-5 04/01/2014&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; __dump_stack linux/lib/dump_stack.c:88&#xA; dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106&#xA; print_address_description linux/mm/kasan/report.c:377&#xA; print_report+0xc4/0x620 linux/mm/kasan/report.c:488&#xA; kasan_report+0xda/0x110 linux/mm/kasan/report.c:601&#xA; kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183&#xA; skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026&#xA; skb_release_all linux/net/core/skbuff.c:1094&#xA; __kfree_skb linux/net/core/skbuff.c:1108&#xA; kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144&#xA; kfree_skb linux/./include/linux/skbuff.h:1244&#xA; tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186&#xA; tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324&#xA; tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824&#xA; tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159&#xA; tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390&#xA; udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108&#xA; udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186&#xA; udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346&#xA; __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422&#xA; ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205&#xA; ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233&#xA; NF_HOOK linux/./include/linux/netfilter.h:314&#xA; NF_HOOK linux/./include/linux/netfilter.h:308&#xA; ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254&#xA; dst_input linux/./include/net/dst.h:461&#xA; ip_rcv_finish linux/net/ipv4/ip_input.c:449&#xA; NF_HOOK linux/./include/linux/netfilter.h:314&#xA; NF_HOOK linux/./include/linux/netfilter.h:308&#xA; ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569&#xA; __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534&#xA; __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648&#xA; process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976&#xA; __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576&#xA; napi_poll linux/net/core/dev.c:6645&#xA; net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781&#xA; __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553&#xA; do_softirq linux/kernel/softirq.c:454&#xA; do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381&#xA; local_bh_enable linux/./include/linux/bottom_half.h:33&#xA; rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851&#xA; __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378&#xA; dev_queue_xmit linux/./include/linux/netdevice.h:3169&#xA; neigh_hh_output linux/./include/net/neighbour.h:526&#xA; neigh_output linux/./include/net/neighbour.h:540&#xA; ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235&#xA; __ip_finish_output linux/net/ipv4/ip_output.c:313&#xA; __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295&#xA; ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323&#xA; NF_HOOK_COND linux/./include/linux/netfilter.h:303&#xA; ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433&#xA; dst_output linux/./include/net/dst.h:451&#xA; ip_local_out linux/net/ipv4/ip_output.c:129&#xA; ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492&#xA; udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963&#xA; udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250&#xA; inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850&#xA; sock_sendmsg_nosec linux/net/socket.c:730&#xA; __sock_sendmsg linux/net/socket.c:745&#xA; __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191&#xA; __do_sys_sendto linux/net/socket.c:2203&#xA; __se_sys_sendto linux/net/socket.c:2199&#xA; __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199&#xA; do_syscall_x64 linux/arch/x86/entry/common.c:52&#xA; do_syscall_&#xA;---truncated---&#xA;CVE-2024-35870:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix UAF in smb2_reconnect_server()&#xA;The UAF bug is due to smb2_reconnect_server() accessing a session that&#xA;is already being teared down by another thread that is executing&#xA;__cifs_put_smb_ses().  This can happen when (a) the client has&#xA;connection to the server but no session or (b) another thread ends up&#xA;setting @ses-&gt;ses_status again to something different than&#xA;SES_EXITING.&#xA;To fix this, we need to make sure to unconditionally set&#xA;@ses-&gt;ses_status to SES_EXITING and prevent any other threads from&#xA;setting a new status while we&#39;re still tearing it down.&#xA;The following can be reproduced by adding some delay to right after&#xA;the ipc is freed in __cifs_put_smb_ses() - which will give&#xA;smb2_reconnect_server() worker a chance to run and then accessing&#xA;@ses-&gt;ipc:&#xA;kinit ...&#xA;mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10&#xA;[disconnect srv]&#xA;ls /mnt/1 &amp;&gt;/dev/null&#xA;sleep 30&#xA;kdestroy&#xA;[reconnect srv]&#xA;sleep 10&#xA;umount /mnt/1&#xA;...&#xA;CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed&#xA;CIFS: VFS: \\srv Send error in SessSetup = -126&#xA;CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed&#xA;CIFS: VFS: \\srv Send error in SessSetup = -126&#xA;general protection fault, probably for non-canonical address&#xA;0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39&#xA;04/01/2014&#xA;Workqueue: cifsiod smb2_reconnect_server [cifs]&#xA;RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0&#xA;Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad&#xA;de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 &lt;48&gt; 8b 01 48 39 f8 75&#xA;7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8&#xA;RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83&#xA;RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b&#xA;RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800&#xA;RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000&#xA;R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000&#xA;FS: 0000000000000000(0000) GS:ffff888157c00000(0000)&#xA;knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? die_addr+0x36/0x90&#xA; ? exc_general_protection+0x1c1/0x3f0&#xA; ? asm_exc_general_protection+0x26/0x30&#xA; ? __list_del_entry_valid_or_report+0x33/0xf0&#xA; __cifs_put_smb_ses+0x1ae/0x500 [cifs]&#xA; smb2_reconnect_server+0x4ed/0x710 [cifs]&#xA; process_one_work+0x205/0x6b0&#xA; worker_thread+0x191/0x360&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0xe2/0x110&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x34/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;CVE-2024-27393:In the Linux kernel, the following vulnerability has been resolved:&#xA;xen-netfront: Add missing skb_mark_for_recycle&#xA;Notice that skb_mark_for_recycle() is introduced later than fixes tag in&#xA;commit 6a5bcd84e886 (&#34;page_pool: Allow drivers to hint on SKB recycling&#34;).&#xA;It is believed that fixes tag were missing a call to page_pool_release_page()&#xA;between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().&#xA;Since v6.6 the call page_pool_release_page() were removed (in&#xA;commit 535b9c61bdef (&#34;net: page_pool: hide page_pool_release_page()&#34;)&#xA;and remaining callers converted (in commit 6bfef2ec0172 (&#34;Merge branch&#xA;&#39;net-page_pool-remove-page_pool_release_page&#39;&#34;)).&#xA;This leak became visible in v6.8 via commit dba1b8a7ab68 (&#34;mm/page_pool: catch&#xA;page_pool memory leaks&#34;).&#xA;CVE-2024-35967:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: SCO: Fix not validating setsockopt user input&#xA;syzbot reported sco_sock_setsockopt() is copying data without&#xA;checking user input length.&#xA;BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset&#xA;include/linux/sockptr.h:49 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in copy_from_sockptr&#xA;include/linux/sockptr.h:55 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90&#xA;net/bluetooth/sco.c:893&#xA;Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578&#xA;CVE-2023-52807:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs&#xA;The hns3 driver define an array of string to show the coalesce&#xA;info, but if the kernel adds a new mode or a new state,&#xA;out-of-bounds access may occur when coalesce info is read via&#xA;debugfs, this patch fix the problem.&#xA;CVE-2024-35951:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()&#xA;Subject: [PATCH] drm/panfrost: Fix the error path in&#xA; panfrost_mmu_map_fault_addr()&#xA;If some the pages or sgt allocation failed, we shouldn&#39;t release the&#xA;pages ref we got earlier, otherwise we will end up with unbalanced&#xA;get/put_pages() calls. We should instead leave everything in place&#xA;and let the BO release function deal with extra cleanup when the object&#xA;is destroyed, or let the fault handler try again next time it&#39;s called.&#xA;CVE-2024-36916:In the Linux kernel, the following vulnerability has been resolved:&#xA;blk-iocost: avoid out of bounds shift&#xA;UBSAN catches undefined behavior in blk-iocost, where sometimes&#xA;iocg-&gt;delay is shifted right by a number that is too large,&#xA;resulting in undefined behavior on some architectures.&#xA;[  186.556576] ------------[ cut here ]------------&#xA;UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23&#xA;shift exponent 64 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long long&#39;)&#xA;CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1&#xA;Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl+0x8f/0xe0&#xA; __ubsan_handle_shift_out_of_bounds+0x22c/0x280&#xA; iocg_kick_delay+0x30b/0x310&#xA; ioc_timer_fn+0x2fb/0x1f80&#xA; __run_timer_base+0x1b6/0x250&#xA;...&#xA;Avoid that undefined behavior by simply taking the&#xA;&#34;delay = 0&#34; branch if the shift is too large.&#xA;I am not sure what the symptoms of an undefined value&#xA;delay will be, but I suspect it could be more than a&#xA;little annoying to debug.&#xA;CVE-2023-52745:In the Linux kernel, the following vulnerability has been resolved:&#xA;IB/IPoIB: Fix legacy IPoIB due to wrong number of queues&#xA;The cited commit creates child PKEY interfaces over netlink will&#xA;multiple tx and rx queues, but some devices doesn&#39;t support more than 1&#xA;tx and 1 rx queues. This causes to a crash when traffic is sent over the&#xA;PKEY interface due to the parent having a single queue but the child&#xA;having multiple queues.&#xA;This patch fixes the number of queues to 1 for legacy IPoIB at the&#xA;earliest possible point in time.&#xA;BUG: kernel NULL pointer dereference, address: 000000000000036b&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] SMP&#xA;CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:kmem_cache_alloc+0xcb/0x450&#xA;Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a&#xA;01 49 8b 3c 24 &lt;49&gt; 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b&#xA;RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202&#xA;RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae&#xA;RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00&#xA;RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40&#xA;R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000&#xA;R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000&#xA;FS:  00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; skb_clone+0x55/0xd0&#xA; ip6_finish_output2+0x3fe/0x690&#xA; ip6_finish_output+0xfa/0x310&#xA; ip6_send_skb+0x1e/0x60&#xA; udp_v6_send_skb+0x1e5/0x420&#xA; udpv6_sendmsg+0xb3c/0xe60&#xA; ? ip_mc_finish_output+0x180/0x180&#xA; ? __switch_to_asm+0x3a/0x60&#xA; ? __switch_to_asm+0x34/0x60&#xA; sock_sendmsg+0x33/0x40&#xA; __sys_sendto+0x103/0x160&#xA; ? _copy_to_user+0x21/0x30&#xA; ? kvm_clock_get_cycles+0xd/0x10&#xA; ? ktime_get_ts64+0x49/0xe0&#xA; __x64_sys_sendto+0x25/0x30&#xA; do_syscall_64+0x3d/0x90&#xA; entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA;RIP: 0033:0x7f9374f1ed14&#xA;Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b&#xA;7c 24 08 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b&#xA;RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c&#xA;RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14&#xA;RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030&#xA;RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c&#xA;R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000&#xA;R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc&#xA; &lt;/TASK&gt;&#xA;CVE-2024-36902:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()&#xA;syzbot is able to trigger the following crash [1],&#xA;caused by unsafe ip6_dst_idev() use.&#xA;Indeed ip6_dst_idev() can return NULL, and must always be checked.&#xA;[1]&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA; RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]&#xA; RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267&#xA;Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 &lt;42&gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c&#xA;RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700&#xA;RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760&#xA;RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd&#xA;R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000&#xA;R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00&#xA;FS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317&#xA;  fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108&#xA;  ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]&#xA;  ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649&#xA;  ip6_route_output include/net/ip6_route.h:93 [inline]&#xA;  ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120&#xA;  ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250&#xA;  sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326&#xA;  sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455&#xA;  sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662&#xA;  sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099&#xA;  __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197&#xA;  sctp_connect net/sctp/socket.c:4819 [inline]&#xA;  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834&#xA;  __sys_connect_file net/socket.c:2048 [inline]&#xA;  __sys_connect+0x2df/0x310 net/socket.c:2065&#xA;  __do_sys_connect net/socket.c:2075 [inline]&#xA;  __se_sys_connect net/socket.c:2072 [inline]&#xA;  __x64_sys_connect+0x7a/0x90 net/socket.c:2072&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-35809:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI/PM: Drain runtime-idle callbacks before driver removal&#xA;A race condition between the .runtime_idle() callback and the .remove()&#xA;callback in the rtsx_pcr PCI driver leads to a kernel crash due to an&#xA;unhandled page fault [1].&#xA;The problem is that rtsx_pci_runtime_idle() is not expected to be running&#xA;after pm_runtime_get_sync() has been called, but the latter doesn&#39;t really&#xA;guarantee that.  It only guarantees that the suspend and resume callbacks&#xA;will not be running when it returns.&#xA;However, if a .runtime_idle() callback is already running when&#xA;pm_runtime_get_sync() is called, the latter will notice that the runtime PM&#xA;status of the device is RPM_ACTIVE and it will return right away without&#xA;waiting for the former to complete.  In fact, it cannot wait for&#xA;.runtime_idle() to complete because it may be called from that callback (it&#xA;arguably does not make much sense to do that, but it is not strictly&#xA;prohibited).&#xA;Thus in general, whoever is providing a .runtime_idle() callback needs&#xA;to protect it from running in parallel with whatever code runs after&#xA;pm_runtime_get_sync().  [Note that .runtime_idle() will not start after&#xA;pm_runtime_get_sync() has returned, but it may continue running then if it&#xA;has started earlier.]&#xA;One way to address that race condition is to call pm_runtime_barrier()&#xA;after pm_runtime_get_sync() (not before it, because a nonzero value of the&#xA;runtime PM usage counter is necessary to prevent runtime PM callbacks from&#xA;being invoked) to wait for the .runtime_idle() callback to complete should&#xA;it be running at that point.  A suitable place for doing that is in&#xA;pci_device_remove() which calls pm_runtime_get_sync() before removing the&#xA;driver, so it may as well call pm_runtime_barrier() subsequently, which&#xA;will prevent the race in question from occurring, not just in the rtsx_pcr&#xA;driver, but in any PCI drivers providing .runtime_idle() callbacks.&#xA;CVE-2023-52775:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/smc: avoid data corruption caused by decline&#xA;We found a data corruption issue during testing of SMC-R on Redis&#xA;applications.&#xA;The benchmark has a low probability of reporting a strange error as&#xA;shown below.&#xA;&#34;Error: Protocol error, got &#34;\xe2&#34; as reply type byte&#34;&#xA;Finally, we found that the retrieved error data was as follows:&#xA;0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C&#xA;0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00&#xA;0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2&#xA;It is quite obvious that this is a SMC DECLINE message, which means that&#xA;the applications received SMC protocol message.&#xA;We found that this was caused by the following situations:&#xA;client                  server&#xA;        ¦  clc proposal&#xA;        -------------&gt;&#xA;        ¦  clc accept&#xA;        &lt;-------------&#xA;        ¦  clc confirm&#xA;        -------------&gt;&#xA;wait llc confirm&#xA;&#x9;&#x9;&#x9;send llc confirm&#xA;        ¦failed llc confirm&#xA;        ¦   x------&#xA;(after 2s)timeout&#xA;                        wait llc confirm rsp&#xA;wait decline&#xA;(after 1s) timeout&#xA;                        (after 2s) timeout&#xA;        ¦   decline&#xA;        --------------&gt;&#xA;        ¦   decline&#xA;        &lt;--------------&#xA;As a result, a decline message was sent in the implementation, and this&#xA;message was read from TCP by the already-fallback connection.&#xA;This patch double the client timeout as 2x of the server value,&#xA;With this simple change, the Decline messages should never cross or&#xA;collide (during Confirm link timeout).&#xA;This issue requires an immediate solution, since the protocol updates&#xA;involve a more long-term solution.&#xA;CVE-2024-36908:In the Linux kernel, the following vulnerability has been resolved:&#xA;blk-iocost: do not WARN if iocg was already offlined&#xA;In iocg_pay_debt(), warn is triggered if &#39;active_list&#39; is empty, which&#xA;is intended to confirm iocg is active when it has debt. However, warn&#xA;can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()&#xA;is run at that time:&#xA;  WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190&#xA;  Call trace:&#xA;  iocg_pay_debt+0x14c/0x190&#xA;  iocg_kick_waitq+0x438/0x4c0&#xA;  iocg_waitq_timer_fn+0xd8/0x130&#xA;  __run_hrtimer+0x144/0x45c&#xA;  __hrtimer_run_queues+0x16c/0x244&#xA;  hrtimer_interrupt+0x2cc/0x7b0&#xA;The warn in this situation is meaningless. Since this iocg is being&#xA;removed, the state of the &#39;active_list&#39; is irrelevant, and &#39;waitq_timer&#39;&#xA;is canceled after removing &#39;active_list&#39; in ioc_pd_free(), which ensures&#xA;iocg is freed after iocg_waitq_timer_fn() returns.&#xA;Therefore, add the check if iocg was already offlined to avoid warn&#xA;when removing a blkcg or disk.&#xA;CVE-2024-36901:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: prevent NULL dereference in ip6_output()&#xA;According to syzbot, there is a chance that ip6_dst_idev()&#xA;returns NULL in ip6_output(). Most places in IPv6 stack&#xA;deal with a NULL idev just fine, but not here.&#xA;syzbot reported:&#xA;general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]&#xA;CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA; RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237&#xA;Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 &lt;42&gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff&#xA;RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202&#xA;RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000&#xA;RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48&#xA;RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad&#xA;R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0&#xA;R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000&#xA;FS:  00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358&#xA;  sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248&#xA;  sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653&#xA;  sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783&#xA;  sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]&#xA;  sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212&#xA;  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]&#xA;  sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169&#xA;  sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73&#xA;  __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234&#xA;  sctp_connect net/sctp/socket.c:4819 [inline]&#xA;  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834&#xA;  __sys_connect_file net/socket.c:2048 [inline]&#xA;  __sys_connect+0x2df/0x310 net/socket.c:2065&#xA;  __do_sys_connect net/socket.c:2075 [inline]&#xA;  __se_sys_connect net/socket.c:2072 [inline]&#xA;  __x64_sys_connect+0x7a/0x90 net/socket.c:2072&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-36960:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vmwgfx: Fix invalid reads in fence signaled events&#xA;Correctly set the length of the drm_event to the size of the structure&#xA;that&#39;s actually used.&#xA;The length of the drm_event was set to the parent structure instead of&#xA;to the drm_vmw_event_fence which is supposed to be read. drm_read&#xA;uses the length parameter to copy the event to the user space thus&#xA;resuling in oob reads.&#xA;CVE-2024-36929:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: core: reject skb_copy(_expand) for fraglist GSO skbs&#xA;SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become&#xA;invalid. Return NULL if such an skb is passed to skb_copy or&#xA;skb_copy_expand, in order to prevent a crash on a potential later&#xA;call to skb_gso_segment.&#xA;CVE-2024-36952:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: lpfc: Move NPIV&#39;s transport unregistration to after resource clean up&#xA;There are cases after NPIV deletion where the fabric switch still believes&#xA;the NPIV is logged into the fabric.  This occurs when a vport is&#xA;unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the&#xA;fabric.&#xA;Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including&#xA;the fabric D_ID, removes the last ndlp reference and frees the ndlp rport&#xA;object.  This sometimes causes the race condition where the final DA_ID and&#xA;LOGO are skipped from being sent to the fabric switch.&#xA;Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID&#xA;and LOGO are sent.&#xA;CVE-2024-36933:In the Linux kernel, the following vulnerability has been resolved:&#xA;nsh: Restore skb-&gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().&#xA;syzbot triggered various splats (see [0] and links) by a crafted GSO&#xA;packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:&#xA;  ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP&#xA;NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the inner&#xA;protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls&#xA;skb_mac_gso_segment() to invoke inner protocol GSO handlers.&#xA;nsh_gso_segment() does the following for the original skb before&#xA;calling skb_mac_gso_segment()&#xA;  1. reset skb-&gt;network_header&#xA;  2. save the original skb-&gt;{mac_heaeder,mac_len} in a local variable&#xA;  3. pull the NSH header&#xA;  4. resets skb-&gt;mac_header&#xA;  5. set up skb-&gt;mac_len and skb-&gt;protocol for the inner protocol.&#xA;and does the following for the segmented skb&#xA;  6. set ntohs(ETH_P_NSH) to skb-&gt;protocol&#xA;  7. push the NSH header&#xA;  8. restore skb-&gt;mac_header&#xA;  9. set skb-&gt;mac_header + mac_len to skb-&gt;network_header&#xA; 10. restore skb-&gt;mac_len&#xA;There are two problems in 6-7 and 8-9.&#xA;  (a)&#xA;  After 6 &amp; 7, skb-&gt;data points to the NSH header, so the outer header&#xA;  (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.&#xA;  Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),&#xA;  skb_pull() in the first nsh_gso_segment() will make skb-&gt;data point&#xA;  to the middle of the outer NSH or Ethernet header because the Ethernet&#xA;  header is not pulled by the second nsh_gso_segment().&#xA;  (b)&#xA;  While restoring skb-&gt;{mac_header,network_header} in 8 &amp; 9,&#xA;  nsh_gso_segment() does not assume that the data in the linear&#xA;  buffer is shifted.&#xA;  However, udp6_ufo_fragment() could shift the data and change&#xA;  skb-&gt;mac_header accordingly as demonstrated by syzbot.&#xA;  If this happens, even the restored skb-&gt;mac_header points to&#xA;  the middle of the outer header.&#xA;It seems nsh_gso_segment() has never worked with outer headers so far.&#xA;At the end of nsh_gso_segment(), the outer header must be restored for&#xA;the segmented skb, instead of the NSH header.&#xA;To do that, let&#39;s calculate the outer header position relatively from&#xA;the inner header and set skb-&gt;{data,mac_header,protocol} properly.&#xA;[0]:&#xA;BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]&#xA;BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]&#xA;BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668&#xA; ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]&#xA; ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]&#xA; ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668&#xA; ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222&#xA; __netdev_start_xmit include/linux/netdevice.h:4989 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:5003 [inline]&#xA; xmit_one net/core/dev.c:3547 [inline]&#xA; dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563&#xA; __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351&#xA; dev_queue_xmit include/linux/netdevice.h:3171 [inline]&#xA; packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276&#xA; packet_snd net/packet/af_packet.c:3081 [inline]&#xA; packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; __sys_sendto+0x735/0xa10 net/socket.c:2191&#xA; __do_sys_sendto net/socket.c:2203 [inline]&#xA; __se_sys_sendto net/socket.c:2199 [inline]&#xA; __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;Uninit was created at:&#xA; slab_post_alloc_hook mm/slub.c:3819 [inline]&#xA; slab_alloc_node mm/slub.c:3860 [inline]&#xA; __do_kmalloc_node mm/slub.c:3980 [inline]&#xA; __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001&#xA; kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582&#xA; __&#xA;---truncated---&#xA;CVE-2024-36883:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: fix out-of-bounds access in ops_init&#xA;net_alloc_generic is called by net_alloc, which is called without any&#xA;locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It&#xA;is read twice, first to allocate an array, then to set s.len, which is&#xA;later used to limit the bounds of the array access.&#xA;It is possible that the array is allocated and another thread is&#xA;registering a new pernet ops, increments max_gen_ptrs, which is then used&#xA;to set s.len with a larger than allocated length for the variable array.&#xA;Fix it by reading max_gen_ptrs only once in net_alloc_generic. If&#xA;max_gen_ptrs is later incremented, it will be caught in net_assign_generic.&#xA;CVE-2023-52680:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: scarlett2: Add missing error checks to *_ctl_get()&#xA;The *_ctl_get() functions which call scarlett2_update_*() were not&#xA;checking the return value. Fix to check the return value and pass to&#xA;the caller.&#xA;CVE-2021-47247:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: Fix use-after-free of encap entry in neigh update handler&#xA;Function mlx5e_rep_neigh_update() wasn&#39;t updated to accommodate rtnl lock&#xA;removal from TC filter update path and properly handle concurrent encap&#xA;entry insertion/deletion which can lead to following use-after-free:&#xA; [23827.464923] ==================================================================&#xA; [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]&#xA; [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635&#xA; [23827.472251]&#xA; [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5&#xA; [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA; [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]&#xA; [23827.476731] Call Trace:&#xA; [23827.477260]  dump_stack+0xbb/0x107&#xA; [23827.477906]  print_address_description.constprop.0+0x18/0x140&#xA; [23827.478896]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]&#xA; [23827.479879]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]&#xA; [23827.480905]  kasan_report.cold+0x7c/0xd8&#xA; [23827.481701]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]&#xA; [23827.482744]  kasan_check_range+0x145/0x1a0&#xA; [23827.493112]  mlx5e_encap_take+0x72/0x140 [mlx5_core]&#xA; [23827.494054]  ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]&#xA; [23827.495296]  mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]&#xA; [23827.496338]  ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]&#xA; [23827.497486]  ? read_word_at_a_time+0xe/0x20&#xA; [23827.498250]  ? strscpy+0xa0/0x2a0&#xA; [23827.498889]  process_one_work+0x8ac/0x14e0&#xA; [23827.499638]  ? lockdep_hardirqs_on_prepare+0x400/0x400&#xA; [23827.500537]  ? pwq_dec_nr_in_flight+0x2c0/0x2c0&#xA; [23827.501359]  ? rwlock_bug.part.0+0x90/0x90&#xA; [23827.502116]  worker_thread+0x53b/0x1220&#xA; [23827.502831]  ? process_one_work+0x14e0/0x14e0&#xA; [23827.503627]  kthread+0x328/0x3f0&#xA; [23827.504254]  ? _raw_spin_unlock_irq+0x24/0x40&#xA; [23827.505065]  ? __kthread_bind_mask+0x90/0x90&#xA; [23827.505912]  ret_from_fork+0x1f/0x30&#xA; [23827.506621]&#xA; [23827.506987] Allocated by task 28248:&#xA; [23827.507694]  kasan_save_stack+0x1b/0x40&#xA; [23827.508476]  __kasan_kmalloc+0x7c/0x90&#xA; [23827.509197]  mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]&#xA; [23827.510194]  mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]&#xA; [23827.511218]  __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]&#xA; [23827.512234]  mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]&#xA; [23827.513298]  tc_setup_cb_add+0x1d5/0x420&#xA; [23827.514023]  fl_hw_replace_filter+0x382/0x6a0 [cls_flower]&#xA; [23827.514975]  fl_change+0x2ceb/0x4a51 [cls_flower]&#xA; [23827.515821]  tc_new_tfilter+0x89a/0x2070&#xA; [23827.516548]  rtnetlink_rcv_msg+0x644/0x8c0&#xA; [23827.517300]  netlink_rcv_skb+0x11d/0x340&#xA; [23827.518021]  netlink_unicast+0x42b/0x700&#xA; [23827.518742]  netlink_sendmsg+0x743/0xc20&#xA; [23827.519467]  sock_sendmsg+0xb2/0xe0&#xA; [23827.520131]  ____sys_sendmsg+0x590/0x770&#xA; [23827.520851]  ___sys_sendmsg+0xd8/0x160&#xA; [23827.521552]  __sys_sendmsg+0xb7/0x140&#xA; [23827.522238]  do_syscall_64+0x3a/0x70&#xA; [23827.522907]  entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA; [23827.523797]&#xA; [23827.524163] Freed by task 25948:&#xA; [23827.524780]  kasan_save_stack+0x1b/0x40&#xA; [23827.525488]  kasan_set_track+0x1c/0x30&#xA; [23827.526187]  kasan_set_free_info+0x20/0x30&#xA; [23827.526968]  __kasan_slab_free+0xed/0x130&#xA; [23827.527709]  slab_free_freelist_hook+0xcf/0x1d0&#xA; [23827.528528]  kmem_cache_free_bulk+0x33a/0x6e0&#xA; [23827.529317]  kfree_rcu_work+0x55f/0xb70&#xA; [23827.530024]  process_one_work+0x8ac/0x14e0&#xA; [23827.530770]  worker_thread+0x53b/0x1220&#xA; [23827.531480]  kthread+0x328/0x3f0&#xA; [23827.532114]  ret_from_fork+0x1f/0x30&#xA; [23827.532785]&#xA; [23827.533147] Last potentially related work creation:&#xA; [23827.534007]  kasan_save_stack+0x1b/0x40&#xA; [23827.534710]  kasan_record_aux_stack+0xab/0xc0&#xA; [23827.535492]  kvfree_call_rcu+0x31/0x7b0&#xA; [23827.536206]  mlx5e_tc_del&#xA;---truncated---&#xA;CVE-2024-36899:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpiolib: cdev: Fix use after free in lineinfo_changed_notify&#xA;The use-after-free issue occurs as follows: when the GPIO chip device file&#xA;is being closed by invoking gpio_chrdev_release(), watched_lines is freed&#xA;by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier&#xA;chain failed due to waiting write rwsem. Additionally, one of the GPIO&#xA;chip&#39;s lines is also in the release process and holds the notifier chain&#39;s&#xA;read rwsem. Consequently, a race condition leads to the use-after-free of&#xA;watched_lines.&#xA;Here is the typical stack when issue happened:&#xA;[free]&#xA;gpio_chrdev_release()&#xA;  --&gt; bitmap_free(cdev-&gt;watched_lines)                  &lt;-- freed&#xA;  --&gt; blocking_notifier_chain_unregister()&#xA;    --&gt; down_write(&amp;nh-&gt;rwsem)                          &lt;-- waiting rwsem&#xA;          --&gt; __down_write_common()&#xA;            --&gt; rwsem_down_write_slowpath()&#xA;                  --&gt; schedule_preempt_disabled()&#xA;                    --&gt; schedule()&#xA;[use]&#xA;st54spi_gpio_dev_release()&#xA;  --&gt; gpio_free()&#xA;    --&gt; gpiod_free()&#xA;      --&gt; gpiod_free_commit()&#xA;        --&gt; gpiod_line_state_notify()&#xA;          --&gt; blocking_notifier_call_chain()&#xA;            --&gt; down_read(&amp;nh-&gt;rwsem);                  &lt;-- held rwsem&#xA;            --&gt; notifier_call_chain()&#xA;              --&gt; lineinfo_changed_notify()&#xA;                --&gt; test_bit(xxxx, cdev-&gt;watched_lines) &lt;-- use after free&#xA;The side effect of the use-after-free issue is that a GPIO line event is&#xA;being generated for userspace where it shouldn&#39;t. However, since the chrdev&#xA;is being closed, userspace won&#39;t have the chance to read that event anyway.&#xA;To fix the issue, call the bitmap_free() function after the unregistration&#xA;of lineinfo_changed_nb notifier chain.&#xA;CVE-2023-52672:In the Linux kernel, the following vulnerability has been resolved:&#xA;pipe: wakeup wr_wait after setting max_usage&#xA;Commit c73be61cede5 (&#34;pipe: Add general notification queue support&#34;) a&#xA;regression was introduced that would lock up resized pipes under certain&#xA;conditions. See the reproducer in [1].&#xA;The commit resizing the pipe ring size was moved to a different&#xA;function, doing that moved the wakeup for pipe-&gt;wr_wait before actually&#xA;raising pipe-&gt;max_usage. If a pipe was full before the resize occured it&#xA;would result in the wakeup never actually triggering pipe_write.&#xA;Set @max_usage and @nr_accounted before waking writers if this isn&#39;t a&#xA;watch queue.&#xA;[Christian Brauner &lt;brauner@kernel.org&gt;: rewrite to account for watch queues]&#xA;CVE-2023-52732:In the Linux kernel, the following vulnerability has been resolved:&#xA;ceph: blocklist the kclient when receiving corrupted snap trace&#xA;When received corrupted snap trace we don&#39;t know what exactly has&#xA;happened in MDS side. And we shouldn&#39;t continue IOs and metadatas&#xA;access to MDS, which may corrupt or get incorrect contents.&#xA;This patch will just block all the further IO/MDS requests&#xA;immediately and then evict the kclient itself.&#xA;The reason why we still need to evict the kclient just after&#xA;blocking all the further IOs is that the MDS could revoke the caps&#xA;faster.&#xA;CVE-2023-52882:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change&#xA;While PLL CPUX clock rate change when CPU is running from it works in&#xA;vast majority of cases, now and then it causes instability. This leads&#xA;to system crashes and other undefined behaviour. After a lot of testing&#xA;(30+ hours) while also doing a lot of frequency switches, we can&#39;t&#xA;observe any instability issues anymore when doing reparenting to stable&#xA;clock like 24 MHz oscillator.&#xA;CVE-2024-35924:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: typec: ucsi: Limit read size on v1.2&#xA;Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was&#xA;increased from 16 to 256. In order to avoid overflowing reads for older&#xA;systems, add a mechanism to use the read UCSI version to truncate read&#xA;sizes on UCSI v1.2.&#xA;CVE-2022-48652:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: Fix crash by keep old cfg when update TCs more than queues&#xA;There are problems if allocated queues less than Traffic Classes.&#xA;Commit a632b2a4c920 (&#34;ice: ethtool: Prohibit improper channel config&#xA;for DCB&#34;) already disallow setting less queues than TCs.&#xA;Another case is if we first set less queues, and later update more TCs&#xA;config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty&#xA;num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.&#xA;[   95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.&#xA;[   95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!&#xA;[   95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0&#xA;[   95.969621] general protection fault: 0000 [#1] SMP NOPTI&#xA;[   95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G     U  W  O     --------- -t - 4.18.0 #1&#xA;[   95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021&#xA;[   95.969992] RIP: 0010:devm_kmalloc+0xa/0x60&#xA;[   95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 &lt;8b&gt; 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c&#xA;[   95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206&#xA;[   95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0&#xA;[   95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200&#xA;[   95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000&#xA;[   95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100&#xA;[   95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460&#xA;[   95.970981] FS:  00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000&#xA;[   95.971108] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0&#xA;[   95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[   95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[   95.971530] PKRU: 55555554&#xA;[   95.971573] Call Trace:&#xA;[   95.971622]  ice_setup_rx_ring+0x39/0x110 [ice]&#xA;[   95.971695]  ice_vsi_setup_rx_rings+0x54/0x90 [ice]&#xA;[   95.971774]  ice_vsi_open+0x25/0x120 [ice]&#xA;[   95.971843]  ice_open_internal+0xb8/0x1f0 [ice]&#xA;[   95.971919]  ice_ena_vsi+0x4f/0xd0 [ice]&#xA;[   95.971987]  ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]&#xA;[   95.972082]  ice_pf_dcb_cfg+0x29a/0x380 [ice]&#xA;[   95.972154]  ice_dcbnl_setets+0x174/0x1b0 [ice]&#xA;[   95.972220]  dcbnl_ieee_set+0x89/0x230&#xA;[   95.972279]  ? dcbnl_ieee_del+0x150/0x150&#xA;[   95.972341]  dcb_doit+0x124/0x1b0&#xA;[   95.972392]  rtnetlink_rcv_msg+0x243/0x2f0&#xA;[   95.972457]  ? dcb_doit+0x14d/0x1b0&#xA;[   95.972510]  ? __kmalloc_node_track_caller+0x1d3/0x280&#xA;[   95.972591]  ? rtnl_calcit.isra.31+0x100/0x100&#xA;[   95.972661]  netlink_rcv_skb+0xcf/0xf0&#xA;[   95.972720]  netlink_unicast+0x16d/0x220&#xA;[   95.972781]  netlink_sendmsg+0x2ba/0x3a0&#xA;[   95.975891]  sock_sendmsg+0x4c/0x50&#xA;[   95.979032]  ___sys_sendmsg+0x2e4/0x300&#xA;[   95.982147]  ? kmem_cache_alloc+0x13e/0x190&#xA;[   95.985242]  ? __wake_up_common_lock+0x79/0x90&#xA;[   95.988338]  ? __check_object_size+0xac/0x1b0&#xA;[   95.991440]  ? _copy_to_user+0x22/0x30&#xA;[   95.994539]  ? move_addr_to_user+0xbb/0xd0&#xA;[   95.997619]  ? __sys_sendmsg+0x53/0x80&#xA;[   96.000664]  __sys_sendmsg+0x53/0x80&#xA;[   96.003747]  do_syscall_64+0x5b/0x1d0&#xA;[   96.006862]  entry_SYSCALL_64_after_hwframe+0x65/0xca&#xA;Only update num_txq/rxq when passed check, and restore tc_cfg if setup&#xA;queue map failed.&#xA;CVE-2023-52693:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPI: video: check for error while searching for backlight device parent&#xA;If acpi_get_parent() called in acpi_video_dev_register_backlight()&#xA;fails, for example, because acpi_ut_acquire_mutex() fails inside&#xA;acpi_get_parent), this can lead to incorrect (uninitialized)&#xA;acpi_parent handle being passed to acpi_get_pci_dev() for detecting&#xA;the parent pci device.&#xA;Check acpi_get_parent() result and set parent device only in case of success.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-35915:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet&#xA;syzbot reported the following uninit-value access issue [1][2]:&#xA;nci_rx_work() parses and processes received packet. When the payload&#xA;length is zero, each message type handler reads uninitialized payload&#xA;and KMSAN detects this issue. The receipt of a packet with a zero-size&#xA;payload is considered unexpected, and therefore, such packets should be&#xA;silently discarded.&#xA;This patch resolved this issue by checking payload size before calling&#xA;each message type handler codes.&#xA;CVE-2024-36949:In the Linux kernel, the following vulnerability has been resolved:&#xA;amd/amdkfd: sync all devices to wait all processes being evicted&#xA;If there are more than one device doing reset in parallel, the first&#xA;device will call kfd_suspend_all_processes() to evict all processes&#xA;on all devices, this call takes time to finish. other device will&#xA;start reset and recover without waiting. if the process has not been&#xA;evicted before doing recover, it will be restored, then caused page&#xA;fault.&#xA;CVE-2023-52708:In the Linux kernel, the following vulnerability has been resolved:&#xA;mmc: mmc_spi: fix error handling in mmc_spi_probe()&#xA;If mmc_add_host() fails, it doesn&#39;t need to call mmc_remove_host(),&#xA;or it will cause null-ptr-deref, because of deleting a not added&#xA;device in mmc_remove_host().&#xA;To fix this, goto label &#39;fail_glue_init&#39;, if mmc_add_host() fails,&#xA;and change the label &#39;fail_add_host&#39; to &#39;fail_gpiod_request&#39;.&#xA;CVE-2023-52762:In the Linux kernel, the following vulnerability has been resolved:&#xA;virtio-blk: fix implicit overflow on virtio_max_dma_size&#xA;The following codes have an implicit conversion from size_t to u32:&#xA;(u32)max_size = (size_t)virtio_max_dma_size(vdev);&#xA;This may lead overflow, Ex (size_t)4G -&gt; (u32)0. Once&#xA;virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX&#xA;instead.&#xA;CVE-2024-36905:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets&#xA;TCP_SYN_RECV state is really special, it is only used by&#xA;cross-syn connections, mostly used by fuzzers.&#xA;In the following crash [1], syzbot managed to trigger a divide&#xA;by zero in tcp_rcv_space_adjust()&#xA;A socket makes the following state transitions,&#xA;without ever calling tcp_init_transfer(),&#xA;meaning tcp_init_buffer_space() is also not called.&#xA;         TCP_CLOSE&#xA;connect()&#xA;         TCP_SYN_SENT&#xA;         TCP_SYN_RECV&#xA;shutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)&#xA;         TCP_FIN_WAIT1&#xA;To fix this issue, change tcp_shutdown() to not&#xA;perform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,&#xA;which makes no sense anyway.&#xA;When tcp_rcv_state_process() later changes socket state&#xA;from TCP_SYN_RECV to TCP_ESTABLISH, then look at&#xA;sk-&gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,&#xA;and send a FIN packet from a sane socket state.&#xA;This means tcp_send_fin() can now be called from BH&#xA;context, and must use GFP_ATOMIC allocations.&#xA;[1]&#xA;divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA; RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767&#xA;Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 &lt;48&gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48&#xA;RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246&#xA;RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7&#xA;R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30&#xA;R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da&#xA;FS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513&#xA;  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578&#xA;  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680&#xA;  sock_recvmsg_nosec net/socket.c:1046 [inline]&#xA;  sock_recvmsg+0x109/0x280 net/socket.c:1068&#xA;  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803&#xA;  ___sys_recvmsg net/socket.c:2845 [inline]&#xA;  do_recvmmsg+0x474/0xae0 net/socket.c:2939&#xA;  __sys_recvmmsg net/socket.c:3018 [inline]&#xA;  __do_sys_recvmmsg net/socket.c:3041 [inline]&#xA;  __se_sys_recvmmsg net/socket.c:3034 [inline]&#xA;  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7faeb6363db9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b&#xA;RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9&#xA;RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005&#xA;RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c&#xA;R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001&#xA;CVE-2024-36928:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/qeth: Fix kernel panic after setting hsuid&#xA;Symptom:&#xA;When the hsuid attribute is set for the first time on an IQD Layer3&#xA;device while the corresponding network interface is already UP,&#xA;the kernel will try to execute a napi function pointer that is NULL.&#xA;Example:&#xA;---------------------------------------------------------------------------&#xA;[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP&#xA;[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6&#xA;nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de&#xA;s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod&#xA; qdio ccwgroup pkey zcrypt&#xA;[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1&#xA;[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)&#xA;[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)&#xA;[ 2057.572748]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3&#xA;[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000&#xA;[ 2057.572754]            00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80&#xA;[ 2057.572756]            000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8&#xA;[ 2057.572758]            00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68&#xA;[ 2057.572762] Krnl Code:#0000000000000000: 0000                illegal&#xA;                         &gt;0000000000000002: 0000                illegal&#xA;                          0000000000000004: 0000                illegal&#xA;                          0000000000000006: 0000                illegal&#xA;                          0000000000000008: 0000                illegal&#xA;                          000000000000000a: 0000                illegal&#xA;                          000000000000000c: 0000                illegal&#xA;                          000000000000000e: 0000                illegal&#xA;[ 2057.572800] Call Trace:&#xA;[ 2057.572801] ([&lt;00000000ec639700&gt;] 0xec639700)&#xA;[ 2057.572803]  [&lt;00000000913183e2&gt;] net_rx_action+0x2ba/0x398&#xA;[ 2057.572809]  [&lt;0000000091515f76&gt;] __do_softirq+0x11e/0x3a0&#xA;[ 2057.572813]  [&lt;0000000090ce160c&gt;] do_softirq_own_stack+0x3c/0x58&#xA;[ 2057.572817] ([&lt;0000000090d2cbd6&gt;] do_softirq.part.1+0x56/0x60)&#xA;[ 2057.572822]  [&lt;0000000090d2cc60&gt;] __local_bh_enable_ip+0x80/0x98&#xA;[ 2057.572825]  [&lt;0000000091314706&gt;] __dev_queue_xmit+0x2be/0xd70&#xA;[ 2057.572827]  [&lt;000003ff803dd6d6&gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]&#xA;[ 2057.572830]  [&lt;000003ff803dd88a&gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]&#xA;[ 2057.572833]  [&lt;000003ff803de72a&gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]&#xA;[ 2057.572835]  [&lt;00000000912e7e90&gt;] __sys_connect+0xa0/0xd8&#xA;[ 2057.572839]  [&lt;00000000912e9580&gt;] sys_socketcall+0x228/0x348&#xA;[ 2057.572841]  [&lt;0000000091514e1a&gt;] system_call+0x2a6/0x2c8&#xA;[ 2057.572843] Last Breaking-Event-Address:&#xA;[ 2057.572844]  [&lt;0000000091317e44&gt;] __napi_poll+0x4c/0x1d8&#xA;[ 2057.572846]&#xA;[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt&#xA;-------------------------------------------------------------------------------------------&#xA;Analysis:&#xA;There is one napi structure per out_q: card-&gt;qdio.out_qs[i].napi&#xA;The napi.poll functions are set during qeth_open().&#xA;Since&#xA;commit 1cfef80d4c2b (&#34;s390/qeth: Don&#39;t call dev_close/dev_open (DOWN/UP)&#34;)&#xA;qeth_set_offline()/qeth_set_online() no longer call dev_close()/&#xA;dev_open(). So if qeth_free_qdio_queues() cleared&#xA;card-&gt;qdio.out_qs[i].napi.poll while the network interface was UP and the&#xA;card was offline, they are not set again.&#xA;Reproduction:&#xA;chzdev -e $devno layer2=0&#xA;ip link set dev $network_interface up&#xA;echo 0 &gt; /sys/bus/ccw&#xA;---truncated---&#xA;CVE-2024-36919:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload&#xA;The session resources are used by FW and driver when session is offloaded,&#xA;once session is uploaded these resources are not used. The lock is not&#xA;required as these fields won&#39;t be used any longer. The offload and upload&#xA;calls are sequential, hence lock is not required.&#xA;This will suppress following BUG_ON():&#xA;[  449.843143] ------------[ cut here ]------------&#xA;[  449.848302] kernel BUG at mm/vmalloc.c:2727!&#xA;[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI&#xA;[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1&#xA;Rebooting.&#xA;[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016&#xA;[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]&#xA;[  449.882910] RIP: 0010:vunmap+0x2e/0x30&#xA;[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 &lt;0f&gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41&#xA;[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206&#xA;[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005&#xA;[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000&#xA;[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf&#xA;[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000&#xA;[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0&#xA;[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000&#xA;[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0&#xA;[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  449.993028] Call Trace:&#xA;[  449.995756]  __iommu_dma_free+0x96/0x100&#xA;[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]&#xA;[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]&#xA;[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]&#xA;[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]&#xA;[  450.023103]  process_one_work+0x1e8/0x3c0&#xA;[  450.027581]  worker_thread+0x50/0x3b0&#xA;[  450.031669]  ? rescuer_thread+0x370/0x370&#xA;[  450.036143]  kthread+0x149/0x170&#xA;[  450.039744]  ? set_kthread_struct+0x40/0x40&#xA;[  450.044411]  ret_from_fork+0x22/0x30&#xA;[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls&#xA;[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler&#xA;[  450.159753] ---[ end trace 712de2c57c64abc8 ]---&#xA;CVE-2024-35830:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: tc358743: register v4l2 async device only after successful setup&#xA;Ensure the device has been setup correctly before registering the v4l2&#xA;async device, thus allowing userspace to access.&#xA;CVE-2024-35828:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()&#xA;In the for statement of lbs_allocate_cmd_buffer(), if the allocation of&#xA;cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to&#xA;be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().&#xA;CVE-2024-36016:In the Linux kernel, the following vulnerability has been resolved:&#xA;tty: n_gsm: fix possible out-of-bounds in gsm0_receive()&#xA;Assuming the following:&#xA;- side A configures the n_gsm in basic option mode&#xA;- side B sends the header of a basic option mode frame with data length 1&#xA;- side A switches to advanced option mode&#xA;- side B sends 2 data bytes which exceeds gsm-&gt;len&#xA;  Reason: gsm-&gt;len is not used in advanced option mode.&#xA;- side A switches to basic option mode&#xA;- side B keeps sending until gsm0_receive() writes past gsm-&gt;buf&#xA;  Reason: Neither gsm-&gt;state nor gsm-&gt;len have been reset after&#xA;  reconfiguration.&#xA;Fix this by changing gsm-&gt;count to gsm-&gt;len comparison from equal to less&#xA;than. Also add upper limit checks against the constant MAX_MRU in&#xA;gsm0_receive() and gsm1_receive() to harden against memory corruption of&#xA;gsm-&gt;len and gsm-&gt;mru.&#xA;All other checks remain as we still need to limit the data according to the&#xA;user configuration and actual payload size.&#xA;CVE-2024-36938:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue&#xA;Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which&#xA;syzbot reported [1].&#xA;[1]&#xA;BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue&#xA;write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:&#xA; sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]&#xA; sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843&#xA; sk_psock_put include/linux/skmsg.h:459 [inline]&#xA; sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648&#xA; unix_release+0x4b/0x80 net/unix/af_unix.c:1048&#xA; __sock_release net/socket.c:659 [inline]&#xA; sock_close+0x68/0x150 net/socket.c:1421&#xA; __fput+0x2c1/0x660 fs/file_table.c:422&#xA; __fput_sync+0x44/0x60 fs/file_table.c:507&#xA; __do_sys_close fs/open.c:1556 [inline]&#xA; __se_sys_close+0x101/0x1b0 fs/open.c:1541&#xA; __x64_sys_close+0x1f/0x30 fs/open.c:1541&#xA; do_syscall_64+0xd3/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:&#xA; sk_psock_data_ready include/linux/skmsg.h:464 [inline]&#xA; sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555&#xA; sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606&#xA; sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]&#xA; sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202&#xA; unix_read_skb net/unix/af_unix.c:2546 [inline]&#xA; unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682&#xA; sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223&#xA; unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0x140/0x180 net/socket.c:745&#xA; ____sys_sendmsg+0x312/0x410 net/socket.c:2584&#xA; ___sys_sendmsg net/socket.c:2638 [inline]&#xA; __sys_sendmsg+0x1e9/0x280 net/socket.c:2667&#xA; __do_sys_sendmsg net/socket.c:2676 [inline]&#xA; __se_sys_sendmsg net/socket.c:2674 [inline]&#xA; __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674&#xA; do_syscall_64+0xd3/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;value changed: 0xffffffff83d7feb0 -&gt; 0x0000000000000000&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024&#xA;Prior to this, commit 4cd12c6065df (&#34;bpf, sockmap: Fix NULL pointer&#xA;dereference in sk_psock_verdict_data_ready()&#34;) fixed one NULL pointer&#xA;similarly due to no protection of saved_data_ready. Here is another&#xA;different caller causing the same issue because of the same reason. So&#xA;we should protect it with sk_callback_lock read lock because the writer&#xA;side in the sk_psock_drop() uses &#34;write_lock_bh(&amp;sk-&gt;sk_callback_lock);&#34;.&#xA;To avoid errors that could happen in future, I move those two pairs of&#xA;lock into the sk_psock_data_ready(), which is suggested by John Fastabend.&#xA;CVE-2023-52747:In the Linux kernel, the following vulnerability has been resolved:&#xA;IB/hfi1: Restore allocated resources on failed copyout&#xA;Fix a resource leak if an error occurs.&#xA;CVE-2024-36914:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Skip on writeback when it&#39;s not applicable&#xA;[WHY]&#xA;dynamic memory safety error detector (KASAN) catches and generates error&#xA;messages &#34;BUG: KASAN: slab-out-of-bounds&#34; as writeback connector does not&#xA;support certain features which are not initialized.&#xA;[HOW]&#xA;Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.&#xA;CVE-2024-35796:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ll_temac: platform_get_resource replaced by wrong function&#xA;The function platform_get_resource was replaced with&#xA;devm_platform_ioremap_resource_byname and is called using 0 as name.&#xA;This eventually ends up in platform_get_resource_byname in the call&#xA;stack, where it causes a null pointer in strcmp.&#xA;&#x9;if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))&#xA;It should have been replaced with devm_platform_ioremap_resource.&#xA;CVE-2024-35966:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: RFCOMM: Fix not validating setsockopt user input&#xA;syzbot reported rfcomm_sock_setsockopt_old() is copying data without&#xA;checking user input length.&#xA;BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset&#xA;include/linux/sockptr.h:49 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in copy_from_sockptr&#xA;include/linux/sockptr.h:55 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old&#xA;net/bluetooth/rfcomm/sock.c:632 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70&#xA;net/bluetooth/rfcomm/sock.c:673&#xA;Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064&#xA;CVE-2024-35932:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vc4: don&#39;t check if plane-&gt;state-&gt;fb == state-&gt;fb&#xA;Currently, when using non-blocking commits, we can see the following&#xA;kernel warning:&#xA;[  110.908514] ------------[ cut here ]------------&#xA;[  110.908529] refcount_t: underflow; use-after-free.&#xA;[  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0&#xA;[  110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6&#xA;[  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32&#xA;[  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)&#xA;[  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[  110.909132] pc : refcount_dec_not_one+0xb8/0xc0&#xA;[  110.909152] lr : refcount_dec_not_one+0xb4/0xc0&#xA;[  110.909170] sp : ffffffc00913b9c0&#xA;[  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60&#xA;[  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480&#xA;[  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78&#xA;[  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000&#xA;[  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004&#xA;[  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003&#xA;[  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00&#xA;[  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572&#xA;[  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000&#xA;[  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001&#xA;[  110.909434] Call trace:&#xA;[  110.909441]  refcount_dec_not_one+0xb8/0xc0&#xA;[  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]&#xA;[  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]&#xA;[  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]&#xA;[  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]&#xA;[  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]&#xA;[  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]&#xA;[  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]&#xA;[  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]&#xA;[  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]&#xA;[  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]&#xA;[  110.914850]  __arm64_sys_ioctl+0x9c/0xd4&#xA;[  110.914873]  invoke_syscall+0x4c/0x114&#xA;[  110.914897]  el0_svc_common+0xd0/0x118&#xA;[  110.914917]  do_el0_svc+0x38/0xd0&#xA;[  110.914936]  el0_svc+0x30/0x8c&#xA;[  110.914958]  el0t_64_sync_handler+0x84/0xf0&#xA;[  110.914979]  el0t_64_sync+0x18c/0x190&#xA;[  110.914996] ---[ end trace 0000000000000000 ]---&#xA;This happens because, although `prepare_fb` and `cleanup_fb` are&#xA;perfectly balanced, we cannot guarantee consistency in the check&#xA;plane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increase&#xA;the refcount in `prepare_fb` and don&#39;t decrease it in `cleanup_fb`. The&#xA;opposite can also be true.&#xA;In fact, the struct drm_plane .state shouldn&#39;t be accessed directly&#xA;but instead, the `drm_atomic_get_new_plane_state()` helper function should&#xA;be used. So, we could stick to this check, but using&#xA;`drm_atomic_get_new_plane_state()`. But actually, this check is not re&#xA;---truncated---&#xA;CVE-2024-36953:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()&#xA;vgic_v2_parse_attr() is responsible for finding the vCPU that matches&#xA;the user-provided CPUID, which (of course) may not be valid. If the ID&#xA;is invalid, kvm_get_vcpu_by_id() returns NULL, which isn&#39;t handled&#xA;gracefully.&#xA;Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()&#xA;actually returns something and fail the ioctl if not.&#xA;CVE-2024-35965:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: L2CAP: Fix not validating setsockopt user input&#xA;Check user input length before copying data.&#xA;CVE-2024-36923:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/9p: fix uninitialized values during inode evict&#xA;If an iget fails due to not being able to retrieve information&#xA;from the server then the inode structure is only partially&#xA;initialized.  When the inode gets evicted, references to&#xA;uninitialized structures (like fscache cookies) were being&#xA;made.&#xA;This patch checks for a bad_inode before doing anything other&#xA;than clearing the inode from the cache.  Since the inode is&#xA;bad, it shouldn&#39;t have any state associated with it that needs&#xA;to be written back (and there really isn&#39;t a way to complete&#xA;those anyways).&#xA;CVE-2024-26936:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: validate request buffer size in smb2_allocate_rsp_buf()&#xA;The response buffer should be allocated in smb2_allocate_rsp_buf&#xA;before validating request. But the fields in payload as well as smb2 header&#xA;is used in smb2_allocate_rsp_buf(). This patch add simple buffer size&#xA;validation to avoid potencial out-of-bounds in request buffer.&#xA;CVE-2023-39179:This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication is not required to exploit this vulnerability. However, only systems with ksmbd enabled are vulnerable.&#xA;The specific flaw exists within the handling of SMB2 read requests. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the kernel.&#xA;CVE-2024-26947:In the Linux kernel, the following vulnerability has been resolved:&#xA;ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses&#xA;Since commit a4d5613c4dc6 (&#34;arm: extend pfn_valid to take into account&#xA;freed memory map alignment&#34;) changes the semantics of pfn_valid() to check&#xA;presence of the memory map for a PFN. A valid page for an address which&#xA;is reserved but not mapped by the kernel[1], the system crashed during&#xA;some uio test with the following memory layout:&#xA; node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]&#xA; node   0: [mem 0x00000000d0000000-0x00000000da1fffff]&#xA; the uio layout is：0xc0900000, 0x100000&#xA;the crash backtrace like:&#xA;  Unable to handle kernel paging request at virtual address bff00000&#xA;  [...]&#xA;  CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1&#xA;  Hardware name: Generic DT based system&#xA;  PC is at b15_flush_kern_dcache_area+0x24/0x3c&#xA;  LR is at __sync_icache_dcache+0x6c/0x98&#xA;  [...]&#xA;   (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)&#xA;   (__sync_icache_dcache) from (set_pte_at+0x28/0x54)&#xA;   (set_pte_at) from (remap_pfn_range+0x1a0/0x274)&#xA;   (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])&#xA;   (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)&#xA;   (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)&#xA;   (__do_mmap_mm) from (do_mmap+0x50/0x58)&#xA;   (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)&#xA;   (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)&#xA;   (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)&#xA;  Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)&#xA;  ---[ end trace 09cf0734c3805d52 ]---&#xA;  Kernel panic - not syncing: Fatal exception&#xA;So check if PG_reserved was set to solve this issue.&#xA;[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/&#xA;CVE-2023-52810:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/jfs: Add check for negative db_l2nbperpage&#xA;l2nbperpage is log2(number of blks per page), and the minimum legal&#xA;value should be 0, not negative.&#xA;In the case of l2nbperpage being negative, an error will occur&#xA;when subsequently used as shift exponent.&#xA;Syzbot reported this bug:&#xA;UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12&#xA;shift exponent -16777216 is negative&#xA;CVE-2023-52791:In the Linux kernel, the following vulnerability has been resolved:&#xA;i2c: core: Run atomic i2c xfer when !preemptible&#xA;Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is&#xA;disabled. However, non-atomic i2c transfers require preemption (e.g. in&#xA;wait_for_completion() while waiting for the DMA).&#xA;panic() calls preempt_disable_notrace() before calling&#xA;emergency_restart(). Therefore, if an i2c device is used for the&#xA;restart, the xfer should be atomic. This avoids warnings like:&#xA;[   12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0&#xA;[   12.676926] Voluntary context switch within RCU read-side critical section!&#xA;...&#xA;[   12.742376]  schedule_timeout from wait_for_completion_timeout+0x90/0x114&#xA;[   12.749179]  wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70&#xA;...&#xA;[   12.994527]  atomic_notifier_call_chain from machine_restart+0x34/0x58&#xA;[   13.001050]  machine_restart from panic+0x2a8/0x32c&#xA;Use !preemptible() instead, which is basically the same check as&#xA;pre-v5.2.&#xA;CVE-2024-26935:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: core: Fix unremoved procfs host directory regression&#xA;Commit fc663711b944 (&#34;scsi: core: Remove the /proc/scsi/${proc_name}&#xA;directory earlier&#34;) fixed a bug related to modules loading/unloading, by&#xA;adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led&#xA;to a potential duplicate call to the hostdir_rm() routine, since it&#39;s also&#xA;called from scsi_host_dev_release(). That triggered a regression report,&#xA;which was then fixed by commit be03df3d4bfe (&#34;scsi: core: Fix a procfs host&#xA;directory removal regression&#34;). The fix just dropped the hostdir_rm() call&#xA;from dev_release().&#xA;But it happens that this proc directory is created on scsi_host_alloc(),&#xA;and that function &#34;pairs&#34; with scsi_host_dev_release(), while&#xA;scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the&#xA;reason for removing the proc directory on dev_release() was meant to cover&#xA;cases in which a SCSI host structure was allocated, but the call to&#xA;scsi_add_host() didn&#39;t happen. And that pattern happens to exist in some&#xA;error paths, for example.&#xA;Syzkaller causes that by using USB raw gadget device, error&#39;ing on&#xA;usb-storage driver, at usb_stor_probe2(). By checking that path, we can see&#xA;that the BadDevice label leads to a scsi_host_put() after a SCSI host&#xA;allocation, but there&#39;s no call to scsi_add_host() in such path. That leads&#xA;to messages like this in dmesg (and a leak of the SCSI host proc&#xA;structure):&#xA;usb-storage 4-1:87.51: USB Mass Storage device detected&#xA;proc_dir_entry &#39;scsi/usb-storage&#39; already registered&#xA;WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376&#xA;The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),&#xA;but guard that with the state check for SHOST_CREATED; there is even a&#xA;comment in scsi_host_dev_release() detailing that: such conditional is&#xA;meant for cases where the SCSI host was allocated but there was no calls to&#xA;{add,remove}_host(), like the usb-storage case.&#xA;This is what we propose here and with that, the error path of usb-storage&#xA;does not trigger the warning anymore.&#xA;CVE-2024-35947:In the Linux kernel, the following vulnerability has been resolved:&#xA;dyndbg: fix old BUG_ON in &gt;control parser&#xA;Fix a BUG_ON from 2009.  Even if it looks &#34;unreachable&#34; (I didn&#39;t&#xA;really look), lets make sure by removing it, doing pr_err and return&#xA;-EINVAL instead.&#xA;CVE-2024-36969:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix division by zero in setup_dsc_config&#xA;When slice_height is 0, the division by slice_height in the calculation&#xA;of the number of slices will cause a division by zero driver crash. This&#xA;leaves the kernel in a state that requires a reboot. This patch adds a&#xA;check to avoid the division by zero.&#xA;The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on&#xA;a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor&#xA;connected via Thunderbolt. The amdgpu driver crashed with this exception&#xA;when I rebooted the system with the monitor connected.&#xA;kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)&#xA;kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)&#xA;kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu&#xA;kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)&#xA;kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu&#xA;kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))&#xA;kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu&#xA;kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)&#xA;kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu&#xA;kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu&#xA;After applying this patch, the driver no longer crashes when the monitor&#xA;is connected and the system is rebooted. I believe this is the same&#xA;issue reported for 3113.&#xA;CVE-2024-38601:In the Linux kernel, the following vulnerability has been resolved:&#xA;ring-buffer: Fix a race between readers and resize checks&#xA;The reader code in rb_get_reader_page() swaps a new reader page into the&#xA;ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the&#xA;new page. Following that, if the operation is successful,&#xA;old-&gt;list.next-&gt;prev gets updated too. This means the underlying&#xA;doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or&#xA;page-&gt;next-&gt;prev might not be equal back to page for some page in the&#xA;ring buffer.&#xA;The resize operation in ring_buffer_resize() can be invoked in parallel.&#xA;It calls rb_check_pages() which can detect the described inconsistency&#xA;and stop further tracing:&#xA;[  190.271762] ------------[ cut here ]------------&#xA;[  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0&#xA;[  190.271789] Modules linked in: [...]&#xA;[  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1&#xA;[  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f&#xA;[  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014&#xA;[  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0&#xA;[  190.272023] Code: [...]&#xA;[  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206&#xA;[  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80&#xA;[  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700&#xA;[  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000&#xA;[  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720&#xA;[  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000&#xA;[  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000&#xA;[  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0&#xA;[  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  190.272077] Call Trace:&#xA;[  190.272098]  &lt;TASK&gt;&#xA;[  190.272189]  ring_buffer_resize+0x2ab/0x460&#xA;[  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0&#xA;[  190.272206]  tracing_resize_ring_buffer+0x65/0x90&#xA;[  190.272216]  tracing_entries_write+0x74/0xc0&#xA;[  190.272225]  vfs_write+0xf5/0x420&#xA;[  190.272248]  ksys_write+0x67/0xe0&#xA;[  190.272256]  do_syscall_64+0x82/0x170&#xA;[  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[  190.272373] RIP: 0033:0x7f1bd657d263&#xA;[  190.272381] Code: [...]&#xA;[  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;[  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263&#xA;[  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001&#xA;[  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000&#xA;[  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500&#xA;[  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002&#xA;[  190.272412]  &lt;/TASK&gt;&#xA;[  190.272414] ---[ end trace 0000000000000000 ]---&#xA;Note that ring_buffer_resize() calls rb_check_pages() only if the parent&#xA;trace_buffer has recording disabled. Recent commit d78ab792705c&#xA;(&#34;tracing: Stop current tracer when resizing buffer&#34;) causes that it is&#xA;now always the case which makes it more likely to experience this issue.&#xA;The window to hit this race is nonetheless very small. To help&#xA;reproducing it, one can add a delay loop in rb_get_reader_page():&#xA; ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);&#xA; if (!ret)&#xA; &#x9;goto spin;&#xA; for (unsigned i = 0; i &lt; 1U &lt;&lt; 26; i++)  /* inserted delay loop */&#xA; &#x9;__asm__ __volatile__ (&#34;&#34; : : : &#34;memory&#34;);&#xA; rb_list_head(reader-&gt;list.next)-&gt;prev = &amp;cpu_buffer-&gt;reader_page-&gt;list;&#xA;.. &#xA;---truncated---&#xA;CVE-2024-38549:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/mediatek: Add 0 size check to mtk_drm_gem_obj&#xA;Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object&#xA;of 0 bytes. Currently, no such check exists and the kernel will panic if&#xA;a userspace application attempts to allocate a 0x0 GBM buffer.&#xA;Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and&#xA;verifying that we now return EINVAL.&#xA;CVE-2024-35811:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach&#xA;This is the candidate patch of CVE-2023-47233 :&#xA;https://nvd.nist.gov/vuln/detail/CVE-2023-47233&#xA;In brcm80211 driver,it starts with the following invoking chain&#xA;to start init a timeout worker:&#xA;-&gt;brcmf_usb_probe&#xA;  -&gt;brcmf_usb_probe_cb&#xA;    -&gt;brcmf_attach&#xA;      -&gt;brcmf_bus_started&#xA;        -&gt;brcmf_cfg80211_attach&#xA;          -&gt;wl_init_priv&#xA;            -&gt;brcmf_init_escan&#xA;              -&gt;INIT_WORK(&amp;cfg-&gt;escan_timeout_work,&#xA;&#x9;&#x9;  brcmf_cfg80211_escan_timeout_worker);&#xA;If we disconnect the USB by hotplug, it will call&#xA;brcmf_usb_disconnect to make cleanup. The invoking chain is :&#xA;brcmf_usb_disconnect&#xA;  -&gt;brcmf_usb_disconnect_cb&#xA;    -&gt;brcmf_detach&#xA;      -&gt;brcmf_cfg80211_detach&#xA;        -&gt;kfree(cfg);&#xA;While the timeout woker may still be running. This will cause&#xA;a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.&#xA;Fix it by deleting the timer and canceling the worker in&#xA;brcmf_cfg80211_detach.&#xA;[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]&#xA;CVE-2024-36978:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: sched: sch_multiq: fix possible OOB write in multiq_tune()&#xA;q-&gt;bands will be assigned to qopt-&gt;bands to execute subsequent code logic&#xA;after kmalloc. So the old q-&gt;bands should not be used in kmalloc.&#xA;Otherwise, an out-of-bounds write will occur.&#xA;CVE-2024-38569:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group&#xA;The perf tool allows users to create event groups through following&#xA;cmd [1], but the driver does not check whether the array index is out of&#xA;bounds when writing data to the event_group array. If the number of events&#xA;in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write&#xA;overflow of event_group array occurs.&#xA;Add array index check to fix the possible array out of bounds violation,&#xA;and return directly when write new events are written to array bounds.&#xA;There are 9 different events in an event_group.&#xA;[1] perf stat -e &#39;{pmu/event1/, ... ,pmu/event9/}&#39;&#xA;CVE-2024-38538:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: bridge: xmit: make sure we have at least eth header len bytes&#xA;syzbot triggered an uninit value[1] error in bridge device&#39;s xmit path&#xA;by sending a short (less than ETH_HLEN bytes) skb. To fix it check if&#xA;we can actually pull that amount instead of assuming.&#xA;Tested with dropwatch:&#xA; drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)&#xA; origin: software&#xA; timestamp: Mon May 13 11:31:53 2024 778214037 nsec&#xA; protocol: 0x88a8&#xA; length: 2&#xA; original length: 2&#xA; drop reason: PKT_TOO_SMALL&#xA;[1]&#xA;BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65&#xA; br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65&#xA; __netdev_start_xmit include/linux/netdevice.h:4903 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:4917 [inline]&#xA; xmit_one net/core/dev.c:3531 [inline]&#xA; dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547&#xA; __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341&#xA; dev_queue_xmit include/linux/netdevice.h:3091 [inline]&#xA; __bpf_tx_skb net/core/filter.c:2136 [inline]&#xA; __bpf_redirect_common net/core/filter.c:2180 [inline]&#xA; __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187&#xA; ____bpf_clone_redirect net/core/filter.c:2460 [inline]&#xA; bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432&#xA; ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997&#xA; __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238&#xA; bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]&#xA; __bpf_prog_run include/linux/filter.h:657 [inline]&#xA; bpf_prog_run include/linux/filter.h:664 [inline]&#xA; bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425&#xA; bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058&#xA; bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269&#xA; __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678&#xA; __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]&#xA; __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]&#xA; __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765&#xA; x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-38596:In the Linux kernel, the following vulnerability has been resolved:&#xA;af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg&#xA;A data-race condition has been identified in af_unix. In one data path,&#xA;the write function unix_release_sock() atomically writes to&#xA;sk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,&#xA;unix_stream_sendmsg() does not read it atomically. Consequently, this&#xA;issue is causing the following KCSAN splat to occur:&#xA;&#x9;BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg&#xA;&#x9;write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:&#xA;&#x9;unix_release_sock (net/unix/af_unix.c:640)&#xA;&#x9;unix_release (net/unix/af_unix.c:1050)&#xA;&#x9;sock_close (net/socket.c:659 net/socket.c:1421)&#xA;&#x9;__fput (fs/file_table.c:422)&#xA;&#x9;__fput_sync (fs/file_table.c:508)&#xA;&#x9;__se_sys_close (fs/open.c:1559 fs/open.c:1541)&#xA;&#x9;__x64_sys_close (fs/open.c:1541)&#xA;&#x9;x64_sys_call (arch/x86/entry/syscall_64.c:33)&#xA;&#x9;do_syscall_64 (arch/x86/entry/common.c:?)&#xA;&#x9;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;&#x9;read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:&#xA;&#x9;unix_stream_sendmsg (net/unix/af_unix.c:2273)&#xA;&#x9;__sock_sendmsg (net/socket.c:730 net/socket.c:745)&#xA;&#x9;____sys_sendmsg (net/socket.c:2584)&#xA;&#x9;__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)&#xA;&#x9;__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)&#xA;&#x9;x64_sys_call (arch/x86/entry/syscall_64.c:33)&#xA;&#x9;do_syscall_64 (arch/x86/entry/common.c:?)&#xA;&#x9;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;&#x9;value changed: 0x01 -&gt; 0x03&#xA;The line numbers are related to commit dd5a440a31fa (&#34;Linux 6.9-rc7&#34;).&#xA;Commit e1d09c2c2f57 (&#34;af_unix: Fix data races around sk-&gt;sk_shutdown.&#34;)&#xA;addressed a comparable issue in the past regarding sk-&gt;sk_shutdown.&#xA;However, it overlooked resolving this particular data path.&#xA;This patch only offending unix_stream_sendmsg() function, since the&#xA;other reads seem to be protected by unix_state_lock() as discussed in&#xA;CVE-2024-36974:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP&#xA;If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,&#xA;taprio_parse_mqprio_opt() must validate it, or userspace&#xA;can inject arbitrary data to the kernel, the second time&#xA;taprio_change() is called.&#xA;First call (with valid attributes) sets dev-&gt;num_tc&#xA;to a non zero value.&#xA;Second call (with arbitrary mqprio attributes)&#xA;returns early from taprio_parse_mqprio_opt()&#xA;and bad things can happen.&#xA;CVE-2023-52696:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/powernv: Add a null pointer check in opal_powercap_init()&#xA;kasprintf() returns a pointer to dynamically allocated memory&#xA;which can be NULL upon failure.&#xA;CVE-2024-26661:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add NULL test for &#39;timing generator&#39; in &#39;dcn21_set_pipe()&#39;&#xA;In &#34;u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;&#34;&#xA;pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller to&#xA;ensure the tg is not NULL.&#xA;CVE-2024-38634:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: max3100: Lock port-&gt;lock when calling uart_handle_cts_change()&#xA;uart_handle_cts_change() has to be called with port lock taken,&#xA;Since we run it in a separate work, the lock may not be taken at&#xA;the time of running. Make sure that it&#39;s taken by explicitly doing&#xA;that. Without it we got a splat:&#xA;  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0&#xA;  ...&#xA;  Workqueue: max3100-0 max3100_work [max3100]&#xA;  RIP: 0010:uart_handle_cts_change+0xa6/0xb0&#xA;  ...&#xA;   max3100_handlerx+0xc5/0x110 [max3100]&#xA;   max3100_work+0x12a/0x340 [max3100]&#xA;CVE-2024-38605:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: core: Fix NULL module pointer assignment at card init&#xA;The commit 81033c6b584b (&#34;ALSA: core: Warn on empty module&#34;)&#xA;introduced a WARN_ON() for a NULL module pointer passed at snd_card&#xA;object creation, and it also wraps the code around it with &#39;#ifdef&#xA;MODULE&#39;.  This works in most cases, but the devils are always in&#xA;details.  &#34;MODULE&#34; is defined when the target code (i.e. the sound&#xA;core) is built as a module; but this doesn&#39;t mean that the caller is&#xA;also built-in or not.  Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),&#xA;the passed module pointer is ignored even if it&#39;s non-NULL, and&#xA;card-&gt;module remains as NULL.  This would result in the missing module&#xA;reference up/down at the device open/close, leading to a race with the&#xA;code execution after the module removal.&#xA;For addressing the bug, move the assignment of card-&gt;module again out&#xA;of ifdef.  The WARN_ON() is still wrapped with ifdef because the&#xA;module can be really NULL when all sound drivers are built-in.&#xA;Note that we keep &#39;ifdef MODULE&#39; for WARN_ON(), otherwise it would&#xA;lead to a false-positive NULL module check.  Admittedly it won&#39;t catch&#xA;perfectly, i.e. no check is performed when CONFIG_SND=y.  But, it&#39;s no&#xA;real problem as it&#39;s only for debugging, and the condition is pretty&#xA;rare.&#xA;CVE-2024-38545:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/hns: Fix UAF for cq async event&#xA;The refcount of CQ is not protected by locks. When CQ asynchronous&#xA;events and CQ destruction are concurrent, CQ may have been released,&#xA;which will cause UAF.&#xA;Use the xa_lock() to protect the CQ refcount.&#xA;CVE-2024-38633:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: max3100: Update uart_driver_registered on driver removal&#xA;The removal of the last MAX3100 device triggers the removal of&#xA;the driver. However, code doesn&#39;t update the respective global&#xA;variable and after insmod — rmmod — insmod cycle the kernel&#xA;oopses:&#xA;  max3100 spi-PRP0001:01: max3100_probe: adding port 0&#xA;  BUG: kernel NULL pointer dereference, address: 0000000000000408&#xA;  ...&#xA;  RIP: 0010:serial_core_register_port+0xa0/0x840&#xA;  ...&#xA;   max3100_probe+0x1b6/0x280 [max3100]&#xA;   spi_probe+0x8d/0xb0&#xA;Update the actual state so next time UART driver will be registered&#xA;again.&#xA;Hugo also noticed, that the error path in the probe also affected&#xA;by having the variable set, and not cleared. Instead of clearing it&#xA;move the assignment after the successfull uart_register_driver() call.&#xA;CVE-2024-38632:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfio/pci: fix potential memory leak in vfio_intx_enable()&#xA;If vfio_irq_ctx_alloc() failed will lead to &#39;name&#39; memory leak.&#xA;CVE-2024-38591:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/hns: Fix deadlock on SRQ async events.&#xA;xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/&#xA;xa_erase_irq() to avoid deadlock.&#xA;CVE-2024-31076:In the Linux kernel, the following vulnerability has been resolved:&#xA;genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&#xA;The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of&#xA;interrupt affinity reconfiguration via procfs. Instead, the change is&#xA;deferred until the next instance of the interrupt being triggered on the&#xA;original CPU.&#xA;When the interrupt next triggers on the original CPU, the new affinity is&#xA;enforced within __irq_move_irq(). A vector is allocated from the new CPU,&#xA;but the old vector on the original CPU remains and is not immediately&#xA;reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming&#xA;process is delayed until the next trigger of the interrupt on the new CPU.&#xA;Upon the subsequent triggering of the interrupt on the new CPU,&#xA;irq_complete_move() adds a task to the old CPU&#39;s vector_cleanup list if it&#xA;remains online. Subsequently, the timer on the old CPU iterates over its&#xA;vector_cleanup list, reclaiming old vectors.&#xA;However, a rare scenario arises if the old CPU is outgoing before the&#xA;interrupt triggers again on the new CPU.&#xA;In that case irq_force_complete_move() is not invoked on the outgoing CPU&#xA;to reclaim the old apicd-&gt;prev_vector because the interrupt isn&#39;t currently&#xA;affine to the outgoing CPU, and irq_needs_fixup() returns false. Even&#xA;though __vector_schedule_cleanup() is later called on the new CPU, it&#xA;doesn&#39;t reclaim apicd-&gt;prev_vector; instead, it simply resets both&#xA;apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.&#xA;As a result, the vector remains unreclaimed in vector_matrix, leading to a&#xA;CPU vector leak.&#xA;To address this issue, move the invocation of irq_force_complete_move()&#xA;before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the&#xA;interrupt is currently or used to be affine to the outgoing CPU.&#xA;Additionally, reclaim the vector in __vector_schedule_cleanup() as well,&#xA;following a warning message, although theoretically it should never see&#xA;apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.&#xA;CVE-2024-35955:In the Linux kernel, the following vulnerability has been resolved:&#xA;kprobes: Fix possible use-after-free issue on kprobe registration&#xA;When unloading a module, its state is changing MODULE_STATE_LIVE -&gt;&#xA; MODULE_STATE_GOING -&gt; MODULE_STATE_UNFORMED. Each change will take&#xA;a time. `is_module_text_address()` and `__module_text_address()`&#xA;works with MODULE_STATE_LIVE and MODULE_STATE_GOING.&#xA;If we use `is_module_text_address()` and `__module_text_address()`&#xA;separately, there is a chance that the first one is succeeded but the&#xA;next one is failed because module-&gt;state becomes MODULE_STATE_UNFORMED&#xA;between those operations.&#xA;In `check_kprobe_address_safe()`, if the second `__module_text_address()`&#xA;is failed, that is ignored because it expected a kernel_text address.&#xA;But it may have failed simply because module-&gt;state has been changed&#xA;to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify&#xA;non-exist module text address (use-after-free).&#xA;To fix this problem, we should not use separated `is_module_text_address()`&#xA;and `__module_text_address()`, but use only `__module_text_address()`&#xA;once and do `try_module_get(module)` which is only available with&#xA;MODULE_STATE_LIVE.&#xA;CVE-2021-47381:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: SOF: Fix DSP oops stack dump output contents&#xA;Fix @buf arg given to hex_dump_to_buffer() and stack address used&#xA;in dump error output.&#xA;CVE-2024-38555:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Discard command completions in internal error&#xA;Fix use after free when FW completion arrives while device is in&#xA;internal error state. Avoid calling completion handler in this case,&#xA;since the device will flush the command interface and trigger all&#xA;completions manually.&#xA;Kernel log:&#xA;------------[ cut here ]------------&#xA;refcount_t: underflow; use-after-free.&#xA;...&#xA;RIP: 0010:refcount_warn_saturate+0xd8/0xe0&#xA;...&#xA;Call Trace:&#xA;&lt;IRQ&gt;&#xA;? __warn+0x79/0x120&#xA;? refcount_warn_saturate+0xd8/0xe0&#xA;? report_bug+0x17c/0x190&#xA;? handle_bug+0x3c/0x60&#xA;? exc_invalid_op+0x14/0x70&#xA;? asm_exc_invalid_op+0x16/0x20&#xA;? refcount_warn_saturate+0xd8/0xe0&#xA;cmd_ent_put+0x13b/0x160 [mlx5_core]&#xA;mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]&#xA;cmd_comp_notifier+0x1f/0x30 [mlx5_core]&#xA;notifier_call_chain+0x35/0xb0&#xA;atomic_notifier_call_chain+0x16/0x20&#xA;mlx5_eq_async_int+0xf6/0x290 [mlx5_core]&#xA;notifier_call_chain+0x35/0xb0&#xA;atomic_notifier_call_chain+0x16/0x20&#xA;irq_int_handler+0x19/0x30 [mlx5_core]&#xA;__handle_irq_event_percpu+0x4b/0x160&#xA;handle_irq_event+0x2e/0x80&#xA;handle_edge_irq+0x98/0x230&#xA;__common_interrupt+0x3b/0xa0&#xA;common_interrupt+0x7b/0xa0&#xA;&lt;/IRQ&gt;&#xA;&lt;TASK&gt;&#xA;asm_common_interrupt+0x22/0x40&#xA;CVE-2024-38577:In the Linux kernel, the following vulnerability has been resolved:&#xA;rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow&#xA;There is a possibility of buffer overflow in&#xA;show_rcu_tasks_trace_gp_kthread() if counters, passed&#xA;to sprintf() are huge. Counter numbers, needed for this&#xA;are unrealistically high, but buffer overflow is still&#xA;possible.&#xA;Use snprintf() with buffer size instead of sprintf().&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-38599:In the Linux kernel, the following vulnerability has been resolved:&#xA;jffs2: prevent xattr node from overflowing the eraseblock&#xA;Add a check to make sure that the requested xattr node size is no larger&#xA;than the eraseblock minus the cleanmarker.&#xA;Unlike the usual inode nodes, the xattr nodes aren&#39;t split into parts&#xA;and spread across multiple eraseblocks, which means that a xattr node&#xA;must not occupy more than one eraseblock. If the requested xattr value is&#xA;too large, the xattr node can spill onto the next eraseblock, overwriting&#xA;the nodes and causing errors such as:&#xA;jffs2: argh. node added in wrong place at 0x0000b050(2)&#xA;jffs2: nextblock 0x0000a000, expected at 0000b00c&#xA;jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000&#xA;jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed&#xA;at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}&#xA;jffs2: Node at 0x0000000c with length 0x00001044 would run over the&#xA;end of the erase block&#xA;jffs2: Perhaps the file system was created with the wrong erase size?&#xA;jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found&#xA;at 0x00000010: 0x1044 instead&#xA;This breaks the filesystem and can lead to KASAN crashes such as:&#xA;BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0&#xA;Read of size 4 at addr ffff88802c31e914 by task repro/830&#xA;CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),&#xA;BIOS Arch Linux 1.16.3-1-1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0xc6/0x120&#xA; print_report+0xc4/0x620&#xA; ? __virt_addr_valid+0x308/0x5b0&#xA; kasan_report+0xc1/0xf0&#xA; ? jffs2_sum_add_kvec+0x125e/0x15d0&#xA; ? jffs2_sum_add_kvec+0x125e/0x15d0&#xA; jffs2_sum_add_kvec+0x125e/0x15d0&#xA; jffs2_flash_direct_writev+0xa8/0xd0&#xA; jffs2_flash_writev+0x9c9/0xef0&#xA; ? __x64_sys_setxattr+0xc4/0x160&#xA; ? do_syscall_64+0x69/0x140&#xA; ? entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA; [...]&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2024-38564:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE&#xA;bpf_prog_attach uses attach_type_to_prog_type to enforce proper&#xA;attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses&#xA;bpf_prog_get and relies on bpf_prog_attach_check_attach_type&#xA;to properly verify prog_type &lt;&gt; attach_type association.&#xA;Add missing attach_type enforcement for the link_create case.&#xA;Otherwise, it&#39;s currently possible to attach cgroup_skb prog&#xA;types to other cgroup hooks.&#xA;CVE-2024-38630:In the Linux kernel, the following vulnerability has been resolved:&#xA;watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger&#xA;When the cpu5wdt module is removing, the origin code uses del_timer() to&#xA;de-activate the timer. If the timer handler is running, del_timer() could&#xA;not stop it and will return directly. If the port region is released by&#xA;release_region() and then the timer handler cpu5wdt_trigger() calls outb()&#xA;to write into the region that is released, the use-after-free bug will&#xA;happen.&#xA;Change del_timer() to timer_shutdown_sync() in order that the timer handler&#xA;could be finished before the port region is released.&#xA;CVE-2024-38624:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow&#xA;For example, in the expression:&#xA;&#x9;vbo = 2 * vbo + skip&#xA;CVE-2024-38589:In the Linux kernel, the following vulnerability has been resolved:&#xA;netrom: fix possible dead-lock in nr_rt_ioctl()&#xA;syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]&#xA;Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)&#xA;[1]&#xA;WARNING: possible circular locking dependency detected&#xA;6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted&#xA;------------------------------------------------------&#xA;syz-executor350/5129 is trying to acquire lock:&#xA; ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA; ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]&#xA; ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]&#xA; ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697&#xA;but task is already holding lock:&#xA; ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA; ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]&#xA; ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697&#xA;which lock already depends on the new lock.&#xA;the existing dependency chain (in reverse order) is:&#xA;-&gt; #1 (nr_node_list_lock){+...}-{2:2}:&#xA;        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754&#xA;        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]&#xA;        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178&#xA;        spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA;        nr_remove_node net/netrom/nr_route.c:299 [inline]&#xA;        nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355&#xA;        nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683&#xA;        sock_do_ioctl+0x158/0x460 net/socket.c:1222&#xA;        sock_ioctl+0x629/0x8e0 net/socket.c:1341&#xA;        vfs_ioctl fs/ioctl.c:51 [inline]&#xA;        __do_sys_ioctl fs/ioctl.c:904 [inline]&#xA;        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890&#xA;        do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA;       entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;-&gt; #0 (&amp;nr_node-&gt;node_lock){+...}-{2:2}:&#xA;        check_prev_add kernel/locking/lockdep.c:3134 [inline]&#xA;        check_prevs_add kernel/locking/lockdep.c:3253 [inline]&#xA;        validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869&#xA;        __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137&#xA;        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754&#xA;        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]&#xA;        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178&#xA;        spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA;        nr_node_lock include/net/netrom.h:152 [inline]&#xA;        nr_dec_obs net/netrom/nr_route.c:464 [inline]&#xA;        nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697&#xA;        sock_do_ioctl+0x158/0x460 net/socket.c:1222&#xA;        sock_ioctl+0x629/0x8e0 net/socket.c:1341&#xA;        vfs_ioctl fs/ioctl.c:51 [inline]&#xA;        __do_sys_ioctl fs/ioctl.c:904 [inline]&#xA;        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890&#xA;        do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA;       entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;other info that might help us debug this:&#xA; Possible unsafe locking scenario:&#xA;       CPU0                    CPU1&#xA;       ----                    ----&#xA;  lock(nr_node_list_lock);&#xA;                               lock(&amp;nr_node-&gt;node_lock);&#xA;                               lock(nr_node_list_lock);&#xA;  lock(&amp;nr_node-&gt;node_lock);&#xA; *** DEADLOCK ***&#xA;1 lock held by syz-executor350/5129:&#xA;  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA;  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]&#xA;  #0: ffffffff8f70&#xA;---truncated---&#xA;CVE-2024-35969:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr&#xA;Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it&#xA;still means hlist_for_each_entry_rcu can return an item that got removed&#xA;from the list. The memory itself of such item is not freed thanks to RCU&#xA;but nothing guarantees the actual content of the memory is sane.&#xA;In particular, the reference count can be zero. This can happen if&#xA;ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry&#xA;from inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops all&#xA;references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough&#xA;timing, this can happen:&#xA;1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.&#xA;2. Then, the whole ipv6_del_addr is executed for the given entry. The&#xA;   reference count drops to zero and kfree_rcu is scheduled.&#xA;3. ipv6_get_ifaddr continues and tries to increments the reference count&#xA;   (in6_ifa_hold).&#xA;4. The rcu is unlocked and the entry is freed.&#xA;5. The freed entry is returned.&#xA;Prevent increasing of the reference count in such case. The name&#xA;in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.&#xA;[   41.506330] refcount_t: addition on 0; use-after-free.&#xA;[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130&#xA;[   41.507413] Modules linked in: veth bridge stp llc&#xA;[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14&#xA;[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130&#xA;[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 &lt;0f&gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff&#xA;[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282&#xA;[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000&#xA;[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900&#xA;[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff&#xA;[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000&#xA;[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48&#xA;[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000&#xA;[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0&#xA;[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[   41.516799] Call Trace:&#xA;[   41.517037]  &lt;TASK&gt;&#xA;[   41.517249]  ? __warn+0x7b/0x120&#xA;[   41.517535]  ? refcount_warn_saturate+0xa5/0x130&#xA;[   41.517923]  ? report_bug+0x164/0x190&#xA;[   41.518240]  ? handle_bug+0x3d/0x70&#xA;[   41.518541]  ? exc_invalid_op+0x17/0x70&#xA;[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[   41.521325]  ? refcount_warn_saturate+0xa5/0x130&#xA;[   41.521708]  ipv6_get_ifaddr+0xda/0xe0&#xA;[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0&#xA;[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10&#xA;[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0&#xA;[   41.523102]  ? netlink_unicast+0x30f/0x390&#xA;[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10&#xA;[   41.523832]  netlink_rcv_skb+0x53/0x100&#xA;[   41.524157]  netlink_unicast+0x23b/0x390&#xA;[   41.524484]  netlink_sendmsg+0x1f2/0x440&#xA;[   41.524826]  __sys_sendto+0x1d8/0x1f0&#xA;[   41.525145]  __x64_sys_sendto+0x1f/0x30&#xA;[   41.525467]  do_syscall_64+0xa5/0x1b0&#xA;[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a&#xA;[   41.526213] RIP: 0033:0x7fbc4cfcea9a&#xA;[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89&#xA;[   41.527942] RSP: 002b:00007f&#xA;---truncated---&#xA;CVE-2024-38544:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt&#xA;In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the&#xA;resp_pkts queue and then a decision is made whether to run the completer&#xA;task inline or schedule it. Finally the skb is dereferenced to bump a &#39;hw&#39;&#xA;performance counter. This is wrong because if the completer task is&#xA;already running in a separate thread it may have already processed the skb&#xA;and freed it which can cause a seg fault.  This has been observed&#xA;infrequently in testing at high scale.&#xA;This patch fixes this by changing the order of enqueuing the packet until&#xA;after the counter is accessed.&#xA;CVE-2022-48772:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: lgdt3306a: Add a check against null-pointer-def&#xA;The driver should check whether the client provides the platform_data.&#xA;The following log reveals it:&#xA;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40&#xA;[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414&#xA;[   29.612820] Call Trace:&#xA;[   29.613030]  &lt;TASK&gt;&#xA;[   29.613201]  dump_stack_lvl+0x56/0x6f&#xA;[   29.613496]  ? kmemdup+0x30/0x40&#xA;[   29.613754]  print_report.cold+0x494/0x6b7&#xA;[   29.614082]  ? kmemdup+0x30/0x40&#xA;[   29.614340]  kasan_report+0x8a/0x190&#xA;[   29.614628]  ? kmemdup+0x30/0x40&#xA;[   29.614888]  kasan_check_range+0x14d/0x1d0&#xA;[   29.615213]  memcpy+0x20/0x60&#xA;[   29.615454]  kmemdup+0x30/0x40&#xA;[   29.615700]  lgdt3306a_probe+0x52/0x310&#xA;[   29.616339]  i2c_device_probe+0x951/0xa90&#xA;CVE-2024-39276:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix mb_cache_entry&#39;s e_refcnt leak in ext4_xattr_block_cache_find()&#xA;Syzbot reports a warning as follows: ============================================&#xA;WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290&#xA;Modules linked in:&#xA;CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7&#xA;RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375&#xA; generic_shutdown_super+0x136/0x2d0 fs/super.c:641&#xA; kill_block_super+0x44/0x90 fs/super.c:1675&#xA; ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================&#xA;This is because when finding an entry in ext4_xattr_block_cache_find(), if&#xA;ext4_sb_bread() returns -ENOMEM, the ce&#39;s e_refcnt, which has already grown&#xA;in the __entry_find(), won&#39;t be put away, and eventually trigger the above&#xA;issue in mb_cache_destroy() due to reference count leakage.&#xA;So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.&#xA;CVE-2024-38625:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Check &#39;folio&#39; pointer for NULL&#xA;It can be NULL if bmap is called.&#xA;CVE-2024-38552:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix potential index out of bounds in color transformation function&#xA;Fixes index out of bounds issue in the color transformation function.&#xA;The issue could occur when the index &#39;i&#39; exceeds the number of transfer&#xA;function points (TRANSFER_FUNC_POINTS).&#xA;The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the&#xA;transfer function points. If &#39;i&#39; is out of bounds, an error message is&#xA;logged and the function returns false to indicate an error.&#xA;Reported by smatch:&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max&#xA;CVE-2024-37354:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix crash on racing fsync and size-extending write into prealloc&#xA;We have been seeing crashes on duplicate keys in&#xA;btrfs_set_item_key_safe():&#xA;  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)&#xA;  ------------[ cut here ]------------&#xA;  kernel BUG at fs/btrfs/ctree.c:2620!&#xA;  invalid opcode: 0000 [#1] PREEMPT SMP PTI&#xA;  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014&#xA;  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]&#xA;With the following stack trace:&#xA;  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)&#xA;  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)&#xA;  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)&#xA;  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)&#xA;  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)&#xA;  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)&#xA;  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)&#xA;  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)&#xA;  #8  vfs_fsync_range (fs/sync.c:188:9)&#xA;  #9  vfs_fsync (fs/sync.c:202:9)&#xA;  #10 do_fsync (fs/sync.c:212:9)&#xA;  #11 __do_sys_fdatasync (fs/sync.c:225:9)&#xA;  #12 __se_sys_fdatasync (fs/sync.c:223:1)&#xA;  #13 __x64_sys_fdatasync (fs/sync.c:223:1)&#xA;  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)&#xA;  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)&#xA;  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)&#xA;So we&#39;re logging a changed extent from fsync, which is splitting an&#xA;extent in the log tree. But this split part already exists in the tree,&#xA;triggering the BUG().&#xA;This is the state of the log tree at the time of the crash, dumped with&#xA;drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)&#xA;to get more details than btrfs_print_leaf() gives us:&#xA;  &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][&#34;eb&#34;])&#xA;  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610&#xA;  leaf 33439744 flags 0x100000000000000&#xA;  fs uuid e5bd3946-400c-4223-8923-190ef1f18677&#xA;  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da&#xA;          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160&#xA;                  generation 7 transid 9 size 8192 nbytes 8473563889606862198&#xA;                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0&#xA;                  sequence 204 flags 0x10(PREALLOC)&#xA;                  atime 1716417703.220000000 (2024-05-22 15:41:43)&#xA;                  ctime 1716417704.983333333 (2024-05-22 15:41:44)&#xA;                  mtime 1716417704.983333333 (2024-05-22 15:41:44)&#xA;                  otime 17592186044416.000000000 (559444-03-08 01:40:16)&#xA;          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13&#xA;                  index 195 namelen 3 name: 193&#xA;          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37&#xA;                  location key (0 UNKNOWN.0 0) type XATTR&#xA;                  transid 7 data_len 1 name_len 6&#xA;                  name: user.a&#xA;                  data a&#xA;          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53&#xA;                  generation 9 type 1 (regular)&#xA;                  extent data disk byte 303144960 nr 12288&#xA;                  extent data offset 0 nr 4096 ram 12288&#xA;                  extent compression 0 (none)&#xA;          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53&#xA;                  generation 9 type 2 (prealloc)&#xA;                  prealloc data disk byte 303144960 nr 12288&#xA;                  prealloc data offset 4096 nr 8192&#xA;          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53&#xA;                  generation 9 type 2 (prealloc)&#xA;                  prealloc data disk byte 303144960 nr 12288&#xA;                  prealloc data offset 8192 nr 4096&#xA;  ...&#xA;So the real problem happened earlier: notice that items 4 (4k-12k) and 5&#xA;(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and&#xA;item 5 starts at i_size.&#xA;Here is the state of &#xA;---truncated---&#xA;CVE-2024-38541:In the Linux kernel, the following vulnerability has been resolved:&#xA;of: module: add buffer overflow check in of_modalias()&#xA;In of_modalias(), if the buffer happens to be too small even for the 1st&#xA;snprintf() call, the len parameter will become negative and str parameter&#xA;(if not NULL initially) will point beyond the buffer&#39;s end. Add the buffer&#xA;overflow check after the 1st snprintf() call and fix such check after the&#xA;strlen() call (accounting for the terminating NUL char).&#xA;CVE-2024-38661:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/ap: Fix crash in AP internal function modify_bitmap()&#xA;A system crash like this&#xA;  Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403&#xA;  Fault in home space mode while using kernel ASCE.&#xA;  AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d&#xA;  Oops: 0038 ilc:3 [#1] PREEMPT SMP&#xA;  Modules linked in: mlx5_ib ...&#xA;  CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8&#xA;  Hardware name: IBM 3931 A01 704 (LPAR)&#xA;  Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)&#xA;  R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3&#xA;  Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3&#xA;  000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0&#xA;  000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff&#xA;  000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8&#xA;  Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a&#xA;  0000014b75e7b600: 18b2                lr      %r11,%r2&#xA;  #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616&#xA;  &gt;0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)&#xA;  0000014b75e7b60c: a7680001            lhi     %r6,1&#xA;  0000014b75e7b610: 187b                lr      %r7,%r11&#xA;  0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654&#xA;  0000014b75e7b616: 18e9                lr      %r14,%r9&#xA;  Call Trace:&#xA;  [&lt;0000014b75e7b606&gt;] ap_parse_bitmap_str+0x10e/0x1f8&#xA;  ([&lt;0000014b75e7b5dc&gt;] ap_parse_bitmap_str+0xe4/0x1f8)&#xA;  [&lt;0000014b75e7b758&gt;] apmask_store+0x68/0x140&#xA;  [&lt;0000014b75679196&gt;] kernfs_fop_write_iter+0x14e/0x1e8&#xA;  [&lt;0000014b75598524&gt;] vfs_write+0x1b4/0x448&#xA;  [&lt;0000014b7559894c&gt;] ksys_write+0x74/0x100&#xA;  [&lt;0000014b7618a440&gt;] __do_syscall+0x268/0x328&#xA;  [&lt;0000014b761a3558&gt;] system_call+0x70/0x98&#xA;  INFO: lockdep is turned off.&#xA;  Last Breaking-Event-Address:&#xA;  [&lt;0000014b75e7b636&gt;] ap_parse_bitmap_str+0x13e/0x1f8&#xA;  Kernel panic - not syncing: Fatal exception: panic_on_oops&#xA;occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value&#xA;(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.&#xA;The fix is simple: use unsigned long values for the internal variables. The&#xA;correct checks are already in place in the function but a simple int for&#xA;the internal variables was used with the possibility to overflow.&#xA;CVE-2024-38597:In the Linux kernel, the following vulnerability has been resolved:&#xA;eth: sungem: remove .ndo_poll_controller to avoid deadlocks&#xA;Erhard reports netpoll warnings from sungem:&#xA;  netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)&#xA;  WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c&#xA;gem_poll_controller() disables interrupts, which may sleep.&#xA;We can&#39;t sleep in netpoll, it has interrupts disabled completely.&#xA;Strangely, gem_poll_controller() doesn&#39;t even poll the completions,&#xA;and instead acts as if an interrupt has fired so it just schedules&#xA;NAPI and exits. None of this has been necessary for years, since&#xA;netpoll invokes NAPI directly.&#xA;CVE-2024-39292:In the Linux kernel, the following vulnerability has been resolved:&#xA;um: Add winch to winch_handlers before registering winch IRQ&#xA;Registering a winch IRQ is racy, an interrupt may occur before the winch is&#xA;added to the winch_handlers list.&#xA;If that happens, register_winch_irq() adds to that list a winch that is&#xA;scheduled to be (or has already been) freed, causing a panic later in&#xA;winch_cleanup().&#xA;Avoid the race by adding the winch to the winch_handlers list before&#xA;registering the IRQ, and rolling back if um_request_irq() fails.&#xA;CVE-2021-47618:In the Linux kernel, the following vulnerability has been resolved:&#xA;ARM: 9170/1: fix panic when kasan and kprobe are enabled&#xA;arm32 uses software to simulate the instruction replaced&#xA;by kprobe. some instructions may be simulated by constructing&#xA;assembly functions. therefore, before executing instruction&#xA;simulation, it is necessary to construct assembly function&#xA;execution environment in C language through binding registers.&#xA;after kasan is enabled, the register binding relationship will&#xA;be destroyed, resulting in instruction simulation errors and&#xA;causing kernel panic.&#xA;the kprobe emulate instruction function is distributed in three&#xA;files: actions-common.c actions-arm.c actions-thumb.c, so disable&#xA;KASAN when compiling these files.&#xA;for example, use kprobe insert on cap_capable+20 after kasan&#xA;enabled, the cap_capable assembly code is as follows:&#xA;&lt;cap_capable&gt;:&#xA;e92d47f0&#x9;push&#x9;{r4, r5, r6, r7, r8, r9, sl, lr}&#xA;e1a05000&#x9;mov&#x9;r5, r0&#xA;e280006c&#x9;add&#x9;r0, r0, #108    ; 0x6c&#xA;e1a04001&#x9;mov&#x9;r4, r1&#xA;e1a06002&#x9;mov&#x9;r6, r2&#xA;e59fa090&#x9;ldr&#x9;sl, [pc, #144]  ;&#xA;ebfc7bf8&#x9;bl&#x9;c03aa4b4 &lt;__asan_load4&gt;&#xA;e595706c&#x9;ldr&#x9;r7, [r5, #108]  ; 0x6c&#xA;e2859014&#x9;add&#x9;r9, r5, #20&#xA;......&#xA;The emulate_ldr assembly code after enabling kasan is as follows:&#xA;c06f1384 &lt;emulate_ldr&gt;:&#xA;e92d47f0&#x9;push&#x9;{r4, r5, r6, r7, r8, r9, sl, lr}&#xA;e282803c&#x9;add&#x9;r8, r2, #60     ; 0x3c&#xA;e1a05000&#x9;mov&#x9;r5, r0&#xA;e7e37855&#x9;ubfx&#x9;r7, r5, #16, #4&#xA;e1a00008&#x9;mov&#x9;r0, r8&#xA;e1a09001&#x9;mov&#x9;r9, r1&#xA;e1a04002&#x9;mov&#x9;r4, r2&#xA;ebf35462&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;&#xA;e357000f&#x9;cmp&#x9;r7, #15&#xA;e7e36655&#x9;ubfx&#x9;r6, r5, #12, #4&#xA;e205a00f&#x9;and&#x9;sl, r5, #15&#xA;0a000001&#x9;beq&#x9;c06f13bc &lt;emulate_ldr+0x38&gt;&#xA;e0840107&#x9;add&#x9;r0, r4, r7, lsl #2&#xA;ebf3545c&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;&#xA;e084010a&#x9;add&#x9;r0, r4, sl, lsl #2&#xA;ebf3545a&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;&#xA;e2890010&#x9;add&#x9;r0, r9, #16&#xA;ebf35458&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;&#xA;e5990010&#x9;ldr&#x9;r0, [r9, #16]&#xA;e12fff30&#x9;blx&#x9;r0&#xA;e356000f&#x9;cm&#x9;r6, #15&#xA;1a000014&#x9;bne&#x9;c06f1430 &lt;emulate_ldr+0xac&gt;&#xA;e1a06000&#x9;mov&#x9;r6, r0&#xA;e2840040&#x9;add&#x9;r0, r4, #64     ; 0x40&#xA;......&#xA;when running in emulate_ldr to simulate the ldr instruction, panic&#xA;occurred, and the log is as follows:&#xA;Unable to handle kernel NULL pointer dereference at virtual address&#xA;00000090&#xA;pgd = ecb46400&#xA;[00000090] *pgd=2e0fa003, *pmd=00000000&#xA;Internal error: Oops: 206 [#1] SMP ARM&#xA;PC is at cap_capable+0x14/0xb0&#xA;LR is at emulate_ldr+0x50/0xc0&#xA;psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c&#xA;r10: 00000000  r9 : c30897f4  r8 : ecd63cd4&#xA;r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98&#xA;r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008&#xA;Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user&#xA;Control: 32c5387d  Table: 2d546400  DAC: 55555555&#xA;Process bash (pid: 1643, stack limit = 0xecd60190)&#xA;(cap_capable) from (kprobe_handler+0x218/0x340)&#xA;(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)&#xA;(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)&#xA;(do_undefinstr) from (__und_svc_finish+0x0/0x30)&#xA;(__und_svc_finish) from (cap_capable+0x18/0xb0)&#xA;(cap_capable) from (cap_vm_enough_memory+0x38/0x48)&#xA;(cap_vm_enough_memory) from&#xA;(security_vm_enough_memory_mm+0x48/0x6c)&#xA;(security_vm_enough_memory_mm) from&#xA;(copy_process.constprop.5+0x16b4/0x25c8)&#xA;(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)&#xA;(_do_fork) from (SyS_clone+0x1c/0x24)&#xA;(SyS_clone) from (__sys_trace_return+0x0/0x10)&#xA;Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)&#xA;CVE-2024-36014:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/arm/malidp: fix a possible null pointer dereference&#xA;In malidp_mw_connector_reset, new memory is allocated with kzalloc, but&#xA;no check is performed. In order to prevent null pointer dereferencing,&#xA;ensure that mw_state is checked before calling&#xA;__drm_atomic_helper_connector_reset.&#xA;CVE-2024-38590:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/hns: Modify the print level of CQE error&#xA;Too much print may lead to a panic in kernel. Change ibdev_err() to&#xA;ibdev_err_ratelimited(), and change the printing level of cqe dump&#xA;to debug level.&#xA;CVE-2024-38620:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: HCI: Remove HCI_AMP support&#xA;Since BT_HS has been remove HCI_AMP controllers no longer has any use so&#xA;remove it along with the capability of creating AMP controllers.&#xA;Since we no longer need to differentiate between AMP and Primary&#xA;controllers, as only HCI_PRIMARY is left, this also remove&#xA;hdev-&gt;dev_type altogether.&#xA;CVE-2022-48761:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: xhci-plat: fix crash when suspend if remote wake enable&#xA;Crashed at i.mx8qm platform when suspend if enable remote wakeup&#xA;Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP&#xA;Modules linked in:&#xA;CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12&#xA;Hardware name: Freescale i.MX8QM MEK (DT)&#xA;Workqueue: events_unbound async_run_entry_fn&#xA;pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8&#xA;lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8&#xA;sp : ffff80001394bbf0&#xA;x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578&#xA;x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000&#xA;x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001&#xA;x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000&#xA;x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000&#xA;x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0&#xA;x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453&#xA;x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c&#xA;x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620&#xA;Call trace:&#xA; xhci_disable_hub_port_wake.isra.62+0x60/0xf8&#xA; xhci_suspend+0x58/0x510&#xA; xhci_plat_suspend+0x50/0x78&#xA; platform_pm_suspend+0x2c/0x78&#xA; dpm_run_callback.isra.25+0x50/0xe8&#xA; __device_suspend+0x108/0x3c0&#xA;The basic flow:&#xA;&#x9;1. run time suspend call xhci_suspend, xhci parent devices gate the clock.&#xA;        2. echo mem &gt;/sys/power/state, system _device_suspend call xhci_suspend&#xA;        3. xhci_suspend call xhci_disable_hub_port_wake, which access register,&#xA;&#x9;   but clock already gated by run time suspend.&#xA;This problem was hidden by power domain driver, which call run time resume before it.&#xA;But the below commit remove it and make this issue happen.&#xA;&#x9;commit c1df456d0f06e (&#34;PM: domains: Don&#39;t runtime resume devices at genpd_prepare()&#34;)&#xA;This patch call run time resume before suspend to make sure clock is on&#xA;before access register.&#xA;Testeb-by: Abel Vesa &lt;abel.vesa@nxp.com&gt;&#xA;CVE-2024-39461:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: bcm: rpi: Assign -&gt;num before accessing -&gt;hws&#xA;Commit f316cdff8d67 (&#34;clk: Annotate struct clk_hw_onecell_data with&#xA;__counted_by&#34;) annotated the hws member of &#39;struct clk_hw_onecell_data&#39;&#xA;with __counted_by, which informs the bounds sanitizer about the number&#xA;of elements in hws, so that it can warn when hws is accessed out of&#xA;bounds. As noted in that change, the __counted_by member must be&#xA;initialized with the number of elements before the first array access&#xA;happens, otherwise there will be a warning from each access prior to the&#xA;initialization because the number of elements is zero. This occurs in&#xA;raspberrypi_discover_clocks() due to -&gt;num being assigned after -&gt;hws&#xA;has been accessed:&#xA;  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4&#xA;  index 3 is out of range for type &#39;struct clk_hw *[] __counted_by(num)&#39; (aka &#39;struct clk_hw *[]&#39;)&#xA;Move the -&gt;num initialization to before the first access of -&gt;hws, which&#xA;clears up the warning.&#xA;CVE-2021-47441:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: thermal: Fix out-of-bounds memory accesses&#xA;Currently, mlxsw allows cooling states to be set above the maximum&#xA;cooling state supported by the driver:&#xA; # cat /sys/class/thermal/thermal_zone2/cdev0/type&#xA; mlxsw_fan&#xA; # cat /sys/class/thermal/thermal_zone2/cdev0/max_state&#xA; 10&#xA; # echo 18 &gt; /sys/class/thermal/thermal_zone2/cdev0/cur_state&#xA; # echo $?&#xA; 0&#xA;This results in out-of-bounds memory accesses when thermal state&#xA;transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the&#xA;transition table is accessed with a too large index (state) [1].&#xA;According to the thermal maintainer, it is the responsibility of the&#xA;driver to reject such operations [2].&#xA;Therefore, return an error when the state to be set exceeds the maximum&#xA;cooling state supported by the driver.&#xA;To avoid dead code, as suggested by the thermal maintainer [3],&#xA;partially revert commit a421ce088ac8 (&#34;mlxsw: core: Extend cooling&#xA;device with cooling levels&#34;) that tried to interpret these invalid&#xA;cooling states (above the maximum) in a special way. The cooling levels&#xA;array is not removed in order to prevent the fans going below 20% PWM,&#xA;which would cause them to get stuck at 0% PWM.&#xA;[1]&#xA;BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290&#xA;Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5&#xA;CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122&#xA;Hardware name: Mellanox Technologies Ltd. &#34;MSN2410-CB2FO&#34;/&#34;SA000874&#34;, BIOS 4.6.5 03/08/2016&#xA;Workqueue: events_freezable_power_ thermal_zone_device_check&#xA;Call Trace:&#xA; dump_stack_lvl+0x8b/0xb3&#xA; print_address_description.constprop.0+0x1f/0x140&#xA; kasan_report.cold+0x7f/0x11b&#xA; thermal_cooling_device_stats_update+0x271/0x290&#xA; __thermal_cdev_update+0x15e/0x4e0&#xA; thermal_cdev_update+0x9f/0xe0&#xA; step_wise_throttle+0x770/0xee0&#xA; thermal_zone_device_update+0x3f6/0xdf0&#xA; process_one_work+0xa42/0x1770&#xA; worker_thread+0x62f/0x13e0&#xA; kthread+0x3ee/0x4e0&#xA; ret_from_fork+0x1f/0x30&#xA;Allocated by task 1:&#xA; kasan_save_stack+0x1b/0x40&#xA; __kasan_kmalloc+0x7c/0x90&#xA; thermal_cooling_device_setup_sysfs+0x153/0x2c0&#xA; __thermal_cooling_device_register.part.0+0x25b/0x9c0&#xA; thermal_cooling_device_register+0xb3/0x100&#xA; mlxsw_thermal_init+0x5c5/0x7e0&#xA; __mlxsw_core_bus_device_register+0xcb3/0x19c0&#xA; mlxsw_core_bus_device_register+0x56/0xb0&#xA; mlxsw_pci_probe+0x54f/0x710&#xA; local_pci_probe+0xc6/0x170&#xA; pci_device_probe+0x2b2/0x4d0&#xA; really_probe+0x293/0xd10&#xA; __driver_probe_device+0x2af/0x440&#xA; driver_probe_device+0x51/0x1e0&#xA; __driver_attach+0x21b/0x530&#xA; bus_for_each_dev+0x14c/0x1d0&#xA; bus_add_driver+0x3ac/0x650&#xA; driver_register+0x241/0x3d0&#xA; mlxsw_sp_module_init+0xa2/0x174&#xA; do_one_initcall+0xee/0x5f0&#xA; kernel_init_freeable+0x45a/0x4de&#xA; kernel_init+0x1f/0x210&#xA; ret_from_fork+0x1f/0x30&#xA;The buggy address belongs to the object at ffff8881052f7800&#xA; which belongs to the cache kmalloc-1k of size 1024&#xA;The buggy address is located 1016 bytes inside of&#xA; 1024-byte region [ffff8881052f7800, ffff8881052f7c00)&#xA;The buggy address belongs to the page:&#xA;page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0&#xA;head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0&#xA;flags: 0x200000000010200(slab|head|node=0|zone=2)&#xA;raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0&#xA;raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;Memory state around the buggy address:&#xA; ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc&#xA; ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;&gt;ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;                                                                ^&#xA; ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA; ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-&#xA;---truncated---&#xA;CVE-2024-39462:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: bcm: dvp: Assign -&gt;num before accessing -&gt;hws&#xA;Commit f316cdff8d67 (&#34;clk: Annotate struct clk_hw_onecell_data with&#xA;__counted_by&#34;) annotated the hws member of &#39;struct clk_hw_onecell_data&#39;&#xA;with __counted_by, which informs the bounds sanitizer about the number&#xA;of elements in hws, so that it can warn when hws is accessed out of&#xA;bounds. As noted in that change, the __counted_by member must be&#xA;initialized with the number of elements before the first array access&#xA;happens, otherwise there will be a warning from each access prior to the&#xA;initialization because the number of elements is zero. This occurs in&#xA;clk_dvp_probe() due to -&gt;num being assigned after -&gt;hws has been&#xA;accessed:&#xA;  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2&#xA;  index 0 is out of range for type &#39;struct clk_hw *[] __counted_by(num)&#39; (aka &#39;struct clk_hw *[]&#39;)&#xA;Move the -&gt;num initialization to before the first access of -&gt;hws, which&#xA;clears up the warning.&#xA;CVE-2022-48720:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: macsec: Fix offload support for NETDEV_UNREGISTER event&#xA;Current macsec netdev notify handler handles NETDEV_UNREGISTER event by&#xA;releasing relevant SW resources only, this causes resources leak in case&#xA;of macsec HW offload, as the underlay driver was not notified to clean&#xA;it&#39;s macsec offload resources.&#xA;Fix by calling the underlay driver to clean it&#39;s relevant resources&#xA;by moving offload handling from macsec_dellink() to macsec_common_dellink()&#xA;when handling NETDEV_UNREGISTER event.&#xA;CVE-2023-52884:In the Linux kernel, the following vulnerability has been resolved:&#xA;Input: cyapa - add missing input core locking to suspend/resume functions&#xA;Grab input-&gt;mutex during suspend/resume functions like it is done in&#xA;other input drivers. This fixes the following warning during system&#xA;suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c&#xA;Modules linked in: ...&#xA;CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G        W          6.6.0-rc5-next-20231009 #14109&#xA;Hardware name: Samsung Exynos (Flattened Device Tree)&#xA;Workqueue: events_unbound async_run_entry_fn&#xA; unwind_backtrace from show_stack+0x10/0x14&#xA; show_stack from dump_stack_lvl+0x58/0x70&#xA; dump_stack_lvl from __warn+0x1a8/0x1cc&#xA; __warn from warn_slowpath_fmt+0x18c/0x1b4&#xA; warn_slowpath_fmt from input_device_enabled+0x68/0x6c&#xA; input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc&#xA; cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c&#xA; cyapa_reinitialize from cyapa_resume+0x48/0x98&#xA; cyapa_resume from dpm_run_callback+0x90/0x298&#xA; dpm_run_callback from device_resume+0xb4/0x258&#xA; device_resume from async_resume+0x20/0x64&#xA; async_resume from async_run_entry_fn+0x40/0x15c&#xA; async_run_entry_fn from process_scheduled_works+0xbc/0x6a8&#xA; process_scheduled_works from worker_thread+0x188/0x454&#xA; worker_thread from kthread+0x108/0x140&#xA; kthread from ret_from_fork+0x14/0x28&#xA;Exception stack(0xf1625fb0 to 0xf1625ff8)&#xA;...&#xA;---[ end trace 0000000000000000 ]---&#xA;...&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c&#xA;Modules linked in: ...&#xA;CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G        W          6.6.0-rc5-next-20231009 #14109&#xA;Hardware name: Samsung Exynos (Flattened Device Tree)&#xA;Workqueue: events_unbound async_run_entry_fn&#xA; unwind_backtrace from show_stack+0x10/0x14&#xA; show_stack from dump_stack_lvl+0x58/0x70&#xA; dump_stack_lvl from __warn+0x1a8/0x1cc&#xA; __warn from warn_slowpath_fmt+0x18c/0x1b4&#xA; warn_slowpath_fmt from input_device_enabled+0x68/0x6c&#xA; input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc&#xA; cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c&#xA; cyapa_reinitialize from cyapa_resume+0x48/0x98&#xA; cyapa_resume from dpm_run_callback+0x90/0x298&#xA; dpm_run_callback from device_resume+0xb4/0x258&#xA; device_resume from async_resume+0x20/0x64&#xA; async_resume from async_run_entry_fn+0x40/0x15c&#xA; async_run_entry_fn from process_scheduled_works+0xbc/0x6a8&#xA; process_scheduled_works from worker_thread+0x188/0x454&#xA; worker_thread from kthread+0x108/0x140&#xA; kthread from ret_from_fork+0x14/0x28&#xA;Exception stack(0xf1625fb0 to 0xf1625ff8)&#xA;...&#xA;---[ end trace 0000000000000000 ]---&#xA;CVE-2022-48748:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: bridge: vlan: fix memory leak in __allowed_ingress&#xA;When using per-vlan state, if vlan snooping and stats are disabled,&#xA;untagged or priority-tagged ingress frame will go to check pvid state.&#xA;If the port state is forwarding and the pvid state is not&#xA;learning/forwarding, untagged or priority-tagged frame will be dropped&#xA;but skb memory is not freed.&#xA;Should free skb when __allowed_ingress returns false.&#xA;CVE-2024-36481:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing/probes: fix error check in parse_btf_field()&#xA;btf_find_struct_member() might return NULL or an error via the&#xA;ERR_PTR() macro. However, its caller in parse_btf_field() only checks&#xA;for the NULL condition. Fix this by using IS_ERR() and returning the&#xA;error up the stack.&#xA;CVE-2024-38384:In the Linux kernel, the following vulnerability has been resolved:&#xA;blk-cgroup: fix list corruption from reorder of WRITE -&gt;lqueued&#xA;__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start&#xA;is being executed.&#xA;If WRITE of `-&gt;lqueued` is re-ordered with READ of &#39;bisc-&gt;lnode.next&#39; in&#xA;the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one&#xA;stat instance being added in blk_cgroup_bio_start(), then the local&#xA;list in __blkcg_rstat_flush() could be corrupted.&#xA;Fix the issue by adding one barrier.&#xA;CVE-2024-39470:In the Linux kernel, the following vulnerability has been resolved:&#xA;eventfs: Fix a possible null pointer dereference in eventfs_find_events()&#xA;In function eventfs_find_events,there is a potential null pointer&#xA;that may be caused by calling update_events_attr which will perform&#xA;some operations on the members of the ei struct when ei is NULL.&#xA;Hence,When ei-&gt;is_freed is set,return NULL directly.&#xA;CVE-2024-39465:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: mgb4: Fix double debugfs remove&#xA;Fixes an error where debugfs_remove_recursive() is called first on a parent&#xA;directory and then again on a child which causes a kernel panic.&#xA;[hverkuil: added Fixes/Cc tags]&#xA;CVE-2024-39466:In the Linux kernel, the following vulnerability has been resolved:&#xA;thermal/drivers/qcom/lmh: Check for SCM availability at probe&#xA;Up until now, the necessary scm availability check has not been&#xA;performed, leading to possible null pointer dereferences (which did&#xA;happen for me on RB1).&#xA;Fix that.&#xA;CVE-2024-35785:In the Linux kernel, the following vulnerability has been resolved:&#xA;tee: optee: Fix kernel panic caused by incorrect error handling&#xA;The error path while failing to register devices on the TEE bus has a&#xA;bug leading to kernel panic as follows:&#xA;[   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c&#xA;[   15.406913] Mem abort info:&#xA;[   15.409722]   ESR = 0x0000000096000005&#xA;[   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[   15.418814]   SET = 0, FnV = 0&#xA;[   15.421878]   EA = 0, S1PTW = 0&#xA;[   15.425031]   FSC = 0x05: level 1 translation fault&#xA;[   15.429922] Data abort info:&#xA;[   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000&#xA;[   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;[   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;[   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000&#xA;[   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000&#xA;[   15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP&#xA;Commit 7269cba53d90 (&#34;tee: optee: Fix supplicant based device enumeration&#34;)&#xA;lead to the introduction of this bug. So fix it appropriately.&#xA;CVE-2024-35949:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: make sure that WRITTEN is set on all metadata blocks&#xA;We previously would call btrfs_check_leaf() if we had the check&#xA;integrity code enabled, which meant that we could only run the extended&#xA;leaf checks if we had WRITTEN set on the header flags.&#xA;This leaves a gap in our checking, because we could end up with&#xA;corruption on disk where WRITTEN isn&#39;t set on the leaf, and then the&#xA;extended leaf checks don&#39;t get run which we rely on to validate all of&#xA;the item pointers to make sure we don&#39;t access memory outside of the&#xA;extent buffer.&#xA;However, since 732fab95abe2 (&#34;btrfs: check-integrity: remove&#xA;CONFIG_BTRFS_FS_CHECK_INTEGRITY option&#34;) we no longer call&#xA;btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only&#xA;ever call it on blocks that are being written out, and thus have WRITTEN&#xA;set, or that are being read in, which should have WRITTEN set.&#xA;Add checks to make sure we have WRITTEN set appropriately, and then make&#xA;sure __btrfs_check_leaf() always does the item checking.  This will&#xA;protect us from file systems that have been corrupted and no longer have&#xA;WRITTEN set on some of the blocks.&#xA;This was hit on a crafted image tweaking the WRITTEN bit and reported by&#xA;KASAN as out-of-bound access in the eb accessors. The example is a dir&#xA;item at the end of an eb.&#xA;  [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2&#xA;  [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;  [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]&#xA;  [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1&#xA;  [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;  [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0&#xA;  [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206&#xA;  [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0&#xA;  [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748&#xA;  [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9&#xA;  [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a&#xA;  [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8&#xA;  [2.621] FS:  00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000&#xA;  [2.621] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0&#xA;  [2.621] Call Trace:&#xA;  [2.621]  &lt;TASK&gt;&#xA;  [2.621]  ? show_regs+0x74/0x80&#xA;  [2.621]  ? die_addr+0x46/0xc0&#xA;  [2.621]  ? exc_general_protection+0x161/0x2a0&#xA;  [2.621]  ? asm_exc_general_protection+0x26/0x30&#xA;  [2.621]  ? btrfs_get_16+0x33a/0x6d0&#xA;  [2.621]  ? btrfs_get_16+0x34b/0x6d0&#xA;  [2.621]  ? btrfs_get_16+0x33a/0x6d0&#xA;  [2.621]  ? __pfx_btrfs_get_16+0x10/0x10&#xA;  [2.621]  ? __pfx_mutex_unlock+0x10/0x10&#xA;  [2.621]  btrfs_match_dir_item_name+0x101/0x1a0&#xA;  [2.621]  btrfs_lookup_dir_item+0x1f3/0x280&#xA;  [2.621]  ? __pfx_btrfs_lookup_dir_item+0x10/0x10&#xA;  [2.621]  btrfs_get_tree+0xd25/0x1910&#xA;[ copy more details from report ]&#xA;CVE-2024-36931:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/cio: Ensure the copied buf is NUL terminated&#xA;Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from&#xA;userspace to that buffer. Later, we use scanf on this buffer but we don&#39;t&#xA;ensure that the string is terminated inside the buffer, this can lead to&#xA;OOB read when using scanf. Fix this issue by using memdup_user_nul instead.&#xA;CVE-2024-36937:In the Linux kernel, the following vulnerability has been resolved:&#xA;xdp: use flags field to disambiguate broadcast redirect&#xA;When redirecting a packet using XDP, the bpf_redirect_map() helper will set&#xA;up the redirect destination information in struct bpf_redirect_info (using&#xA;the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect()&#xA;function will read this information after the XDP program returns and pass&#xA;the frame on to the right redirect destination.&#xA;When using the BPF_F_BROADCAST flag to do multicast redirect to a whole&#xA;map, __bpf_xdp_redirect_map() sets the &#39;map&#39; pointer in struct&#xA;bpf_redirect_info to point to the destination map to be broadcast. And&#xA;xdp_do_redirect() reacts to the value of this map pointer to decide whether&#xA;it&#39;s dealing with a broadcast or a single-value redirect. However, if the&#xA;destination map is being destroyed before xdp_do_redirect() is called, the&#xA;map pointer will be cleared out (by bpf_clear_redirect_map()) without&#xA;waiting for any XDP programs to stop running. This causes xdp_do_redirect()&#xA;to think that the redirect was to a single target, but the target pointer&#xA;is also NULL (since broadcast redirects don&#39;t have a single target), so&#xA;this causes a crash when a NULL pointer is passed to dev_map_enqueue().&#xA;To fix this, change xdp_do_redirect() to react directly to the presence of&#xA;the BPF_F_BROADCAST flag in the &#39;flags&#39; value in struct bpf_redirect_info&#xA;to disambiguate between a single-target and a broadcast redirect. And only&#xA;read the &#39;map&#39; pointer if the broadcast flag is set, aborting if that has&#xA;been cleared out in the meantime. This prevents the crash, while keeping&#xA;the atomic (cmpxchg-based) clearing of the map pointer itself, and without&#xA;adding any more checks in the non-broadcast fast path.&#xA;CVE-2024-36028:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()&#xA;When I did memory failure tests recently, below warning occurs:&#xA;DEBUG_LOCKS_WARN_ON(1)&#xA;WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0&#xA;Modules linked in: mce_inject hwpoison_inject&#xA;CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:__lock_acquire+0xccb/0x1ca0&#xA;RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082&#xA;RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8&#xA;RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0&#xA;RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb&#xA;R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10&#xA;R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004&#xA;FS:  00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; lock_acquire+0xbe/0x2d0&#xA; _raw_spin_lock_irqsave+0x3a/0x60&#xA; hugepage_subpool_put_pages.part.0+0xe/0xc0&#xA; free_huge_folio+0x253/0x3f0&#xA; dissolve_free_huge_page+0x147/0x210&#xA; __page_handle_poison+0x9/0x70&#xA; memory_failure+0x4e6/0x8c0&#xA; hard_offline_page_store+0x55/0xa0&#xA; kernfs_fop_write_iter+0x12c/0x1d0&#xA; vfs_write+0x380/0x540&#xA; ksys_write+0x64/0xe0&#xA; do_syscall_64+0xbc/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7ff9f3114887&#xA;RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887&#xA;RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001&#xA;RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c&#xA;R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00&#xA; &lt;/TASK&gt;&#xA;Kernel panic - not syncing: kernel: panic_on_warn set ...&#xA;CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; panic+0x326/0x350&#xA; check_panic_on_warn+0x4f/0x50&#xA; __warn+0x98/0x190&#xA; report_bug+0x18e/0x1a0&#xA; handle_bug+0x3d/0x70&#xA; exc_invalid_op+0x18/0x70&#xA; asm_exc_invalid_op+0x1a/0x20&#xA;RIP: 0010:__lock_acquire+0xccb/0x1ca0&#xA;RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082&#xA;RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8&#xA;RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0&#xA;RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb&#xA;R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10&#xA;R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004&#xA; lock_acquire+0xbe/0x2d0&#xA; _raw_spin_lock_irqsave+0x3a/0x60&#xA; hugepage_subpool_put_pages.part.0+0xe/0xc0&#xA; free_huge_folio+0x253/0x3f0&#xA; dissolve_free_huge_page+0x147/0x210&#xA; __page_handle_poison+0x9/0x70&#xA; memory_failure+0x4e6/0x8c0&#xA; hard_offline_page_store+0x55/0xa0&#xA; kernfs_fop_write_iter+0x12c/0x1d0&#xA; vfs_write+0x380/0x540&#xA; ksys_write+0x64/0xe0&#xA; do_syscall_64+0xbc/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7ff9f3114887&#xA;RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887&#xA;RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001&#xA;RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c&#xA;R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00&#xA; &lt;/TASK&gt;&#xA;After git bisecting and digging into the code, I believe the root cause is&#xA;that _deferred_list field of folio is unioned with _hugetlb_subpool field.&#xA;In __update_and_free_hugetlb_folio(), folio-&gt;_deferred_&#xA;---truncated---&#xA;CVE-2024-27405:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs&#xA;It is observed sometimes when tethering is used over NCM with Windows 11&#xA;as host, at some instances, the gadget_giveback has one byte appended at&#xA;the end of a proper NTB. When the NTB is parsed, unwrap call looks for&#xA;any leftover bytes in SKB provided by u_ether and if there are any pending&#xA;bytes, it treats them as a separate NTB and parses it. But in case the&#xA;second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that&#xA;were parsed properly in the first NTB and saved in rx_list are dropped.&#xA;Adding a few custom traces showed the following:&#xA;[002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:&#xA;req 000000003868811a length 1025/16384 zsI ==&gt; 0&#xA;[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025&#xA;[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342&#xA;[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67&#xA;[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400&#xA;[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10&#xA;[002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames&#xA;In this case, the giveback is of 1025 bytes and block length is 1024.&#xA;The rest 1 byte (which is 0x00) won&#39;t be parsed resulting in drop of&#xA;all datagrams in rx_list.&#xA;Same is case with packets of size 2048:&#xA;[002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:&#xA;req 0000000011dfd96e length 2049/16384 zsI ==&gt; 0&#xA;[002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342&#xA;[002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800&#xA;Lecroy shows one byte coming in extra confirming that the byte is coming&#xA;in from PC:&#xA; Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590)&#xA; - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)&#xA; --- Packet 4063861&#xA;       Data(1024 bytes)&#xA;       Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)&#xA; --- Packet 4063863&#xA;       Data(1 byte)&#xA;       Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)&#xA;According to Windows driver, no ZLP is needed if wBlockLength is non-zero,&#xA;because the non-zero wBlockLength has already told the function side the&#xA;size of transfer to be expected. However, there are in-market NCM devices&#xA;that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.&#xA;To deal with such devices, it pads an extra 0 at end so the transfer is no&#xA;longer multiple of wMaxPacketSize.&#xA;CVE-2021-47568:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: fix memleak in get_file_stream_info()&#xA;Fix memleak in get_file_stream_info()&#xA;CVE-2024-39492:In the Linux kernel, the following vulnerability has been resolved:&#xA;mailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdown&#xA;The return value of pm_runtime_get_sync() in cmdq_mbox_shutdown()&#xA;will return 1 when pm runtime state is active, and we don&#39;t want to&#xA;get the warning message in this case.&#xA;So we change the return value &lt; 0 for WARN_ON().&#xA;CVE-2021-47598:In the Linux kernel, the following vulnerability has been resolved:&#xA;sch_cake: do not call cake_destroy() from cake_init()&#xA;qdiscs are not supposed to call their own destroy() method&#xA;from init(), because core stack already does that.&#xA;syzbot was able to trigger use after free:&#xA;DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)&#xA;WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]&#xA;WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740&#xA;Modules linked in:&#xA;CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]&#xA;RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740&#xA;Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff &lt;0f&gt; 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8&#xA;RSP: 0018:ffffc9000627f290 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000&#xA;RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44&#xA;RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000&#xA;R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000&#xA;FS:  0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810&#xA; tcf_block_put_ext net/sched/cls_api.c:1381 [inline]&#xA; tcf_block_put_ext net/sched/cls_api.c:1376 [inline]&#xA; tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394&#xA; cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695&#xA; qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293&#xA; tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660&#xA; rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571&#xA; netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]&#xA; netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345&#xA; netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921&#xA; sock_sendmsg_nosec net/socket.c:704 [inline]&#xA; sock_sendmsg+0xcf/0x120 net/socket.c:724&#xA; ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409&#xA; ___sys_sendmsg+0xf3/0x170 net/socket.c:2463&#xA; __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;RIP: 0033:0x7f1bb06badb9&#xA;Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.&#xA;RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9&#xA;RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003&#xA;RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003&#xA;R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688&#xA;R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2&#xA; &lt;/TASK&gt;&#xA;CVE-2024-36965:In the Linux kernel, the following vulnerability has been resolved:&#xA;remoteproc: mediatek: Make sure IPI buffer fits in L2TCM&#xA;The IPI buffer location is read from the firmware that we load to the&#xA;System Companion Processor, and it&#39;s not granted that both the SRAM&#xA;(L2TCM) size that is defined in the devicetree node is large enough&#xA;for that, and while this is especially true for multi-core SCP, it&#39;s&#xA;still useful to check on single-core variants as well.&#xA;Failing to perform this check may make this driver perform R/W&#xA;operations out of the L2TCM boundary, resulting (at best) in a&#xA;kernel panic.&#xA;To fix that, check that the IPI buffer fits, otherwise return a&#xA;failure and refuse to boot the relevant SCP core (or the SCP at&#xA;all, if this is single core).&#xA;CVE-2021-47187:In the Linux kernel, the following vulnerability has been resolved:&#xA;arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency&#xA;The entry/exit latency and minimum residency in state for the idle&#xA;states of MSM8998 were ..bad: first of all, for all of them the&#xA;timings were written for CPU sleep but the min-residency-us param&#xA;was miscalculated (supposedly, while porting this from downstream);&#xA;Then, the power collapse states are setting PC on both the CPU&#xA;cluster *and* the L2 cache, which have different timings: in the&#xA;specific case of L2 the times are higher so these ones should be&#xA;taken into account instead of the CPU ones.&#xA;This parameter misconfiguration was not giving particular issues&#xA;because on MSM8998 there was no CPU scaling at all, so cluster/L2&#xA;power collapse was rarely (if ever) hit.&#xA;When CPU scaling is enabled, though, the wrong timings will produce&#xA;SoC unstability shown to the user as random, apparently error-less,&#xA;sudden reboots and/or lockups.&#xA;This set of parameters are stabilizing the SoC when CPU scaling is&#xA;ON and when power collapse is frequently hit.&#xA;CVE-2023-52657:In the Linux kernel, the following vulnerability has been resolved:&#xA;Revert &#34;drm/amd/pm: resolve reboot exception for si oland&#34;&#xA;This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86.&#xA;This causes hangs on SI when DC is enabled and errors on driver&#xA;reboot and power off cycles.&#xA;CVE-2024-35786:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf&#xA;If VM_BIND is enabled on the client the legacy submission ioctl can&#39;t be&#xA;used, however if a client tries to do so regardless it will return an&#xA;error. In this case the clients mutex remained unlocked leading to a&#xA;deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.&#xA;CVE-2024-27432:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ethernet: mtk_eth_soc: fix PPE hanging issue&#xA;A patch to resolve an issue was found in MediaTek&#39;s GPL-licensed SDK:&#xA;In the mtk_ppe_stop() function, the PPE scan mode is not disabled before&#xA;disabling the PPE. This can potentially lead to a hang during the process&#xA;of disabling the PPE.&#xA;Without this patch, the PPE may experience a hang during the reboot test.&#xA;CVE-2023-52684:In the Linux kernel, the following vulnerability has been resolved:&#xA;firmware: qcom: qseecom: fix memory leaks in error paths&#xA;Fix instances of returning error codes directly instead of jumping to&#xA;the relevant labels where memory allocated for the SCM calls would be&#xA;freed.&#xA;CVE-2024-35850:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: qca: fix NULL-deref on non-serdev setup&#xA;Qualcomm ROME controllers can be registered from the Bluetooth line&#xA;discipline and in this case the HCI UART serdev pointer is NULL.&#xA;Add the missing sanity check to prevent a NULL-pointer dereference when&#xA;setup() is called for a non-serdev controller.&#xA;CVE-2023-52689:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: scarlett2: Add missing mutex lock around get meter levels&#xA;As scarlett2_meter_ctl_get() uses meter_level_map[], the data_mutex&#xA;should be locked while accessing it.&#xA;CVE-2023-52673:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix a debugfs null pointer error&#xA;[WHY &amp; HOW]&#xA;Check whether get_subvp_en() callback exists before calling it.&#xA;CVE-2023-52692:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()&#xA;scarlett2_usb_set_config() calls scarlett2_usb_get() but was not&#xA;checking the result. Return the error if it fails rather than&#xA;continuing with an invalid value.&#xA;CVE-2021-47349:In the Linux kernel, the following vulnerability has been resolved:&#xA;mwifiex: bring down link before deleting interface&#xA;We can deadlock when rmmod&#39;ing the driver or going through firmware&#xA;reset, because the cfg80211_unregister_wdev() has to bring down the link&#xA;for us, ... which then grab the same wiphy lock.&#xA;nl80211_del_interface() already handles a very similar case, with a nice&#xA;description:&#xA;        /*&#xA;         * We hold RTNL, so this is safe, without RTNL opencount cannot&#xA;         * reach 0, and thus the rdev cannot be deleted.&#xA;         *&#xA;         * We need to do it for the dev_close(), since that will call&#xA;         * the netdev notifiers, and we need to acquire the mutex there&#xA;         * but don&#39;t know if we get there from here or from some other&#xA;         * place (e.g. &#34;ip link set ... down&#34;).&#xA;         */&#xA;        mutex_unlock(&amp;rdev-&gt;wiphy.mtx);&#xA;...&#xA;Do similarly for mwifiex teardown, by ensuring we bring the link down&#xA;first.&#xA;Sample deadlock trace:&#xA;[  247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds.&#xA;[  247.110630]       Not tainted 5.12.4 #5&#xA;[  247.115796] &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA;[  247.124557] task:rmmod           state:D stack:    0 pid: 2119 ppid:  2114 flags:0x00400208&#xA;[  247.133905] Call trace:&#xA;[  247.136644]  __switch_to+0x130/0x170&#xA;[  247.140643]  __schedule+0x714/0xa0c&#xA;[  247.144548]  schedule_preempt_disabled+0x88/0xf4&#xA;[  247.149714]  __mutex_lock_common+0x43c/0x750&#xA;[  247.154496]  mutex_lock_nested+0x5c/0x68&#xA;[  247.158884]  cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211]&#xA;[  247.165769]  raw_notifier_call_chain+0x4c/0x78&#xA;[  247.170742]  call_netdevice_notifiers_info+0x68/0xa4&#xA;[  247.176305]  __dev_close_many+0x7c/0x138&#xA;[  247.180693]  dev_close_many+0x7c/0x10c&#xA;[  247.184893]  unregister_netdevice_many+0xfc/0x654&#xA;[  247.190158]  unregister_netdevice_queue+0xb4/0xe0&#xA;[  247.195424]  _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211]&#xA;[  247.201816]  cfg80211_unregister_wdev+0x20/0x2c [cfg80211]&#xA;[  247.208016]  mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex]&#xA;[  247.214174]  mwifiex_uninit_sw+0x158/0x1b0 [mwifiex]&#xA;[  247.219747]  mwifiex_remove_card+0x38/0xa0 [mwifiex]&#xA;[  247.225316]  mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie]&#xA;[  247.231451]  pci_device_remove+0x50/0xe0&#xA;[  247.235849]  device_release_driver_internal+0x110/0x1b0&#xA;[  247.241701]  driver_detach+0x5c/0x9c&#xA;[  247.245704]  bus_remove_driver+0x84/0xb8&#xA;[  247.250095]  driver_unregister+0x3c/0x60&#xA;[  247.254486]  pci_unregister_driver+0x2c/0x90&#xA;[  247.259267]  cleanup_module+0x18/0xcdc [mwifiex_pcie]&#xA;CVE-2021-47230:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: x86: Immediately reset the MMU context when the SMM flag is cleared&#xA;Immediately reset the MMU context when the vCPU&#39;s SMM flag is cleared so&#xA;that the SMM flag in the MMU role is always synchronized with the vCPU&#39;s&#xA;flag.  If RSM fails (which isn&#39;t correctly emulated), KVM will bail&#xA;without calling post_leave_smm() and leave the MMU in a bad state.&#xA;The bad MMU role can lead to a NULL pointer dereference when grabbing a&#xA;shadow page&#39;s rmap for a page fault as the initial lookups for the gfn&#xA;will happen with the vCPU&#39;s SMM flag (=0), whereas the rmap lookup will&#xA;use the shadow page&#39;s SMM flag, which comes from the MMU (=1).  SMM has&#xA;an entirely different set of memslots, and so the initial lookup can find&#xA;a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).&#xA;  general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN&#xA;  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0&#xA;  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]&#xA;  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947&#xA;  Code: &lt;42&gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44&#xA;  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246&#xA;  RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40&#xA;  RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001&#xA;  RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002&#xA;  R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000&#xA;  R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000&#xA;  FS:  000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0&#xA;  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;  Call Trace:&#xA;   rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline]&#xA;   mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604&#xA;   __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline]&#xA;   direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769&#xA;   kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline]&#xA;   kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065&#xA;   vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122&#xA;   vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428&#xA;   vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494&#xA;   kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722&#xA;   kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460&#xA;   vfs_ioctl fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl fs/ioctl.c:1069 [inline]&#xA;   __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055&#xA;   do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47&#xA;   entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;  RIP: 0033:0x440ce9&#xA;CVE-2024-35857:In the Linux kernel, the following vulnerability has been resolved:&#xA;icmp: prevent possible NULL dereferences from icmp_build_probe()&#xA;First problem is a double call to __in_dev_get_rcu(), because&#xA;the second one could return NULL.&#xA;if (__in_dev_get_rcu(dev) &amp;&amp; __in_dev_get_rcu(dev)-&gt;ifa_list)&#xA;Second problem is a read from dev-&gt;ip6_ptr with no NULL check:&#xA;if (!list_empty(&amp;rcu_dereference(dev-&gt;ip6_ptr)-&gt;addr_list))&#xA;Use the correct RCU API to fix these.&#xA;v2: add missing include &lt;net/addrconf.h&gt;&#xA;CVE-2021-47311:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: qcom/emac: fix UAF in emac_remove&#xA;adpt is netdev private data and it cannot be&#xA;used after free_netdev() call. Using adpt after free_netdev()&#xA;can cause UAF bug. Fix it by moving free_netdev() at the end of the&#xA;function.&#xA;CVE-2021-47611:In the Linux kernel, the following vulnerability has been resolved:&#xA;mac80211: validate extended element ID is present&#xA;Before attempting to parse an extended element, verify that&#xA;the extended element ID is present.&#xA;CVE-2021-47596:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg&#xA;Currently, the hns3_remove function firstly uninstall client instance,&#xA;and then uninstall acceletion engine device. The netdevice is freed in&#xA;client instance uninstall process, but acceletion engine device uninstall&#xA;process still use it to trace runtime information. This causes a use after&#xA;free problem.&#xA;So fixes it by check the instance register state to avoid use after free.&#xA;CVE-2021-47605:In the Linux kernel, the following vulnerability has been resolved:&#xA;vduse: fix memory corruption in vduse_dev_ioctl()&#xA;The &#34;config.offset&#34; comes from the user.  There needs to a check to&#xA;prevent it being out of bounds.  The &#34;config.offset&#34; and&#xA;&#34;dev-&gt;config_size&#34; variables are both type u32.  So if the offset if&#xA;out of bounds then the &#34;dev-&gt;config_size - config.offset&#34; subtraction&#xA;results in a very high u32 value.  The out of bounds offset can result&#xA;in memory corruption.&#xA;CVE-2022-48712:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix error handling in ext4_fc_record_modified_inode()&#xA;Current code does not fully takes care of krealloc() error case, which&#xA;could lead to silent memory corruption or a kernel bug.  This patch&#xA;fixes that.&#xA;Also it cleans up some duplicated error handling logic from various&#xA;functions in fast_commit.c file.&#xA;CVE-2022-48724:In the Linux kernel, the following vulnerability has been resolved:&#xA;iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()&#xA;After commit e3beca48a45b (&#34;irqdomain/treewide: Keep firmware node&#xA;unconditionally allocated&#34;). For tear down scenario, fn is only freed&#xA;after fail to allocate ir_domain, though it also should be freed in case&#xA;dmar_enable_qi returns error.&#xA;Besides free fn, irq_domain and ir_msi_domain need to be removed as well&#xA;if intel_setup_irq_remapping fails to enable queued invalidation.&#xA;Improve the rewinding path by add out_free_ir_domain and out_free_fwnode&#xA;lables per Baolu&#39;s suggestion.&#xA;CVE-2022-48771:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vmwgfx: Fix stale file descriptors on failed usercopy&#xA;A failing usercopy of the fence_rep object will lead to a stale entry in&#xA;the file descriptor table as put_unused_fd() won&#39;t release it. This&#xA;enables userland to refer to a dangling &#39;file&#39; object through that still&#xA;valid file descriptor, leading to all kinds of use-after-free&#xA;exploitation scenarios.&#xA;Fix this by deferring the call to fd_install() until after the usercopy&#xA;has succeeded.&#xA;CVE-2022-48730:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma-buf: heaps: Fix potential spectre v1 gadget&#xA;It appears like nr could be a Spectre v1 gadget as it&#39;s supplied by a&#xA;user and used as an array index. Prevent the contents&#xA;of kernel memory from being leaked to userspace via speculative&#xA;execution by using array_index_nospec.&#xA; [sumits: added fixes and cc: stable tags]&#xA;CVE-2022-48768:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing/histogram: Fix a potential memory leak for kstrdup()&#xA;kfree() is missing on an error path to free the memory allocated by&#xA;kstrdup():&#xA;  p = param = kstrdup(data-&gt;params[i], GFP_KERNEL);&#xA;So it is better to free it via kfree(p).&#xA;CVE-2024-38388:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup&#xA;Use the control private_free callback to free the associated data&#xA;block. This ensures that the memory won&#39;t leak, whatever way the&#xA;control gets destroyed.&#xA;The original implementation didn&#39;t actually remove the ALSA&#xA;controls in hda_cs_dsp_control_remove(). It only freed the internal&#xA;tracking structure. This meant it was possible to remove/unload the&#xA;amp driver while leaving its ALSA controls still present in the&#xA;soundcard. Obviously attempting to access them could cause segfaults&#xA;or at least dereferencing stale pointers.&#xA;CVE-2022-48757:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: fix information leakage in /proc/net/ptype&#xA;In one net namespace, after creating a packet socket without binding&#xA;it to a device, users in other net namespaces can observe the new&#xA;`packet_type` added by this packet socket by reading `/proc/net/ptype`&#xA;file. This is minor information leakage as packet socket is&#xA;namespace aware.&#xA;Add a net pointer in `packet_type` to keep the net namespace of&#xA;of corresponding packet socket. In `ptype_seq_show`, this net pointer&#xA;must be checked when it is not NULL.&#xA;CVE-2021-47612:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: fix segfault in nfc_genl_dump_devices_done&#xA;When kmalloc in nfc_genl_dump_devices() fails then&#xA;nfc_genl_dump_devices_done() segfaults as below&#xA;KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014&#xA;Workqueue: events netlink_sock_destruct_work&#xA;RIP: 0010:klist_iter_exit+0x26/0x80&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;class_dev_iter_exit+0x15/0x20&#xA;nfc_genl_dump_devices_done+0x3b/0x50&#xA;genl_lock_done+0x84/0xd0&#xA;netlink_sock_destruct+0x8f/0x270&#xA;__sk_destruct+0x64/0x3b0&#xA;sk_destruct+0xa8/0xd0&#xA;__sk_free+0x2e8/0x3d0&#xA;sk_free+0x51/0x90&#xA;netlink_sock_destruct_work+0x1c/0x20&#xA;process_one_work+0x411/0x710&#xA;worker_thread+0x6fd/0xa80&#xA;CVE-2024-38551:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: mediatek: Assign dummy when codec not specified for a DAI link&#xA;MediaTek sound card drivers are checking whether a DAI link is present&#xA;and used on a board to assign the correct parameters and this is done&#xA;by checking the codec DAI names at probe time.&#xA;If no real codec is present, assign the dummy codec to the DAI link&#xA;to avoid NULL pointer during string comparison.&#xA;CVE-2024-38581:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu/mes: fix use-after-free issue&#xA;Delete fence fallback timer to fix the ramdom&#xA;use-after-free issue.&#xA;v2: move to amdgpu_mes.c&#xA;CVE-2024-38614:In the Linux kernel, the following vulnerability has been resolved:&#xA;openrisc: traps: Don&#39;t send signals to kernel mode threads&#xA;OpenRISC exception handling sends signals to user processes on floating&#xA;point exceptions and trap instructions (for debugging) among others.&#xA;There is a bug where the trap handling logic may send signals to kernel&#xA;threads, we should not send these signals to kernel threads, if that&#xA;happens we treat it as an error.&#xA;This patch adds conditions to die if the kernel receives these&#xA;exceptions in kernel mode code.&#xA;CVE-2024-39464:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: v4l: async: Fix notifier list entry init&#xA;struct v4l2_async_notifier has several list_head members, but only&#xA;waiting_list and done_list are initialized. notifier_entry was kept&#xA;&#39;zeroed&#39; leading to an uninitialized list_head.&#xA;This results in a NULL-pointer dereference if csi2_async_register() fails,&#xA;e.g. node for remote endpoint is disabled, and returns -ENOTCONN.&#xA;The following calls to v4l2_async_nf_unregister() results in a NULL&#xA;pointer dereference.&#xA;Add the missing list head initializer.&#xA;CVE-2024-39463:In the Linux kernel, the following vulnerability has been resolved:&#xA;9p: add missing locking around taking dentry fid list&#xA;Fix a use-after-free on dentry&#39;s d_fsdata fid list when a thread&#xA;looks up a fid through dentry while another thread unlinks it:&#xA;UAF thread:&#xA;refcount_t: addition on 0; use-after-free.&#xA; p9_fid_get linux/./include/net/9p/client.h:262&#xA; v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129&#xA; v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181&#xA; v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314&#xA; v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400&#xA; vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248&#xA;Freed by:&#xA; p9_fid_destroy (inlined)&#xA; p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456&#xA; p9_fid_put linux/./include/net/9p/client.h:278&#xA; v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55&#xA; v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518&#xA; vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335&#xA;The problem is that d_fsdata was not accessed under d_lock, because&#xA;d_release() normally is only called once the dentry is otherwise no&#xA;longer accessible but since we also call it explicitly in v9fs_remove&#xA;that lock is required:&#xA;move the hlist out of the dentry under lock then unref its fids once&#xA;they are no longer accessible.&#xA;CVE-2024-39479:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/i915/hwmon: Get rid of devm&#xA;When both hwmon and hwmon drvdata (on which hwmon depends) are device&#xA;managed resources, the expectation, on device unbind, is that hwmon will be&#xA;released before drvdata. However, in i915 there are two separate code&#xA;paths, which both release either drvdata or hwmon and either can be&#xA;released before the other. These code paths (for device unbind) are as&#xA;follows (see also the bug referenced below):&#xA;Call Trace:&#xA;release_nodes+0x11/0x70&#xA;devres_release_group+0xb2/0x110&#xA;component_unbind_all+0x8d/0xa0&#xA;component_del+0xa5/0x140&#xA;intel_pxp_tee_component_fini+0x29/0x40 [i915]&#xA;intel_pxp_fini+0x33/0x80 [i915]&#xA;i915_driver_remove+0x4c/0x120 [i915]&#xA;i915_pci_remove+0x19/0x30 [i915]&#xA;pci_device_remove+0x32/0xa0&#xA;device_release_driver_internal+0x19c/0x200&#xA;unbind_store+0x9c/0xb0&#xA;and&#xA;Call Trace:&#xA;release_nodes+0x11/0x70&#xA;devres_release_all+0x8a/0xc0&#xA;device_unbind_cleanup+0x9/0x70&#xA;device_release_driver_internal+0x1c1/0x200&#xA;unbind_store+0x9c/0xb0&#xA;This means that in i915, if use devm, we cannot gurantee that hwmon will&#xA;always be released before drvdata. Which means that we have a uaf if hwmon&#xA;sysfs is accessed when drvdata has been released but hwmon hasn&#39;t.&#xA;The only way out of this seems to be do get rid of devm_ and release/free&#xA;everything explicitly during device unbind.&#xA;v2: Change commit message and other minor code changes&#xA;v3: Cleanup from i915_hwmon_register on error (Armin Wolf)&#xA;v4: Eliminate potential static analyzer warning (Rodrigo)&#xA;    Eliminate fetch_and_zero (Jani)&#xA;v5: Restore previous logic for ddat_gt-&gt;hwmon_dev error return (Andi)&#xA;CVE-2024-39478:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: starfive - Do not free stack buffer&#xA;RSA text data uses variable length buffer allocated in software stack.&#xA;Calling kfree on it causes undefined behaviour in subsequent operations.&#xA;CVE-2024-39502:In the Linux kernel, the following vulnerability has been resolved:&#xA;ionic: fix use after netif_napi_del()&#xA;When queues are started, netif_napi_add() and napi_enable() are called.&#xA;If there are 4 queues and only 3 queues are used for the current&#xA;configuration, only 3 queues&#39; napi should be registered and enabled.&#xA;The ionic_qcq_enable() checks whether the .poll pointer is not NULL for&#xA;enabling only the using queue&#39; napi. Unused queues&#39; napi will not be&#xA;registered by netif_napi_add(), so the .poll pointer indicates NULL.&#xA;But it couldn&#39;t distinguish whether the napi was unregistered or not&#xA;because netif_napi_del() doesn&#39;t reset the .poll pointer to NULL.&#xA;So, ionic_qcq_enable() calls napi_enable() for the queue, which was&#xA;unregistered by netif_napi_del().&#xA;Reproducer:&#xA;   ethtool -L &lt;interface name&gt; rx 1 tx 1 combined 0&#xA;   ethtool -L &lt;interface name&gt; rx 0 tx 0 combined 1&#xA;   ethtool -L &lt;interface name&gt; rx 0 tx 0 combined 4&#xA;Splat looks like:&#xA;kernel BUG at net/core/dev.c:6666!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16&#xA;Workqueue: events ionic_lif_deferred_work [ionic]&#xA;RIP: 0010:napi_enable+0x3b/0x40&#xA;Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f&#xA;RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029&#xA;RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28&#xA;RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001&#xA;R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000&#xA;R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20&#xA;FS:  0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? die+0x33/0x90&#xA; ? do_trap+0xd9/0x100&#xA; ? napi_enable+0x3b/0x40&#xA; ? do_error_trap+0x83/0xb0&#xA; ? napi_enable+0x3b/0x40&#xA; ? napi_enable+0x3b/0x40&#xA; ? exc_invalid_op+0x4e/0x70&#xA; ? napi_enable+0x3b/0x40&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? napi_enable+0x3b/0x40&#xA; ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; process_one_work+0x145/0x360&#xA; worker_thread+0x2bb/0x3d0&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0xcc/0x100&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x2d/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA;CVE-2024-40997:In the Linux kernel, the following vulnerability has been resolved:&#xA;cpufreq: amd-pstate: fix memory leak on CPU EPP exit&#xA;The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is&#xA;not freed in the analogous exit function, so fix that.&#xA;[ rjw: Subject and changelog edits ]&#xA;CVE-2024-40964:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()&#xA;The cs35l41_hda_unbind() function clears the hda_component entry&#xA;matching it&#39;s index and then dereferences the codec pointer held in the&#xA;first element of the hda_component array, this is an issue when the&#xA;device index was 0.&#xA;Instead use the codec pointer stashed in the cs35l41_hda structure as it&#xA;will still be valid.&#xA;CVE-2022-48732:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/nouveau: fix off by one in BIOS boundary checking&#xA;Bounds checking when parsing init scripts embedded in the BIOS reject&#xA;access to the last byte. This causes driver initialization to fail on&#xA;Apple eMac&#39;s with GeForce 2 MX GPUs, leaving the system with no working&#xA;console.&#xA;This is probably only seen on OpenFirmware machines like PowerPC Macs&#xA;because the BIOS image provided by OF is only the used parts of the ROM,&#xA;not a power-of-two blocks read from PCI directly so PCs always have&#xA;empty bytes at the end that are never accessed.&#xA;CVE-2024-38628:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.&#xA;Hang on to the control IDs instead of pointers since those are correctly&#xA;handled with locks.&#xA;CVE-2024-38572:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath12k: fix out-of-bound access of qmi_invoke_handler()&#xA;Currently, there is no terminator entry for ath12k_qmi_msg_handlers hence&#xA;facing below KASAN warning,&#xA; ==================================================================&#xA; BUG: KASAN: global-out-of-bounds in qmi_invoke_handler+0xa4/0x148&#xA; Read of size 8 at addr ffffffd00a6428d8 by task kworker/u8:2/1273&#xA; CPU: 0 PID: 1273 Comm: kworker/u8:2 Not tainted 5.4.213 #0&#xA; Workqueue: qmi_msg_handler qmi_data_ready_work&#xA; Call trace:&#xA;  dump_backtrace+0x0/0x20c&#xA;  show_stack+0x14/0x1c&#xA;  dump_stack+0xe0/0x138&#xA;  print_address_description.isra.5+0x30/0x330&#xA;  __kasan_report+0x16c/0x1bc&#xA;  kasan_report+0xc/0x14&#xA;  __asan_load8+0xa8/0xb0&#xA;  qmi_invoke_handler+0xa4/0x148&#xA;  qmi_handle_message+0x18c/0x1bc&#xA;  qmi_data_ready_work+0x4ec/0x528&#xA;  process_one_work+0x2c0/0x440&#xA;  worker_thread+0x324/0x4b8&#xA;  kthread+0x210/0x228&#xA;  ret_from_fork+0x10/0x18&#xA; The address belongs to the variable:&#xA;  ath12k_mac_mon_status_filter_default+0x4bd8/0xfffffffffffe2300 [ath12k]&#xA; [...]&#xA; ==================================================================&#xA;Add a dummy terminator entry at the end to assist the qmi_invoke_handler()&#xA;in traversing up to the terminator entry without accessing an&#xA;out-of-boundary index.&#xA;Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1&#xA;CVE-2024-27416:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST&#xA;If we received HCI_EV_IO_CAPA_REQUEST while&#xA;HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote&#xA;does support SSP since otherwise this event shouldn&#39;t be generated.&#xA;CVE-2022-48822:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: f_fs: Fix use-after-free for epfile&#xA;Consider a case where ffs_func_eps_disable is called from&#xA;ffs_func_disable as part of composition switch and at the&#xA;same time ffs_epfile_release get called from userspace.&#xA;ffs_epfile_release will free up the read buffer and call&#xA;ffs_data_closed which in turn destroys ffs-&gt;epfiles and&#xA;mark it as NULL. While this was happening the driver has&#xA;already initialized the local epfile in ffs_func_eps_disable&#xA;which is now freed and waiting to acquire the spinlock. Once&#xA;spinlock is acquired the driver proceeds with the stale value&#xA;of epfile and tries to free the already freed read buffer&#xA;causing use-after-free.&#xA;Following is the illustration of the race:&#xA;      CPU1                                  CPU2&#xA;   ffs_func_eps_disable&#xA;   epfiles (local copy)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;ffs_epfile_release&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;ffs_data_closed&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;if (last file closed)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;ffs_data_reset&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;ffs_data_clear&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;ffs_epfiles_destroy&#xA;spin_lock&#xA;dereference epfiles&#xA;Fix this races by taking epfiles local copy &amp; assigning it under&#xA;spinlock and if epfiles(local) is null then update it in ffs-&gt;epfiles&#xA;then finally destroy it.&#xA;Extending the scope further from the race, protecting the ep related&#xA;structures, and concurrent accesses.&#xA;CVE-2024-36935:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: ensure the copied buf is NUL terminated&#xA;Currently, we allocate a count-sized kernel buffer and copy count bytes&#xA;from userspace to that buffer. Later, we use sscanf on this buffer but we&#xA;don&#39;t ensure that the string is terminated inside the buffer, this can lead&#xA;to OOB read when using sscanf. Fix this issue by using memdup_user_nul&#xA;instead of memdup_user.&#xA;CVE-2024-36955:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()&#xA;The documentation for device_get_named_child_node() mentions this&#xA;important point:&#xA;&#34;&#xA;The caller is responsible for calling fwnode_handle_put() on the&#xA;returned fwnode pointer.&#xA;&#34;&#xA;Add fwnode_handle_put() to avoid a leaked reference.&#xA;CVE-2024-36956:In the Linux kernel, the following vulnerability has been resolved:&#xA;thermal/debugfs: Free all thermal zone debug memory on zone removal&#xA;Because thermal_debug_tz_remove() does not free all memory allocated for&#xA;thermal zone diagnostics, some of that memory becomes unreachable after&#xA;freeing the thermal zone&#39;s struct thermal_debugfs object.&#xA;Address this by making thermal_debug_tz_remove() free all of the memory&#xA;in question.&#xA;Cc :6.8+ &lt;stable@vger.kernel.org&gt; # 6.8+&#xA;CVE-2022-48807:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler&#xA;Currently, the same handler is called for both a NETDEV_BONDING_INFO&#xA;LAG unlink notification as for a NETDEV_UNREGISTER call.  This is&#xA;causing a problem though, since the netdev_notifier_info passed has&#xA;a different structure depending on which event is passed.  The problem&#xA;manifests as a call trace from a BUG: KASAN stack-out-of-bounds error.&#xA;Fix this by creating a handler specific to NETDEV_UNREGISTER that only&#xA;is passed valid elements in the netdev_notifier_info struct for the&#xA;NETDEV_UNREGISTER event.&#xA;Also included is the removal of an unbalanced dev_put on the peer_netdev&#xA;and related braces.&#xA;CVE-2024-36973:In the Linux kernel, the following vulnerability has been resolved:&#xA;misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe()&#xA;When auxiliary_device_add() returns error and then calls&#xA;auxiliary_device_uninit(), callback function&#xA;gp_auxiliary_device_release() calls ida_free() and&#xA;kfree(aux_device_wrapper) to free memory. We should&#39;t&#xA;call them again in the error handling path.&#xA;Fix this by skipping the redundant cleanup functions.&#xA;CVE-2022-48837:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: rndis: prevent integer overflow in rndis_set_response()&#xA;If &#34;BufOffset&#34; is very large the &#34;BufOffset + 8&#34; operation can have an&#xA;integer overflow.&#xA;CVE-2024-36951:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdkfd: range check cp bad op exception interrupts&#xA;Due to a CP interrupt bug, bad packet garbage exception codes are raised.&#xA;Do a range check so that the debugger and runtime do not receive garbage&#xA;codes.&#xA;Update the user api to guard exception code type checking as well.&#xA;CVE-2024-26978:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: max310x: fix NULL pointer dereference in I2C instantiation&#xA;When trying to instantiate a max14830 device from userspace:&#xA;    echo max14830 0x60 &gt; /sys/bus/i2c/devices/i2c-2/new_device&#xA;we get the following error:&#xA;    Unable to handle kernel NULL pointer dereference at virtual address...&#xA;    ...&#xA;    Call trace:&#xA;        max310x_i2c_probe+0x48/0x170 [max310x]&#xA;        i2c_device_probe+0x150/0x2a0&#xA;    ...&#xA;Add check for validity of devtype to prevent the error, and abort probe&#xA;with a meaningful error message.&#xA;CVE-2024-36967:In the Linux kernel, the following vulnerability has been resolved:&#xA;KEYS: trusted: Fix memory leak in tpm2_key_encode()&#xA;&#39;scratch&#39; is never freed. Fix this by calling kfree() in the success, and&#xA;in the error case.&#xA;CVE-2024-36031:In the Linux kernel, the following vulnerability has been resolved:&#xA;keys: Fix overwrite of key expiration on instantiation&#xA;The expiry time of a key is unconditionally overwritten during&#xA;instantiation, defaulting to turn it permanent. This causes a problem&#xA;for DNS resolution as the expiration set by user-space is overwritten to&#xA;TIME64_MAX, disabling further DNS updates. Fix this by restoring the&#xA;condition that key_set_expiry is only called when the pre-parser sets a&#xA;specific expiry.&#xA;CVE-2024-36979:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: bridge: mst: fix vlan use-after-free&#xA;syzbot reported a suspicious rcu usage[1] in bridge&#39;s mst code. While&#xA;fixing it I noticed that nothing prevents a vlan to be freed while&#xA;walking the list from the same path (br forward delay timer). Fix the rcu&#xA;usage and also make sure we are not accessing freed memory by making&#xA;br_mst_vlan_set_state use rcu read lock.&#xA;[1]&#xA; WARNING: suspicious RCU usage&#xA; 6.9.0-rc6-syzkaller #0 Not tainted&#xA; -----------------------------&#xA; net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!&#xA; ...&#xA; stack backtrace:&#xA; CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0&#xA; Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA; Call Trace:&#xA;  &lt;IRQ&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA;  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712&#xA;  nbp_vlan_group net/bridge/br_private.h:1599 [inline]&#xA;  br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105&#xA;  br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47&#xA;  br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88&#xA;  call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793&#xA;  expire_timers kernel/time/timer.c:1844 [inline]&#xA;  __run_timers kernel/time/timer.c:2418 [inline]&#xA;  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429&#xA;  run_timer_base kernel/time/timer.c:2438 [inline]&#xA;  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448&#xA;  __do_softirq+0x2c6/0x980 kernel/softirq.c:554&#xA;  invoke_softirq kernel/softirq.c:428 [inline]&#xA;  __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633&#xA;  irq_exit_rcu+0x9/0x30 kernel/softirq.c:645&#xA;  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]&#xA;  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043&#xA;  &lt;/IRQ&gt;&#xA;  &lt;TASK&gt;&#xA; asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702&#xA; RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758&#xA; Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 &lt;4b&gt; c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25&#xA; RSP: 0018:ffffc90013657100 EFLAGS: 00000206&#xA; RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001&#xA; RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60&#xA; RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0&#xA; R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28&#xA; R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246&#xA;CVE-2024-36881:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/userfaultfd: reset ptes when close() for wr-protected ones&#xA;Userfaultfd unregister includes a step to remove wr-protect bits from all&#xA;the relevant pgtable entries, but that only covered an explicit&#xA;UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself.  Cover&#xA;that too.  This fixes a WARN trace.&#xA;The only user visible side effect is the user can observe leftover&#xA;wr-protect bits even if the user close()ed on an userfaultfd when&#xA;releasing the last reference of it.  However hopefully that should be&#xA;harmless, and nothing bad should happen even if so.&#xA;This change is now more important after the recent page-table-check&#xA;patch we merged in mm-unstable (446dd9ad37d0 (&#34;mm/page_table_check:&#xA;support userfault wr-protect entries&#34;)), as we&#39;ll do sanity check on&#xA;uffd-wp bits without vma context.  So it&#39;s better if we can 100%&#xA;guarantee no uffd-wp bit leftovers, to make sure each report will be&#xA;valid.&#xA;CVE-2024-34030:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: of_property: Return error for int_map allocation failure&#xA;Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a&#xA;NULL pointer dereference in this case.&#xA;[bhelgaas: commit log]&#xA;CVE-2024-38385:In the Linux kernel, the following vulnerability has been resolved:&#xA;genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()&#xA;irq_find_at_or_after() dereferences the interrupt descriptor which is&#xA;returned by mt_find() while neither holding sparse_irq_lock nor RCU read&#xA;lock, which means the descriptor can be freed between mt_find() and the&#xA;dereference:&#xA;    CPU0                            CPU1&#xA;    desc = mt_find()&#xA;                                    delayed_free_desc(desc)&#xA;    irq_desc_get_irq(desc)&#xA;The use-after-free is reported by KASAN:&#xA;    Call trace:&#xA;     irq_get_next_irq+0x58/0x84&#xA;     show_stat+0x638/0x824&#xA;     seq_read_iter+0x158/0x4ec&#xA;     proc_reg_read_iter+0x94/0x12c&#xA;     vfs_read+0x1e0/0x2c8&#xA;    Freed by task 4471:&#xA;     slab_free_freelist_hook+0x174/0x1e0&#xA;     __kmem_cache_free+0xa4/0x1dc&#xA;     kfree+0x64/0x128&#xA;     irq_kobj_release+0x28/0x3c&#xA;     kobject_put+0xcc/0x1e0&#xA;     delayed_free_desc+0x14/0x2c&#xA;     rcu_do_batch+0x214/0x720&#xA;Guard the access with a RCU read lock section.&#xA;CVE-2024-39485:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: v4l: async: Properly re-initialise notifier entry in unregister&#xA;The notifier_entry of a notifier is not re-initialised after unregistering&#xA;the notifier. This leads to dangling pointers being left there so use&#xA;list_del_init() to return the notifier_entry an empty list.&#xA;CVE-2024-40957:In the Linux kernel, the following vulnerability has been resolved:&#xA;seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors&#xA;input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for&#xA;PREROUTING hook, in PREROUTING hook, we should passing a valid indev,&#xA;and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer&#xA;dereference, as below:&#xA;    [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090&#xA;    [74830.655633] #PF: supervisor read access in kernel mode&#xA;    [74830.657888] #PF: error_code(0x0000) - not-present page&#xA;    [74830.659500] PGD 0 P4D 0&#xA;    [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI&#xA;    ...&#xA;    [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011&#xA;    [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]&#xA;    ...&#xA;    [74830.689725] Call Trace:&#xA;    [74830.690402]  &lt;IRQ&gt;&#xA;    [74830.690953]  ? show_trace_log_lvl+0x1c4/0x2df&#xA;    [74830.692020]  ? show_trace_log_lvl+0x1c4/0x2df&#xA;    [74830.693095]  ? ipt_do_table+0x286/0x710 [ip_tables]&#xA;    [74830.694275]  ? __die_body.cold+0x8/0xd&#xA;    [74830.695205]  ? page_fault_oops+0xac/0x140&#xA;    [74830.696244]  ? exc_page_fault+0x62/0x150&#xA;    [74830.697225]  ? asm_exc_page_fault+0x22/0x30&#xA;    [74830.698344]  ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]&#xA;    [74830.699540]  ipt_do_table+0x286/0x710 [ip_tables]&#xA;    [74830.700758]  ? ip6_route_input+0x19d/0x240&#xA;    [74830.701752]  nf_hook_slow+0x3f/0xb0&#xA;    [74830.702678]  input_action_end_dx4+0x19b/0x1e0&#xA;    [74830.703735]  ? input_action_end_t+0xe0/0xe0&#xA;    [74830.704734]  seg6_local_input_core+0x2d/0x60&#xA;    [74830.705782]  lwtunnel_input+0x5b/0xb0&#xA;    [74830.706690]  __netif_receive_skb_one_core+0x63/0xa0&#xA;    [74830.707825]  process_backlog+0x99/0x140&#xA;    [74830.709538]  __napi_poll+0x2c/0x160&#xA;    [74830.710673]  net_rx_action+0x296/0x350&#xA;    [74830.711860]  __do_softirq+0xcb/0x2ac&#xA;    [74830.713049]  do_softirq+0x63/0x90&#xA;input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally&#xA;trigger a NULL dereference in rpfilter_mt()-&gt;rpfilter_is_loopback():&#xA;    static bool&#xA;    rpfilter_is_loopback(const struct sk_buff *skb,&#xA;          &#x9;       const struct net_device *in)&#xA;    {&#xA;            // in is NULL&#xA;            return skb-&gt;pkt_type == PACKET_LOOPBACK ||&#xA;          &#x9; in-&gt;flags &amp; IFF_LOOPBACK;&#xA;    }&#xA;CVE-2024-40923:In the Linux kernel, the following vulnerability has been resolved:&#xA;vmxnet3: disable rx data ring on dma allocation failure&#xA;When vmxnet3_rq_create() fails to allocate memory for rq-&gt;data_ring.base,&#xA;the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset&#xA;rq-&gt;data_ring.desc_size for the data ring that failed, which presumably&#xA;causes the hypervisor to reference it on packet reception.&#xA;To fix this bug, rq-&gt;data_ring.desc_size needs to be set to 0 to tell&#xA;the hypervisor to disable this feature.&#xA;[   95.436876] kernel BUG at net/core/skbuff.c:207!&#xA;[   95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;[   95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1&#xA;[   95.441558] Hardware name: VMware, Inc. VMware Virtual&#xA;Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018&#xA;[   95.443481] RIP: 0010:skb_panic+0x4d/0x4f&#xA;[   95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50&#xA;ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9&#xA;ff &lt;0f&gt; 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24&#xA;[   95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246&#xA;[   95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f&#xA;[   95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f&#xA;[   95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60&#xA;[   95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000&#xA;[   95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0&#xA;[   95.455682] FS:  0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000&#xA;[   95.457178] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0&#xA;[   95.459791] Call Trace:&#xA;[   95.460515]  &lt;IRQ&gt;&#xA;[   95.461180]  ? __die_body.cold+0x19/0x27&#xA;[   95.462150]  ? die+0x2e/0x50&#xA;[   95.462976]  ? do_trap+0xca/0x110&#xA;[   95.463973]  ? do_error_trap+0x6a/0x90&#xA;[   95.464966]  ? skb_panic+0x4d/0x4f&#xA;[   95.465901]  ? exc_invalid_op+0x50/0x70&#xA;[   95.466849]  ? skb_panic+0x4d/0x4f&#xA;[   95.467718]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[   95.468758]  ? skb_panic+0x4d/0x4f&#xA;[   95.469655]  skb_put.cold+0x10/0x10&#xA;[   95.470573]  vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]&#xA;[   95.471853]  vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]&#xA;[   95.473185]  __napi_poll+0x2b/0x160&#xA;[   95.474145]  net_rx_action+0x2c6/0x3b0&#xA;[   95.475115]  handle_softirqs+0xe7/0x2a0&#xA;[   95.476122]  __irq_exit_rcu+0x97/0xb0&#xA;[   95.477109]  common_interrupt+0x85/0xa0&#xA;[   95.478102]  &lt;/IRQ&gt;&#xA;[   95.478846]  &lt;TASK&gt;&#xA;[   95.479603]  asm_common_interrupt+0x26/0x40&#xA;[   95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20&#xA;[   95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 &lt;e9&gt; 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90&#xA;[   95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246&#xA;[   95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000&#xA;[   95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001&#xA;[   95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3&#xA;[   95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260&#xA;[   95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000&#xA;[   95.495035]  acpi_safe_halt+0x14/0x20&#xA;[   95.496127]  acpi_idle_do_entry+0x2f/0x50&#xA;[   95.497221]  acpi_idle_enter+0x7f/0xd0&#xA;[   95.498272]  cpuidle_enter_state+0x81/0x420&#xA;[   95.499375]  cpuidle_enter+0x2d/0x40&#xA;[   95.500400]  do_idle+0x1e5/0x240&#xA;[   95.501385]  cpu_startup_entry+0x29/0x30&#xA;[   95.502422]  start_secondary+0x11c/0x140&#xA;[   95.503454]  common_startup_64+0x13e/0x141&#xA;[   95.504466]  &lt;/TASK&gt;&#xA;[   95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4&#xA;nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6&#xA;nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip&#xA;---truncated---&#xA;CVE-2024-40918:In the Linux kernel, the following vulnerability has been resolved:&#xA;parisc: Try to fix random segmentation faults in package builds&#xA;PA-RISC systems with PA8800 and PA8900 processors have had problems&#xA;with random segmentation faults for many years.  Systems with earlier&#xA;processors are much more stable.&#xA;Systems with PA8800 and PA8900 processors have a large L2 cache which&#xA;needs per page flushing for decent performance when a large range is&#xA;flushed. The combined cache in these systems is also more sensitive to&#xA;non-equivalent aliases than the caches in earlier systems.&#xA;The majority of random segmentation faults that I have looked at&#xA;appear to be memory corruption in memory allocated using mmap and&#xA;malloc.&#xA;My first attempt at fixing the random faults didn&#39;t work. On&#xA;reviewing the cache code, I realized that there were two issues&#xA;which the existing code didn&#39;t handle correctly. Both relate&#xA;to cache move-in. Another issue is that the present bit in PTEs&#xA;is racy.&#xA;1) PA-RISC caches have a mind of their own and they can speculatively&#xA;load data and instructions for a page as long as there is a entry in&#xA;the TLB for the page which allows move-in. TLBs are local to each&#xA;CPU. Thus, the TLB entry for a page must be purged before flushing&#xA;the page. This is particularly important on SMP systems.&#xA;In some of the flush routines, the flush routine would be called&#xA;and then the TLB entry would be purged. This was because the flush&#xA;routine needed the TLB entry to do the flush.&#xA;2) My initial approach to trying the fix the random faults was to&#xA;try and use flush_cache_page_if_present for all flush operations.&#xA;This actually made things worse and led to a couple of hardware&#xA;lockups. It finally dawned on me that some lines weren&#39;t being&#xA;flushed because the pte check code was racy. This resulted in&#xA;random inequivalent mappings to physical pages.&#xA;The __flush_cache_page tmpalias flush sets up its own TLB entry&#xA;and it doesn&#39;t need the existing TLB entry. As long as we can find&#xA;the pte pointer for the vm page, we can get the pfn and physical&#xA;address of the page. We can also purge the TLB entry for the page&#xA;before doing the flush. Further, __flush_cache_page uses a special&#xA;TLB entry that inhibits cache move-in.&#xA;When switching page mappings, we need to ensure that lines are&#xA;removed from the cache.  It is not sufficient to just flush the&#xA;lines to memory as they may come back.&#xA;This made it clear that we needed to implement all the required&#xA;flush operations using tmpalias routines. This includes flushes&#xA;for user and kernel pages.&#xA;After modifying the code to use tmpalias flushes, it became clear&#xA;that the random segmentation faults were not fully resolved. The&#xA;frequency of faults was worse on systems with a 64 MB L2 (PA8900)&#xA;and systems with more CPUs (rp4440).&#xA;The warning that I added to flush_cache_page_if_present to detect&#xA;pages that couldn&#39;t be flushed triggered frequently on some systems.&#xA;Helge and I looked at the pages that couldn&#39;t be flushed and found&#xA;that the PTE was either cleared or for a swap page. Ignoring pages&#xA;that were swapped out seemed okay but pages with cleared PTEs seemed&#xA;problematic.&#xA;I looked at routines related to pte_clear and noticed ptep_clear_flush.&#xA;The default implementation just flushes the TLB entry. However, it was&#xA;obvious that on parisc we need to flush the cache page as well. If&#xA;we don&#39;t flush the cache page, stale lines will be left in the cache&#xA;and cause random corruption. Once a PTE is cleared, there is no way&#xA;to find the physical address associated with the PTE and flush the&#xA;associated page at a later time.&#xA;I implemented an updated change with a parisc specific version of&#xA;ptep_clear_flush. It fixed the random data corruption on Helge&#39;s rp4440&#xA;and rp3440, as well as on my c8000.&#xA;At this point, I realized that I could restore the code where we only&#xA;flush in flush_cache_page_if_present if the page has been accessed.&#xA;However, for this, we also need to flush the cache when the accessed&#xA;bit is cleared in&#xA;---truncated---&#xA;CVE-2024-40936:In the Linux kernel, the following vulnerability has been resolved:&#xA;cxl/region: Fix memregion leaks in devm_cxl_add_region()&#xA;Move the mode verification to __create_region() before allocating the&#xA;memregion to avoid the memregion leaks.&#xA;CVE-2024-40975:In the Linux kernel, the following vulnerability has been resolved:&#xA;platform/x86: x86-android-tablets: Unregister devices in reverse order&#xA;Not all subsystems support a device getting removed while there are&#xA;still consumers of the device with a reference to the device.&#xA;One example of this is the regulator subsystem. If a regulator gets&#xA;unregistered while there are still drivers holding a reference&#xA;a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:&#xA; WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister&#xA; Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015&#xA; RIP: 0010:regulator_unregister&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  regulator_unregister&#xA;  devres_release_group&#xA;  i2c_device_remove&#xA;  device_release_driver_internal&#xA;  bus_remove_device&#xA;  device_del&#xA;  device_unregister&#xA;  x86_android_tablet_remove&#xA;On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides&#xA;a 5V boost converter output for powering USB devices connected to the micro&#xA;USB port, the bq24190-charger driver exports this as a Vbus regulator.&#xA;On the 830 (8&#34;) and 1050 (&#34;10&#34;) models this regulator is controlled by&#xA;a platform_device and x86_android_tablet_remove() removes platform_device-s&#xA;before i2c_clients so the consumer gets removed first.&#xA;But on the 1380 (13&#34;) model there is a lc824206xa micro-USB switch&#xA;connected over I2C and the extcon driver for that controls the regulator.&#xA;The bq24190 i2c-client *must* be registered first, because that creates&#xA;the regulator with the lc824206xa listed as its consumer. If the regulator&#xA;has not been registered yet the lc824206xa driver will end up getting&#xA;a dummy regulator.&#xA;Since in this case both the regulator provider and consumer are I2C&#xA;devices, the only way to ensure that the consumer is unregistered first&#xA;is to unregister the I2C devices in reverse order of in which they were&#xA;created.&#xA;For consistency and to avoid similar problems in the future change&#xA;x86_android_tablet_remove() to unregister all device types in reverse&#xA;order.&#xA;CVE-2024-40951:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()&#xA;bdev-&gt;bd_super has been removed and commit 8887b94d9322 change the usage&#xA;from bdev-&gt;bd_super to b_assoc_map-&gt;host-&gt;i_sb.  Since ocfs2 hasn&#39;t set&#xA;bh-&gt;b_assoc_map, it will trigger NULL pointer dereference when calling&#xA;into ocfs2_abort_trigger().&#xA;Actually this was pointed out in history, see commit 74e364ad1b13.  But&#xA;I&#39;ve made a mistake when reviewing commit 8887b94d9322 and then&#xA;re-introduce this regression.&#xA;Since we cannot revive bdev in buffer head, so fix this issue by&#xA;initializing all types of ocfs2 triggers when fill super, and then get the&#xA;specific ocfs2 trigger from ocfs2_caching_info when access journal.&#xA;[joseph.qi@linux.alibaba.com: v2]&#xA;  Link: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com&#xA;CVE-2024-40977:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mt76: mt7921s: fix potential hung tasks during chip recovery&#xA;During chip recovery (e.g. chip reset), there is a possible situation that&#xA;kernel worker reset_work is holding the lock and waiting for kernel thread&#xA;stat_worker to be parked, while stat_worker is waiting for the release of&#xA;the same lock.&#xA;It causes a deadlock resulting in the dumping of hung tasks messages and&#xA;possible rebooting of the device.&#xA;This patch prevents the execution of stat_worker during the chip recovery.&#xA;CVE-2022-48775:In the Linux kernel, the following vulnerability has been resolved:&#xA;Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj&#xA;kobject_init_and_add() takes reference even when it fails.&#xA;According to the doc of kobject_init_and_add()：&#xA;   If this function returns an error, kobject_put() must be called to&#xA;   properly clean up the memory associated with the object.&#xA;Fix memory leak by calling kobject_put().&#xA;CVE-2022-48788:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvme-rdma: fix possible use-after-free in transport error_recovery work&#xA;While nvme_rdma_submit_async_event_work is checking the ctrl and queue&#xA;state before preparing the AER command and scheduling io_work, in order&#xA;to fully prevent a race where this check is not reliable the error&#xA;recovery work must flush async_event_work before continuing to destroy&#xA;the admin queue after setting the ctrl state to RESETTING such that&#xA;there is no race .submit_async_event and the error recovery handler&#xA;itself changing the ctrl state.&#xA;CVE-2022-48865:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: fix kernel panic when enabling bearer&#xA;When enabling a bearer on a node, a kernel panic is observed:&#xA;[    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]&#xA;...&#xA;[    4.520030] Call Trace:&#xA;[    4.520689]  &lt;IRQ&gt;&#xA;[    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]&#xA;[    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]&#xA;[    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]&#xA;[    4.525292]  tipc_rcv+0x5da/0x730 [tipc]&#xA;[    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0&#xA;[    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]&#xA;[    4.528737]  __netif_receive_skb_list_core+0x20b/0x260&#xA;[    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0&#xA;[    4.531450]  ? dev_gro_receive+0x4c2/0x680&#xA;[    4.532512]  napi_complete_done+0x6f/0x180&#xA;[    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]&#xA;...&#xA;The node in question is receiving activate messages in another&#xA;thread after changing bearer status to allow message sending/&#xA;receiving in current thread:&#xA;         thread 1           |              thread 2&#xA;         --------           |              --------&#xA;                            |&#xA;tipc_enable_bearer()        |&#xA;  test_and_set_bit_lock()   |&#xA;    tipc_bearer_xmit_skb()  |&#xA;                            | tipc_l2_rcv_msg()&#xA;                            |   tipc_rcv()&#xA;                            |     __tipc_node_link_up()&#xA;                            |       tipc_link_build_state_msg()&#xA;                            |         tipc_link_build_proto_msg()&#xA;                            |           tipc_mon_prep()&#xA;                            |           {&#xA;                            |             ...&#xA;                            |             // null-pointer dereference&#xA;                            |             u16 gen = mon-&gt;dom_gen;&#xA;                            |             ...&#xA;                            |           }&#xA;  // Not being executed yet |&#xA;  tipc_mon_create()         |&#xA;  {                         |&#xA;    ...                     |&#xA;    // allocate             |&#xA;    mon = kzalloc();        |&#xA;    ...                     |&#xA;  }                         |&#xA;Monitoring pointer in thread 2 is dereferenced before monitoring data&#xA;is allocated in thread 1. This causes kernel panic.&#xA;This commit fixes it by allocating the monitoring data before enabling&#xA;the bearer to receive messages.&#xA;CVE-2022-48856:In the Linux kernel, the following vulnerability has been resolved:&#xA;gianfar: ethtool: Fix refcount leak in gfar_get_ts_info&#xA;The of_find_compatible_node() function returns a node pointer with&#xA;refcount incremented, We should use of_node_put() on it when done&#xA;Add the missing of_node_put() to release the refcount.&#xA;CVE-2022-48838:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: Fix use-after-free bug by not setting udc-&gt;dev.driver&#xA;The syzbot fuzzer found a use-after-free bug:&#xA;BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320&#xA;Read of size 8 at addr ffff88802b934098 by task udevd/3689&#xA;CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106&#xA; print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255&#xA; __kasan_report mm/kasan/report.c:442 [inline]&#xA; kasan_report.cold+0x83/0xdf mm/kasan/report.c:459&#xA; dev_uevent+0x712/0x780 drivers/base/core.c:2320&#xA; uevent_show+0x1b8/0x380 drivers/base/core.c:2391&#xA; dev_attr_show+0x4b/0x90 drivers/base/core.c:2094&#xA;Although the bug manifested in the driver core, the real cause was a&#xA;race with the gadget core.  dev_uevent() does:&#xA;&#x9;if (dev-&gt;driver)&#xA;&#x9;&#x9;add_uevent_var(env, &#34;DRIVER=%s&#34;, dev-&gt;driver-&gt;name);&#xA;and between the test and the dereference of dev-&gt;driver, the gadget&#xA;core sets dev-&gt;driver to NULL.&#xA;The race wouldn&#39;t occur if the gadget core registered its devices on&#xA;a real bus, using the standard synchronization techniques of the&#xA;driver core.  However, it&#39;s not necessary to make such a large change&#xA;in order to fix this bug; all we need to do is make sure that&#xA;udc-&gt;dev.driver is always NULL.&#xA;In fact, there is no reason for udc-&gt;dev.driver ever to be set to&#xA;anything, let alone to the value it currently gets: the address of the&#xA;gadget&#39;s driver.  After all, a gadget driver only knows how to manage&#xA;a gadget, not how to manage a UDC.&#xA;This patch simply removes the statements in the gadget core that touch&#xA;udc-&gt;dev.driver.&#xA;CVE-2024-38593:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: micrel: Fix receiving the timestamp in the frame for lan8841&#xA;The blamed commit started to use the ptp workqueue to get the second&#xA;part of the timestamp. And when the port was set down, then this&#xA;workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING&#xA;is not enabled, then the ptp_clock is not initialized so then it would&#xA;crash when it would try to access the delayed work.&#xA;So then basically by setting up and then down the port, it would crash.&#xA;The fix consists in checking if the ptp_clock is initialized and only&#xA;then cancel the delayed work.&#xA;CVE-2024-36962:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs&#xA;Currently the driver uses local_bh_disable()/local_bh_enable() in its&#xA;IRQ handler to avoid triggering net_rx_action() softirq on exit from&#xA;netif_rx(). The net_rx_action() could trigger this driver .start_xmit&#xA;callback, which is protected by the same lock as the IRQ handler, so&#xA;calling the .start_xmit from netif_rx() from the IRQ handler critical&#xA;section protected by the lock could lead to an attempt to claim the&#xA;already claimed lock, and a hang.&#xA;The local_bh_disable()/local_bh_enable() approach works only in case&#xA;the IRQ handler is protected by a spinlock, but does not work if the&#xA;IRQ handler is protected by mutex, i.e. this works for KS8851 with&#xA;Parallel bus interface, but not for KS8851 with SPI bus interface.&#xA;Remove the BH manipulation and instead of calling netif_rx() inside&#xA;the IRQ handler code protected by the lock, queue all the received&#xA;SKBs in the IRQ handler into a queue first, and once the IRQ handler&#xA;exits the critical section protected by the lock, dequeue all the&#xA;queued SKBs and push them all into netif_rx(). At this point, it is&#xA;safe to trigger the net_rx_action() softirq, since the netif_rx()&#xA;call is outside of the lock that protects the IRQ handler.&#xA;CVE-2024-38557:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Reload only IB representors upon lag disable/enable&#xA;On lag disable, the bond IB device along with all of its&#xA;representors are destroyed, and then the slaves&#39; representors get reloaded.&#xA;In case the slave IB representor load fails, the eswitch error flow&#xA;unloads all representors, including ethernet representors, where the&#xA;netdevs get detached and removed from lag bond. Such flow is inaccurate&#xA;as the lag driver is not responsible for loading/unloading ethernet&#xA;representors. Furthermore, the flow described above begins by holding&#xA;lag lock to prevent bond changes during disable flow. However, when&#xA;reaching the ethernet representors detachment from lag, the lag lock is&#xA;required again, triggering the following deadlock:&#xA;Call trace:&#xA;__switch_to+0xf4/0x148&#xA;__schedule+0x2c8/0x7d0&#xA;schedule+0x50/0xe0&#xA;schedule_preempt_disabled+0x18/0x28&#xA;__mutex_lock.isra.13+0x2b8/0x570&#xA;__mutex_lock_slowpath+0x1c/0x28&#xA;mutex_lock+0x4c/0x68&#xA;mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]&#xA;mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]&#xA;mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]&#xA;mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]&#xA;mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]&#xA;mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]&#xA;mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]&#xA;mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]&#xA;mlx5_disable_lag+0x130/0x138 [mlx5_core]&#xA;mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev-&gt;lock&#xA;mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]&#xA;devlink_nl_cmd_eswitch_set_doit+0xdc/0x180&#xA;genl_family_rcv_msg_doit.isra.17+0xe8/0x138&#xA;genl_rcv_msg+0xe4/0x220&#xA;netlink_rcv_skb+0x44/0x108&#xA;genl_rcv+0x40/0x58&#xA;netlink_unicast+0x198/0x268&#xA;netlink_sendmsg+0x1d4/0x418&#xA;sock_sendmsg+0x54/0x60&#xA;__sys_sendto+0xf4/0x120&#xA;__arm64_sys_sendto+0x30/0x40&#xA;el0_svc_common+0x8c/0x120&#xA;do_el0_svc+0x30/0xa0&#xA;el0_svc+0x20/0x30&#xA;el0_sync_handler+0x90/0xb8&#xA;el0_sync+0x160/0x180&#xA;Thus, upon lag enable/disable, load and unload only the IB representors&#xA;of the slaves preventing the deadlock mentioned above.&#xA;While at it, refactor the mlx5_esw_offloads_rep_load() function to have&#xA;a static helper method for its internal logic, in symmetry with the&#xA;representor unload design.&#xA;CVE-2024-38562:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: nl80211: Avoid address calculations via out of bounds array indexing&#xA;Before request-&gt;channels[] can be used, request-&gt;n_channels must be set.&#xA;Additionally, address calculations for memory after the &#34;channels&#34; array&#xA;need to be calculated from the allocation base (&#34;request&#34;) rather than&#xA;via the first &#34;out of bounds&#34; index of &#34;channels&#34;, otherwise run-time&#xA;bounds checking will throw a warning.&#xA;CVE-2024-38604:In the Linux kernel, the following vulnerability has been resolved:&#xA;block: refine the EOF check in blkdev_iomap_begin&#xA;blkdev_iomap_begin rounds down the offset to the logical block size&#xA;before stashing it in iomap-&gt;offset and checking that it still is&#xA;inside the inode size.&#xA;Check the i_size check to the raw pos value so that we don&#39;t try a&#xA;zero size write if iter-&gt;pos is unaligned.&#xA;CVE-2024-38584:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()&#xA;In the prueth_probe() function, if one of the calls to emac_phy_connect()&#xA;fails due to of_phy_connect() returning NULL, then the subsequent call to&#xA;phy_attached_info() will dereference a NULL pointer.&#xA;Check the return code of emac_phy_connect and fail cleanly if there is an&#xA;error.&#xA;CVE-2024-38616:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: carl9170: re-fix fortified-memset warning&#xA;The carl9170_tx_release() function sometimes triggers a fortified-memset&#xA;warning in my randconfig builds:&#xA;In file included from include/linux/string.h:254,&#xA;                 from drivers/net/wireless/ath/carl9170/tx.c:40:&#xA;In function &#39;fortify_memset_chk&#39;,&#xA;    inlined from &#39;carl9170_tx_release&#39; at drivers/net/wireless/ath/carl9170/tx.c:283:2,&#xA;    inlined from &#39;kref_put&#39; at include/linux/kref.h:65:3,&#xA;    inlined from &#39;carl9170_tx_put_skb&#39; at drivers/net/wireless/ath/carl9170/tx.c:342:9:&#xA;include/linux/fortify-string.h:493:25: error: call to &#39;__write_overflow_field&#39; declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]&#xA;  493 |                         __write_overflow_field(p_size_field, size);&#xA;Kees previously tried to avoid this by using memset_after(), but it seems&#xA;this does not fully address the problem. I noticed that the memset_after()&#xA;here is done on a different part of the union (status) than the original&#xA;cast was from (rate_driver_data), which may confuse the compiler.&#xA;Unfortunately, the memset_after() trick does not work on driver_rates[]&#xA;because that is part of an anonymous struct, and I could not get&#xA;struct_group() to do this either. Using two separate memset() calls&#xA;on the two members does address the warning though.&#xA;CVE-2021-47610:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/msm: Fix null ptr access msm_ioctl_gem_submit()&#xA;Fix the below null pointer dereference in msm_ioctl_gem_submit():&#xA; 26545.260705:   Call trace:&#xA; 26545.263223:    kref_put+0x1c/0x60&#xA; 26545.266452:    msm_ioctl_gem_submit+0x254/0x744&#xA; 26545.270937:    drm_ioctl_kernel+0xa8/0x124&#xA; 26545.274976:    drm_ioctl+0x21c/0x33c&#xA; 26545.278478:    drm_compat_ioctl+0xdc/0xf0&#xA; 26545.282428:    __arm64_compat_sys_ioctl+0xc8/0x100&#xA; 26545.287169:    el0_svc_common+0xf8/0x250&#xA; 26545.291025:    do_el0_svc_compat+0x28/0x54&#xA; 26545.295066:    el0_svc_compat+0x10/0x1c&#xA; 26545.298838:    el0_sync_compat_handler+0xa8/0xcc&#xA; 26545.303403:    el0_sync_compat+0x188/0x1c0&#xA; 26545.307445:   Code: d503201f d503201f 52800028 4b0803e8 (b8680008)&#xA; 26545.318799:   Kernel panic - not syncing: Oops: Fatal exception&#xA;CVE-2023-52883:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix possible null pointer dereference&#xA;abo-&gt;tbo.resource may be NULL in amdgpu_vm_bo_update.&#xA;CVE-2024-38622:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/msm/dpu: Add callback function pointer check before its call&#xA;In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,&#xA;but then callback function is unconditionally called by this pointer.&#xA;Fix this bug by adding conditional return.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;Patchwork: https://patchwork.freedesktop.org/patch/588237/&#xA;CVE-2024-38664:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm: zynqmp_dpsub: Always register bridge&#xA;We must always register the DRM bridge, since zynqmp_dp_hpd_work_func&#xA;calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be&#xA;initialized. We do this before zynqmp_dpsub_drm_init since that calls&#xA;drm_bridge_attach. This fixes the following lockdep warning:&#xA;[   19.217084] ------------[ cut here ]------------&#xA;[   19.227530] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)&#xA;[   19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550&#xA;[   19.241696] Modules linked in:&#xA;[   19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96&#xA;[   19.252046] Hardware name: xlnx,zynqmp (DT)&#xA;[   19.256421] Workqueue: events zynqmp_dp_hpd_work_func&#xA;[   19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[   19.269104] pc : __mutex_lock+0x4bc/0x550&#xA;[   19.273364] lr : __mutex_lock+0x4bc/0x550&#xA;[   19.277592] sp : ffffffc085c5bbe0&#xA;[   19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8&#xA;[   19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000&#xA;[   19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000&#xA;[   19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000&#xA;[   19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720&#xA;[   19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001&#xA;[   19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888&#xA;[   19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000&#xA;[   19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000&#xA;[   19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880&#xA;[   19.356581] Call trace:&#xA;[   19.359160]  __mutex_lock+0x4bc/0x550&#xA;[   19.363032]  mutex_lock_nested+0x24/0x30&#xA;[   19.367187]  drm_bridge_hpd_notify+0x2c/0x6c&#xA;[   19.371698]  zynqmp_dp_hpd_work_func+0x44/0x54&#xA;[   19.376364]  process_one_work+0x3ac/0x988&#xA;[   19.380660]  worker_thread+0x398/0x694&#xA;[   19.384736]  kthread+0x1bc/0x1c0&#xA;[   19.388241]  ret_from_fork+0x10/0x20&#xA;[   19.392031] irq event stamp: 183&#xA;[   19.395450] hardirqs last  enabled at (183): [&lt;ffffffc0800b9278&gt;] finish_task_switch.isra.0+0xa8/0x2d4&#xA;[   19.405140] hardirqs last disabled at (182): [&lt;ffffffc081ad3754&gt;] __schedule+0x714/0xd04&#xA;[   19.413612] softirqs last  enabled at (114): [&lt;ffffffc080133de8&gt;] srcu_invoke_callbacks+0x158/0x23c&#xA;[   19.423128] softirqs last disabled at (110): [&lt;ffffffc080133de8&gt;] srcu_invoke_callbacks+0x158/0x23c&#xA;[   19.432614] ---[ end trace 0000000000000000 ]---&#xA;(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)&#xA;CVE-2024-39371:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring: check for non-NULL file pointer in io_file_can_poll()&#xA;In earlier kernels, it was possible to trigger a NULL pointer&#xA;dereference off the forced async preparation path, if no file had&#xA;been assigned. The trace leading to that looks as follows:&#xA;BUG: kernel NULL pointer dereference, address: 00000000000000b0&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] PREEMPT SMP&#xA;CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022&#xA;RIP: 0010:io_buffer_select+0xc3/0x210&#xA;Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 &lt;48&gt; 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b&#xA;RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246&#xA;RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040&#xA;RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700&#xA;RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020&#xA;R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8&#xA;R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000&#xA;FS:  00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die+0x1f/0x60&#xA; ? page_fault_oops+0x14d/0x420&#xA; ? do_user_addr_fault+0x61/0x6a0&#xA; ? exc_page_fault+0x6c/0x150&#xA; ? asm_exc_page_fault+0x22/0x30&#xA; ? io_buffer_select+0xc3/0x210&#xA; __io_import_iovec+0xb5/0x120&#xA; io_readv_prep_async+0x36/0x70&#xA; io_queue_sqe_fallback+0x20/0x260&#xA; io_submit_sqes+0x314/0x630&#xA; __do_sys_io_uring_enter+0x339/0xbc0&#xA; ? __do_sys_io_uring_register+0x11b/0xc50&#xA; ? vm_mmap_pgoff+0xce/0x160&#xA; do_syscall_64+0x5f/0x180&#xA; entry_SYSCALL_64_after_hwframe+0x46/0x4e&#xA;RIP: 0033:0x55e0a110a67e&#xA;Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 &lt;c3&gt; 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6&#xA;because the request is marked forced ASYNC and has a bad file fd, and&#xA;hence takes the forced async prep path.&#xA;Current kernels with the request async prep cleaned up can no longer hit&#xA;this issue, but for ease of backporting, let&#39;s add this safety check in&#xA;here too as it really doesn&#39;t hurt. For both cases, this will inevitably&#xA;end with a CQE posted with -EBADF.&#xA;CVE-2024-39468:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix deadlock in smb2_find_smb_tcon()&#xA;Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such&#xA;deadlock.&#xA;CVE-2021-47583:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: mxl111sf: change mutex_init() location&#xA;Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized&#xA;mutex. The problem was in wrong mutex_init() location.&#xA;Previous mutex_init(&amp;state-&gt;msg_lock) call was in -&gt;init() function, but&#xA;dvb_usbv2_init() has this order of calls:&#xA;&#x9;dvb_usbv2_init()&#xA;&#x9;  dvb_usbv2_adapter_init()&#xA;&#x9;    dvb_usbv2_adapter_frontend_init()&#xA;&#x9;      props-&gt;frontend_attach()&#xA;&#x9;  props-&gt;init()&#xA;Since mxl111sf_* devices call mxl111sf_ctrl_msg() in -&gt;frontend_attach()&#xA;internally we need to initialize state-&gt;msg_lock before&#xA;frontend_attach(). To achieve it, -&gt;probe() call added to all mxl111sf_*&#xA;devices, which will simply initiaize mutex.&#xA;CVE-2022-48743:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: amd-xgbe: Fix skb data length underflow&#xA;There will be BUG_ON() triggered in include/linux/skbuff.h leading to&#xA;intermittent kernel panic, when the skb length underflow is detected.&#xA;Fix this by dropping the packet if such length underflows are seen&#xA;because of inconsistencies in the hardware descriptors.&#xA;CVE-2024-35885:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxbf_gige: stop interface during shutdown&#xA;The mlxbf_gige driver intermittantly encounters a NULL pointer&#xA;exception while the system is shutting down via &#34;reboot&#34; command.&#xA;The mlxbf_driver will experience an exception right after executing&#xA;its shutdown() method.  One example of this exception is:&#xA;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070&#xA;Mem abort info:&#xA;  ESR = 0x0000000096000004&#xA;  EC = 0x25: DABT (current EL), IL = 32 bits&#xA;  SET = 0, FnV = 0&#xA;  EA = 0, S1PTW = 0&#xA;  FSC = 0x04: level 0 translation fault&#xA;Data abort info:&#xA;  ISV = 0, ISS = 0x00000004&#xA;  CM = 0, WnR = 0&#xA;user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000&#xA;[0000000000000070] pgd=0000000000000000, p4d=0000000000000000&#xA;Internal error: Oops: 96000004 [#1] SMP&#xA;CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S         OE     5.15.0-bf.6.gef6992a #1&#xA;Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023&#xA;pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]&#xA;lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]&#xA;sp : ffff8000080d3c10&#xA;x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58&#xA;x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008&#xA;x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128&#xA;x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff&#xA;x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7&#xA;x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101&#xA;x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404&#xA;x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080&#xA;x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001&#xA;x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000&#xA;Call trace:&#xA; mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]&#xA; mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]&#xA; __napi_poll+0x40/0x1c8&#xA; net_rx_action+0x314/0x3a0&#xA; __do_softirq+0x128/0x334&#xA; run_ksoftirqd+0x54/0x6c&#xA; smpboot_thread_fn+0x14c/0x190&#xA; kthread+0x10c/0x110&#xA; ret_from_fork+0x10/0x20&#xA;Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)&#xA;---[ end trace 7cc3941aa0d8e6a4 ]---&#xA;Kernel panic - not syncing: Oops: Fatal exception in interrupt&#xA;Kernel Offset: 0x4ce722520000 from 0xffff800008000000&#xA;PHYS_OFFSET: 0x80000000&#xA;CPU features: 0x000005c1,a3330e5a&#xA;Memory Limit: none&#xA;---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---&#xA;During system shutdown, the mlxbf_gige driver&#39;s shutdown() is always executed.&#xA;However, the driver&#39;s stop() method will only execute if networking interface&#xA;configuration logic within the Linux distribution has been setup to do so.&#xA;If shutdown() executes but stop() does not execute, NAPI remains enabled&#xA;and this can lead to an exception if NAPI is scheduled while the hardware&#xA;interface has only been partially deinitialized.&#xA;The networking interface managed by the mlxbf_gige driver must be properly&#xA;stopped during system shutdown so that IFF_UP is cleared, the hardware&#xA;interface is put into a clean state, and NAPI is fully deinitialized.&#xA;CVE-2024-35912:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: rfi: fix potential response leaks&#xA;If the rx payload length check fails, or if kmemdup() fails,&#xA;we still need to free the command response. Fix that.&#xA;CVE-2024-35911:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: fix memory corruption bug with suspend and rebuild&#xA;The ice driver would previously panic after suspend. This is caused&#xA;from the driver *only* calling the ice_vsi_free_q_vectors() function by&#xA;itself, when it is suspending. Since commit b3e7b3a6ee92 (&#34;ice: prevent&#xA;NULL pointer deref during reload&#34;) the driver has zeroed out&#xA;num_q_vectors, and only restored it in ice_vsi_cfg_def().&#xA;This further causes the ice_rebuild() function to allocate a zero length&#xA;buffer, after which num_q_vectors is updated, and then the new value of&#xA;num_q_vectors is used to index into the zero length buffer, which&#xA;corrupts memory.&#xA;The fix entails making sure all the code referencing num_q_vectors only&#xA;does so after it has been reset via ice_vsi_cfg_def().&#xA;I didn&#39;t perform a full bisect, but I was able to test against 6.1.77&#xA;kernel and that ice driver works fine for suspend/resume with no panic,&#xA;so sometime since then, this problem was introduced.&#xA;Also clean up an un-needed init of a local variable in the function&#xA;being modified.&#xA;PANIC from 6.8.0-rc1:&#xA;[1026674.915596] PM: suspend exit&#xA;[1026675.664697] ice 0000:17:00.1: PTP reset successful&#xA;[1026675.664707] ice 0000:17:00.1: 2755 msecs passed between update to cached PHC time&#xA;[1026675.667660] ice 0000:b1:00.0: PTP reset successful&#xA;[1026675.675944] ice 0000:b1:00.0: 2832 msecs passed between update to cached PHC time&#xA;[1026677.137733] ixgbe 0000:31:00.0 ens787: NIC Link is Up 1 Gbps, Flow Control: None&#xA;[1026677.190201] BUG: kernel NULL pointer dereference, address: 0000000000000010&#xA;[1026677.192753] ice 0000:17:00.0: PTP reset successful&#xA;[1026677.192764] ice 0000:17:00.0: 4548 msecs passed between update to cached PHC time&#xA;[1026677.197928] #PF: supervisor read access in kernel mode&#xA;[1026677.197933] #PF: error_code(0x0000) - not-present page&#xA;[1026677.197937] PGD 1557a7067 P4D 0&#xA;[1026677.212133] ice 0000:b1:00.1: PTP reset successful&#xA;[1026677.212143] ice 0000:b1:00.1: 4344 msecs passed between update to cached PHC time&#xA;[1026677.212575]&#xA;[1026677.243142] Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;[1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: loaded Tainted: G        W          6.8.0-rc1+ #1&#xA;[1026677.257989] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022&#xA;[1026677.269367] Workqueue: ice ice_service_task [ice]&#xA;[1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]&#xA;[1026677.281421] Code: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff ff 48 8b 43 30 49 63 ed &lt;41&gt; 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6&#xA;[1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 00010202&#xA;[1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000&#xA;[1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828&#xA;[1026677.321730] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;[1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010&#xA;[1026677.336896] R13: 0000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0&#xA;[1026677.344472] FS:  0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000&#xA;[1026677.353000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0&#xA;[1026677.366779] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[1026677.381952] PKRU: 55555554&#xA;[1026677.385116] Call Trace:&#xA;[1026677.388023]  &lt;TASK&gt;&#xA;[1026677.390589]  ? __die+0x20/0x70&#xA;[1026677.394105]  ? page_fault_oops+0x82/0x160&#xA;[1026677.398576]  ? do_user_addr_fault+0x65/0x6a0&#xA;[1026677.403307]  ? exc_page_fault+0x6a/0x150&#xA;[1026677.407694]  ? asm_exc_page_fault+0x22/0x30&#xA;[1026677.412349]  ? ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]&#xA;[1026677.4186&#xA;---truncated---&#xA;CVE-2024-35907:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxbf_gige: call request_irq() after NAPI initialized&#xA;The mlxbf_gige driver encounters a NULL pointer exception in&#xA;mlxbf_gige_open() when kdump is enabled.  The sequence to reproduce&#xA;the exception is as follows:&#xA;a) enable kdump&#xA;b) trigger kdump via &#34;echo c &gt; /proc/sysrq-trigger&#34;&#xA;c) kdump kernel executes&#xA;d) kdump kernel loads mlxbf_gige module&#xA;e) the mlxbf_gige module runs its open() as the&#xA;   the &#34;oob_net0&#34; interface is brought up&#xA;f) mlxbf_gige module will experience an exception&#xA;   during its open(), something like:&#xA;     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000&#xA;     Mem abort info:&#xA;       ESR = 0x0000000086000004&#xA;       EC = 0x21: IABT (current EL), IL = 32 bits&#xA;       SET = 0, FnV = 0&#xA;       EA = 0, S1PTW = 0&#xA;       FSC = 0x04: level 0 translation fault&#xA;     user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000&#xA;     [0000000000000000] pgd=0000000000000000, p4d=0000000000000000&#xA;     Internal error: Oops: 0000000086000004 [#1] SMP&#xA;     CPU: 0 PID: 812 Comm: NetworkManager Tainted: G           OE     5.15.0-1035-bluefield #37-Ubuntu&#xA;     Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024&#xA;     pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;     pc : 0x0&#xA;     lr : __napi_poll+0x40/0x230&#xA;     sp : ffff800008003e00&#xA;     x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff&#xA;     x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8&#xA;     x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000&#xA;     x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000&#xA;     x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0&#xA;     x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c&#xA;     x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398&#xA;     x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2&#xA;     x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100&#xA;     x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238&#xA;     Call trace:&#xA;      0x0&#xA;      net_rx_action+0x178/0x360&#xA;      __do_softirq+0x15c/0x428&#xA;      __irq_exit_rcu+0xac/0xec&#xA;      irq_exit+0x18/0x2c&#xA;      handle_domain_irq+0x6c/0xa0&#xA;      gic_handle_irq+0xec/0x1b0&#xA;      call_on_irq_stack+0x20/0x2c&#xA;      do_interrupt_handler+0x5c/0x70&#xA;      el1_interrupt+0x30/0x50&#xA;      el1h_64_irq_handler+0x18/0x2c&#xA;      el1h_64_irq+0x7c/0x80&#xA;      __setup_irq+0x4c0/0x950&#xA;      request_threaded_irq+0xf4/0x1bc&#xA;      mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]&#xA;      mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]&#xA;      __dev_open+0x100/0x220&#xA;      __dev_change_flags+0x16c/0x1f0&#xA;      dev_change_flags+0x2c/0x70&#xA;      do_setlink+0x220/0xa40&#xA;      __rtnl_newlink+0x56c/0x8a0&#xA;      rtnl_newlink+0x58/0x84&#xA;      rtnetlink_rcv_msg+0x138/0x3c4&#xA;      netlink_rcv_skb+0x64/0x130&#xA;      rtnetlink_rcv+0x20/0x30&#xA;      netlink_unicast+0x2ec/0x360&#xA;      netlink_sendmsg+0x278/0x490&#xA;      __sock_sendmsg+0x5c/0x6c&#xA;      ____sys_sendmsg+0x290/0x2d4&#xA;      ___sys_sendmsg+0x84/0xd0&#xA;      __sys_sendmsg+0x70/0xd0&#xA;      __arm64_sys_sendmsg+0x2c/0x40&#xA;      invoke_syscall+0x78/0x100&#xA;      el0_svc_common.constprop.0+0x54/0x184&#xA;      do_el0_svc+0x30/0xac&#xA;      el0_svc+0x48/0x160&#xA;      el0t_64_sync_handler+0xa4/0x12c&#xA;      el0t_64_sync+0x1a4/0x1a8&#xA;     Code: bad PC value&#xA;     ---[ end trace 7d1c3f3bf9d81885 ]---&#xA;     Kernel panic - not syncing: Oops: Fatal exception in interrupt&#xA;     Kernel Offset: 0x2870a7a00000 from 0xffff800008000000&#xA;     PHYS_OFFSET: 0x80000000&#xA;     CPU features: 0x0,000005c1,a3332a5a&#xA;     Memory Limit: none&#xA;     ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---&#xA;The exception happens because there is a pending RX interrupt before the&#xA;call to request_irq(RX IRQ) executes.  Then, the RX IRQ handler fires&#xA;immediately after this request_irq() completes. The&#xA;---truncated---&#xA;CVE-2024-35920:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: mediatek: vcodec: adding lock to protect decoder context list&#xA;Add a lock for the ctx_list, to avoid accessing a NULL pointer&#xA;within the &#39;vpu_dec_ipi_handler&#39; function when the ctx_list has&#xA;been deleted due to an unexpected behavior on the SCP IP block.&#xA;Hardware name: Google juniper sku16 board (DT)&#xA;pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)&#xA;pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec]&#xA;lr : scp_ipi_handler+0xd0/0x194 [mtk_scp]&#xA;sp : ffffffc0131dbbd0&#xA;x29: ffffffc0131dbbd0 x28: 0000000000000000&#xA;x27: ffffff9bb277f348 x26: ffffff9bb242ad00&#xA;x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4&#xA;x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0&#xA;x21: 0000000000000010 x20: ffffff9b050ea328&#xA;x19: ffffffc0131dbc08 x18: 0000000000001000&#xA;x17: 0000000000000000 x16: ffffffd2d461c6e0&#xA;x15: 0000000000000242 x14: 000000000000018f&#xA;x13: 000000000000004d x12: 0000000000000000&#xA;x11: 0000000000000001 x10: fffffffffffffff0&#xA;x9 : ffffff9bb6e793a8 x8 : 0000000000000000&#xA;x7 : 0000000000000000 x6 : 000000000000003f&#xA;x5 : 0000000000000040 x4 : fffffffffffffff0&#xA;x3 : 0000000000000020 x2 : ffffff9bb6e79080&#xA;x1 : 0000000000000010 x0 : ffffffc0131dbc08&#xA;Call trace:&#xA;vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)]&#xA;scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)]&#xA;mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)]&#xA;scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)]&#xA;irq_thread_fn+0x38/0x94&#xA;irq_thread+0x100/0x1c0&#xA;kthread+0x140/0x1fc&#xA;ret_from_fork+0x10/0x30&#xA;Code: 54000088 f94ca50a eb14015f 54000060 (f9400108)&#xA;---[ end trace ace43ce36cbd5c93 ]---&#xA;Kernel panic - not syncing: Oops: Fatal exception&#xA;SMP: stopping secondary CPUs&#xA;Kernel Offset: 0x12c4000000 from 0xffffffc010000000&#xA;PHYS_OFFSET: 0xffffffe580000000&#xA;CPU features: 0x08240002,2188200c&#xA;Memory Limit: none&#xA;CVE-2024-35959:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: Fix mlx5e_priv_init() cleanup flow&#xA;When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which&#xA;calls mlx5e_selq_apply() that assures that the `priv-&gt;state_lock` is held using&#xA;lockdep_is_held().&#xA;Acquire the state_lock in mlx5e_selq_cleanup().&#xA;Kernel log: =============================&#xA;WARNING: suspicious RCU usage&#xA;6.8.0-rc3_net_next_841a9b5 #1 Not tainted&#xA;-----------------------------&#xA;drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!&#xA;other info that might help us debug this:&#xA;rcu_scheduler_active = 2, debug_locks = 1&#xA;2 locks held by systemd-modules/293:&#xA; #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]&#xA; #1: ffff8881096c65c0 (&amp;device-&gt;client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]&#xA;stack backtrace:&#xA;CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x8a/0xa0&#xA; lockdep_rcu_suspicious+0x154/0x1a0&#xA; mlx5e_selq_apply+0x94/0xa0 [mlx5_core]&#xA; mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core]&#xA; mlx5e_priv_init+0x2be/0x2f0 [mlx5_core]&#xA; mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core]&#xA; rdma_init_netdev+0x4e/0x80 [ib_core]&#xA; ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core]&#xA; ipoib_intf_init+0x64/0x550 [ib_ipoib]&#xA; ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib]&#xA; ipoib_add_one+0xb0/0x360 [ib_ipoib]&#xA; add_client_context+0x112/0x1c0 [ib_core]&#xA; ib_register_client+0x166/0x1b0 [ib_core]&#xA; ? 0xffffffffa0573000&#xA; ipoib_init_module+0xeb/0x1a0 [ib_ipoib]&#xA; do_one_initcall+0x61/0x250&#xA; do_init_module+0x8a/0x270&#xA; init_module_from_file+0x8b/0xd0&#xA; idempotent_init_module+0x17d/0x230&#xA; __x64_sys_finit_module+0x61/0xb0&#xA; do_syscall_64+0x71/0x140&#xA; entry_SYSCALL_64_after_hwframe+0x46/0x4e&#xA; &lt;/TASK&gt;&#xA;CVE-2024-35952:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/ast: Fix soft lockup&#xA;There is a while-loop in ast_dp_set_on_off() that could lead to&#xA;infinite-loop. This is because the register, VGACRI-Dx, checked in&#xA;this API is a scratch register actually controlled by a MCU, named&#xA;DPMCU, in BMC.&#xA;These scratch registers are protected by scu-lock. If suc-lock is not&#xA;off, DPMCU can not update these registers and then host will have soft&#xA;lockup due to never updated status.&#xA;DPMCU is used to control DP and relative registers to handshake with&#xA;host&#39;s VGA driver. Even the most time-consuming task, DP&#39;s link&#xA;training, is less than 100ms. 200ms should be enough.&#xA;CVE-2021-47299:In the Linux kernel, the following vulnerability has been resolved:&#xA;xdp, net: Fix use-after-free in bpf_xdp_link_release&#xA;The problem occurs between dev_get_by_index() and dev_xdp_attach_link().&#xA;At this point, dev_xdp_uninstall() is called. Then xdp link will not be&#xA;detached automatically when dev is released. But link-&gt;dev already&#xA;points to dev, when xdp link is released, dev will still be accessed,&#xA;but dev has been released.&#xA;dev_get_by_index()        |&#xA;link-&gt;dev = dev           |&#xA;                          |      rtnl_lock()&#xA;                          |      unregister_netdevice_many()&#xA;                          |          dev_xdp_uninstall()&#xA;                          |      rtnl_unlock()&#xA;rtnl_lock();              |&#xA;dev_xdp_attach_link()     |&#xA;rtnl_unlock();            |&#xA;                          |      netdev_run_todo() // dev released&#xA;bpf_xdp_link_release()    |&#xA;    /* access dev.        |&#xA;       use-after-free */  |&#xA;[   45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0&#xA;[   45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732&#xA;[   45.968297]&#xA;[   45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22&#xA;[   45.969222] Hardware name: linux,dummy-virt (DT)&#xA;[   45.969795] Call trace:&#xA;[   45.970106]  dump_backtrace+0x0/0x4c8&#xA;[   45.970564]  show_stack+0x30/0x40&#xA;[   45.970981]  dump_stack_lvl+0x120/0x18c&#xA;[   45.971470]  print_address_description.constprop.0+0x74/0x30c&#xA;[   45.972182]  kasan_report+0x1e8/0x200&#xA;[   45.972659]  __asan_report_load8_noabort+0x2c/0x50&#xA;[   45.973273]  bpf_xdp_link_release+0x3b8/0x3d0&#xA;[   45.973834]  bpf_link_free+0xd0/0x188&#xA;[   45.974315]  bpf_link_put+0x1d0/0x218&#xA;[   45.974790]  bpf_link_release+0x3c/0x58&#xA;[   45.975291]  __fput+0x20c/0x7e8&#xA;[   45.975706]  ____fput+0x24/0x30&#xA;[   45.976117]  task_work_run+0x104/0x258&#xA;[   45.976609]  do_notify_resume+0x894/0xaf8&#xA;[   45.977121]  work_pending+0xc/0x328&#xA;[   45.977575]&#xA;[   45.977775] The buggy address belongs to the page:&#xA;[   45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998&#xA;[   45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)&#xA;[   45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000&#xA;[   45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000&#xA;[   45.982259] page dumped because: kasan: bad access detected&#xA;[   45.982948]&#xA;[   45.983153] Memory state around the buggy address:&#xA;[   45.983753]  ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;[   45.984645]  ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;[   45.985533] &gt;ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;[   45.986419]                                               ^&#xA;[   45.987112]  ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;[   45.988006]  ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;[   45.988895] ==================================================================&#xA;[   45.989773] Disabling lock debugging due to kernel taint&#xA;[   45.990552] Kernel panic - not syncing: panic_on_warn set ...&#xA;[   45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G    B             5.13.0+ #22&#xA;[   45.991929] Hardware name: linux,dummy-virt (DT)&#xA;[   45.992448] Call trace:&#xA;[   45.992753]  dump_backtrace+0x0/0x4c8&#xA;[   45.993208]  show_stack+0x30/0x40&#xA;[   45.993627]  dump_stack_lvl+0x120/0x18c&#xA;[   45.994113]  dump_stack+0x1c/0x34&#xA;[   45.994530]  panic+0x3a4/0x7d8&#xA;[   45.994930]  end_report+0x194/0x198&#xA;[   45.995380]  kasan_report+0x134/0x200&#xA;[   45.995850]  __asan_report_load8_noabort+0x2c/0x50&#xA;[   45.996453]  bpf_xdp_link_release+0x3b8/0x3d0&#xA;[   45.997007]  bpf_link_free+0xd0/0x188&#xA;[   45.997474]  bpf_link_put+0x1d0/0x218&#xA;[   45.997942]  bpf_link_release+0x3c/0x58&#xA;[   45.998429]  __fput+0x20c/0x7e8&#xA;[   45.998833]  ____fput+0x24/0x30&#xA;[   45.999247]  task_work_run+0x104/0x258&#xA;[   45.999731]  do_notify_resume+0x894/0xaf8&#xA;[   46.000236]  work_pending&#xA;---truncated---&#xA;CVE-2021-47304:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized&#xA;This commit fixes a bug (found by syzkaller) that could cause spurious&#xA;double-initializations for congestion control modules, which could cause&#xA;memory leaks or other problems for congestion control modules (like CDG)&#xA;that allocate memory in their init functions.&#xA;The buggy scenario constructed by syzkaller was something like:&#xA;(1) create a TCP socket&#xA;(2) initiate a TFO connect via sendto()&#xA;(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),&#xA;    which calls:&#xA;       tcp_set_congestion_control() -&gt;&#xA;         tcp_reinit_congestion_control() -&gt;&#xA;           tcp_init_congestion_control()&#xA;(4) receive ACK, connection is established, call tcp_init_transfer(),&#xA;    set icsk_ca_initialized=0 (without first calling cc-&gt;release()),&#xA;    call tcp_init_congestion_control() again.&#xA;Note that in this sequence tcp_init_congestion_control() is called&#xA;twice without a cc-&gt;release() call in between. Thus, for CC modules&#xA;that allocate memory in their init() function, e.g, CDG, a memory leak&#xA;may occur. The syzkaller tool managed to find a reproducer that&#xA;triggered such a leak in CDG.&#xA;The bug was introduced when that commit 8919a9b31eb4 (&#34;tcp: Only init&#xA;congestion control if not initialized already&#34;)&#xA;introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in&#xA;tcp_init_transfer(), missing the possibility for a sequence like the&#xA;one above, where a process could call setsockopt(TCP_CONGESTION) in&#xA;state TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()),&#xA;which would call tcp_init_congestion_control(). It did not intend to&#xA;reset any initialization that the user had already explicitly made;&#xA;it just missed the possibility of that particular sequence (which&#xA;syzkaller managed to find).&#xA;CVE-2021-47364:In the Linux kernel, the following vulnerability has been resolved:&#xA;comedi: Fix memory leak in compat_insnlist()&#xA;`compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST`&#xA;ioctl (whenwhen `CONFIG_COMPAT` is enabled).  It allocates memory to&#xA;temporarily hold an array of `struct comedi_insn` converted from the&#xA;32-bit version in user space.  This memory is only being freed if there&#xA;is a fault while filling the array, otherwise it is leaked.&#xA;Add a call to `kfree()` to fix the leak.&#xA;CVE-2021-47464:In the Linux kernel, the following vulnerability has been resolved:&#xA;audit: fix possible null-pointer dereference in audit_filter_rules&#xA;Fix  possible null-pointer dereference in audit_filter_rules.&#xA;audit_filter_rules() error: we previously assumed &#39;ctx&#39; could be null&#xA;CVE-2021-47517:In the Linux kernel, the following vulnerability has been resolved:&#xA;ethtool: do not perform operations on net devices being unregistered&#xA;There is a short period between a net device starts to be unregistered&#xA;and when it is actually gone. In that time frame ethtool operations&#xA;could still be performed, which might end up in unwanted or undefined&#xA;behaviours[1].&#xA;Do not allow ethtool operations after a net device starts its&#xA;unregistration. This patch targets the netlink part as the ioctl one&#xA;isn&#39;t affected: the reference to the net device is taken and the&#xA;operation is executed within an rtnl lock section and the net device&#xA;won&#39;t be found after unregister.&#xA;[1] For example adding Tx queues after unregister ends up in NULL&#xA;    pointer exceptions and UaFs, such as:&#xA;      BUG: KASAN: use-after-free in kobject_get+0x14/0x90&#xA;      Read of size 1 at addr ffff88801961248c by task ethtool/755&#xA;      CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778&#xA;      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014&#xA;      Call Trace:&#xA;       dump_stack_lvl+0x57/0x72&#xA;       print_address_description.constprop.0+0x1f/0x140&#xA;       kasan_report.cold+0x7f/0x11b&#xA;       kobject_get+0x14/0x90&#xA;       kobject_add_internal+0x3d1/0x450&#xA;       kobject_init_and_add+0xba/0xf0&#xA;       netdev_queue_update_kobjects+0xcf/0x200&#xA;       netif_set_real_num_tx_queues+0xb4/0x310&#xA;       veth_set_channels+0x1c3/0x550&#xA;       ethnl_set_channels+0x524/0x610&#xA;CVE-2021-47519:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: m_can: m_can_read_fifo: fix memory leak in error branch&#xA;In m_can_read_fifo(), if the second call to m_can_fifo_read() fails,&#xA;the function jump to the out_fail label and returns without calling&#xA;m_can_receive_skb(). This means that the skb previously allocated by&#xA;alloc_can_skb() is not freed. In other terms, this is a memory leak.&#xA;This patch adds a goto label to destroy the skb if an error occurs.&#xA;Issue was found with GCC -fanalyzer, please follow the link below for&#xA;details.&#xA;CVE-2021-47570:In the Linux kernel, the following vulnerability has been resolved:&#xA;staging: r8188eu: fix a memory leak in rtw_wx_read32()&#xA;Free &#34;ptmp&#34; before returning -EINVAL.&#xA;CVE-2021-47536:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/smc: fix wrong list_del in smc_lgr_cleanup_early&#xA;smc_lgr_cleanup_early() meant to delete the link&#xA;group from the link group list, but it deleted&#xA;the list head by mistake.&#xA;This may cause memory corruption since we didn&#39;t&#xA;remove the real link group from the list and later&#xA;memseted the link group structure.&#xA;We got a list corruption panic when testing:&#xA;[  231.277259] list_del corruption. prev-&gt;next should be ffff8881398a8000, but was 0000000000000000&#xA;[  231.278222] ------------[ cut here ]------------&#xA;[  231.278726] kernel BUG at lib/list_debug.c:53!&#xA;[  231.279326] invalid opcode: 0000 [#1] SMP NOPTI&#xA;[  231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435&#xA;[  231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014&#xA;[  231.281248] Workqueue: events smc_link_down_work&#xA;[  231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90&#xA;[  231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c&#xA;60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 &lt;0f&gt;&#xA;0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc&#xA;[  231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292&#xA;[  231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000&#xA;[  231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040&#xA;[  231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001&#xA;[  231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001&#xA;[  231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003&#xA;[  231.288337] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000&#xA;[  231.289160] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0&#xA;[  231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  231.291940] Call Trace:&#xA;[  231.292211]  smc_lgr_terminate_sched+0x53/0xa0&#xA;[  231.292677]  smc_switch_conns+0x75/0x6b0&#xA;[  231.293085]  ? update_load_avg+0x1a6/0x590&#xA;[  231.293517]  ? ttwu_do_wakeup+0x17/0x150&#xA;[  231.293907]  ? update_load_avg+0x1a6/0x590&#xA;[  231.294317]  ? newidle_balance+0xca/0x3d0&#xA;[  231.294716]  smcr_link_down+0x50/0x1a0&#xA;[  231.295090]  ? __wake_up_common_lock+0x77/0x90&#xA;[  231.295534]  smc_link_down_work+0x46/0x60&#xA;[  231.295933]  process_one_work+0x18b/0x350&#xA;CVE-2024-36026:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11&#xA;While doing multiple S4 stress tests, GC/RLC/PMFW get into&#xA;an invalid state resulting into hard hangs.&#xA;Adding a GFX reset as workaround just before sending the&#xA;MP1_UNLOAD message avoids this failure.&#xA;CVE-2024-36882:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm: use memalloc_nofs_save() in page_cache_ra_order()&#xA;See commit f2c817bed58d (&#34;mm: use memalloc_nofs_save in readahead path&#34;),&#xA;ensure that page_cache_ra_order() do not attempt to reclaim file-backed&#xA;pages too, or it leads to a deadlock, found issue when test ext4 large&#xA;folio.&#xA; INFO: task DataXceiver for:7494 blocked for more than 120 seconds.&#xA; &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA; task:DataXceiver for state:D stack:0     pid:7494  ppid:1      flags:0x00000200&#xA; Call trace:&#xA;  __switch_to+0x14c/0x240&#xA;  __schedule+0x82c/0xdd0&#xA;  schedule+0x58/0xf0&#xA;  io_schedule+0x24/0xa0&#xA;  __folio_lock+0x130/0x300&#xA;  migrate_pages_batch+0x378/0x918&#xA;  migrate_pages+0x350/0x700&#xA;  compact_zone+0x63c/0xb38&#xA;  compact_zone_order+0xc0/0x118&#xA;  try_to_compact_pages+0xb0/0x280&#xA;  __alloc_pages_direct_compact+0x98/0x248&#xA;  __alloc_pages+0x510/0x1110&#xA;  alloc_pages+0x9c/0x130&#xA;  folio_alloc+0x20/0x78&#xA;  filemap_alloc_folio+0x8c/0x1b0&#xA;  page_cache_ra_order+0x174/0x308&#xA;  ondemand_readahead+0x1c8/0x2b8&#xA;  page_cache_async_ra+0x68/0xb8&#xA;  filemap_readahead.isra.0+0x64/0xa8&#xA;  filemap_get_pages+0x3fc/0x5b0&#xA;  filemap_splice_read+0xf4/0x280&#xA;  ext4_file_splice_read+0x2c/0x48 [ext4]&#xA;  vfs_splice_read.part.0+0xa8/0x118&#xA;  splice_direct_to_actor+0xbc/0x288&#xA;  do_splice_direct+0x9c/0x108&#xA;  do_sendfile+0x328/0x468&#xA;  __arm64_sys_sendfile64+0x8c/0x148&#xA;  invoke_syscall+0x4c/0x118&#xA;  el0_svc_common.constprop.0+0xc8/0xf0&#xA;  do_el0_svc+0x24/0x38&#xA;  el0_svc+0x4c/0x1f8&#xA;  el0t_64_sync_handler+0xc0/0xc8&#xA;  el0t_64_sync+0x188/0x190&#xA;CVE-2024-36022:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Init zone device and drm client after mode-1 reset on reload&#xA;In passthrough environment, when amdgpu is reloaded after unload, mode-1&#xA;is triggered after initializing the necessary IPs, That init does not&#xA;include KFD, and KFD init waits until the reset is completed. KFD init&#xA;is called in the reset handler, but in this case, the zone device and&#xA;drm client is not initialized, causing app to create kernel panic.&#xA;v2: Removing the init KFD condition from amdgpu_amdkfd_drm_client_create.&#xA;As the previous version has the potential of creating DRM client twice.&#xA;v3: v2 patch results in SDMA engine hung as DRM open causes VM clear to SDMA&#xA;before SDMA init. Adding the condition to in drm client creation, on top of v1,&#xA;to guard against drm client creation call multiple times.&#xA;CVE-2024-36033:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: qca: fix info leak when fetching board id&#xA;Add the missing sanity check when fetching the board id to avoid leaking&#xA;slab data when later requesting the firmware.&#xA;CVE-2024-36892:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/slub: avoid zeroing outside-object freepointer for single free&#xA;Commit 284f17ac13fe (&#34;mm/slub: handle bulk and single object freeing&#xA;separately&#34;) splits single and bulk object freeing in two functions&#xA;slab_free() and slab_free_bulk() which leads slab_free() to call&#xA;slab_free_hook() directly instead of slab_free_freelist_hook().&#xA;If `init_on_free` is set, slab_free_hook() zeroes the object.&#xA;Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are&#xA;set, the do_slab_free() slowpath executes freelist consistency&#xA;checks and try to decode a zeroed freepointer which leads to a&#xA;&#34;Freepointer corrupt&#34; detection in check_object().&#xA;During bulk free, slab_free_freelist_hook() isn&#39;t affected as it always&#xA;sets it objects freepointer using set_freepointer() to maintain its&#xA;reconstructed freelist after `init_on_free`.&#xA;For single free, object&#39;s freepointer thus needs to be avoided when&#xA;stored outside the object if `init_on_free` is set. The freepointer left&#xA;as is, check_object() may later detect an invalid pointer value due to&#xA;objects overflow.&#xA;To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the&#xA;command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.&#xA;dmesg sample log:&#xA;[   10.708715] =============================================================================&#xA;[   10.710323] BUG kmalloc-rnd-05-32 (Tainted: G    B           T ): Freepointer corrupt&#xA;[   10.712695] -----------------------------------------------------------------------------&#xA;[   10.712695]&#xA;[   10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)&#xA;[   10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c&#xA;[   10.716698]&#xA;[   10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;[   10.720703] Object   ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;[   10.720703] Object   ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;[   10.724696] Padding  ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;[   10.724696] Padding  ffff9d9a8035667c: 00 00 00 00                                      ....&#xA;[   10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed&#xA;CVE-2024-36943:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan&#xA;make_uffd_wp_pte() was previously doing:&#xA;  pte = ptep_get(ptep);&#xA;  ptep_modify_prot_start(ptep);&#xA;  pte = pte_mkuffd_wp(pte);&#xA;  ptep_modify_prot_commit(ptep, pte);&#xA;But if another thread accessed or dirtied the pte between the first 2&#xA;calls, this could lead to loss of that information.  Since&#xA;ptep_modify_prot_start() gets and clears atomically, the following is the&#xA;correct pattern and prevents any possible race.  Any access after the&#xA;first call would see an invalid pte and cause a fault:&#xA;  pte = ptep_modify_prot_start(ptep);&#xA;  pte = pte_mkuffd_wp(pte);&#xA;  ptep_modify_prot_commit(ptep, pte);&#xA;CVE-2024-36932:In the Linux kernel, the following vulnerability has been resolved:&#xA;thermal/debugfs: Prevent use-after-free from occurring after cdev removal&#xA;Since thermal_debug_cdev_remove() does not run under cdev-&gt;lock, it can&#xA;run in parallel with thermal_debug_cdev_state_update() and it may free&#xA;the struct thermal_debugfs object used by the latter after it has been&#xA;checked against NULL.&#xA;If that happens, thermal_debug_cdev_state_update() will access memory&#xA;that has been freed already causing the kernel to crash.&#xA;Address this by using cdev-&gt;lock in thermal_debug_cdev_remove() around&#xA;the cdev-&gt;debugfs value check (in case the same cdev is removed at the&#xA;same time in two different threads) and its reset to NULL.&#xA;Cc :6.8+ &lt;stable@vger.kernel.org&gt; # 6.8+&#xA;CVE-2021-4440:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/xen: Drop USERGS_SYSRET64 paravirt call&#xA;commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.&#xA;USERGS_SYSRET64 is used to return from a syscall via SYSRET, but&#xA;a Xen PV guest will nevertheless use the IRET hypercall, as there&#xA;is no sysret PV hypercall defined.&#xA;So instead of testing all the prerequisites for doing a sysret and&#xA;then mangling the stack for Xen PV again for doing an iret just use&#xA;the iret exit from the beginning.&#xA;This can easily be done via an ALTERNATIVE like it is done for the&#xA;sysenter compat case already.&#xA;It should be noted that this drops the optimization in Xen for not&#xA;restoring a few registers when returning to user mode, but it seems&#xA;as if the saved instructions in the kernel more than compensate for&#xA;this drop (a kernel build in a Xen PV guest was slightly faster with&#xA;this patch applied).&#xA;While at it remove the stale sysret32 remnants.&#xA;  [ pawan: Brad Spengler and Salvatore Bonaccorso &lt;carnil@debian.org&gt;&#xA;&#x9;   reported a problem with the 5.10 backport commit edc702b4a820&#xA;&#x9;   (&#34;x86/entry_64: Add VERW just before userspace transition&#34;).&#xA;&#x9;   When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in&#xA;&#x9;   syscall_return_via_sysret path as USERGS_SYSRET64 is runtime&#xA;&#x9;   patched to:&#xA;&#x9;.cpu_usergs_sysret64    = { 0x0f, 0x01, 0xf8,&#xA;&#x9;&#x9;&#x9;&#x9;    0x48, 0x0f, 0x07 }, // swapgs; sysretq&#xA;&#x9;   which is missing CLEAR_CPU_BUFFERS. It turns out dropping&#xA;&#x9;   USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS&#xA;&#x9;   to be explicitly added to syscall_return_via_sysret path. Below&#xA;&#x9;   is with CONFIG_PARAVIRT_XXL=y and this patch applied:&#xA;&#x9;   syscall_return_via_sysret:&#xA;&#x9;   ...&#xA;&#x9;   &lt;+342&gt;:   swapgs&#xA;&#x9;   &lt;+345&gt;:   xchg   %ax,%ax&#xA;&#x9;   &lt;+347&gt;:   verw   -0x1a2(%rip)  &lt;------&#xA;&#x9;   &lt;+354&gt;:   sysretq&#xA;  ]&#xA;CVE-2022-48738:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()&#xA;We don&#39;t currently validate that the values being set are within the range&#xA;we advertised to userspace as being valid, do so and reject any values&#xA;that are out of range.&#xA;CVE-2021-47351:In the Linux kernel, the following vulnerability has been resolved:&#xA;ubifs: Fix races between xattr_{set|get} and listxattr operations&#xA;UBIFS may occur some problems with concurrent xattr_{set|get} and&#xA;listxattr operations, such as assertion failure, memory corruption,&#xA;stale xattr value[1].&#xA;Fix it by importing a new rw-lock in @ubifs_inode to serilize write&#xA;operations on xattr, concurrent read operations are still effective,&#xA;just like ext4.&#xA;[1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com&#xA;CVE-2024-36030:In the Linux kernel, the following vulnerability has been resolved:&#xA;octeontx2-af: fix the double free in rvu_npc_freemem()&#xA;Clang static checker(scan-build) warning：&#xA;drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2&#xA;Attempt to free released memory.&#xA;npc_mcam_rsrcs_deinit() has released &#39;mcam-&gt;counters.bmap&#39;. Deleted this&#xA;redundant kfree() to fix this double free problem.&#xA;CVE-2021-47430:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n&#xA;Commit&#xA;  3c73b81a9164 (&#34;x86/entry, selftests: Further improve user entry sanity checks&#34;)&#xA;added a warning if AC is set when in the kernel.&#xA;Commit&#xA;  662a0221893a3d (&#34;x86/entry: Fix AC assertion&#34;)&#xA;changed the warning to only fire if the CPU supports SMAP.&#xA;However, the warning can still trigger on a machine that supports SMAP&#xA;but where it&#39;s disabled in the kernel config and when running the&#xA;syscall_nt selftest, for example:&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode&#xA;  CPU: 0 PID: 49 Comm: init Tainted: G                T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014&#xA;  RIP: 0010:irqentry_enter_from_user_mode&#xA;  ...&#xA;  Call Trace:&#xA;   ? irqentry_enter&#xA;   ? exc_general_protection&#xA;   ? asm_exc_general_protection&#xA;   ? asm_exc_general_protectio&#xA;IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but&#xA;even this would not be enough in case SMAP is disabled at boot time with&#xA;the &#34;nosmap&#34; parameter.&#xA;To be consistent with &#34;nosmap&#34; behaviour, clear X86_FEATURE_SMAP when&#xA;!CONFIG_X86_SMAP.&#xA;Found using entry-fuzz + satrandconfig.&#xA; [ bp: Massage commit message. ]&#xA;CVE-2024-38610:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()&#xA;Patch series &#34;mm: follow_pte() improvements and acrn follow_pte() fixes&#34;.&#xA;Patch #1 fixes a bunch of issues I spotted in the acrn driver.  It&#xA;compiles, that&#39;s all I know.  I&#39;ll appreciate some review and testing from&#xA;acrn folks.&#xA;Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding&#xA;more sanity checks, and improving the documentation.  Gave it a quick test&#xA;on x86-64 using VM_PAT that ends up using follow_pte().&#xA;This patch (of 3):&#xA;We currently miss handling various cases, resulting in a dangerous&#xA;follow_pte() (previously follow_pfn()) usage.&#xA;(1) We&#39;re not checking PTE write permissions.&#xA;Maybe we should simply always require pte_write() like we do for&#xA;pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let&#39;s check for&#xA;ACRN_MEM_ACCESS_WRITE for now.&#xA;(2) We&#39;re not rejecting refcounted pages.&#xA;As we are not using MMU notifiers, messing with refcounted pages is&#xA;dangerous and can result in use-after-free. Let&#39;s make sure to reject them.&#xA;(3) We are only looking at the first PTE of a bigger range.&#xA;We only lookup a single PTE, but memmap-&gt;len may span a larger area.&#xA;Let&#39;s loop over all involved PTEs and make sure the PFN range is&#xA;actually contiguous. Reject everything else: it couldn&#39;t have worked&#xA;either way, and rather made use access PFNs we shouldn&#39;t be accessing.&#xA;CVE-2021-47296:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak&#xA;vcpu_put is not called if the user copy fails. This can result in preempt&#xA;notifier corruption and crashes, among other issues.&#xA;CVE-2024-38580:In the Linux kernel, the following vulnerability has been resolved:&#xA;epoll: be better about file lifetimes&#xA;epoll can call out to vfs_poll() with a file pointer that may race with&#xA;the last &#39;fput()&#39;. That would make f_count go down to zero, and while&#xA;the ep-&gt;mtx locking means that the resulting file pointer tear-down will&#xA;be blocked until the poll returns, it means that f_count is already&#xA;dead, and any use of it won&#39;t actually get a reference to the file any&#xA;more: it&#39;s dead regardless.&#xA;Make sure we have a valid ref on the file pointer before we call down to&#xA;vfs_poll() from the epoll routines.&#xA;CVE-2022-48760:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: core: Fix hang in usb_kill_urb by adding memory barriers&#xA;The syzbot fuzzer has identified a bug in which processes hang waiting&#xA;for usb_kill_urb() to return.  It turns out the issue is not unlinking&#xA;the URB; that works just fine.  Rather, the problem arises when the&#xA;wakeup notification that the URB has completed is not received.&#xA;The reason is memory-access ordering on SMP systems.  In outline form,&#xA;usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on&#xA;different CPUs perform the following actions:&#xA;CPU 0&#x9;&#x9;&#x9;&#x9;&#x9;CPU 1&#xA;----------------------------&#x9;&#x9;---------------------------------&#xA;usb_kill_urb():&#x9;&#x9;&#x9;&#x9;__usb_hcd_giveback_urb():&#xA;  ...&#x9;&#x9;&#x9;&#x9;&#x9;  ...&#xA;  atomic_inc(&amp;urb-&gt;reject);&#x9;&#x9;  atomic_dec(&amp;urb-&gt;use_count);&#xA;  ...&#x9;&#x9;&#x9;&#x9;&#x9;  ...&#xA;  wait_event(usb_kill_urb_queue,&#xA;&#x9;atomic_read(&amp;urb-&gt;use_count) == 0);&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  if (atomic_read(&amp;urb-&gt;reject))&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;wake_up(&amp;usb_kill_urb_queue);&#xA;Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can&#xA;see that the overall pattern of accesses on CPU 0 is:&#xA;&#x9;write urb-&gt;reject, then read urb-&gt;use_count;&#xA;whereas the overall pattern of accesses on CPU 1 is:&#xA;&#x9;write urb-&gt;use_count, then read urb-&gt;reject.&#xA;This pattern is referred to in memory-model circles as SB (for &#34;Store&#xA;Buffering&#34;), and it is well known that without suitable enforcement of&#xA;the desired order of accesses -- in the form of memory barriers -- it&#xA;is entirely possible for one or both CPUs to execute their reads ahead&#xA;of their writes.  The end result will be that sometimes CPU 0 sees the&#xA;old un-decremented value of urb-&gt;use_count while CPU 1 sees the old&#xA;un-incremented value of urb-&gt;reject.  Consequently CPU 0 ends up on&#xA;the wait queue and never gets woken up, leading to the observed hang&#xA;in usb_kill_urb().&#xA;The same pattern of accesses occurs in usb_poison_urb() and the&#xA;failure pathway of usb_hcd_submit_urb().&#xA;The problem is fixed by adding suitable memory barriers.  To provide&#xA;proper memory-access ordering in the SB pattern, a full barrier is&#xA;required on both CPUs.  The atomic_inc() and atomic_dec() accesses&#xA;themselves don&#39;t provide any memory ordering, but since they are&#xA;present, we can use the optimized smp_mb__after_atomic() memory&#xA;barrier in the various routines to obtain the desired effect.&#xA;This patch adds the necessary memory barriers.&#xA;CVE-2024-36965:In the Linux kernel, the following vulnerability has been resolved:&#xA;remoteproc: mediatek: Make sure IPI buffer fits in L2TCM&#xA;The IPI buffer location is read from the firmware that we load to the&#xA;System Companion Processor, and it&#39;s not granted that both the SRAM&#xA;(L2TCM) size that is defined in the devicetree node is large enough&#xA;for that, and while this is especially true for multi-core SCP, it&#39;s&#xA;still useful to check on single-core variants as well.&#xA;Failing to perform this check may make this driver perform R/W&#xA;operations out of the L2TCM boundary, resulting (at best) in a&#xA;kernel panic.&#xA;To fix that, check that the IPI buffer fits, otherwise return a&#xA;failure and refuse to boot the relevant SCP core (or the SCP at&#xA;all, if this is single core).&#xA;CVE-2024-38629:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: idxd: Avoid unnecessary destruction of file_ida&#xA;file_ida is allocated during cdev open and is freed accordingly&#xA;during cdev release. This sequence is guaranteed by driver file&#xA;operations. Therefore, there is no need to destroy an already empty&#xA;file_ida when the WQ cdev is removed.&#xA;Worse, ida_free() in cdev release may happen after destruction of&#xA;file_ida per WQ cdev. This can lead to accessing an id in file_ida&#xA;after it has been destroyed, resulting in a kernel panic.&#xA;Remove ida_destroy(&amp;file_ida) to address these issues.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/kernel-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/kernel-headers-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/kernel-devel-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/kernel-tools-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/kernel-tools-devel-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/perf-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-perf-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bpftool-5.10.0-136.83.0.163.u126.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/kernel-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/kernel-headers-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/kernel-devel-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/kernel-tools-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/kernel-tools-devel-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/perf-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/python3-perf-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.83.0.163.u126.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bpftool-5.10.0-136.83.0.163.u126.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2238</id>
		<title>An update for krb5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37370" id="CVE-2024-37370" title="CVE-2024-37370" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37371" id="CVE-2024-37371" title="CVE-2024-37371" type="cve"></reference>
		</references>
		<description>CVE-2024-37370:In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.&#xA;CVE-2024-37371:In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="krb5" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-1.19.2-17.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/krb5-1.19.2-17.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-server" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-server-1.19.2-17.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/krb5-server-1.19.2-17.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-client" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-client-1.19.2-17.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/krb5-client-1.19.2-17.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-devel" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-devel-1.19.2-17.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/krb5-devel-1.19.2-17.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-libs" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-libs-1.19.2-17.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/krb5-libs-1.19.2-17.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="krb5-help" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-help-1.19.2-17.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/krb5-help-1.19.2-17.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-1.19.2-17.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/krb5-1.19.2-17.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-server" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-server-1.19.2-17.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/krb5-server-1.19.2-17.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-client" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-client-1.19.2-17.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/krb5-client-1.19.2-17.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-devel" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-devel-1.19.2-17.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/krb5-devel-1.19.2-17.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-libs" release="17.u6.fos23" version="1.19.2">
					<filename>krb5-libs-1.19.2-17.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/krb5-libs-1.19.2-17.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2239</id>
		<title>An update for libarchive is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20696" id="CVE-2024-20696" title="CVE-2024-20696" type="cve"></reference>
		</references>
		<description>CVE-2024-20696:Windows Libarchive Remote Code Execution Vulnerability</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="libarchive" release="7.u5.fos23" version="3.5.2">
					<filename>libarchive-3.5.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libarchive-3.5.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive-devel" release="7.u5.fos23" version="3.5.2">
					<filename>libarchive-devel-3.5.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libarchive-devel-3.5.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libarchive-help" release="7.u5.fos23" version="3.5.2">
					<filename>libarchive-help-3.5.2-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libarchive-help-3.5.2-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdtar" release="7.u5.fos23" version="3.5.2">
					<filename>bsdtar-3.5.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bsdtar-3.5.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcpio" release="7.u5.fos23" version="3.5.2">
					<filename>bsdcpio-3.5.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bsdcpio-3.5.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcat" release="7.u5.fos23" version="3.5.2">
					<filename>bsdcat-3.5.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/bsdcat-3.5.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive" release="7.u5.fos23" version="3.5.2">
					<filename>libarchive-3.5.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libarchive-3.5.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive-devel" release="7.u5.fos23" version="3.5.2">
					<filename>libarchive-devel-3.5.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libarchive-devel-3.5.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdtar" release="7.u5.fos23" version="3.5.2">
					<filename>bsdtar-3.5.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bsdtar-3.5.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcpio" release="7.u5.fos23" version="3.5.2">
					<filename>bsdcpio-3.5.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bsdcpio-3.5.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcat" release="7.u5.fos23" version="3.5.2">
					<filename>bsdcat-3.5.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/bsdcat-3.5.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2240</id>
		<title>An update for libndp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5564" id="CVE-2024-5564" title="CVE-2024-5564" type="cve"></reference>
		</references>
		<description>CVE-2024-5564:A vulnerability was found in libndp. This flaw allows a local malicious user to cause a buffer overflow in NetworkManager, triggered by sending a malformed IPv6 router advertisement packet. This issue occurred as libndp was not correctly validating the route length information.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="libndp" release="3.u1.fos23" version="1.8">
					<filename>libndp-1.8-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libndp-1.8-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libndp-devel" release="3.u1.fos23" version="1.8">
					<filename>libndp-devel-1.8-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libndp-devel-1.8-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libndp-help" release="3.u1.fos23" version="1.8">
					<filename>libndp-help-1.8-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libndp-help-1.8-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libndp" release="3.u1.fos23" version="1.8">
					<filename>libndp-1.8-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libndp-1.8-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libndp-devel" release="3.u1.fos23" version="1.8">
					<filename>libndp-devel-1.8-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libndp-devel-1.8-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libndp-help" release="3.u1.fos23" version="1.8">
					<filename>libndp-help-1.8-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libndp-help-1.8-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2241</id>
		<title>An update for libva is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39929" id="CVE-2023-39929" title="CVE-2023-39929" type="cve"></reference>
		</references>
		<description>CVE-2023-39929:Uncontrolled search path in some Libva software maintained by Intel(R) before version 2.20.0 may allow an authenticated user to potentially enable escalation of privilege via local access.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="libva" release="1.fos23" version="2.20.0">
					<filename>libva-2.20.0-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libva-2.20.0-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libva-devel" release="1.fos23" version="2.20.0">
					<filename>libva-devel-2.20.0-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/libva-devel-2.20.0-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libva" release="1.fos23" version="2.20.0">
					<filename>libva-2.20.0-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libva-2.20.0-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libva-devel" release="1.fos23" version="2.20.0">
					<filename>libva-devel-2.20.0-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/libva-devel-2.20.0-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2242</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45733" id="CVE-2023-45733" title="CVE-2023-45733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45745" id="CVE-2023-45745" title="CVE-2023-45745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46103" id="CVE-2023-46103" title="CVE-2023-46103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47855" id="CVE-2023-47855" title="CVE-2023-47855" type="cve"></reference>
		</references>
		<description>CVE-2023-45733:Hardware logic contains race conditions in some Intel(R) Processors may allow an authenticated user to potentially enable partial information disclosure via local access.&#xA;CVE-2023-45745:Improper input validation in some Intel(R) TDX module software before version 1.5.05.46.698 may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2023-46103:Sequence of processor instructions leads to unexpected behavior in Intel(R) Core(TM) Ultra Processors may allow an authenticated user to potentially enable denial of service via local access.&#xA;CVE-2023-47855:Improper input validation in some Intel(R) TDX module software before version 1.5.05.46.698 may allow a privileged user to potentially enable escalation of privilege via local access.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="1.fos23" version="20240531">
					<filename>microcode_ctl-20240531-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/microcode_ctl-20240531-1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2243</id>
		<title>An update for mod_http2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36387" id="CVE-2024-36387" title="CVE-2024-36387" type="cve"></reference>
		</references>
		<description>CVE-2024-36387:Serving WebSocket protocol upgrades over a HTTP/2 connection could result in a Null Pointer dereference, leading to a crash of the server process, degrading performance.</description>
		<pkglist>
			<collection>
				<name>23.1.1.2</name>
				<package arch="x86_64" epoch="0" name="mod_http2" release="3.u1.fos23" version="1.15.25">
					<filename>mod_http2-1.15.25-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.2/mod_http2-1.15.25-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="mod_http2-help" release="3.u1.fos23" version="1.15.25">
					<filename>mod_http2-help-1.15.25-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_http2-help-1.15.25-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_http2" release="3.u1.fos23" version="1.15.25">
					<filename>mod_http2-1.15.25-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.2/mod_http2-1.15.25-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2244</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21176" id="CVE-2024-21176" title="CVE-2024-21176" type="cve"></reference>
		</references>
		<description>CVE-2024-21176:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.4.0 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).</description>
		<pkglist>
			<collection>
				<name>23.1.1.3</name>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-libs-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-libs-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-config-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-config-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-common-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-common-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-errmsg-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-errmsg-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-server-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-server-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-devel-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-devel-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-test-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-test-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-help-8.0.37-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.1.3/mysql-help-8.0.37-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-libs-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-libs-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-config-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-config-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-common-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-common-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-errmsg-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-errmsg-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-server-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-server-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-devel-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-devel-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-test-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-test-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u1.fos23" version="8.0.37">
					<filename>mysql-help-8.0.37-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.1.3/mysql-help-8.0.37-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2245</id>
		<title>An update for nano is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5742" id="CVE-2024-5742" title="CVE-2024-5742" type="cve"></reference>
		</references>
		<description>CVE-2024-5742:A vulnerability was found in GNU Nano that allows a possible privilege escalation through an insecure temporary file. If Nano is killed while editing, a file it saves to an emergency file with the permissions of the running user provides a window of opportunity for attackers to escalate privileges through a malicious symlink.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="nano" release="1.fos23" version="8.0">
					<filename>nano-8.0-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/nano-8.0-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nano-help" release="1.fos23" version="8.0">
					<filename>nano-help-8.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/nano-help-8.0-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nano" release="1.fos23" version="8.0">
					<filename>nano-8.0-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/nano-8.0-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2246</id>
		<title>An update for ntfs-3g is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52890" id="CVE-2023-52890" title="CVE-2023-52890" type="cve"></reference>
		</references>
		<description>CVE-2023-52890:NTFS-3G before 75dcdc2 has a use-after-free in ntfs_uppercase_mbs in libntfs-3g/unistr.c. NOTE: discussion suggests that exploitation would be challenging.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="2" name="ntfs-3g" release="3.u1.fos23" version="2022.5.17">
					<filename>ntfs-3g-2022.5.17-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ntfs-3g-2022.5.17-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ntfs-3g-devel" release="3.u1.fos23" version="2022.5.17">
					<filename>ntfs-3g-devel-2022.5.17-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ntfs-3g-devel-2022.5.17-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ntfs-3g-help" release="3.u1.fos23" version="2022.5.17">
					<filename>ntfs-3g-help-2022.5.17-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ntfs-3g-help-2022.5.17-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ntfs-3g" release="3.u1.fos23" version="2022.5.17">
					<filename>ntfs-3g-2022.5.17-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ntfs-3g-2022.5.17-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ntfs-3g-devel" release="3.u1.fos23" version="2022.5.17">
					<filename>ntfs-3g-devel-2022.5.17-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ntfs-3g-devel-2022.5.17-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ntfs-3g-help" release="3.u1.fos23" version="2022.5.17">
					<filename>ntfs-3g-help-2022.5.17-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ntfs-3g-help-2022.5.17-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2247</id>
		<title>An update for openjpeg2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39328" id="CVE-2023-39328" title="CVE-2023-39328" type="cve"></reference>
		</references>
		<description>CVE-2023-39328:A vulnerability was found in OpenJPEG similar to CVE-2019-6988. This flaw allows an attacker to bypass existing protections and cause an application crash through a maliciously crafted file.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="openjpeg2" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-2.5.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openjpeg2-2.5.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-devel" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openjpeg2-devel-2.5.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-tools" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openjpeg2-tools-2.5.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openjpeg2-help" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-help-2.5.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openjpeg2-help-2.5.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-2.5.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openjpeg2-2.5.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2-devel" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openjpeg2-devel-2.5.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2-tools" release="3.u2.fos23" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openjpeg2-tools-2.5.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2248</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6409" id="CVE-2024-6409" title="CVE-2024-6409" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6387" id="CVE-2024-6387" title="CVE-2024-6387" type="cve"></reference>
		</references>
		<description>CVE-2024-6409:A race condition vulnerability was discovered in how signals are handled by OpenSSH&#39;s server (sshd). If a remote attacker does not authenticate within a set time period, then sshd&#39;s SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). As a consequence of a successful attack, in the worst case scenario, an attacker may be able to perform a remote code execution (RCE) as an unprivileged user running the sshd server.&#xA;CVE-2024-6387:A security regression (CVE-2006-5051) was discovered in OpenSSH&#39;s server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="openssh" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-8.8p1-29.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssh-8.8p1-29.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-29.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssh-clients-8.8p1-29.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-29.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssh-server-8.8p1-29.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-29.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssh-keycat-8.8p1-29.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-29.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssh-askpass-8.8p1-29.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.29.u23.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.29.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/pam_ssh_agent_auth-0.10.4-4.29.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-help-8.8p1-29.u23.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssh-help-8.8p1-29.u23.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-8.8p1-29.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssh-8.8p1-29.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-clients-8.8p1-29.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssh-clients-8.8p1-29.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-server-8.8p1-29.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssh-server-8.8p1-29.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-keycat-8.8p1-29.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssh-keycat-8.8p1-29.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="29.u23.fos23" version="8.8p1">
					<filename>openssh-askpass-8.8p1-29.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssh-askpass-8.8p1-29.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.29.u23.fos23" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.29.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/pam_ssh_agent_auth-0.10.4-4.29.u23.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2249</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"></reference>
		</references>
		<description>CVE-2024-4741:A use-after-free vulnerability was found in OpenSSL. Calling the OpenSSL API SSL_free_buffers function may cause memory to be accessed that was previously freed in some situations.&#xA;CVE-2024-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an&#xA;empty supported client protocols buffer may cause a crash or memory contents to&#xA;be sent to the peer.&#xA;Impact summary: A buffer overread can have a range of potential consequences&#xA;such as unexpected application beahviour or a crash. In particular this issue&#xA;could result in up to 255 bytes of arbitrary private data from memory being sent&#xA;to the peer leading to a loss of confidentiality. However, only applications&#xA;that directly call the SSL_select_next_proto function with a 0 length list of&#xA;supported client protocols are affected by this issue. This would normally never&#xA;be a valid scenario and is typically not under attacker control but may occur by&#xA;accident in the case of a configuration or programming error in the calling&#xA;application.&#xA;The OpenSSL API function SSL_select_next_proto is typically used by TLS&#xA;applications that support ALPN (Application Layer Protocol Negotiation) or NPN&#xA;(Next Protocol Negotiation). NPN is older, was never standardised and&#xA;is deprecated in favour of ALPN. We believe that ALPN is significantly more&#xA;widely deployed than NPN. The SSL_select_next_proto function accepts a list of&#xA;protocols from the server and a list of protocols from the client and returns&#xA;the first protocol that appears in the server list that also appears in the&#xA;client list. In the case of no overlap between the two lists it returns the&#xA;first item in the client list. In either case it will signal whether an overlap&#xA;between the two lists was found. In the case where SSL_select_next_proto is&#xA;called with a zero length client list it fails to notice this condition and&#xA;returns the memory immediately following the client list pointer (and reports&#xA;that there was no overlap in the lists).&#xA;This function is typically called from a server side application callback for&#xA;ALPN or a client side application callback for NPN. In the case of ALPN the list&#xA;of protocols supplied by the client is guaranteed by libssl to never be zero in&#xA;length. The list of server protocols comes from the application and should never&#xA;normally be expected to be of zero length. In this case if the&#xA;SSL_select_next_proto function has been called as expected (with the list&#xA;supplied by the client passed in the client/client_len parameters), then the&#xA;application will not be vulnerable to this issue. If the application has&#xA;accidentally been configured with a zero length server list, and has&#xA;accidentally passed that zero length server list in the client/client_len&#xA;parameters, and has additionally failed to correctly handle a &#34;no overlap&#34;&#xA;response (which would normally result in a handshake failure in ALPN) then it&#xA;will be vulnerable to this problem.&#xA;In the case of NPN, the protocol permits the client to opportunistically select&#xA;a protocol when there is no overlap. OpenSSL returns the first client protocol&#xA;in the no overlap case in support of this. The list of client protocols comes&#xA;from the application and should never normally be expected to be of zero length.&#xA;However if the SSL_select_next_proto function is accidentally called with a&#xA;client_len of 0 then an invalid memory pointer will be returned instead. If the&#xA;application uses this output as the opportunistic protocol then the loss of&#xA;confidentiality will occur.&#xA;This issue has been assessed as Low severity because applications are most&#xA;likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not&#xA;widely used. It also requires an application configuration or programming error.&#xA;Finally, this issue would not typically be under attacker control making active&#xA;exploitation unlikely.&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;Due to the low severity of this issue we are not issuing new releases of&#xA;OpenSSL at this time. The fix will be included in the next releases when they&#xA;become available.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="openssl" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-37.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssl-1.1.1m-37.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-37.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssl-libs-1.1.1m-37.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-37.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssl-perl-1.1.1m-37.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-37.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssl-devel-1.1.1m-37.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-37.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openssl-help-1.1.1m-37.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-37.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssl-1.1.1m-37.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-37.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssl-libs-1.1.1m-37.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-37.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssl-perl-1.1.1m-37.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="37.u17.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-37.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openssl-devel-1.1.1m-37.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2250</id>
		<title>An update for openvpn is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28882" id="CVE-2024-28882" title="CVE-2024-28882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27459" id="CVE-2024-27459" title="CVE-2024-27459" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27903" id="CVE-2024-27903" title="CVE-2024-27903" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24974" id="CVE-2024-24974" title="CVE-2024-24974" type="cve"></reference>
		</references>
		<description>CVE-2024-28882:OpenVPN from 2.6.0 through 2.6.10 in a server role accepts multiple exit notifications from authenticated clients which will extend the validity of a closing session&#xA;CVE-2024-27459:The interactive service in OpenVPN 2.6.9 and earlier allows an attacker to send data causing a stack overflow which can be used to execute arbitrary code with more privileges.&#xA;CVE-2024-27903:OpenVPN plug-ins on Windows with OpenVPN 2.6.9 and earlier could be loaded from any directory, which allows an attacker to load an arbitrary plug-in which can be used to interact with the privileged OpenVPN interactive service.&#xA;CVE-2024-24974:The interactive service in OpenVPN 2.6.9 and earlier allows the OpenVPN service pipe to be accessed remotely, which allows a remote attacker to interact with the privileged OpenVPN interactive service.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="openvpn" release="3.u1.fos23" version="2.5.5">
					<filename>openvpn-2.5.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openvpn-2.5.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvpn-devel" release="3.u1.fos23" version="2.5.5">
					<filename>openvpn-devel-2.5.5-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openvpn-devel-2.5.5-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openvpn-help" release="3.u1.fos23" version="2.5.5">
					<filename>openvpn-help-2.5.5-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/openvpn-help-2.5.5-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn" release="3.u1.fos23" version="2.5.5">
					<filename>openvpn-2.5.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openvpn-2.5.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn-devel" release="3.u1.fos23" version="2.5.5">
					<filename>openvpn-devel-2.5.5-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/openvpn-devel-2.5.5-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2251</id>
		<title>An update for p7zip is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52169" id="CVE-2023-52169" title="CVE-2023-52169" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52168" id="CVE-2023-52168" title="CVE-2023-52168" type="cve"></reference>
		</references>
		<description>CVE-2023-52169:The NtfsHandler.cpp NTFS handler in 7-Zip before 24.01 (for 7zz) contains an out-of-bounds read that allows an attacker to read beyond the intended buffer. The bytes read beyond the intended buffer are presented as a part of a filename listed in the file system image. This has security relevance in some known web-service use cases where untrusted users can upload files and have them extracted by a server-side 7-Zip process.&#xA;CVE-2023-52168:The NtfsHandler.cpp NTFS handler in 7-Zip before 24.01 (for 7zz) contains a heap-based buffer overflow that allows an attacker to overwrite two bytes at multiple offsets beyond the allocated buffer size: buffer+512*i-2, for i=9, i=10, i=11, etc.</description>
		<pkglist>
			<collection>
				<name>23.0.1</name>
				<package arch="x86_64" epoch="0" name="p7zip" release="4.fos23" version="16.02">
					<filename>p7zip-16.02-4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/x86_64/Packages/p7zip-16.02-4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="p7zip" release="4.fos23" version="16.02">
					<filename>p7zip-16.02-4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/everything/aarch64/Packages/p7zip-16.02-4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2252</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5458" id="CVE-2024-5458" title="CVE-2024-5458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4577" id="CVE-2024-4577" title="CVE-2024-4577" type="cve"></reference>
		</references>
		<description>CVE-2024-5458:In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.* before 8.3.8, due to a code logic error, filtering functions such as filter_var when validating URLs (FILTER_VALIDATE_URL) for certain types of URLs the function will result in invalid user information (username + password part of URLs) being treated as valid user information. This may lead to the downstream code accepting invalid URLs as valid and parsing them incorrectly.&#xA;CVE-2024-4577:In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.* before 8.3.8, when using Apache and PHP-CGI on Windows, if the system is set up to use certain code pages, Windows may use &#34;Best-Fit&#34; behavior to replace characters in command line given to Win32 API functions. PHP CGI module may misinterpret those characters as PHP options, which may allow a malicious user to pass options to PHP binary being run, and thus reveal the source code of scripts, run arbitrary PHP code on the server, etc.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="php" release="5.u3.fos23" version="8.0.30">
					<filename>php-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="5.u3.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-cli-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="5.u3.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-dbg-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="5.u3.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-fpm-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="5.u3.fos23" version="8.0.30">
					<filename>php-common-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-common-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="5.u3.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-devel-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="5.u3.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-opcache-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="5.u3.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-ldap-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="5.u3.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-pdo-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="5.u3.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-mysqlnd-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="5.u3.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-pgsql-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="5.u3.fos23" version="8.0.30">
					<filename>php-process-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-process-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="5.u3.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-odbc-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="5.u3.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-soap-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="5.u3.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-snmp-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="5.u3.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-xml-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="5.u3.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-mbstring-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="5.u3.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-gd-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="5.u3.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-bcmath-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="5.u3.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-gmp-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="5.u3.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-dba-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="5.u3.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-tidy-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="5.u3.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-embedded-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="5.u3.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-intl-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="5.u3.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-enchant-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="5.u3.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-sodium-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="5.u3.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-ffi-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-help" release="5.u3.fos23" version="8.0.30">
					<filename>php-help-8.0.30-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/php-help-8.0.30-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="5.u3.fos23" version="8.0.30">
					<filename>php-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="5.u3.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-cli-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="5.u3.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-dbg-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="5.u3.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-fpm-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="5.u3.fos23" version="8.0.30">
					<filename>php-common-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-common-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="5.u3.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-devel-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="5.u3.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-opcache-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="5.u3.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-ldap-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="5.u3.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-pdo-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="5.u3.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-mysqlnd-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="5.u3.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-pgsql-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="5.u3.fos23" version="8.0.30">
					<filename>php-process-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-process-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="5.u3.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-odbc-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="5.u3.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-soap-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="5.u3.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-snmp-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="5.u3.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-xml-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="5.u3.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-mbstring-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="5.u3.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-gd-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="5.u3.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-bcmath-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="5.u3.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-gmp-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="5.u3.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-dba-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="5.u3.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-tidy-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="5.u3.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-embedded-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="5.u3.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-intl-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="5.u3.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-enchant-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="5.u3.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-sodium-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="5.u3.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-ffi-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-help" release="5.u3.fos23" version="8.0.30">
					<filename>php-help-8.0.30-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/php-help-8.0.30-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2253</id>
		<title>An update for podman is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32149" id="CVE-2022-32149" title="CVE-2022-32149" type="cve"></reference>
		</references>
		<description>CVE-2022-32149:An attacker may cause a denial of service by crafting an Accept-Language header which ParseAcceptLanguage will take significant time to parse.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="1" name="podman" release="2.u2.fos23" version="3.4.4">
					<filename>podman-3.4.4-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/podman-3.4.4-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="podman-docker" release="2.u2.fos23" version="3.4.4">
					<filename>podman-docker-3.4.4-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/podman-docker-3.4.4-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman-remote" release="2.u2.fos23" version="3.4.4">
					<filename>podman-remote-3.4.4-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/podman-remote-3.4.4-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman-plugins" release="2.u2.fos23" version="3.4.4">
					<filename>podman-plugins-3.4.4-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/podman-plugins-3.4.4-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman-gvproxy" release="2.u2.fos23" version="3.4.4">
					<filename>podman-gvproxy-3.4.4-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/podman-gvproxy-3.4.4-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman-help" release="2.u2.fos23" version="3.4.4">
					<filename>podman-help-3.4.4-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/podman-help-3.4.4-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman" release="2.u2.fos23" version="3.4.4">
					<filename>podman-3.4.4-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/podman-3.4.4-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-remote" release="2.u2.fos23" version="3.4.4">
					<filename>podman-remote-3.4.4-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/podman-remote-3.4.4-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-plugins" release="2.u2.fos23" version="3.4.4">
					<filename>podman-plugins-3.4.4-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/podman-plugins-3.4.4-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-gvproxy" release="2.u2.fos23" version="3.4.4">
					<filename>podman-gvproxy-3.4.4-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/podman-gvproxy-3.4.4-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-help" release="2.u2.fos23" version="3.4.4">
					<filename>podman-help-3.4.4-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/podman-help-3.4.4-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2254</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6239" id="CVE-2024-6239" title="CVE-2024-6239" type="cve"></reference>
		</references>
		<description>CVE-2024-6239:A flaw was found in the Poppler&#39;s Pdfinfo utility. This issue occurs when using -dests parameter with pdfinfo utility. By using certain malformed input files, an attacker could cause the utility to crash, leading to a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="poppler" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-devel-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-glib-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-glib-devel-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-glib-doc-0.90.0-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-qt5-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-qt5-devel-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-cpp-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-cpp-devel-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-utils-0.90.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/poppler-help-0.90.0-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-devel-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-glib-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-glib-devel-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-qt5-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-qt5-devel-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-cpp-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-cpp-devel-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="8.u5.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/poppler-utils-0.90.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2255</id>
		<title>An update for python-aiosmtpd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34083" id="CVE-2024-34083" title="CVE-2024-34083" type="cve"></reference>
		</references>
		<description>CVE-2024-34083:aiosmptd is  a reimplementation of the Python stdlib smtpd.py based on asyncio. Prior to version 1.4.6, servers based on aiosmtpd accept extra unencrypted commands after STARTTLS, treating them as if they came from inside the encrypted connection. This could be exploited by a man-in-the-middle attack. Version 1.4.6 contains a patch for the issue.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="0" name="python3-aiosmtpd" release="1.u2.fos23" version="1.4.6">
					<filename>python3-aiosmtpd-1.4.6-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-aiosmtpd-1.4.6-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-aiosmtpd-help" release="1.u2.fos23" version="1.4.6">
					<filename>python-aiosmtpd-help-1.4.6-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python-aiosmtpd-help-1.4.6-1.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2256</id>
		<title>An update for python-scikit-learn is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5206" id="CVE-2024-5206" title="CVE-2024-5206" type="cve"></reference>
		</references>
		<description>CVE-2024-5206:A sensitive data leakage vulnerability was identified in scikit-learn&#39;s TfidfVectorizer, specifically in versions up to and including 1.4.1.post1, which was fixed in version 1.5.0. The vulnerability arises from the unexpected storage of all tokens present in the training data within the `stop_words_` attribute, rather than only storing the subset of tokens required for the TF-IDF technique to function. This behavior leads to the potential leakage of sensitive information, as the `stop_words_` attribute could contain tokens that were meant to be discarded and not stored, such as passwords or keys. The impact of this vulnerability varies based on the nature of the data being processed by the vectorizer.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="python3-scikit-learn" release="2.u1.fos23" version="1.1.1">
					<filename>python3-scikit-learn-1.1.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-scikit-learn-1.1.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-scikit-learn" release="2.u1.fos23" version="1.1.1">
					<filename>python3-scikit-learn-1.1.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/python3-scikit-learn-1.1.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2257</id>
		<title>An update for python-setuptools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6345" id="CVE-2024-6345" title="CVE-2024-6345" type="cve"></reference>
		</references>
		<description>CVE-2024-6345:A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="0" name="python-setuptools" release="6.u2.fos23" version="59.4.0">
					<filename>python-setuptools-59.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python-setuptools-59.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-setuptools" release="6.u2.fos23" version="59.4.0">
					<filename>python3-setuptools-59.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-setuptools-59.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-setuptools-help" release="6.u2.fos23" version="59.4.0">
					<filename>python-setuptools-help-59.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python-setuptools-help-59.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2258</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"></reference>
		</references>
		<description>CVE-2024-37891:urllib3 is a user-friendly HTTP client library for Python. When using urllib3&#39;s proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3&#39;s proxy support, it&#39;s possible to accidentally configure the `Proxy-Authorization` header even though it won&#39;t have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn&#39;t treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn&#39;t strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3&#39;s proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren&#39;t using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3&#39;s built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3&#39;s `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="0" name="python3-urllib3" release="6.u6.fos23" version="1.26.12">
					<filename>python3-urllib3-1.26.12-6.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-urllib3-1.26.12-6.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2259</id>
		<title>An update for python-zipp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5569" id="CVE-2024-5569" title="CVE-2024-5569" type="cve"></reference>
		</references>
		<description>CVE-2024-5569:A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="0" name="python3-zipp" release="3.u2.fos23" version="3.7.0">
					<filename>python3-zipp-3.7.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python3-zipp-3.7.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-zipp-help" release="3.u2.fos23" version="3.7.0">
					<filename>python-zipp-help-3.7.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/python-zipp-help-3.7.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2260</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4467" id="CVE-2024-4467" title="CVE-2024-4467" type="cve"></reference>
		</references>
		<description>CVE-2024-4467:A flaw was found in the QEMU disk image utility (qemu-img) &#39;info&#39; command. A specially crafted image file containing a `json:{}` value describing block devices in QMP could cause the qemu-img process on the host to consume large amounts of memory or CPU time, leading to denial of service or read/write to an existing external file.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="10" name="qemu" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-guest-agent-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-96.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-help-6.2.0-96.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-img-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-block-rbd-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-block-ssh-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-block-iscsi-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-block-curl-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-hw-usb-host-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-seabios-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-system-aarch64-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-system-arm-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-system-x86_64-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-96.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qemu-system-riscv-6.2.0-96.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-guest-agent-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-img-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-block-rbd-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-block-ssh-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-block-iscsi-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-block-curl-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-hw-usb-host-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-system-aarch64-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-system-arm-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-system-x86_64-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="96.u18.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-96.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qemu-system-riscv-6.2.0-96.u18.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2261</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39936" id="CVE-2024-39936" title="CVE-2024-39936" type="cve"></reference>
		</references>
		<description>CVE-2024-39936:An issue was discovered in HTTP2 in Qt before 5.15.18, 6.x before 6.2.13, 6.3.x through 6.5.x before 6.5.7, and 6.6.x through 6.7.x before 6.7.3. Code to make security-relevant decisions about an established connection may execute too early, because the encrypted() signal has not yet been emitted and processed..</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="x86_64" epoch="1" name="qt" release="58.u8.fos23" version="4.8.7">
					<filename>qt-4.8.7-58.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/qt-4.8.7-58.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="qt-devel" release="58.u8.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-58.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2/qt-devel-4.8.7-58.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt" release="58.u8.fos23" version="4.8.7">
					<filename>qt-4.8.7-58.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt-4.8.7-58.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="qt-devel" release="58.u8.fos23" version="4.8.7">
					<filename>qt-devel-4.8.7-58.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt-devel-4.8.7-58.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2262</id>
		<title>An update for qt5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39936" id="CVE-2024-39936" title="CVE-2024-39936" type="cve"></reference>
		</references>
		<description>CVE-2024-39936:An issue was discovered in HTTP2 in Qt before 5.15.18, 6.x before 6.2.13, 6.3.x through 6.5.x before 6.5.7, and 6.6.x through 6.7.x before 6.7.3. Code to make security-relevant decisions about an established connection may execute too early, because the encrypted() signal has not yet been emitted and processed..</description>
		<pkglist>
			<collection>
				<name>23.1.2</name>
				<package arch="noarch" epoch="0" name="qt5" release="2.u2.fos23" version="5.15.2">
					<filename>qt5-5.15.2-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt5-5.15.2-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-devel" release="2.u2.fos23" version="5.15.2">
					<filename>qt5-devel-5.15.2-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt5-devel-5.15.2-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-rpm-macros" release="2.u2.fos23" version="5.15.2">
					<filename>qt5-rpm-macros-5.15.2-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt5-rpm-macros-5.15.2-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-srpm-macros" release="2.u2.fos23" version="5.15.2">
					<filename>qt5-srpm-macros-5.15.2-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2/qt5-srpm-macros-5.15.2-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2263</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39936" id="CVE-2024-39936" title="CVE-2024-39936" type="cve"></reference>
		</references>
		<description>CVE-2024-39936:An issue was discovered in HTTP2 in Qt before 5.15.18, 6.x before 6.2.13, 6.3.x through 6.5.x before 6.5.7, and 6.6.x through 6.7.x before 6.7.3. Code to make security-relevant decisions about an established connection may execute too early, because the encrypted() signal has not yet been emitted and processed..</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-17.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-common-5.15.2-17.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-devel-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-private-devel-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-examples-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-static-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-mysql-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-odbc-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-postgresql-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-17.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/qt5-qtbase-gui-5.15.2-17.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-devel-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-private-devel-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-examples-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-static-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-mysql-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-odbc-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-postgresql-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="17.u10.fos23" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-17.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/qt5-qtbase-gui-5.15.2-17.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2264</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35221" id="CVE-2024-35221" title="CVE-2024-35221" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35176" id="CVE-2024-35176" title="CVE-2024-35176" type="cve"></reference>
		</references>
		<description>CVE-2024-35221:Rubygems.org is the Ruby community&#39;s gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab.&#xA;CVE-2024-35176:REXML is an XML toolkit for Ruby. The REXML gem before 3.2.6 has a denial of service vulnerability when it parses an XML that has many `&lt;`s in an attribute value. Those who need to parse untrusted XMLs may be impacted to this vulnerability. The REXML gem 3.2.7 or later include the patch to fix this vulnerability. As a workaround, don&#39;t parse untrusted XMLs.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="ruby" release="136.u10.fos23" version="3.0.3">
					<filename>ruby-3.0.3-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ruby-3.0.3-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="136.u10.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ruby-devel-3.0.3-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="136.u10.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygems-3.2.32-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="136.u10.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygems-devel-3.2.32-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="136.u10.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rake-13.0.3-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="136.u10.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rbs-1.4.0-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="136.u10.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ruby-irb-3.0.3-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="136.u10.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rdoc-6.3.3-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="136.u10.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/ruby-help-3.0.3-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="136.u10.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-bigdecimal-3.0.0-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="136.u10.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-did_you_mean-1.5.0-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="136.u10.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-io-console-0.5.7-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="136.u10.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-json-2.5.1-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="136.u10.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-minitest-5.14.2-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="136.u10.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-openssl-2.2.1-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="136.u10.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-136.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-psych-3.3.2-136.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="136.u10.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-test-unit-3.3.7-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="136.u10.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rexml-3.2.5-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="136.u10.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rss-0.2.9-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="136.u10.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-136.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-typeprof-0.15.2-136.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="136.u10.fos23" version="3.0.3">
					<filename>ruby-3.0.3-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ruby-3.0.3-136.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="136.u10.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/ruby-devel-3.0.3-136.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="136.u10.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rubygem-bigdecimal-3.0.0-136.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="136.u10.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rubygem-io-console-0.5.7-136.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="136.u10.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rubygem-json-2.5.1-136.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="136.u10.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rubygem-openssl-2.2.1-136.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="136.u10.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-136.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rubygem-psych-3.3.2-136.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2265</id>
		<title>An update for rubygem-actionpack is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28103" id="CVE-2024-28103" title="CVE-2024-28103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23633" id="CVE-2022-23633" title="CVE-2022-23633" type="cve"></reference>
		</references>
		<description>CVE-2024-28103:Action Pack is a framework for handling and responding to web requests. Since 6.1.0, the application configurable Permissions-Policy is only served on responses with an HTML related Content-Type. This vulnerability is fixed in  6.1.7.8, 7.0.8.2, and 7.1.3.3.&#xA;CVE-2022-23633:Action Pack is a framework for handling and responding to web requests. Under certain circumstances response bodies will not be closed. In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests.This has been fixed in Rails 7.0.2.1, 6.1.4.5, 6.0.4.5, and 5.2.6.1. Upgrading is highly recommended, but to work around this problem a middleware described in GHSA-wh98-p28r-vrc9 can be used.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="1" name="rubygem-actionpack" release="5.u3.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-6.1.4.1-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-actionpack-6.1.4.1-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-actionpack-doc" release="5.u3.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-doc-6.1.4.1-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-actionpack-doc-6.1.4.1-5.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2266</id>
		<title>An update for rubygem-actionview is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23913" id="CVE-2023-23913" title="CVE-2023-23913" type="cve"></reference>
		</references>
		<description>CVE-2023-23913:A flaw was found in Rails. rails-ujs may allow an attacker to perform Cross-Site Scripting (XSS), which could lead to stolen information, phishing attacks, and other types of attacks.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="0" name="rubygem-actionview" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-actionview-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-actionview-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-actionview-doc" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-actionview-doc-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-actionview-doc-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2267</id>
		<title>An update for rubygem-activesupport is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23633" id="CVE-2022-23633" title="CVE-2022-23633" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28120" id="CVE-2023-28120" title="CVE-2023-28120" type="cve"></reference>
		</references>
		<description>CVE-2022-23633:Action Pack is a framework for handling and responding to web requests. Under certain circumstances response bodies will not be closed. In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests.This has been fixed in Rails 7.0.2.1, 6.1.4.5, 6.0.4.5, and 5.2.6.1. Upgrading is highly recommended, but to work around this problem a middleware described in GHSA-wh98-p28r-vrc9 can be used.&#xA;CVE-2023-28120:A Cross-Site-Scripting vulnerability was found in rubygem ActiveSupport. If the new bytesplice method is called on a SafeBuffer with untrusted user input, malicious code could be executed.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="1" name="rubygem-activesupport" release="7.u4.fos23" version="6.1.4.1">
					<filename>rubygem-activesupport-6.1.4.1-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-activesupport-6.1.4.1-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-activesupport-doc" release="7.u4.fos23" version="6.1.4.1">
					<filename>rubygem-activesupport-doc-6.1.4.1-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-activesupport-doc-6.1.4.1-7.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2268</id>
		<title>An update for rubygem-rack is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39316" id="CVE-2024-39316" title="CVE-2024-39316" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25126" id="CVE-2024-25126" title="CVE-2024-25126" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26141" id="CVE-2024-26141" title="CVE-2024-26141" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26146" id="CVE-2024-26146" title="CVE-2024-26146" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44570" id="CVE-2022-44570" title="CVE-2022-44570" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44571" id="CVE-2022-44571" title="CVE-2022-44571" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44572" id="CVE-2022-44572" title="CVE-2022-44572" type="cve"></reference>
		</references>
		<description>CVE-2024-39316:Rack is a modular Ruby web server interface. Starting in version 3.1.0 and prior to version 3.1.5, Regular Expression Denial of Service (ReDoS) vulnerability exists in the `Rack::Request::Helpers` module when parsing HTTP Accept headers. This vulnerability can be exploited by an attacker sending specially crafted `Accept-Encoding` or `Accept-Language` headers, causing the server to spend excessive time processing the request and leading to a Denial of Service (DoS). The fix for CVE-2024-26146 was not applied to the main branch and thus while the issue was fixed for the Rack v3.0 release series, it was not fixed in the v3.1 release series until v3.1.5. Users of versions on the 3.1 branch should upgrade to version 3.1.5 to receive the fix.&#xA;CVE-2024-25126:Rack is a modular Ruby web server interface. Carefully crafted content type headers can cause Rack’s media type parser to take much longer than expected, leading to a possible denial of service vulnerability (ReDos 2nd degree polynomial). This vulnerability is patched in 3.0.9.1 and 2.2.8.1.&#xA;CVE-2024-26141:Rack is a modular Ruby web server interface. Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). The vulnerability is fixed in 3.0.9.1 and 2.2.8.1.&#xA;CVE-2024-26146:Rack is a modular Ruby web server interface. Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted. Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2 or newer are unaffected. This vulnerability is fixed in 2.0.9.4, 2.1.4.4, 2.2.8.1, and 3.0.9.1.&#xA;CVE-2022-44570:A denial of service vulnerability in the Range header parsing component of Rack &gt;= 1.5.0. A Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.&#xA;CVE-2022-44571:There is a denial of service vulnerability in the Content-Disposition parsingcomponent of Rack fixed in 2.0.9.2, 2.1.4.2, 2.2.4.1, 3.0.0.1. This could allow an attacker to craft an input that can cause Content-Disposition header parsing in Rackto take an unexpected amount of time, possibly resulting in a denial ofservice attack vector. This header is used typically used in multipartparsing. Any applications that parse multipart posts using Rack (virtuallyall Rails applications) are impacted.&#xA;CVE-2022-44572:A denial of service vulnerability in the multipart parsing component of Rack fixed in 2.0.9.2, 2.1.4.2, 2.2.4.1 and 3.0.0.1 could allow an attacker tocraft input that can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="1" name="rubygem-rack" release="4.u1.fos23" version="2.2.3.1">
					<filename>rubygem-rack-2.2.3.1-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rack-2.2.3.1-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-rack-help" release="4.u1.fos23" version="2.2.3.1">
					<filename>rubygem-rack-help-2.2.3.1-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rubygem-rack-help-2.2.3.1-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2269</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3154" id="CVE-2024-3154" title="CVE-2024-3154" type="cve"></reference>
		</references>
		<description>CVE-2024-3154:A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="runc" release="25.u8.fos23" version="1.1.3">
					<filename>runc-1.1.3-25.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/runc-1.1.3-25.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="runc" release="25.u8.fos23" version="1.1.3">
					<filename>runc-1.1.3-25.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/runc-1.1.3-25.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2270</id>
		<title>An update for rust is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36113" id="CVE-2022-36113" title="CVE-2022-36113" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36114" id="CVE-2022-36114" title="CVE-2022-36114" type="cve"></reference>
		</references>
		<description>CVE-2022-36113:Cargo is a package manager for the rust programming language. After a package is downloaded, Cargo extracts its source code in the ~/.cargo folder on disk, making it available to the Rust projects it builds. To record when an extraction is successful, Cargo writes &#34;ok&#34; to the .cargo-ok file at the root of the extracted source code once it extracted all the files. It was discovered that Cargo allowed packages to contain a .cargo-ok symbolic link, which Cargo would extract. Then, when Cargo attempted to write &#34;ok&#34; into .cargo-ok, it would actually replace the first two bytes of the file the symlink pointed to with ok. This would allow an attacker to corrupt one file on the machine using Cargo to extract the package. Note that by design Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it&#39;s possible to perform the same attacks with build scripts and procedural macros. The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it. Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available in the wg-security-response repository for people building their own toolchain.&#xA;Mitigations We recommend users of alternate registries to exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to exercise care in choosing their dependencies though, as remote code execution is allowed by design there as well.&#xA;CVE-2022-36114:Cargo is a package manager for the rust programming language. It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extracts way more data than its size (also known as a &#34;zip bomb&#34;), exhausting the disk space on the machine using Cargo to download the package. Note that by design Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it&#39;s possible to perform the same attacks with build scripts and procedural macros. The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it. Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available in the wg-security-response repository for people building their own toolchain. We recommend users of alternate registries to excercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as the same concerns about build scripts and procedural macros apply here.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="rust" release="4.u2.fos23" version="1.60.0">
					<filename>rust-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-std-static" release="4.u2.fos23" version="1.60.0">
					<filename>rust-std-static-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-std-static-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-debugger-common" release="4.u2.fos23" version="1.60.0">
					<filename>rust-debugger-common-1.60.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-debugger-common-1.60.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-gdb" release="4.u2.fos23" version="1.60.0">
					<filename>rust-gdb-1.60.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-gdb-1.60.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-lldb" release="4.u2.fos23" version="1.60.0">
					<filename>rust-lldb-1.60.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-lldb-1.60.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cargo" release="4.u2.fos23" version="1.60.0">
					<filename>cargo-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/cargo-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rustfmt" release="4.u2.fos23" version="1.60.0">
					<filename>rustfmt-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rustfmt-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rls" release="4.u2.fos23" version="1.60.0">
					<filename>rls-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rls-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clippy" release="4.u2.fos23" version="1.60.0">
					<filename>clippy-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/clippy-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-src" release="4.u2.fos23" version="1.60.0">
					<filename>rust-src-1.60.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-src-1.60.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-analysis" release="4.u2.fos23" version="1.60.0">
					<filename>rust-analysis-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-analysis-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-help" release="4.u2.fos23" version="1.60.0">
					<filename>rust-help-1.60.0-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/rust-help-1.60.0-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust" release="4.u2.fos23" version="1.60.0">
					<filename>rust-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rust-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-std-static" release="4.u2.fos23" version="1.60.0">
					<filename>rust-std-static-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rust-std-static-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cargo" release="4.u2.fos23" version="1.60.0">
					<filename>cargo-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/cargo-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rustfmt" release="4.u2.fos23" version="1.60.0">
					<filename>rustfmt-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rustfmt-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rls" release="4.u2.fos23" version="1.60.0">
					<filename>rls-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rls-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clippy" release="4.u2.fos23" version="1.60.0">
					<filename>clippy-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/clippy-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-analysis" release="4.u2.fos23" version="1.60.0">
					<filename>rust-analysis-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rust-analysis-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-help" release="4.u2.fos23" version="1.60.0">
					<filename>rust-help-1.60.0-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/rust-help-1.60.0-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2271</id>
		<title>An update for sbt is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46122" id="CVE-2023-46122" title="CVE-2023-46122" type="cve"></reference>
		</references>
		<description>CVE-2023-46122:sbt is a build tool for Scala, Java, and others. Given a specially crafted zip or JAR file, `IO.unzip` allows writing of arbitrary file. This would have potential to overwrite `/root/.ssh/authorized_keys`. Within sbt&#39;s main code, `IO.unzip` is used in `pullRemoteCache` task and `Resolvers.remote`; however many projects use `IO.unzip(...)` directly to implement custom tasks. This vulnerability has been patched in version 1.9.7.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="noarch" epoch="0" name="sbt" release="3.u1.fos23" version="0.13.1">
					<filename>sbt-0.13.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/sbt-0.13.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2272</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37894" id="CVE-2024-37894" title="CVE-2024-37894" type="cve"></reference>
		</references>
		<description>CVE-2024-37894:Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to an Out-of-bounds Write error when assigning ESI variables, Squid is susceptible to a Memory Corruption error. This error can lead to a Denial of Service attack.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="7" name="squid" release="25.u6.fos23" version="4.9">
					<filename>squid-4.9-25.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/squid-4.9-25.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="25.u6.fos23" version="4.9">
					<filename>squid-4.9-25.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/squid-4.9-25.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2273</id>
		<title>An update for vte291 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37535" id="CVE-2024-37535" title="CVE-2024-37535" type="cve"></reference>
		</references>
		<description>CVE-2024-37535:GNOME VTE before 0.76.3 allows an attacker to cause a denial of service (memory consumption) via a window resize escape sequence, a related issue to CVE-2000-0476.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="vte291" release="2.u1.fos23" version="0.62.3">
					<filename>vte291-0.62.3-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/vte291-0.62.3-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="vte291-devel" release="2.u1.fos23" version="0.62.3">
					<filename>vte291-devel-0.62.3-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/vte291-devel-0.62.3-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="vte291" release="2.u1.fos23" version="0.62.3">
					<filename>vte291-0.62.3-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/vte291-0.62.3-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="vte291-devel" release="2.u1.fos23" version="0.62.3">
					<filename>vte291-devel-0.62.3-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/vte291-devel-0.62.3-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2274</id>
		<title>An update for xorg-x11-server-Xwayland is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-08-08"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2320" id="CVE-2022-2320" title="CVE-2022-2320" type="cve"></reference>
		</references>
		<description>CVE-2022-2320:A flaw was found in the Xorg-x11-server. The specific flaw exists within the handling of ProcXkbSetDeviceInfo requests. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an allocated buffer. This flaw allows an attacker to escalate privileges and execute arbitrary code in the context of root.</description>
		<pkglist>
			<collection>
				<name>23.1.2.4</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland" release="6.u4.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/xorg-x11-server-Xwayland-22.1.2-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="6.u4.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.2.4/xorg-x11-server-Xwayland-devel-22.1.2-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland" release="6.u4.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/xorg-x11-server-Xwayland-22.1.2-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="6.u4.fos23" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.2.4/xorg-x11-server-Xwayland-devel-22.1.2-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2275</id>
		<title>An update for bubblewrap is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42472" id="CVE-2024-42472" title="CVE-2024-42472" type="cve"></reference>
		</references>
		<description>CVE-2024-42472:Flatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.14.0 and 1.15.10, a malicious or compromised Flatpak app using persistent directories could access and write files outside of what it would otherwise have access to, which is an attack on integrity and confidentiality.&#xA;When `persistent=subdir` is used in the application permissions (represented as `--persist=subdir` in the command-line interface), that means that an application which otherwise doesn&#39;t have access to the real user home directory will see an empty home directory with a writeable subdirectory `subdir`. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as `~/.var/app/$APPID/subdir`. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.&#xA;However, the application does have write access to the application directory `~/.var/app/$APPID` where this directory is stored. If the source directory for the `persistent`/`--persist` option is replaced by a symlink, then the next time the application is started, the bind mount will follow the symlink and mount whatever it points to into the sandbox.&#xA;Partial protection against this vulnerability can be provided by patching Flatpak using the patches in commits ceec2ffc and 98f79773. However, this leaves a race condition that could be exploited by two instances of a malicious app running in parallel. Closing the race condition requires updating or patching the version of bubblewrap that is used by Flatpak to add the new `--bind-fd` option using the patch and then patching Flatpak to use it. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=bwrap` (1.15.x) or `--with-system-bubblewrap=bwrap` (1.14.x or older), or a similar option, then the version of bubblewrap that needs to be patched is a system copy that is distributed separately, typically `/usr/bin/bwrap`. This configuration is the one that is typically used in Linux distributions. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=` (1.15.x) or with `--without-system-bubblewrap` (1.14.x or older), then it is the bundled version of bubblewrap that is included with Flatpak that must be patched. This is typically installed as `/usr/libexec/flatpak-bwrap`. This configuration is the default when building from source code.&#xA;For the 1.14.x stable branch, these changes are included in Flatpak 1.14.10. The bundled version of bubblewrap included in this release has been updated to 0.6.3. For the 1.15.x development branch, these changes are included in Flatpak 1.15.10. The bundled version of bubblewrap in this release is a Meson &#34;wrap&#34; subproject, which has been updated to 0.10.0. The 1.12.x and 1.10.x branches will not be updated for this vulnerability. Long-term support OS distributions should backport the individual changes into their versions of Flatpak and bubblewrap, or update to newer versions if their stability policy allows it. As a workaround, avoid using applications using the `persistent` (`--persist`) permission.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="bubblewrap" release="1.u1.fos23" version="0.4.1">
					<filename>bubblewrap-0.4.1-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/bubblewrap-0.4.1-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="bubblewrap-help" release="1.u1.fos23" version="0.4.1">
					<filename>bubblewrap-help-0.4.1-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/bubblewrap-help-0.4.1-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bubblewrap" release="1.u1.fos23" version="0.4.1">
					<filename>bubblewrap-0.4.1-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/bubblewrap-0.4.1-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2276</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7264" id="CVE-2024-7264" title="CVE-2024-7264" type="cve"></reference>
		</references>
		<description>CVE-2024-7264:libcurl&#39;s ASN1 parser code has the `GTime2str()` function, used for parsing an&#xA;ASN.1 Generalized Time field. If given an syntactically incorrect field, the&#xA;parser might end up using -1 for the length of the *time fraction*, leading to&#xA;a `strlen()` getting performed on a pointer to a heap buffer area that is not&#xA;(purposely) null terminated.&#xA;This flaw most likely leads to a crash, but can also lead to heap contents&#xA;getting returned to the application when&#xA;[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="curl" release="30.u16.fos23" version="7.79.1">
					<filename>curl-7.79.1-30.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/curl-7.79.1-30.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-30.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libcurl-7.79.1-30.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-30.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libcurl-devel-7.79.1-30.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="30.u16.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-30.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/curl-help-7.79.1-30.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="30.u16.fos23" version="7.79.1">
					<filename>curl-7.79.1-30.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/curl-7.79.1-30.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-30.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libcurl-7.79.1-30.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-30.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libcurl-devel-7.79.1-30.u16.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2277</id>
		<title>An update for docker is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41110" id="CVE-2024-41110" title="CVE-2024-41110" type="cve"></reference>
		</references>
		<description>CVE-2024-41110:Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.&#xA;Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.&#xA;A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.&#xA;Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.&#xA;docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="docker" release="1.u3.fos23" version="20.10.24">
					<filename>docker-20.10.24-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/docker-20.10.24-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="docker-engine" release="1.u3.fos23" version="20.10.24">
					<filename>docker-engine-20.10.24-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/docker-engine-20.10.24-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="docker-client" release="1.u3.fos23" version="20.10.24">
					<filename>docker-client-20.10.24-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/docker-client-20.10.24-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="docker" release="1.u3.fos23" version="20.10.24">
					<filename>docker-20.10.24-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/docker-20.10.24-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="docker-engine" release="1.u3.fos23" version="20.10.24">
					<filename>docker-engine-20.10.24-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/docker-engine-20.10.24-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="docker-client" release="1.u3.fos23" version="20.10.24">
					<filename>docker-client-20.10.24-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/docker-client-20.10.24-1.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2278</id>
		<title>An update for dovecot is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-3420" id="CVE-2015-3420" title="CVE-2015-3420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-8652" id="CVE-2016-8652" title="CVE-2016-8652" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10957" id="CVE-2020-10957" title="CVE-2020-10957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10958" id="CVE-2020-10958" title="CVE-2020-10958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10967" id="CVE-2020-10967" title="CVE-2020-10967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12100" id="CVE-2020-12100" title="CVE-2020-12100" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12673" id="CVE-2020-12673" title="CVE-2020-12673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12674" id="CVE-2020-12674" title="CVE-2020-12674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24386" id="CVE-2020-24386" title="CVE-2020-24386" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-25275" id="CVE-2020-25275" title="CVE-2020-25275" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-30550" id="CVE-2022-30550" title="CVE-2022-30550" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23184" id="CVE-2024-23184" title="CVE-2024-23184" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23185" id="CVE-2024-23185" title="CVE-2024-23185" type="cve"></reference>
		</references>
		<description>CVE-2015-3420:The ssl-proxy-openssl.c function in Dovecot before 2.2.17, when SSLv3 is disabled, allow remote attackers to cause a d&#xA;enial of service (login process crash) via vectors related to handshake failures.&#xA;CVE-2016-8652:The auth component in Dovecot before 2.2.27, when auth-policy is configured, allows a remote attackers to cause a denial of service (crash) by aborting authentication without setting a username.&#xA;CVE-2020-10957:A flaw was found in Dovecot, where it did not properly handle certain malformed NOOP commands. This flaw allows a malicious attacker to cause the submission, submission-login, or lmtp services to crash by sending specially crafted commands.&#xA;CVE-2020-10958:In Dovecot before 2.3.10.1, a crafted SMTP/LMTP message triggers an unauthenticated use-after-free bug in submission-login, submission, or lmtp, and can lead to a crash under circumstances involving many newlines after a command.&#xA;CVE-2020-10967:In Dovecot before 2.3.10.1, remote unauthenticated attackers can crash the lmtp or submission process by sending mail with an empty localpart.&#xA;CVE-2020-12100:In Dovecot before 2.3.11.3, uncontrolled recursion in submission, lmtp, and lda allows remote attackers to cause a denial of service (resource consumption) via a crafted e-mail message with deeply nested MIME parts.&#xA;CVE-2020-12673:In Dovecot before 2.3.11.3, sending a specially formatted NTLM request will crash the auth service because of an out-of-bounds read.&#xA;CVE-2020-12674:In Dovecot before 2.3.11.3, sending a specially formatted RPA request will crash the auth service because a length of zero is mishandled.&#xA;CVE-2020-24386:An issue was discovered in Dovecot before 2.3.13. By using IMAP IDLE, an authenticated attacker can trigger unhibernation via attacker-controlled parameters, leading to access to other users&#39; email messages (and path disclosure).&#xA;CVE-2020-25275:Dovecot before 2.3.13 has Improper Input Validation in lda, lmtp, and imap, leading to an application crash via a crafted email message with certain choices for ten thousand MIME parts.&#xA;CVE-2022-30550:An issue was discovered in the auth component in Dovecot 2.2 and 2.3 before 2.3.20. When two passdb configuration entries exist with the same driver and args settings, incorrect username_filter and mechanism settings can be applied to passdb definitions. These incorrectly applied settings can lead to an unintended security configuration and can permit privilege escalation in certain configurations. The documentation does not advise against the use of passdb definitions that have the same driver and args settings. One such configuration would be where an administrator wishes to use the same PAM configuration or passwd file for both normal and master users but use the username_filter setting to restrict which of the users is able to be a master user.&#xA;CVE-2024-23184:Having a large number of address headers (From, To, Cc, Bcc, etc.) becomes excessively CPU intensive. With 100k header lines CPU usage is already 12 seconds, and in a production environment we observed 500k header lines taking 18 minutes to parse. Since this can be triggered by external actors sending emails to a victim, this is a security issue.&#xA;CVE-2024-23185:Very large headers can cause resource exhaustion when parsing message. The message-parser normally reads reasonably sized chunks of the message. However, when it feeds them to message-header-parser, it starts building up full_value buffer out of the smaller chunks. The full_value buffer has no size limit, so large headers can cause large memory usage. It doesn t matter whether it s a single long header line, or a single header split into multiple lines. This bug exists in all Dovecot versions.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="1" name="dovecot" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-2.3.15-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/dovecot-2.3.15-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dovecot-devel" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-devel-2.3.15-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/dovecot-devel-2.3.15-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dovecot-help" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-help-2.3.15-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/dovecot-help-2.3.15-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-2.3.15-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/dovecot-2.3.15-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot-devel" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-devel-2.3.15-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/dovecot-devel-2.3.15-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot-help" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-help-2.3.15-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/dovecot-help-2.3.15-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2279</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"></reference>
		</references>
		<description>CVE-2024-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a  no overlap response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="19.u8.fos23" version="202011">
					<filename>edk2-devel-202011-19.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/edk2-devel-202011-19.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="19.u8.fos23" version="202011">
					<filename>python3-edk2-devel-202011-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-edk2-devel-202011-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="19.u8.fos23" version="202011">
					<filename>edk2-help-202011-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/edk2-help-202011-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="19.u8.fos23" version="202011">
					<filename>edk2-ovmf-202011-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/edk2-ovmf-202011-19.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="19.u8.fos23" version="202011">
					<filename>edk2-devel-202011-19.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/edk2-devel-202011-19.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="19.u8.fos23" version="202011">
					<filename>edk2-aarch64-202011-19.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/edk2-aarch64-202011-19.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2280</id>
		<title>An update for flatpak is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42472" id="CVE-2024-42472" title="CVE-2024-42472" type="cve"></reference>
		</references>
		<description>CVE-2024-42472:Flatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.14.0 and 1.15.10, a malicious or compromised Flatpak app using persistent directories could access and write files outside of what it would otherwise have access to, which is an attack on integrity and confidentiality.&#xA;When `persistent=subdir` is used in the application permissions (represented as `--persist=subdir` in the command-line interface), that means that an application which otherwise doesn&#39;t have access to the real user home directory will see an empty home directory with a writeable subdirectory `subdir`. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as `~/.var/app/$APPID/subdir`. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.&#xA;However, the application does have write access to the application directory `~/.var/app/$APPID` where this directory is stored. If the source directory for the `persistent`/`--persist` option is replaced by a symlink, then the next time the application is started, the bind mount will follow the symlink and mount whatever it points to into the sandbox.&#xA;Partial protection against this vulnerability can be provided by patching Flatpak using the patches in commits ceec2ffc and 98f79773. However, this leaves a race condition that could be exploited by two instances of a malicious app running in parallel. Closing the race condition requires updating or patching the version of bubblewrap that is used by Flatpak to add the new `--bind-fd` option using the patch and then patching Flatpak to use it. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=bwrap` (1.15.x) or `--with-system-bubblewrap=bwrap` (1.14.x or older), or a similar option, then the version of bubblewrap that needs to be patched is a system copy that is distributed separately, typically `/usr/bin/bwrap`. This configuration is the one that is typically used in Linux distributions. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=` (1.15.x) or with `--without-system-bubblewrap` (1.14.x or older), then it is the bundled version of bubblewrap that is included with Flatpak that must be patched. This is typically installed as `/usr/libexec/flatpak-bwrap`. This configuration is the default when building from source code.&#xA;For the 1.14.x stable branch, these changes are included in Flatpak 1.14.10. The bundled version of bubblewrap included in this release has been updated to 0.6.3. For the 1.15.x development branch, these changes are included in Flatpak 1.15.10. The bundled version of bubblewrap in this release is a Meson &#34;wrap&#34; subproject, which has been updated to 0.10.0. The 1.12.x and 1.10.x branches will not be updated for this vulnerability. Long-term support OS distributions should backport the individual changes into their versions of Flatpak and bubblewrap, or update to newer versions if their stability policy allows it. As a workaround, avoid using applications using the `persistent` (`--persist`) permission.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="flatpak" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-1.10.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/flatpak-1.10.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="flatpak-devel" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-devel-1.10.2-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/flatpak-devel-1.10.2-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="flatpak-help" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-help-1.10.2-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/flatpak-help-1.10.2-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flatpak" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-1.10.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/flatpak-1.10.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="flatpak-devel" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-devel-1.10.2-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/flatpak-devel-1.10.2-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2281</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-23922" id="CVE-2020-23922" title="CVE-2020-23922" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48161" id="CVE-2023-48161" title="CVE-2023-48161" type="cve"></reference>
		</references>
		<description>CVE-2020-23922:An issue was discovered in giflib through 5.1.4. DumpScreen2RGB in gif2rgb.c has a heap-based buffer over-read.&#xA;CVE-2023-48161:Buffer Overflow vulnerability in GifLib Project GifLib v.5.2.1 allows a local attacker to obtain sensitive information via the DumpSCreen2RGB function in gif2rgb.c</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="giflib" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-5.2.2-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/giflib-5.2.2-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-devel" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-devel-5.2.2-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/giflib-devel-5.2.2-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-utils" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-utils-5.2.2-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/giflib-utils-5.2.2-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="giflib-help" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-help-5.2.2-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/giflib-help-5.2.2-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-5.2.2-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/giflib-5.2.2-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-devel" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-devel-5.2.2-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/giflib-devel-5.2.2-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-utils" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-utils-5.2.2-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/giflib-utils-5.2.2-1.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2282</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
		</references>
		<description>CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-src-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-src-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2283</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
		</references>
		<description>CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-headless-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-headless-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-devel-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-devel-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-jmods-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-jmods-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-demo-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-demo-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-src-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-src-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-javadoc-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-11-openjdk-javadoc-zip-11.0.24.8-0.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-headless-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-headless-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-devel-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-devel-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-jmods-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-jmods-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-demo-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-demo-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-src-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-src-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-javadoc-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-11-openjdk-javadoc-zip-11.0.24.8-0.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2284</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
		</references>
		<description>CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-headless-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-headless-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-devel-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-devel-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-jmods-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-demo-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-demo-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-src-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-src-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-javadoc-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/java-17-openjdk-javadoc-zip-17.0.12.7-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-headless-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-headless-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-devel-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-devel-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-jmods-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-demo-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-demo-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-src-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-src-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-javadoc-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/java-17-openjdk-javadoc-zip-17.0.12.7-0.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2285</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38580" id="CVE-2024-38580" title="CVE-2024-38580" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40916" id="CVE-2024-40916" title="CVE-2024-40916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35963" id="CVE-2024-35963" title="CVE-2024-35963" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48878" id="CVE-2022-48878" title="CVE-2022-48878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38570" id="CVE-2024-38570" title="CVE-2024-38570" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42160" id="CVE-2024-42160" title="CVE-2024-42160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41087" id="CVE-2024-41087" title="CVE-2024-41087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40902" id="CVE-2024-40902" title="CVE-2024-40902" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41073" id="CVE-2024-41073" title="CVE-2024-41073" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42271" id="CVE-2024-42271" title="CVE-2024-42271" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42284" id="CVE-2024-42284" title="CVE-2024-42284" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42285" id="CVE-2024-42285" title="CVE-2024-42285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26924" id="CVE-2024-26924" title="CVE-2024-26924" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38607" id="CVE-2024-38607" title="CVE-2024-38607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37353" id="CVE-2024-37353" title="CVE-2024-37353" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52743" id="CVE-2023-52743" title="CVE-2023-52743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38582" id="CVE-2024-38582" title="CVE-2024-38582" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39467" id="CVE-2024-39467" title="CVE-2024-39467" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38586" id="CVE-2024-38586" title="CVE-2024-38586" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36489" id="CVE-2024-36489" title="CVE-2024-36489" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38579" id="CVE-2024-38579" title="CVE-2024-38579" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38554" id="CVE-2024-38554" title="CVE-2024-38554" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38546" id="CVE-2024-38546" title="CVE-2024-38546" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38637" id="CVE-2024-38637" title="CVE-2024-38637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38780" id="CVE-2024-38780" title="CVE-2024-38780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38602" id="CVE-2024-38602" title="CVE-2024-38602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48765" id="CVE-2022-48765" title="CVE-2022-48765" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38603" id="CVE-2024-38603" title="CVE-2024-38603" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39301" id="CVE-2024-39301" title="CVE-2024-39301" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38621" id="CVE-2024-38621" title="CVE-2024-38621" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38547" id="CVE-2024-38547" title="CVE-2024-38547" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39277" id="CVE-2024-39277" title="CVE-2024-39277" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39469" id="CVE-2024-39469" title="CVE-2024-39469" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26816" id="CVE-2024-26816" title="CVE-2024-26816" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34027" id="CVE-2024-34027" title="CVE-2024-34027" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48733" id="CVE-2022-48733" title="CVE-2022-48733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38558" id="CVE-2024-38558" title="CVE-2024-38558" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4458" id="CVE-2023-4458" title="CVE-2023-4458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38548" id="CVE-2024-38548" title="CVE-2024-38548" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36478" id="CVE-2024-36478" title="CVE-2024-36478" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39480" id="CVE-2024-39480" title="CVE-2024-39480" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38540" id="CVE-2024-38540" title="CVE-2024-38540" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38615" id="CVE-2024-38615" title="CVE-2024-38615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52757" id="CVE-2023-52757" title="CVE-2023-52757" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52755" id="CVE-2023-52755" title="CVE-2023-52755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39484" id="CVE-2024-39484" title="CVE-2024-39484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39472" id="CVE-2024-39472" title="CVE-2024-39472" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38598" id="CVE-2024-38598" title="CVE-2024-38598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35899" id="CVE-2024-35899" title="CVE-2024-35899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38583" id="CVE-2024-38583" title="CVE-2024-38583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35988" id="CVE-2024-35988" title="CVE-2024-35988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39489" id="CVE-2024-39489" title="CVE-2024-39489" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39487" id="CVE-2024-39487" title="CVE-2024-39487" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40905" id="CVE-2024-40905" title="CVE-2024-40905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40931" id="CVE-2024-40931" title="CVE-2024-40931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39500" id="CVE-2024-39500" title="CVE-2024-39500" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39488" id="CVE-2024-39488" title="CVE-2024-39488" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40974" id="CVE-2024-40974" title="CVE-2024-40974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47200" id="CVE-2021-47200" title="CVE-2021-47200" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40943" id="CVE-2024-40943" title="CVE-2024-40943" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52674" id="CVE-2023-52674" title="CVE-2023-52674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35904" id="CVE-2024-35904" title="CVE-2024-35904" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40984" id="CVE-2024-40984" title="CVE-2024-40984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40971" id="CVE-2024-40971" title="CVE-2024-40971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39505" id="CVE-2024-39505" title="CVE-2024-39505" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40953" id="CVE-2024-40953" title="CVE-2024-40953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52781" id="CVE-2023-52781" title="CVE-2023-52781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40972" id="CVE-2024-40972" title="CVE-2024-40972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41005" id="CVE-2024-41005" title="CVE-2024-41005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39508" id="CVE-2024-39508" title="CVE-2024-39508" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52833" id="CVE-2023-52833" title="CVE-2023-52833" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40932" id="CVE-2024-40932" title="CVE-2024-40932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39506" id="CVE-2024-39506" title="CVE-2024-39506" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40960" id="CVE-2024-40960" title="CVE-2024-40960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36939" id="CVE-2024-36939" title="CVE-2024-36939" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48666" id="CVE-2022-48666" title="CVE-2022-48666" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47432" id="CVE-2021-47432" title="CVE-2021-47432" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40983" id="CVE-2024-40983" title="CVE-2024-40983" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39499" id="CVE-2024-39499" title="CVE-2024-39499" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40945" id="CVE-2024-40945" title="CVE-2024-40945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37078" id="CVE-2024-37078" title="CVE-2024-37078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40967" id="CVE-2024-40967" title="CVE-2024-40967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40987" id="CVE-2024-40987" title="CVE-2024-40987" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40995" id="CVE-2024-40995" title="CVE-2024-40995" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38559" id="CVE-2024-38559" title="CVE-2024-38559" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38578" id="CVE-2024-38578" title="CVE-2024-38578" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41004" id="CVE-2024-41004" title="CVE-2024-41004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40929" id="CVE-2024-40929" title="CVE-2024-40929" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40941" id="CVE-2024-40941" title="CVE-2024-40941" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38618" id="CVE-2024-38618" title="CVE-2024-38618" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40968" id="CVE-2024-40968" title="CVE-2024-40968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40912" id="CVE-2024-40912" title="CVE-2024-40912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40990" id="CVE-2024-40990" title="CVE-2024-40990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40980" id="CVE-2024-40980" title="CVE-2024-40980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34777" id="CVE-2024-34777" title="CVE-2024-34777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48814" id="CVE-2022-48814" title="CVE-2022-48814" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38568" id="CVE-2024-38568" title="CVE-2024-38568" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35837" id="CVE-2024-35837" title="CVE-2024-35837" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41009" id="CVE-2024-41009" title="CVE-2024-41009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35931" id="CVE-2024-35931" title="CVE-2024-35931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39494" id="CVE-2024-39494" title="CVE-2024-39494" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41007" id="CVE-2024-41007" title="CVE-2024-41007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40947" id="CVE-2024-40947" title="CVE-2024-40947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48844" id="CVE-2022-48844" title="CVE-2022-48844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40982" id="CVE-2024-40982" title="CVE-2024-40982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39475" id="CVE-2024-39475" title="CVE-2024-39475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40956" id="CVE-2024-40956" title="CVE-2024-40956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40981" id="CVE-2024-40981" title="CVE-2024-40981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40904" id="CVE-2024-40904" title="CVE-2024-40904" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39509" id="CVE-2024-39509" title="CVE-2024-39509" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52679" id="CVE-2023-52679" title="CVE-2023-52679" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38619" id="CVE-2024-38619" title="CVE-2024-38619" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48859" id="CVE-2022-48859" title="CVE-2022-48859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40915" id="CVE-2024-40915" title="CVE-2024-40915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47205" id="CVE-2021-47205" title="CVE-2021-47205" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38611" id="CVE-2024-38611" title="CVE-2024-38611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41011" id="CVE-2024-41011" title="CVE-2024-41011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40988" id="CVE-2024-40988" title="CVE-2024-40988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42090" id="CVE-2024-42090" title="CVE-2024-42090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41069" id="CVE-2024-41069" title="CVE-2024-41069" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38627" id="CVE-2024-38627" title="CVE-2024-38627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38561" id="CVE-2024-38561" title="CVE-2024-38561" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47382" id="CVE-2021-47382" title="CVE-2021-47382" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41040" id="CVE-2024-41040" title="CVE-2024-41040" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40999" id="CVE-2024-40999" title="CVE-2024-40999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41019" id="CVE-2024-41019" title="CVE-2024-41019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40959" id="CVE-2024-40959" title="CVE-2024-40959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41041" id="CVE-2024-41041" title="CVE-2024-41041" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41077" id="CVE-2024-41077" title="CVE-2024-41077" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41080" id="CVE-2024-41080" title="CVE-2024-41080" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39471" id="CVE-2024-39471" title="CVE-2024-39471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42115" id="CVE-2024-42115" title="CVE-2024-42115" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42097" id="CVE-2024-42097" title="CVE-2024-42097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42086" id="CVE-2024-42086" title="CVE-2024-42086" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42228" id="CVE-2024-42228" title="CVE-2024-42228" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41014" id="CVE-2024-41014" title="CVE-2024-41014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41063" id="CVE-2024-41063" title="CVE-2024-41063" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42084" id="CVE-2024-42084" title="CVE-2024-42084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40961" id="CVE-2024-40961" title="CVE-2024-40961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41090" id="CVE-2024-41090" title="CVE-2024-41090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41091" id="CVE-2024-41091" title="CVE-2024-41091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41020" id="CVE-2024-41020" title="CVE-2024-41020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42068" id="CVE-2024-42068" title="CVE-2024-42068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41048" id="CVE-2024-41048" title="CVE-2024-41048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52887" id="CVE-2023-52887" title="CVE-2023-52887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42092" id="CVE-2024-42092" title="CVE-2024-42092" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41081" id="CVE-2024-41081" title="CVE-2024-41081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42161" id="CVE-2024-42161" title="CVE-2024-42161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40910" id="CVE-2024-40910" title="CVE-2024-40910" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41046" id="CVE-2024-41046" title="CVE-2024-41046" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41044" id="CVE-2024-41044" title="CVE-2024-41044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42145" id="CVE-2024-42145" title="CVE-2024-42145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41072" id="CVE-2024-41072" title="CVE-2024-41072" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41035" id="CVE-2024-41035" title="CVE-2024-41035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42155" id="CVE-2024-42155" title="CVE-2024-42155" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42129" id="CVE-2024-42129" title="CVE-2024-42129" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41023" id="CVE-2024-41023" title="CVE-2024-41023" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42080" id="CVE-2024-42080" title="CVE-2024-42080" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41097" id="CVE-2024-41097" title="CVE-2024-41097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42106" id="CVE-2024-42106" title="CVE-2024-42106" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42224" id="CVE-2024-42224" title="CVE-2024-42224" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41013" id="CVE-2024-41013" title="CVE-2024-41013" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41070" id="CVE-2024-41070" title="CVE-2024-41070" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41062" id="CVE-2024-41062" title="CVE-2024-41062" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42089" id="CVE-2024-42089" title="CVE-2024-42089" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42076" id="CVE-2024-42076" title="CVE-2024-42076" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41089" id="CVE-2024-41089" title="CVE-2024-41089" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42098" id="CVE-2024-42098" title="CVE-2024-42098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42077" id="CVE-2024-42077" title="CVE-2024-42077" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39497" id="CVE-2024-39497" title="CVE-2024-39497" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42096" id="CVE-2024-42096" title="CVE-2024-42096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41079" id="CVE-2024-41079" title="CVE-2024-41079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42101" id="CVE-2024-42101" title="CVE-2024-42101" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42162" id="CVE-2024-42162" title="CVE-2024-42162" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42124" id="CVE-2024-42124" title="CVE-2024-42124" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42094" id="CVE-2024-42094" title="CVE-2024-42094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41012" id="CVE-2024-41012" title="CVE-2024-41012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42093" id="CVE-2024-42093" title="CVE-2024-42093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52888" id="CVE-2023-52888" title="CVE-2023-52888" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41078" id="CVE-2024-41078" title="CVE-2024-41078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41027" id="CVE-2024-41027" title="CVE-2024-41027" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47582" id="CVE-2021-47582" title="CVE-2021-47582" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41034" id="CVE-2024-41034" title="CVE-2024-41034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42157" id="CVE-2024-42157" title="CVE-2024-42157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48827" id="CVE-2022-48827" title="CVE-2022-48827" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42128" id="CVE-2024-42128" title="CVE-2024-42128" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40942" id="CVE-2024-40942" title="CVE-2024-40942" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42154" id="CVE-2024-42154" title="CVE-2024-42154" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41065" id="CVE-2024-41065" title="CVE-2024-41065" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42095" id="CVE-2024-42095" title="CVE-2024-42095" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42114" id="CVE-2024-42114" title="CVE-2024-42114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42102" id="CVE-2024-42102" title="CVE-2024-42102" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42225" id="CVE-2024-42225" title="CVE-2024-42225" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41042" id="CVE-2024-41042" title="CVE-2024-41042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42247" id="CVE-2024-42247" title="CVE-2024-42247" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42223" id="CVE-2024-42223" title="CVE-2024-42223" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42246" id="CVE-2024-42246" title="CVE-2024-42246" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42244" id="CVE-2024-42244" title="CVE-2024-42244" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41092" id="CVE-2024-41092" title="CVE-2024-41092" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42087" id="CVE-2024-42087" title="CVE-2024-42087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42143" id="CVE-2024-42143" title="CVE-2024-42143" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42229" id="CVE-2024-42229" title="CVE-2024-42229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42156" id="CVE-2024-42156" title="CVE-2024-42156" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35840" id="CVE-2024-35840" title="CVE-2024-35840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36971" id="CVE-2024-36971" title="CVE-2024-36971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37356" id="CVE-2024-37356" title="CVE-2024-37356" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35879" id="CVE-2024-35879" title="CVE-2024-35879" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39362" id="CVE-2024-39362" title="CVE-2024-39362" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27415" id="CVE-2024-27415" title="CVE-2024-27415" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35839" id="CVE-2024-35839" title="CVE-2024-35839" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35819" id="CVE-2024-35819" title="CVE-2024-35819" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47366" id="CVE-2021-47366" title="CVE-2021-47366" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36968" id="CVE-2024-36968" title="CVE-2024-36968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47469" id="CVE-2021-47469" title="CVE-2021-47469" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38588" id="CVE-2024-38588" title="CVE-2024-38588" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47599" id="CVE-2021-47599" title="CVE-2021-47599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38623" id="CVE-2024-38623" title="CVE-2024-38623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26921" id="CVE-2024-26921" title="CVE-2024-26921" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26592" id="CVE-2024-26592" title="CVE-2024-26592" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38556" id="CVE-2024-38556" title="CVE-2024-38556" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48744" id="CVE-2022-48744" title="CVE-2022-48744" type="cve"></reference>
		</references>
		<description>CVE-2024-38580:In the Linux kernel, the following vulnerability has been resolved:&#xA;epoll: be better about file lifetimes&#xA;epoll can call out to vfs_poll() with a file pointer that may race with&#xA;the last &#39;fput()&#39;. That would make f_count go down to zero, and while&#xA;the ep-&gt;mtx locking means that the resulting file pointer tear-down will&#xA;be blocked until the poll returns, it means that f_count is already&#xA;dead, and any use of it won&#39;t actually get a reference to the file any&#xA;more: it&#39;s dead regardless.&#xA;Make sure we have a valid ref on the file pointer before we call down to&#xA;vfs_poll() from the epoll routines.&#xA;CVE-2024-40916:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found&#xA;When reading EDID fails and driver reports no modes available, the DRM&#xA;core adds an artificial 1024x786 mode to the connector. Unfortunately&#xA;some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not&#xA;able to drive such mode, so report a safe 640x480 mode instead of nothing&#xA;in case of the EDID reading failure.&#xA;This fixes the following issue observed on Trats2 board since commit&#xA;13d5b040363c (&#34;drm/exynos: do not return negative values from .get_modes()&#34;):&#xA;[drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations&#xA;exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops)&#xA;exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)&#xA;exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b)&#xA;exynos-drm exynos-drm: bound 11c80000.dsi (ops exynos_dsi_component_ops)&#xA;exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)&#xA;[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1&#xA;exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not reach steady state&#xA;panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c&#xA;exynos-mixer 12c10000.mixer: timeout waiting for VSYNC&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8&#xA;[CRTC:70:crtc-1] vblank wait timed out&#xA;Modules linked in:&#xA;CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913&#xA;Hardware name: Samsung Exynos (Flattened Device Tree)&#xA;Workqueue: events_unbound deferred_probe_work_func&#xA;Call trace:&#xA; unwind_backtrace from show_stack+0x10/0x14&#xA; show_stack from dump_stack_lvl+0x68/0x88&#xA; dump_stack_lvl from __warn+0x7c/0x1c4&#xA; __warn from warn_slowpath_fmt+0x11c/0x1a8&#xA; warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8&#xA; drm_atomic_helper_wait_for_vblanks.part.0 from drm_atomic_helper_commit_tail_rpm+0x7c/0x8c&#xA; drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184&#xA; commit_tail from drm_atomic_helper_commit+0x168/0x190&#xA; drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0&#xA; drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c&#xA; drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1cc&#xA; drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40&#xA; drm_client_modeset_commit from __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4&#xA; __drm_fb_helper_restore_fbdev_mode_unlocked from drm_fb_helper_set_par+0x2c/0x3c&#xA; drm_fb_helper_set_par from fbcon_init+0x3d8/0x550&#xA; fbcon_init from visual_init+0xc0/0x108&#xA; visual_init from do_bind_con_driver+0x1b8/0x3a4&#xA; do_bind_con_driver from do_take_over_console+0x140/0x1ec&#xA; do_take_over_console from do_fbcon_takeover+0x70/0xd0&#xA; do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac&#xA; fbcon_fb_registered from register_framebuffer+0x190/0x21c&#xA; register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574&#xA; __drm_fb_helper_initial_config_and_unlock from exynos_drm_fbdev_client_hotplug+0x6c/0xb0&#xA; exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94&#xA; drm_client_register from exynos_drm_bind+0x160/0x190&#xA; exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8&#xA; try_to_bring_up_aggregate_device from __component_add+0xb0/0x170&#xA; __component_add from mixer_probe+0x74/0xcc&#xA; mixer_probe from platform_probe+0x5c/0xb8&#xA; platform_probe from really_probe+0xe0/0x3d8&#xA; really_probe from __driver_probe_device+0x9c/0x1e4&#xA; __driver_probe_device from driver_probe_device+0x30/0xc0&#xA; driver_probe_device from __device_attach_driver+0xa8/0x120&#xA; __device_attach_driver from bus_for_each_drv+0x80/0xcc&#xA; bus_for_each_drv from __device_attach+0xac/0x1fc&#xA; __device_attach from bus_probe_device+0x8c/0x90&#xA; bus_probe_device from deferred_probe_work_func+0&#xA;---truncated---&#xA;CVE-2024-35963:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: hci_sock: Fix not validating setsockopt user input&#xA;Check user input length before copying data.&#xA;CVE-2022-48878:In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Fix driver shutdown on closed serdev The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()). The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth: Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac KASAN report: BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1 CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194&#xA;CVE-2024-38570:In the Linux kernel, the following vulnerability has been resolved:&#xA;gfs2: Fix potential glock use-after-free on unmount&#xA;When a DLM lockspace is released and there ares still locks in that&#xA;lockspace, DLM will unlock those locks automatically.  Commit&#xA;fb6791d100d1b started exploiting this behavior to speed up filesystem&#xA;unmount: gfs2 would simply free glocks it didn&#39;t want to unlock and then&#xA;release the lockspace.  This didn&#39;t take the bast callbacks for&#xA;asynchronous lock contention notifications into account, which remain&#xA;active until until a lock is unlocked or its lockspace is released.&#xA;To prevent those callbacks from accessing deallocated objects, put the&#xA;glocks that should not be unlocked on the sd_dead_glocks list, release&#xA;the lockspace, and only then free those glocks.&#xA;As an additional measure, ignore unexpected ast and bast callbacks if&#xA;the receiving glock is dead.&#xA;CVE-2024-42160:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: check validation of fault attrs in f2fs_build_fault_attr()&#xA;- It missed to check validation of fault attrs in parse_options(),&#xA;let&#39;s fix to add check condition in f2fs_build_fault_attr().&#xA;- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.&#xA;CVE-2024-41087:In the Linux kernel, the following vulnerability has been resolved:&#xA;ata: libata-core: Fix double free on error&#xA;If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump&#xA;to the err_out label, which will call devres_release_group().&#xA;devres_release_group() will trigger a call to ata_host_release().&#xA;ata_host_release() calls kfree(host), so executing the kfree(host) in&#xA;ata_host_alloc() will lead to a double free:&#xA;kernel BUG at mm/slub.c:553!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014&#xA;RIP: 0010:kfree+0x2cf/0x2f0&#xA;Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da&#xA;RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246&#xA;RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320&#xA;RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0&#xA;RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780&#xA;R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006&#xA;FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body.cold+0x19/0x27&#xA; ? die+0x2e/0x50&#xA; ? do_trap+0xca/0x110&#xA; ? do_error_trap+0x6a/0x90&#xA; ? kfree+0x2cf/0x2f0&#xA; ? exc_invalid_op+0x50/0x70&#xA; ? kfree+0x2cf/0x2f0&#xA; ? asm_exc_invalid_op+0x1a/0x20&#xA; ? ata_host_alloc+0xf5/0x120 [libata]&#xA; ? ata_host_alloc+0xf5/0x120 [libata]&#xA; ? kfree+0x2cf/0x2f0&#xA; ata_host_alloc+0xf5/0x120 [libata]&#xA; ata_host_alloc_pinfo+0x14/0xa0 [libata]&#xA; ahci_init_one+0x6c9/0xd20 [ahci]&#xA;Ensure that we will not call kfree(host) twice, by performing the kfree()&#xA;only if the devres_open_group() call failed.&#xA;CVE-2024-40902:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: xattr: fix buffer overflow for invalid xattr&#xA;When an xattr size is not what is expected, it is printed out to the&#xA;kernel log in hex format as a form of debugging.  But when that xattr&#xA;size is bigger than the expected size, printing it out can cause an&#xA;access off the end of the buffer.&#xA;Fix this all up by properly restricting the size of the debug hex dump&#xA;in the kernel log.&#xA;CVE-2024-41073:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvme: avoid double free special payload&#xA;If a discard request needs to be retried, and that retry may fail before&#xA;a new special payload is added, a double free will result. Clear the&#xA;RQF_SPECIAL_LOAD when the request is cleaned.&#xA;CVE-2024-42271:In the Linux kernel, the following vulnerability has been resolved:net/iucv: fix use after free in iucv_sock_close()iucv_sever_path() is called from process context and from bh context.iucv-&gt;path is used as indicator whether somebody else is taking care ofsevering the path (or it is already removed / never existed).This needs to be done with atomic compare and swap, otherwise there is asmall window where iucv_sock_close() will try to work with a path that hasalready been severed and freed by iucv_callback_connrej() called byiucv_tasklet_fn().Example:[452744.123844] Call Trace:[452744.123845] ([&lt;0000001e87f03880&gt;] 0x1e87f03880)[452744.123966]  [&lt;00000000d593001e&gt;] iucv_path_sever+0x96/0x138[452744.124330]  [&lt;000003ff801ddbca&gt;] iucv_sever_path+0xc2/0xd0 [af_iucv][452744.124336]  [&lt;000003ff801e01b6&gt;] iucv_sock_close+0xa6/0x310 [af_iucv][452744.124341]  [&lt;000003ff801e08cc&gt;] iucv_sock_release+0x3c/0xd0 [af_iucv][452744.124345]  [&lt;00000000d574794e&gt;] __sock_release+0x5e/0xe8[452744.124815]  [&lt;00000000d5747a0c&gt;] sock_close+0x34/0x48[452744.124820]  [&lt;00000000d5421642&gt;] __fput+0xba/0x268[452744.124826]  [&lt;00000000d51b382c&gt;] task_work_run+0xbc/0xf0[452744.124832]  [&lt;00000000d5145710&gt;] do_notify_resume+0x88/0x90[452744.124841]  [&lt;00000000d5978096&gt;] system_call+0xe2/0x2c8[452744.125319] Last Breaking-Event-Address:[452744.125321]  [&lt;00000000d5930018&gt;] iucv_path_sever+0x90/0x138[452744.125324][452744.125325] Kernel panic - not syncing: Fatal exception in interruptNote that bh_lock_sock() is not serializing the tasklet context againstprocess context, because the check for sock_owned_by_user() andcorresponding handling is missing.Ideas for a future clean-up patch:A) Correct usage of bh_lock_sock() in tasklet context, as described inRe-enqueue, if needed. This may require adding return values to thetasklet functions and thus changes to all users of iucv.B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.&#xA;CVE-2024-42284:In the Linux kernel, the following vulnerability has been resolved:tipc: Return non-zero value from tipc_udp_addr2str() on errortipc_udp_addr2str() should return non-zero value if the UDP mediaaddress is invalid. Otherwise, a buffer overflow access can occur intipc_media_addr_printf(). Fix this by returning 1 on an invalid UDPmedia address.&#xA;CVE-2024-42285:In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix a use-after-free related to destroying CM IDsiw_conn_req_handler() associates a new struct rdma_id_private (conn_id) withan existing struct iw_cm_id (cm_id) as follows:        conn_id-&gt;cm_id.iw = cm_id;        cm_id-&gt;context = conn_id;        cm_id-&gt;cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Makesure that cm_work_handler() does not trigger a use-after-free by onlyfreeing of the struct rdma_id_private after all pending work has finished.&#xA;CVE-2024-26924:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_set_pipapo: do not free live element&#xA;Pablo reports a crash with large batches of elements with a&#xA;back-to-back add/remove pattern.  Quoting Pablo:&#xA;  add_elem(&#34;00000000&#34;) timeout 100 ms&#xA;  ...&#xA;  add_elem(&#34;0000000X&#34;) timeout 100 ms&#xA;  del_elem(&#34;0000000X&#34;) &lt;---------------- delete one that was just added&#xA;  ...&#xA;  add_elem(&#34;00005000&#34;) timeout 100 ms&#xA;  1) nft_pipapo_remove() removes element 0000000X&#xA;  Then, KASAN shows a splat.&#xA;Looking at the remove function there is a chance that we will drop a&#xA;rule that maps to a non-deactivated element.&#xA;Removal happens in two steps, first we do a lookup for key k and return the&#xA;to-be-removed element and mark it as inactive in the next generation.&#xA;Then, in a second step, the element gets removed from the set/map.&#xA;The _remove function does not work correctly if we have more than one&#xA;element that share the same key.&#xA;This can happen if we insert an element into a set when the set already&#xA;holds an element with same key, but the element mapping to the existing&#xA;key has timed out or is not active in the next generation.&#xA;In such case its possible that removal will unmap the wrong element.&#xA;If this happens, we will leak the non-deactivated element, it becomes&#xA;unreachable.&#xA;The element that got deactivated (and will be freed later) will&#xA;remain reachable in the set data structure, this can result in&#xA;a crash when such an element is retrieved during lookup (stale&#xA;pointer).&#xA;Add a check that the fully matching key does in fact map to the element&#xA;that we have marked as inactive in the deactivation step.&#xA;If not, we need to continue searching.&#xA;Add a bug/warn trap at the end of the function as well, the remove&#xA;function must not ever be called with an invisible/unreachable/non-existent&#xA;element.&#xA;v2: avoid uneeded temporary variable (Stefano)&#xA;CVE-2024-38607:In the Linux kernel, the following vulnerability has been resolved:&#xA;macintosh/via-macii: Fix &#34;BUG: sleeping function called from invalid context&#34;&#xA;The via-macii ADB driver calls request_irq() after disabling hard&#xA;interrupts. But disabling interrupts isn&#39;t necessary here because the&#xA;VIA shift register interrupt was masked during VIA1 initialization.&#xA;CVE-2024-37353:In the Linux kernel, the following vulnerability has been resolved:&#xA;virtio: delete vq in vp_find_vqs_msix() when request_irq() fails&#xA;When request_irq() fails, error path calls vp_del_vqs(). There, as vq is&#xA;present in the list, free_irq() is called for the same vector. That&#xA;causes following splat:&#xA;[    0.414355] Trying to free already-free IRQ 27&#xA;[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0&#xA;[    0.414510] Modules linked in:&#xA;[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27&#xA;[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014&#xA;[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0&#xA;[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 &lt;0f&gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40&#xA;[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086&#xA;[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000&#xA;[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001&#xA;[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001&#xA;[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760&#xA;[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600&#xA;[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000&#xA;[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0&#xA;[    0.414540] Call Trace:&#xA;[    0.414540]  &lt;TASK&gt;&#xA;[    0.414540]  ? __warn+0x80/0x120&#xA;[    0.414540]  ? free_irq+0x1a1/0x2d0&#xA;[    0.414540]  ? report_bug+0x164/0x190&#xA;[    0.414540]  ? handle_bug+0x3b/0x70&#xA;[    0.414540]  ? exc_invalid_op+0x17/0x70&#xA;[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[    0.414540]  ? free_irq+0x1a1/0x2d0&#xA;[    0.414540]  vp_del_vqs+0xc1/0x220&#xA;[    0.414540]  vp_find_vqs_msix+0x305/0x470&#xA;[    0.414540]  vp_find_vqs+0x3e/0x1a0&#xA;[    0.414540]  vp_modern_find_vqs+0x1b/0x70&#xA;[    0.414540]  init_vqs+0x387/0x600&#xA;[    0.414540]  virtnet_probe+0x50a/0xc80&#xA;[    0.414540]  virtio_dev_probe+0x1e0/0x2b0&#xA;[    0.414540]  really_probe+0xc0/0x2c0&#xA;[    0.414540]  ? __pfx___driver_attach+0x10/0x10&#xA;[    0.414540]  __driver_probe_device+0x73/0x120&#xA;[    0.414540]  driver_probe_device+0x1f/0xe0&#xA;[    0.414540]  __driver_attach+0x88/0x180&#xA;[    0.414540]  bus_for_each_dev+0x85/0xd0&#xA;[    0.414540]  bus_add_driver+0xec/0x1f0&#xA;[    0.414540]  driver_register+0x59/0x100&#xA;[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10&#xA;[    0.414540]  virtio_net_driver_init+0x90/0xb0&#xA;[    0.414540]  do_one_initcall+0x58/0x230&#xA;[    0.414540]  kernel_init_freeable+0x1a3/0x2d0&#xA;[    0.414540]  ? __pfx_kernel_init+0x10/0x10&#xA;[    0.414540]  kernel_init+0x1a/0x1c0&#xA;[    0.414540]  ret_from_fork+0x31/0x50&#xA;[    0.414540]  ? __pfx_kernel_init+0x10/0x10&#xA;[    0.414540]  ret_from_fork_asm+0x1a/0x30&#xA;[    0.414540]  &lt;/TASK&gt;&#xA;Fix this by calling deleting the current vq when request_irq() fails.&#xA;CVE-2023-52743:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: Do not use WQ_MEM_RECLAIM flag for workqueue&#xA;When both ice and the irdma driver are loaded, a warning in&#xA;check_flush_dependency is being triggered. This is due to ice driver&#xA;workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one&#xA;is not.&#xA;According to kernel documentation, this flag should be set if the&#xA;workqueue will be involved in the kernel&#39;s memory reclamation flow.&#xA;Since it is not, there is no need for the ice driver&#39;s WQ to have this&#xA;flag set so remove it.&#xA;Example trace:&#xA;[  +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0&#xA;[  +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0&#xA;[  +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha&#xA;in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel&#xA;_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1&#xA;0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_&#xA;core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs&#xA;ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter&#xA;acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba&#xA;ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse&#xA;[  +0.000161]  [last unloaded: bonding]&#xA;[  +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S                 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1&#xA;[  +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020&#xA;[  +0.000003] Workqueue: ice ice_service_task [ice]&#xA;[  +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0&#xA;[  +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08&#xA;9f e8 bb d3 07 01 &lt;0f&gt; 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06&#xA;[  +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282&#xA;[  +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000&#xA;[  +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80&#xA;[  +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112&#xA;[  +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000&#xA;[  +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400&#xA;[  +0.000004] FS:  0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000&#xA;[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0&#xA;[  +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  +0.000002] PKRU: 55555554&#xA;[  +0.000003] Call Trace:&#xA;[  +0.000002]  &lt;TASK&gt;&#xA;[  +0.000003]  __flush_workqueue+0x203/0x840&#xA;[  +0.000006]  ? mutex_unlock+0x84/0xd0&#xA;[  +0.000008]  ? __pfx_mutex_unlock+0x10/0x10&#xA;[  +0.000004]  ? __pfx___flush_workqueue+0x10/0x10&#xA;[  +0.000006]  ? mutex_lock+0xa3/0xf0&#xA;[  +0.000005]  ib_cache_cleanup_one+0x39/0x190 [ib_core]&#xA;[  +0.000174]  __ib_unregister_device+0x84/0xf0 [ib_core]&#xA;[  +0.000094]  ib_unregister_device+0x25/0x30 [ib_core]&#xA;[  +0.000093]  irdma_ib_unregister_device+0x97/0xc0 [irdma]&#xA;[  +0.000064]  ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]&#xA;[  +0.000059]  ? up_write+0x5c/0x90&#xA;[  +0.000005]  irdma_remove+0x36/0x90 [irdma]&#xA;[  +0.000062]  auxiliary_bus_remove+0x32/0x50&#xA;[  +0.000007]  device_r&#xA;---truncated---&#xA;CVE-2024-38582:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential hang in nilfs_detach_log_writer()&#xA;Syzbot has reported a potential hang in nilfs_detach_log_writer() called&#xA;during nilfs2 unmount.&#xA;Analysis revealed that this is because nilfs_segctor_sync(), which&#xA;synchronizes with the log writer thread, can be called after&#xA;nilfs_segctor_destroy() terminates that thread, as shown in the call trace&#xA;below:&#xA;nilfs_detach_log_writer&#xA;  nilfs_segctor_destroy&#xA;    nilfs_segctor_kill_thread  --&gt; Shut down log writer thread&#xA;    flush_work&#xA;      nilfs_iput_work_func&#xA;        nilfs_dispose_list&#xA;          iput&#xA;            nilfs_evict_inode&#xA;              nilfs_transaction_commit&#xA;                nilfs_construct_segment (if inode needs sync)&#xA;                  nilfs_segctor_sync  --&gt; Attempt to synchronize with&#xA;                                          log writer thread&#xA;                           *** DEADLOCK ***&#xA;Fix this issue by changing nilfs_segctor_sync() so that the log writer&#xA;thread returns normally without synchronizing after it terminates, and by&#xA;forcing tasks that are already waiting to complete once after the thread&#xA;terminates.&#xA;The skipped inode metadata flushout will then be processed together in the&#xA;subsequent cleanup work in nilfs_segctor_destroy().&#xA;CVE-2024-39467:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()&#xA;syzbot reports a kernel bug as below:&#xA;F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4&#xA;==================================================================&#xA;BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600&#xA;Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076&#xA;CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0x169/0x550 mm/kasan/report.c:488&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA; f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]&#xA; current_nat_addr fs/f2fs/node.h:213 [inline]&#xA; f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600&#xA; f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]&#xA; f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925&#xA; ioctl_fiemap fs/ioctl.c:220 [inline]&#xA; do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838&#xA; __do_sys_ioctl fs/ioctl.c:902 [inline]&#xA; __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;The root cause is we missed to do sanity check on i_xattr_nid during&#xA;f2fs_iget(), so that in fiemap() path, current_nat_addr() will access&#xA;nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering&#xA;kasan bug report, fix it.&#xA;CVE-2024-38586:In the Linux kernel, the following vulnerability has been resolved:&#xA;r8169: Fix possible ring buffer corruption on fragmented Tx packets.&#xA;An issue was found on the RTL8125b when transmitting small fragmented&#xA;packets, whereby invalid entries were inserted into the transmit ring&#xA;buffer, subsequently leading to calls to dma_unmap_single() with a null&#xA;address.&#xA;This was caused by rtl8169_start_xmit() not noticing changes to nr_frags&#xA;which may occur when small packets are padded (to work around hardware&#xA;quirks) in rtl8169_tso_csum_v2().&#xA;To fix this, postpone inspecting nr_frags until after any padding has been&#xA;applied.&#xA;CVE-2024-36489:In the Linux kernel, the following vulnerability has been resolved:&#xA;tls: fix missing memory barrier in tls_init&#xA;In tls_init(), a write memory barrier is missing, and store-store&#xA;reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.&#xA;CPU0                               CPU1&#xA;-----                              -----&#xA;// In tls_init()&#xA;// In tls_ctx_create()&#xA;ctx = kzalloc()&#xA;ctx-&gt;sk_proto = READ_ONCE(sk-&gt;sk_prot) -(1)&#xA;// In update_sk_prot()&#xA;WRITE_ONCE(sk-&gt;sk_prot, tls_prots)     -(2)&#xA;                                   // In sock_common_setsockopt()&#xA;                                   READ_ONCE(sk-&gt;sk_prot)-&gt;setsockopt()&#xA;                                   // In tls_{setsockopt,getsockopt}()&#xA;                                   ctx-&gt;sk_proto-&gt;setsockopt()    -(3)&#xA;In the above scenario, when (1) and (2) are reordered, (3) can observe&#xA;the NULL value of ctx-&gt;sk_proto, causing NULL dereference.&#xA;To fix it, we rely on rcu_assign_pointer() which implies the release&#xA;barrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto is&#xA;initialized, we can ensure that ctx-&gt;sk_proto are visible when&#xA;changing sk-&gt;sk_prot.&#xA;CVE-2024-38579:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: bcm - Fix pointer arithmetic&#xA;In spu2_dump_omd() value of ptr is increased by ciph_key_len&#xA;instead of hash_iv_len which could lead to going beyond the&#xA;buffer boundaries.&#xA;Fix this bug by changing ciph_key_len to hash_iv_len.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-38554:In the Linux kernel, the following vulnerability has been resolved:&#xA;ax25: Fix reference count leak issue of net_device&#xA;There is a reference count leak issue of the object &#34;net_device&#34; in&#xA;ax25_dev_device_down(). When the ax25 device is shutting down, the&#xA;ax25_dev_device_down() drops the reference count of net_device one&#xA;or zero times depending on if we goto unlock_put or not, which will&#xA;cause memory leak.&#xA;In order to solve the above issue, decrease the reference count of&#xA;net_device after dev-&gt;ax25_ptr is set to null.&#xA;CVE-2024-38546:In the Linux kernel, the following vulnerability has been resolved:drm: vc4: Fix possible null pointer dereferenceIn vc4_hdmi_audio_init() of_get_address() may returnNULL which is later dereferenced. Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-38637:In the Linux kernel, the following vulnerability has been resolved:&#xA;greybus: lights: check return of get_channel_from_mode&#xA;If channel for the given node is not found we return null from&#xA;get_channel_from_mode. Make sure we validate the return pointer&#xA;before using it in two of the missing places.&#xA;This was originally reported in [0]:&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru&#xA;CVE-2024-38780:In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don t enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ( dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context ) by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().&#xA;CVE-2024-38602:In the Linux kernel, the following vulnerability has been resolved:&#xA;ax25: Fix reference count leak issues of ax25_dev&#xA;The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference&#xA;count leak issue of the object &#34;ax25_dev&#34;.&#xA;Memory leak issue in ax25_addr_ax25dev():&#xA;The reference count of the object &#34;ax25_dev&#34; can be increased multiple&#xA;times in ax25_addr_ax25dev(). This will cause a memory leak.&#xA;Memory leak issues in ax25_dev_device_down():&#xA;The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and&#xA;then increase the reference count when ax25_dev is added to ax25_dev_list.&#xA;As a result, the reference count of ax25_dev is 2. But when the device is&#xA;shutting down. The ax25_dev_device_down() drops the reference count once&#xA;or twice depending on if we goto unlock_put or not, which will cause&#xA;memory leak.&#xA;As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer&#xA;to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the&#xA;issue of ax25_dev_device_down(), increase the reference count of ax25_dev&#xA;once in ax25_dev_device_up() and decrease the reference count of ax25_dev&#xA;after it is removed from the ax25_dev_list.&#xA;CVE-2022-48765:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: LAPIC: Also cancel preemption timer during SET_LAPIC&#xA;The below warning is splatting during guest reboot.&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]&#xA;  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5&#xA;  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   kvm_vcpu_ioctl+0x279/0x710 [kvm]&#xA;   __x64_sys_ioctl+0x83/0xb0&#xA;   do_syscall_64+0x3b/0xc0&#xA;   entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;  RIP: 0033:0x7fd39797350b&#xA;This can be triggered by not exposing tsc-deadline mode and doing a reboot in&#xA;the guest. The lapic_shutdown() function which is called in sys_reboot path&#xA;will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears&#xA;APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode&#xA;switch between tsc-deadline and oneshot/periodic, which can result in preemption&#xA;timer be cancelled in apic_update_lvtt(). However, We can&#39;t depend on this when&#xA;not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption&#xA;timer. Qemu will synchronise states around reset, let&#39;s cancel preemption timer&#xA;under KVM_SET_LAPIC.&#xA;CVE-2024-38603:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()&#xA;pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()&#xA;fails, the irq vector is not freed, which leads to a memory leak.&#xA;Replace the devm_add_action with devm_add_action_or_reset to ensure&#xA;the irq vector can be destroyed when it fails.&#xA;CVE-2024-39301:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/9p: fix uninit-value in p9_client_rpc()&#xA;Syzbot with the help of KMSAN reported the following error:&#xA;BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]&#xA;BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754&#xA; trace_9p_client_res include/trace/events/9p.h:146 [inline]&#xA; p9_client_rpc+0x1314/0x1340 net/9p/client.c:754&#xA; p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031&#xA; v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410&#xA; v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122&#xA; legacy_get_tree+0x114/0x290 fs/fs_context.c:662&#xA; vfs_get_tree+0xa7/0x570 fs/super.c:1797&#xA; do_new_mount+0x71f/0x15e0 fs/namespace.c:3352&#xA; path_mount+0x742/0x1f20 fs/namespace.c:3679&#xA; do_mount fs/namespace.c:3692 [inline]&#xA; __do_sys_mount fs/namespace.c:3898 [inline]&#xA; __se_sys_mount+0x725/0x810 fs/namespace.c:3875&#xA; __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;Uninit was created at:&#xA; __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598&#xA; __alloc_pages_node include/linux/gfp.h:238 [inline]&#xA; alloc_pages_node include/linux/gfp.h:261 [inline]&#xA; alloc_slab_page mm/slub.c:2175 [inline]&#xA; allocate_slab mm/slub.c:2338 [inline]&#xA; new_slab+0x2de/0x1400 mm/slub.c:2391&#xA; ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525&#xA; __slab_alloc mm/slub.c:3610 [inline]&#xA; __slab_alloc_node mm/slub.c:3663 [inline]&#xA; slab_alloc_node mm/slub.c:3835 [inline]&#xA; kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852&#xA; p9_tag_alloc net/9p/client.c:278 [inline]&#xA; p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641&#xA; p9_client_rpc+0x27e/0x1340 net/9p/client.c:688&#xA; p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031&#xA; v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410&#xA; v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122&#xA; legacy_get_tree+0x114/0x290 fs/fs_context.c:662&#xA; vfs_get_tree+0xa7/0x570 fs/super.c:1797&#xA; do_new_mount+0x71f/0x15e0 fs/namespace.c:3352&#xA; path_mount+0x742/0x1f20 fs/namespace.c:3679&#xA; do_mount fs/namespace.c:3692 [inline]&#xA; __do_sys_mount fs/namespace.c:3898 [inline]&#xA; __se_sys_mount+0x725/0x810 fs/namespace.c:3875&#xA; __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;If p9_check_errors() fails early in p9_client_rpc(), req-&gt;rc.tag&#xA;will not be properly initialized. However, trace_9p_client_res()&#xA;ends up trying to print it out anyway before p9_client_rpc()&#xA;finishes.&#xA;Fix this issue by assigning default values to p9_fcall fields&#xA;such as &#39;tag&#39; and (just in case KMSAN unearths something new) &#39;id&#39;&#xA;during the tag allocation stage.&#xA;CVE-2024-38621:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: stk1160: fix bounds checking in stk1160_copy_video()&#xA;The subtract in this condition is reversed.  The -&gt;length is the length&#xA;of the buffer.  The -&gt;bytesused is how many bytes we have copied thus&#xA;far.  When the condition is reversed that means the result of the&#xA;subtraction is always negative but since it&#39;s unsigned then the result&#xA;is a very high positive value.  That means the overflow check is never&#xA;true.&#xA;Additionally, the -&gt;bytesused doesn&#39;t actually work for this purpose&#xA;because we&#39;re not writing to &#34;buf-&gt;mem + buf-&gt;bytesused&#34;.  Instead, the&#xA;math to calculate the destination where we are writing is a bit&#xA;involved.  You calculate the number of full lines already written,&#xA;multiply by two, skip a line if necessary so that we start on an odd&#xA;numbered line, and add the offset into the line.&#xA;To fix this buffer overflow, just take the actual destination where we&#xA;are writing, if the offset is already out of bounds print an error and&#xA;return.  Otherwise, write up to buf-&gt;length bytes.&#xA;CVE-2024-38547:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries&#xA;The allocation failure of mycs-&gt;yuv_scaler_binary in load_video_binaries()&#xA;is followed with a dereference of mycs-&gt;yuv_scaler_binary after the&#xA;following call chain:&#xA;sh_css_pipe_load_binaries()&#xA;  |-&gt; load_video_binaries(mycs-&gt;yuv_scaler_binary == NULL)&#xA;  |&#xA;  |-&gt; sh_css_pipe_unload_binaries()&#xA;        |-&gt; unload_video_binaries()&#xA;In unload_video_binaries(), it calls to ia_css_binary_unload with argument&#xA;&amp;pipe-&gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the&#xA;same memory slot as mycs-&gt;yuv_scaler_binary. Thus, a null-pointer&#xA;dereference is triggered.&#xA;CVE-2024-39277:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma-mapping: benchmark: handle NUMA_NO_NODE correctly&#xA;cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark()&#xA;resulting in the following sanitizer report:&#xA;UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28&#xA;index -1 is out of range for type &#39;cpumask [64][1]&#39;&#xA;CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;dump_stack_lvl (lib/dump_stack.c:117)&#xA;ubsan_epilogue (lib/ubsan.c:232)&#xA;__ubsan_handle_out_of_bounds (lib/ubsan.c:429)&#xA;cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline]&#xA;do_map_benchmark (kernel/dma/map_benchmark.c:104)&#xA;map_benchmark_ioctl (kernel/dma/map_benchmark.c:246)&#xA;full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)&#xA;__x64_sys_ioctl (fs/ioctl.c:890)&#xA;do_syscall_64 (arch/x86/entry/common.c:83)&#xA;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;Use cpumask_of_node() in place when binding a kernel thread to a cpuset&#xA;of a particular node.&#xA;Note that the provided node id is checked inside map_benchmark_ioctl().&#xA;It&#39;s just a NUMA_NO_NODE case which is not handled properly later.&#xA;Found by Linux Verification Center (linuxtesting.org).&#xA;CVE-2024-39469:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors&#xA;The error handling in nilfs_empty_dir() when a directory folio/page read&#xA;fails is incorrect, as in the old ext2 implementation, and if the&#xA;folio/page cannot be read or nilfs_check_folio() fails, it will falsely&#xA;determine the directory as empty and corrupt the file system.&#xA;In addition, since nilfs_empty_dir() does not immediately return on a&#xA;failed folio/page read, but continues to loop, this can cause a long loop&#xA;with I/O if i_size of the directory&#39;s inode is also corrupted, causing the&#xA;log writer thread to wait and hang, as reported by syzbot.&#xA;Fix these issues by making nilfs_empty_dir() immediately return a false&#xA;value (0) if it fails to get a directory folio/page.&#xA;CVE-2024-26816:In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the &#34;startup_xen&#34; entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.&#xA;CVE-2024-34027:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock&#xA;It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock&#xA;to avoid racing with checkpoint, otherwise, filesystem metadata including&#xA;blkaddr in dnode, inode fields and .total_valid_block_count may be&#xA;corrupted after SPO case.&#xA;CVE-2022-48733:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix use-after-free after failure to create a snapshot&#xA;At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and&#xA;then attach it to the transaction&#39;s list of pending snapshots. After that&#xA;we call btrfs_commit_transaction(), and if that returns an error we jump&#xA;to &#39;fail&#39; label, where we kfree() the pending snapshot structure. This can&#xA;result in a later use-after-free of the pending snapshot:&#xA;1) We allocated the pending snapshot and added it to the transaction&#39;s&#xA;   list of pending snapshots;&#xA;2) We call btrfs_commit_transaction(), and it fails either at the first&#xA;   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().&#xA;   In both cases, we don&#39;t abort the transaction and we release our&#xA;   transaction handle. We jump to the &#39;fail&#39; label and free the pending&#xA;   snapshot structure. We return with the pending snapshot still in the&#xA;   transaction&#39;s list;&#xA;3) Another task commits the transaction. This time there&#39;s no error at&#xA;   all, and then during the transaction commit it accesses a pointer&#xA;   to the pending snapshot structure that the snapshot creation task&#xA;   has already freed, resulting in a user-after-free.&#xA;This issue could actually be detected by smatch, which produced the&#xA;following warning:&#xA;  fs/btrfs/ioctl.c:843 create_snapshot() warn: &#39;&amp;pending_snapshot-&gt;list&#39; not removed from list&#xA;So fix this by not having the snapshot creation ioctl directly add the&#xA;pending snapshot to the transaction&#39;s list. Instead add the pending&#xA;snapshot to the transaction handle, and then at btrfs_commit_transaction()&#xA;we add the snapshot to the list only when we can guarantee that any error&#xA;returned after that point will result in a transaction abort, in which&#xA;case the ioctl code can safely free the pending snapshot and no one can&#xA;access it anymore.&#xA;CVE-2024-38558:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: openvswitch: fix overwriting ct original tuple for ICMPv6&#xA;OVS_PACKET_CMD_EXECUTE has 3 main attributes:&#xA; - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.&#xA; - OVS_PACKET_ATTR_PACKET - Binary packet content.&#xA; - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.&#xA;OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure&#xA;with the metadata like conntrack state, input port, recirculation id,&#xA;etc.  Then the packet itself gets parsed to populate the rest of the&#xA;keys from the packet headers.&#xA;Whenever the packet parsing code starts parsing the ICMPv6 header, it&#xA;first zeroes out fields in the key corresponding to Neighbor Discovery&#xA;information even if it is not an ND packet.&#xA;It is an &#39;ipv6.nd&#39; field.  However, the &#39;ipv6&#39; is a union that shares&#xA;the space between &#39;nd&#39; and &#39;ct_orig&#39; that holds the original tuple&#xA;conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.&#xA;ND packets should not normally have conntrack state, so it&#39;s fine to&#xA;share the space, but normal ICMPv6 Echo packets or maybe other types of&#xA;ICMPv6 can have the state attached and it should not be overwritten.&#xA;The issue results in all but the last 4 bytes of the destination&#xA;address being wiped from the original conntrack tuple leading to&#xA;incorrect packet matching and potentially executing wrong actions&#xA;in case this packet recirculates within the datapath or goes back&#xA;to userspace.&#xA;ND fields should not be accessed in non-ND packets, so not clearing&#xA;them should be fine.  Executing memset() only for actual ND packets to&#xA;avoid the issue.&#xA;Initializing the whole thing before parsing is needed because ND packet&#xA;may not contain all the options.&#xA;The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn&#39;t&#xA;affect packets entering OVS datapath from network interfaces, because&#xA;in this case CT metadata is populated from skb after the packet is&#xA;already parsed.&#xA;CVE-2023-4458:This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication may or may not be required to exploit this vulnerability, depending upon configuration. Furthermore, only systems with ksmbd enabled are vulnerable.&#xA;CVE-2024-38548:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference&#xA;In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is&#xA;assigned to mhdp_state-&gt;current_mode, and there is a dereference of it in&#xA;drm_mode_set_name(), which will lead to a NULL pointer dereference on&#xA;failure of drm_mode_duplicate().&#xA;Fix this bug add a check of mhdp_state-&gt;current_mode.&#xA;CVE-2024-36478:In the Linux kernel, the following vulnerability has been resolved:&#xA;null_blk: fix null-ptr-dereference while configuring &#39;power&#39; and &#39;submit_queues&#39;&#xA;Writing &#39;power&#39; and &#39;submit_queues&#39; concurrently will trigger kernel&#xA;panic:&#xA;Test script:&#xA;modprobe null_blk nr_devices=0&#xA;mkdir -p /sys/kernel/config/nullb/nullb0&#xA;while true; do echo 1 &gt; submit_queues; echo 4 &gt; submit_queues; done &amp;&#xA;while true; do echo 1 &gt; power; echo 0 &gt; power; done&#xA;Test result:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000148&#xA;Oops: 0000 [#1] PREEMPT SMP&#xA;RIP: 0010:__lock_acquire+0x41d/0x28f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; lock_acquire+0x121/0x450&#xA; down_write+0x5f/0x1d0&#xA; simple_recursive_removal+0x12f/0x5c0&#xA; blk_mq_debugfs_unregister_hctxs+0x7c/0x100&#xA; blk_mq_update_nr_hw_queues+0x4a3/0x720&#xA; nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]&#xA; nullb_device_submit_queues_store+0x79/0xf0 [null_blk]&#xA; configfs_write_iter+0x119/0x1e0&#xA; vfs_write+0x326/0x730&#xA; ksys_write+0x74/0x150&#xA;This is because del_gendisk() can concurrent with&#xA;blk_mq_update_nr_hw_queues():&#xA;nullb_device_power_store&#x9;nullb_apply_submit_queues&#xA; null_del_dev&#xA; del_gendisk&#xA;&#x9;&#x9;&#x9;&#x9; nullb_update_nr_hw_queues&#xA;&#x9;&#x9;&#x9;&#x9;  if (!dev-&gt;nullb)&#xA;&#x9;&#x9;&#x9;&#x9;  // still set while gendisk is deleted&#xA;&#x9;&#x9;&#x9;&#x9;   return 0&#xA;&#x9;&#x9;&#x9;&#x9;  blk_mq_update_nr_hw_queues&#xA; dev-&gt;nullb = NULL&#xA;Fix this problem by resuing the global mutex to protect&#xA;nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.&#xA;CVE-2024-39480:In the Linux kernel, the following vulnerability has been resolved:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.&#xA;CVE-2024-38540:In the Linux kernel, the following vulnerability has been resolved:&#xA;bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq&#xA;Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called&#xA;with hwq_attr-&gt;aux_depth != 0 and hwq_attr-&gt;aux_stride == 0.&#xA;In that case, &#34;roundup_pow_of_two(hwq_attr-&gt;aux_stride)&#34; gets called.&#xA;roundup_pow_of_two is documented as undefined for 0.&#xA;Fix it in the one caller that had this combination.&#xA;The undefined behavior was detected by UBSAN:&#xA;  UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13&#xA;  shift exponent 64 is too large for 64-bit type &#39;long unsigned int&#39;&#xA;  CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4&#xA;  Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x5d/0x80&#xA;   ubsan_epilogue+0x5/0x30&#xA;   __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec&#xA;   __roundup_pow_of_two+0x25/0x35 [bnxt_re]&#xA;   bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]&#xA;   bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]&#xA;   bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? __kmalloc+0x1b6/0x4f0&#xA;   ? create_qp.part.0+0x128/0x1c0 [ib_core]&#xA;   ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]&#xA;   create_qp.part.0+0x128/0x1c0 [ib_core]&#xA;   ib_create_qp_kernel+0x50/0xd0 [ib_core]&#xA;   create_mad_qp+0x8e/0xe0 [ib_core]&#xA;   ? __pfx_qp_event_handler+0x10/0x10 [ib_core]&#xA;   ib_mad_init_device+0x2be/0x680 [ib_core]&#xA;   add_client_context+0x10d/0x1a0 [ib_core]&#xA;   enable_device_and_get+0xe0/0x1d0 [ib_core]&#xA;   ib_register_device+0x53c/0x630 [ib_core]&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   bnxt_re_probe+0xbd8/0xe50 [bnxt_re]&#xA;   ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]&#xA;   auxiliary_bus_probe+0x49/0x80&#xA;   ? driver_sysfs_add+0x57/0xc0&#xA;   really_probe+0xde/0x340&#xA;   ? pm_runtime_barrier+0x54/0x90&#xA;   ? __pfx___driver_attach+0x10/0x10&#xA;   __driver_probe_device+0x78/0x110&#xA;   driver_probe_device+0x1f/0xa0&#xA;   __driver_attach+0xba/0x1c0&#xA;   bus_for_each_dev+0x8f/0xe0&#xA;   bus_add_driver+0x146/0x220&#xA;   driver_register+0x72/0xd0&#xA;   __auxiliary_driver_register+0x6e/0xd0&#xA;   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]&#xA;   bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]&#xA;   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]&#xA;   do_one_initcall+0x5b/0x310&#xA;   do_init_module+0x90/0x250&#xA;   init_module_from_file+0x86/0xc0&#xA;   idempotent_init_module+0x121/0x2b0&#xA;   __x64_sys_finit_module+0x5e/0xb0&#xA;   do_syscall_64+0x82/0x160&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? syscall_exit_to_user_mode_prepare+0x149/0x170&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? syscall_exit_to_user_mode+0x75/0x230&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? do_syscall_64+0x8e/0x160&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? __count_memcg_events+0x69/0x100&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? count_memcg_events.constprop.0+0x1a/0x30&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? handle_mm_fault+0x1f0/0x300&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? do_user_addr_fault+0x34e/0x640&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   ? srso_alias_return_thunk+0x5/0xfbef5&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;  RIP: 0033:0x7f4e5132821d&#xA;  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48&#xA;  RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139&#xA;  RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d&#xA;  RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b&#xA;  RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0&#xA;  R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d&#xA;  R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace ]---&#xA;CVE-2024-38615:In the Linux kernel, the following vulnerability has been resolved:&#xA;cpufreq: exit() callback is optional&#xA;The exit() callback is optional and shouldn&#39;t be called without checking&#xA;a valid pointer first.&#xA;Also, we must clear freq_table pointer even if the exit() callback isn&#39;t&#xA;present.&#xA;CVE-2023-52757:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix potential deadlock when releasing mids&#xA;All release_mid() callers seem to hold a reference of @mid so there is&#xA;no need to call kref_put(&amp;mid-&gt;refcount, __release_mid) under&#xA;@server-&gt;mid_lock spinlock.  If they don&#39;t, then an use-after-free bug&#xA;would have occurred anyways.&#xA;By getting rid of such spinlock also fixes a potential deadlock as&#xA;shown below&#xA;CPU 0                                CPU 1&#xA;------------------------------------------------------------------&#xA;cifs_demultiplex_thread()            cifs_debug_data_proc_show()&#xA; release_mid()&#xA;  spin_lock(&amp;server-&gt;mid_lock);&#xA;                                     spin_lock(&amp;cifs_tcp_ses_lock)&#xA;&#x9;&#x9;&#x9;&#x9;      spin_lock(&amp;server-&gt;mid_lock)&#xA;  __release_mid()&#xA;   smb2_find_smb_tcon()&#xA;    spin_lock(&amp;cifs_tcp_ses_lock) *deadlock*&#xA;CVE-2023-52755:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: fix slab out of bounds write in smb_inherit_dacl()&#xA;slab out-of-bounds write is caused by that offsets is bigger than pntsd&#xA;allocation size. This patch add the check to validate 3 offsets using&#xA;allocation size.&#xA;CVE-2024-39484:In the Linux kernel, the following vulnerability has been resolved:&#xA;mmc: davinci: Don&#39;t strip remove function when driver is builtin&#xA;Using __exit for the remove function results in the remove callback being&#xA;discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.&#xA;using sysfs or hotplug), the driver is just removed without the cleanup&#xA;being performed. This results in resource leaks. Fix it by compiling in the&#xA;remove callback unconditionally.&#xA;This also fixes a W=1 modpost warning:&#xA;WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in&#xA;reference: davinci_mmcsd_driver+0x10 (section: .data) -&gt;&#xA;davinci_mmcsd_remove (section: .exit.text)&#xA;CVE-2024-39472:In the Linux kernel, the following vulnerability has been resolved:xfs: fix log recovery buffer allocation for the legacy h_size fixupCommit a70f9fe52daa ( xfs: detect and handle invalid iclog size set bymkfs ) added a fixup for incorrect h_size values used for the initialumount record in old xfsprogs versions.  Later commit 0c771b99d6c9( xfs: clean up calculation of LR header blocks ) cleaned up the logreover buffer calculation, but stoped using the fixed up h_size valueto size the log recovery buffer, which can lead to an out of boundsaccess when the incorrect h_size does not come from the old mkfstool, but a fuzzer.Fix this by open coding xlog_logrec_hblks and taking the fixed h_sizeinto account for this calculation.&#xA;CVE-2024-38598:In the Linux kernel, the following vulnerability has been resolved:&#xA;md: fix resync softlockup when bitmap size is less than array size&#xA;Is is reported that for dm-raid10, lvextend + lvchange --syncaction will&#xA;trigger following softlockup:&#xA;kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]&#xA;CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1&#xA;RIP: 0010:_raw_spin_unlock_irq+0x13/0x30&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; md_bitmap_start_sync+0x6b/0xf0&#xA; raid10_sync_request+0x25c/0x1b40 [raid10]&#xA; md_do_sync+0x64b/0x1020&#xA; md_thread+0xa7/0x170&#xA; kthread+0xcf/0x100&#xA; ret_from_fork+0x30/0x50&#xA; ret_from_fork_asm+0x1a/0x30&#xA;And the detailed process is as follows:&#xA;md_do_sync&#xA; j = mddev-&gt;resync_min&#xA; while (j &lt; max_sectors)&#xA;  sectors = raid10_sync_request(mddev, j, &amp;skipped)&#xA;   if (!md_bitmap_start_sync(..., &amp;sync_blocks))&#xA;    // md_bitmap_start_sync set sync_blocks to 0&#xA;    return sync_blocks + sectors_skippe;&#xA;  // sectors = 0;&#xA;  j += sectors;&#xA;  // j never change&#xA;Root cause is that commit 301867b1c168 (&#34;md/raid10: check&#xA;slab-out-of-bounds in md_bitmap_get_counter&#34;) return early from&#xA;md_bitmap_get_counter(), without setting returned blocks.&#xA;Fix this problem by always set returned blocks from&#xA;md_bitmap_get_counter&#34;(), as it used to be.&#xA;Noted that this patch just fix the softlockup problem in kernel, the&#xA;case that bitmap size doesn&#39;t match array size still need to be fixed.&#xA;CVE-2024-35899:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: flush pending destroy work before exit_net release&#xA;Similar to 2c9f0293280e (&#34;netfilter: nf_tables: flush pending destroy&#xA;work before netlink notifier&#34;) to address a race between exit_net and&#xA;the destroy workqueue.&#xA;The trace below shows an element to be released via destroy workqueue&#xA;while exit_net path (triggered via module removal) has already released&#xA;the set that is used in such transaction.&#xA;[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]&#xA;[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465&#xA;[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359&#xA;[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]&#xA;[ 1360.547984] Call Trace:&#xA;[ 1360.547991]  &lt;TASK&gt;&#xA;[ 1360.547998]  dump_stack_lvl+0x53/0x70&#xA;[ 1360.548014]  print_report+0xc4/0x610&#xA;[ 1360.548026]  ? __virt_addr_valid+0xba/0x160&#xA;[ 1360.548040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10&#xA;[ 1360.548054]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]&#xA;[ 1360.548176]  kasan_report+0xae/0xe0&#xA;[ 1360.548189]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]&#xA;[ 1360.548312]  nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]&#xA;[ 1360.548447]  ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]&#xA;[ 1360.548577]  ? _raw_spin_unlock_irq+0x18/0x30&#xA;[ 1360.548591]  process_one_work+0x2f1/0x670&#xA;[ 1360.548610]  worker_thread+0x4d3/0x760&#xA;[ 1360.548627]  ? __pfx_worker_thread+0x10/0x10&#xA;[ 1360.548640]  kthread+0x16b/0x1b0&#xA;[ 1360.548653]  ? __pfx_kthread+0x10/0x10&#xA;[ 1360.548665]  ret_from_fork+0x2f/0x50&#xA;[ 1360.548679]  ? __pfx_kthread+0x10/0x10&#xA;[ 1360.548690]  ret_from_fork_asm+0x1a/0x30&#xA;[ 1360.548707]  &lt;/TASK&gt;&#xA;[ 1360.548719] Allocated by task 192061:&#xA;[ 1360.548726]  kasan_save_stack+0x20/0x40&#xA;[ 1360.548739]  kasan_save_track+0x14/0x30&#xA;[ 1360.548750]  __kasan_kmalloc+0x8f/0xa0&#xA;[ 1360.548760]  __kmalloc_node+0x1f1/0x450&#xA;[ 1360.548771]  nf_tables_newset+0x10c7/0x1b50 [nf_tables]&#xA;[ 1360.548883]  nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]&#xA;[ 1360.548909]  nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]&#xA;[ 1360.548927]  netlink_unicast+0x367/0x4f0&#xA;[ 1360.548935]  netlink_sendmsg+0x34b/0x610&#xA;[ 1360.548944]  ____sys_sendmsg+0x4d4/0x510&#xA;[ 1360.548953]  ___sys_sendmsg+0xc9/0x120&#xA;[ 1360.548961]  __sys_sendmsg+0xbe/0x140&#xA;[ 1360.548971]  do_syscall_64+0x55/0x120&#xA;[ 1360.548982]  entry_SYSCALL_64_after_hwframe+0x55/0x5d&#xA;[ 1360.548994] Freed by task 192222:&#xA;[ 1360.548999]  kasan_save_stack+0x20/0x40&#xA;[ 1360.549009]  kasan_save_track+0x14/0x30&#xA;[ 1360.549019]  kasan_save_free_info+0x3b/0x60&#xA;[ 1360.549028]  poison_slab_object+0x100/0x180&#xA;[ 1360.549036]  __kasan_slab_free+0x14/0x30&#xA;[ 1360.549042]  kfree+0xb6/0x260&#xA;[ 1360.549049]  __nft_release_table+0x473/0x6a0 [nf_tables]&#xA;[ 1360.549131]  nf_tables_exit_net+0x170/0x240 [nf_tables]&#xA;[ 1360.549221]  ops_exit_list+0x50/0xa0&#xA;[ 1360.549229]  free_exit_list+0x101/0x140&#xA;[ 1360.549236]  unregister_pernet_operations+0x107/0x160&#xA;[ 1360.549245]  unregister_pernet_subsys+0x1c/0x30&#xA;[ 1360.549254]  nf_tables_module_exit+0x43/0x80 [nf_tables]&#xA;[ 1360.549345]  __do_sys_delete_module+0x253/0x370&#xA;[ 1360.549352]  do_syscall_64+0x55/0x120&#xA;[ 1360.549360]  entry_SYSCALL_64_after_hwframe+0x55/0x5d&#xA;(gdb) list *__nft_release_table+0x473&#xA;0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).&#xA;11349           list_for_each_entry_safe(flowtable, nf, &amp;table-&gt;flowtables, list) {&#xA;11350                   list_del(&amp;flowtable-&gt;list);&#xA;11351                   nft_use_dec(&amp;table-&gt;use);&#xA;11352                   nf_tables_flowtable_destroy(flowtable);&#xA;11353           }&#xA;11354           list_for_each_entry_safe(set, ns, &amp;table-&gt;sets, list) {&#xA;11355                   list_del(&amp;set-&gt;list);&#xA;11356                   nft_use_dec(&amp;table-&gt;use);&#xA;11357                   if (set-&gt;flags &amp; (NFT_SET_MAP | NFT_SET_OBJECT))&#xA;11358                           nft_map_deactivat&#xA;---truncated---&#xA;CVE-2024-38583:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix use-after-free of timer for log writer thread&#xA;Patch series &#34;nilfs2: fix log writer related issues&#34;.&#xA;This bug fix series covers three nilfs2 log writer-related issues,&#xA;including a timer use-after-free issue and potential deadlock issue on&#xA;unmount, and a potential freeze issue in event synchronization found&#xA;during their analysis.  Details are described in each commit log.&#xA;This patch (of 3):&#xA;A use-after-free issue has been reported regarding the timer sc_timer on&#xA;the nilfs_sc_info structure.&#xA;The problem is that even though it is used to wake up a sleeping log&#xA;writer thread, sc_timer is not shut down until the nilfs_sc_info structure&#xA;is about to be freed, and is used regardless of the thread&#39;s lifetime.&#xA;Fix this issue by limiting the use of sc_timer only while the log writer&#xA;thread is alive.&#xA;CVE-2024-35988:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: Fix TASK_SIZE on 64-bit NOMMU&#xA;On NOMMU, userspace memory can come from anywhere in physical RAM. The&#xA;current definition of TASK_SIZE is wrong if any RAM exists above 4G,&#xA;causing spurious failures in the userspace access routines.&#xA;CVE-2024-39489:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: sr: fix memleak in seg6_hmac_init_algo&#xA;seg6_hmac_init_algo returns without cleaning up the previous allocations&#xA;if one fails, so it&#39;s going to leak all that memory and the crypto tfms.&#xA;Update seg6_hmac_exit to only free the memory when allocated, so we can&#xA;reuse the code directly.&#xA;CVE-2024-39487:In the Linux kernel, the following vulnerability has been resolved:&#xA;bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()&#xA;In function bond_option_arp_ip_targets_set(), if newval-&gt;string is an&#xA;empty string, newval-&gt;string+1 will point to the byte after the&#xA;string, causing an out-of-bound read.&#xA;BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418&#xA;Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107&#xA;CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:364 [inline]&#xA; print_report+0xc1/0x5e0 mm/kasan/report.c:475&#xA; kasan_report+0xbe/0xf0 mm/kasan/report.c:588&#xA; strlen+0x7d/0xa0 lib/string.c:418&#xA; __fortify_strlen include/linux/fortify-string.h:210 [inline]&#xA; in4_pton+0xa3/0x3f0 net/core/utils.c:130&#xA; bond_option_arp_ip_targets_set+0xc2/0x910&#xA;drivers/net/bonding/bond_options.c:1201&#xA; __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767&#xA; __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792&#xA; bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817&#xA; bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156&#xA; dev_attr_store+0x54/0x80 drivers/base/core.c:2366&#xA; sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136&#xA; kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334&#xA; call_write_iter include/linux/fs.h:2020 [inline]&#xA; new_sync_write fs/read_write.c:491 [inline]&#xA; vfs_write+0x96a/0xd80 fs/read_write.c:584&#xA; ksys_write+0x122/0x250 fs/read_write.c:637&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;---[ end trace ]---&#xA;Fix it by adding a check of string length before using it.&#xA;CVE-2024-40905:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: fix possible race in __fib6_drop_pcpu_from()&#xA;syzbot found a race in __fib6_drop_pcpu_from() [1]&#xA;If compiler reads more than once (*ppcpu_rt),&#xA;second read could read NULL, if another cpu clears&#xA;the value in rt6_get_pcpu_route().&#xA;Add a READ_ONCE() to prevent this race.&#xA;Also add rcu_read_lock()/rcu_read_unlock() because&#xA;we rely on RCU protection while dereferencing pcpu_rt.&#xA;[1]&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]&#xA;CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA;Workqueue: netns cleanup_net&#xA; RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984&#xA;Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 &lt;80&gt; 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48&#xA;RSP: 0018:ffffc900040df070 EFLAGS: 00010206&#xA;RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16&#xA;RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091&#xA;RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007&#xA;R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8&#xA;R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001&#xA;FS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]&#xA;  fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]&#xA;  fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038&#xA;  fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]&#xA;  fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043&#xA;  fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205&#xA;  fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127&#xA;  fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175&#xA;  fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255&#xA;  __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271&#xA;  rt6_sync_down_dev net/ipv6/route.c:4906 [inline]&#xA;  rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911&#xA;  addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855&#xA;  addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778&#xA;  notifier_call_chain+0xb9/0x410 kernel/notifier.c:93&#xA;  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992&#xA;  call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]&#xA;  call_netdevice_notifiers net/core/dev.c:2044 [inline]&#xA;  dev_close_many+0x333/0x6a0 net/core/dev.c:1585&#xA;  unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193&#xA;  unregister_netdevice_many net/core/dev.c:11276 [inline]&#xA;  default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759&#xA;  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178&#xA;  cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640&#xA;  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231&#xA;  process_scheduled_works kernel/workqueue.c:3312 [inline]&#xA;  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393&#xA;  kthread+0x2c1/0x3a0 kernel/kthread.c:389&#xA;  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147&#xA;  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;CVE-2024-40931:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: ensure snd_una is properly initialized on connect&#xA;This is strictly related to commit fb7a0d334894 (&#34;mptcp: ensure snd_nxt&#xA;is properly initialized on connect&#34;). It turns out that syzkaller can&#xA;trigger the retransmit after fallback and before processing any other&#xA;incoming packet - so that snd_una is still left uninitialized.&#xA;Address the issue explicitly initializing snd_una together with snd_nxt&#xA;and write_seq.&#xA;CVE-2024-39500:In the Linux kernel, the following vulnerability has been resolved:&#xA;sock_map: avoid race between sock_map_close and sk_psock_put&#xA;sk_psock_get will return NULL if the refcount of psock has gone to 0, which&#xA;will happen when the last call of sk_psock_put is done. However,&#xA;sk_psock_drop may not have finished yet, so the close callback will still&#xA;point to sock_map_close despite psock being NULL.&#xA;This can be reproduced with a thread deleting an element from the sock map,&#xA;while the second one creates a socket, adds it to the map and closes it.&#xA;That will trigger the WARN_ON_ONCE:&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701&#xA;Modules linked in:&#xA;CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA;RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701&#xA;Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 &lt;0f&gt; 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02&#xA;RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293&#xA;RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000&#xA;RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0&#xA;RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3&#xA;R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840&#xA;R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870&#xA;FS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; unix_release+0x87/0xc0 net/unix/af_unix.c:1048&#xA; __sock_release net/socket.c:659 [inline]&#xA; sock_close+0xbe/0x240 net/socket.c:1421&#xA; __fput+0x42b/0x8a0 fs/file_table.c:422&#xA; __do_sys_close fs/open.c:1556 [inline]&#xA; __se_sys_close fs/open.c:1541 [inline]&#xA; __x64_sys_close+0x7f/0x110 fs/open.c:1541&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7fb37d618070&#xA;Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c&#xA;RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003&#xA;RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070&#xA;RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004&#xA;RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000&#xA;R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA; &lt;/TASK&gt;&#xA;Use sk_psock, which will only check that the pointer is not been set to&#xA;NULL yet, which should only happen after the callbacks are restored. If,&#xA;then, a reference can still be gotten, we may call sk_psock_stop and cancel&#xA;psock-&gt;work.&#xA;As suggested by Paolo Abeni, reorder the condition so the control flow is&#xA;less convoluted.&#xA;After that change, the reproducer does not trigger the WARN_ON_ONCE&#xA;anymore.&#xA;CVE-2024-39488:In the Linux kernel, the following vulnerability has been resolved:&#xA;arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY&#xA;When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes&#xA;to bug_table entries, and as a result the last entry in a bug table will&#xA;be ignored, potentially leading to an unexpected panic(). All prior&#xA;entries in the table will be handled correctly.&#xA;The arm64 ABI requires that struct fields of up to 8 bytes are&#xA;naturally-aligned, with padding added within a struct such that struct&#xA;are suitably aligned within arrays.&#xA;When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:&#xA;&#x9;struct bug_entry {&#xA;&#x9;&#x9;signed int      bug_addr_disp;&#x9;// 4 bytes&#xA;&#x9;&#x9;signed int      file_disp;&#x9;// 4 bytes&#xA;&#x9;&#x9;unsigned short  line;&#x9;&#x9;// 2 bytes&#xA;&#x9;&#x9;unsigned short  flags;&#x9;&#x9;// 2 bytes&#xA;&#x9;}&#xA;... with 12 bytes total, requiring 4-byte alignment.&#xA;When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:&#xA;&#x9;struct bug_entry {&#xA;&#x9;&#x9;signed int      bug_addr_disp;&#x9;// 4 bytes&#xA;&#x9;&#x9;unsigned short  flags;&#x9;&#x9;// 2 bytes&#xA;&#x9;&#x9;&lt; implicit padding &gt;&#x9;&#x9;// 2 bytes&#xA;&#x9;}&#xA;... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing&#xA;padding, requiring 4-byte alginment.&#xA;When we create a bug_entry in assembly, we align the start of the entry&#xA;to 4 bytes, which implicitly handles padding for any prior entries.&#xA;However, we do not align the end of the entry, and so when&#xA;CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding&#xA;bytes.&#xA;For the main kernel image this is not a problem as find_bug() doesn&#39;t&#xA;depend on the trailing padding bytes when searching for entries:&#xA;&#x9;for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)&#xA;&#x9;&#x9;if (bugaddr == bug_addr(bug))&#xA;&#x9;&#x9;&#x9;return bug;&#xA;However for modules, module_bug_finalize() depends on the trailing&#xA;bytes when calculating the number of entries:&#xA;&#x9;mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);&#xA;... and as the last bug_entry lacks the necessary padding bytes, this entry&#xA;will not be counted, e.g. in the case of a single entry:&#xA;&#x9;sechdrs[i].sh_size == 6&#xA;&#x9;sizeof(struct bug_entry) == 8;&#xA;&#x9;sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;&#xA;Consequently module_find_bug() will miss the last bug_entry when it does:&#xA;&#x9;for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)&#xA;&#x9;&#x9;if (bugaddr == bug_addr(bug))&#xA;&#x9;&#x9;&#x9;goto out;&#xA;... which can lead to a kenrel panic due to an unhandled bug.&#xA;This can be demonstrated with the following module:&#xA;&#x9;static int __init buginit(void)&#xA;&#x9;{&#xA;&#x9;&#x9;WARN(1, &#34;hello\n&#34;);&#xA;&#x9;&#x9;return 0;&#xA;&#x9;}&#xA;&#x9;static void __exit bugexit(void)&#xA;&#x9;{&#xA;&#x9;}&#xA;&#x9;module_init(buginit);&#xA;&#x9;module_exit(bugexit);&#xA;&#x9;MODULE_LICENSE(&#34;GPL&#34;);&#xA;... which will trigger a kernel panic when loaded:&#xA;&#x9;------------[ cut here ]------------&#xA;&#x9;hello&#xA;&#x9;Unexpected kernel BRK exception at EL1&#xA;&#x9;Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP&#xA;&#x9;Modules linked in: hello(O+)&#xA;&#x9;CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8&#xA;&#x9;Hardware name: linux,dummy-virt (DT)&#xA;&#x9;pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;&#x9;pc : buginit+0x18/0x1000 [hello]&#xA;&#x9;lr : buginit+0x18/0x1000 [hello]&#xA;&#x9;sp : ffff800080533ae0&#xA;&#x9;x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000&#xA;&#x9;x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58&#xA;&#x9;x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0&#xA;&#x9;x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006&#xA;&#x9;x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720&#xA;&#x9;x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312&#xA;&#x9;x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8&#xA;&#x9;x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000&#xA;&#x9;x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000&#xA;&#x9;x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0&#xA;&#x9;Call trace:&#xA;&#x9; buginit+0x18/0x1000 [hello]&#xA;&#x9; do_one_initcall+0x80/0x1c8&#xA;&#x9; do_init_module+0x60/0x218&#xA;&#x9; load_module+0x1ba4/0x1d70&#xA;&#x9; __do_sys_init_module+0x198/0x1d0&#xA;&#x9; __arm64_sys_init_module+0x1c/0x28&#xA;&#x9; invoke_syscall+0x48/0x114&#xA;&#x9; el0_svc&#xA;---truncated---&#xA;CVE-2024-40974:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/pseries: Enforce hcall result buffer validity and size&#xA;plpar_hcall(), plpar_hcall9(), and related functions expect callers to&#xA;provide valid result buffers of certain minimum size. Currently this&#xA;is communicated only through comments in the code and the compiler has&#xA;no idea.&#xA;For example, if I write a bug like this:&#xA;  long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE&#xA;  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);&#xA;This compiles with no diagnostics emitted, but likely results in stack&#xA;corruption at runtime when plpar_hcall9() stores results past the end&#xA;of the array. (To be clear this is a contrived example and I have not&#xA;found a real instance yet.)&#xA;To make this class of error less likely, we can use explicitly-sized&#xA;array parameters instead of pointers in the declarations for the hcall&#xA;APIs. When compiled with -Warray-bounds[1], the code above now&#xA;provokes a diagnostic like this:&#xA;error: array argument is too small;&#xA;is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]&#xA;   60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,&#xA;      |                 ^                                   ~~~~~~&#xA;[1] Enabled for LLVM builds but not GCC for now. See commit&#xA;    0da6e5fd6c37 (&#34;gcc: disable &#39;-Warray-bounds&#39; for gcc-13 too&#34;) and&#xA;    related changes.&#xA;CVE-2021-47200:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap&#xA;drm_gem_ttm_mmap() drops a reference to the gem object on success. If&#xA;the gem object&#39;s refcount == 1 on entry to drm_gem_prime_mmap(), that&#xA;drop will free the gem object, and the subsequent drm_gem_object_get()&#xA;will be a UAF. Fix by grabbing a reference before calling the mmap&#xA;helper.&#xA;This issue was forseen when the reference dropping was adding in&#xA;commit 9786b65bc61ac (&#34;drm/ttm: fix mmap refcounting&#34;):&#xA;  &#34;For that to work properly the drm_gem_object_get() call in&#xA;  drm_gem_ttm_mmap() must be moved so it happens before calling&#xA;  obj-&gt;funcs-&gt;mmap(), otherwise the gem refcount would go down&#xA;  to zero.&#34;&#xA;CVE-2024-40943:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: fix races between hole punching and AIO+DIO&#xA;After commit &#34;ocfs2: return real error code in ocfs2_dio_wr_get_block&#34;,&#xA;fstests/generic/300 become from always failed to sometimes failed:&#xA;========================================================================&#xA;[  473.293420 ] run fstests generic/300&#xA;[  475.296983 ] JBD2: Ignoring recovery information on journal&#xA;[  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.&#xA;[  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found&#xA;[  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.&#xA;[  494.292018 ] OCFS2: File system is now read-only.&#xA;[  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30&#xA;[  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3&#xA;fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072&#xA;=========================================================================&#xA;In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten&#xA;extents to a list.  extents are also inserted into extent tree in&#xA;ocfs2_write_begin_nolock.  Then another thread call fallocate to puch a&#xA;hole at one of the unwritten extent.  The extent at cpos was removed by&#xA;ocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list&#xA;found there is no such extent at the cpos.&#xA;    T1                        T2                T3&#xA;                              inode lock&#xA;                                ...&#xA;                                insert extents&#xA;                                ...&#xA;                              inode unlock&#xA;ocfs2_fallocate&#xA; __ocfs2_change_file_space&#xA;  inode lock&#xA;  lock ip_alloc_sem&#xA;  ocfs2_remove_inode_range inode&#xA;   ocfs2_remove_btree_range&#xA;    ocfs2_remove_extent&#xA;    ^---remove the extent at cpos 78723&#xA;  ...&#xA;  unlock ip_alloc_sem&#xA;  inode unlock&#xA;                                       ocfs2_dio_end_io&#xA;                                        ocfs2_dio_end_io_write&#xA;                                         lock ip_alloc_sem&#xA;                                         ocfs2_mark_extent_written&#xA;                                          ocfs2_change_extent_flag&#xA;                                           ocfs2_search_extent_list&#xA;                                           ^---failed to find extent&#xA;                                          ...&#xA;                                          unlock ip_alloc_sem&#xA;In most filesystems, fallocate is not compatible with racing with AIO+DIO,&#xA;so fix it by adding to wait for all dio before fallocate/punch_hole like&#xA;ext4.&#xA;CVE-2023-52674:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()&#xA;Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and&#xA;SCARLETT2_MIXER_MAX_VALUE so we don&#39;t attempt to access outside&#xA;scarlett2_mixer_values[].&#xA;CVE-2024-35904:In the Linux kernel, the following vulnerability has been resolved:&#xA;selinux: avoid dereference of garbage after mount failure&#xA;In case kern_mount() fails and returns an error pointer return in the&#xA;error branch instead of continuing and dereferencing the error pointer.&#xA;While on it drop the never read static variable selinuxfs_mount.&#xA;CVE-2024-40984:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPICA: Revert &#34;ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine.&#34;&#xA;Undo the modifications made in commit d410ee5109a1 (&#34;ACPICA: avoid&#xA;&#34;Info: mapping multiple BARs. Your kernel is fine.&#34;&#34;). The initial&#xA;purpose of this commit was to stop memory mappings for operation&#xA;regions from overlapping page boundaries, as it can trigger warnings&#xA;if different page attributes are present.&#xA;However, it was found that when this situation arises, mapping&#xA;continues until the boundary&#39;s end, but there is still an attempt to&#xA;read/write the entire length of the map, leading to a NULL pointer&#xA;deference. For example, if a four-byte mapping request is made but&#xA;only one byte is mapped because it hits the current page boundary&#39;s&#xA;end, a four-byte read/write attempt is still made, resulting in a NULL&#xA;pointer deference.&#xA;Instead, map the entire length, as the ACPI specification does not&#xA;mandate that it must be within the same page boundary. It is&#xA;permissible for it to be mapped across different regions.&#xA;CVE-2024-40971:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: remove clear SB_INLINECRYPT flag in default_options&#xA;In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.&#xA;If create new file or open file during this gap, these files&#xA;will not use inlinecrypt. Worse case, it may lead to data&#xA;corruption if wrappedkey_v0 is enable.&#xA;Thread A:                               Thread B:&#xA;-f2fs_remount&#x9;&#x9;&#x9;&#x9;-f2fs_file_open or f2fs_new_inode&#xA;  -default_options&#xA;&#x9;&lt;- clear SB_INLINECRYPT flag&#xA;                                          -fscrypt_select_encryption_impl&#xA;  -parse_options&#xA;&#x9;&lt;- set SB_INLINECRYPT again&#xA;CVE-2024-39505:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/komeda: check for error-valued pointer&#xA;komeda_pipeline_get_state() may return an error-valued pointer, thus&#xA;check the pointer for negative or null value before dereferencing.&#xA;CVE-2024-40953:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()&#xA;Use {READ,WRITE}_ONCE() to access kvm-&gt;last_boosted_vcpu to ensure the&#xA;loads and stores are atomic.  In the extremely unlikely scenario the&#xA;compiler tears the stores, it&#39;s theoretically possible for KVM to attempt&#xA;to get a vCPU using an out-of-bounds index, e.g. if the write is split&#xA;into multiple 8-bit stores, and is paired with a 32-bit load on a VM with&#xA;257 vCPUs:&#xA;  CPU0                              CPU1&#xA;  last_boosted_vcpu = 0xff;&#xA;                                    (last_boosted_vcpu = 0x100)&#xA;                                    last_boosted_vcpu[15:8] = 0x01;&#xA;  i = (last_boosted_vcpu = 0x1ff)&#xA;                                    last_boosted_vcpu[7:0] = 0x00;&#xA;  vcpu = kvm-&gt;vcpu_array[0x1ff];&#xA;As detected by KCSAN:&#xA;  BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]&#xA;  write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:&#xA;  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm&#xA;  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel&#xA;  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?&#xA;&#x9;&#x9; arch/x86/kvm/vmx/vmx.c:6606) kvm_intel&#xA;  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm&#xA;  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm&#xA;  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm&#xA;  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)&#xA;  __x64_sys_ioctl (fs/ioctl.c:890)&#xA;  x64_sys_call (arch/x86/entry/syscall_64.c:33)&#xA;  do_syscall_64 (arch/x86/entry/common.c:?)&#xA;  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;  read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:&#xA;  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm&#xA;  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel&#xA;  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?&#xA;&#x9;&#x9;&#x9;arch/x86/kvm/vmx/vmx.c:6606) kvm_intel&#xA;  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm&#xA;  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm&#xA;  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm&#xA;  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)&#xA;  __x64_sys_ioctl (fs/ioctl.c:890)&#xA;  x64_sys_call (arch/x86/entry/syscall_64.c:33)&#xA;  do_syscall_64 (arch/x86/entry/common.c:?)&#xA;  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;  value changed: 0x00000012 -&gt; 0x00000000&#xA;CVE-2023-52781:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: config: fix iteration issue in &#39;usb_get_bos_descriptor()&#39;&#xA;The BOS descriptor defines a root descriptor and is the base descriptor for&#xA;accessing a family of related descriptors.&#xA;Function &#39;usb_get_bos_descriptor()&#39; encounters an iteration issue when&#xA;skipping the &#39;USB_DT_DEVICE_CAPABILITY&#39; descriptor type. This results in&#xA;the same descriptor being read repeatedly.&#xA;To address this issue, a &#39;goto&#39; statement is introduced to ensure that the&#xA;pointer and the amount read is updated correctly. This ensures that the&#xA;function iterates to the next descriptor instead of reading the same&#xA;descriptor repeatedly.&#xA;CVE-2024-40972:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: do not create EA inode under buffer lock&#xA;ext4_xattr_set_entry() creates new EA inodes while holding buffer lock&#xA;on the external xattr block. This is problematic as it nests all the&#xA;allocation locking (which acquires locks on other buffers) under the&#xA;buffer lock. This can even deadlock when the filesystem is corrupted and&#xA;e.g. quota file is setup to contain xattr block as data block. Move the&#xA;allocation of EA inode out of ext4_xattr_set_entry() into the callers.&#xA;CVE-2024-41005:In the Linux kernel, the following vulnerability has been resolved:&#xA;netpoll: Fix race condition in netpoll_owner_active&#xA;KCSAN detected a race condition in netpoll:&#xA;&#x9;BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb&#xA;&#x9;write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:&#xA;&#x9;net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)&#xA;&lt;snip&gt;&#xA;&#x9;read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:&#xA;&#x9;netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)&#xA;&#x9;netpoll_send_udp (net/core/netpoll.c:?)&#xA;&lt;snip&gt;&#xA;&#x9;value changed: 0x0000000a -&gt; 0xffffffff&#xA;This happens because netpoll_owner_active() needs to check if the&#xA;current CPU is the owner of the lock, touching napi-&gt;poll_owner&#xA;non atomically. The -&gt;poll_owner field contains the current CPU holding&#xA;the lock.&#xA;Use an atomic read to check if the poll owner is the current CPU.&#xA;CVE-2024-39508:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring/io-wq: Use set_bit() and test_bit() at worker-&gt;flags&#xA;Utilize set_bit() and test_bit() on worker-&gt;flags within io_uring/io-wq&#xA;to address potential data races.&#xA;The structure io_worker-&gt;flags may be accessed through various data&#xA;paths, leading to concurrency issues. When KCSAN is enabled, it reveals&#xA;data races occurring in io_worker_handle_work and&#xA;io_wq_activate_free_worker functions.&#xA;&#x9; BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker&#xA;&#x9; write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:&#xA;&#x9; io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)&#xA;&#x9; io_wq_worker (io_uring/io-wq.c:?)&#xA;&lt;snip&gt;&#xA;&#x9; read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:&#xA;&#x9; io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)&#xA;&#x9; io_wq_enqueue (io_uring/io-wq.c:947)&#xA;&#x9; io_queue_iowq (io_uring/io_uring.c:524)&#xA;&#x9; io_req_task_submit (io_uring/io_uring.c:1511)&#xA;&#x9; io_handle_tw_list (io_uring/io_uring.c:1198)&#xA;&lt;snip&gt;&#xA;Line numbers against commit 18daea77cca6 (&#34;Merge tag &#39;for-linus&#39; of&#xA;git://git.kernel.org/pub/scm/virt/kvm/kvm&#34;).&#xA;These races involve writes and reads to the same memory location by&#xA;different tasks running on different CPUs. To mitigate this, refactor&#xA;the code to use atomic operations such as set_bit(), test_bit(), and&#xA;clear_bit() instead of basic &#34;and&#34; and &#34;or&#34; operations. This ensures&#xA;thread-safe manipulation of worker flags.&#xA;Also, move `create_index` to avoid holes in the structure.&#xA;CVE-2023-52833:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: btusb: Add date-&gt;evt_skb is NULL check&#xA;fix crash because of null pointers&#xA;[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8&#xA;[ 6104.969667] #PF: supervisor read access in kernel mode&#xA;[ 6104.969668] #PF: error_code(0x0000) - not-present page&#xA;[ 6104.969670] PGD 0 P4D 0&#xA;[ 6104.969673] Oops: 0000 [#1] SMP NOPTI&#xA;[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]&#xA;[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246&#xA;[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006&#xA;[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000&#xA;[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001&#xA;[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0&#xA;[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90&#xA;[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000&#xA;[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0&#xA;[ 6104.969701] PKRU: 55555554&#xA;[ 6104.969702] Call Trace:&#xA;[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]&#xA;[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]&#xA;[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]&#xA;[ 6104.969753]  rfkill_set_block+0x92/0x160&#xA;[ 6104.969755]  rfkill_fop_write+0x136/0x1e0&#xA;[ 6104.969759]  __vfs_write+0x18/0x40&#xA;[ 6104.969761]  vfs_write+0xdf/0x1c0&#xA;[ 6104.969763]  ksys_write+0xb1/0xe0&#xA;[ 6104.969765]  __x64_sys_write+0x1a/0x20&#xA;[ 6104.969769]  do_syscall_64+0x51/0x180&#xA;[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9&#xA;[ 6104.969773] RIP: 0033:0x7f5a21f18fef&#xA;[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001&#xA;[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef&#xA;[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012&#xA;[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017&#xA;[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002&#xA;[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0&#xA;CVE-2024-40932:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/exynos/vidi: fix memory leak in .get_modes()&#xA;The duplicated EDID is never freed. Fix it.&#xA;CVE-2024-39506:In the Linux kernel, the following vulnerability has been resolved:&#xA;liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet&#xA;In lio_vf_rep_copy_packet() pg_info-&gt;page is compared to a NULL value,&#xA;but then it is unconditionally passed to skb_add_rx_frag() which looks&#xA;strange and could lead to null pointer dereference.&#xA;lio_vf_rep_copy_packet() call trace looks like:&#xA;&#x9;octeon_droq_process_packets&#xA;&#x9; octeon_droq_fast_process_packets&#xA;&#x9;  octeon_droq_dispatch_pkt&#xA;&#x9;   octeon_create_recv_info&#xA;&#x9;    ...search in the dispatch_list...&#xA;&#x9;     -&gt;disp_fn(rdisp-&gt;rinfo, ...)&#xA;&#x9;      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)&#xA;In this path there is no code which sets pg_info-&gt;page to NULL.&#xA;So this check looks unneeded and doesn&#39;t solve potential problem.&#xA;But I guess the author had reason to add a check and I have no such card&#xA;and can&#39;t do real test.&#xA;In addition, the code in the function liquidio_push_packet() in&#xA;liquidio/lio_core.c does exactly the same.&#xA;Based on this, I consider the most acceptable compromise solution to&#xA;adjust this issue by moving skb_add_rx_frag() into conditional scope.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-40960:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: prevent possible NULL dereference in rt6_probe()&#xA;syzbot caught a NULL dereference in rt6_probe() [1]&#xA;Bail out if  __in6_dev_get() returns NULL.&#xA;[1]&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]&#xA;CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA; RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]&#xA; RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758&#xA;Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19&#xA;RSP: 0018:ffffc900034af070 EFLAGS: 00010203&#xA;RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000&#xA;RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c&#xA;RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000&#xA;R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a&#xA;R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000&#xA;FS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784&#xA;  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496&#xA;  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825&#xA;  find_rr_leaf net/ipv6/route.c:853 [inline]&#xA;  rt6_select net/ipv6/route.c:897 [inline]&#xA;  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195&#xA;  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231&#xA;  pol_lookup_func include/net/ip6_fib.h:616 [inline]&#xA;  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121&#xA;  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]&#xA;  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651&#xA;  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147&#xA;  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250&#xA;  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898&#xA;  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg net/socket.c:745 [inline]&#xA;  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160&#xA;  new_sync_write fs/read_write.c:497 [inline]&#xA;  vfs_write+0x6b6/0x1140 fs/read_write.c:590&#xA;  ksys_write+0x1f8/0x260 fs/read_write.c:643&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-36939:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfs: Handle error of rpc_proc_register() in nfs_net_init().&#xA;syzkaller reported a warning [0] triggered while destroying immature&#xA;netns.&#xA;rpc_proc_register() was called in init_nfs_fs(), but its error&#xA;has been ignored since at least the initial commit 1da177e4c3f4&#xA;(&#34;Linux-2.6.12-rc2&#34;).&#xA;Recently, commit d47151b79e32 (&#34;nfs: expose /proc/net/sunrpc/nfs&#xA;in net namespaces&#34;) converted the procfs to per-netns and made&#xA;the problem more visible.&#xA;Even when rpc_proc_register() fails, nfs_net_init() could succeed,&#xA;and thus nfs_net_exit() will be called while destroying the netns.&#xA;Then, remove_proc_entry() will be called for non-existing proc&#xA;directory and trigger the warning below.&#xA;Let&#39;s handle the error of rpc_proc_register() properly in nfs_net_init().&#xA;[0]:&#xA;name &#39;nfs&#39;&#xA;WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711&#xA;Modules linked in:&#xA;CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711&#xA;Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff &lt;0f&gt; 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb&#xA;RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286&#xA;RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c&#xA;RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001&#xA;RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc&#xA;R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8&#xA;FS:  00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310&#xA; nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438&#xA; ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170&#xA; setup_net+0x46c/0x660 net/core/net_namespace.c:372&#xA; copy_net_ns+0x244/0x590 net/core/net_namespace.c:505&#xA; create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110&#xA; unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228&#xA; ksys_unshare+0x342/0x760 kernel/fork.c:3322&#xA; __do_sys_unshare kernel/fork.c:3393 [inline]&#xA; __se_sys_unshare kernel/fork.c:3391 [inline]&#xA; __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x46/0x4e&#xA;RIP: 0033:0x7f30d0febe5d&#xA;Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48&#xA;RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110&#xA;RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600&#xA;RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002&#xA;R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000&#xA; &lt;/TASK&gt;&#xA;CVE-2022-48666:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: core: Fix a use-after-free&#xA;There are two .exit_cmd_priv implementations. Both implementations use&#xA;resources associated with the SCSI host. Make sure that these resources are&#xA;still available when .exit_cmd_priv is called by waiting inside&#xA;scsi_remove_host() until the tag set has been freed.&#xA;This commit fixes the following use-after-free:&#xA;==================================================================&#xA;BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]&#xA;Read of size 8 at addr ffff888100337000 by task multipathd/16727&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x34/0x44&#xA; print_report.cold+0x5e/0x5db&#xA; kasan_report+0xab/0x120&#xA; srp_exit_cmd_priv+0x27/0xd0 [ib_srp]&#xA; scsi_mq_exit_request+0x4d/0x70&#xA; blk_mq_free_rqs+0x143/0x410&#xA; __blk_mq_free_map_and_rqs+0x6e/0x100&#xA; blk_mq_free_tag_set+0x2b/0x160&#xA; scsi_host_dev_release+0xf3/0x1a0&#xA; device_release+0x54/0xe0&#xA; kobject_put+0xa5/0x120&#xA; device_release+0x54/0xe0&#xA; kobject_put+0xa5/0x120&#xA; scsi_device_dev_release_usercontext+0x4c1/0x4e0&#xA; execute_in_process_context+0x23/0x90&#xA; device_release+0x54/0xe0&#xA; kobject_put+0xa5/0x120&#xA; scsi_disk_release+0x3f/0x50&#xA; device_release+0x54/0xe0&#xA; kobject_put+0xa5/0x120&#xA; disk_release+0x17f/0x1b0&#xA; device_release+0x54/0xe0&#xA; kobject_put+0xa5/0x120&#xA; dm_put_table_device+0xa3/0x160 [dm_mod]&#xA; dm_put_device+0xd0/0x140 [dm_mod]&#xA; free_priority_group+0xd8/0x110 [dm_multipath]&#xA; free_multipath+0x94/0xe0 [dm_multipath]&#xA; dm_table_destroy+0xa2/0x1e0 [dm_mod]&#xA; __dm_destroy+0x196/0x350 [dm_mod]&#xA; dev_remove+0x10c/0x160 [dm_mod]&#xA; ctl_ioctl+0x2c2/0x590 [dm_mod]&#xA; dm_ctl_ioctl+0x5/0x10 [dm_mod]&#xA; __x64_sys_ioctl+0xb4/0xf0&#xA; dm_ctl_ioctl+0x5/0x10 [dm_mod]&#xA; __x64_sys_ioctl+0xb4/0xf0&#xA; do_syscall_64+0x3b/0x90&#xA; entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA;CVE-2021-47432:In the Linux kernel, the following vulnerability has been resolved:&#xA;lib/generic-radix-tree.c: Don&#39;t overflow in peek()&#xA;When we started spreading new inode numbers throughout most of the 64&#xA;bit inode space, that triggered some corner case bugs, in particular&#xA;some integer overflows related to the radix tree code. Oops.&#xA;CVE-2024-40983:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: force a dst refcount before doing decryption&#xA;As it says in commit 3bc07321ccc2 (&#34;xfrm: Force a dst refcount before&#xA;entering the xfrm type handlers&#34;):&#xA;&#34;Crypto requests might return asynchronous. In this case we leave the&#xA; rcu protected region, so force a refcount on the skb&#39;s destination&#xA; entry before we enter the xfrm type input/output handlers.&#34;&#xA;On TIPC decryption path it has the same problem, and skb_dst_force()&#xA;should be called before doing decryption to avoid a possible crash.&#xA;Shuang reported this issue when this warning is triggered:&#xA;  [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]&#xA;  [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug&#xA;  [] Workqueue: crypto cryptd_queue_worker&#xA;  [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]&#xA;  [] Call Trace:&#xA;  [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]&#xA;  [] tipc_rcv+0xcf5/0x1060 [tipc]&#xA;  [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]&#xA;  [] cryptd_aead_crypt+0xdb/0x190&#xA;  [] cryptd_queue_worker+0xed/0x190&#xA;  [] process_one_work+0x93d/0x17e0&#xA;CVE-2024-39499:In the Linux kernel, the following vulnerability has been resolved:&#xA;vmci: prevent speculation leaks by sanitizing event in event_deliver()&#xA;Coverity spotted that event_msg is controlled by user-space,&#xA;event_msg-&gt;event_data.event is passed to event_deliver() and used&#xA;as an index without sanitization.&#xA;This change ensures that the event index is sanitized to mitigate any&#xA;possibility of speculative information leaks.&#xA;This bug was discovered and resolved using Coverity Static Analysis&#xA;Security Testing (SAST) by Synopsys, Inc.&#xA;Only compile tested, no access to HW.&#xA;CVE-2024-40945:In the Linux kernel, the following vulnerability has been resolved:&#xA;iommu: Return right value in iommu_sva_bind_device()&#xA;iommu_sva_bind_device() should return either a sva bond handle or an&#xA;ERR_PTR value in error cases. Existing drivers (idxd and uacce) only&#xA;check the return value with IS_ERR(). This could potentially lead to&#xA;a kernel NULL pointer dereference issue if the function returns NULL&#xA;instead of an error pointer.&#xA;In reality, this doesn&#39;t cause any problems because iommu_sva_bind_device()&#xA;only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.&#xA;In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will&#xA;return an error, and the device drivers won&#39;t call iommu_sva_bind_device()&#xA;at all.&#xA;CVE-2024-37078:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential kernel bug due to lack of writeback flag waiting&#xA;Destructive writes to a block device on which nilfs2 is mounted can cause&#xA;a kernel bug in the folio/page writeback start routine or writeback end&#xA;routine (__folio_start_writeback in the log below):&#xA; kernel BUG at mm/page-writeback.c:3070!&#xA; Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI&#xA; ...&#xA; RIP: 0010:__folio_start_writeback+0xbaa/0x10e0&#xA; Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff&#xA;  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 &lt;0f&gt;&#xA;  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00&#xA; ...&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]&#xA;  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]&#xA;  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]&#xA;  kthread+0x2f0/0x390&#xA;  ret_from_fork+0x4b/0x80&#xA;  ret_from_fork_asm+0x1a/0x30&#xA;  &lt;/TASK&gt;&#xA;This is because when the log writer starts a writeback for segment summary&#xA;blocks or a super root block that use the backing device&#39;s page cache, it&#xA;does not wait for the ongoing folio/page writeback, resulting in an&#xA;inconsistent writeback state.&#xA;Fix this issue by waiting for ongoing writebacks when putting&#xA;folios/pages on the backing device into writeback state.&#xA;CVE-2024-40967:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: imx: Introduce timeout when waiting on transmitter empty&#xA;By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential&#xA;deadlock.&#xA;In case of the timeout, there is not much we can do, so we simply ignore&#xA;the transmitter state and optimistically try to continue.&#xA;CVE-2024-40987:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: fix UBSAN warning in kv_dpm.c&#xA;Adds bounds check for sumo_vid_mapping_entry.&#xA;CVE-2024-40995:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()&#xA;syzbot found hanging tasks waiting on rtnl_lock [1]&#xA;A reproducer is available in the syzbot bug.&#xA;When a request to add multiple actions with the same index is sent, the&#xA;second request will block forever on the first request. This holds&#xA;rtnl_lock, and causes tasks to hang.&#xA;Return -EAGAIN to prevent infinite looping, while keeping documented&#xA;behavior.&#xA;[1]&#xA;INFO: task kworker/1:0:5088 blocked for more than 143 seconds.&#xA;Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0&#xA;&#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA;task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000&#xA;Workqueue: events_power_efficient reg_check_chans_work&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;context_switch kernel/sched/core.c:5409 [inline]&#xA;__schedule+0xf15/0x5d00 kernel/sched/core.c:6746&#xA;__schedule_loop kernel/sched/core.c:6823 [inline]&#xA;schedule+0xe7/0x350 kernel/sched/core.c:6838&#xA;schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895&#xA;__mutex_lock_common kernel/locking/mutex.c:684 [inline]&#xA;__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752&#xA;wiphy_lock include/net/cfg80211.h:5953 [inline]&#xA;reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]&#xA;reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481&#xA;CVE-2024-38559:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qedf: Ensure the copied buf is NUL terminated&#xA;Currently, we allocate a count-sized kernel buffer and copy count from&#xA;userspace to that buffer. Later, we use kstrtouint on this buffer but we&#xA;don&#39;t ensure that the string is terminated inside the buffer, this can&#xA;lead to OOB read when using kstrtouint. Fix this issue by using&#xA;memdup_user_nul instead of memdup_user.&#xA;CVE-2024-38578:In the Linux kernel, the following vulnerability has been resolved:&#xA;ecryptfs: Fix buffer size for tag 66 packet&#xA;The &#39;TAG 66 Packet Format&#39; description is missing the cipher code and&#xA;checksum fields that are packed into the message packet. As a result,&#xA;the buffer allocated for the packet is 3 bytes too small and&#xA;write_tag_66_packet() will write up to 3 bytes past the end of the&#xA;buffer.&#xA;Fix this by increasing the size of the allocation so the whole packet&#xA;will always fit in the buffer.&#xA;This fixes the below kasan slab-out-of-bounds bug:&#xA;  BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0&#xA;  Write of size 1 at addr ffff88800afbb2a5 by task touch/181&#xA;  CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x4c/0x70&#xA;   print_report+0xc5/0x610&#xA;   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0&#xA;   ? kasan_complete_mode_report_info+0x44/0x210&#xA;   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0&#xA;   kasan_report+0xc2/0x110&#xA;   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0&#xA;   __asan_store1+0x62/0x80&#xA;   ecryptfs_generate_key_packet_set+0x7d6/0xde0&#xA;   ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10&#xA;   ? __alloc_pages+0x2e2/0x540&#xA;   ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]&#xA;   ? dentry_open+0x8f/0xd0&#xA;   ecryptfs_write_metadata+0x30a/0x550&#xA;   ? __pfx_ecryptfs_write_metadata+0x10/0x10&#xA;   ? ecryptfs_get_lower_file+0x6b/0x190&#xA;   ecryptfs_initialize_file+0x77/0x150&#xA;   ecryptfs_create+0x1c2/0x2f0&#xA;   path_openat+0x17cf/0x1ba0&#xA;   ? __pfx_path_openat+0x10/0x10&#xA;   do_filp_open+0x15e/0x290&#xA;   ? __pfx_do_filp_open+0x10/0x10&#xA;   ? __kasan_check_write+0x18/0x30&#xA;   ? _raw_spin_lock+0x86/0xf0&#xA;   ? __pfx__raw_spin_lock+0x10/0x10&#xA;   ? __kasan_check_write+0x18/0x30&#xA;   ? alloc_fd+0xf4/0x330&#xA;   do_sys_openat2+0x122/0x160&#xA;   ? __pfx_do_sys_openat2+0x10/0x10&#xA;   __x64_sys_openat+0xef/0x170&#xA;   ? __pfx___x64_sys_openat+0x10/0x10&#xA;   do_syscall_64+0x60/0xd0&#xA;   entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;  RIP: 0033:0x7f00a703fd67&#xA;  Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f&#xA;  RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101&#xA;  RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67&#xA;  RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c&#xA;  RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000&#xA;  R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941&#xA;  R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040&#xA;   &lt;/TASK&gt;&#xA;  Allocated by task 181:&#xA;   kasan_save_stack+0x2f/0x60&#xA;   kasan_set_track+0x29/0x40&#xA;   kasan_save_alloc_info+0x25/0x40&#xA;   __kasan_kmalloc+0xc5/0xd0&#xA;   __kmalloc+0x66/0x160&#xA;   ecryptfs_generate_key_packet_set+0x6d2/0xde0&#xA;   ecryptfs_write_metadata+0x30a/0x550&#xA;   ecryptfs_initialize_file+0x77/0x150&#xA;   ecryptfs_create+0x1c2/0x2f0&#xA;   path_openat+0x17cf/0x1ba0&#xA;   do_filp_open+0x15e/0x290&#xA;   do_sys_openat2+0x122/0x160&#xA;   __x64_sys_openat+0xef/0x170&#xA;   do_syscall_64+0x60/0xd0&#xA;   entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;CVE-2024-41004:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing: Build event generation tests only as modules&#xA;The kprobes and synth event generation test modules add events and lock&#xA;(get a reference) those event file reference in module init function,&#xA;and unlock and delete it in module exit function. This is because those&#xA;are designed for playing as modules.&#xA;If we make those modules as built-in, those events are left locked in the&#xA;kernel, and never be removed. This causes kprobe event self-test failure&#xA;as below.&#xA;[   97.349708] ------------[ cut here ]------------&#xA;[   97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480&#xA;[   97.357106] Modules linked in:&#xA;[   97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14&#xA;[   97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;[   97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480&#xA;[   97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 &lt;0f&gt; 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90&#xA;[   97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286&#xA;[   97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000&#xA;[   97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68&#xA;[   97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000&#xA;[   97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000&#xA;[   97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000&#xA;[   97.381536] FS:  0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000&#xA;[   97.383813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0&#xA;[   97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[   97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[   97.391196] Call Trace:&#xA;[   97.391967]  &lt;TASK&gt;&#xA;[   97.392647]  ? __warn+0xcc/0x180&#xA;[   97.393640]  ? kprobe_trace_self_tests_init+0x3f1/0x480&#xA;[   97.395181]  ? report_bug+0xbd/0x150&#xA;[   97.396234]  ? handle_bug+0x3e/0x60&#xA;[   97.397311]  ? exc_invalid_op+0x1a/0x50&#xA;[   97.398434]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[   97.399652]  ? trace_kprobe_is_busy+0x20/0x20&#xA;[   97.400904]  ? tracing_reset_all_online_cpus+0x15/0x90&#xA;[   97.402304]  ? kprobe_trace_self_tests_init+0x3f1/0x480&#xA;[   97.403773]  ? init_kprobe_trace+0x50/0x50&#xA;[   97.404972]  do_one_initcall+0x112/0x240&#xA;[   97.406113]  do_initcall_level+0x95/0xb0&#xA;[   97.407286]  ? kernel_init+0x1a/0x1a0&#xA;[   97.408401]  do_initcalls+0x3f/0x70&#xA;[   97.409452]  kernel_init_freeable+0x16f/0x1e0&#xA;[   97.410662]  ? rest_init+0x1f0/0x1f0&#xA;[   97.411738]  kernel_init+0x1a/0x1a0&#xA;[   97.412788]  ret_from_fork+0x39/0x50&#xA;[   97.413817]  ? rest_init+0x1f0/0x1f0&#xA;[   97.414844]  ret_from_fork_asm+0x11/0x20&#xA;[   97.416285]  &lt;/TASK&gt;&#xA;[   97.417134] irq event stamp: 13437323&#xA;[   97.418376] hardirqs last  enabled at (13437337): [&lt;ffffffff8110bc0c&gt;] console_unlock+0x11c/0x150&#xA;[   97.421285] hardirqs last disabled at (13437370): [&lt;ffffffff8110bbf1&gt;] console_unlock+0x101/0x150&#xA;[   97.423838] softirqs last  enabled at (13437366): [&lt;ffffffff8108e17f&gt;] handle_softirqs+0x23f/0x2a0&#xA;[   97.426450] softirqs last disabled at (13437393): [&lt;ffffffff8108e346&gt;] __irq_exit_rcu+0x66/0xd0&#xA;[   97.428850] ---[ end trace 0000000000000000 ]---&#xA;And also, since we can not cleanup dynamic_event file, ftracetest are&#xA;failed too.&#xA;To avoid these issues, build these tests only as modules.&#xA;CVE-2024-40929:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: check n_ssids before accessing the ssids&#xA;In some versions of cfg80211, the ssids poinet might be a valid one even&#xA;though n_ssids is 0. Accessing the pointer in this case will cuase an&#xA;out-of-bound access. Fix this by checking n_ssids first.&#xA;CVE-2024-40941:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: don&#39;t read past the mfuart notifcation&#xA;In case the firmware sends a notification that claims it has more data&#xA;than it has, we will read past that was allocated for the notification.&#xA;Remove the print of the buffer, we won&#39;t see it by default. If needed,&#xA;we can see the content with tracing.&#xA;This was reported by KFENCE.&#xA;CVE-2024-38618:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: timer: Set lower bound of start tick time&#xA;Currently ALSA timer doesn&#39;t have the lower limit of the start tick&#xA;time, and it allows a very small size, e.g. 1 tick with 1ns resolution&#xA;for hrtimer.  Such a situation may lead to an unexpected RCU stall,&#xA;where  the callback repeatedly queuing the expire update, as reported&#xA;by fuzzer.&#xA;This patch introduces a sanity check of the timer start tick time, so&#xA;that the system returns an error when a too small start size is set.&#xA;As of this patch, the lower limit is hard-coded to 100us, which is&#xA;small enough but can still work somehow.&#xA;CVE-2024-40968:In the Linux kernel, the following vulnerability has been resolved:&#xA;MIPS: Octeon: Add PCIe link status check&#xA;The standard PCIe configuration read-write interface is used to&#xA;access the configuration space of the peripheral PCIe devices&#xA;of the mips processor after the PCIe link surprise down, it can&#xA;generate kernel panic caused by &#34;Data bus error&#34;. So it is&#xA;necessary to add PCIe link status check for system protection.&#xA;When the PCIe link is down or in training, assigning a value&#xA;of 0 to the configuration address can prevent read-write behavior&#xA;to the configuration space of peripheral PCIe devices, thereby&#xA;preventing kernel panic.&#xA;CVE-2024-40912:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()&#xA;The ieee80211_sta_ps_deliver_wakeup() function takes sta-&gt;ps_lock to&#xA;synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from&#xA;softirq context. However using only spin_lock() to get sta-&gt;ps_lock in&#xA;ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute&#xA;on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to&#xA;take this same lock ending in deadlock. Below is an example of rcu stall&#xA;that arises in such situation.&#xA; rcu: INFO: rcu_sched self-detected stall on CPU&#xA; rcu:    2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996&#xA; rcu:    (t=42586894 jiffies g=2057 q=362405 ncpus=4)&#xA; CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G        W          6.4.0-02158-g1b062f552873 #742&#xA; Hardware name: RPT (r1) (DT)&#xA; pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : queued_spin_lock_slowpath+0x58/0x2d0&#xA; lr : invoke_tx_handlers_early+0x5b4/0x5c0&#xA; sp : ffff00001ef64660&#xA; x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8&#xA; x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000&#xA; x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000&#xA; x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000&#xA; x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80&#xA; x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da&#xA; x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440&#xA; x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880&#xA; x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000&#xA; x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8&#xA; Call trace:&#xA;  queued_spin_lock_slowpath+0x58/0x2d0&#xA;  ieee80211_tx+0x80/0x12c&#xA;  ieee80211_tx_pending+0x110/0x278&#xA;  tasklet_action_common.constprop.0+0x10c/0x144&#xA;  tasklet_action+0x20/0x28&#xA;  _stext+0x11c/0x284&#xA;  ____do_softirq+0xc/0x14&#xA;  call_on_irq_stack+0x24/0x34&#xA;  do_softirq_own_stack+0x18/0x20&#xA;  do_softirq+0x74/0x7c&#xA;  __local_bh_enable_ip+0xa0/0xa4&#xA;  _ieee80211_wake_txqs+0x3b0/0x4b8&#xA;  __ieee80211_wake_queue+0x12c/0x168&#xA;  ieee80211_add_pending_skbs+0xec/0x138&#xA;  ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480&#xA;  ieee80211_mps_sta_status_update.part.0+0xd8/0x11c&#xA;  ieee80211_mps_sta_status_update+0x18/0x24&#xA;  sta_apply_parameters+0x3bc/0x4c0&#xA;  ieee80211_change_station+0x1b8/0x2dc&#xA;  nl80211_set_station+0x444/0x49c&#xA;  genl_family_rcv_msg_doit.isra.0+0xa4/0xfc&#xA;  genl_rcv_msg+0x1b0/0x244&#xA;  netlink_rcv_skb+0x38/0x10c&#xA;  genl_rcv+0x34/0x48&#xA;  netlink_unicast+0x254/0x2bc&#xA;  netlink_sendmsg+0x190/0x3b4&#xA;  ____sys_sendmsg+0x1e8/0x218&#xA;  ___sys_sendmsg+0x68/0x8c&#xA;  __sys_sendmsg+0x44/0x84&#xA;  __arm64_sys_sendmsg+0x20/0x28&#xA;  do_el0_svc+0x6c/0xe8&#xA;  el0_svc+0x14/0x48&#xA;  el0t_64_sync_handler+0xb0/0xb4&#xA;  el0t_64_sync+0x14c/0x150&#xA;Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise&#xA;on the same CPU that is holding the lock.&#xA;CVE-2024-40990:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/mlx5: Add check for srq max_sge attribute&#xA;max_sge attribute is passed by the user, and is inserted and used&#xA;unchecked, so verify that the value doesn&#39;t exceed maximum allowed value&#xA;before using it.&#xA;CVE-2024-40980:In the Linux kernel, the following vulnerability has been resolved:&#xA;drop_monitor: replace spin_lock by raw_spin_lock&#xA;trace_drop_common() is called with preemption disabled, and it acquires&#xA;a spin_lock. This is problematic for RT kernels because spin_locks are&#xA;sleeping locks in this configuration, which causes the following splat:&#xA;BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48&#xA;in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47&#xA;preempt_count: 1, expected: 0&#xA;RCU nest depth: 2, expected: 2&#xA;5 locks held by rcuc/47/449:&#xA; #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210&#xA; #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130&#xA; #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210&#xA; #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70&#xA; #4: ff1100086ee07520 (&amp;data-&gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290&#xA;irq event stamp: 139909&#xA;hardirqs last  enabled at (139908): [&lt;ffffffffb1df2b33&gt;] _raw_spin_unlock_irqrestore+0x63/0x80&#xA;hardirqs last disabled at (139909): [&lt;ffffffffb19bd03d&gt;] trace_drop_common.constprop.0+0x26d/0x290&#xA;softirqs last  enabled at (139892): [&lt;ffffffffb07a1083&gt;] __local_bh_enable_ip+0x103/0x170&#xA;softirqs last disabled at (139898): [&lt;ffffffffb0909b33&gt;] rcu_cpu_kthread+0x93/0x1f0&#xA;Preemption disabled at:&#xA;[&lt;ffffffffb1de786b&gt;] rt_mutex_slowunlock+0xab/0x2e0&#xA;CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7&#xA;Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x8c/0xd0&#xA; dump_stack+0x14/0x20&#xA; __might_resched+0x21e/0x2f0&#xA; rt_spin_lock+0x5e/0x130&#xA; ? trace_drop_common.constprop.0+0xb5/0x290&#xA; ? skb_queue_purge_reason.part.0+0x1bf/0x230&#xA; trace_drop_common.constprop.0+0xb5/0x290&#xA; ? preempt_count_sub+0x1c/0xd0&#xA; ? _raw_spin_unlock_irqrestore+0x4a/0x80&#xA; ? __pfx_trace_drop_common.constprop.0+0x10/0x10&#xA; ? rt_mutex_slowunlock+0x26a/0x2e0&#xA; ? skb_queue_purge_reason.part.0+0x1bf/0x230&#xA; ? __pfx_rt_mutex_slowunlock+0x10/0x10&#xA; ? skb_queue_purge_reason.part.0+0x1bf/0x230&#xA; trace_kfree_skb_hit+0x15/0x20&#xA; trace_kfree_skb+0xe9/0x150&#xA; kfree_skb_reason+0x7b/0x110&#xA; skb_queue_purge_reason.part.0+0x1bf/0x230&#xA; ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10&#xA; ? mark_lock.part.0+0x8a/0x520&#xA;...&#xA;trace_drop_common() also disables interrupts, but this is a minor issue&#xA;because we could easily replace it with a local_lock.&#xA;Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic&#xA;context.&#xA;CVE-2024-34777:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma-mapping: benchmark: fix node id validation&#xA;While validating node ids in map_benchmark_ioctl(), node_possible() may&#xA;be provided with invalid argument outside of [0,MAX_NUMNODES-1] range&#xA;leading to:&#xA;BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)&#xA;Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971&#xA;CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;dump_stack_lvl (lib/dump_stack.c:117)&#xA;kasan_report (mm/kasan/report.c:603)&#xA;kasan_check_range (mm/kasan/generic.c:189)&#xA;variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]&#xA;arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]&#xA;_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]&#xA;node_state (include/linux/nodemask.h:423) [inline]&#xA;map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)&#xA;full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)&#xA;__x64_sys_ioctl (fs/ioctl.c:890)&#xA;do_syscall_64 (arch/x86/entry/common.c:83)&#xA;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;Compare node ids with sane bounds first. NUMA_NO_NODE is considered a&#xA;special valid case meaning that benchmarking kthreads won&#39;t be bound to a&#xA;cpuset of a given node.&#xA;Found by Linux Verification Center (linuxtesting.org).&#xA;CVE-2022-48814:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: dsa: seville: register the mdiobus under devres&#xA;As explained in commits:&#xA;74b6d7d13307 (&#34;net: dsa: realtek: register the MDIO bus under devres&#34;)&#xA;5135e96a3dd2 (&#34;net: dsa: don&#39;t allocate the slave_mii_bus using devres&#34;)&#xA;mdiobus_free() will panic when called from devm_mdiobus_free() &lt;-&#xA;devres_release_all() &lt;- __device_release_driver(), and that mdiobus was&#xA;not previously unregistered.&#xA;The Seville VSC9959 switch is a platform device, so the initial set of&#xA;constraints that I thought would cause this (I2C or SPI buses which call&#xA;-&gt;remove on -&gt;shutdown) do not apply. But there is one more which&#xA;applies here.&#xA;If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown&#xA;(like dpaa2-eth, which is on the fsl-mc bus), there is a device link&#xA;between the switch and the DSA master, and device_links_unbind_consumers()&#xA;will unbind the seville switch driver on shutdown.&#xA;So the same treatment must be applied to all DSA switch drivers, which&#xA;is: either use devres for both the mdiobus allocation and registration,&#xA;or don&#39;t use devres at all.&#xA;The seville driver has a code structure that could accommodate both the&#xA;mdiobus_unregister and mdiobus_free calls, but it has an external&#xA;dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls&#xA;devm_mdiobus_alloc_size() on its behalf. So rather than restructuring&#xA;that, and exporting yet one more symbol mscc_miim_teardown(), let&#39;s work&#xA;with devres and replace of_mdiobus_register with the devres variant.&#xA;When we use all-devres, we can ensure that devres doesn&#39;t free a&#xA;still-registered bus (it either runs both callbacks, or none).&#xA;CVE-2024-38568:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group&#xA;The perf tool allows users to create event groups through following&#xA;cmd [1], but the driver does not check whether the array index is out&#xA;of bounds when writing data to the event_group array. If the number of&#xA;events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the&#xA;memory write overflow of event_group array occurs.&#xA;Add array index check to fix the possible array out of bounds violation,&#xA;and return directly when write new events are written to array bounds.&#xA;There are 9 different events in an event_group.&#xA;[1] perf stat -e &#39;{pmu/event1/, ... ,pmu/event9/}&#xA;CVE-2024-35837:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: mvpp2: clear BM pool before initialization&#xA;Register value persist after booting the kernel using&#xA;kexec which results in kernel panic. Thus clear the&#xA;BM pool registers before initialisation to fix the issue.&#xA;CVE-2024-41009:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix overrunning reservations in ringbuf&#xA;The BPF ring buffer internally is implemented as a power-of-2 sized circular&#xA;buffer, with two logical and ever-increasing counters: consumer_pos is the&#xA;consumer counter to show which logical position the consumer consumed the&#xA;data, and producer_pos which is the producer counter denoting the amount of&#xA;data reserved by all producers.&#xA;Each time a record is reserved, the producer that &#34;owns&#34; the record will&#xA;successfully advance producer counter. In user space each time a record is&#xA;read, the consumer of the data advanced the consumer counter once it finished&#xA;processing. Both counters are stored in separate pages so that from user&#xA;space, the producer counter is read-only and the consumer counter is read-write.&#xA;One aspect that simplifies and thus speeds up the implementation of both&#xA;producers and consumers is how the data area is mapped twice contiguously&#xA;back-to-back in the virtual memory, allowing to not take any special measures&#xA;for samples that have to wrap around at the end of the circular buffer data&#xA;area, because the next page after the last data page would be first data page&#xA;again, and thus the sample will still appear completely contiguous in virtual&#xA;memory.&#xA;Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for&#xA;book-keeping the length and offset, and is inaccessible to the BPF program.&#xA;Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`&#xA;for the BPF program to use. Bing-Jhong and Muhammad reported that it is however&#xA;possible to make a second allocated memory chunk overlapping with the first&#xA;chunk and as a result, the BPF program is now able to edit first chunk&#39;s&#xA;header.&#xA;For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size&#xA;of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to&#xA;bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in&#xA;[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets&#xA;allocate a chunk B with size 0x3000. This will succeed because consumer_pos&#xA;was edited ahead of time to pass the `new_prod_pos - cons_pos &gt; rb-&gt;mask`&#xA;check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able&#xA;to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned&#xA;earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data&#xA;pages. This means that chunk B at [0x4000,0x4008] is chunk A&#39;s header.&#xA;bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header&#39;s pg_off to then&#xA;locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk&#xA;B modified chunk A&#39;s header, then bpf_ringbuf_commit() refers to the wrong&#xA;page and could cause a crash.&#xA;Fix it by calculating the oldest pending_pos and check whether the range&#xA;from the oldest outstanding record to the newest would span beyond the ring&#xA;buffer size. If that is the case, then reject the request. We&#39;ve tested with&#xA;the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)&#xA;before/after the fix and while it seems a bit slower on some benchmarks, it&#xA;is still not significantly enough to matter.&#xA;CVE-2024-35931:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Skip do PCI error slot reset during RAS recovery&#xA;Why:&#xA;    The PCI error slot reset maybe triggered after inject ue to UMC multi times, this&#xA;    caused system hang.&#xA;    [  557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume&#xA;    [  557.373718] [drm] PCIE GART of 512M enabled.&#xA;    [  557.373722] [drm] PTB located at 0x0000031FED700000&#xA;    [  557.373788] [drm] VRAM is lost due to GPU reset!&#xA;    [  557.373789] [drm] PSP is resuming...&#xA;    [  557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset&#xA;    [  557.547067] [drm] PCI error: detected callback, state(1)!!&#xA;    [  557.547069] [drm] No support for XGMI hive yet...&#xA;    [  557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter&#xA;    [  557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations&#xA;    [  557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered&#xA;    [  557.610492] [drm] PCI error: slot reset callback!!&#xA;    ...&#xA;    [  560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!&#xA;    [  560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!&#xA;    [  560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI&#xA;    [  560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G           OE     5.15.0-91-generic #101-Ubuntu&#xA;    [  560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023&#xA;    [  560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]&#xA;    [  560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]&#xA;    [  560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff &lt;48&gt; 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00&#xA;    [  560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202&#xA;    [  560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0&#xA;    [  560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010&#xA;    [  560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08&#xA;    [  560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000&#xA;    [  560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000&#xA;    [  560.803889] FS:  0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000&#xA;    [  560.812973] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;    [  560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0&#xA;    [  560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;    [  560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400&#xA;    [  560.843444] PKRU: 55555554&#xA;    [  560.846480] Call Trace:&#xA;    [  560.849225]  &lt;TASK&gt;&#xA;    [  560.851580]  ? show_trace_log_lvl+0x1d6/0x2ea&#xA;    [  560.856488]  ? show_trace_log_lvl+0x1d6/0x2ea&#xA;    [  560.861379]  ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]&#xA;    [  560.867778]  ? show_regs.part.0+0x23/0x29&#xA;    [  560.872293]  ? __die_body.cold+0x8/0xd&#xA;    [  560.876502]  ? die_addr+0x3e/0x60&#xA;    [  560.880238]  ? exc_general_protection+0x1c5/0x410&#xA;    [  560.885532]  ? asm_exc_general_protection+0x27/0x30&#xA;    [  560.891025]  ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]&#xA;    [  560.898323]  amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]&#xA;    [  560.904520]  process_one_work+0x228/0x3d0&#xA;How:&#xA;    In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected&#xA;    all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.&#xA;CVE-2024-39494:In the Linux kernel, the following vulnerability has been resolved:ima: Fix use-after-free on a dentry s dname.name-&gt;d_name.name can change on rename and the earlier value can be freed;there are conditions sufficient to stabilize it (-&gt;d_lock on dentry,-&gt;d_lock on its parent, -&gt;i_rwsem exclusive on the parent s inode,rename_lock), but none of those are met at any of the sites. Take a stablesnapshot of the name instead.&#xA;CVE-2024-41007:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: avoid too many retransmit packets&#xA;If a TCP socket is using TCP_USER_TIMEOUT, and the other peer&#xA;retracted its window to zero, tcp_retransmit_timer() can&#xA;retransmit a packet every two jiffies (2 ms for HZ=1000),&#xA;for about 4 minutes after TCP_USER_TIMEOUT has &#39;expired&#39;.&#xA;The fix is to make sure tcp_rtx_probe0_timed_out() takes&#xA;icsk-&gt;icsk_user_timeout into account.&#xA;Before blamed commit, the socket would not timeout after&#xA;icsk-&gt;icsk_user_timeout, but would use standard exponential&#xA;backoff for the retransmits.&#xA;Also worth noting that before commit e89688e3e978 (&#34;net: tcp:&#xA;fix unexcepted socket die when snd_wnd is 0&#34;), the issue&#xA;would last 2 minutes instead of 4.&#xA;CVE-2024-40947:In the Linux kernel, the following vulnerability has been resolved:&#xA;ima: Avoid blocking in RCU read-side critical section&#xA;A panic happens in ima_match_policy:&#xA;BUG: unable to handle kernel NULL pointer dereference at 0000000000000010&#xA;PGD 42f873067 P4D 0&#xA;Oops: 0000 [#1] SMP NOPTI&#xA;CPU: 5 PID: 1286325 Comm: kubeletmonit.sh&#xA;Kdump: loaded Tainted: P&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),&#xA;               BIOS 0.0.0 02/06/2015&#xA;RIP: 0010:ima_match_policy+0x84/0x450&#xA;Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39&#xA;      7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d&#xA;      f2 b9 f4 00 0f 84 9c 01 00 00 &lt;44&gt; 85 73 10 74 ea&#xA;      44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f&#xA;RSP: 0018:ff71570009e07a80 EFLAGS: 00010207&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200&#xA;RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000&#xA;RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739&#xA;R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970&#xA;R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001&#xA;FS:  00007f5195b51740(0000)&#xA;GS:ff3e278b12d40000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; ima_get_action+0x22/0x30&#xA; process_measurement+0xb0/0x830&#xA; ? page_add_file_rmap+0x15/0x170&#xA; ? alloc_set_pte+0x269/0x4c0&#xA; ? prep_new_page+0x81/0x140&#xA; ? simple_xattr_get+0x75/0xa0&#xA; ? selinux_file_open+0x9d/0xf0&#xA; ima_file_check+0x64/0x90&#xA; path_openat+0x571/0x1720&#xA; do_filp_open+0x9b/0x110&#xA; ? page_counter_try_charge+0x57/0xc0&#xA; ? files_cgroup_alloc_fd+0x38/0x60&#xA; ? __alloc_fd+0xd4/0x250&#xA; ? do_sys_open+0x1bd/0x250&#xA; do_sys_open+0x1bd/0x250&#xA; do_syscall_64+0x5d/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x65/0xca&#xA;Commit c7423dbdbc9e (&#34;ima: Handle -ESTALE returned by&#xA;ima_filter_rule_match()&#34;) introduced call to ima_lsm_copy_rule within a&#xA;RCU read-side critical section which contains kmalloc with GFP_KERNEL.&#xA;This implies a possible sleep and violates limitations of RCU read-side&#xA;critical sections on non-PREEMPT systems.&#xA;Sleeping within RCU read-side critical section might cause&#xA;synchronize_rcu() returning early and break RCU protection, allowing a&#xA;UAF to happen.&#xA;The root cause of this issue could be described as follows:&#xA;|&#x9;Thread A&#x9;|&#x9;Thread B&#x9;|&#xA;|&#x9;&#x9;&#x9;|ima_match_policy&#x9;|&#xA;|&#x9;&#x9;&#x9;|  rcu_read_lock&#x9;|&#xA;|ima_lsm_update_rule&#x9;|&#x9;&#x9;&#x9;|&#xA;|  synchronize_rcu&#x9;|&#x9;&#x9;&#x9;|&#xA;|&#x9;&#x9;&#x9;|    kmalloc(GFP_KERNEL)|&#xA;|&#x9;&#x9;&#x9;|      sleep&#x9;&#x9;|&#xA;==&gt; synchronize_rcu returns early&#xA;|  kfree(entry)&#x9;&#x9;|&#x9;&#x9;&#x9;|&#xA;|&#x9;&#x9;&#x9;|    entry = entry-&gt;next|&#xA;==&gt; UAF happens and entry now becomes NULL (or could be anything).&#xA;|&#x9;&#x9;&#x9;|    entry-&gt;action&#x9;|&#xA;==&gt; Accessing entry might cause panic.&#xA;To fix this issue, we are converting all kmalloc that is called within&#xA;RCU read-side critical section to use GFP_ATOMIC.&#xA;[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]&#xA;CVE-2022-48844:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: hci_core: Fix leaking sent_cmd skb&#xA;sent_cmd memory is not freed before freeing hci_dev causing it to leak&#xA;it contents.&#xA;CVE-2024-40982:In the Linux kernel, the following vulnerability has been resolved:&#xA;ssb: Fix potential NULL pointer dereference in ssb_device_uevent()&#xA;The ssb_device_uevent() function first attempts to convert the &#39;dev&#39; pointer&#xA;to &#39;struct ssb_device *&#39;. However, it mistakenly dereferences &#39;dev&#39; before&#xA;performing the NULL check, potentially leading to a NULL pointer&#xA;dereference if &#39;dev&#39; is NULL.&#xA;To fix this issue, move the NULL check before dereferencing the &#39;dev&#39; pointer,&#xA;ensuring that the pointer is valid before attempting to use it.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-39475:In the Linux kernel, the following vulnerability has been resolved:&#xA;fbdev: savage: Handle err return when savagefb_check_var failed&#xA;The commit 04e5eac8f3ab(&#34;fbdev: savage: Error out if pixclock equals zero&#34;)&#xA;checks the value of pixclock to avoid divide-by-zero error. However&#xA;the function savagefb_probe doesn&#39;t handle the error return of&#xA;savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.&#xA;CVE-2024-40956:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list&#xA;Use list_for_each_entry_safe() to allow iterating through the list and&#xA;deleting the entry in the iteration process. The descriptor is freed via&#xA;idxd_desc_complete() and there&#39;s a slight chance may cause issue for&#xA;the list iterator when the descriptor is reused by another thread&#xA;without it being deleted from the list.&#xA;CVE-2024-40981:In the Linux kernel, the following vulnerability has been resolved:&#xA;batman-adv: bypass empty buckets in batadv_purge_orig_ref()&#xA;Many syzbot reports are pointing to soft lockups in&#xA;batadv_purge_orig_ref() [1]&#xA;Root cause is unknown, but we can avoid spending too much&#xA;time there and perhaps get more interesting reports.&#xA;[1]&#xA;watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]&#xA;Modules linked in:&#xA;irq event stamp: 6182794&#xA; hardirqs last  enabled at (6182793): [&lt;ffff8000801dae10&gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386&#xA; hardirqs last disabled at (6182794): [&lt;ffff80008ad66a78&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]&#xA; hardirqs last disabled at (6182794): [&lt;ffff80008ad66a78&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551&#xA; softirqs last  enabled at (6182792): [&lt;ffff80008aab71c4&gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]&#xA; softirqs last  enabled at (6182792): [&lt;ffff80008aab71c4&gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287&#xA; softirqs last disabled at (6182790): [&lt;ffff80008aab61dc&gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA; softirqs last disabled at (6182790): [&lt;ffff80008aab61dc&gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271&#xA;CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024&#xA;Workqueue: bat_events batadv_purge_orig&#xA;pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]&#xA; pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388&#xA; lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386&#xA;sp : ffff800099007970&#xA;x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000&#xA;x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001&#xA;x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4&#xA;x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0&#xA;x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001&#xA;x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003&#xA;x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000&#xA;x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000&#xA;x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000&#xA;x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000&#xA;Call trace:&#xA;  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]&#xA;  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]&#xA;  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386&#xA;  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]&#xA;  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210&#xA;  spin_unlock_bh include/linux/spinlock.h:396 [inline]&#xA;  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287&#xA;  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300&#xA;  process_one_work+0x694/0x1204 kernel/workqueue.c:2633&#xA;  process_scheduled_works kernel/workqueue.c:2706 [inline]&#xA;  worker_thread+0x938/0xef4 kernel/workqueue.c:2787&#xA;  kthread+0x288/0x310 kernel/kthread.c:388&#xA;  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860&#xA;Sending NMI from CPU 0 to CPUs 1:&#xA;NMI backtrace for cpu 1&#xA;CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024&#xA;pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51&#xA; lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103&#xA;sp : ffff800093a17d30&#xA;x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4&#xA;x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002&#xA;x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000&#xA;x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396&#xA;x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001&#xA;---truncated---&#xA;CVE-2024-40904:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages&#xA;The syzbot fuzzer found that the interrupt-URB completion callback in&#xA;the cdc-wdm driver was taking too long, and the driver&#39;s immediate&#xA;resubmission of interrupt URBs with -EPROTO status combined with the&#xA;dummy-hcd emulation to cause a CPU lockup:&#xA;cdc_wdm 1-1:1.0: nonzero urb status received: -71&#xA;cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes&#xA;watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]&#xA;CPU#0 Utilization every 4s during lockup:&#xA;&#x9;#1:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#xA;&#x9;#2:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#xA;&#x9;#3:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#xA;&#x9;#4:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#xA;&#x9;#5:  98% system,&#x9;  1% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#xA;Modules linked in:&#xA;irq event stamp: 73096&#xA;hardirqs last  enabled at (73095): [&lt;ffff80008037bc00&gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]&#xA;hardirqs last  enabled at (73095): [&lt;ffff80008037bc00&gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994&#xA;hardirqs last disabled at (73096): [&lt;ffff80008af10b00&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]&#xA;hardirqs last disabled at (73096): [&lt;ffff80008af10b00&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551&#xA;softirqs last  enabled at (73048): [&lt;ffff8000801ea530&gt;] softirq_handle_end kernel/softirq.c:400 [inline]&#xA;softirqs last  enabled at (73048): [&lt;ffff8000801ea530&gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582&#xA;softirqs last disabled at (73043): [&lt;ffff800080020de8&gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588&#xA;CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA;Testing showed that the problem did not occur if the two error&#xA;messages -- the first two lines above -- were removed; apparently adding&#xA;material to the kernel log takes a surprisingly large amount of time.&#xA;In any case, the best approach for preventing these lockups and to&#xA;avoid spamming the log with thousands of error messages per second is&#xA;to ratelimit the two dev_err() calls.  Therefore we replace them with&#xA;dev_err_ratelimited().&#xA;CVE-2024-39509:In the Linux kernel, the following vulnerability has been resolved:&#xA;HID: core: remove unnecessary WARN_ON() in implement()&#xA;Syzkaller hit a warning [1] in a call to implement() when trying&#xA;to write a value into a field of smaller size in an output report.&#xA;Since implement() already has a warn message printed out with the&#xA;help of hid_warn() and value in question gets trimmed with:&#xA;&#x9;...&#xA;&#x9;value &amp;= m;&#xA;&#x9;...&#xA;WARN_ON may be considered superfluous. Remove it to suppress future&#xA;syzkaller triggers.&#xA;[1]&#xA;WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]&#xA;WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863&#xA;Modules linked in:&#xA;CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA;RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]&#xA;RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]&#xA; usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636&#xA; hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:904 [inline]&#xA; __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;...&#xA;CVE-2023-52679:In the Linux kernel, the following vulnerability has been resolved:&#xA;of: Fix double free in of_parse_phandle_with_args_map&#xA;In of_parse_phandle_with_args_map() the inner loop that&#xA;iterates through the map entries calls of_node_put(new)&#xA;to free the reference acquired by the previous iteration&#xA;of the inner loop. This assumes that the value of &#34;new&#34; is&#xA;NULL on the first iteration of the inner loop.&#xA;Make sure that this is true in all iterations of the outer&#xA;loop by setting &#34;new&#34; to NULL after its value is assigned to &#34;cur&#34;.&#xA;Extend the unittest to detect the double free and add an additional&#xA;test case that actually triggers this path.&#xA;CVE-2024-38619:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb-storage: alauda: Check whether the media is initialized&#xA;The member &#34;uzonesize&#34; of struct alauda_info will remain 0&#xA;if alauda_init_media() fails, potentially causing divide errors&#xA;in alauda_read_data() and alauda_write_lba().&#xA;- Add a member &#34;media_initialized&#34; to struct alauda_info.&#xA;- Change a condition in alauda_check_media() to ensure the&#xA;  first initialization.&#xA;- Add an error check for the return value of alauda_init_media().&#xA;CVE-2022-48859:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr&#xA;This node pointer is returned by of_find_compatible_node() with&#xA;refcount incremented. Calling of_node_put() to aovid the refcount leak.&#xA;CVE-2024-40915:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context&#xA;__kernel_map_pages() is a debug function which clears the valid bit in page&#xA;table entry for deallocated pages to detect illegal memory accesses to&#xA;freed pages.&#xA;This function set/clear the valid bit using __set_memory(). __set_memory()&#xA;acquires init_mm&#39;s semaphore, and this operation may sleep. This is&#xA;problematic, because  __kernel_map_pages() can be called in atomic context,&#xA;and thus is illegal to sleep. An example warning that this causes:&#xA;BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578&#xA;in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd&#xA;preempt_count: 2, expected: 0&#xA;CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37&#xA;Hardware name: riscv-virtio,qemu (DT)&#xA;Call Trace:&#xA;[&lt;ffffffff800060dc&gt;] dump_backtrace+0x1c/0x24&#xA;[&lt;ffffffff8091ef6e&gt;] show_stack+0x2c/0x38&#xA;[&lt;ffffffff8092baf8&gt;] dump_stack_lvl+0x5a/0x72&#xA;[&lt;ffffffff8092bb24&gt;] dump_stack+0x14/0x1c&#xA;[&lt;ffffffff8003b7ac&gt;] __might_resched+0x104/0x10e&#xA;[&lt;ffffffff8003b7f4&gt;] __might_sleep+0x3e/0x62&#xA;[&lt;ffffffff8093276a&gt;] down_write+0x20/0x72&#xA;[&lt;ffffffff8000cf00&gt;] __set_memory+0x82/0x2fa&#xA;[&lt;ffffffff8000d324&gt;] __kernel_map_pages+0x5a/0xd4&#xA;[&lt;ffffffff80196cca&gt;] __alloc_pages_bulk+0x3b2/0x43a&#xA;[&lt;ffffffff8018ee82&gt;] __vmalloc_node_range+0x196/0x6ba&#xA;[&lt;ffffffff80011904&gt;] copy_process+0x72c/0x17ec&#xA;[&lt;ffffffff80012ab4&gt;] kernel_clone+0x60/0x2fe&#xA;[&lt;ffffffff80012f62&gt;] kernel_thread+0x82/0xa0&#xA;[&lt;ffffffff8003552c&gt;] kthreadd+0x14a/0x1be&#xA;[&lt;ffffffff809357de&gt;] ret_from_fork+0xe/0x1c&#xA;Rewrite this function with apply_to_existing_page_range(). It is fine to&#xA;not have any locking, because __kernel_map_pages() works with pages being&#xA;allocated/deallocated and those pages are not changed by anyone else in the&#xA;meantime.&#xA;CVE-2021-47205:In the Linux kernel, the following vulnerability has been resolved:&#xA;clk: sunxi-ng: Unregister clocks/resets when unbinding&#xA;Currently, unbinding a CCU driver unmaps the device&#39;s MMIO region, while&#xA;leaving its clocks/resets and their providers registered. This can cause&#xA;a page fault later when some clock operation tries to perform MMIO. Fix&#xA;this by separating the CCU initialization from the memory allocation,&#xA;and then using a devres callback to unregister the clocks and resets.&#xA;This also fixes a memory leak of the `struct ccu_reset`, and uses the&#xA;correct owner (the specific platform driver) for the clocks and resets.&#xA;Early OF clock providers are never unregistered, and limited error&#xA;handling is possible, so they are mostly unchanged. The error reporting&#xA;is made more consistent by moving the message inside of_sunxi_ccu_probe.&#xA;CVE-2024-38611:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: i2c: et8ek8: Don&#39;t strip remove function when driver is builtin&#xA;Using __exit for the remove function results in the remove callback&#xA;being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets&#xA;unbound (e.g. using sysfs or hotplug), the driver is just removed&#xA;without the cleanup being performed. This results in resource leaks. Fix&#xA;it by compiling in the remove callback unconditionally.&#xA;This also fixes a W=1 modpost warning:&#xA;&#x9;WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -&gt; et8ek8_remove (section: .exit.text)&#xA;CVE-2024-41011:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdkfd: don&#39;t allow mapping the MMIO HDP page with large pages&#xA;We don&#39;t get the right offset in that case.  The GPU has&#xA;an unused 4K area of the register BAR space into which you can&#xA;remap registers.  We remap the HDP flush registers into this&#xA;space to allow userspace (CPU or GPU) to flush the HDP when it&#xA;updates VRAM.  However, on systems with &gt;4K pages, we end up&#xA;exposing PAGE_SIZE of MMIO space.&#xA;CVE-2024-40988:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/radeon: fix UBSAN warning in kv_dpm.c&#xA;Adds bounds check for sumo_vid_mapping_entry.&#xA;CVE-2024-42090:In the Linux kernel, the following vulnerability has been resolved:&#xA;pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER&#xA;In create_pinctrl(), pinctrl_maps_mutex is acquired before calling&#xA;add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()&#xA;calls pinctrl_free(). However, pinctrl_free() attempts to acquire&#xA;pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to&#xA;a potential deadlock.&#xA;This patch resolves the issue by releasing pinctrl_maps_mutex before&#xA;calling pinctrl_free(), preventing the deadlock.&#xA;This bug was discovered and resolved using Coverity Static Analysis&#xA;Security Testing (SAST) by Synopsys, Inc.&#xA;CVE-2024-41069:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: topology: Fix references to freed memory&#xA;Most users after parsing a topology file, release memory used by it, so&#xA;having pointer references directly into topology file contents is wrong.&#xA;Use devm_kmemdup(), to allocate memory as needed.&#xA;CVE-2024-38627:In the Linux kernel, the following vulnerability has been resolved:&#xA;stm class: Fix a double free in stm_register_device()&#xA;The put_device(&amp;stm-&gt;dev) call will trigger stm_device_release() which&#xA;frees &#34;stm&#34; so the vfree(stm) on the next line is a double free.&#xA;CVE-2024-38561:In the Linux kernel, the following vulnerability has been resolved:&#xA;kunit: Fix kthread reference&#xA;There is a race condition when a kthread finishes after the deadline and&#xA;before the call to kthread_stop(), which may lead to use after free.&#xA;CVE-2021-47382:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/qeth: fix deadlock during failing recovery&#xA;Commit 0b9902c1fcc5 (&#34;s390/qeth: fix deadlock during recovery&#34;) removed&#xA;taking discipline_mutex inside qeth_do_reset(), fixing potential&#xA;deadlocks. An error path was missed though, that still takes&#xA;discipline_mutex and thus has the original deadlock potential.&#xA;Intermittent deadlocks were seen when a qeth channel path is configured&#xA;offline, causing a race between qeth_do_reset and ccwgroup_remove.&#xA;Call qeth_set_offline() directly in the qeth_do_reset() error case and&#xA;then a new variant of ccwgroup_set_offline(), without taking&#xA;discipline_mutex.&#xA;CVE-2024-41040:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: Fix UAF when resolving a clash&#xA;KASAN reports the following UAF:&#xA; BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]&#xA; Read of size 1 at addr ffff888c07603600 by task handler130/6469&#xA; Call Trace:&#xA;  &lt;IRQ&gt;&#xA;  dump_stack_lvl+0x48/0x70&#xA;  print_address_description.constprop.0+0x33/0x3d0&#xA;  print_report+0xc0/0x2b0&#xA;  kasan_report+0xd0/0x120&#xA;  __asan_load1+0x6c/0x80&#xA;  tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]&#xA;  tcf_ct_act+0x886/0x1350 [act_ct]&#xA;  tcf_action_exec+0xf8/0x1f0&#xA;  fl_classify+0x355/0x360 [cls_flower]&#xA;  __tcf_classify+0x1fd/0x330&#xA;  tcf_classify+0x21c/0x3c0&#xA;  sch_handle_ingress.constprop.0+0x2c5/0x500&#xA;  __netif_receive_skb_core.constprop.0+0xb25/0x1510&#xA;  __netif_receive_skb_list_core+0x220/0x4c0&#xA;  netif_receive_skb_list_internal+0x446/0x620&#xA;  napi_complete_done+0x157/0x3d0&#xA;  gro_cell_poll+0xcf/0x100&#xA;  __napi_poll+0x65/0x310&#xA;  net_rx_action+0x30c/0x5c0&#xA;  __do_softirq+0x14f/0x491&#xA;  __irq_exit_rcu+0x82/0xc0&#xA;  irq_exit_rcu+0xe/0x20&#xA;  common_interrupt+0xa1/0xb0&#xA;  &lt;/IRQ&gt;&#xA;  &lt;TASK&gt;&#xA;  asm_common_interrupt+0x27/0x40&#xA; Allocated by task 6469:&#xA;  kasan_save_stack+0x38/0x70&#xA;  kasan_set_track+0x25/0x40&#xA;  kasan_save_alloc_info+0x1e/0x40&#xA;  __kasan_krealloc+0x133/0x190&#xA;  krealloc+0xaa/0x130&#xA;  nf_ct_ext_add+0xed/0x230 [nf_conntrack]&#xA;  tcf_ct_act+0x1095/0x1350 [act_ct]&#xA;  tcf_action_exec+0xf8/0x1f0&#xA;  fl_classify+0x355/0x360 [cls_flower]&#xA;  __tcf_classify+0x1fd/0x330&#xA;  tcf_classify+0x21c/0x3c0&#xA;  sch_handle_ingress.constprop.0+0x2c5/0x500&#xA;  __netif_receive_skb_core.constprop.0+0xb25/0x1510&#xA;  __netif_receive_skb_list_core+0x220/0x4c0&#xA;  netif_receive_skb_list_internal+0x446/0x620&#xA;  napi_complete_done+0x157/0x3d0&#xA;  gro_cell_poll+0xcf/0x100&#xA;  __napi_poll+0x65/0x310&#xA;  net_rx_action+0x30c/0x5c0&#xA;  __do_softirq+0x14f/0x491&#xA; Freed by task 6469:&#xA;  kasan_save_stack+0x38/0x70&#xA;  kasan_set_track+0x25/0x40&#xA;  kasan_save_free_info+0x2b/0x60&#xA;  ____kasan_slab_free+0x180/0x1f0&#xA;  __kasan_slab_free+0x12/0x30&#xA;  slab_free_freelist_hook+0xd2/0x1a0&#xA;  __kmem_cache_free+0x1a2/0x2f0&#xA;  kfree+0x78/0x120&#xA;  nf_conntrack_free+0x74/0x130 [nf_conntrack]&#xA;  nf_ct_destroy+0xb2/0x140 [nf_conntrack]&#xA;  __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]&#xA;  nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]&#xA;  __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]&#xA;  tcf_ct_act+0x12ad/0x1350 [act_ct]&#xA;  tcf_action_exec+0xf8/0x1f0&#xA;  fl_classify+0x355/0x360 [cls_flower]&#xA;  __tcf_classify+0x1fd/0x330&#xA;  tcf_classify+0x21c/0x3c0&#xA;  sch_handle_ingress.constprop.0+0x2c5/0x500&#xA;  __netif_receive_skb_core.constprop.0+0xb25/0x1510&#xA;  __netif_receive_skb_list_core+0x220/0x4c0&#xA;  netif_receive_skb_list_internal+0x446/0x620&#xA;  napi_complete_done+0x157/0x3d0&#xA;  gro_cell_poll+0xcf/0x100&#xA;  __napi_poll+0x65/0x310&#xA;  net_rx_action+0x30c/0x5c0&#xA;  __do_softirq+0x14f/0x491&#xA;The ct may be dropped if a clash has been resolved but is still passed to&#xA;the tcf_ct_flow_table_process_conn function for further usage. This issue&#xA;can be fixed by retrieving ct from skb again after confirming conntrack.&#xA;CVE-2024-40999:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ena: Add validation for completion descriptors consistency&#xA;Validate that `first` flag is set only for the first&#xA;descriptor in multi-buffer packets.&#xA;In case of an invalid descriptor, a reset will occur.&#xA;A new reset reason for RX data corruption has been added.&#xA;CVE-2024-41019:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Validate ff offset&#xA;This adds sanity checks for ff offset. There is a check&#xA;on rt-&gt;first_free at first, but walking through by ff&#xA;without any check. If the second ff is a large offset.&#xA;We may encounter an out-of-bound read.&#xA;CVE-2024-40959:In the Linux kernel, the following vulnerability has been resolved:&#xA;xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()&#xA;ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.&#xA;syzbot reported:&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA;Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker&#xA; RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64&#xA;Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00&#xA;RSP: 0018:ffffc90000117378 EFLAGS: 00010246&#xA;RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7&#xA;RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98&#xA;RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000&#xA;R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]&#xA;  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]&#xA;  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541&#xA;  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835&#xA;  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]&#xA;  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201&#xA;  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]&#xA;  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309&#xA;  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256&#xA;  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139&#xA;  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178&#xA;  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200&#xA;  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40&#xA;  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51&#xA;  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231&#xA;  process_scheduled_works kernel/workqueue.c:3312 [inline]&#xA;  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393&#xA;  kthread+0x2c1/0x3a0 kernel/kthread.c:389&#xA;  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147&#xA;  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;CVE-2024-41041:In the Linux kernel, the following vulnerability has been resolved:&#xA;udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().&#xA;syzkaller triggered the warning [0] in udp_v4_early_demux().&#xA;In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount&#xA;of the looked-up sk and use sock_pfree() as skb-&gt;destructor, so we check&#xA;SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace&#xA;period.&#xA;Currently, SOCK_RCU_FREE is flagged for a bound socket after being put&#xA;into the hash table.  Moreover, the SOCK_RCU_FREE check is done too early&#xA;in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race&#xA;window:&#xA;  CPU1                                 CPU2&#xA;  ----                                 ----&#xA;  udp_v4_early_demux()                 udp_lib_get_port()&#xA;  |                                    |- hlist_add_head_rcu()&#xA;  |- sk = __udp4_lib_demux_lookup()    |&#xA;  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));&#xA;                                       `- sock_set_flag(sk, SOCK_RCU_FREE)&#xA;We had the same bug in TCP and fixed it in commit 871019b22d1b (&#34;net:&#xA;set SOCK_RCU_FREE before inserting socket into hashtable&#34;).&#xA;Let&#39;s apply the same fix for UDP.&#xA;[0]:&#xA;WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599&#xA;Modules linked in:&#xA;CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599&#xA;Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe &lt;0f&gt; 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52&#xA;RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c&#xA;RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001&#xA;RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680&#xA;R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e&#xA;FS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349&#xA; ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447&#xA; NF_HOOK include/linux/netfilter.h:314 [inline]&#xA; NF_HOOK include/linux/netfilter.h:308 [inline]&#xA; ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569&#xA; __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624&#xA; __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738&#xA; netif_receive_skb_internal net/core/dev.c:5824 [inline]&#xA; netif_receive_skb+0x271/0x300 net/core/dev.c:5884&#xA; tun_rx_batched drivers/net/tun.c:1549 [inline]&#xA; tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002&#xA; tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048&#xA; new_sync_write fs/read_write.c:497 [inline]&#xA; vfs_write+0x76f/0x8d0 fs/read_write.c:590&#xA; ksys_write+0xbf/0x190 fs/read_write.c:643&#xA; __do_sys_write fs/read_write.c:655 [inline]&#xA; __se_sys_write fs/read_write.c:652 [inline]&#xA; __x64_sys_write+0x41/0x50 fs/read_write.c:652&#xA; x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;RIP: 0033:0x7fc44a68bc1f&#xA;Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48&#xA;RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f&#xA;R&#xA;---truncated---&#xA;CVE-2024-41077:In the Linux kernel, the following vulnerability has been resolved:&#xA;null_blk: fix validation of block size&#xA;Block size should be between 512 and PAGE_SIZE and be a power of 2. The current&#xA;check does not validate this, so update the check.&#xA;Without this patch, null_blk would Oops due to a null pointer deref when&#xA;loaded with bs=1536 [1].&#xA;[axboe: remove unnecessary braces and != 0 check]&#xA;CVE-2024-41080:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring: fix possible deadlock in io_register_iowq_max_workers()&#xA;The io_register_iowq_max_workers() function calls io_put_sq_data(),&#xA;which acquires the sqd-&gt;lock without releasing the uring_lock.&#xA;Similar to the commit 009ad9f0c6ee (&#34;io_uring: drop ctx-&gt;uring_lock&#xA;before acquiring sqd-&gt;lock&#34;), this can lead to a potential deadlock&#xA;situation.&#xA;To resolve this issue, the uring_lock is released before calling&#xA;io_put_sq_data(), and then it is re-acquired after the function call.&#xA;This change ensures that the locks are acquired in the correct&#xA;order, preventing the possibility of a deadlock.&#xA;CVE-2024-39471:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: add error handle to avoid out-of-bounds&#xA;if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should&#xA;be stop to avoid out-of-bounds read, so directly return -EINVAL.&#xA;CVE-2024-42115:In the Linux kernel, the following vulnerability has been resolved:&#xA;jffs2: Fix potential illegal address access in jffs2_free_inode&#xA;During the stress testing of the jffs2 file system,the following&#xA;abnormal printouts were found:&#xA;[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948&#xA;[ 2430.649622] Mem abort info:&#xA;[ 2430.649829]   ESR = 0x96000004&#xA;[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[ 2430.650564]   SET = 0, FnV = 0&#xA;[ 2430.650795]   EA = 0, S1PTW = 0&#xA;[ 2430.651032]   FSC = 0x04: level 0 translation fault&#xA;[ 2430.651446] Data abort info:&#xA;[ 2430.651683]   ISV = 0, ISS = 0x00000004&#xA;[ 2430.652001]   CM = 0, WnR = 0&#xA;[ 2430.652558] [0069696969696948] address between user and kernel address ranges&#xA;[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP&#xA;[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33&#xA;[ 2430.655008] Hardware name: linux,dummy-virt (DT)&#xA;[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[ 2430.656142] pc : kfree+0x78/0x348&#xA;[ 2430.656630] lr : jffs2_free_inode+0x24/0x48&#xA;[ 2430.657051] sp : ffff800009eebd10&#xA;[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000&#xA;[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000&#xA;[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14&#xA;[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000&#xA;[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000&#xA;[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19&#xA;[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14&#xA;[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302&#xA;[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342&#xA;[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000&#xA;[ 2430.664217] Call trace:&#xA;[ 2430.664528]  kfree+0x78/0x348&#xA;[ 2430.664855]  jffs2_free_inode+0x24/0x48&#xA;[ 2430.665233]  i_callback+0x24/0x50&#xA;[ 2430.665528]  rcu_do_batch+0x1ac/0x448&#xA;[ 2430.665892]  rcu_core+0x28c/0x3c8&#xA;[ 2430.666151]  rcu_core_si+0x18/0x28&#xA;[ 2430.666473]  __do_softirq+0x138/0x3cc&#xA;[ 2430.666781]  irq_exit+0xf0/0x110&#xA;[ 2430.667065]  handle_domain_irq+0x6c/0x98&#xA;[ 2430.667447]  gic_handle_irq+0xac/0xe8&#xA;[ 2430.667739]  call_on_irq_stack+0x28/0x54&#xA;The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of&#xA;the jffs_inode_info structure. It was found that all variables in the jffs_inode_info&#xA;structure were 5a5a5a5a, except for the first member sem. It is suspected that these&#xA;variables are not initialized because they were set to 5a5a5a5a during memory testing,&#xA;which is meant to detect uninitialized memory.The sem variable is initialized in the&#xA;function jffs2_i_init_once, while other members are initialized in&#xA;the function jffs2_init_inode_info.&#xA;The function jffs2_init_inode_info is called after iget_locked,&#xA;but in the iget_locked function, the destroy_inode process is triggered,&#xA;which releases the inode and consequently, the target member of the inode&#xA;is not initialized.In concurrent high pressure scenarios, iget_locked&#xA;may enter the destroy_inode branch as described in the code.&#xA;Since the destroy_inode functionality of jffs2 only releases the target,&#xA;the fix method is to set target to NULL in jffs2_i_init_once.&#xA;CVE-2024-42097:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: emux: improve patch ioctl data validation&#xA;In load_data(), make the validation of and skipping over the main info&#xA;block match that in load_guspatch().&#xA;In load_guspatch(), add checking that the specified patch length matches&#xA;the actually supplied data, like load_data() already did.&#xA;CVE-2024-42086:In the Linux kernel, the following vulnerability has been resolved:&#xA;iio: chemical: bme680: Fix overflows in compensate() functions&#xA;There are cases in the compensate functions of the driver that&#xA;there could be overflows of variables due to bit shifting ops.&#xA;These implications were initially discussed here [1] and they&#xA;were mentioned in log message of Commit 1b3bd8592780 (&#34;iio:&#xA;chemical: Add support for Bosch BME680 sensor&#34;).&#xA;[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/&#xA;CVE-2024-42228:In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually   need to have a separate value of 0xffffffff.(Christian)&#xA;CVE-2024-41014:In the Linux kernel, the following vulnerability has been resolved:&#xA;xfs: add bounds checking to xlog_recover_process_data&#xA;There is a lack of verification of the space occupied by fixed members&#xA;of xlog_op_header in the xlog_recover_process_data.&#xA;We can create a crafted image to trigger an out of bounds read by&#xA;following these steps:&#xA;    1) Mount an image of xfs, and do some file operations to leave records&#xA;    2) Before umounting, copy the image for subsequent steps to simulate&#xA;       abnormal exit. Because umount will ensure that tail_blk and&#xA;       head_blk are the same, which will result in the inability to enter&#xA;       xlog_recover_process_data&#xA;    3) Write a tool to parse and modify the copied image in step 2&#xA;    4) Make the end of the xlog_op_header entries only 1 byte away from&#xA;       xlog_rec_header-&gt;h_size&#xA;    5) xlog_rec_header-&gt;h_num_logops++&#xA;    6) Modify xlog_rec_header-&gt;h_crc&#xA;Fix:&#xA;Add a check to make sure there is sufficient space to access fixed members&#xA;of xlog_op_header.&#xA;CVE-2024-41063:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: hci_core: cancel all works upon hci_unregister_dev()&#xA;syzbot is reporting that calling hci_release_dev() from hci_error_reset()&#xA;due to hci_dev_put() from hci_error_reset() can cause deadlock at&#xA;destroy_workqueue(), for hci_error_reset() is called from&#xA;hdev-&gt;req_workqueue which destroy_workqueue() needs to flush.&#xA;We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which are&#xA;queued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which are&#xA;queued into hdev-&gt;req_workqueue are no longer running by the moment&#xA;       destroy_workqueue(hdev-&gt;workqueue);&#xA;       destroy_workqueue(hdev-&gt;req_workqueue);&#xA;are called from hci_release_dev().&#xA;Call cancel_work_sync() on these work items from hci_unregister_dev()&#xA;as soon as hdev-&gt;list is removed from hci_dev_list.&#xA;CVE-2024-42084:In the Linux kernel, the following vulnerability has been resolved:&#xA;ftruncate: pass a signed offset&#xA;The old ftruncate() syscall, using the 32-bit off_t misses a sign&#xA;extension when called in compat mode on 64-bit architectures.  As a&#xA;result, passing a negative length accidentally succeeds in truncating&#xA;to file size between 2GiB and 4GiB.&#xA;Changing the type of the compat syscall to the signed compat_off_t&#xA;changes the behavior so it instead returns -EINVAL.&#xA;The native entry point, the truncate() syscall and the corresponding&#xA;loff_t based variants are all correct already and do not suffer&#xA;from this mistake.&#xA;CVE-2024-40961:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: prevent possible NULL deref in fib6_nh_init()&#xA;syzbot reminds us that in6_dev_get() can return NULL.&#xA;fib6_nh_init()&#xA;    ip6_validate_gw(  &amp;idev  )&#xA;        ip6_route_check_nh(  idev  )&#xA;            *idev = in6_dev_get(dev); // can be NULL&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]&#xA;CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024&#xA; RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606&#xA;Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 &lt;42&gt; 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b&#xA;RSP: 0018:ffffc900032775a0 EFLAGS: 00010202&#xA;RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000&#xA;RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8&#xA;RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000&#xA;R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8&#xA;R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000&#xA;FS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809&#xA;  ip6_route_add+0x28/0x160 net/ipv6/route.c:3853&#xA;  ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483&#xA;  inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579&#xA;  sock_do_ioctl+0x158/0x460 net/socket.c:1222&#xA;  sock_ioctl+0x629/0x8e0 net/socket.c:1341&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f940f07cea9&#xA;CVE-2024-41090:In the Linux kernel, the following vulnerability has been resolved:&#xA;tap: add missing verification for short frame&#xA;The cited commit missed to check against the validity of the frame length&#xA;in the tap_get_user_xdp() path, which could cause a corrupted skb to be&#xA;sent downstack. Even before the skb is transmitted, the&#xA;tap_get_user_xdp()--&gt;skb_set_network_header() may assume the size is more&#xA;than ETH_HLEN. Once transmitted, this could either cause out-of-bound&#xA;access beyond the actual length, or confuse the underlayer with incorrect&#xA;or inconsistent header length in the skb metadata.&#xA;In the alternative path, tap_get_user() already prohibits short frame which&#xA;has the length less than Ethernet header size from being transmitted.&#xA;This is to drop any frame shorter than the Ethernet header size just like&#xA;how tap_get_user() does.&#xA;CVE: CVE-2024-41090&#xA;CVE-2024-41091:In the Linux kernel, the following vulnerability has been resolved:&#xA;tun: add missing verification for short frame&#xA;The cited commit missed to check against the validity of the frame length&#xA;in the tun_xdp_one() path, which could cause a corrupted skb to be sent&#xA;downstack. Even before the skb is transmitted, the&#xA;tun_xdp_one--&gt;eth_type_trans() may access the Ethernet header although it&#xA;can be less than ETH_HLEN. Once transmitted, this could either cause&#xA;out-of-bound access beyond the actual length, or confuse the underlayer&#xA;with incorrect or inconsistent header length in the skb metadata.&#xA;In the alternative path, tun_get_user() already prohibits short frame which&#xA;has the length less than Ethernet header size from being transmitted for&#xA;IFF_TAP.&#xA;This is to drop any frame shorter than the Ethernet header size just like&#xA;how tun_get_user() does.&#xA;CVE: CVE-2024-41091&#xA;CVE-2024-41020:In the Linux kernel, the following vulnerability has been resolved:&#xA;filelock: Fix fcntl/close race recovery compat path&#xA;When I wrote commit 3cad1bc01041 (&#34;filelock: Remove locks reliably when&#xA;fcntl/close race is detected&#34;), I missed that there are two copies of the&#xA;code I was patching: The normal version, and the version for 64-bit offsets&#xA;on 32-bit kernels.&#xA;Thanks to Greg KH for stumbling over this while doing the stable&#xA;backport...&#xA;Apply exactly the same fix to the compat path for 32-bit kernels.&#xA;CVE-2024-42068:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()&#xA;set_memory_ro() can fail, leaving memory unprotected.&#xA;Check its return and take it into account as an error.&#xA;CVE-2024-41048:In the Linux kernel, the following vulnerability has been resolved:&#xA;skmsg: Skip zero length skb in sk_msg_recvmsg&#xA;When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch&#xA;platform, the following kernel panic occurs:&#xA;  [...]&#xA;  Oops[#1]:&#xA;  CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18&#xA;  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018&#xA;     ... ...&#xA;     ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560&#xA;    ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0&#xA;   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)&#xA;   PRMD: 0000000c (PPLV0 +PIE +PWE)&#xA;   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)&#xA;   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)&#xA;  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)&#xA;   BADV: 0000000000000040&#xA;   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)&#xA;  Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack&#xA;  Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)&#xA;  Stack : ...&#xA;  Call Trace:&#xA;  [&lt;9000000004162774&gt;] copy_page_to_iter+0x74/0x1c0&#xA;  [&lt;90000000048bf6c0&gt;] sk_msg_recvmsg+0x120/0x560&#xA;  [&lt;90000000049f2b90&gt;] tcp_bpf_recvmsg_parser+0x170/0x4e0&#xA;  [&lt;90000000049aae34&gt;] inet_recvmsg+0x54/0x100&#xA;  [&lt;900000000481ad5c&gt;] sock_recvmsg+0x7c/0xe0&#xA;  [&lt;900000000481e1a8&gt;] __sys_recvfrom+0x108/0x1c0&#xA;  [&lt;900000000481e27c&gt;] sys_recvfrom+0x1c/0x40&#xA;  [&lt;9000000004c076ec&gt;] do_syscall+0x8c/0xc0&#xA;  [&lt;9000000003731da4&gt;] handle_syscall+0xc4/0x160&#xA;  Code: ...&#xA;  ---[ end trace 0000000000000000 ]---&#xA;  Kernel panic - not syncing: Fatal exception&#xA;  Kernel relocated by 0x3510000&#xA;   .text @ 0x9000000003710000&#xA;   .data @ 0x9000000004d70000&#xA;   .bss  @ 0x9000000006469400&#xA;  ---[ end Kernel panic - not syncing: Fatal exception ]---&#xA;  [...]&#xA;This crash happens every time when running sockmap_skb_verdict_shutdown&#xA;subtest in sockmap_basic.&#xA;This crash is because a NULL pointer is passed to page_address() in the&#xA;sk_msg_recvmsg(). Due to the different implementations depending on the&#xA;architecture, page_address(NULL) will trigger a panic on Loongarch&#xA;platform but not on x86 platform. So this bug was hidden on x86 platform&#xA;for a while, but now it is exposed on Loongarch platform. The root cause&#xA;is that a zero length skb (skb-&gt;len == 0) was put on the queue.&#xA;This zero length skb is a TCP FIN packet, which was sent by shutdown(),&#xA;invoked in test_sockmap_skb_verdict_shutdown():&#xA;&#x9;shutdown(p1, SHUT_WR);&#xA;In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no&#xA;page is put to this sge (see sg_set_page in sg_set_page), but this empty&#xA;sge is queued into ingress_msg list.&#xA;And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by&#xA;sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it&#xA;to kmap_local_page() and to page_address(), then kernel panics.&#xA;To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),&#xA;if copy is zero, that means it&#39;s a zero length skb, skip invoking&#xA;copy_page_to_iter(). We are using the EFAULT return triggered by&#xA;copy_page_to_iter to check for is_fin in tcp_bpf.c.&#xA;CVE-2023-52887:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new&#xA;This patch enhances error handling in scenarios with RTS (Request to&#xA;Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE&#xA;backtraces with a new error handling method. This provides clearer error&#xA;messages and allows for the early termination of problematic sessions.&#xA;Previously, sessions were only released at the end of j1939_xtp_rx_rts().&#xA;Potentially this could be reproduced with something like:&#xA;testj1939 -r vcan0:0x80 &amp;&#xA;while true; do&#xA;&#x9;# send first RTS&#xA;&#x9;cansend vcan0 18EC8090#1014000303002301;&#xA;&#x9;# send second RTS&#xA;&#x9;cansend vcan0 18EC8090#1014000303002301;&#xA;&#x9;# send abort&#xA;&#x9;cansend vcan0 18EC8090#ff00000000002301;&#xA;done&#xA;CVE-2024-42092:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpio: davinci: Validate the obtained number of IRQs&#xA;Value of pdata-&gt;gpio_unbanked is taken from Device Tree. In case of broken&#xA;DT due to any error this value can be any. Without this value validation&#xA;there can be out of chips-&gt;irqs array boundaries access in&#xA;davinci_gpio_probe().&#xA;Validate the obtained nirq value so that it won&#39;t exceed the maximum&#xA;number of IRQs per bank.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-41081:In the Linux kernel, the following vulnerability has been resolved:&#xA;ila: block BH in ila_output()&#xA;As explained in commit 1378817486d6 (&#34;tipc: block BH&#xA;before using dst_cache&#34;), net/core/dst_cache.c&#xA;helpers need to be called with BH disabled.&#xA;ila_output() is called from lwtunnel_output()&#xA;possibly from process context, and under rcu_read_lock().&#xA;We might be interrupted by a softirq, re-enter ila_output()&#xA;and corrupt dst_cache data structures.&#xA;Fix the race by using local_bh_disable().&#xA;CVE-2024-42161:In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD[Changes from V1: - Use a default branch in the switch statement to initialize `val .]GCC warns that `val  may be used uninitialized in theBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val;              [...]                switch (__CORE_RELO(s, field, BYTE_SIZE)) {           case 1: val = *(const unsigned char *)p; break;           case 2: val = *(const unsigned short *)p; break;          case 4: val = *(const unsigned int *)p; break;           case 8: val = *(const unsigned long long *)p; break;                 }                      [...] val;                }               This patch adds a default entry in the switch statement that sets`val  to zero in order to avoid the warning, and random values to beused in case __builtin_preserve_field_info returns unexpected valuesfor BPF_FIELD_BYTE_SIZE.Tested in bpf-next master.No regressions.&#xA;CVE-2024-40910:In the Linux kernel, the following vulnerability has been resolved:&#xA;ax25: Fix refcount imbalance on inbound connections&#xA;When releasing a socket in ax25_release(), we call netdev_put() to&#xA;decrease the refcount on the associated ax.25 device. However, the&#xA;execution path for accepting an incoming connection never calls&#xA;netdev_hold(). This imbalance leads to refcount errors, and ultimately&#xA;to kernel crashes.&#xA;A typical call trace for the above situation will start with one of the&#xA;following errors:&#xA;    refcount_t: decrement hit 0; leaking memory.&#xA;    refcount_t: underflow; use-after-free.&#xA;And will then have a trace like:&#xA;    Call Trace:&#xA;    &lt;TASK&gt;&#xA;    ? show_regs+0x64/0x70&#xA;    ? __warn+0x83/0x120&#xA;    ? refcount_warn_saturate+0xb2/0x100&#xA;    ? report_bug+0x158/0x190&#xA;    ? prb_read_valid+0x20/0x30&#xA;    ? handle_bug+0x3e/0x70&#xA;    ? exc_invalid_op+0x1c/0x70&#xA;    ? asm_exc_invalid_op+0x1f/0x30&#xA;    ? refcount_warn_saturate+0xb2/0x100&#xA;    ? refcount_warn_saturate+0xb2/0x100&#xA;    ax25_release+0x2ad/0x360&#xA;    __sock_release+0x35/0xa0&#xA;    sock_close+0x19/0x20&#xA;    [...]&#xA;On reboot (or any attempt to remove the interface), the kernel gets&#xA;stuck in an infinite loop:&#xA;    unregister_netdevice: waiting for ax0 to become free. Usage count = 0&#xA;This patch corrects these issues by ensuring that we call netdev_hold()&#xA;and ax25_dev_hold() for new connections in ax25_accept(). This makes the&#xA;logic leading to ax25_accept() match the logic for ax25_bind(): in both&#xA;cases we increment the refcount, which is ultimately decremented in&#xA;ax25_release().&#xA;CVE-2024-41046:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ethernet: lantiq_etop: fix double free in detach&#xA;The number of the currently released descriptor is never incremented&#xA;which results in the same skb being released multiple times.&#xA;CVE-2024-41044:In the Linux kernel, the following vulnerability has been resolved:&#xA;ppp: reject claimed-as-LCP but actually malformed packets&#xA;Since &#39;ppp_async_encode()&#39; assumes valid LCP packets (with code&#xA;from 1 to 7 inclusive), add &#39;ppp_check_packet()&#39; to ensure that&#xA;LCP packet has an actual body beyond PPP_LCP header bytes, and&#xA;reject claimed-as-LCP but actually malformed data otherwise.&#xA;CVE-2024-42145:In the Linux kernel, the following vulnerability has been resolved:&#xA;IB/core: Implement a limit on UMAD receive List&#xA;The existing behavior of ib_umad, which maintains received MAD&#xA;packets in an unbounded list, poses a risk of uncontrolled growth.&#xA;As user-space applications extract packets from this list, the rate&#xA;of extraction may not match the rate of incoming packets, leading&#xA;to potential list overflow.&#xA;To address this, we introduce a limit to the size of the list. After&#xA;considering typical scenarios, such as OpenSM processing, which can&#xA;handle approximately 100k packets per second, and the 1-second retry&#xA;timeout for most packets, we set the list size limit to 200k. Packets&#xA;received beyond this limit are dropped, assuming they are likely timed&#xA;out by the time they are handled by user-space.&#xA;Notably, packets queued on the receive list due to reasons like&#xA;timed-out sends are preserved even when the list is full.&#xA;CVE-2024-41072:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: cfg80211: wext: add extra SIOCSIWSCAN data check&#xA;In &#39;cfg80211_wext_siwscan()&#39;, add extra check whether number of&#xA;channels passed via &#39;ioctl(sock, SIOCSIWSCAN, ...)&#39; doesn&#39;t exceed&#xA;IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.&#xA;CVE-2024-41035:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor&#xA;Syzbot has identified a bug in usbcore (see the Closes: tag below)&#xA;caused by our assumption that the reserved bits in an endpoint&#xA;descriptor&#39;s bEndpointAddress field will always be 0.  As a result of&#xA;the bug, the endpoint_is_duplicate() routine in config.c (and possibly&#xA;other routines as well) may believe that two descriptors are for&#xA;distinct endpoints, even though they have the same direction and&#xA;endpoint number.  This can lead to confusion, including the bug&#xA;identified by syzbot (two descriptors with matching endpoint numbers&#xA;and directions, where one was interrupt and the other was bulk).&#xA;To fix the bug, we will clear the reserved bits in bEndpointAddress&#xA;when we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1&#xA;specs say these bits are &#34;Reserved, reset to zero&#34;.)  This requires us&#xA;to make a copy of the descriptor earlier in usb_parse_endpoint() and&#xA;use the copy instead of the original when checking for duplicates.&#xA;CVE-2024-42155:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/pkey: Wipe copies of protected- and secure-keys&#xA;Although the clear-key of neither protected- nor secure-keys is&#xA;accessible, this key material should only be visible to the calling&#xA;process. So wipe all copies of protected- or secure-keys from stack,&#xA;even in case of an error.&#xA;CVE-2024-42129:In the Linux kernel, the following vulnerability has been resolved:&#xA;leds: mlxreg: Use devm_mutex_init() for mutex initialization&#xA;In this driver LEDs are registered using devm_led_classdev_register()&#xA;so they are automatically unregistered after module&#39;s remove() is done.&#xA;led_classdev_unregister() calls module&#39;s led_set_brightness() to turn off&#xA;the LEDs and that callback uses mutex which was destroyed already&#xA;in module&#39;s remove() so use devm API instead.&#xA;CVE-2024-41023:In the Linux kernel, the following vulnerability has been resolved:&#xA;sched/deadline: Fix task_struct reference leak&#xA;During the execution of the following stress test with linux-rt:&#xA;stress-ng --cyclic 30 --timeout 30 --minimize --quiet&#xA;kmemleak frequently reported a memory leak concerning the task_struct:&#xA;unreferenced object 0xffff8881305b8000 (size 16136):&#xA;  comm &#34;stress-ng&#34;, pid 614, jiffies 4294883961 (age 286.412s)&#xA;  object hex dump (first 32 bytes):&#xA;    02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .@..............&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  debug hex dump (first 16 bytes):&#xA;    53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............&#xA;  backtrace:&#xA;    [&lt;00000000046b6790&gt;] dup_task_struct+0x30/0x540&#xA;    [&lt;00000000c5ca0f0b&gt;] copy_process+0x3d9/0x50e0&#xA;    [&lt;00000000ced59777&gt;] kernel_clone+0xb0/0x770&#xA;    [&lt;00000000a50befdc&gt;] __do_sys_clone+0xb6/0xf0&#xA;    [&lt;000000001dbf2008&gt;] do_syscall_64+0x5d/0xf0&#xA;    [&lt;00000000552900ff&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;The issue occurs in start_dl_timer(), which increments the task_struct&#xA;reference count and sets a timer. The timer callback, dl_task_timer,&#xA;is supposed to decrement the reference count upon expiration. However,&#xA;if enqueue_task_dl() is called before the timer expires and cancels it,&#xA;the reference count is not decremented, leading to the leak.&#xA;This patch fixes the reference leak by ensuring the task_struct&#xA;reference count is properly decremented when the timer is canceled.&#xA;CVE-2024-42080:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/restrack: Fix potential invalid address access&#xA;struct rdma_restrack_entry&#39;s kern_name was set to KBUILD_MODNAME&#xA;in ib_create_cq(), while if the module exited but forgot del this&#xA;rdma_restrack_entry, it would cause a invalid address access in&#xA;rdma_restrack_clean() when print the owner of this rdma_restrack_entry.&#xA;These code is used to help find one forgotten PD release in one of the&#xA;ULPs. But it is not needed anymore, so delete them.&#xA;CVE-2024-41097:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: atm: cxacru: fix endpoint checking in cxacru_bind()&#xA;Syzbot is still reporting quite an old issue [1] that occurs due to&#xA;incomplete checking of present usb endpoints. As such, wrong&#xA;endpoints types may be used at urb sumbitting stage which in turn&#xA;triggers a warning in usb_submit_urb().&#xA;Fix the issue by verifying that required endpoint types are present&#xA;for both in and out endpoints, taking into account cmd endpoint type.&#xA;Unfortunately, this patch has not been tested on real hardware.&#xA;[1] Syzbot report:&#xA;usb 1-1: BOGUS urb xfer, pipe 1 != type 3&#xA;WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502&#xA;Modules linked in:&#xA;CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;Workqueue: usb_hub_wq hub_event&#xA;RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502&#xA;...&#xA;Call Trace:&#xA; cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649&#xA; cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760&#xA; cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209&#xA; usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055&#xA; cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363&#xA; usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396&#xA; call_driver_probe drivers/base/dd.c:517 [inline]&#xA; really_probe+0x23c/0xcd0 drivers/base/dd.c:595&#xA; __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747&#xA; driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777&#xA; __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894&#xA; bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427&#xA; __device_attach+0x228/0x4a0 drivers/base/dd.c:965&#xA; bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487&#xA; device_add+0xc2f/0x2180 drivers/base/core.c:3354&#xA; usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170&#xA; usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238&#xA; usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293&#xA;CVE-2024-42106:In the Linux kernel, the following vulnerability has been resolved:&#xA;inet_diag: Initialize pad field in struct inet_diag_req_v2&#xA;KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw&#xA;sockets uses the pad field in struct inet_diag_req_v2 for the&#xA;underlying protocol. This field corresponds to the sdiag_raw_protocol&#xA;field in struct inet_diag_req_raw.&#xA;inet_diag_get_exact_compat() converts inet_diag_req to&#xA;inet_diag_req_v2, but leaves the pad field uninitialized. So the issue&#xA;occurs when raw_lookup() accesses the sdiag_raw_protocol field.&#xA;Fix this by initializing the pad field in&#xA;inet_diag_get_exact_compat(). Also, do the same fix in&#xA;inet_diag_dump_compat() to avoid the similar issue in the future.&#xA;[1]&#xA;BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]&#xA;BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71&#xA; raw_lookup net/ipv4/raw_diag.c:49 [inline]&#xA; raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71&#xA; raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99&#xA; inet_diag_cmd_exact+0x7d9/0x980&#xA; inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]&#xA; inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426&#xA; sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282&#xA; netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564&#xA; sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]&#xA; netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361&#xA; netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0x332/0x3d0 net/socket.c:745&#xA; ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585&#xA; ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639&#xA; __sys_sendmsg net/socket.c:2668 [inline]&#xA; __do_sys_sendmsg net/socket.c:2677 [inline]&#xA; __se_sys_sendmsg net/socket.c:2675 [inline]&#xA; __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675&#xA; x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was stored to memory at:&#xA; raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71&#xA; raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99&#xA; inet_diag_cmd_exact+0x7d9/0x980&#xA; inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]&#xA; inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426&#xA; sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282&#xA; netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564&#xA; sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]&#xA; netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361&#xA; netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0x332/0x3d0 net/socket.c:745&#xA; ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585&#xA; ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639&#xA; __sys_sendmsg net/socket.c:2668 [inline]&#xA; __do_sys_sendmsg net/socket.c:2677 [inline]&#xA; __se_sys_sendmsg net/socket.c:2675 [inline]&#xA; __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675&#xA; x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Local variable req.i created at:&#xA; inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]&#xA; inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426&#xA; sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282&#xA;CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014&#xA;CVE-2024-42224:In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 ( net: dsa: mv88e6xxx: Support multiple MDIObusses ) mv88e6xxx_default_mdio_bus() has checked that thereturn value of list_first_entry() is non-NULL.This appears to be intended to guard against the list chip-&gt;mdios beingempty.  However, it is not the correct check as the implementation oflist_first_entry is not designed to return NULL for empty lists.Instead, use list_first_entry_or_null() which does return NULL if thelist is empty.Flagged by Smatch.Compile tested only.&#xA;CVE-2024-41013:In the Linux kernel, the following vulnerability has been resolved:&#xA;xfs: don&#39;t walk off the end of a directory data block&#xA;This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry&#xA;to make sure don&#39;t stray beyond valid memory region. Before patching, the&#xA;loop simply checks that the start offset of the dup and dep is within the&#xA;range. So in a crafted image, if last entry is xfs_dir2_data_unused, we&#xA;can change dup-&gt;length to dup-&gt;length-1 and leave 1 byte of space. In the&#xA;next traversal, this space will be considered as dup or dep. We may&#xA;encounter an out of bound read when accessing the fixed members.&#xA;In the patch, we make sure that the remaining bytes large enough to hold&#xA;an unused entry before accessing xfs_dir2_data_unused and&#xA;xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make&#xA;sure that the remaining bytes large enough to hold a dirent with a&#xA;single-byte name before accessing xfs_dir2_data_entry.&#xA;CVE-2024-41070:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()&#xA;Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().&#xA;It looks up `stt` from tablefd, but then continues to use it after doing&#xA;fdput() on the returned fd. After the fdput() the tablefd is free to be&#xA;closed by another thread. The close calls kvm_spapr_tce_release() and&#xA;then release_spapr_tce_table() (via call_rcu()) which frees `stt`.&#xA;Although there are calls to rcu_read_lock() in&#xA;kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent&#xA;the UAF, because `stt` is used outside the locked regions.&#xA;With an artifcial delay after the fdput() and a userspace program which&#xA;triggers the race, KASAN detects the UAF:&#xA;  BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]&#xA;  Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505&#xA;  CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1&#xA;  Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV&#xA;  Call Trace:&#xA;    dump_stack_lvl+0xb4/0x108 (unreliable)&#xA;    print_report+0x2b4/0x6ec&#xA;    kasan_report+0x118/0x2b0&#xA;    __asan_load4+0xb8/0xd0&#xA;    kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]&#xA;    kvm_vfio_set_attr+0x524/0xac0 [kvm]&#xA;    kvm_device_ioctl+0x144/0x240 [kvm]&#xA;    sys_ioctl+0x62c/0x1810&#xA;    system_call_exception+0x190/0x440&#xA;    system_call_vectored_common+0x15c/0x2ec&#xA;  ...&#xA;  Freed by task 0:&#xA;   ...&#xA;   kfree+0xec/0x3e0&#xA;   release_spapr_tce_table+0xd4/0x11c [kvm]&#xA;   rcu_core+0x568/0x16a0&#xA;   handle_softirqs+0x23c/0x920&#xA;   do_softirq_own_stack+0x6c/0x90&#xA;   do_softirq_own_stack+0x58/0x90&#xA;   __irq_exit_rcu+0x218/0x2d0&#xA;   irq_exit+0x30/0x80&#xA;   arch_local_irq_restore+0x128/0x230&#xA;   arch_local_irq_enable+0x1c/0x30&#xA;   cpuidle_enter_state+0x134/0x5cc&#xA;   cpuidle_enter+0x6c/0xb0&#xA;   call_cpuidle+0x7c/0x100&#xA;   do_idle+0x394/0x410&#xA;   cpu_startup_entry+0x60/0x70&#xA;   start_secondary+0x3fc/0x410&#xA;   start_secondary_prolog+0x10/0x14&#xA;Fix it by delaying the fdput() until `stt` is no longer in use, which&#xA;is effectively the entire function. To keep the patch minimal add a call&#xA;to fdput() at each of the existing return paths. Future work can convert&#xA;the function to goto or __cleanup style cleanup.&#xA;With the fix in place the test case no longer triggers the UAF.&#xA;CVE-2024-41062:In the Linux kernel, the following vulnerability has been resolved:&#xA;bluetooth/l2cap: sync sock recv cb and release&#xA;The problem occurs between the system call to close the sock and hci_rx_work,&#xA;where the former releases the sock and the latter accesses it without lock protection.&#xA;           CPU0                       CPU1&#xA;           ----                       ----&#xA;           sock_close                 hci_rx_work&#xA;&#x9;   l2cap_sock_release         hci_acldata_packet&#xA;&#x9;   l2cap_sock_kill            l2cap_recv_frame&#xA;&#x9;   sk_free                    l2cap_conless_channel&#xA;&#x9;                              l2cap_sock_recv_cb&#xA;If hci_rx_work processes the data that needs to be received before the sock is&#xA;closed, then everything is normal; Otherwise, the work thread may access the&#xA;released sock when receiving data.&#xA;Add a chan mutex in the rx callback of the sock to achieve synchronization between&#xA;the sock release and recv cb.&#xA;Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.&#xA;CVE-2024-42089:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: fsl-asoc-card: set priv-&gt;pdev before using it&#xA;priv-&gt;pdev pointer was set after being used in&#xA;fsl_asoc_card_audmux_init().&#xA;Move this assignment at the start of the probe function, so&#xA;sub-functions can correctly use pdev through priv.&#xA;fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to the&#xA;dev struct, used with dev_err macros.&#xA;As priv is zero-initialised, there would be a NULL pointer dereference.&#xA;Note that if priv-&gt;dev is dereferenced before assignment but never used,&#xA;for example if there is no error to be printed, the driver won&#39;t crash&#xA;probably due to compiler optimisations.&#xA;CVE-2024-42076:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: can: j1939: Initialize unused data in j1939_send_one()&#xA;syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()&#xA;creates full frame including unused data, but it doesn&#39;t initialize&#xA;it. This causes the kernel-infoleak issue. Fix this by initializing&#xA;unused data.&#xA;[1]&#xA;BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]&#xA;BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]&#xA;BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]&#xA;BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]&#xA;BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185&#xA; instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA; copy_to_user_iter lib/iov_iter.c:24 [inline]&#xA; iterate_ubuf include/linux/iov_iter.h:29 [inline]&#xA; iterate_and_advance2 include/linux/iov_iter.h:245 [inline]&#xA; iterate_and_advance include/linux/iov_iter.h:271 [inline]&#xA; _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185&#xA; copy_to_iter include/linux/uio.h:196 [inline]&#xA; memcpy_to_msg include/linux/skbuff.h:4113 [inline]&#xA; raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008&#xA; sock_recvmsg_nosec net/socket.c:1046 [inline]&#xA; sock_recvmsg+0x2c4/0x340 net/socket.c:1068&#xA; ____sys_recvmsg+0x18a/0x620 net/socket.c:2803&#xA; ___sys_recvmsg+0x223/0x840 net/socket.c:2845&#xA; do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939&#xA; __sys_recvmmsg net/socket.c:3018 [inline]&#xA; __do_sys_recvmmsg net/socket.c:3041 [inline]&#xA; __se_sys_recvmmsg net/socket.c:3034 [inline]&#xA; __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034&#xA; x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was created at:&#xA; slab_post_alloc_hook mm/slub.c:3804 [inline]&#xA; slab_alloc_node mm/slub.c:3845 [inline]&#xA; kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888&#xA; kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577&#xA; __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668&#xA; alloc_skb include/linux/skbuff.h:1313 [inline]&#xA; alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504&#xA; sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795&#xA; sock_alloc_send_skb include/net/sock.h:1842 [inline]&#xA; j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]&#xA; j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]&#xA; j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0x30f/0x380 net/socket.c:745&#xA; ____sys_sendmsg+0x877/0xb60 net/socket.c:2584&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA; __sys_sendmsg net/socket.c:2667 [inline]&#xA; __do_sys_sendmsg net/socket.c:2676 [inline]&#xA; __se_sys_sendmsg net/socket.c:2674 [inline]&#xA; __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674&#xA; x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Bytes 12-15 of 16 are uninitialized&#xA;Memory access of size 16 starts at ffff888120969690&#xA;Data copied to user address 00000000200017c0&#xA;CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;CVE-2024-41089:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes&#xA;In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is&#xA;assigned to mode, which will lead to a possible NULL pointer dereference&#xA;on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().&#xA;Add a check to avoid null pointer dereference.&#xA;CVE-2024-42098:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: ecdh - explicitly zeroize private_key&#xA;private_key is overwritten with the key parameter passed in by the&#xA;caller (if present), or alternatively a newly generated private key.&#xA;However, it is possible that the caller provides a key (or the newly&#xA;generated key) which is shorter than the previous key. In that&#xA;scenario, some key material from the previous key would not be&#xA;overwritten. The easiest solution is to explicitly zeroize the entire&#xA;private_key array first.&#xA;Note that this patch slightly changes the behavior of this function:&#xA;previously, if the ecc_gen_privkey failed, the old private_key would&#xA;remain. Now, the private_key is always zeroized. This behavior is&#xA;consistent with the case where params.key is set and ecc_is_key_valid&#xA;fails.&#xA;CVE-2024-42077:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: fix DIO failure due to insufficient transaction credits&#xA;The code in ocfs2_dio_end_io_write() estimates number of necessary&#xA;transaction credits using ocfs2_calc_extend_credits().  This however does&#xA;not take into account that the IO could be arbitrarily large and can&#xA;contain arbitrary number of extents.&#xA;Extent tree manipulations do often extend the current transaction but not&#xA;in all of the cases.  For example if we have only single block extents in&#xA;the tree, ocfs2_mark_extent_written() will end up calling&#xA;ocfs2_replace_extent_rec() all the time and we will never extend the&#xA;current transaction and eventually exhaust all the transaction credits if&#xA;the IO contains many single block extents.  Once that happens a&#xA;WARN_ON(jbd2_handle_buffer_credits(handle) &lt;= 0) is triggered in&#xA;jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to&#xA;this error.  This was actually triggered by one of our customers on a&#xA;heavily fragmented OCFS2 filesystem.&#xA;To fix the issue make sure the transaction always has enough credits for&#xA;one extent insert before each call of ocfs2_mark_extent_written().&#xA;Heming Zhao said:&#xA;------&#xA;PANIC: &#34;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error&#34;&#xA;PID: xxx  TASK: xxxx  CPU: 5  COMMAND: &#34;SubmitThread-CA&#34;&#xA;  #0 machine_kexec at ffffffff8c069932&#xA;  #1 __crash_kexec at ffffffff8c1338fa&#xA;  #2 panic at ffffffff8c1d69b9&#xA;  #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]&#xA;  #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]&#xA;  #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]&#xA;  #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]&#xA;  #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]&#xA;  #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]&#xA;  #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]&#xA;#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]&#xA;#11 dio_complete at ffffffff8c2b9fa7&#xA;#12 do_blockdev_direct_IO at ffffffff8c2bc09f&#xA;#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]&#xA;#14 generic_file_direct_write at ffffffff8c1dcf14&#xA;#15 __generic_file_write_iter at ffffffff8c1dd07b&#xA;#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]&#xA;#17 aio_write at ffffffff8c2cc72e&#xA;#18 kmem_cache_alloc at ffffffff8c248dde&#xA;#19 do_io_submit at ffffffff8c2ccada&#xA;#20 do_syscall_64 at ffffffff8c004984&#xA;#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba&#xA;CVE-2024-39497:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)&#xA;Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap&#xA;allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag&#xA;causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:&#xA;BUG_ON((vma-&gt;vm_flags &amp; VM_PFNMAP) &amp;&amp; is_cow_mapping(vma-&gt;vm_flags));&#xA;Return -EINVAL early if COW mapping is detected.&#xA;This bug affects all drm drivers using default shmem helpers.&#xA;It can be reproduced by this simple example:&#xA;void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);&#xA;ptr[0] = 0;&#xA;CVE-2024-42096:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86: stop playing stack games in profile_pc()&#xA;The &#39;profile_pc()&#39; function is used for timer-based profiling, which&#xA;isn&#39;t really all that relevant any more to begin with, but it also ends&#xA;up making assumptions based on the stack layout that aren&#39;t necessarily&#xA;valid.&#xA;Basically, the code tries to account the time spent in spinlocks to the&#xA;caller rather than the spinlock, and while I support that as a concept,&#xA;it&#39;s not worth the code complexity or the KASAN warnings when no serious&#xA;profiling is done using timers anyway these days.&#xA;And the code really does depend on stack layout that is only true in the&#xA;simplest of cases.  We&#39;ve lost the comment at some point (I think when&#xA;the 32-bit and 64-bit code was unified), but it used to say:&#xA;&#x9;Assume the lock function has either no stack frame or a copy&#xA;&#x9;of eflags from PUSHF.&#xA;which explains why it just blindly loads a word or two straight off the&#xA;stack pointer and then takes a minimal look at the values to just check&#xA;if they might be eflags or the return pc:&#xA;&#x9;Eflags always has bits 22 and up cleared unlike kernel addresses&#xA;but that basic stack layout assumption assumes that there isn&#39;t any lock&#xA;debugging etc going on that would complicate the code and cause a stack&#xA;frame.&#xA;It causes KASAN unhappiness reported for years by syzkaller [1] and&#xA;others [2].&#xA;With no real practical reason for this any more, just remove the code.&#xA;Just for historical interest, here&#39;s some background commits relating to&#xA;this code from 2006:&#xA;  0cb91a229364 (&#34;i386: Account spinlocks to the caller during profiling for !FP kernels&#34;)&#xA;  31679f38d886 (&#34;Simplify profile_pc on x86-64&#34;)&#xA;and a code unification from 2009:&#xA;  ef4512882dbe (&#34;x86: time_32/64.c unify profile_pc&#34;)&#xA;but the basics of this thing actually goes back to before the git tree.&#xA;CVE-2024-41079:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvmet: always initialize cqe.result&#xA;The spec doesn&#39;t mandate that the first two double words (aka results)&#xA;for the command queue entry need to be set to 0 when they are not&#xA;used (not specified). Though, the target implemention returns 0 for TCP&#xA;and FC but not for RDMA.&#xA;Let&#39;s make RDMA behave the same and thus explicitly initializing the&#xA;result field. This prevents leaking any data from the stack.&#xA;CVE-2024-42101:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes&#xA;In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()&#xA;is assigned to mode, which will lead to a possible NULL pointer&#xA;dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2024-42162:In the Linux kernel, the following vulnerability has been resolved:&#xA;gve: Account for stopped queues when reading NIC stats&#xA;We now account for the fact that the NIC might send us stats for a&#xA;subset of queues. Without this change, gve_get_ethtool_stats might make&#xA;an invalid access on the priv-&gt;stats_report-&gt;stats array.&#xA;CVE-2024-42124:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qedf: Make qedf_execute_tmf() non-preemptible&#xA;Stop calling smp_processor_id() from preemptible code in&#xA;qedf_execute_tmf90.  This results in BUG_ON() when running an RT kernel.&#xA;[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646&#xA;[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]&#xA;CVE-2024-42094:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/iucv: Avoid explicit cpumask var allocation on stack&#xA;For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask&#xA;variable on stack is not recommended since it can cause potential stack&#xA;overflow.&#xA;Instead, kernel code should always use *cpumask_var API(s) to allocate&#xA;cpumask var in config-neutral way, leaving allocation strategy to&#xA;CONFIG_CPUMASK_OFFSTACK.&#xA;Use *cpumask_var API(s) to address it.&#xA;CVE-2024-41012:In the Linux kernel, the following vulnerability has been resolved:&#xA;filelock: Remove locks reliably when fcntl/close race is detected&#xA;When fcntl_setlk() races with close(), it removes the created lock with&#xA;do_lock_file_wait().&#xA;However, LSMs can allow the first do_lock_file_wait() that created the lock&#xA;while denying the second do_lock_file_wait() that tries to remove the lock.&#xA;Separately, posix_lock_file() could also fail to&#xA;remove a lock due to GFP_KERNEL allocation failure (when splitting a range&#xA;in the middle).&#xA;After the bug has been triggered, use-after-free reads will occur in&#xA;lock_get_status() when userspace reads /proc/locks. This can likely be used&#xA;to read arbitrary kernel memory, but can&#39;t corrupt kernel memory.&#xA;Fix it by calling locks_remove_posix() instead, which is designed to&#xA;reliably get rid of POSIX locks associated with the given file and&#xA;files_struct and is also used by filp_flush().&#xA;CVE-2024-42093:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/dpaa2: Avoid explicit cpumask var allocation on stack&#xA;For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask&#xA;variable on stack is not recommended since it can cause potential stack&#xA;overflow.&#xA;Instead, kernel code should always use *cpumask_var API(s) to allocate&#xA;cpumask var in config-neutral way, leaving allocation strategy to&#xA;CONFIG_CPUMASK_OFFSTACK.&#xA;Use *cpumask_var API(s) to address it.&#xA;CVE-2023-52888:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: mediatek: vcodec: Only free buffer VA that is not NULL&#xA;In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly&#xA;called only when the buffer to free exists, there are some instances&#xA;that didn&#39;t do the check and triggered warnings in practice.&#xA;We believe those checks were forgotten unintentionally. Add the checks&#xA;back to fix the warnings.&#xA;CVE-2024-41078:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: qgroup: fix quota root leak after quota disable failure&#xA;If during the quota disable we fail when cleaning the quota tree or when&#xA;deleting the root from the root tree, we jump to the &#39;out&#39; label without&#xA;ever dropping the reference on the quota root, resulting in a leak of the&#xA;root since fs_info-&gt;quota_root is no longer pointing to the root (we have&#xA;set it to NULL just before those steps).&#xA;Fix this by always doing a btrfs_put_root() call under the &#39;out&#39; label.&#xA;This is a problem that exists since qgroups were first added in 2012 by&#xA;commit bed92eae26cc (&#34;Btrfs: qgroup implementation and prototypes&#34;), but&#xA;back then we missed a kfree on the quota root and free_extent_buffer()&#xA;calls on its root and commit root nodes, since back then roots were not&#xA;yet reference counted.&#xA;CVE-2024-41027:In the Linux kernel, the following vulnerability has been resolved:&#xA;Fix userfaultfd_api to return EINVAL as expected&#xA;Currently if we request a feature that is not set in the Kernel config we&#xA;fail silently and return all the available features.  However, the man&#xA;page indicates we should return an EINVAL.&#xA;We need to fix this issue since we can end up with a Kernel warning should&#xA;a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with&#xA;the config not set with this feature.&#xA; [  200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660&#xA; [  200.820738] Modules linked in:&#xA; [  200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8&#xA; [  200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022&#xA; [  200.885052] RIP: 0010:zap_pte_range+0x43d/0x660&#xA;CVE-2021-47582:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: core: Make do_proc_control() and do_proc_bulk() killable&#xA;The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke&#xA;usb_start_wait_urb(), which contains an uninterruptible wait with a&#xA;user-specified timeout value.  If timeout value is very large and the&#xA;device being accessed does not respond in a reasonable amount of time,&#xA;the kernel will complain about &#34;Task X blocked for more than N&#xA;seconds&#34;, as found in testing by syzbot:&#xA;INFO: task syz-executor.0:8700 blocked for more than 143 seconds.&#xA;      Not tainted 5.14.0-rc7-syzkaller #0&#xA;&#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA;task:syz-executor.0  state:D stack:23192 pid: 8700 ppid:  8455 flags:0x00004004&#xA;Call Trace:&#xA; context_switch kernel/sched/core.c:4681 [inline]&#xA; __schedule+0xc07/0x11f0 kernel/sched/core.c:5938&#xA; schedule+0x14b/0x210 kernel/sched/core.c:6017&#xA; schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857&#xA; do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85&#xA; __wait_for_common kernel/sched/completion.c:106 [inline]&#xA; wait_for_common kernel/sched/completion.c:117 [inline]&#xA; wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157&#xA; usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63&#xA; do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236&#xA; proc_bulk drivers/usb/core/devio.c:1273 [inline]&#xA; usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]&#xA; usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713&#xA;...&#xA;To fix this problem, this patch replaces usbfs&#39;s calls to&#xA;usb_control_msg() and usb_bulk_msg() with special-purpose code that&#xA;does essentially the same thing (as recommended in the comment for&#xA;usb_start_wait_urb()), except that it always uses a killable wait and&#xA;it uses GFP_KERNEL rather than GFP_NOIO.&#xA;CVE-2024-41034:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix kernel bug on rename operation of broken directory&#xA;Syzbot reported that in rename directory operation on broken directory on&#xA;nilfs2, __block_write_begin_int() called to prepare block write may fail&#xA;BUG_ON check for access exceeding the folio/page size.&#xA;This is because nilfs_dotdot(), which gets parent directory reference&#xA;entry (&#34;..&#34;) of the directory to be moved or renamed, does not check&#xA;consistency enough, and may return location exceeding folio/page size for&#xA;broken directories.&#xA;Fix this issue by checking required directory entries (&#34;.&#34; and &#34;..&#34;) in&#xA;the first chunk of the directory in nilfs_dotdot().&#xA;CVE-2024-42157:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/pkey: Wipe sensitive data on failure&#xA;Wipe sensitive data from stack also if the copy_to_user() fails.&#xA;CVE-2022-48827:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSD: Fix the behavior of READ near OFFSET_MAX&#xA;Dan Aloni reports:&#xA;&gt; Due to commit 8cfb9015280d (&#34;NFS: Always provide aligned buffers to&#xA;&gt; the RPC read layers&#34;) on the client, a read of 0xfff is aligned up&#xA;&gt; to server rsize of 0x1000.&#xA;&gt;&#xA;&gt; As a result, in a test where the server has a file of size&#xA;&gt; 0x7fffffffffffffff, and the client tries to read from the offset&#xA;&gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server&#xA;&gt; and it returns an NFS code of EINVAL to the client. The client as&#xA;&gt; a result indefinitely retries the request.&#xA;The Linux NFS client does not handle NFS?ERR_INVAL, even though all&#xA;NFS specifications permit servers to return that status code for a&#xA;READ.&#xA;Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed&#xA;and return a short result. Set the EOF flag in the result to prevent&#xA;the client from retrying the READ request. This behavior appears to&#xA;be consistent with Solaris NFS servers.&#xA;Note that NFSv3 and NFSv4 use u64 offset values on the wire. These&#xA;must be converted to loff_t internally before use -- an implicit&#xA;type cast is not adequate for this purpose. Otherwise VFS checks&#xA;against sb-&gt;s_maxbytes do not work properly.&#xA;CVE-2024-42128:In the Linux kernel, the following vulnerability has been resolved:&#xA;leds: an30259a: Use devm_mutex_init() for mutex initialization&#xA;In this driver LEDs are registered using devm_led_classdev_register()&#xA;so they are automatically unregistered after module&#39;s remove() is done.&#xA;led_classdev_unregister() calls module&#39;s led_set_brightness() to turn off&#xA;the LEDs and that callback uses mutex which was destroyed already&#xA;in module&#39;s remove() so use devm API instead.&#xA;CVE-2024-40942:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects&#xA;The hwmp code use objects of type mesh_preq_queue, added to a list in&#xA;ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath&#xA;gets deleted, ex mesh interface is removed, the entries in that list will&#xA;never get cleaned. Fix this by flushing all corresponding items of the&#xA;preq_queue in mesh_path_flush_pending().&#xA;This should take care of KASAN reports like this:&#xA;unreferenced object 0xffff00000668d800 (size 128):&#xA;  comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s)&#xA;  hex dump (first 32 bytes):&#xA;    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....&#xA;    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....&gt;...........&#xA;  backtrace:&#xA;    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c&#xA;    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80&#xA;    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8&#xA;    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c&#xA;    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4&#xA;    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764&#xA;    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4&#xA;    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440&#xA;    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c&#xA;    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4&#xA;    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508&#xA;    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c&#xA;    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634&#xA;    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4&#xA;    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20&#xA;unreferenced object 0xffff000009051f00 (size 128):&#xA;  comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419553 (age 1836.440s)&#xA;  hex dump (first 32 bytes):&#xA;    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....&#xA;    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6&#39;.......Xy.....&#xA;  backtrace:&#xA;    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c&#xA;    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80&#xA;    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8&#xA;    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c&#xA;    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4&#xA;    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764&#xA;    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4&#xA;    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440&#xA;    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c&#xA;    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4&#xA;    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508&#xA;    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c&#xA;    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634&#xA;    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4&#xA;    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20&#xA;CVE-2024-42154:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp_metrics: validate source addr length&#xA;I don&#39;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4&#xA;is at least 4 bytes long, and the policy doesn&#39;t have an entry&#xA;for this attribute at all (neither does it for IPv6 but v6 is&#xA;manually validated).&#xA;CVE-2024-41065:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/pseries: Whitelist dtl slub object for copying to userspace&#xA;Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*&#xA;results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as&#xA;shown below.&#xA;    kernel BUG at mm/usercopy.c:102!&#xA;    Oops: Exception in kernel mode, sig: 5 [#1]&#xA;    LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries&#xA;    Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc&#xA;    scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse&#xA;    CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85&#xA;    Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries&#xA;    NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8&#xA;    REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)&#xA;    MSR:  8000000000029033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 2828220f  XER: 0000000e&#xA;    CFAR: c0000000001fdc80 IRQMASK: 0&#xA;    [ ... GPRs omitted ... ]&#xA;    NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0&#xA;    LR [c0000000005d23d0] usercopy_abort+0x74/0xb0&#xA;    Call Trace:&#xA;     usercopy_abort+0x74/0xb0 (unreliable)&#xA;     __check_heap_object+0xf8/0x120&#xA;     check_heap_object+0x218/0x240&#xA;     __check_object_size+0x84/0x1a4&#xA;     dtl_file_read+0x17c/0x2c4&#xA;     full_proxy_read+0x8c/0x110&#xA;     vfs_read+0xdc/0x3a0&#xA;     ksys_read+0x84/0x144&#xA;     system_call_exception+0x124/0x330&#xA;     system_call_vectored_common+0x15c/0x2ec&#xA;    --- interrupt: 3000 at 0x7fff81f3ab34&#xA;Commit 6d07d1cd300f (&#34;usercopy: Restrict non-usercopy caches to size 0&#34;)&#xA;requires that only whitelisted areas in slab/slub objects can be copied to&#xA;userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.&#xA;Dtl contains hypervisor dispatch events which are expected to be read by&#xA;privileged users. Hence mark this safe for user access.&#xA;Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the&#xA;entire object.&#xA;CVE-2024-42095:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: 8250_omap: Implementation of Errata i2310&#xA;As per Errata i2310[0], Erroneous timeout can be triggered,&#xA;if this Erroneous interrupt is not cleared then it may leads&#xA;to storm of interrupts, therefore apply Errata i2310 solution.&#xA;[0] https://www.ti.com/lit/pdf/sprz536 page 23&#xA;CVE-2024-42114:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values&#xA;syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM&#xA;to 2^31.&#xA;We had a similar issue in sch_fq, fixed with commit&#xA;d9e15a273306 (&#34;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&#34;)&#xA;watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]&#xA;Modules linked in:&#xA;irq event stamp: 131135&#xA; hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]&#xA; hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95&#xA; hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]&#xA; hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551&#xA; softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]&#xA; softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553&#xA; softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19&#xA;CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;Workqueue: mld mld_ifc_work&#xA;pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : __list_del include/linux/list.h:195 [inline]&#xA; pc : __list_del_entry include/linux/list.h:218 [inline]&#xA; pc : list_move_tail include/linux/list.h:310 [inline]&#xA; pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]&#xA; pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854&#xA; lr : __list_del_entry include/linux/list.h:218 [inline]&#xA; lr : list_move_tail include/linux/list.h:310 [inline]&#xA; lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]&#xA; lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854&#xA;sp : ffff800093d36700&#xA;x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000&#xA;x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0&#xA;x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0&#xA;x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0&#xA;x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8&#xA;x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff&#xA;x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000&#xA;x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000&#xA;x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc&#xA;x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470&#xA;Call trace:&#xA;  __list_del include/linux/list.h:195 [inline]&#xA;  __list_del_entry include/linux/list.h:218 [inline]&#xA;  list_move_tail include/linux/list.h:310 [inline]&#xA;  fq_tin_dequeue include/net/fq_impl.h:112 [inline]&#xA;  ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854&#xA;  wake_tx_push_queue net/mac80211/util.c:294 [inline]&#xA;  ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315&#xA;  drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]&#xA;  schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]&#xA;  ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664&#xA;  ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966&#xA;  ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062&#xA;  __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338&#xA;  ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532&#xA;  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:4917 [inline]&#xA;  xmit_one net/core/dev.c:3531 [inline]&#xA;  dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547&#xA;  __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341&#xA;  dev_queue_xmit include/linux/netdevice.h:3091 [inline]&#xA;  neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563&#xA;  neigh_output include/net/neighbour.h:542 [inline]&#xA;  ip6_fini&#xA;---truncated---&#xA;CVE-2024-42102:In the Linux kernel, the following vulnerability has been resolved:&#xA;Revert &#34;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&#34;&#xA;Patch series &#34;mm: Avoid possible overflows in dirty throttling&#34;.&#xA;Dirty throttling logic assumes dirty limits in page units fit into&#xA;32-bits.  This patch series makes sure this is true (see patch 2/2 for&#xA;more details).&#xA;This patch (of 2):&#xA;This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.&#xA;The commit is broken in several ways.  Firstly, the removed (u64) cast&#xA;from the multiplication will introduce a multiplication overflow on 32-bit&#xA;archs if wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (which is actually common - the&#xA;default settings with 4GB of RAM will trigger this).  Secondly, the&#xA;div64_u64() is unnecessarily expensive on 32-bit archs.  We have&#xA;div64_ul() in case we want to be safe &amp; cheap.  Thirdly, if dirty&#xA;thresholds are larger than 1&lt;&lt;32 pages, then dirty balancing is going to&#xA;blow up in many other spectacular ways anyway so trying to fix one&#xA;possible overflow is just moot.&#xA;CVE-2024-42225:In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: replace skb_put with skb_put_zeroAvoid potentially reusing uninitialized data&#xA;CVE-2024-41042:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: prefer nft_chain_validate&#xA;nft_chain_validate already performs loop detection because a cycle will&#xA;result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).&#xA;It also follows maps via -&gt;validate callback in nft_lookup, so there&#xA;appears no reason to iterate the maps again.&#xA;nf_tables_check_loops() and all its helper functions can be removed.&#xA;This improves ruleset load time significantly, from 23s down to 12s.&#xA;This also fixes a crash bug. Old loop detection code can result in&#xA;unbounded recursion:&#xA;BUG: TASK stack guard page was hit at ....&#xA;Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN&#xA;CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1&#xA;[..]&#xA;with a suitable ruleset during validation of register stores.&#xA;I can&#39;t see any actual reason to attempt to check for this from&#xA;nft_validate_register_store(), at this point the transaction is still in&#xA;progress, so we don&#39;t have a full picture of the rule graph.&#xA;For nf-next it might make sense to either remove it or make this depend&#xA;on table-&gt;validate_state in case we could catch an error earlier&#xA;(for improved error reporting to userspace).&#xA;CVE-2024-42247:In the Linux kernel, the following vulnerability has been resolved:&#xA;wireguard: allowedips: avoid unaligned 64-bit memory accesses&#xA;On the parisc platform, the kernel issues kernel warnings because&#xA;swap_endian() tries to load a 128-bit IPv6 address from an unaligned&#xA;memory location:&#xA; Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)&#xA; Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)&#xA;Avoid such unaligned memory accesses by instead using the&#xA;get_unaligned_be64() helper macro.&#xA;[Jason: replace src[8] in original patch with src+8]&#xA;CVE-2024-42223:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: dvb-frontends: tda10048: Fix integer overflow&#xA;state-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer&#xA;when multiplied by pll_mfactor.&#xA;Create a new 64 bit variable to hold the calculations.&#xA;CVE-2024-42246:In the Linux kernel, the following vulnerability has been resolved:&#xA;net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket&#xA;When using a BPF program on kernel_connect(), the call can return -EPERM. This&#xA;causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing&#xA;the kernel to potentially freeze up.&#xA;Neil suggested:&#xA;  This will propagate -EPERM up into other layers which might not be ready&#xA;  to handle it. It might be safer to map EPERM to an error we would be more&#xA;  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.&#xA;ECONNREFUSED as error seems reasonable. For programs setting a different error&#xA;can be out of reach (see handling in 4fbac77d2d09) in particular on kernels&#xA;which do not have f10d05966196 (&#34;bpf: Make BPF_PROG_RUN_ARRAY return -err&#xA;instead of allow boolean&#34;), thus given that it is better to simply remap for&#xA;consistent behavior. UDP does handle EPERM in xs_udp_send_request().&#xA;CVE-2024-42244:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: serial: mos7840: fix crash on resume&#xA;Since commit c49cfa917025 (&#34;USB: serial: use generic method if no&#xA;alternative is provided in usb serial layer&#34;), USB serial core calls the&#xA;generic resume implementation when the driver has not provided one.&#xA;This can trigger a crash on resume with mos7840 since support for&#xA;multiple read URBs was added back in 2011. Specifically, both port read&#xA;URBs are now submitted on resume for open ports, but the context pointer&#xA;of the second URB is left set to the core rather than mos7840 port&#xA;structure.&#xA;Fix this by implementing dedicated suspend and resume functions for&#xA;mos7840.&#xA;Tested with Delock 87414 USB 2.0 to 4x serial adapter.&#xA;[ johan: analyse crash and rewrite commit message; set busy flag on&#xA;         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]&#xA;CVE-2024-41092:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/i915/gt: Fix potential UAF by revoke of fence registers&#xA;CI has been sporadically reporting the following issue triggered by&#xA;igt@i915_selftest@live@hangcheck on ADL-P and similar machines:&#xA;&lt;6&gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence&#xA;...&#xA;&lt;6&gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled&#xA;&lt;6&gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled&#xA;&lt;3&gt; [414.070354] Unable to pin Y-tiled fence; err:-4&#xA;&lt;3&gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))&#xA;...&#xA;&lt;4&gt;[  609.603992] ------------[ cut here ]------------&#xA;&lt;2&gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!&#xA;&lt;4&gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;&lt;4&gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1&#xA;&lt;4&gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023&#xA;&lt;4&gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]&#xA;&lt;4&gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]&#xA;...&#xA;&lt;4&gt;[  609.604271] Call Trace:&#xA;&lt;4&gt;[  609.604273]  &lt;TASK&gt;&#xA;...&#xA;&lt;4&gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]&#xA;&lt;4&gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]&#xA;&lt;4&gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]&#xA;&lt;4&gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]&#xA;&lt;4&gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]&#xA;&lt;4&gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]&#xA;&lt;4&gt;[  609.605440]  process_scheduled_works+0x351/0x690&#xA;...&#xA;In the past, there were similar failures reported by CI from other IGT&#xA;tests, observed on other platforms.&#xA;Before commit 63baf4f3d587 (&#34;drm/i915/gt: Only wait for GPU activity&#xA;before unbinding a GGTT fence&#34;), i915_vma_revoke_fence() was waiting for&#xA;idleness of vma-&gt;active via fence_update().   That commit introduced&#xA;vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait&#xA;selectively on that one instead of vma-&gt;active since only idleness of&#xA;fence registers was needed.  But then, another commit 0d86ee35097a&#xA;(&#34;drm/i915/gt: Make fence revocation unequivocal&#34;) replaced the call to&#xA;fence_update() in i915_vma_revoke_fence() with only fence_write(), and&#xA;also added that GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active)) in front.&#xA;No justification was provided on why we might then expect idleness of&#xA;vma-&gt;fence-&gt;active without first waiting on it.&#xA;The issue can be potentially caused by a race among revocation of fence&#xA;registers on one side and sequential execution of signal callbacks invoked&#xA;on completion of a request that was using them on the other, still&#xA;processed in parallel to revocation of those fence registers.  Fix it by&#xA;waiting for idleness of vma-&gt;fence-&gt;active in i915_vma_revoke_fence().&#xA;(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)&#xA;CVE-2024-42087:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep&#xA;The ilitek-ili9881c controls the reset GPIO using the non-sleeping&#xA;gpiod_set_value() function. This complains loudly when the GPIO&#xA;controller needs to sleep. As the caller can sleep, use&#xA;gpiod_set_value_cansleep() to fix the issue.&#xA;CVE-2024-42143:In the Linux kernel, the following vulnerability has been resolved:&#xA;orangefs: fix out-of-bounds fsid access&#xA;Arnd Bergmann sent a patch to fsdevel, he says:&#xA;&#34;orangefs_statfs() copies two consecutive fields of the superblock into&#xA;the statfs structure, which triggers a warning from the string fortification&#xA;helpers&#34;&#xA;Jan Kara suggested an alternate way to do the patch to make it more readable.&#xA;I ran both ideas through xfstests and both seem fine. This patch&#xA;is based on Jan Kara&#39;s suggestion.&#xA;CVE-2024-42229:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: aead,cipher - zeroize key buffer after use&#xA;I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding&#xA;cryptographic information should be zeroized once they are no longer&#xA;needed. Accomplish this by using kfree_sensitive for buffers that&#xA;previously held the private key.&#xA;CVE-2024-42156:In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of clear-key structures on failureWipe all sensitive data from stack for all IOCTLs, which convert aclear-key into a protected- or secure-key.&#xA;CVE-2024-35840:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()&#xA;subflow_finish_connect() uses four fields (backup, join_id, thmac, none)&#xA;that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set&#xA;in mptcp_parse_option()&#xA;CVE-2024-36971:In the Linux kernel, the following vulnerability has been resolved:net: fix __dst_negative_advice() race__dst_negative_advice() does not enforce proper RCU rules whensk-&gt;dst_cache must be cleared, leading to possible UAF.RCU rules are that we must first clear sk-&gt;sk_dst_cache,then call dst_release(old_dst).Note that sk_dst_reset(sk) is implementing this protocol correctly,while __dst_negative_advice() uses the wrong order.Given that ip6_negative_advice() has special logicagainst RTF_CACHE, this means each of the three -&gt;negative_advice()existing methods must perform the sk_dst_reset() themselves.Note the check against NULL dst is centralized in__dst_negative_advice(), there is no need to duplicateit in various callbacks.Many thanks to Clement Lecigne for tracking this issue.This old bug became visible after the blamed commit, using UDP sockets.&#xA;CVE-2024-37356:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: Fix shift-out-of-bounds in dctcp_update_alpha().&#xA;In dctcp_update_alpha(), we use a module parameter dctcp_shift_g&#xA;as follows:&#xA;  alpha -= min_not_zero(alpha, alpha &gt;&gt; dctcp_shift_g);&#xA;  ...&#xA;  delivered_ce &lt;&lt;= (10 - dctcp_shift_g);&#xA;It seems syzkaller started fuzzing module parameters and triggered&#xA;shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:&#xA;  memcpy((void*)0x20000080,&#xA;         &#34;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000&#34;, 47);&#xA;  res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,&#xA;                /*flags=*/2ul, /*mode=*/0ul);&#xA;  memcpy((void*)0x20000000, &#34;100\000&#34;, 4);&#xA;  syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);&#xA;Let&#39;s limit the max value of dctcp_shift_g by param_set_uint_minmax().&#xA;With this patch:&#xA;  # echo 10 &gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g&#xA;  # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g&#xA;  10&#xA;  # echo 11 &gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g&#xA;  -bash: echo: write error: Invalid argument&#xA;[0]:&#xA;UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12&#xA;shift exponent 100 is too large for 32-bit type &#39;u32&#39; (aka &#39;unsigned int&#39;)&#xA;CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;1.13.0-1ubuntu1.1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114&#xA; ubsan_epilogue lib/ubsan.c:231 [inline]&#xA; __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468&#xA; dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143&#xA; tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]&#xA; tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948&#xA; tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711&#xA; tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937&#xA; sk_backlog_rcv include/net/sock.h:1106 [inline]&#xA; __release_sock+0x20f/0x350 net/core/sock.c:2983&#xA; release_sock+0x61/0x1f0 net/core/sock.c:3549&#xA; mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907&#xA; mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976&#xA; __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072&#xA; mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127&#xA; inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437&#xA; __sock_release net/socket.c:659 [inline]&#xA; sock_close+0xc0/0x240 net/socket.c:1421&#xA; __fput+0x41b/0x890 fs/file_table.c:422&#xA; task_work_run+0x23b/0x300 kernel/task_work.c:180&#xA; exit_task_work include/linux/task_work.h:38 [inline]&#xA; do_exit+0x9c8/0x2540 kernel/exit.c:878&#xA; do_group_exit+0x201/0x2b0 kernel/exit.c:1027&#xA; __do_sys_exit_group kernel/exit.c:1038 [inline]&#xA; __se_sys_exit_group kernel/exit.c:1036 [inline]&#xA; __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x67/0x6f&#xA;RIP: 0033:0x7f6c2b5005b6&#xA;Code: Unable to access opcode bytes at 0x7f6c2b50058c.&#xA;RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7&#xA;RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6&#xA;RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001&#xA;RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0&#xA;R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0&#xA;R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001&#xA; &lt;/TASK&gt;&#xA;CVE-2024-35879:In the Linux kernel, the following vulnerability has been resolved:&#xA;of: dynamic: Synchronize of_changeset_destroy() with the devlink removals&#xA;In the following sequence:&#xA;  1) of_platform_depopulate()&#xA;  2) of_overlay_remove()&#xA;During the step 1, devices are destroyed and devlinks are removed.&#xA;During the step 2, OF nodes are destroyed but&#xA;__of_changeset_entry_destroy() can raise warnings related to missing&#xA;of_node_put():&#xA;  ERROR: memory leak, expected refcount 1 instead of 2 ...&#xA;Indeed, during the devlink removals performed at step 1, the removal&#xA;itself releasing the device (and the attached of_node) is done by a job&#xA;queued in a workqueue and so, it is done asynchronously with respect to&#xA;function calls.&#xA;When the warning is present, of_node_put() will be called but wrongly&#xA;too late from the workqueue job.&#xA;In order to be sure that any ongoing devlink removals are done before&#xA;the of_node destruction, synchronize the of_changeset_destroy() with the&#xA;devlink removals.&#xA;CVE-2024-39362:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-27415:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: bridge: confirm multicast packets before passing them up the stack&#xA;conntrack nf_confirm logic cannot handle cloned skbs referencing&#xA;the same nf_conn entry, which will happen for multicast (broadcast)&#xA;frames on bridges.&#xA; Example:&#xA;    macvlan0&#xA;       |&#xA;      br0&#xA;     /  \&#xA;  ethX    ethY&#xA; ethX (or Y) receives a L2 multicast or broadcast packet containing&#xA; an IP packet, flow is not yet in conntrack table.&#xA; 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.&#xA;    -&gt; skb-&gt;_nfct now references a unconfirmed entry&#xA; 2. skb is broad/mcast packet. bridge now passes clones out on each bridge&#xA;    interface.&#xA; 3. skb gets passed up the stack.&#xA; 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb&#xA;    and schedules a work queue to send them out on the lower devices.&#xA;    The clone skb-&gt;_nfct is not a copy, it is the same entry as the&#xA;    original skb.  The macvlan rx handler then returns RX_HANDLER_PASS.&#xA; 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.&#xA;The Macvlan broadcast worker and normal confirm path will race.&#xA;This race will not happen if step 2 already confirmed a clone. In that&#xA;case later steps perform skb_clone() with skb-&gt;_nfct already confirmed (in&#xA;hash table).  This works fine.&#xA;But such confirmation won&#39;t happen when eb/ip/nftables rules dropped the&#xA;packets before they reached the nf_confirm step in postrouting.&#xA;Pablo points out that nf_conntrack_bridge doesn&#39;t allow use of stateful&#xA;nat, so we can safely discard the nf_conn entry and let inet call&#xA;conntrack again.&#xA;This doesn&#39;t work for bridge netfilter: skb could have a nat&#xA;transformation. Also bridge nf prevents re-invocation of inet prerouting&#xA;via &#39;sabotage_in&#39; hook.&#xA;Work around this problem by explicit confirmation of the entry at LOCAL_IN&#xA;time, before upper layer has a chance to clone the unconfirmed entry.&#xA;The downside is that this disables NAT and conntrack helpers.&#xA;Alternative fix would be to add locking to all code parts that deal with&#xA;unconfirmed packets, but even if that could be done in a sane way this&#xA;opens up other problems, for example:&#xA;-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4&#xA;-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5&#xA;For multicast case, only one of such conflicting mappings will be&#xA;created, conntrack only handles 1:1 NAT mappings.&#xA;Users should set create a setup that explicitly marks such traffic&#xA;NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass&#xA;them, ruleset might have accept rules for untracked traffic already,&#xA;so user-visible behaviour would change.&#xA;CVE-2024-35839:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: bridge: replace physindev with physinif in nf_bridge_info&#xA;An skb can be added to a neigh-&gt;arp_queue while waiting for an arp&#xA;reply. Where original skb&#39;s skb-&gt;dev can be different to neigh&#39;s&#xA;neigh-&gt;dev. For instance in case of bridging dnated skb from one veth to&#xA;another, the skb would be added to a neigh-&gt;arp_queue of the bridge.&#xA;As skb-&gt;dev can be reset back to nf_bridge-&gt;physindev and used, and as&#xA;there is no explicit mechanism that prevents this physindev from been&#xA;freed under us (for instance neigh_flush_dev doesn&#39;t cleanup skbs from&#xA;different device&#39;s neigh queue) we can crash on e.g. this stack:&#xA;arp_process&#xA;  neigh_update&#xA;    skb = __skb_dequeue(&amp;neigh-&gt;arp_queue)&#xA;      neigh_resolve_output(..., skb)&#xA;        ...&#xA;          br_nf_dev_xmit&#xA;            br_nf_pre_routing_finish_bridge_slow&#xA;              skb-&gt;dev = nf_bridge-&gt;physindev&#xA;              br_handle_frame_finish&#xA;Let&#39;s use plain ifindex instead of net_device link. To peek into the&#xA;original net_device we will use dev_get_by_index_rcu(). Thus either we&#xA;get device and are safe to use it or we don&#39;t get it and drop skb.&#xA;CVE-2024-35819:In the Linux kernel, the following vulnerability has been resolved:&#xA;soc: fsl: qbman: Use raw spinlock for cgr_lock&#xA;smp_call_function always runs its callback in hard IRQ context, even on&#xA;PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock&#xA;for cgr_lock to ensure we aren&#39;t waiting on a sleeping task.&#xA;Although this bug has existed for a while, it was not apparent until&#xA;commit ef2a8d5478b9 (&#34;net: dpaa: Adjust queue depth on rate change&#34;)&#xA;which invokes smp_call_function_single via qman_update_cgr_safe every&#xA;time a link goes up or down.&#xA;CVE-2021-47366:In the Linux kernel, the following vulnerability has been resolved:&#xA;afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server&#xA;AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and&#xA;Linux&#39;s afs client switches between them when talking to a non-YFS server&#xA;if the read size, the file position or the sum of the two have the upper 32&#xA;bits set of the 64-bit value.&#xA;This is a problem, however, since the file position and length fields of&#xA;FS.FetchData are *signed* 32-bit values.&#xA;Fix this by capturing the capability bits obtained from the fileserver when&#xA;it&#39;s sent an FS.GetCapabilities RPC, rather than just discarding them, and&#xA;then picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be&#xA;used to decide whether to use FS.FetchData or FS.FetchData64 - and also&#xA;FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to&#xA;switch on the parameter values.&#xA;This capabilities flag could also be used to limit the maximum size of the&#xA;file, but all servers must be checked for that.&#xA;Note that the issue does not exist with FS.StoreData - that uses *unsigned*&#xA;32-bit values.  It&#39;s also not a problem with Auristor servers as its&#xA;YFS.FetchData64 op uses unsigned 64-bit values.&#xA;This can be tested by cloning a git repo through an OpenAFS client to an&#xA;OpenAFS server and then doing &#34;git status&#34; on it from a Linux afs&#xA;client[1].  Provided the clone has a pack file that&#39;s in the 2G-4G range,&#xA;the git status will show errors like:&#xA;&#x9;error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index&#xA;&#x9;error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index&#xA;This can be observed in the server&#39;s FileLog with something like the&#xA;following appearing:&#xA;Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001&#xA;Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001&#xA;Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154&#xA;Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866&#xA;...&#xA;Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5&#xA;Note the file position of 18446744071815340032.  This is the requested file&#xA;position sign-extended.&#xA;CVE-2024-36968:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()&#xA;l2cap_le_flowctl_init() can cause both div-by-zero and an integer&#xA;overflow since hdev-&gt;le_mtu may not fall in the valid range.&#xA;Move MTU from hci_dev to hci_conn to validate MTU and stop the connection&#xA;process earlier if MTU is invalid.&#xA;Also, add a missing validation in read_buffer_size() and make it return&#xA;an error value if the validation fails.&#xA;Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a&#xA;kzalloc failure and invalid MTU value.&#xA;divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;Workqueue: hci0 hci_rx_work&#xA;RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547&#xA;Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c&#xA;89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 &lt;66&gt; f7 f3 89 c3 ff c3 4d 8d&#xA;b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42&#xA;RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246&#xA;RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000&#xA;RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f&#xA;RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa&#xA;R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084&#xA;R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000&#xA;FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]&#xA; l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]&#xA; l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]&#xA; l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809&#xA; l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506&#xA; hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]&#xA; hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176&#xA; process_one_work kernel/workqueue.c:3254 [inline]&#xA; process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335&#xA; worker_thread+0x926/0xe70 kernel/workqueue.c:3416&#xA; kthread+0x2e3/0x380 kernel/kthread.c:388&#xA; ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;---[ end trace 0000000000000000 ]---&#xA;CVE-2021-47469:In the Linux kernel, the following vulnerability has been resolved:&#xA;spi: Fix deadlock when adding SPI controllers on SPI buses&#xA;Currently we have a global spi_add_lock which we take when adding new&#xA;devices so that we can check that we&#39;re not trying to reuse a chip&#xA;select that&#39;s already controlled.  This means that if the SPI device is&#xA;itself a SPI controller and triggers the instantiation of further SPI&#xA;devices we trigger a deadlock as we try to register and instantiate&#xA;those devices while in the process of doing so for the parent controller&#xA;and hence already holding the global spi_add_lock.  Since we only care&#xA;about concurrency within a single SPI bus move the lock to be per&#xA;controller, avoiding the deadlock.&#xA;This can be easily triggered in the case of spi-mux.&#xA;CVE-2024-38588:In the Linux kernel, the following vulnerability has been resolved:&#xA;ftrace: Fix possible use-after-free issue in ftrace_location()&#xA;KASAN reports a bug:&#xA;  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120&#xA;  Read of size 8 at addr ffff888141d40010 by task insmod/424&#xA;  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+&#xA;  [...]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x68/0xa0&#xA;   print_report+0xcf/0x610&#xA;   kasan_report+0xb5/0xe0&#xA;   ftrace_location+0x90/0x120&#xA;   register_kprobe+0x14b/0xa40&#xA;   kprobe_init+0x2d/0xff0 [kprobe_example]&#xA;   do_one_initcall+0x8f/0x2d0&#xA;   do_init_module+0x13a/0x3c0&#xA;   load_module+0x3082/0x33d0&#xA;   init_module_from_file+0xd2/0x130&#xA;   __x64_sys_finit_module+0x306/0x440&#xA;   do_syscall_64+0x68/0x140&#xA;   entry_SYSCALL_64_after_hwframe+0x71/0x79&#xA;The root cause is that, in lookup_rec(), ftrace record of some address&#xA;is being searched in ftrace pages of some module, but those ftrace pages&#xA;at the same time is being freed in ftrace_release_mod() as the&#xA;corresponding module is being deleted:&#xA;           CPU1                       |      CPU2&#xA;  register_kprobes() {                | delete_module() {&#xA;    check_kprobe_address_safe() {     |&#xA;      arch_check_ftrace_location() {  |&#xA;        ftrace_location() {           |&#xA;          lookup_rec() // USE!        |   ftrace_release_mod() // Free!&#xA;To fix this issue:&#xA;  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();&#xA;  2. Use ftrace_location_range() instead of lookup_rec() in&#xA;     ftrace_location();&#xA;  3. Call synchronize_rcu() before freeing any ftrace pages both in&#xA;     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().&#xA;CVE-2021-47599:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: use latest_dev in btrfs_show_devname&#xA;The test case btrfs/238 reports the warning below:&#xA; WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]&#xA; CPU: 2 PID: 1 Comm: systemd Tainted: G        W  O 5.14.0-rc1-custom #72&#xA; Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015&#xA; Call trace:&#xA;   btrfs_show_devname+0x108/0x1b4 [btrfs]&#xA;   show_mountinfo+0x234/0x2c4&#xA;   m_show+0x28/0x34&#xA;   seq_read_iter+0x12c/0x3c4&#xA;   vfs_read+0x29c/0x2c8&#xA;   ksys_read+0x80/0xec&#xA;   __arm64_sys_read+0x28/0x34&#xA;   invoke_syscall+0x50/0xf8&#xA;   do_el0_svc+0x88/0x138&#xA;   el0_svc+0x2c/0x8c&#xA;   el0t_64_sync_handler+0x84/0xe4&#xA;   el0t_64_sync+0x198/0x19c&#xA;Reason:&#xA;While btrfs_prepare_sprout() moves the fs_devices::devices into&#xA;fs_devices::seed_list, the btrfs_show_devname() searches for the devices&#xA;and found none, leading to the warning as in above.&#xA;Fix:&#xA;latest_dev is updated according to the changes to the device list.&#xA;That means we could use the latest_dev-&gt;name to show the device name in&#xA;/proc/self/mounts, the pointer will be always valid as it&#39;s assigned&#xA;before the device is deleted from the list in remove or replace.&#xA;The RCU protection is sufficient as the device structure is freed after&#xA;synchronization.&#xA;CVE-2024-38623:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Use variable length array instead of fixed size&#xA;Should fix smatch warning:&#xA;&#x9;ntfs_set_label() error: __builtin_memcpy() &#39;uni-&gt;name&#39; too small (20 vs 256)&#xA;CVE-2024-26921:In the Linux kernel, the following vulnerability has been resolved:&#xA;inet: inet_defrag: prevent sk release while still in use&#xA;ip_local_out() and other functions can pass skb-&gt;sk as function argument.&#xA;If the skb is a fragment and reassembly happens before such function call&#xA;returns, the sk must not be released.&#xA;This affects skb fragments reassembled via netfilter or similar&#xA;modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.&#xA;Eric Dumazet made an initial analysis of this bug.  Quoting Eric:&#xA;  Calling ip_defrag() in output path is also implying skb_orphan(),&#xA;  which is buggy because output path relies on sk not disappearing.&#xA;  A relevant old patch about the issue was :&#xA;  8282f27449bf (&#34;inet: frag: Always orphan skbs inside ip_defrag()&#34;)&#xA;  [..]&#xA;  net/ipv4/ip_output.c depends on skb-&gt;sk being set, and probably to an&#xA;  inet socket, not an arbitrary one.&#xA;  If we orphan the packet in ipvlan, then downstream things like FQ&#xA;  packet scheduler will not work properly.&#xA;  We need to change ip_defrag() to only use skb_orphan() when really&#xA;  needed, ie whenever frag_list is going to be used.&#xA;Eric suggested to stash sk in fragment queue and made an initial patch.&#xA;However there is a problem with this:&#xA;If skb is refragmented again right after, ip_do_fragment() will copy&#xA;head-&gt;sk to the new fragments, and sets up destructor to sock_wfree.&#xA;IOW, we have no choice but to fix up sk_wmem accouting to reflect the&#xA;fully reassembled skb, else wmem will underflow.&#xA;This change moves the orphan down into the core, to last possible moment.&#xA;As ip_defrag_offset is aliased with sk_buff-&gt;sk member, we must move the&#xA;offset into the FRAG_CB, else skb-&gt;sk gets clobbered.&#xA;This allows to delay the orphaning long enough to learn if the skb has&#xA;to be queued or if the skb is completing the reasm queue.&#xA;In the former case, things work as before, skb is orphaned.  This is&#xA;safe because skb gets queued/stolen and won&#39;t continue past reasm engine.&#xA;In the latter case, we will steal the skb-&gt;sk reference, reattach it to&#xA;the head skb, and fix up wmem accouting when inet_frag inflates truesize.&#xA;CVE-2024-26592:In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix UAF issue in ksmbd_tcp_new_connection()The race is between the handling of a new TCP connection andits disconnection. It leads to UAF on `struct tcp_transport` inksmbd_tcp_new_connection() function.&#xA;CVE-2024-38556:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Add a timeout to acquire the command queue semaphore&#xA;Prevent forced completion handling on an entry that has not yet been&#xA;assigned an index, causing an out of bounds access on idx = -22.&#xA;Instead of waiting indefinitely for the sem, blocking flow now waits for&#xA;index to be allocated or a sem acquisition timeout before beginning the&#xA;timer for FW completion.&#xA;Kernel log example:&#xA;mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion&#xA;CVE-2022-48744:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: Avoid field-overflowing memcpy()&#xA;In preparation for FORTIFY_SOURCE performing compile-time and run-time&#xA;field bounds checking for memcpy(), memmove(), and memset(), avoid&#xA;intentionally writing across neighboring fields.&#xA;Use flexible arrays instead of zero-element arrays (which look like they&#xA;are always overflowing) and split the cross-field memcpy() into two halves&#xA;that can be appropriately bounds-checked by the compiler.&#xA;We were doing:&#xA;&#x9;#define ETH_HLEN  14&#xA;&#x9;#define VLAN_HLEN  4&#xA;&#x9;...&#xA;&#x9;#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)&#xA;&#x9;...&#xA;        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);&#xA;&#x9;...&#xA;        struct mlx5_wqe_eth_seg  *eseg = &amp;wqe-&gt;eth;&#xA;        struct mlx5_wqe_data_seg *dseg = wqe-&gt;data;&#xA;&#x9;...&#xA;&#x9;memcpy(eseg-&gt;inline_hdr.start, xdptxd-&gt;data, MLX5E_XDP_MIN_INLINE);&#xA;target is wqe-&gt;eth.inline_hdr.start (which the compiler sees as being&#xA;2 bytes in size), but copying 18, intending to write across start&#xA;(really vlan_tci, 2 bytes). The remaining 16 bytes get written into&#xA;wqe-&gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr&#xA;(8 bytes).&#xA;struct mlx5e_tx_wqe {&#xA;        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */&#xA;        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */&#xA;        struct mlx5_wqe_data_seg   data[];               /*    32     0 */&#xA;        /* size: 32, cachelines: 1, members: 3 */&#xA;        /* last cacheline: 32 bytes */&#xA;};&#xA;struct mlx5_wqe_eth_seg {&#xA;        u8                         swp_outer_l4_offset;  /*     0     1 */&#xA;        u8                         swp_outer_l3_offset;  /*     1     1 */&#xA;        u8                         swp_inner_l4_offset;  /*     2     1 */&#xA;        u8                         swp_inner_l3_offset;  /*     3     1 */&#xA;        u8                         cs_flags;             /*     4     1 */&#xA;        u8                         swp_flags;            /*     5     1 */&#xA;        __be16                     mss;                  /*     6     2 */&#xA;        __be32                     flow_table_metadata;  /*     8     4 */&#xA;        union {&#xA;                struct {&#xA;                        __be16     sz;                   /*    12     2 */&#xA;                        u8         start[2];             /*    14     2 */&#xA;                } inline_hdr;                            /*    12     4 */&#xA;                struct {&#xA;                        __be16     type;                 /*    12     2 */&#xA;                        __be16     vlan_tci;             /*    14     2 */&#xA;                } insert;                                /*    12     4 */&#xA;                __be32             trailer;              /*    12     4 */&#xA;        };                                               /*    12     4 */&#xA;        /* size: 16, cachelines: 1, members: 9 */&#xA;        /* last cacheline: 16 bytes */&#xA;};&#xA;struct mlx5_wqe_data_seg {&#xA;        __be32                     byte_count;           /*     0     4 */&#xA;        __be32                     lkey;                 /*     4     4 */&#xA;        __be64                     addr;                 /*     8     8 */&#xA;        /* size: 16, cachelines: 1, members: 3 */&#xA;        /* last cacheline: 16 bytes */&#xA;};&#xA;So, split the memcpy() so the compiler can reason about the buffer&#xA;sizes.&#xA;&#34;pahole&#34; shows no size nor member offset changes to struct mlx5e_tx_wqe&#xA;nor struct mlx5e_umr_wqe. &#34;objdump -d&#34; shows no meaningful object&#xA;code changes (i.e. only source line number induced differences and&#xA;optimizations).</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/kernel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/kernel-headers-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/kernel-devel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/kernel-tools-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/kernel-tools-devel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/perf-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-perf-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/bpftool-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/kernel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/kernel-headers-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/kernel-devel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/kernel-tools-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/kernel-tools-devel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/perf-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/python3-perf-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/bpftool-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2286</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7006" id="CVE-2024-7006" title="CVE-2024-7006" type="cve"></reference>
		</references>
		<description>CVE-2024-7006:A null pointer dereference flaw was found in Libtiff via `tif_dirinfo.c`. This issue may allow an attacker to trigger memory allocation failures through certain means, such as restricting the heap space size or injecting faults, causing a segmentation fault. This can cause an application crash, eventually leading to a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-38.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libtiff-4.3.0-38.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-38.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libtiff-devel-4.3.0-38.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-38.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libtiff-static-4.3.0-38.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-38.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libtiff-tools-4.3.0-38.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-38.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libtiff-help-4.3.0-38.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-38.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libtiff-4.3.0-38.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-38.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libtiff-devel-4.3.0-38.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-38.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libtiff-static-4.3.0-38.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-38.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libtiff-tools-4.3.0-38.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2287</id>
		<title>An update for libvpx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5197" id="CVE-2024-5197" title="CVE-2024-5197" type="cve"></reference>
		</references>
		<description>CVE-2024-5197:There exists interger overflows in libvpx in versions prior to 1.14.1. Calling vpx_img_alloc() with a large value of the d_w, d_h, or align parameter may result in integer overflows in the calculations of buffer sizes and offsets and some fields of the returned vpx_image_t struct may be invalid. Calling vpx_img_wrap() with a large value of the d_w, d_h, or stride_align parameter may result in integer overflows in the calculations of buffer sizes and offsets and some fields of the returned vpx_image_t struct may be invalid. We recommend upgrading to version 1.14.1 or beyond</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="libvpx" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-1.7.0-12.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libvpx-1.7.0-12.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvpx-devel" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-devel-1.7.0-12.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libvpx-devel-1.7.0-12.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-1.7.0-12.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libvpx-1.7.0-12.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx-devel" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-devel-1.7.0-12.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/libvpx-devel-1.7.0-12.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2288</id>
		<title>An update for linux-sgx is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"></reference>
		</references>
		<description>CVE-2024-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a  no overlap response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="sgxsdk" release="12.u3.fos23" version="2.15.1">
					<filename>sgxsdk-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/sgxsdk-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qe3" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-qe3-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ae-qe3-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-pce-logic" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-pce-logic-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-pce-logic-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-qe3-logic" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-qe3-logic-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-qe3-logic-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-aesm-service" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-aesm-service-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/sgx-aesm-service-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-epid" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-epid-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ae-epid-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-le" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-le-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ae-le-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-pce" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-pce-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ae-pce-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-ecdsa-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-ecdsa-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-aesm-ecdsa-plugin-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-epid-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-epid-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-aesm-epid-plugin-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-launch-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-launch-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-aesm-launch-plugin-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-pce-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-pce-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-aesm-pce-plugin-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-quote-ex-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-quote-ex-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-aesm-quote-ex-plugin-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-epid-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-epid-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-epid-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-epid-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-launch-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-launch-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-launch-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-launch-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-quote-ex-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-quote-ex-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-uae-service" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-uae-service-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-uae-service-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-enclave-common-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-enclave-common-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-urts" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-urts-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-urts-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-dcap-default-qpl-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-dcap-default-qpl-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-dcap-pccs" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-dcap-pccs-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/sgx-dcap-pccs-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-dcap-ql-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-dcap-ql-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qve" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-qve-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ae-qve-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-dcap-quote-verify-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-dcap-quote-verify-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-pck-id-retrieval-tool" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-pck-id-retrieval-tool-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/sgx-pck-id-retrieval-tool-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ra-uefi-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ra-uefi-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-network-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ra-network-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-network-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-ra-network-devel-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-ra-service" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-ra-service-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/sgx-ra-service-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-headers" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-headers-2.15.1-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/libsgx-headers-2.15.1-12.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2289</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21125" id="CVE-2024-21125" title="CVE-2024-21125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21142" id="CVE-2024-21142" title="CVE-2024-21142" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21179" id="CVE-2024-21179" title="CVE-2024-21179" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21171" id="CVE-2024-21171" title="CVE-2024-21171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21130" id="CVE-2024-21130" title="CVE-2024-21130" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21162" id="CVE-2024-21162" title="CVE-2024-21162" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21177" id="CVE-2024-21177" title="CVE-2024-21177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20996" id="CVE-2024-20996" title="CVE-2024-20996" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21134" id="CVE-2024-21134" title="CVE-2024-21134" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21165" id="CVE-2024-21165" title="CVE-2024-21165" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21173" id="CVE-2024-21173" title="CVE-2024-21173" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21129" id="CVE-2024-21129" title="CVE-2024-21129" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21127" id="CVE-2024-21127" title="CVE-2024-21127" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21163" id="CVE-2024-21163" title="CVE-2024-21163" type="cve"></reference>
		</references>
		<description>CVE-2024-21125:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21142:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21179:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21171:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21130:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21162:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21177:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-20996:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21134:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Connection Handling).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 4.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21165:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Pluggable Auth).  Supported versions that are affected are 8.0.37 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21173:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21129:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21127:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21163:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-libs-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-libs-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-config-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-config-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-common-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-common-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-errmsg-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-errmsg-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-server-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-server-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-devel-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-devel-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-test-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-test-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-help-8.0.38-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/mysql-help-8.0.38-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-libs-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-libs-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-config-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-config-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-common-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-common-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-errmsg-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-errmsg-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-server-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-server-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-devel-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-devel-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-test-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-test-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-help-8.0.38-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/mysql-help-8.0.38-1.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2290</id>
		<title>An update for nginx is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7347" id="CVE-2024-7347" title="CVE-2024-7347" type="cve"></reference>
		</references>
		<description>CVE-2024-7347:NGINX Open Source and NGINX Plus have a vulnerability in the ngx_http_mp4_module, which might allow an attacker to over-read NGINX worker memory resulting in its termination, using a specially crafted mp4 file. The issue only affects NGINX if it is built with the ngx_http_mp4_module and the mp4 directive is used in the configuration file. Additionally, the attack is possible only if an attacker can trigger the processing of a specially crafted mp4 file with the ngx_http_mp4_module.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="1" name="nginx" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-all-modules-1.21.5-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-filesystem-1.21.5-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-mod-http-image-filter-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-mod-http-perl-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-mod-http-xslt-filter-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-mod-mail-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-mod-stream-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-mod-devel-1.21.5-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-help-1.21.5-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/nginx-help-1.21.5-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-mod-http-image-filter-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-mod-http-perl-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-mod-http-xslt-filter-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-mod-mail-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-mod-stream-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/nginx-mod-devel-1.21.5-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2291</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"></reference>
		</references>
		<description>CVE-2024-4741:A use-after-free vulnerability was found in OpenSSL. Calling the OpenSSL API SSL_free_buffers function may cause memory to be accessed that was previously freed in some situations.&#xA;CVE-2024-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a  no overlap response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u6.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/openresty-openssl111-asan-1.1.1h-2.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u6.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/openresty-openssl111-asan-1.1.1h-2.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2292</id>
		<title>An update for openvpn is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5594" id="CVE-2024-5594" title="CVE-2024-5594" type="cve"></reference>
		</references>
		<description>CVE-2024-5594:OpenVPN incorrectly handled certain control channel messages with nonprintable characters. A remote attacker could possibly use this issue to cause OpenVPN to consume resources, or fill up log files with garbage, leading to a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="openvpn" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-2.5.5-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/openvpn-2.5.5-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvpn-devel" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-devel-2.5.5-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/openvpn-devel-2.5.5-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openvpn-help" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-help-2.5.5-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/openvpn-help-2.5.5-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-2.5.5-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/openvpn-2.5.5-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn-devel" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-devel-2.5.5-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/openvpn-devel-2.5.5-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2293</id>
		<title>An update for orc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40897" id="CVE-2024-40897" title="CVE-2024-40897" type="cve"></reference>
		</references>
		<description>CVE-2024-40897:Stack-based buffer overflow vulnerability exists in orcparse.c of ORC versions prior to 0.4.39. If a developer is tricked to process a specially crafted file with the affected ORC compiler, an arbitrary code may be executed on the developer s build environment. This may lead to compromise of developer machines or CI build environments.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="orc" release="3.u1.fos23" version="0.4.32">
					<filename>orc-0.4.32-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/orc-0.4.32-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="orc-help" release="3.u1.fos23" version="0.4.32">
					<filename>orc-help-0.4.32-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/orc-help-0.4.32-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="orc-devel" release="3.u1.fos23" version="0.4.32">
					<filename>orc-devel-0.4.32-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/orc-devel-0.4.32-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="orc-compiler" release="3.u1.fos23" version="0.4.32">
					<filename>orc-compiler-0.4.32-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/orc-compiler-0.4.32-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="orc" release="3.u1.fos23" version="0.4.32">
					<filename>orc-0.4.32-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/orc-0.4.32-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="orc-help" release="3.u1.fos23" version="0.4.32">
					<filename>orc-help-0.4.32-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/orc-help-0.4.32-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="orc-devel" release="3.u1.fos23" version="0.4.32">
					<filename>orc-devel-0.4.32-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/orc-devel-0.4.32-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="orc-compiler" release="3.u1.fos23" version="0.4.32">
					<filename>orc-compiler-0.4.32-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/orc-compiler-0.4.32-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2294</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5868" id="CVE-2023-5868" title="CVE-2023-5868" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5869" id="CVE-2023-5869" title="CVE-2023-5869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5870" id="CVE-2023-5870" title="CVE-2023-5870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7348" id="CVE-2024-7348" title="CVE-2024-7348" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0985" id="CVE-2024-0985" title="CVE-2024-0985" type="cve"></reference>
		</references>
		<description>CVE-2023-5868:A memory disclosure vulnerability was found in PostgreSQL that allows remote users to access sensitive information by exploiting certain aggregate function calls with &#39;unknown&#39;-type arguments. Handling &#39;unknown&#39;-type values from string literals without type designation can disclose bytes, potentially revealing notable and confidential information. This issue exists due to excessive data output in aggregate function calls, enabling remote users to read some portion of system memory.&#xA;CVE-2023-5869:A flaw was found in PostgreSQL that allows authenticated database users to execute arbitrary code through missing overflow checks during SQL array value modification. This issue exists due to an integer overflow during array modification where a remote user can trigger the overflow by providing specially crafted data. This enables the execution of arbitrary code on the target system, allowing users to write arbitrary bytes to memory and extensively read the server&#39;s memory.&#xA;CVE-2023-5870:A flaw was found in PostgreSQL involving the pg_cancel_backend role that signals background workers, including the log&#xA;ical replication launcher, autovacuum workers, and the autovacuum launcher. Successful exploitation requires a non-core extension w&#xA;ith a less-resilient background worker and would affect that specific background worker only. This issue may allow a remote high pr&#xA;ivileged user to launch a denial of service (DoS) attack.&#xA;CVE-2024-7348:Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.&#xA;CVE-2024-0985:Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker&#39;s roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker&#39;s materialized view. Versions before PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 are affected.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u3.fos23" version="13.16">
					<filename>postgresql-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-libs-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-private-libs-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-devel-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-private-devel-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-server-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-docs-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-docs-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u3.fos23" version="13.16">
					<filename>postgresql-contrib-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-contrib-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-devel-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-server-devel-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u3.fos23" version="13.16">
					<filename>postgresql-test-rpm-macros-13.16-1.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-test-rpm-macros-13.16-1.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u3.fos23" version="13.16">
					<filename>postgresql-static-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-static-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plperl-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-plperl-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plpython3-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-plpython3-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-pltcl-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-pltcl-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u3.fos23" version="13.16">
					<filename>postgresql-test-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-test-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u3.fos23" version="13.16">
					<filename>postgresql-llvmjit-13.16-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/postgresql-llvmjit-13.16-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u3.fos23" version="13.16">
					<filename>postgresql-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-libs-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-private-libs-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-devel-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-private-devel-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-server-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-docs-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-docs-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u3.fos23" version="13.16">
					<filename>postgresql-contrib-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-contrib-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-devel-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-server-devel-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u3.fos23" version="13.16">
					<filename>postgresql-static-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-static-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plperl-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-plperl-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plpython3-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-plpython3-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-pltcl-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-pltcl-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u3.fos23" version="13.16">
					<filename>postgresql-test-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-test-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u3.fos23" version="13.16">
					<filename>postgresql-llvmjit-13.16-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/postgresql-llvmjit-13.16-1.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2295</id>
		<title>An update for python-pip is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43804" id="CVE-2023-43804" title="CVE-2023-43804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3651" id="CVE-2024-3651" title="CVE-2024-3651" type="cve"></reference>
		</references>
		<description>CVE-2023-45803:urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn&#39;t remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren&#39;t putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn&#39;t exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren&#39;t expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.&#xA;CVE-2024-37891:urllib3 is a user-friendly HTTP client library for Python. When using urllib3 s proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3 s proxy support, it s possible to accidentally configure the `Proxy-Authorization` header even though it won t have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn t treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn t strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3 s proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren t using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3 s built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3 s `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.&#xA;CVE-2023-43804:urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn t treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn t disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.&#xA;CVE-2024-3651:A flaw was found in the python-idna library. A malicious argument was sent to the idna.encode() function can trigger an uncontrolled resource consumption, resulting in a denial of service.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="noarch" epoch="0" name="python3-pip" release="6.u4.fos23" version="21.3.1">
					<filename>python3-pip-21.3.1-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-pip-21.3.1-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-help" release="6.u4.fos23" version="21.3.1">
					<filename>python-pip-help-21.3.1-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python-pip-help-21.3.1-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-wheel" release="6.u4.fos23" version="21.3.1">
					<filename>python-pip-wheel-21.3.1-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python-pip-wheel-21.3.1-6.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2296</id>
		<title>An update for python-webob is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42353" id="CVE-2024-42353" title="CVE-2024-42353" type="cve"></reference>
		</references>
		<description>CVE-2024-42353:WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python s urlparse, and joining it to the base URL. `urlparse` however treats a `//` at the start of a string as a URI without a scheme, and then treats the next part as the hostname. `urljoin` will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="noarch" epoch="0" name="python3-webob" release="3.u1.fos23" version="1.8.7">
					<filename>python3-webob-1.8.7-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-webob-1.8.7-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2297</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4032" id="CVE-2024-4032" title="CVE-2024-4032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0397" id="CVE-2024-0397" title="CVE-2024-0397" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7592" id="CVE-2024-7592" title="CVE-2024-7592" type="cve"></reference>
		</references>
		<description>CVE-2024-4032:The “ipaddress” module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as “globally reachable” or “private”. This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn’t be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.&#xA;CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.&#xA;CVE-2024-0397:A defect was discovered in the Python “ssl” module where there is a memoryrace condition with the ssl.SSLContext methods “cert_store_stats()” and“get_ca_certs()”. The race condition can be triggered if the methods arecalled at the same time as certificates are loaded into the SSLContext,such as during the TLS handshake with a certificate directory configured.This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.&#xA;CVE-2024-7592:There is a LOW severity vulnerability affecting CPython, specifically the&#xA;&#39;http.cookies&#39; standard library module.&#xA;When parsing cookies that contained backslashes for quoted characters in&#xA;the cookie value, the parser would use an algorithm with quadratic&#xA;complexity, resulting in excess CPU resources being used while parsing the&#xA;value.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="python3" release="29.u12.fos23" version="3.9.9">
					<filename>python3-3.9.9-29.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-3.9.9-29.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="29.u12.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-29.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-unversioned-command-3.9.9-29.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="29.u12.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-29.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-devel-3.9.9-29.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="29.u12.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-29.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-debug-3.9.9-29.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="29.u12.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-29.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-help-3.9.9-29.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="29.u12.fos23" version="3.9.9">
					<filename>python3-3.9.9-29.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/python3-3.9.9-29.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="29.u12.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-29.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/python3-unversioned-command-3.9.9-29.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="29.u12.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-29.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/python3-devel-3.9.9-29.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="29.u12.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-29.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/python3-debug-3.9.9-29.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2298</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7409" id="CVE-2024-7409" title="CVE-2024-7409" type="cve"></reference>
		</references>
		<description>CVE-2024-7409:A flaw was found in the QEMU NBD Server. This vulnerability allows a denial of service (DoS) attack via improper synchronization during socket closure when a client keeps a socket open as the server is taken offline.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="10" name="qemu" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-guest-agent-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-97.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-help-6.2.0-97.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-img-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-block-rbd-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-block-ssh-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-block-iscsi-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-block-curl-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-hw-usb-host-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-seabios-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-system-aarch64-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-system-arm-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-system-x86_64-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-97.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/qemu-system-riscv-6.2.0-97.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-guest-agent-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-img-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-block-rbd-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-block-ssh-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-block-iscsi-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-block-curl-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-hw-usb-host-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-system-aarch64-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-system-arm-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-system-x86_64-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-97.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/qemu-system-riscv-6.2.0-97.u19.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2299</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32626" id="CVE-2021-32626" title="CVE-2021-32626" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32627" id="CVE-2021-32627" title="CVE-2021-32627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32628" id="CVE-2021-32628" title="CVE-2021-32628" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32762" id="CVE-2021-32762" title="CVE-2021-32762" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-41099" id="CVE-2021-41099" title="CVE-2021-41099" type="cve"></reference>
		</references>
		<description>CVE-2021-32626:Redis is an open source, in-memory database that persists on disk. In affected versions specially crafted Lua scripts executing in Redis can cause the heap-based Lua stack to be overflowed, due to incomplete checks for this condition. This can result with heap corruption and potentially remote code execution. This problem exists in all versions of Redis with Lua scripting support, starting from 2.6. The problem is fixed in versions 6.2.6, 6.0.16 and 5.0.14. For users unable to update an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.&#xA;CVE-2021-32627:Redis is an open source, in-memory database that persists on disk. In affected versions an integer overflow bug in Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves changing the default proto-max-bulk-len and client-query-buffer-limit configuration parameters to very large values and constructing specially crafted very large stream elements. The problem is fixed in Redis 6.2.6, 6.0.16 and 5.0.14. For users unable to upgrade an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.&#xA;CVE-2021-32628:Redis is an open source, in-memory database that persists on disk. An integer overflow bug in the ziplist data structure used by all versions of Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves modifying the default ziplist configuration parameters (hash-max-ziplist-entries, hash-max-ziplist-value, zset-max-ziplist-entries or zset-max-ziplist-value) to a very large value, and then constructing specially crafted commands to create very large ziplists. The problem is fixed in Redis versions 6.2.6, 6.0.16, 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the above configuration parameters. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.&#xA;CVE-2021-32762:Redis is an open source, in-memory database that persists on disk. The redis-cli command line tool and redis-sentinel service may be vulnerable to integer overflow when parsing specially crafted large multi-bulk network replies. This is a result of a vulnerability in the underlying hiredis library which does not perform an overflow check before calling the calloc() heap allocation function. This issue only impacts systems with heap allocators that do not perform their own overflow checks. Most modern systems do and are therefore not likely to be affected. Furthermore, by default redis-sentinel uses the jemalloc allocator which is also not vulnerable. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14.&#xA;CVE-2021-41099:Redis is an open source, in-memory database that persists on disk. An integer overflow bug in the underlying string library can be used to corrupt the heap and potentially result with denial of service or remote code execution. The vulnerability involves changing the default proto-max-bulk-len configuration parameter to a very large value and constructing specially crafted network payloads or commands. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/redis5-5.0.7-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/redis5-devel-5.0.7-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/redis5-doc-5.0.7-6.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/redis5-5.0.7-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/redis5-devel-5.0.7-6.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2300</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41946" id="CVE-2024-41946" title="CVE-2024-41946" type="cve"></reference>
		</references>
		<description>CVE-2024-41946:REXML is an XML toolkit for Ruby. The REXML gem 3.3.2 has a DoS vulnerability when it parses an XML that has many entity expansions with SAX2 or pull parser API. The REXML gem 3.3.3 or later include the patch to fix the vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="ruby" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-3.0.3-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/ruby-3.0.3-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/ruby-devel-3.0.3-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="137.u11.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygems-3.2.32-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="137.u11.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygems-devel-3.2.32-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="137.u11.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-rake-13.0.3-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="137.u11.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-rbs-1.4.0-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/ruby-irb-3.0.3-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="137.u11.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-rdoc-6.3.3-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/ruby-help-3.0.3-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="137.u11.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-bigdecimal-3.0.0-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="137.u11.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-did_you_mean-1.5.0-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="137.u11.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-io-console-0.5.7-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="137.u11.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-json-2.5.1-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="137.u11.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-minitest-5.14.2-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="137.u11.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-openssl-2.2.1-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="137.u11.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-137.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-psych-3.3.2-137.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="137.u11.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-test-unit-3.3.7-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="137.u11.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-rexml-3.2.5-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="137.u11.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-rss-0.2.9-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="137.u11.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-137.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/rubygem-typeprof-0.15.2-137.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-3.0.3-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/ruby-3.0.3-137.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/ruby-devel-3.0.3-137.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="137.u11.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/rubygem-bigdecimal-3.0.0-137.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="137.u11.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/rubygem-io-console-0.5.7-137.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="137.u11.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/rubygem-json-2.5.1-137.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="137.u11.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/rubygem-openssl-2.2.1-137.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="137.u11.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-137.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/rubygem-psych-3.3.2-137.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2301</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43167" id="CVE-2024-43167" title="CVE-2024-43167" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43168" id="CVE-2024-43168" title="CVE-2024-43168" type="cve"></reference>
		</references>
		<description>CVE-2024-43167:A NULL pointer dereference flaw was found in the ub_ctx_set_fwd function in Unbound. This issue could allow an attacker who can invoke specific sequences of API calls to cause a segmentation fault. When certain API functions such as ub_ctx_set_fwd and ub_ctx_resolvconf are called in a particular order, the program attempts to read from a NULL pointer, leading to a crash. This issue can result in a denial of service by causing the application to terminate unexpectedly.&#xA;CVE-2024-43168:A heap-buffer-overflow flaw was found in the cfg_mark_ports function within Unbound&#39;s config_file.c, which can lead to memory corruption. This issue could allow an attacker with local access to provide specially crafted input, potentially causing the application to crash or allowing arbitrary code execution. This could result in a denial of service or unauthorized actions on the system.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="unbound" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-1.13.2-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/unbound-1.13.2-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/unbound-libs-1.13.2-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/unbound-devel-1.13.2-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="12.u5.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/python3-unbound-1.13.2-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/unbound-help-1.13.2-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-1.13.2-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/unbound-1.13.2-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/unbound-libs-1.13.2-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/unbound-devel-1.13.2-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="12.u5.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/python3-unbound-1.13.2-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/unbound-help-1.13.2-12.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2302</id>
		<title>An update for wget is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-09-10"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38428" id="CVE-2024-38428" title="CVE-2024-38428" type="cve"></reference>
		</references>
		<description>CVE-2024-38428:url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.</description>
		<pkglist>
			<collection>
				<name>23.1.3</name>
				<package arch="x86_64" epoch="0" name="wget" release="5.u2.fos23" version="1.21.2">
					<filename>wget-1.21.2-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/wget-1.21.2-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="wget-help" release="5.u2.fos23" version="1.21.2">
					<filename>wget-help-1.21.2-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3/wget-help-1.21.2-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="wget" release="5.u2.fos23" version="1.21.2">
					<filename>wget-1.21.2-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/wget-1.21.2-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="wget-help" release="5.u2.fos23" version="1.21.2">
					<filename>wget-help-1.21.2-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3/wget-help-1.21.2-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2303</id>
		<title>An update for 389-ds-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1949" id="CVE-2022-1949" title="CVE-2022-1949" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5953" id="CVE-2024-5953" title="CVE-2024-5953" type="cve"></reference>
		</references>
		<description>CVE-2022-1949:An access control bypass vulnerability found in 389-ds-base. That mishandling of the filter that would yield incorrect results, but as that has progressed, can be determined that it actually is an access control bypass. This may allow any remote unauthenticated user to issue a filter that allows searching for database items they do not have access to, including but not limited to potentially userPassword hashes and other sensitive data.&#xA;CVE-2024-5953:A denial of service vulnerability was found in the 389-ds-base LDAP server. This issue may allow an authenticated user to cause a server denial of service while attempting to log in with a user with a malformed hash in their password.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="389-ds-base" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/389-ds-base-1.4.3.36-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-legacy-tools" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/389-ds-base-legacy-tools-1.4.3.36-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-devel" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/389-ds-base-devel-1.4.3.36-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-snmp" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/389-ds-base-snmp-1.4.3.36-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-lib389" release="7.u4.fos23" version="1.4.3.36">
					<filename>python3-lib389-1.4.3.36-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-lib389-1.4.3.36-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-389-ds" release="7.u4.fos23" version="1.4.3.36">
					<filename>cockpit-389-ds-1.4.3.36-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/cockpit-389-ds-1.4.3.36-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-help" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/389-ds-base-help-1.4.3.36-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/389-ds-base-1.4.3.36-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-legacy-tools" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/389-ds-base-legacy-tools-1.4.3.36-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-devel" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/389-ds-base-devel-1.4.3.36-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-snmp" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/389-ds-base-snmp-1.4.3.36-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-help" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/389-ds-base-help-1.4.3.36-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2304</id>
		<title>An update for OpenIPMI is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42934" id="CVE-2024-42934" title="CVE-2024-42934" type="cve"></reference>
		</references>
		<description>CVE-2024-42934:OpenIPMI before 2.0.36 has an out-of-bounds array access (for authentication type) in the ipmi_sim simulator, resulting in denial of service or (with very low probability) authentication bypass or code execution.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="OpenIPMI" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-2.0.32-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/OpenIPMI-2.0.32-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenIPMI-perl" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-perl-2.0.32-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/OpenIPMI-perl-2.0.32-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-openipmi" release="4.u2.fos23" version="2.0.32">
					<filename>python3-openipmi-2.0.32-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-openipmi-2.0.32-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenIPMI-devel" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-devel-2.0.32-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/OpenIPMI-devel-2.0.32-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="OpenIPMI-help" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-help-2.0.32-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/OpenIPMI-help-2.0.32-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenIPMI" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-2.0.32-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/OpenIPMI-2.0.32-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenIPMI-perl" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-perl-2.0.32-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/OpenIPMI-perl-2.0.32-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-openipmi" release="4.u2.fos23" version="2.0.32">
					<filename>python3-openipmi-2.0.32-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-openipmi-2.0.32-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenIPMI-devel" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-devel-2.0.32-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/OpenIPMI-devel-2.0.32-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2305</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45679" id="CVE-2024-45679" title="CVE-2024-45679" type="cve"></reference>
		</references>
		<description>CVE-2024-45679:Heap-based buffer overflow vulnerability in Assimp versions prior to 5.4.3 allows a local attacker to execute arbitrary code by importing a specially crafted file into the product.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="assimp" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-5.2.4-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/assimp-5.2.4-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/assimp-devel-5.2.4-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-assimp" release="3.u2.fos23" version="5.2.4">
					<filename>python3-assimp-5.2.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-assimp-5.2.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="assimp-help" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-help-5.2.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/assimp-help-5.2.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-5.2.4-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/assimp-5.2.4-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/assimp-devel-5.2.4-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2306</id>
		<title>An update for cups-filters is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47076" id="CVE-2024-47076" title="CVE-2024-47076" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47175" id="CVE-2024-47175" title="CVE-2024-47175" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47176" id="CVE-2024-47176" title="CVE-2024-47176" type="cve"></reference>
		</references>
		<description>CVE-2024-47076:CUPS is a standards-based, open-source printing system, and `libcupsfilters` contains the code of the filters of the former `cups-filters` package as library functions to be used for the data format conversion tasks needed in Printer Applications. The `cfGetPrinterAttributes5` function in `libcupsfilters` does not sanitize IPP attributes returned from an IPP server. When these IPP attributes are used, for instance, to generate a PPD file, this can lead to attacker controlled data to be provided to the rest of the CUPS system.&#xA;CVE-2024-47175:CUPS is a standards-based, open-source printing system, and `libppd` can be used for legacy PPD file support. The `libppd` function `ppdCreatePPDFromIPP2` does not sanitize IPP attributes when creating the PPD buffer. When used in combination with other functions such as `cfGetPrinterAttributes5`, can result in user controlled input and ultimately code execution via Foomatic. This vulnerability can be part of an exploit chain leading to remote code execution (RCE), as described in CVE-2024-47176.&#xA;CVE-2024-47176:CUPS is a standards-based, open-source printing system, and `cups-browsed` contains network printing functionality including, but not limited to, auto-discovering print services and shared printers. `cups-browsed` binds to `INADDR_ANY:631`, causing it to trust any packet from any source, and can cause the `Get-Printer-Attributes` IPP request to an attacker controlled URL. When combined with other vulnerabilities, such as CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177, an attacker can execute arbitrary commands remotely on the target machine without authentication when a malicious printer is printed to.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="cups-filters" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/cups-filters-1.28.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters-devel" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/cups-filters-devel-1.28.9-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cups-filters-help" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-help-1.28.9-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/cups-filters-help-1.28.9-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/cups-filters-1.28.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters-devel" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/cups-filters-devel-1.28.9-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2307</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8096" id="CVE-2024-8096" title="CVE-2024-8096" type="cve"></reference>
		</references>
		<description>CVE-2024-8096:When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine.  If the returned status reports another error than &#39;revoked&#39; (like for example &#39;unauthorized&#39;) it is not treated as a bad certficate.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="curl" release="32.u18.fos23" version="7.79.1">
					<filename>curl-7.79.1-32.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/curl-7.79.1-32.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-32.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libcurl-7.79.1-32.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-32.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libcurl-devel-7.79.1-32.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="32.u18.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-32.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/curl-help-7.79.1-32.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="32.u18.fos23" version="7.79.1">
					<filename>curl-7.79.1-32.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/curl-7.79.1-32.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-32.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libcurl-7.79.1-32.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-32.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libcurl-devel-7.79.1-32.u18.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2308</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3712" id="CVE-2021-3712" title="CVE-2021-3712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"></reference>
		</references>
		<description>CVE-2021-3712:ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL&#39;s own &#34;d2i&#34; functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the &#34;data&#34; and &#34;length&#34; fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the &#34;data&#34; field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).&#xA;CVE-2022-0778:The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="20.u9.fos23" version="202011">
					<filename>edk2-devel-202011-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/edk2-devel-202011-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="20.u9.fos23" version="202011">
					<filename>python3-edk2-devel-202011-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-edk2-devel-202011-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="20.u9.fos23" version="202011">
					<filename>edk2-help-202011-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/edk2-help-202011-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="20.u9.fos23" version="202011">
					<filename>edk2-ovmf-202011-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/edk2-ovmf-202011-20.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="20.u9.fos23" version="202011">
					<filename>edk2-devel-202011-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/edk2-devel-202011-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="20.u9.fos23" version="202011">
					<filename>edk2-aarch64-202011-20.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/edk2-aarch64-202011-20.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2309</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35965" id="CVE-2020-35965" title="CVE-2020-35965" type="cve"></reference>
		</references>
		<description>CVE-2020-35965:decode_frame in libavcodec/exr.c in FFmpeg 4.3.1 has an out-of-bounds write because of errors in calculations of when to perform memset zero operations.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-18.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ffmpeg-4.2.4-18.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-18.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ffmpeg-libs-4.2.4-18.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="18.u2.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-18.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libavdevice-4.2.4-18.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-18.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ffmpeg-devel-4.2.4-18.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-18.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ffmpeg-4.2.4-18.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-18.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ffmpeg-libs-4.2.4-18.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="18.u2.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-18.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libavdevice-4.2.4-18.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-18.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ffmpeg-devel-4.2.4-18.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2310</id>
		<title>An update for fop is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28168" id="CVE-2024-28168" title="CVE-2024-28168" type="cve"></reference>
		</references>
		<description>CVE-2024-28168:Improper Restriction of XML External Entity Reference (&#39;XXE&#39;) vulnerability in Apache XML Graphics FOP.&#xA;This issue affects Apache XML Graphics FOP: 2.9.&#xA;Users are recommended to upgrade to version 2.10, which fixes the issue.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="noarch" epoch="0" name="fop" release="9.u2.fos23" version="2.2">
					<filename>fop-2.2-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/fop-2.2-9.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2311</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33871" id="CVE-2024-33871" title="CVE-2024-33871" type="cve"></reference>
		</references>
		<description>CVE-2024-33871:An issue was discovered in Artifex Ghostscript before 10.03.1. contrib/opvp/gdevopvp.c allows arbitrary code execution via a custom Driver library, exploitable via a crafted PostScript document. This occurs because the Driver parameter for opvp (and oprp) devices can have an arbitrary name for a dynamic library; this library is then loaded.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ghostscript-9.55.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ghostscript-devel-9.55.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ghostscript-help-9.55.0-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ghostscript-tools-dvipdf-9.55.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ghostscript-9.55.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ghostscript-devel-9.55.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ghostscript-tools-dvipdf-9.55.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2312</id>
		<title>An update for gstreamer1-plugins-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4453" id="CVE-2024-4453" title="CVE-2024-4453" type="cve"></reference>
		</references>
		<description>CVE-2024-4453:GStreamer EXIF Metadata Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.&#xA;The specific flaw exists within the parsing of EXIF metadata. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.&#xA;. Was ZDI-CAN-23896.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/gstreamer1-plugins-base-1.18.4-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base-devel" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/gstreamer1-plugins-base-devel-1.18.4-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-base-help" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-help-1.18.4-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/gstreamer1-plugins-base-help-1.18.4-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/gstreamer1-plugins-base-1.18.4-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base-devel" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/gstreamer1-plugins-base-devel-1.18.4-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2313</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
		</references>
		<description>CVE-2024-21208:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-src-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-src-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2314</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
		</references>
		<description>CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-headless-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-headless-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-devel-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-devel-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-jmods-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-jmods-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-demo-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-demo-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-src-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-src-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-javadoc-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-11-openjdk-javadoc-zip-11.0.24.8-0.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-headless-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-headless-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-devel-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-devel-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-jmods-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-jmods-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-demo-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-demo-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-src-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-src-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-javadoc-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-11-openjdk-javadoc-zip-11.0.24.8-0.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2315</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
		</references>
		<description>CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-headless-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-headless-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-devel-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-devel-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-jmods-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-demo-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-demo-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-src-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-src-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-javadoc-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/java-17-openjdk-javadoc-zip-17.0.12.7-0.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-headless-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-headless-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-devel-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-devel-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-jmods-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-demo-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-demo-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-src-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-src-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-javadoc-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/java-17-openjdk-javadoc-zip-17.0.12.7-0.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2316</id>
		<title>An update for jbig2dec is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46361" id="CVE-2023-46361" title="CVE-2023-46361" type="cve"></reference>
		</references>
		<description>CVE-2023-46361:Artifex Software jbig2dec v0.20 was discovered to contain a SEGV vulnerability via jbig2_error at /jbig2dec/jbig2.c.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="jbig2dec" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-0.19-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/jbig2dec-0.19-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jbig2dec-devel" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-devel-0.19-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/jbig2dec-devel-0.19-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jbig2dec-help" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-help-0.19-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/jbig2dec-help-0.19-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jbig2dec" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-0.19-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/jbig2dec-0.19-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jbig2dec-devel" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-devel-0.19-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/jbig2dec-devel-0.19-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2317</id>
		<title>An update for json-lib is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47855" id="CVE-2024-47855" title="CVE-2024-47855" type="cve"></reference>
		</references>
		<description>CVE-2024-47855:util/JSONTokener.java in JSON-lib before 3.1.0 mishandles an unbalanced comment string.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="noarch" epoch="0" name="json-lib" release="23.u1.fos23" version="2.4">
					<filename>json-lib-2.4-23.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/json-lib-2.4-23.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jenkins-json-lib" release="23.u1.fos23" version="2.4">
					<filename>jenkins-json-lib-2.4-23.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/jenkins-json-lib-2.4-23.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="json-lib-help" release="23.u1.fos23" version="2.4">
					<filename>json-lib-help-2.4-23.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/json-lib-help-2.4-23.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2318</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52742" id="CVE-2023-52742" title="CVE-2023-52742" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38565" id="CVE-2024-38565" title="CVE-2024-38565" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39490" id="CVE-2024-39490" title="CVE-2024-39490" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41016" id="CVE-2024-41016" title="CVE-2024-41016" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42121" id="CVE-2024-42121" title="CVE-2024-42121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41098" id="CVE-2024-41098" title="CVE-2024-41098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52748" id="CVE-2023-52748" title="CVE-2023-52748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42309" id="CVE-2024-42309" title="CVE-2024-42309" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43828" id="CVE-2024-43828" title="CVE-2024-43828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41068" id="CVE-2024-41068" title="CVE-2024-41068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42122" id="CVE-2024-42122" title="CVE-2024-42122" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42322" id="CVE-2024-42322" title="CVE-2024-42322" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42290" id="CVE-2024-42290" title="CVE-2024-42290" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43824" id="CVE-2024-43824" title="CVE-2024-43824" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42313" id="CVE-2024-42313" title="CVE-2024-42313" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43831" id="CVE-2024-43831" title="CVE-2024-43831" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43860" id="CVE-2024-43860" title="CVE-2024-43860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43819" id="CVE-2024-43819" title="CVE-2024-43819" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42126" id="CVE-2024-42126" title="CVE-2024-42126" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43823" id="CVE-2024-43823" title="CVE-2024-43823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42281" id="CVE-2024-42281" title="CVE-2024-42281" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36946" id="CVE-2024-36946" title="CVE-2024-36946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38613" id="CVE-2024-38613" title="CVE-2024-38613" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40901" id="CVE-2024-40901" title="CVE-2024-40901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41008" id="CVE-2024-41008" title="CVE-2024-41008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52898" id="CVE-2023-52898" title="CVE-2023-52898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48899" id="CVE-2022-48899" title="CVE-2022-48899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43879" id="CVE-2024-43879" title="CVE-2024-43879" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48896" id="CVE-2022-48896" title="CVE-2022-48896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42297" id="CVE-2024-42297" title="CVE-2024-42297" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43866" id="CVE-2024-43866" title="CVE-2024-43866" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42280" id="CVE-2024-42280" title="CVE-2024-42280" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52901" id="CVE-2023-52901" title="CVE-2023-52901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52903" id="CVE-2023-52903" title="CVE-2023-52903" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43882" id="CVE-2024-43882" title="CVE-2024-43882" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43849" id="CVE-2024-43849" title="CVE-2024-43849" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42312" id="CVE-2024-42312" title="CVE-2024-42312" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48873" id="CVE-2022-48873" title="CVE-2022-48873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52893" id="CVE-2023-52893" title="CVE-2023-52893" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42120" id="CVE-2024-42120" title="CVE-2024-42120" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48935" id="CVE-2022-48935" title="CVE-2022-48935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42308" id="CVE-2024-42308" title="CVE-2024-42308" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42153" id="CVE-2024-42153" title="CVE-2024-42153" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48898" id="CVE-2022-48898" title="CVE-2022-48898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42230" id="CVE-2024-42230" title="CVE-2024-42230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42265" id="CVE-2024-42265" title="CVE-2024-42265" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52896" id="CVE-2023-52896" title="CVE-2023-52896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43883" id="CVE-2024-43883" title="CVE-2024-43883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48920" id="CVE-2022-48920" title="CVE-2022-48920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48871" id="CVE-2022-48871" title="CVE-2022-48871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48877" id="CVE-2022-48877" title="CVE-2022-48877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42267" id="CVE-2024-42267" title="CVE-2024-42267" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43890" id="CVE-2024-43890" title="CVE-2024-43890" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43854" id="CVE-2024-43854" title="CVE-2024-43854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42299" id="CVE-2024-42299" title="CVE-2024-42299" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52880" id="CVE-2023-52880" title="CVE-2023-52880" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48811" id="CVE-2022-48811" title="CVE-2022-48811" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42288" id="CVE-2024-42288" title="CVE-2024-42288" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43908" id="CVE-2024-43908" title="CVE-2024-43908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42286" id="CVE-2024-42286" title="CVE-2024-42286" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52889" id="CVE-2023-52889" title="CVE-2023-52889" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43884" id="CVE-2024-43884" title="CVE-2024-43884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43907" id="CVE-2024-43907" title="CVE-2024-43907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44938" id="CVE-2024-44938" title="CVE-2024-44938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43892" id="CVE-2024-43892" title="CVE-2024-43892" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44934" id="CVE-2024-44934" title="CVE-2024-44934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43893" id="CVE-2024-43893" title="CVE-2024-43893" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52906" id="CVE-2023-52906" title="CVE-2023-52906" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48872" id="CVE-2022-48872" title="CVE-2022-48872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43905" id="CVE-2024-43905" title="CVE-2024-43905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52899" id="CVE-2023-52899" title="CVE-2023-52899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43889" id="CVE-2024-43889" title="CVE-2024-43889" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41060" id="CVE-2024-41060" title="CVE-2024-41060" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41082" id="CVE-2024-41082" title="CVE-2024-41082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48879" id="CVE-2022-48879" title="CVE-2022-48879" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43856" id="CVE-2024-43856" title="CVE-2024-43856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44944" id="CVE-2024-44944" title="CVE-2024-44944" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43898" id="CVE-2024-43898" title="CVE-2024-43898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48891" id="CVE-2022-48891" title="CVE-2022-48891" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44946" id="CVE-2024-44946" title="CVE-2024-44946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44942" id="CVE-2024-44942" title="CVE-2024-44942" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42295" id="CVE-2024-42295" title="CVE-2024-42295" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43834" id="CVE-2024-43834" title="CVE-2024-43834" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42259" id="CVE-2024-42259" title="CVE-2024-42259" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45896" id="CVE-2023-45896" title="CVE-2023-45896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43902" id="CVE-2024-43902" title="CVE-2024-43902" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44947" id="CVE-2024-44947" title="CVE-2024-44947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48902" id="CVE-2022-48902" title="CVE-2022-48902" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48901" id="CVE-2022-48901" title="CVE-2022-48901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43914" id="CVE-2024-43914" title="CVE-2024-43914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52907" id="CVE-2023-52907" title="CVE-2023-52907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43899" id="CVE-2024-43899" title="CVE-2024-43899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42276" id="CVE-2024-42276" title="CVE-2024-42276" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42311" id="CVE-2024-42311" title="CVE-2024-42311" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44960" id="CVE-2024-44960" title="CVE-2024-44960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44971" id="CVE-2024-44971" title="CVE-2024-44971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52916" id="CVE-2023-52916" title="CVE-2023-52916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43829" id="CVE-2024-43829" title="CVE-2024-43829" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36934" id="CVE-2024-36934" title="CVE-2024-36934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48887" id="CVE-2022-48887" title="CVE-2022-48887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44948" id="CVE-2024-44948" title="CVE-2024-44948" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44988" id="CVE-2024-44988" title="CVE-2024-44988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44986" id="CVE-2024-44986" title="CVE-2024-44986" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44987" id="CVE-2024-44987" title="CVE-2024-44987" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52915" id="CVE-2023-52915" title="CVE-2023-52915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52894" id="CVE-2023-52894" title="CVE-2023-52894" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48828" id="CVE-2022-48828" title="CVE-2022-48828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52900" id="CVE-2023-52900" title="CVE-2023-52900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42104" id="CVE-2024-42104" title="CVE-2024-42104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41059" id="CVE-2024-41059" title="CVE-2024-41059" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42292" id="CVE-2024-42292" title="CVE-2024-42292" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41017" id="CVE-2024-41017" title="CVE-2024-41017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42119" id="CVE-2024-42119" title="CVE-2024-42119" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36915" id="CVE-2024-36915" title="CVE-2024-36915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44999" id="CVE-2024-44999" title="CVE-2024-44999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44974" id="CVE-2024-44974" title="CVE-2024-44974" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45003" id="CVE-2024-45003" title="CVE-2024-45003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46745" id="CVE-2024-46745" title="CVE-2024-46745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45028" id="CVE-2024-45028" title="CVE-2024-45028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46723" id="CVE-2024-46723" title="CVE-2024-46723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36270" id="CVE-2024-36270" title="CVE-2024-36270" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46747" id="CVE-2024-46747" title="CVE-2024-46747" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44995" id="CVE-2024-44995" title="CVE-2024-44995" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46714" id="CVE-2024-46714" title="CVE-2024-46714" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46731" id="CVE-2024-46731" title="CVE-2024-46731" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44965" id="CVE-2024-44965" title="CVE-2024-44965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46787" id="CVE-2024-46787" title="CVE-2024-46787" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46751" id="CVE-2024-46751" title="CVE-2024-46751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46752" id="CVE-2024-46752" title="CVE-2024-46752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46733" id="CVE-2024-46733" title="CVE-2024-46733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46744" id="CVE-2024-46744" title="CVE-2024-46744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48721" id="CVE-2022-48721" title="CVE-2022-48721" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37021" id="CVE-2024-37021" title="CVE-2024-37021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47622" id="CVE-2021-47622" title="CVE-2021-47622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36479" id="CVE-2024-36479" title="CVE-2024-36479" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40976" id="CVE-2024-40976" title="CVE-2024-40976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42105" id="CVE-2024-42105" title="CVE-2024-42105" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42148" id="CVE-2024-42148" title="CVE-2024-42148" type="cve"></reference>
		</references>
		<description>CVE-2023-52742:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: USB: Fix wrong-direction WARNING in plusb.c&#xA;The syzbot fuzzer detected a bug in the plusb network driver: A&#xA;zero-length control-OUT transfer was treated as a read instead of a&#xA;write.  In modern kernels this error provokes a WARNING:&#xA;usb 1-1: BOGUS control dir, pipe 80000280 doesn&#39;t match bRequestType c0&#xA;WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411&#xA;usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411&#xA;Modules linked in:&#xA;CPU: 1 PID: 4645 Comm: dhcpcd Not tainted&#xA;6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google&#xA;01/12/2023&#xA;RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58&#xA; usb_internal_control_msg drivers/usb/core/message.c:102 [inline]&#xA; usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153&#xA; __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010&#xA; usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068&#xA; pl_vendor_req drivers/net/usb/plusb.c:60 [inline]&#xA; pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]&#xA; pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85&#xA; usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889&#xA; __dev_open+0x297/0x4d0 net/core/dev.c:1417&#xA; __dev_change_flags+0x587/0x750 net/core/dev.c:8530&#xA; dev_change_flags+0x97/0x170 net/core/dev.c:8602&#xA; devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147&#xA; inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979&#xA; sock_do_ioctl+0xcc/0x230 net/socket.c:1169&#xA; sock_ioctl+0x1f8/0x680 net/socket.c:1286&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:870 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:856 [inline]&#xA; __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and&#xA;remove the USB_DIR_IN flag.&#xA;CVE-2024-38565:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ar5523: enable proper endpoint verification&#xA;Syzkaller reports [1] hitting a warning about an endpoint in use&#xA;not having an expected type to it.&#xA;Fix the issue by checking for the existence of all proper&#xA;endpoints with their according types intact.&#xA;Sadly, this patch has not been tested on real hardware.&#xA;[1] Syzkaller report:&#xA;------------[ cut here ]------------&#xA;usb 1-1: BOGUS urb xfer, pipe 3 != type 1&#xA;WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275&#xA; ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]&#xA; ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]&#xA; ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655&#xA; usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396&#xA; call_driver_probe drivers/base/dd.c:560 [inline]&#xA; really_probe+0x249/0xb90 drivers/base/dd.c:639&#xA; __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778&#xA; driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808&#xA; __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936&#xA; bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427&#xA; __device_attach+0x1e4/0x530 drivers/base/dd.c:1008&#xA; bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487&#xA; device_add+0xbd9/0x1e90 drivers/base/core.c:3517&#xA; usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170&#xA; usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238&#xA; usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293&#xA; call_driver_probe drivers/base/dd.c:560 [inline]&#xA; really_probe+0x249/0xb90 drivers/base/dd.c:639&#xA; __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778&#xA; driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808&#xA; __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936&#xA; bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427&#xA; __device_attach+0x1e4/0x530 drivers/base/dd.c:1008&#xA; bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487&#xA; device_add+0xbd9/0x1e90 drivers/base/core.c:3517&#xA; usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573&#xA; hub_port_connect drivers/usb/core/hub.c:5353 [inline]&#xA; hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]&#xA; port_event drivers/usb/core/hub.c:5653 [inline]&#xA; hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735&#xA; process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289&#xA; worker_thread+0x669/0x1090 kernel/workqueue.c:2436&#xA; kthread+0x2e8/0x3a0 kernel/kthread.c:376&#xA; ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306&#xA; &lt;/TASK&gt;&#xA;CVE-2024-39490:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: sr: fix missing sk_buff release in seg6_input_core&#xA;The seg6_input() function is responsible for adding the SRH into a&#xA;packet, delegating the operation to the seg6_input_core(). This function&#xA;uses the skb_cow_head() to ensure that there is sufficient headroom in&#xA;the sk_buff for accommodating the link-layer header.&#xA;In the event that the skb_cow_header() function fails, the&#xA;seg6_input_core() catches the error but it does not release the sk_buff,&#xA;which will result in a memory leak.&#xA;This issue was introduced in commit af3b5158b89d (&#34;ipv6: sr: fix BUG due&#xA;to headroom too small after SRH push&#34;) and persists even after commit&#xA;7a3f5b0de364 (&#34;netfilter: add netfilter hooks to SRv6 data plane&#34;),&#xA;where the entire seg6_input() code was refactored to deal with netfilter&#xA;hooks.&#xA;The proposed patch addresses the identified memory leak by requiring the&#xA;seg6_input_core() function to release the sk_buff in the event that&#xA;skb_cow_head() fails.&#xA;CVE-2024-41016:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()&#xA;xattr in ocfs2 maybe &#39;non-indexed&#39;, which saved with additional space&#xA;requested.  It&#39;s better to check if the memory is out of bound before&#xA;memcmp, although this possibility mainly comes from crafted poisonous&#xA;images.&#xA;CVE-2024-42121:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check index msg_id before read or write&#xA;[WHAT]&#xA;msg_id is used as an array index and it cannot be a negative value, and&#xA;therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).&#xA;[HOW]&#xA;Check whether msg_id is valid before reading and setting.&#xA;This fixes 4 OVERRUN issues reported by Coverity.&#xA;CVE-2024-41098:In the Linux kernel, the following vulnerability has been resolved:&#xA;ata: libata-core: Fix null pointer dereference on error&#xA;If the ata_port_alloc() call in ata_host_alloc() fails,&#xA;ata_host_release() will get called.&#xA;However, the code in ata_host_release() tries to free ata_port struct&#xA;members unconditionally, which can lead to the following:&#xA;BUG: unable to handle page fault for address: 0000000000003990&#xA;PGD 0 P4D 0&#xA;Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014&#xA;RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]&#xA;Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41&#xA;RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246&#xA;RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0&#xA;RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68&#xA;R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004&#xA;R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006&#xA;FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body.cold+0x19/0x27&#xA; ? page_fault_oops+0x15a/0x2f0&#xA; ? exc_page_fault+0x7e/0x180&#xA; ? asm_exc_page_fault+0x26/0x30&#xA; ? ata_host_release.cold+0x2f/0x6e [libata]&#xA; ? ata_host_release.cold+0x2f/0x6e [libata]&#xA; release_nodes+0x35/0xb0&#xA; devres_release_group+0x113/0x140&#xA; ata_host_alloc+0xed/0x120 [libata]&#xA; ata_host_alloc_pinfo+0x14/0xa0 [libata]&#xA; ahci_init_one+0x6c9/0xd20 [ahci]&#xA;Do not access ata_port struct members unconditionally.&#xA;CVE-2023-52748:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: avoid format-overflow warning&#xA;With gcc and W=1 option, there&#39;s a warning like this:&#xA;fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’:&#xA;fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between&#xA;1 and 7 bytes into a region of size between 5 and 8&#xA;[-Werror=format-overflow=]&#xA; 1984 |  sprintf(slab_name, &#34;f2fs_page_array_entry-%u:%u&#34;, MAJOR(dev),&#xA;&#x9;&#x9;MINOR(dev));&#xA;      |                                               ^~&#xA;String &#34;f2fs_page_array_entry-%u:%u&#34; can up to 35. The first &#34;%u&#34; can up&#xA;to 4 and the second &#34;%u&#34; can up to 7, so total size is &#34;24 + 4 + 7 = 35&#34;.&#xA;slab_name&#39;s size should be 35 rather than 32.&#xA;CVE-2024-42309:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes&#xA;In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is&#xA;assigned to mode, which will lead to a possible NULL pointer dereference&#xA;on failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2024-43828:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix infinite loop when replaying fast_commit&#xA;When doing fast_commit replay an infinite loop may occur due to an&#xA;uninitialized extent_status struct.  ext4_ext_determine_insert_hole() does&#xA;not detect the replay and calls ext4_es_find_extent_range(), which will&#xA;return immediately without initializing the &#39;es&#39; variable.&#xA;Because &#39;es&#39; contains garbage, an integer overflow may happen causing an&#xA;infinite loop in this function, easily reproducible using fstest generic/039.&#xA;This commit fixes this issue by unconditionally initializing the structure&#xA;in function ext4_es_find_extent_range().&#xA;Thanks to Zhang Yi, for figuring out the real problem!&#xA;CVE-2024-41068:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/sclp: Fix sclp_init() cleanup on failure&#xA;If sclp_init() fails it only partially cleans up: if there are multiple&#xA;failing calls to sclp_init() sclp_state_change_event will be added several&#xA;times to sclp_reg_list, which results in the following warning:&#xA;------------[ cut here ]------------&#xA;list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.&#xA;WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8&#xA;CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3&#xA;Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)&#xA;           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3&#xA;...&#xA;Call Trace:&#xA; [&lt;000003ffe0d6076a&gt;] __list_add_valid_or_report+0xe2/0xf8&#xA;([&lt;000003ffe0d60766&gt;] __list_add_valid_or_report+0xde/0xf8)&#xA; [&lt;000003ffe0a8d37e&gt;] sclp_init+0x40e/0x450&#xA; [&lt;000003ffe00009f2&gt;] do_one_initcall+0x42/0x1e0&#xA; [&lt;000003ffe15b77a6&gt;] do_initcalls+0x126/0x150&#xA; [&lt;000003ffe15b7a0a&gt;] kernel_init_freeable+0x1ba/0x1f8&#xA; [&lt;000003ffe0d6650e&gt;] kernel_init+0x2e/0x180&#xA; [&lt;000003ffe000301c&gt;] __ret_from_fork+0x3c/0x60&#xA; [&lt;000003ffe0d759ca&gt;] ret_from_fork+0xa/0x30&#xA;Fix this by removing sclp_state_change_event from sclp_reg_list when&#xA;sclp_init() fails.&#xA;CVE-2024-42122:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add NULL pointer check for kzalloc&#xA;[Why &amp; How]&#xA;Check return pointer of kzalloc before using it.&#xA;CVE-2024-42322:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipvs: properly dereference pe in ip_vs_add_service&#xA;Use pe directly to resolve sparse warning:&#xA;  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression&#xA;CVE-2024-42290:In the Linux kernel, the following vulnerability has been resolved:&#xA;irqchip/imx-irqsteer: Handle runtime power management correctly&#xA;The power domain is automatically activated from clk_prepare(). However, on&#xA;certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes&#xA;sleeping functions, which triggers the &#39;scheduling while atomic&#39; bug in the&#xA;context switch path during device probing:&#xA; BUG: scheduling while atomic: kworker/u13:1/48/0x00000002&#xA; Call trace:&#xA;  __schedule_bug+0x54/0x6c&#xA;  __schedule+0x7f0/0xa94&#xA;  schedule+0x5c/0xc4&#xA;  schedule_preempt_disabled+0x24/0x40&#xA;  __mutex_lock.constprop.0+0x2c0/0x540&#xA;  __mutex_lock_slowpath+0x14/0x20&#xA;  mutex_lock+0x48/0x54&#xA;  clk_prepare_lock+0x44/0xa0&#xA;  clk_prepare+0x20/0x44&#xA;  imx_irqsteer_resume+0x28/0xe0&#xA;  pm_generic_runtime_resume+0x2c/0x44&#xA;  __genpd_runtime_resume+0x30/0x80&#xA;  genpd_runtime_resume+0xc8/0x2c0&#xA;  __rpm_callback+0x48/0x1d8&#xA;  rpm_callback+0x6c/0x78&#xA;  rpm_resume+0x490/0x6b4&#xA;  __pm_runtime_resume+0x50/0x94&#xA;  irq_chip_pm_get+0x2c/0xa0&#xA;  __irq_do_set_handler+0x178/0x24c&#xA;  irq_set_chained_handler_and_data+0x60/0xa4&#xA;  mxc_gpio_probe+0x160/0x4b0&#xA;Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip&#xA;callbacks and handle power management in them as they are invoked from&#xA;non-atomic context.&#xA;[ tglx: Rewrote change log, added Fixes tag ]&#xA;CVE-2024-43824:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: endpoint: pci-epf-test: Make use of cached &#39;epc_features&#39; in pci_epf_test_core_init()&#xA;Instead of getting the epc_features from pci_epc_get_features() API, use&#xA;the cached pci_epf_test::epc_features value to avoid the NULL check. Since&#xA;the NULL check is already performed in pci_epf_test_bind(), having one more&#xA;check in pci_epf_test_core_init() is redundant and it is not possible to&#xA;hit the NULL pointer dereference.&#xA;Also with commit a01e7214bef9 (&#34;PCI: endpoint: Remove &#34;core_init_notifier&#34;&#xA;flag&#34;), &#39;epc_features&#39; got dereferenced without the NULL check, leading to&#xA;the following false positive Smatch warning:&#xA;  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed &#39;epc_features&#39; could be null (see line 747)&#xA;Thus, remove the redundant NULL check and also use the epc_features::&#xA;{msix_capable/msi_capable} flags directly to avoid local variables.&#xA;[kwilczynski: commit log]&#xA;CVE-2024-42313:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: venus: fix use after free in vdec_close&#xA;There appears to be a possible use after free with vdec_close().&#xA;The firmware will add buffer release work to the work queue through&#xA;HFI callbacks as a normal part of decoding. Randomly closing the&#xA;decoder device from userspace during normal decoding can incur&#xA;a read after free for inst.&#xA;Fix it by cancelling the work in vdec_close.&#xA;CVE-2024-43831:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: mediatek: vcodec: Handle invalid decoder vsi&#xA;Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi&#xA;is valid for future use.&#xA;CVE-2024-43860:In the Linux kernel, the following vulnerability has been resolved:&#xA;remoteproc: imx_rproc: Skip over memory region when node value is NULL&#xA;In imx_rproc_addr_init() &#34;nph = of_count_phandle_with_args()&#34; just counts&#xA;number of phandles. But phandles may be empty. So of_parse_phandle() in&#xA;the parsing loop (0 &lt; a &lt; nph) may return NULL which is later dereferenced.&#xA;Adjust this issue by adding NULL-return check.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;[Fixed title to fit within the prescribed 70-75 charcters]&#xA;CVE-2024-43819:In the Linux kernel, the following vulnerability has been resolved:&#xA;kvm: s390: Reject memory region operations for ucontrol VMs&#xA;This change rejects the KVM_SET_USER_MEMORY_REGION and&#xA;KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.&#xA;This is necessary since ucontrol VMs have kvm-&gt;arch.gmap set to 0 and&#xA;would thus result in a null pointer dereference further in.&#xA;Memory management needs to be performed in userspace and using the&#xA;ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.&#xA;Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION&#xA;and KVM_SET_USER_MEMORY_REGION2.&#xA;[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]&#xA;CVE-2024-42126:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.&#xA;nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel&#xA;crash when invoked during real mode interrupt handling (e.g. early HMI/MCE&#xA;interrupt handler) if percpu allocation comes from vmalloc area.&#xA;Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()&#xA;wrapper which invokes nmi_enter/nmi_exit calls. We don&#39;t see any issue when&#xA;percpu allocation is from the embedded first chunk. However with&#xA;CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu&#xA;allocation can come from the vmalloc area.&#xA;With kernel command line &#34;percpu_alloc=page&#34; we can force percpu allocation&#xA;to come from vmalloc area and can see kernel crash in machine_check_early:&#xA;[    1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110&#xA;[    1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0&#xA;[    1.215719] --- interrupt: 200&#xA;[    1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)&#xA;[    1.215722] [c000000fffd731b0] [0000000000000000] 0x0&#xA;[    1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8&#xA;Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu&#xA;first chunk is not embedded.&#xA;CVE-2024-43823:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()&#xA;If IORESOURCE_MEM is not provided in Device Tree due to&#xA;any error, resource_list_first_type() will return NULL and&#xA;pci_parse_request_of_pci_ranges() will just emit a warning.&#xA;This will cause a NULL pointer dereference. Fix this bug by adding NULL&#xA;return check.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-42281:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix a segment issue when downgrading gso_size&#xA;Linearize the skb when downgrading gso_size because it may trigger a&#xA;BUG_ON() later when the skb is segmented as described in [1,2].&#xA;CVE-2024-36946:In the Linux kernel, the following vulnerability has been resolved:&#xA;phonet: fix rtm_phonet_notify() skb allocation&#xA;fill_route() stores three components in the skb:&#xA;- struct rtmsg&#xA;- RTA_DST (u8)&#xA;- RTA_OIF (u32)&#xA;Therefore, rtm_phonet_notify() should use&#xA;NLMSG_ALIGN(sizeof(struct rtmsg)) +&#xA;nla_total_size(1) +&#xA;nla_total_size(4)&#xA;CVE-2024-38613:In the Linux kernel, the following vulnerability has been resolved:&#xA;m68k: Fix spinlock race in kernel thread creation&#xA;Context switching does take care to retain the correct lock owner across&#xA;the switch from &#39;prev&#39; to &#39;next&#39; tasks.  This does rely on interrupts&#xA;remaining disabled for the entire duration of the switch.&#xA;This condition is guaranteed for normal process creation and context&#xA;switching between already running processes, because both &#39;prev&#39; and&#xA;&#39;next&#39; already have interrupts disabled in their saved copies of the&#xA;status register.&#xA;The situation is different for newly created kernel threads.  The status&#xA;register is set to PS_S in copy_thread(), which does leave the IPL at 0.&#xA;Upon restoring the &#39;next&#39; thread&#39;s status register in switch_to() aka&#xA;resume(), interrupts then become enabled prematurely.  resume() then&#xA;returns via ret_from_kernel_thread() and schedule_tail() where run queue&#xA;lock is released (see finish_task_switch() and finish_lock_switch()).&#xA;A timer interrupt calling scheduler_tick() before the lock is released&#xA;in finish_task_switch() will find the lock already taken, with the&#xA;current task as lock owner.  This causes a spinlock recursion warning as&#xA;reported by Guenter Roeck.&#xA;As far as I can ascertain, this race has been opened in commit&#xA;533e6903bea0 (&#34;m68k: split ret_from_fork(), simplify kernel_thread()&#34;)&#xA;but I haven&#39;t done a detailed study of kernel history so it may well&#xA;predate that commit.&#xA;Interrupts cannot be disabled in the saved status register copy for&#xA;kernel threads (init will complain about interrupts disabled when&#xA;finally starting user space).  Disable interrupts temporarily when&#xA;switching the tasks&#39; register sets in resume().&#xA;Note that a simple oriw 0x700,%sr after restoring sr is not enough here&#xA;- this leaves enough of a race for the &#39;spinlock recursion&#39; warning to&#xA;still be observed.&#xA;Tested on ARAnyM and qemu (Quadra 800 emulation).&#xA;CVE-2024-40901:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory&#xA;There is a potential out-of-bounds access when using test_bit() on a single&#xA;word. The test_bit() and set_bit() functions operate on long values, and&#xA;when testing or setting a single word, they can exceed the word&#xA;boundary. KASAN detects this issue and produces a dump:&#xA;&#x9; BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas&#xA;&#x9; Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965&#xA;For full log, please look at [1].&#xA;Make the allocation at least the size of sizeof(unsigned long) so that&#xA;set_bit() and test_bit() have sufficient room for read/write operations&#xA;without overwriting unallocated memory.&#xA;[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/&#xA;CVE-2024-41008:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: change vm-&gt;task_info handling&#xA;This patch changes the handling and lifecycle of vm-&gt;task_info object.&#xA;The major changes are:&#xA;- vm-&gt;task_info is a dynamically allocated ptr now, and its uasge is&#xA;  reference counted.&#xA;- introducing two new helper funcs for task_info lifecycle management&#xA;    - amdgpu_vm_get_task_info: reference counts up task_info before&#xA;      returning this info&#xA;    - amdgpu_vm_put_task_info: reference counts down task_info&#xA;- last put to task_info() frees task_info from the vm.&#xA;This patch also does logistical changes required for existing usage&#xA;of vm-&gt;task_info.&#xA;V2: Do not block all the prints when task_info not found (Felix)&#xA;V3: Fixed review comments from Felix&#xA;   - Fix wrong indentation&#xA;   - No debug message for -ENOMEM&#xA;   - Add NULL check for task_info&#xA;   - Do not duplicate the debug messages (ti vs no ti)&#xA;   - Get first reference of task_info in vm_init(), put last&#xA;     in vm_fini()&#xA;V4: Fixed review comments from Felix&#xA;   - fix double reference increment in create_task_info&#xA;   - change amdgpu_vm_get_task_info_pasid&#xA;   - additional changes in amdgpu_gem.c while porting&#xA;CVE-2023-52898:In the Linux kernel, the following vulnerability has been resolved:&#xA;xhci: Fix null pointer dereference when host dies&#xA;Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race&#xA;and cause null pointer dereference when host suddenly dies.&#xA;Usb core may call xhci_free_dev() which frees the xhci-&gt;devs[slot_id]&#xA;virt device at the same time that xhci_kill_endpoint_urbs() tries to&#xA;loop through all the device&#39;s endpoints, checking if there are any&#xA;cancelled urbs left to give back.&#xA;hold the xhci spinlock while freeing the virt device&#xA;CVE-2022-48899:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/virtio: Fix GEM handle creation UAF&#xA;Userspace can guess the handle value and try to race GEM object creation&#xA;with handle close, resulting in a use-after-free if we dereference the&#xA;object after dropping the handle&#39;s reference.  For that reason, dropping&#xA;the handle&#39;s reference must be done *after* we are done dereferencing&#xA;the object.&#xA;CVE-2024-43879:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()&#xA;Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in&#xA;cfg80211_calculate_bitrate_he(), leading to below warning:&#xA;kernel: invalid HE MCS: bw:6, ru:6&#xA;kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]&#xA;Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.&#xA;CVE-2022-48896:In the Linux kernel, the following vulnerability has been resolved:&#xA;ixgbe: fix pci device refcount leak&#xA;As the comment of pci_get_domain_bus_and_slot() says, it&#xA;returns a PCI device with refcount incremented, when finish&#xA;using it, the caller must decrement the reference count by&#xA;calling pci_dev_put().&#xA;In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),&#xA;pci_dev_put() is called to avoid leak.&#xA;CVE-2024-42297:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to don&#39;t dirty inode for readonly filesystem&#xA;syzbot reports f2fs bug as below:&#xA;kernel BUG at fs/f2fs/inode.c:933!&#xA;RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933&#xA;Call Trace:&#xA; evict+0x2a4/0x620 fs/inode.c:664&#xA; dispose_list fs/inode.c:697 [inline]&#xA; evict_inodes+0x5f8/0x690 fs/inode.c:747&#xA; generic_shutdown_super+0x9d/0x2c0 fs/super.c:675&#xA; kill_block_super+0x44/0x90 fs/super.c:1667&#xA; kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894&#xA; deactivate_locked_super+0xc1/0x130 fs/super.c:484&#xA; cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256&#xA; task_work_run+0x24a/0x300 kernel/task_work.c:180&#xA; ptrace_notify+0x2cd/0x380 kernel/signal.c:2399&#xA; ptrace_report_syscall include/linux/ptrace.h:411 [inline]&#xA; ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]&#xA; syscall_exit_work kernel/entry/common.c:251 [inline]&#xA; syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]&#xA; __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]&#xA; syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296&#xA; do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;The root cause is:&#xA;- do_sys_open&#xA; - f2fs_lookup&#xA;  - __f2fs_find_entry&#xA;   - f2fs_i_depth_write&#xA;    - f2fs_mark_inode_dirty_sync&#xA;     - f2fs_dirty_inode&#xA;      - set_inode_flag(inode, FI_DIRTY_INODE)&#xA;- umount&#xA; - kill_f2fs_super&#xA;  - kill_block_super&#xA;   - generic_shutdown_super&#xA;    - sync_filesystem&#xA;    : sb is readonly, skip sync_filesystem()&#xA;    - evict_inodes&#xA;     - iput&#xA;      - f2fs_evict_inode&#xA;       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))&#xA;       : trigger kernel panic&#xA;When we try to repair i_current_depth in readonly filesystem, let&#39;s&#xA;skip dirty inode to avoid panic in later f2fs_evict_inode().&#xA;CVE-2024-43866:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Always drain health in shutdown callback&#xA;There is no point in recovery during device shutdown. if health&#xA;work started need to wait for it to avoid races and NULL pointer&#xA;access.&#xA;Hence, drain health WQ on shutdown callback.&#xA;CVE-2024-42280:In the Linux kernel, the following vulnerability has been resolved:&#xA;mISDN: Fix a use after free in hfcmulti_tx()&#xA;Don&#39;t dereference *sp after calling dev_kfree_skb(*sp).&#xA;CVE-2023-52901:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: xhci: Check endpoint is valid before dereferencing it&#xA;When the host controller is not responding, all URBs queued to all&#xA;endpoints need to be killed. This can cause a kernel panic if we&#xA;dereference an invalid endpoint.&#xA;Fix this by using xhci_get_virt_ep() helper to find the endpoint and&#xA;checking if the endpoint is valid before dereferencing it.&#xA;[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead&#xA;[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8&#xA;[233311.853964] pc : xhci_hc_died+0x10c/0x270&#xA;[233311.853971] lr : xhci_hc_died+0x1ac/0x270&#xA;[233311.854077] Call trace:&#xA;[233311.854085]  xhci_hc_died+0x10c/0x270&#xA;[233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4&#xA;[233311.854105]  call_timer_fn+0x50/0x2d4&#xA;[233311.854112]  expire_timers+0xac/0x2e4&#xA;[233311.854118]  run_timer_softirq+0x300/0xabc&#xA;[233311.854127]  __do_softirq+0x148/0x528&#xA;[233311.854135]  irq_exit+0x194/0x1a8&#xA;[233311.854143]  __handle_domain_irq+0x164/0x1d0&#xA;[233311.854149]  gic_handle_irq.22273+0x10c/0x188&#xA;[233311.854156]  el1_irq+0xfc/0x1a8&#xA;[233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]&#xA;[233311.854185]  cpuidle_enter_state+0x1f0/0x764&#xA;[233311.854194]  do_idle+0x594/0x6ac&#xA;[233311.854201]  cpu_startup_entry+0x7c/0x80&#xA;[233311.854209]  secondary_start_kernel+0x170/0x198&#xA;CVE-2023-52903:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring: lock overflowing for IOPOLL&#xA;syzbot reports an issue with overflow filling for IOPOLL:&#xA;WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734&#xA;CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0&#xA;Workqueue: events_unbound io_ring_exit_work&#xA;Call trace:&#xA; io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734&#xA; io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773&#xA; io_fill_cqe_req io_uring/io_uring.h:168 [inline]&#xA; io_do_iopoll+0x474/0x62c io_uring/rw.c:1065&#xA; io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513&#xA; io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056&#xA; io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869&#xA; process_one_work+0x2d8/0x504 kernel/workqueue.c:2289&#xA; worker_thread+0x340/0x610 kernel/workqueue.c:2436&#xA; kthread+0x12c/0x158 kernel/kthread.c:376&#xA; ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863&#xA;There is no real problem for normal IOPOLL as flush is also called with&#xA;uring_lock taken, but it&#39;s getting more complicated for IOPOLL|SQPOLL,&#xA;for which __io_cqring_overflow_flush() happens from the CQ waiting path.&#xA;CVE-2024-43882:In the Linux kernel, the following vulnerability has been resolved:&#xA;exec: Fix ToCToU between perm check and set-uid/gid usage&#xA;When opening a file for exec via do_filp_open(), permission checking is&#xA;done against the file&#39;s metadata at that moment, and on success, a file&#xA;pointer is passed back. Much later in the execve() code path, the file&#xA;metadata (specifically mode, uid, and gid) is used to determine if/how&#xA;to set the uid and gid. However, those values may have changed since the&#xA;permissions check, meaning the execution may gain unintended privileges.&#xA;For example, if a file could change permissions from executable and not&#xA;set-id:&#xA;---------x 1 root root 16048 Aug  7 13:16 target&#xA;to set-id and non-executable:&#xA;---S------ 1 root root 16048 Aug  7 13:16 target&#xA;it is possible to gain root privileges when execution should have been&#xA;disallowed.&#xA;While this race condition is rare in real-world scenarios, it has been&#xA;observed (and proven exploitable) when package managers are updating&#xA;the setuid bits of installed programs. Such files start with being&#xA;world-executable but then are adjusted to be group-exec with a set-uid&#xA;bit. For example, &#34;chmod o-x,u+s target&#34; makes &#34;target&#34; executable only&#xA;by uid &#34;root&#34; and gid &#34;cdrom&#34;, while also becoming setuid-root:&#xA;-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target&#xA;becomes:&#xA;-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target&#xA;But racing the chmod means users without group &#34;cdrom&#34; membership can&#xA;get the permission to execute &#34;target&#34; just before the chmod, and when&#xA;the chmod finishes, the exec reaches brpm_fill_uid(), and performs the&#xA;setuid to root, violating the expressed authorization of &#34;only cdrom&#xA;group members can setuid to root&#34;.&#xA;Re-check that we still have execute permissions in case the metadata&#xA;has changed. It would be better to keep a copy from the perm-check time,&#xA;but until we can do that refactoring, the least-bad option is to do a&#xA;full inode_permission() call (under inode lock). It is understood that&#xA;this is safe against dead-locks, but hardly optimal.&#xA;CVE-2024-43849:In the Linux kernel, the following vulnerability has been resolved:&#xA;soc: qcom: pdr: protect locator_addr with the main mutex&#xA;If the service locator server is restarted fast enough, the PDR can&#xA;rewrite locator_addr fields concurrently. Protect them by placing&#xA;modification of those fields under the main pdr-&gt;lock.&#xA;CVE-2024-42312:In the Linux kernel, the following vulnerability has been resolved:&#xA;sysctl: always initialize i_uid/i_gid&#xA;Always initialize i_uid/i_gid inside the sysfs core so set_ownership()&#xA;can safely skip setting them.&#xA;Commit 5ec27ec735ba (&#34;fs/proc/proc_sysctl.c: fix the default values of&#xA;i_uid/i_gid on /proc/sys inodes.&#34;) added defaults for i_uid/i_gid when&#xA;set_ownership() was not implemented. It also missed adjusting&#xA;net_ctl_set_ownership() to use the same default values in case the&#xA;computation of a better value failed.&#xA;CVE-2022-48873:In the Linux kernel, the following vulnerability has been resolved:&#xA;misc: fastrpc: Don&#39;t remove map on creater_process and device_release&#xA;Do not remove the map from the list on error path in&#xA;fastrpc_init_create_process, instead call fastrpc_map_put, to avoid&#xA;use-after-free. Do not remove it on fastrpc_device_release either,&#xA;call fastrpc_map_put instead.&#xA;The fastrpc_free_map is the only proper place to remove the map.&#xA;This is called only after the reference count is 0.&#xA;CVE-2023-52893:In the Linux kernel, the following vulnerability has been resolved:&#xA;gsmi: fix null-deref in gsmi_get_variable&#xA;We can get EFI variables without fetching the attribute, so we must&#xA;allow for that in gsmi.&#xA;commit 859748255b43 (&#34;efi: pstore: Omit efivars caching EFI varstore&#xA;access layer&#34;) added a new get_variable call with attr=NULL, which&#xA;triggers panic in gsmi.&#xA;CVE-2024-42120:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check pipe offset before setting vblank&#xA;pipe_ctx has a size of MAX_PIPES so checking its index before accessing&#xA;the array.&#xA;This fixes an OVERRUN issue reported by Coverity.&#xA;CVE-2022-48935:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: unregister flowtable hooks on netns exit&#xA;Unregister flowtable hooks before they are releases via&#xA;nf_tables_flowtable_destroy() otherwise hook core reports UAF.&#xA;BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142&#xA;Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666&#xA;CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106&#xA; dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106&#xA; print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247&#xA; __kasan_report mm/kasan/report.c:433 [inline]&#xA; __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450&#xA; kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450&#xA; nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142&#xA; __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429&#xA; nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571&#xA; nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232&#xA; nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430&#xA; nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline]&#xA; nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]&#xA; nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652&#xA; nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652&#xA; nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652&#xA;__nft_release_hook() calls nft_unregister_flowtable_net_hooks() which&#xA;only unregisters the hooks, then after RCU grace period, it is&#xA;guaranteed that no packets add new entries to the flowtable (no flow&#xA;offload rules and flowtable hooks are reachable from packet path), so it&#xA;is safe to call nf_flow_table_free() which cleans up the remaining&#xA;entries from the flowtable (both software and hardware) and it unbinds&#xA;the flow_block.&#xA;CVE-2024-42308:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-42153:In the Linux kernel, the following vulnerability has been resolved:&#xA;i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr&#xA;When del_timer_sync() is called in an interrupt context it throws a warning&#xA;because of potential deadlock. The timer is used only to exit from&#xA;wait_for_completion() after a timeout so replacing the call with&#xA;wait_for_completion_timeout() allows to remove the problematic timer and&#xA;its related functions altogether.&#xA;CVE-2022-48898:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer&#xA;There are 3 possible interrupt sources are handled by DP controller,&#xA;HPDstatus, Controller state changes and Aux read/write transaction.&#xA;At every irq, DP controller have to check isr status of every interrupt&#xA;sources and service the interrupt if its isr status bits shows interrupts&#xA;are pending. There is potential race condition may happen at current aux&#xA;isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()&#xA;even irq is not for aux read or write transaction. This may cause aux read&#xA;transaction return premature if host aux data read is in the middle of&#xA;waiting for sink to complete transferring data to host while irq happen.&#xA;This will cause host&#39;s receiving buffer contains unexpected data. This&#xA;patch fixes this problem by checking aux isr and return immediately at&#xA;aux isr handler if there are no any isr status bits set.&#xA;Current there is a bug report regrading eDP edid corruption happen during&#xA;system booting up. After lengthy debugging to found that VIDEO_READY&#xA;interrupt was continuously firing during system booting up which cause&#xA;dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data&#xA;from aux hardware buffer which is not yet contains complete data transfer&#xA;from sink. This cause edid corruption.&#xA;Follows are the signature at kernel logs when problem happen,&#xA;EDID has corrupt header&#xA;panel-simple-dp-aux aux-aea0000.edp: Couldn&#39;t identify panel via EDID&#xA;Changes in v2:&#xA;-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()&#xA;-- add more commit text&#xA;Changes in v3:&#xA;-- add Stephen suggested&#xA;-- dp_aux_isr() return IRQ_XXX back to caller&#xA;-- dp_ctrl_isr() return IRQ_XXX back to caller&#xA;Changes in v4:&#xA;-- split into two patches&#xA;Changes in v5:&#xA;-- delete empty line between tags&#xA;Changes in v6:&#xA;-- remove extra &#34;that&#34; and fixed line more than 75 char at commit text&#xA;Patchwork: https://patchwork.freedesktop.org/patch/516121/&#xA;CVE-2024-42230:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/pseries: Fix scv instruction crash with kexec&#xA;kexec on pseries disables AIL (reloc_on_exc), required for scv&#xA;instruction support, before other CPUs have been shut down. This means&#xA;they can execute scv instructions after AIL is disabled, which causes an&#xA;interrupt at an unexpected entry location that crashes the kernel.&#xA;Change the kexec sequence to disable AIL after other CPUs have been&#xA;brought down.&#xA;As a refresher, the real-mode scv interrupt vector is 0x17000, and the&#xA;fixed-location head code probably couldn&#39;t easily deal with implementing&#xA;such high addresses so it was just decided not to support that interrupt&#xA;at all.&#xA;CVE-2024-42265:In the Linux kernel, the following vulnerability has been resolved:&#xA;protect the fetch of -&gt;fd[fd] in do_dup2() from mispredictions&#xA;both callers have verified that fd is not greater than -&gt;max_fds;&#xA;however, misprediction might end up with&#xA;        tofree = fdt-&gt;fd[fd];&#xA;being speculatively executed.  That&#39;s wrong for the same reasons&#xA;why it&#39;s wrong in close_fd()/file_close_fd_locked(); the same&#xA;solution applies - array_index_nospec(fd, fdt-&gt;max_fds) could differ&#xA;from fd only in case of speculative execution on mispredicted path.&#xA;CVE-2023-52896:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix race between quota rescan and disable leading to NULL pointer deref&#xA;If we have one task trying to start the quota rescan worker while another&#xA;one is trying to disable quotas, we can end up hitting a race that results&#xA;in the quota rescan worker doing a NULL pointer dereference. The steps for&#xA;this are the following:&#xA;1) Quotas are enabled;&#xA;2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().&#xA;   It calls qgroup_rescan_init() which returns 0 (success) and then joins a&#xA;   transaction and commits it;&#xA;3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().&#xA;   It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info-&gt;flags and calls&#xA;   btrfs_qgroup_wait_for_completion(), which returns immediately since the&#xA;   rescan worker is not yet running.&#xA;   Then it starts a transaction and locks fs_info-&gt;qgroup_ioctl_lock;&#xA;4) Task A queues the rescan worker, by calling btrfs_queue_work();&#xA;5) The rescan worker starts, and calls rescan_should_stop() at the start&#xA;   of its while loop, which results in 0 iterations of the loop, since&#xA;   the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info-&gt;flags by&#xA;   task B at step 3);&#xA;6) Task B sets fs_info-&gt;quota_root to NULL;&#xA;7) The rescan worker tries to start a transaction and uses&#xA;   fs_info-&gt;quota_root as the root argument for btrfs_start_transaction().&#xA;   This results in a NULL pointer dereference down the call chain of&#xA;   btrfs_start_transaction(). The stack trace is something like the one&#xA;   reported in Link tag below:&#xA;   general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN&#xA;   KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]&#xA;   CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0&#xA;   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022&#xA;   Workqueue: btrfs-qgroup-rescan btrfs_work_helper&#xA;   RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564&#xA;   Code: 48 89 fb 48 (...)&#xA;   RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206&#xA;   RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80&#xA;   RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000&#xA;   RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d&#xA;   R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000&#xA;   R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003&#xA;   FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000&#xA;   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;   CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0&#xA;   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;   Call Trace:&#xA;    &lt;TASK&gt;&#xA;    btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402&#xA;    btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280&#xA;    process_one_work+0x877/0xdb0 kernel/workqueue.c:2289&#xA;    worker_thread+0xb14/0x1330 kernel/workqueue.c:2436&#xA;    kthread+0x266/0x300 kernel/kthread.c:376&#xA;    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308&#xA;    &lt;/TASK&gt;&#xA;   Modules linked in:&#xA;So fix this by having the rescan worker function not attempt to start a&#xA;transaction if it didn&#39;t do any rescan work.&#xA;CVE-2024-43883:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: vhci-hcd: Do not drop references before new references are gained&#xA;At a few places the driver carries stale pointers&#xA;to references that can still be used. Make sure that does not happen.&#xA;This strictly speaking closes ZDI-CAN-22273, though there may be&#xA;similar races in the driver.&#xA;CVE-2022-48920:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: get rid of warning on transaction commit when using flushoncommit&#xA;When using the flushoncommit mount option, during almost every transaction&#xA;commit we trigger a warning from __writeback_inodes_sb_nr():&#xA;  $ cat fs/fs-writeback.c:&#xA;  (...)&#xA;  static void __writeback_inodes_sb_nr(struct super_block *sb, ...&#xA;  {&#xA;        (...)&#xA;        WARN_ON(!rwsem_is_locked(&amp;sb-&gt;s_umount));&#xA;        (...)&#xA;  }&#xA;  (...)&#xA;The trace produced in dmesg looks like the following:&#xA;  [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3&#xA;  [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif&#xA;  [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186&#xA;  [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3&#xA;  [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)&#xA;  [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246&#xA;  [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000&#xA;  [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50&#xA;  [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000&#xA;  [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488&#xA;  [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460&#xA;  [947.553621] FS:  0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000&#xA;  [947.560537] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0&#xA;  [947.571072] Call Trace:&#xA;  [947.572354]  &lt;TASK&gt;&#xA;  [947.573266]  btrfs_commit_transaction+0x1f1/0x998&#xA;  [947.576785]  ? start_transaction+0x3ab/0x44e&#xA;  [947.579867]  ? schedule_timeout+0x8a/0xdd&#xA;  [947.582716]  transaction_kthread+0xe9/0x156&#xA;  [947.585721]  ? btrfs_cleanup_transaction.isra.0+0x407/0x407&#xA;  [947.590104]  kthread+0x131/0x139&#xA;  [947.592168]  ? set_kthread_struct+0x32/0x32&#xA;  [947.595174]  ret_from_fork+0x22/0x30&#xA;  [947.597561]  &lt;/TASK&gt;&#xA;  [947.598553] ---[ end trace 644721052755541c ]---&#xA;This is because we started using writeback_inodes_sb() to flush delalloc&#xA;when committing a transaction (when using -o flushoncommit), in order to&#xA;avoid deadlocks with filesystem freeze operations. This change was made&#xA;by commit ce8ea7cc6eb313 (&#34;btrfs: don&#39;t call btrfs_start_delalloc_roots&#xA;in flushoncommit&#34;). After that change we started producing that warning,&#xA;and every now and then a user reports this since the warning happens too&#xA;often, it spams dmesg/syslog, and a user is unsure if this reflects any&#xA;problem that might compromise the filesystem&#39;s reliability.&#xA;We can not just lock the sb-&gt;s_umount semaphore before calling&#xA;writeback_inodes_sb(), because that would at least deadlock with&#xA;filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()&#xA;is called while we are holding that semaphore in write mode, and that can&#xA;trigger a transaction commit, resulting in a deadlock. It would also&#xA;trigger the same type of deadlock in the unmount path. Possibly, it could&#xA;also introduce some other locking dependencies that lockdep would report.&#xA;To fix this call try_to_writeback_inodes_sb() instead of&#xA;writeback_inodes_sb(), because that will try to read lock sb-&gt;s_umount&#xA;and then will only call writeback_inodes_sb() if it was able to lock it.&#xA;This is fine because the cases where it can&#39;t read lock sb-&gt;s_umount&#xA;are during a filesystem unmount or during a filesystem freeze - in those&#xA;cases sb-&gt;s_umount is write locked and sync_filesystem() is called, which&#xA;calls writeback_inodes_sb(). In other words, in all cases where we can&#39;t&#xA;take a read lock on sb-&gt;s_umount, writeback is already being triggered&#xA;elsewhere.&#xA;An alternative would be to call btrfs_start_delalloc_roots() with a&#xA;number of pages different from LONG_MAX, for example matching the number&#xA;of delalloc bytes we currently have, in &#xA;---truncated---&#xA;CVE-2022-48871:In the Linux kernel, the following vulnerability has been resolved:&#xA;tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer&#xA;Driver&#39;s probe allocates memory for RX FIFO (port-&gt;rx_fifo) based on&#xA;default RX FIFO depth, e.g. 16.  Later during serial startup the&#xA;qcom_geni_serial_port_setup() updates the RX FIFO depth&#xA;(port-&gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.&#xA;The RX UART handle code will read &#34;port-&gt;rx_fifo_depth&#34; number of words&#xA;into &#34;port-&gt;rx_fifo&#34; buffer, thus exceeding the bounds.  This can be&#xA;observed in certain configurations with Qualcomm Bluetooth HCI UART&#xA;device and KASAN:&#xA;  Bluetooth: hci0: QCA Product ID   :0x00000010&#xA;  Bluetooth: hci0: QCA SOC Version  :0x400a0200&#xA;  Bluetooth: hci0: QCA ROM Version  :0x00000200&#xA;  Bluetooth: hci0: QCA Patch Version:0x00000d2b&#xA;  Bluetooth: hci0: QCA controller version 0x02000200&#xA;  Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv&#xA;  bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2&#xA;  Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)&#xA;  Bluetooth: hci0: QCA Failed to download patch (-2)&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c&#xA;  Write of size 4 at addr ffff279347d578c0 by task swapper/0/0&#xA;  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26&#xA;  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)&#xA;  Call trace:&#xA;   dump_backtrace.part.0+0xe0/0xf0&#xA;   show_stack+0x18/0x40&#xA;   dump_stack_lvl+0x8c/0xb8&#xA;   print_report+0x188/0x488&#xA;   kasan_report+0xb4/0x100&#xA;   __asan_store4+0x80/0xa4&#xA;   handle_rx_uart+0xa8/0x18c&#xA;   qcom_geni_serial_handle_rx+0x84/0x9c&#xA;   qcom_geni_serial_isr+0x24c/0x760&#xA;   __handle_irq_event_percpu+0x108/0x500&#xA;   handle_irq_event+0x6c/0x110&#xA;   handle_fasteoi_irq+0x138/0x2cc&#xA;   generic_handle_domain_irq+0x48/0x64&#xA;If the RX FIFO depth changes after probe, be sure to resize the buffer.&#xA;CVE-2022-48877:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: let&#39;s avoid panic if extent_tree is not created&#xA;This patch avoids the below panic.&#xA;pc : __lookup_extent_tree+0xd8/0x760&#xA;lr : f2fs_do_write_data_page+0x104/0x87c&#xA;sp : ffffffc010cbb3c0&#xA;x29: ffffffc010cbb3e0 x28: 0000000000000000&#xA;x27: ffffff8803e7f020 x26: ffffff8803e7ed40&#xA;x25: ffffff8803e7f020 x24: ffffffc010cbb460&#xA;x23: ffffffc010cbb480 x22: 0000000000000000&#xA;x21: 0000000000000000 x20: ffffffff22e90900&#xA;x19: 0000000000000000 x18: ffffffc010c5d080&#xA;x17: 0000000000000000 x16: 0000000000000020&#xA;x15: ffffffdb1acdbb88 x14: ffffff888759e2b0&#xA;x13: 0000000000000000 x12: ffffff802da49000&#xA;x11: 000000000a001200 x10: ffffff8803e7ed40&#xA;x9 : ffffff8023195800 x8 : ffffff802da49078&#xA;x7 : 0000000000000001 x6 : 0000000000000000&#xA;x5 : 0000000000000006 x4 : ffffffc010cbba28&#xA;x3 : 0000000000000000 x2 : ffffffc010cbb480&#xA;x1 : 0000000000000000 x0 : ffffff8803e7ed40&#xA;Call trace:&#xA; __lookup_extent_tree+0xd8/0x760&#xA; f2fs_do_write_data_page+0x104/0x87c&#xA; f2fs_write_single_data_page+0x420/0xb60&#xA; f2fs_write_cache_pages+0x418/0xb1c&#xA; __f2fs_write_data_pages+0x428/0x58c&#xA; f2fs_write_data_pages+0x30/0x40&#xA; do_writepages+0x88/0x190&#xA; __writeback_single_inode+0x48/0x448&#xA; writeback_sb_inodes+0x468/0x9e8&#xA; __writeback_inodes_wb+0xb8/0x2a4&#xA; wb_writeback+0x33c/0x740&#xA; wb_do_writeback+0x2b4/0x400&#xA; wb_workfn+0xe4/0x34c&#xA; process_one_work+0x24c/0x5bc&#xA; worker_thread+0x3e8/0xa50&#xA; kthread+0x150/0x1b4&#xA;CVE-2024-42267:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()&#xA;Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly&#xA;kill the process and we don&#39;t BUG() the kernel.&#xA;CVE-2024-43890:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing: Fix overflow in get_free_elt()&#xA;&#34;tracing_map-&gt;next_elt&#34; in get_free_elt() is at risk of overflowing.&#xA;Once it overflows, new elements can still be inserted into the tracing_map&#xA;even though the maximum number of elements (`max_elts`) has been reached.&#xA;Continuing to insert elements after the overflow could result in the&#xA;tracing_map containing &#34;tracing_map-&gt;max_size&#34; elements, leaving no empty&#xA;entries.&#xA;If any attempt is made to insert an element into a full tracing_map using&#xA;`__tracing_map_insert()`, it will cause an infinite loop with preemption&#xA;disabled, leading to a CPU hang problem.&#xA;Fix this by preventing any further increments to &#34;tracing_map-&gt;next_elt&#34;&#xA;once it reaches &#34;tracing_map-&gt;max_elt&#34;.&#xA;CVE-2024-43854:In the Linux kernel, the following vulnerability has been resolved:&#xA;block: initialize integrity buffer to zero before writing it to media&#xA;Metadata added by bio_integrity_prep is using plain kmalloc, which leads&#xA;to random kernel memory being written media.  For PI metadata this is&#xA;limited to the app tag that isn&#39;t used by kernel generated metadata,&#xA;but for non-PI metadata the entire buffer leaks kernel memory.&#xA;Fix this by adding the __GFP_ZERO flag to allocations for writes.&#xA;CVE-2024-42299:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Update log-&gt;page_{mask,bits} if log-&gt;page_size changed&#xA;If an NTFS file system is mounted to another system with different&#xA;PAGE_SIZE from the original system, log-&gt;page_size will change in&#xA;log_replay(), but log-&gt;page_{mask,bits} don&#39;t change correspondingly.&#xA;This will cause a panic because &#34;u32 bytes = log-&gt;page_size - page_off&#34;&#xA;will get a negative value in the later read_log_page().&#xA;CVE-2023-52880:In the Linux kernel, the following vulnerability has been resolved:&#xA;tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc&#xA;Any unprivileged user can attach N_GSM0710 ldisc, but it requires&#xA;CAP_NET_ADMIN to create a GSM network anyway.&#xA;Require initial namespace CAP_NET_ADMIN to do that.&#xA;CVE-2022-48811:In the Linux kernel, the following vulnerability has been resolved:&#xA;ibmvnic: don&#39;t release napi in __ibmvnic_open()&#xA;If __ibmvnic_open() encounters an error such as when setting link state,&#xA;it calls release_resources() which frees the napi structures needlessly.&#xA;Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.&#xA;disable napi and irqs) and leave the rest to the callers.&#xA;If caller of __ibmvnic_open() is ibmvnic_open(), it should release the&#xA;resources immediately. If the caller is do_reset() or do_hard_reset(),&#xA;they will release the resources on the next reset.&#xA;This fixes following crash that occurred when running the drmgr command&#xA;several times to add/remove a vnic interface:&#xA;&#x9;[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq&#xA;&#x9;[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq&#xA;&#x9;[102056] ibmvnic 30000003 env3: Replenished 8 pools&#xA;&#x9;Kernel attempted to read user page (10) - exploit attempt? (uid: 0)&#xA;&#x9;BUG: Kernel NULL pointer dereference on read at 0x00000010&#xA;&#x9;Faulting instruction address: 0xc000000000a3c840&#xA;&#x9;Oops: Kernel access of bad area, sig: 11 [#1]&#xA;&#x9;LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries&#xA;&#x9;...&#xA;&#x9;CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1&#xA;&#x9;Workqueue: events_long __ibmvnic_reset [ibmvnic]&#xA;&#x9;NIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820&#xA;&#x9;REGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)&#xA;&#x9;MSR:  8000000000009033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 28248484  XER: 00000004&#xA;&#x9;CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0&#xA;&#x9;GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000&#xA;&#x9;...&#xA;&#x9;NIP [c000000000a3c840] napi_enable+0x20/0xc0&#xA;&#x9;LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]&#xA;&#x9;Call Trace:&#xA;&#x9;[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)&#xA;&#x9;[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]&#xA;&#x9;[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]&#xA;&#x9;[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570&#xA;&#x9;[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660&#xA;&#x9;[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0&#xA;&#x9;[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64&#xA;&#x9;Instruction dump:&#xA;&#x9;7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010&#xA;&#x9;38a0fff6 e92d1100 f9210028 39200000 &lt;e9030010&gt; f9010020 60420000 e9210020&#xA;&#x9;---[ end trace 5f8033b08fd27706 ]---&#xA;CVE-2024-42288:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qla2xxx: Fix for possible memory corruption&#xA;Init Control Block is dereferenced incorrectly.  Correctly dereference ICB&#xA;CVE-2024-43908:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix the null pointer dereference to ras_manager&#xA;Check ras_manager before using it&#xA;CVE-2024-42286:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qla2xxx: validate nvme_local_port correctly&#xA;The driver load failed with error message,&#xA;qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef&#xA;and with a kernel crash,&#xA;&#x9;BUG: unable to handle kernel NULL pointer dereference at 0000000000000070&#xA;&#x9;Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]&#xA;&#x9;RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]&#xA;&#x9;RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282&#xA;&#x9;RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000&#xA;&#x9;RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000&#xA;&#x9;RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030&#xA;&#x9;R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4&#xA;&#x9;R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8&#xA;&#x9;FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000&#xA;&#x9;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;&#x9;CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0&#xA;&#x9;Call Trace:&#xA;&#x9;qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]&#xA;&#x9;? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]&#xA;&#x9;qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]&#xA;&#x9;qla_register_fcport_fn+0x54/0xc0 [qla2xxx]&#xA;Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()&#xA;fails and correctly validate nvme_local_port.&#xA;CVE-2023-52889:In the Linux kernel, the following vulnerability has been resolved:&#xA;apparmor: Fix null pointer deref when receiving skb during sock creation&#xA;The panic below is observed when receiving ICMP packets with secmark set&#xA;while an ICMP raw socket is being created. SK_CTX(sk)-&gt;label is updated&#xA;in apparmor_socket_post_create(), but the packet is delivered to the&#xA;socket before that, causing the null pointer dereference.&#xA;Drop the packet if label context is not set.&#xA;    BUG: kernel NULL pointer dereference, address: 000000000000004c&#xA;    #PF: supervisor read access in kernel mode&#xA;    #PF: error_code(0x0000) - not-present page&#xA;    PGD 0 P4D 0&#xA;    Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df&#xA;    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020&#xA;    RIP: 0010:aa_label_next_confined+0xb/0x40&#xA;    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 &lt;8b&gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2&#xA;    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246&#xA;    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e&#xA;    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000&#xA;    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002&#xA;    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400&#xA;    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000&#xA;    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000&#xA;    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0&#xA;    PKRU: 55555554&#xA;    Call Trace:&#xA;     &lt;IRQ&gt;&#xA;     ? __die+0x23/0x70&#xA;     ? page_fault_oops+0x171/0x4e0&#xA;     ? exc_page_fault+0x7f/0x180&#xA;     ? asm_exc_page_fault+0x26/0x30&#xA;     ? aa_label_next_confined+0xb/0x40&#xA;     apparmor_secmark_check+0xec/0x330&#xA;     security_sock_rcv_skb+0x35/0x50&#xA;     sk_filter_trim_cap+0x47/0x250&#xA;     sock_queue_rcv_skb_reason+0x20/0x60&#xA;     raw_rcv+0x13c/0x210&#xA;     raw_local_deliver+0x1f3/0x250&#xA;     ip_protocol_deliver_rcu+0x4f/0x2f0&#xA;     ip_local_deliver_finish+0x76/0xa0&#xA;     __netif_receive_skb_one_core+0x89/0xa0&#xA;     netif_receive_skb+0x119/0x170&#xA;     ? __netdev_alloc_skb+0x3d/0x140&#xA;     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]&#xA;     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]&#xA;     __napi_poll+0x28/0x1b0&#xA;     net_rx_action+0x2a4/0x380&#xA;     __do_softirq+0xd1/0x2c8&#xA;     __irq_exit_rcu+0xbb/0xf0&#xA;     common_interrupt+0x86/0xa0&#xA;     &lt;/IRQ&gt;&#xA;     &lt;TASK&gt;&#xA;     asm_common_interrupt+0x26/0x40&#xA;    RIP: 0010:apparmor_socket_post_create+0xb/0x200&#xA;    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 &lt;55&gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48&#xA;    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286&#xA;    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001&#xA;    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740&#xA;    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000&#xA;    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003&#xA;    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748&#xA;     ? __pfx_apparmor_socket_post_create+0x10/0x10&#xA;     security_socket_post_create+0x4b/0x80&#xA;     __sock_create+0x176/0x1f0&#xA;     __sys_socket+0x89/0x100&#xA;     __x64_sys_socket+0x17/0x20&#xA;     do_syscall_64+0x5d/0x90&#xA;     ? do_syscall_64+0x6c/0x90&#xA;     ? do_syscall_64+0x6c/0x90&#xA;     ? do_syscall_64+0x6c/0x90&#xA;     entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;CVE-2024-43884:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: MGMT: Add error handling to pair_device()&#xA;hci_conn_params_add() never checks for a NULL value and could lead to a NULL&#xA;pointer dereference causing a crash.&#xA;Fixed by adding error handling in the function.&#xA;CVE-2024-43907:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules&#xA;Check the pointer value to fix potential null pointer&#xA;dereference&#xA;CVE-2024-44938:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: Fix shift-out-of-bounds in dbDiscardAG&#xA;When searching for the next smaller log2 block, BLKSTOL2() returned 0,&#xA;causing shift exponent -1 to be negative.&#xA;This patch fixes the issue by exiting the loop directly when negative&#xA;shift is found.&#xA;CVE-2024-43892:In the Linux kernel, the following vulnerability has been resolved:&#xA;memcg: protect concurrent access to mem_cgroup_idr&#xA;Commit 73f576c04b94 (&#34;mm: memcontrol: fix cgroup creation failure after&#xA;many small jobs&#34;) decoupled the memcg IDs from the CSS ID space to fix the&#xA;cgroup creation failures.  It introduced IDR to maintain the memcg ID&#xA;space.  The IDR depends on external synchronization mechanisms for&#xA;modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()&#xA;happen within css callback and thus are protected through cgroup_mutex&#xA;from concurrent modifications.  However idr_remove() for mem_cgroup_idr&#xA;was not protected against concurrency and can be run concurrently for&#xA;different memcgs when they hit their refcnt to zero.  Fix that.&#xA;We have been seeing list_lru based kernel crashes at a low frequency in&#xA;our fleet for a long time.  These crashes were in different part of&#xA;list_lru code including list_lru_add(), list_lru_del() and reparenting&#xA;code.  Upon further inspection, it looked like for a given object (dentry&#xA;and inode), the super_block&#39;s list_lru didn&#39;t have list_lru_one for the&#xA;memcg of that object.  The initial suspicions were either the object is&#xA;not allocated through kmem_cache_alloc_lru() or somehow&#xA;memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but&#xA;returned success.  No evidence were found for these cases.&#xA;Looking more deeply, we started seeing situations where valid memcg&#39;s id&#xA;is not present in mem_cgroup_idr and in some cases multiple valid memcgs&#xA;have same id and mem_cgroup_idr is pointing to one of them.  So, the most&#xA;reasonable explanation is that these situations can happen due to race&#xA;between multiple idr_remove() calls or race between&#xA;idr_alloc()/idr_replace() and idr_remove().  These races are causing&#xA;multiple memcgs to acquire the same ID and then offlining of one of them&#xA;would cleanup list_lrus on the system for all of them.  Later access from&#xA;other memcgs to the list_lru cause crashes due to missing list_lru_one.&#xA;CVE-2024-44934:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: bridge: mcast: wait for previous gc cycles when removing port&#xA;syzbot hit a use-after-free[1] which is caused because the bridge doesn&#39;t&#xA;make sure that all previous garbage has been collected when removing a&#xA;port. What happens is:&#xA;      CPU 1                   CPU 2&#xA; start gc cycle           remove port&#xA;                         acquire gc lock first&#xA; wait for lock&#xA;                         call br_multicasg_gc() directly&#xA; acquire lock now but    free port&#xA; the port can be freed&#xA; while grp timers still&#xA; running&#xA;Make sure all previous gc cycles have finished by using flush_work before&#xA;freeing the port.&#xA;[1]&#xA;  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861&#xA;  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699&#xA;  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0&#xA;  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   __dump_stack lib/dump_stack.c:88 [inline]&#xA;   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114&#xA;   print_address_description mm/kasan/report.c:377 [inline]&#xA;   print_report+0xc3/0x620 mm/kasan/report.c:488&#xA;   kasan_report+0xd9/0x110 mm/kasan/report.c:601&#xA;   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861&#xA;   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792&#xA;   expire_timers kernel/time/timer.c:1843 [inline]&#xA;   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417&#xA;   __run_timer_base kernel/time/timer.c:2428 [inline]&#xA;   __run_timer_base kernel/time/timer.c:2421 [inline]&#xA;   run_timer_base+0x111/0x190 kernel/time/timer.c:2437&#xA;CVE-2024-43893:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: core: check uartclk for zero to avoid divide by zero&#xA;Calling ioctl TIOCSSERIAL with an invalid baud_base can&#xA;result in uartclk being zero, which will result in a&#xA;divide by zero error in uart_get_divisor(). The check for&#xA;uartclk being zero in uart_set_info() needs to be done&#xA;before other settings are made as subsequent calls to&#xA;ioctl TIOCSSERIAL for the same port would be impacted if&#xA;the uartclk check was done where uartclk gets set.&#xA;Oops: divide error: 0000  PREEMPT SMP KASAN PTI&#xA;RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576&#xA;    drivers/tty/serial/8250/8250_port.c:2589)&#xA;serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502&#xA;    drivers/tty/serial/8250/8250_port.c:2741)&#xA;serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)&#xA;uart_change_line_settings (./include/linux/spinlock.h:376&#xA;    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)&#xA;uart_port_startup (drivers/tty/serial/serial_core.c:342)&#xA;uart_startup (drivers/tty/serial/serial_core.c:368)&#xA;uart_set_info (drivers/tty/serial/serial_core.c:1034)&#xA;uart_set_info_user (drivers/tty/serial/serial_core.c:1059)&#xA;tty_set_serial (drivers/tty/tty_io.c:2637)&#xA;tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)&#xA;__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907&#xA;    fs/ioctl.c:893 fs/ioctl.c:893)&#xA;do_syscall_64 (arch/x86/entry/common.c:52&#xA;    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))&#xA;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;Rule: add&#xA;CVE-2023-52906:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: act_mpls: Fix warning during failed attribute validation&#xA;The &#39;TCA_MPLS_LABEL&#39; attribute is of &#39;NLA_U32&#39; type, but has a&#xA;validation type of &#39;NLA_VALIDATE_FUNCTION&#39;. This is an invalid&#xA;combination according to the comment above &#39;struct nla_policy&#39;:&#xA;&#34;&#xA;Meaning of `validate&#39; field, use via NLA_POLICY_VALIDATE_FN:&#xA;   NLA_BINARY           Validation function called for the attribute.&#xA;   All other            Unused - but note that it&#39;s a union&#xA;&#34;&#xA;This can trigger the warning [1] in nla_get_range_unsigned() when&#xA;validation of the attribute fails. Despite being of &#39;NLA_U32&#39; type, the&#xA;associated &#39;min&#39;/&#39;max&#39; fields in the policy are negative as they are&#xA;aliased by the &#39;validate&#39; field.&#xA;Fix by changing the attribute type to &#39;NLA_BINARY&#39; which is consistent&#xA;with the above comment and all other users of NLA_POLICY_VALIDATE_FN().&#xA;As a result, move the length validation to the validation function.&#xA;No regressions in MPLS tests:&#xA; # ./tdc.py -f tc-tests/actions/mpls.json&#xA; [...]&#xA; # echo $?&#xA; 0&#xA;[1]&#xA;WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118&#xA;nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117&#xA;Modules linked in:&#xA;CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310&#xA; netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411&#xA; netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]&#xA; netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506&#xA; netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546&#xA; rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]&#xA; netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345&#xA; netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921&#xA; sock_sendmsg_nosec net/socket.c:714 [inline]&#xA; sock_sendmsg net/socket.c:734 [inline]&#xA; ____sys_sendmsg+0x38f/0x500 net/socket.c:2482&#xA; ___sys_sendmsg net/socket.c:2536 [inline]&#xA; __sys_sendmsg+0x197/0x230 net/socket.c:2565&#xA; __do_sys_sendmsg net/socket.c:2574 [inline]&#xA; __se_sys_sendmsg net/socket.c:2572 [inline]&#xA; __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;CVE-2022-48872:In the Linux kernel, the following vulnerability has been resolved:&#xA;misc: fastrpc: Fix use-after-free race condition for maps&#xA;It is possible that in between calling fastrpc_map_get() until&#xA;map-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can call&#xA;fastrpc_map_lookup() and get a reference to a map that is about to be&#xA;deleted.&#xA;Rewrite fastrpc_map_get() to only increase the reference count of a map&#xA;if it&#39;s non-zero. Propagate this to callers so they can know if a map is&#xA;about to be deleted.&#xA;Fixes this warning:&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate&#xA;...&#xA;Call trace:&#xA; refcount_warn_saturate&#xA; [fastrpc_map_get inlined]&#xA; [fastrpc_map_lookup inlined]&#xA; fastrpc_map_create&#xA; fastrpc_internal_invoke&#xA; fastrpc_device_ioctl&#xA; __arm64_sys_ioctl&#xA; invoke_syscall&#xA;CVE-2024-43905:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr&#xA;Check return value and conduct null pointer handling to avoid null pointer dereference.&#xA;CVE-2023-52899:In the Linux kernel, the following vulnerability has been resolved:&#xA;Add exception protection processing for vd in axi_chan_handle_err function&#xA;Since there is no protection for vd, a kernel panic will be&#xA;triggered here in exceptional cases.&#xA;You can refer to the processing of axi_chan_block_xfer_complete function&#xA;The triggered kernel panic is as follows:&#xA;[   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060&#xA;[   67.848447] Mem abort info:&#xA;[   67.848449]   ESR = 0x96000004&#xA;[   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[   67.848454]   SET = 0, FnV = 0&#xA;[   67.848456]   EA = 0, S1PTW = 0&#xA;[   67.848458] Data abort info:&#xA;[   67.848460]   ISV = 0, ISS = 0x00000004&#xA;[   67.848462]   CM = 0, WnR = 0&#xA;[   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000&#xA;[   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000&#xA;[   67.848472] Internal error: Oops: 96000004 [#1] SMP&#xA;[   67.848475] Modules linked in: dmatest&#xA;[   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11&#xA;[   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)&#xA;[   67.848487] pc : axi_chan_handle_err+0xc4/0x230&#xA;[   67.848491] lr : axi_chan_handle_err+0x30/0x230&#xA;[   67.848493] sp : ffff0803fe55ae50&#xA;[   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200&#xA;[   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080&#xA;[   67.848504] x25: ffff800010d33880 x24: ffff80001139d850&#xA;[   67.848508] x23: ffff0800c097c168 x22: 0000000000000000&#xA;[   67.848512] x21: 0000000000000080 x20: 0000000000002000&#xA;[   67.848517] x19: ffff0800c097c080 x18: 0000000000000000&#xA;[   67.848521] x17: 0000000000000000 x16: 0000000000000000&#xA;[   67.848525] x15: 0000000000000000 x14: 0000000000000000&#xA;[   67.848529] x13: 0000000000000000 x12: 0000000000000040&#xA;[   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a&#xA;[   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270&#xA;[   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0&#xA;[   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480&#xA;[   67.848550] x3 : dead000000000100 x2 : dead000000000122&#xA;[   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168&#xA;[   67.848559] Call trace:&#xA;[   67.848562]  axi_chan_handle_err+0xc4/0x230&#xA;[   67.848566]  dw_axi_dma_interrupt+0xf4/0x590&#xA;[   67.848569]  __handle_irq_event_percpu+0x60/0x220&#xA;[   67.848573]  handle_irq_event+0x64/0x120&#xA;[   67.848576]  handle_fasteoi_irq+0xc4/0x220&#xA;[   67.848580]  __handle_domain_irq+0x80/0xe0&#xA;[   67.848583]  gic_handle_irq+0xc0/0x138&#xA;[   67.848585]  el1_irq+0xc8/0x180&#xA;[   67.848588]  arch_cpu_idle+0x14/0x2c&#xA;[   67.848591]  default_idle_call+0x40/0x16c&#xA;[   67.848594]  do_idle+0x1f0/0x250&#xA;[   67.848597]  cpu_startup_entry+0x2c/0x60&#xA;[   67.848600]  rest_init+0xc0/0xcc&#xA;[   67.848603]  arch_call_rest_init+0x14/0x1c&#xA;[   67.848606]  start_kernel+0x4cc/0x500&#xA;[   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)&#xA;[   67.848613] ---[ end trace 585a97036f88203a ]---&#xA;CVE-2024-43889:In the Linux kernel, the following vulnerability has been resolved:&#xA;padata: Fix possible divide-by-0 panic in padata_mt_helper()&#xA;We are hit with a not easily reproducible divide-by-0 panic in padata.c at&#xA;bootup time.&#xA;  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI&#xA;  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1&#xA;  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021&#xA;  [   10.017908] Workqueue: events_unbound padata_mt_helper&#xA;  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0&#xA;    :&#xA;  [   10.017963] Call Trace:&#xA;  [   10.017968]  &lt;TASK&gt;&#xA;  [   10.018004]  ? padata_mt_helper+0x39/0xb0&#xA;  [   10.018084]  process_one_work+0x174/0x330&#xA;  [   10.018093]  worker_thread+0x266/0x3a0&#xA;  [   10.018111]  kthread+0xcf/0x100&#xA;  [   10.018124]  ret_from_fork+0x31/0x50&#xA;  [   10.018138]  ret_from_fork_asm+0x1a/0x30&#xA;  [   10.018147]  &lt;/TASK&gt;&#xA;Looking at the padata_mt_helper() function, the only way a divide-by-0&#xA;panic can happen is when ps-&gt;chunk_size is 0.  The way that chunk_size is&#xA;initialized in padata_do_multithreaded(), chunk_size can be 0 when the&#xA;min_chunk in the passed-in padata_mt_job structure is 0.&#xA;Fix this divide-by-0 panic by making sure that chunk_size will be at least&#xA;1 no matter what the input parameters are.&#xA;CVE-2024-41060:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/radeon: check bo_va-&gt;bo is non-NULL before using it&#xA;The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so&#xA;we have to check it before dereferencing it.&#xA;CVE-2024-41082:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvme-fabrics: use reserved tag for reg read/write command&#xA;In some scenarios, if too many commands are issued by nvme command in&#xA;the same time by user tasks, this may exhaust all tags of admin_q. If&#xA;a reset (nvme reset or IO timeout) occurs before these commands finish,&#xA;reconnect routine may fail to update nvme regs due to insufficient tags,&#xA;which will cause kernel hang forever. In order to workaround this issue,&#xA;maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved&#xA;tags. This maybe safe for nvmf:&#xA;1. For the disable ctrl path,  we will not issue connect command&#xA;2. For the enable ctrl / fw activate path, since connect and reg_xx()&#xA;   are called serially.&#xA;So the reserved tags may still be enough while reg_xx() use reserved tags.&#xA;CVE-2022-48879:In the Linux kernel, the following vulnerability has been resolved:&#xA;efi: fix NULL-deref in init error path&#xA;In cases where runtime services are not supported or have been disabled,&#xA;the runtime services workqueue will never have been allocated.&#xA;Do not try to destroy the workqueue unconditionally in the unlikely&#xA;event that EFI initialisation fails to avoid dereferencing a NULL&#xA;pointer.&#xA;CVE-2024-43856:In the Linux kernel, the following vulnerability has been resolved:&#xA;dma: fix call order in dmam_free_coherent&#xA;dmam_free_coherent() frees a DMA allocation, which makes the&#xA;freed vaddr available for reuse, then calls devres_destroy()&#xA;to remove and free the data structure used to track the DMA&#xA;allocation. Between the two calls, it is possible for a&#xA;concurrent task to make an allocation with the same vaddr&#xA;and add it to the devres list.&#xA;If this happens, there will be two entries in the devres list&#xA;with the same vaddr and devres_destroy() can free the wrong&#xA;entry, triggering the WARN_ON() in dmam_match.&#xA;Fix by destroying the devres entry before freeing the DMA&#xA;allocation.&#xA;  kokonut //net/encryption&#xA;    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03&#xA;CVE-2024-44944:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: ctnetlink: use helper function to calculate expect ID&#xA;Delete expectation path is missing a call to the nf_expect_get_id()&#xA;helper function to calculate the expectation ID, otherwise LSB of the&#xA;expectation object address is leaked to userspace.&#xA;CVE-2024-43898:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2022-48891:In the Linux kernel, the following vulnerability has been resolved:&#xA;regulator: da9211: Use irq handler when ready&#xA;If the system does not come from reset (like when it is kexec()), the&#xA;regulator might have an IRQ waiting for us.&#xA;If we enable the IRQ handler before its structures are ready, we crash.&#xA;This patch fixes:&#xA;[    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078&#xA;[    1.316096] Call trace:&#xA;[    1.316101]  blocking_notifier_call_chain+0x20/0xa8&#xA;[    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests&#xA;[    1.327823]  regulator_notifier_call_chain+0x1c/0x2c&#xA;[    1.327825]  da9211_irq_handler+0x68/0xf8&#xA;[    1.327829]  irq_thread+0x11c/0x234&#xA;[    1.327833]  kthread+0x13c/0x154&#xA;CVE-2024-44946:In the Linux kernel, the following vulnerability has been resolved:&#xA;kcm: Serialise kcm_sendmsg() for the same socket.&#xA;syzkaller reported UAF in kcm_release(). [0]&#xA;The scenario is&#xA;  1. Thread A builds a skb with MSG_MORE and sets kcm-&gt;seq_skb.&#xA;  2. Thread A resumes building skb from kcm-&gt;seq_skb but is blocked&#xA;     by sk_stream_wait_memory()&#xA;  3. Thread B calls sendmsg() concurrently, finishes building kcm-&gt;seq_skb&#xA;     and puts the skb to the write queue&#xA;  4. Thread A faces an error and finally frees skb that is already in the&#xA;     write queue&#xA;  5. kcm_release() does double-free the skb in the write queue&#xA;When a thread is building a MSG_MORE skb, another thread must not touch it.&#xA;Let&#39;s add a per-sk mutex and serialise kcm_sendmsg().&#xA;[0]:&#xA;BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]&#xA;BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]&#xA;BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]&#xA;BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]&#xA;BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691&#xA;Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167&#xA;CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024&#xA;Call trace:&#xA; dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291&#xA; show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0x178/0x518 mm/kasan/report.c:488&#xA; kasan_report+0xd8/0x138 mm/kasan/report.c:601&#xA; __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381&#xA; __skb_unlink include/linux/skbuff.h:2366 [inline]&#xA; __skb_dequeue include/linux/skbuff.h:2385 [inline]&#xA; __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]&#xA; __skb_queue_purge include/linux/skbuff.h:3181 [inline]&#xA; kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691&#xA; __sock_release net/socket.c:659 [inline]&#xA; sock_close+0xa4/0x1e8 net/socket.c:1421&#xA; __fput+0x30c/0x738 fs/file_table.c:376&#xA; ____fput+0x20/0x30 fs/file_table.c:404&#xA; task_work_run+0x230/0x2e0 kernel/task_work.c:180&#xA; exit_task_work include/linux/task_work.h:38 [inline]&#xA; do_exit+0x618/0x1f64 kernel/exit.c:871&#xA; do_group_exit+0x194/0x22c kernel/exit.c:1020&#xA; get_signal+0x1500/0x15ec kernel/signal.c:2893&#xA; do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249&#xA; do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148&#xA; exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]&#xA; exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]&#xA; el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713&#xA; el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730&#xA; el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598&#xA;Allocated by task 6166:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x40/0x78 mm/kasan/common.c:68&#xA; kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626&#xA; unpoison_slab_object mm/kasan/common.c:314 [inline]&#xA; __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340&#xA; kasan_slab_alloc include/linux/kasan.h:201 [inline]&#xA; slab_post_alloc_hook mm/slub.c:3813 [inline]&#xA; slab_alloc_node mm/slub.c:3860 [inline]&#xA; kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903&#xA; __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641&#xA; alloc_skb include/linux/skbuff.h:1296 [inline]&#xA; kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; sock_sendmsg+0x220/0x2c0 net/socket.c:768&#xA; splice_to_socket+0x7cc/0xd58 fs/splice.c:889&#xA; do_splice_from fs/splice.c:941 [inline]&#xA; direct_splice_actor+0xec/0x1d8 fs/splice.c:1164&#xA; splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108&#xA; do_splice_direct_actor &#xA;---truncated---&#xA;CVE-2024-44942:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC&#xA;syzbot reports a f2fs bug as below:&#xA;------------[ cut here ]------------&#xA;kernel BUG at fs/f2fs/inline.c:258!&#xA;CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0&#xA;RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258&#xA;Call Trace:&#xA; f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834&#xA; f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]&#xA; __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]&#xA; f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315&#xA; do_writepages+0x35b/0x870 mm/page-writeback.c:2612&#xA; __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650&#xA; writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941&#xA; wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117&#xA; wb_do_writeback fs/fs-writeback.c:2264 [inline]&#xA; wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304&#xA; process_one_work kernel/workqueue.c:3254 [inline]&#xA; process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335&#xA; worker_thread+0x86d/0xd70 kernel/workqueue.c:3416&#xA; kthread+0x2f2/0x390 kernel/kthread.c:388&#xA; ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;The root cause is: inline_data inode can be fuzzed, so that there may&#xA;be valid blkaddr in its direct node, once f2fs triggers background GC&#xA;to migrate the block, it will hit f2fs_bug_on() during dirty page&#xA;writeback.&#xA;Let&#39;s add sanity check on F2FS_INLINE_DATA flag in inode during GC,&#xA;so that, it can forbid migrating inline_data inode&#39;s data block for&#xA;fixing.&#xA;CVE-2024-42295:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: handle inconsistent state in nilfs_btnode_create_block()&#xA;Syzbot reported that a buffer state inconsistency was detected in&#xA;nilfs_btnode_create_block(), triggering a kernel bug.&#xA;It is not appropriate to treat this inconsistency as a bug; it can occur&#xA;if the argument block address (the buffer index of the newly created&#xA;block) is a virtual block number and has been reallocated due to&#xA;corruption of the bitmap used to manage its allocation state.&#xA;So, modify nilfs_btnode_create_block() and its callers to treat it as a&#xA;possible filesystem error, rather than triggering a kernel bug.&#xA;CVE-2024-43834:In the Linux kernel, the following vulnerability has been resolved:&#xA;xdp: fix invalid wait context of page_pool_destroy()&#xA;If the driver uses a page pool, it creates a page pool with&#xA;page_pool_create().&#xA;The reference count of page pool is 1 as default.&#xA;A page pool will be destroyed only when a reference count reaches 0.&#xA;page_pool_destroy() is used to destroy page pool, it decreases a&#xA;reference count.&#xA;When a page pool is destroyed, -&gt;disconnect() is called, which is&#xA;mem_allocator_disconnect().&#xA;This function internally acquires mutex_lock().&#xA;If the driver uses XDP, it registers a memory model with&#xA;xdp_rxq_info_reg_mem_model().&#xA;The xdp_rxq_info_reg_mem_model() internally increases a page pool&#xA;reference count if a memory model is a page pool.&#xA;Now the reference count is 2.&#xA;To destroy a page pool, the driver should call both page_pool_destroy()&#xA;and xdp_unreg_mem_model().&#xA;The xdp_unreg_mem_model() internally calls page_pool_destroy().&#xA;Only page_pool_destroy() decreases a reference count.&#xA;If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we&#xA;will face an invalid wait context warning.&#xA;Because xdp_unreg_mem_model() calls page_pool_destroy() with&#xA;rcu_read_lock().&#xA;The page_pool_destroy() internally acquires mutex_lock().&#xA;Splat looks like:&#xA;=============================&#xA;[ BUG: Invalid wait context ]&#xA;6.10.0-rc6+ #4 Tainted: G W&#xA;-----------------------------&#xA;ethtool/1806 is trying to lock:&#xA;ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150&#xA;other info that might help us debug this:&#xA;context-{5:5}&#xA;3 locks held by ethtool/1806:&#xA;stack backtrace:&#xA;CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed&#xA;Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;dump_stack_lvl+0x7e/0xc0&#xA;__lock_acquire+0x1681/0x4de0&#xA;? _printk+0x64/0xe0&#xA;? __pfx_mark_lock.part.0+0x10/0x10&#xA;? __pfx___lock_acquire+0x10/0x10&#xA;lock_acquire+0x1b3/0x580&#xA;? mem_allocator_disconnect+0x73/0x150&#xA;? __wake_up_klogd.part.0+0x16/0xc0&#xA;? __pfx_lock_acquire+0x10/0x10&#xA;? dump_stack_lvl+0x91/0xc0&#xA;__mutex_lock+0x15c/0x1690&#xA;? mem_allocator_disconnect+0x73/0x150&#xA;? __pfx_prb_read_valid+0x10/0x10&#xA;? mem_allocator_disconnect+0x73/0x150&#xA;? __pfx_llist_add_batch+0x10/0x10&#xA;? console_unlock+0x193/0x1b0&#xA;? lockdep_hardirqs_on+0xbe/0x140&#xA;? __pfx___mutex_lock+0x10/0x10&#xA;? tick_nohz_tick_stopped+0x16/0x90&#xA;? __irq_work_queue_local+0x1e5/0x330&#xA;? irq_work_queue+0x39/0x50&#xA;? __wake_up_klogd.part.0+0x79/0xc0&#xA;? mem_allocator_disconnect+0x73/0x150&#xA;mem_allocator_disconnect+0x73/0x150&#xA;? __pfx_mem_allocator_disconnect+0x10/0x10&#xA;? mark_held_locks+0xa5/0xf0&#xA;? rcu_is_watching+0x11/0xb0&#xA;page_pool_release+0x36e/0x6d0&#xA;page_pool_destroy+0xd7/0x440&#xA;xdp_unreg_mem_model+0x1a7/0x2a0&#xA;? __pfx_xdp_unreg_mem_model+0x10/0x10&#xA;? kfree+0x125/0x370&#xA;? bnxt_free_ring.isra.0+0x2eb/0x500&#xA;? bnxt_free_mem+0x5ac/0x2500&#xA;xdp_rxq_info_unreg+0x4a/0xd0&#xA;bnxt_free_mem+0x1356/0x2500&#xA;bnxt_close_nic+0xf0/0x3b0&#xA;? __pfx_bnxt_close_nic+0x10/0x10&#xA;? ethnl_parse_bit+0x2c6/0x6d0&#xA;? __pfx___nla_validate_parse+0x10/0x10&#xA;? __pfx_ethnl_parse_bit+0x10/0x10&#xA;bnxt_set_features+0x2a8/0x3e0&#xA;__netdev_update_features+0x4dc/0x1370&#xA;? ethnl_parse_bitset+0x4ff/0x750&#xA;? __pfx_ethnl_parse_bitset+0x10/0x10&#xA;? __pfx___netdev_update_features+0x10/0x10&#xA;? mark_held_locks+0xa5/0xf0&#xA;? _raw_spin_unlock_irqrestore+0x42/0x70&#xA;? __pm_runtime_resume+0x7d/0x110&#xA;ethnl_set_features+0x32d/0xa20&#xA;To fix this problem, it uses rhashtable_lookup_fast() instead of&#xA;rhashtable_lookup() with rcu_read_lock().&#xA;Using xa without rcu_read_lock() here is safe.&#xA;xa is freed by __xdp_mem_allocator_rcu_free() and this is called by&#xA;call_rcu() of mem_xa_remove().&#xA;The mem_xa_remove() is called by page_pool_destroy() if a reference&#xA;count reaches 0.&#xA;The xa is already protected by the reference count mechanism well in the&#xA;control plane.&#xA;So removing rcu_read_lock() for page_pool_destroy() is safe.&#xA;CVE-2024-42259:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/i915/gem: Fix Virtual Memory mapping boundaries calculation&#xA;Calculating the size of the mapped area as the lesser value&#xA;between the requested size and the actual size does not consider&#xA;the partial mapping offset. This can cause page fault access.&#xA;Fix the calculation of the starting and ending addresses, the&#xA;total size is now deduced from the difference between the end and&#xA;start addresses.&#xA;Additionally, the calculations have been rewritten in a clearer&#xA;and more understandable form.&#xA;[Joonas: Add Requires: tag]&#xA;Requires: 60a2066c5005 (&#34;drm/i915/gem: Adjust vma offset for framebuffer mmap offset&#34;)&#xA;(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)&#xA;CVE-2023-45896:ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier&#39;s perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.&#xA;CVE-2024-43902:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add null checker before passing variables&#xA;Checks null pointer before passing variables to functions.&#xA;This fixes 3 NULL_RETURNS issues reported by Coverity.&#xA;CVE-2024-44947:In the Linux kernel, the following vulnerability has been resolved:&#xA;fuse: Initialize beyond-EOF page contents before setting uptodate&#xA;fuse_notify_store(), unlike fuse_do_readpage(), does not enable page&#xA;zeroing (because it can be used to change partial page contents).&#xA;So fuse_notify_store() must be more careful to fully initialize page&#xA;contents (including parts of the page that are beyond end-of-file)&#xA;before marking the page uptodate.&#xA;The current code can leave beyond-EOF page contents uninitialized, which&#xA;makes these uninitialized page contents visible to userspace via mmap().&#xA;This is an information leak, but only affects systems which do not&#xA;enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the&#xA;corresponding kernel command line parameter).&#xA;CVE-2022-48902:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: do not WARN_ON() if we have PageError set&#xA;Whenever we do any extent buffer operations we call&#xA;assert_eb_page_uptodate() to complain loudly if we&#39;re operating on an&#xA;non-uptodate page.  Our overnight tests caught this warning earlier this&#xA;week&#xA;  WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50&#xA;  CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G        W         5.17.0-rc3+ #564&#xA;  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014&#xA;  Workqueue: btrfs-cache btrfs_work_helper&#xA;  RIP: 0010:assert_eb_page_uptodate+0x3f/0x50&#xA;  RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246&#xA;  RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000&#xA;  RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0&#xA;  RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000&#xA;  R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1&#xA;  R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000&#xA;  FS:  0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0&#xA;  Call Trace:&#xA;   extent_buffer_test_bit+0x3f/0x70&#xA;   free_space_test_bit+0xa6/0xc0&#xA;   load_free_space_tree+0x1f6/0x470&#xA;   caching_thread+0x454/0x630&#xA;   ? rcu_read_lock_sched_held+0x12/0x60&#xA;   ? rcu_read_lock_sched_held+0x12/0x60&#xA;   ? rcu_read_lock_sched_held+0x12/0x60&#xA;   ? lock_release+0x1f0/0x2d0&#xA;   btrfs_work_helper+0xf2/0x3e0&#xA;   ? lock_release+0x1f0/0x2d0&#xA;   ? finish_task_switch.isra.0+0xf9/0x3a0&#xA;   process_one_work+0x26d/0x580&#xA;   ? process_one_work+0x580/0x580&#xA;   worker_thread+0x55/0x3b0&#xA;   ? process_one_work+0x580/0x580&#xA;   kthread+0xf0/0x120&#xA;   ? kthread_complete_and_exit+0x20/0x20&#xA;   ret_from_fork+0x1f/0x30&#xA;This was partially fixed by c2e39305299f01 (&#34;btrfs: clear extent buffer&#xA;uptodate when we fail to write it&#34;), however all that fix did was keep&#xA;us from finding extent buffers after a failed writeout.  It didn&#39;t keep&#xA;us from continuing to use a buffer that we already had found.&#xA;In this case we&#39;re searching the commit root to cache the block group,&#xA;so we can start committing the transaction and switch the commit root&#xA;and then start writing.  After the switch we can look up an extent&#xA;buffer that hasn&#39;t been written yet and start processing that block&#xA;group.  Then we fail to write that block out and clear Uptodate on the&#xA;page, and then we start spewing these errors.&#xA;Normally we&#39;re protected by the tree lock to a certain degree here.  If&#xA;we read a block we have that block read locked, and we block the writer&#xA;from locking the block before we submit it for the write.  However this&#xA;isn&#39;t necessarily fool proof because the read could happen before we do&#xA;the submit_bio and after we locked and unlocked the extent buffer.&#xA;Also in this particular case we have path-&gt;skip_locking set, so that&#xA;won&#39;t save us here.  We&#39;ll simply get a block that was valid when we&#xA;read it, but became invalid while we were using it.&#xA;What we really want is to catch the case where we&#39;ve &#34;read&#34; a block but&#xA;it&#39;s not marked Uptodate.  On read we ClearPageError(), so if we&#39;re&#xA;!Uptodate and !Error we know we didn&#39;t do the right thing for reading&#xA;the page.&#xA;Fix this by checking !Uptodate &amp;&amp; !Error, this way we will not complain&#xA;if our buffer gets invalidated while we&#39;re using it, and we&#39;ll maintain&#xA;the spirit of the check which is to make sure we have a fully in-cache&#xA;block while we&#39;re messing with it.&#xA;CVE-2022-48901:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: do not start relocation until in progress drops are done&#xA;We hit a bug with a recovering relocation on mount for one of our file&#xA;systems in production.  I reproduced this locally by injecting errors&#xA;into snapshot delete with balance running at the same time.  This&#xA;presented as an error while looking up an extent item&#xA;  WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680&#xA;  CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8&#xA;  RIP: 0010:lookup_inline_extent_backref+0x647/0x680&#xA;  RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202&#xA;  RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000&#xA;  RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000&#xA;  RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001&#xA;  R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000&#xA;  R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000&#xA;  FS:  0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   insert_inline_extent_backref+0x46/0xd0&#xA;   __btrfs_inc_extent_ref.isra.0+0x5f/0x200&#xA;   ? btrfs_merge_delayed_refs+0x164/0x190&#xA;   __btrfs_run_delayed_refs+0x561/0xfa0&#xA;   ? btrfs_search_slot+0x7b4/0xb30&#xA;   ? btrfs_update_root+0x1a9/0x2c0&#xA;   btrfs_run_delayed_refs+0x73/0x1f0&#xA;   ? btrfs_update_root+0x1a9/0x2c0&#xA;   btrfs_commit_transaction+0x50/0xa50&#xA;   ? btrfs_update_reloc_root+0x122/0x220&#xA;   prepare_to_merge+0x29f/0x320&#xA;   relocate_block_group+0x2b8/0x550&#xA;   btrfs_relocate_block_group+0x1a6/0x350&#xA;   btrfs_relocate_chunk+0x27/0xe0&#xA;   btrfs_balance+0x777/0xe60&#xA;   balance_kthread+0x35/0x50&#xA;   ? btrfs_balance+0xe60/0xe60&#xA;   kthread+0x16b/0x190&#xA;   ? set_kthread_struct+0x40/0x40&#xA;   ret_from_fork+0x22/0x30&#xA;   &lt;/TASK&gt;&#xA;Normally snapshot deletion and relocation are excluded from running at&#xA;the same time by the fs_info-&gt;cleaner_mutex.  However if we had a&#xA;pending balance waiting to get the -&gt;cleaner_mutex, and a snapshot&#xA;deletion was running, and then the box crashed, we would come up in a&#xA;state where we have a half deleted snapshot.&#xA;Again, in the normal case the snapshot deletion needs to complete before&#xA;relocation can start, but in this case relocation could very well start&#xA;before the snapshot deletion completes, as we simply add the root to the&#xA;dead roots list and wait for the next time the cleaner runs to clean up&#xA;the snapshot.&#xA;Fix this by setting a bit on the fs_info if we have any DEAD_ROOT&#39;s that&#xA;had a pending drop_progress key.  If they do then we know we were in the&#xA;middle of the drop operation and set a flag on the fs_info.  Then&#xA;balance can wait until this flag is cleared to start up again.&#xA;If there are DEAD_ROOT&#39;s that don&#39;t have a drop_progress set then we&#39;re&#xA;safe to start balance right away as we&#39;ll be properly protected by the&#xA;cleaner_mutex.&#xA;CVE-2024-43914:In the Linux kernel, the following vulnerability has been resolved:&#xA;md/raid5: avoid BUG_ON() while continue reshape after reassembling&#xA;Currently, mdadm support --revert-reshape to abort the reshape while&#xA;reassembling, as the test 07revert-grow. However, following BUG_ON()&#xA;can be triggerred by the test:&#xA;kernel BUG at drivers/md/raid5.c:6278!&#xA;invalid opcode: 0000 [#1] PREEMPT SMP PTI&#xA;irq event stamp: 158985&#xA;CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94&#xA;RIP: 0010:reshape_request+0x3f1/0xe60&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; raid5_sync_request+0x43d/0x550&#xA; md_do_sync+0xb7a/0x2110&#xA; md_thread+0x294/0x2b0&#xA; kthread+0x147/0x1c0&#xA; ret_from_fork+0x59/0x70&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;Root cause is that --revert-reshape update the raid_disks from 5 to 4,&#xA;while reshape position is still set, and after reassembling the array,&#xA;reshape position will be read from super block, then during reshape the&#xA;checking of &#39;writepos&#39; that is caculated by old reshape position will&#xA;fail.&#xA;Fix this panic the easy way first, by converting the BUG_ON() to&#xA;WARN_ON(), and stop the reshape if checkings fail.&#xA;Noted that mdadm must fix --revert-shape as well, and probably md/raid&#xA;should enhance metadata validation as well, however this means&#xA;reassemble will fail and there must be user tools to fix the wrong&#xA;metadata.&#xA;CVE-2023-52907:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: pn533: Wait for out_urb&#39;s completion in pn533_usb_send_frame()&#xA;Fix a use-after-free that occurs in hcd when in_urb sent from&#xA;pn533_usb_send_frame() is completed earlier than out_urb. Its callback&#xA;frees the skb data in pn533_send_async_complete() that is used as a&#xA;transfer buffer of out_urb. Wait before sending in_urb until the&#xA;callback of out_urb is called. To modify the callback of out_urb alone,&#xA;separate the complete function of out_urb and ack_urb.&#xA;Found by a modified version of syzkaller.&#xA;BUG: KASAN: use-after-free in dummy_timer&#xA;Call Trace:&#xA; memcpy (mm/kasan/shadow.c:65)&#xA; dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)&#xA; transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)&#xA; dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)&#xA; arch_static_branch (arch/x86/include/asm/jump_label.h:27)&#xA; static_key_false (include/linux/jump_label.h:207)&#xA; timer_expire_exit (include/trace/events/timer.h:127)&#xA; call_timer_fn (kernel/time/timer.c:1475)&#xA; expire_timers (kernel/time/timer.c:1519)&#xA; __run_timers (kernel/time/timer.c:1790)&#xA; run_timer_softirq (kernel/time/timer.c:1803)&#xA;CVE-2024-43899:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix null pointer deref in dcn20_resource.c&#xA;Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:&#xA;mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all&#xA;and then enabling fullscreen playback (double click on the video)&#xA;The following calltrace will be seen:&#xA;[  181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[  181.843997] #PF: supervisor instruction fetch in kernel mode&#xA;[  181.844003] #PF: error_code(0x0010) - not-present page&#xA;[  181.844009] PGD 0 P4D 0&#xA;[  181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI&#xA;[  181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu&#xA;[  181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018&#xA;[  181.844044] RIP: 0010:0x0&#xA;[  181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.&#xA;[  181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246&#xA;[  181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004&#xA;[  181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400&#xA;[  181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c&#xA;[  181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8&#xA;[  181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005&#xA;[  181.844121] FS:  00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000&#xA;[  181.844128] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0&#xA;[  181.844141] Call Trace:&#xA;[  181.844146]  &lt;TASK&gt;&#xA;[  181.844153]  ? show_regs+0x6d/0x80&#xA;[  181.844167]  ? __die+0x24/0x80&#xA;[  181.844179]  ? page_fault_oops+0x99/0x1b0&#xA;[  181.844192]  ? do_user_addr_fault+0x31d/0x6b0&#xA;[  181.844204]  ? exc_page_fault+0x83/0x1b0&#xA;[  181.844216]  ? asm_exc_page_fault+0x27/0x30&#xA;[  181.844237]  dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]&#xA;[  181.845115]  amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]&#xA;[  181.845985]  amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]&#xA;[  181.846848]  fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]&#xA;[  181.847734]  fill_dc_plane_attributes+0x162/0x350 [amdgpu]&#xA;[  181.848748]  dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]&#xA;[  181.849791]  ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]&#xA;[  181.850840]  amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]&#xA;CVE-2024-42276:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvme-pci: add missing condition check for existence of mapped data&#xA;nvme_map_data() is called when request has physical segments, hence&#xA;the nvme_unmap_data() should have same condition to avoid dereference.&#xA;CVE-2024-42311:In the Linux kernel, the following vulnerability has been resolved:&#xA;hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()&#xA;Syzbot reports uninitialized value access issue as below:&#xA;loop0: detected capacity change from 0 to 64&#xA;=====================================================&#xA;BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30&#xA; hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30&#xA; d_revalidate fs/namei.c:862 [inline]&#xA; lookup_fast+0x89e/0x8e0 fs/namei.c:1649&#xA; walk_component fs/namei.c:2001 [inline]&#xA; link_path_walk+0x817/0x1480 fs/namei.c:2332&#xA; path_lookupat+0xd9/0x6f0 fs/namei.c:2485&#xA; filename_lookup+0x22e/0x740 fs/namei.c:2515&#xA; user_path_at_empty+0x8b/0x390 fs/namei.c:2924&#xA; user_path_at include/linux/namei.h:57 [inline]&#xA; do_mount fs/namespace.c:3689 [inline]&#xA; __do_sys_mount fs/namespace.c:3898 [inline]&#xA; __se_sys_mount+0x66b/0x810 fs/namespace.c:3875&#xA; __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]&#xA;BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366&#xA; hfs_ext_read_extent fs/hfs/extent.c:196 [inline]&#xA; hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366&#xA; block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271&#xA; hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39&#xA; filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426&#xA; do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553&#xA; do_read_cache_page mm/filemap.c:3595 [inline]&#xA; read_cache_page+0xfb/0x2f0 mm/filemap.c:3604&#xA; read_mapping_page include/linux/pagemap.h:755 [inline]&#xA; hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78&#xA; hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204&#xA; hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406&#xA; mount_bdev+0x628/0x920 fs/super.c:1359&#xA; hfs_mount+0xcd/0xe0 fs/hfs/super.c:456&#xA; legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610&#xA; vfs_get_tree+0xdc/0x5d0 fs/super.c:1489&#xA; do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145&#xA; path_mount+0xf98/0x26a0 fs/namespace.c:3475&#xA; do_mount fs/namespace.c:3488 [inline]&#xA; __do_sys_mount fs/namespace.c:3697 [inline]&#xA; __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674&#xA; __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674&#xA; do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]&#xA; __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178&#xA; do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203&#xA; do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246&#xA; entry_SYSENTER_compat_after_hwframe+0x70/0x82&#xA;Uninit was created at:&#xA; __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590&#xA; __alloc_pages_node include/linux/gfp.h:238 [inline]&#xA; alloc_pages_node include/linux/gfp.h:261 [inline]&#xA; alloc_slab_page mm/slub.c:2190 [inline]&#xA; allocate_slab mm/slub.c:2354 [inline]&#xA; new_slab+0x2d7/0x1400 mm/slub.c:2407&#xA; ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540&#xA; __slab_alloc mm/slub.c:3625 [inline]&#xA; __slab_alloc_node mm/slub.c:3678 [inline]&#xA; slab_alloc_node mm/slub.c:3850 [inline]&#xA; kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879&#xA; alloc_inode_sb include/linux/fs.h:3018 [inline]&#xA; hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165&#xA; alloc_inode+0x83/0x440 fs/inode.c:260&#xA; new_inode_pseudo fs/inode.c:1005 [inline]&#xA; new_inode+0x38/0x4f0 fs/inode.c:1031&#xA; hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186&#xA; hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228&#xA; vfs_mkdir+0x49a/0x700 fs/namei.c:4126&#xA; do_mkdirat+0x529/0x810 fs/namei.c:4149&#xA; __do_sys_mkdirat fs/namei.c:4164 [inline]&#xA; __se_sys_mkdirat fs/namei.c:4162 [inline]&#xA; __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;It missed to initialize .tz_secondswest, .cached_start and .cached_blocks&#xA;fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.&#xA;CVE-2024-44960:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: core: Check for unset descriptor&#xA;Make sure the descriptor has been set before looking at maxpacket.&#xA;This fixes a null pointer panic in this case.&#xA;This may happen if the gadget doesn&#39;t properly set up the endpoint&#xA;for the current speed, or the gadget descriptors are malformed and&#xA;the descriptor for the speed/endpoint are not found.&#xA;No current gadget driver is known to have this problem, but this&#xA;may cause a hard-to-find bug during development of new gadgets.&#xA;CVE-2024-44971:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()&#xA;bcm_sf2_mdio_register() calls of_phy_find_device() and then&#xA;phy_device_remove() in a loop to remove existing PHY devices.&#xA;of_phy_find_device() eventually calls bus_find_device(), which calls&#xA;get_device() on the returned struct device * to increment the refcount.&#xA;The current implementation does not decrement the refcount, which causes&#xA;memory leak.&#xA;This commit adds the missing phy_device_free() call to decrement the&#xA;refcount via put_device() to balance the refcount.&#xA;CVE-2023-52916:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: aspeed: Fix memory overwrite if timing is 1600x900&#xA;When capturing 1600x900, system could crash when system memory usage is&#xA;tight.&#xA;The way to reproduce this issue:&#xA;1. Use 1600x900 to display on host&#xA;2. Mount ISO through &#39;Virtual media&#39; on OpenBMC&#39;s web&#xA;3. Run script as below on host to do sha continuously&#xA;  #!/bin/bash&#xA;  while [ [1] ];&#xA;  do&#xA;&#x9;find /media -type f -printf &#39;&#34;%h/%f&#34;\n&#39; | xargs sha256sum&#xA;  done&#xA;4. Open KVM on OpenBMC&#39;s web&#xA;The size of macro block captured is 8x8. Therefore, we should make sure&#xA;the height of src-buf is 8 aligned to fix this issue.&#xA;CVE-2024-43829:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/qxl: Add check for drm_cvt_mode&#xA;Add check for the return value of drm_cvt_mode() and return the error if&#xA;it fails in order to avoid NULL pointer dereference.&#xA;CVE-2024-36934:In the Linux kernel, the following vulnerability has been resolved:&#xA;bna: ensure the copied buf is NUL terminated&#xA;Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from&#xA;userspace to that buffer. Later, we use sscanf on this buffer but we don&#39;t&#xA;ensure that the string is terminated inside the buffer, this can lead to&#xA;OOB read when using sscanf. Fix this issue by using memdup_user_nul&#xA;instead of memdup_user.&#xA;CVE-2022-48887:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vmwgfx: Remove rcu locks from user resources&#xA;User resource lookups used rcu to avoid two extra atomics. Unfortunately&#xA;the rcu paths were buggy and it was easy to make the driver crash by&#xA;submitting command buffers from two different threads. Because the&#xA;lookups never show up in performance profiles replace them with a&#xA;regular spin lock which fixes the races in accesses to those shared&#xA;resources.&#xA;Fixes kernel oops&#39;es in IGT&#39;s vmwgfx execution_buffer stress test and&#xA;seen crashes with apps using shared resources.&#xA;CVE-2024-44948:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/mtrr: Check if fixed MTRRs exist before saving them&#xA;MTRRs have an obsolete fixed variant for fine grained caching control&#xA;of the 640K-1MB region that uses separate MSRs. This fixed variant has&#xA;a separate capability bit in the MTRR capability MSR.&#xA;So far all x86 CPUs which support MTRR have this separate bit set, so it&#xA;went unnoticed that mtrr_save_state() does not check the capability bit&#xA;before accessing the fixed MTRR MSRs.&#xA;Though on a CPU that does not support the fixed MTRR capability this&#xA;results in a #GP.  The #GP itself is harmless because the RDMSR fault is&#xA;handled gracefully, but results in a WARN_ON().&#xA;Add the missing capability check to prevent this.&#xA;CVE-2024-44988:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: dsa: mv88e6xxx: Fix out-of-bound access&#xA;If an ATU violation was caused by a CPU Load operation, the SPID could&#xA;be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).&#xA;CVE-2024-44986:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: fix possible UAF in ip6_finish_output2()&#xA;If skb_expand_head() returns NULL, skb has been freed&#xA;and associated dst/idev could also have been freed.&#xA;We need to hold rcu_read_lock() to make sure the dst and&#xA;associated idev are alive.&#xA;CVE-2024-44987:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: prevent UAF in ip6_send_skb()&#xA;syzbot reported an UAF in ip6_send_skb() [1]&#xA;After ip6_local_out() has returned, we no longer can safely&#xA;dereference rt, unless we hold rcu_read_lock().&#xA;A similar issue has been fixed in commit&#xA;a688caa34beb (&#34;ipv6: take rcu lock in rawv6_send_hdrinc()&#34;)&#xA;Another potential issue in ip6_finish_output2() is handled in a&#xA;separate patch.&#xA;[1]&#xA; BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964&#xA;Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530&#xA;CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:93 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0x169/0x550 mm/kasan/report.c:488&#xA;  kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA;  ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964&#xA;  rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588&#xA;  rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x1a6/0x270 net/socket.c:745&#xA;  sock_write_iter+0x2dd/0x400 net/socket.c:1160&#xA; do_iter_readv_writev+0x60a/0x890&#xA;  vfs_writev+0x37c/0xbb0 fs/read_write.c:971&#xA;  do_writev+0x1b1/0x350 fs/read_write.c:1018&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f936bf79e79&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014&#xA;RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79&#xA;RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004&#xA;RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8&#xA; &lt;/TASK&gt;&#xA;Allocated by task 6530:&#xA;  kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;  unpoison_slab_object mm/kasan/common.c:312 [inline]&#xA;  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338&#xA;  kasan_slab_alloc include/linux/kasan.h:201 [inline]&#xA;  slab_post_alloc_hook mm/slub.c:3988 [inline]&#xA;  slab_alloc_node mm/slub.c:4037 [inline]&#xA;  kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044&#xA;  dst_alloc+0x12b/0x190 net/core/dst.c:89&#xA;  ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670&#xA;  make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]&#xA;  xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313&#xA;  ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257&#xA;  rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x1a6/0x270 net/socket.c:745&#xA;  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597&#xA;  ___sys_sendmsg net/socket.c:2651 [inline]&#xA;  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Freed by task 45:&#xA;  kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579&#xA;  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240&#xA;  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256&#xA;  kasan_slab_free include/linux/kasan.h:184 [inline]&#xA;  slab_free_hook mm/slub.c:2252 [inline]&#xA;  slab_free mm/slub.c:4473 [inline]&#xA;  kmem_cache_free+0x145/0x350 mm/slub.c:4548&#xA;  dst_destroy+0x2ac/0x460 net/core/dst.c:124&#xA;  rcu_do_batch kernel/rcu/tree.c:2569 [inline]&#xA;  rcu_core+0xafd/0x1830 kernel/rcu/tree.&#xA;---truncated---&#xA;CVE-2023-52915:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer&#xA;In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf&#xA;is null and msg[i].len is zero, former checks on msg[i].buf would be&#xA;passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing&#xA;msg[i].buf[0] without sanity check, null ptr deref would happen.&#xA;We add check on msg[i].len to prevent crash.&#xA;Similar commit:&#xA;commit 0ed554fd769a&#xA;(&#34;media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()&#34;)&#xA;CVE-2023-52894:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()&#xA;In Google internal bug 265639009 we&#39;ve received an (as yet) unreproducible&#xA;crash report from an aarch64 GKI 5.10.149-android13 running device.&#xA;AFAICT the source code is at:&#xA;  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10&#xA;The call stack is:&#xA;  ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()&#xA;with the crash at:&#xA;  ncm_do_notify+0x98/0x270&#xA;Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)&#xA;Which I believe disassembles to (I don&#39;t know ARM assembly, but it looks sane enough to me...):&#xA;  // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)&#xA;  0B 0D 00 79    strh w11, [x8, #6]&#xA;  // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)&#xA;  6C 0A 00 B9    str  w12, [x19, #8]&#xA;  // x10 (NULL) was read here from offset 0 of valid pointer x9&#xA;  // IMHO we&#39;re reading &#39;cdev-&gt;gadget&#39; and getting NULL&#xA;  // gadget is indeed at offset 0 of struct usb_composite_dev&#xA;  2A 01 40 F9    ldr  x10, [x9]&#xA;  // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request&#xA;  69 02 40 F9    ldr  x9, [x19]&#xA;  // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed&#xA;  4B 5D 40 B9    ldr  w11, [x10, #0x5c]&#xA;which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:&#xA;  event-&gt;wLength = cpu_to_le16(8);&#xA;  req-&gt;length = NCM_STATUS_BYTECOUNT;&#xA;  /* SPEED_CHANGE data is up/down speeds in bits/sec */&#xA;  data = req-&gt;buf + sizeof *event;&#xA;  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));&#xA;My analysis of registers and NULL ptr deref crash offset&#xA;  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)&#xA;heavily suggests that the crash is due to &#39;cdev-&gt;gadget&#39; being NULL when executing:&#xA;  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));&#xA;which calls:&#xA;  ncm_bitrate(NULL)&#xA;which then calls:&#xA;  gadget_is_superspeed(NULL)&#xA;which reads&#xA;  ((struct usb_gadget *)NULL)-&gt;max_speed&#xA;and hits a panic.&#xA;AFAICT, if I&#39;m counting right, the offset of max_speed is indeed 0x5C.&#xA;(remember there&#39;s a GKI KABI reservation of 16 bytes in struct work_struct)&#xA;It&#39;s not at all clear to me how this is all supposed to work...&#xA;but returning 0 seems much better than panic-ing...&#xA;CVE-2022-48828:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSD: Fix ia_size underflow&#xA;iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and&#xA;NFSv4 both define file size as an unsigned 64-bit type. Thus there&#xA;is a range of valid file size values an NFS client can send that is&#xA;already larger than Linux can handle.&#xA;Currently decode_fattr4() dumps a full u64 value into ia_size. If&#xA;that value happens to be larger than S64_MAX, then ia_size&#xA;underflows. I&#39;m about to fix up the NFSv3 behavior as well, so let&#39;s&#xA;catch the underflow in the common code path: nfsd_setattr().&#xA;CVE-2023-52900:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix general protection fault in nilfs_btree_insert()&#xA;If nilfs2 reads a corrupted disk image and tries to reads a b-tree node&#xA;block by calling __nilfs_btree_get_block() against an invalid virtual&#xA;block address, it returns -ENOENT because conversion of the virtual block&#xA;address to a disk block address fails.  However, this return value is the&#xA;same as the internal code that b-tree lookup routines return to indicate&#xA;that the block being searched does not exist, so functions that operate on&#xA;that b-tree may misbehave.&#xA;When nilfs_btree_insert() receives this spurious &#39;not found&#39; code from&#xA;nilfs_btree_do_lookup(), it misunderstands that the &#39;not found&#39; check was&#xA;successful and continues the insert operation using incomplete lookup path&#xA;data, causing the following crash:&#xA; general protection fault, probably for non-canonical address&#xA; 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN&#xA; KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]&#xA; ...&#xA; RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]&#xA; RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]&#xA; RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238&#xA; Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89&#xA; ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 &lt;42&gt; 80 3c&#xA; 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02&#xA; ...&#xA; Call Trace:&#xA; &lt;TASK&gt;&#xA;  nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]&#xA;  nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147&#xA;  nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101&#xA;  __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991&#xA;  __block_write_begin fs/buffer.c:2041 [inline]&#xA;  block_write_begin+0x93/0x1e0 fs/buffer.c:2102&#xA;  nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261&#xA;  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772&#xA;  __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900&#xA;  generic_file_write_iter+0xab/0x310 mm/filemap.c:3932&#xA;  call_write_iter include/linux/fs.h:2186 [inline]&#xA;  new_sync_write fs/read_write.c:491 [inline]&#xA;  vfs_write+0x7dc/0xc50 fs/read_write.c:584&#xA;  ksys_write+0x177/0x2a0 fs/read_write.c:637&#xA;  do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80&#xA;  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA; ...&#xA; &lt;/TASK&gt;&#xA;This patch fixes the root cause of this problem by replacing the error&#xA;code that __nilfs_btree_get_block() returns on block address conversion&#xA;failure from -ENOENT to another internal code -EINVAL which means that the&#xA;b-tree metadata is corrupted.&#xA;By returning -EINVAL, it propagates without glitches, and for all relevant&#xA;b-tree operations, functions in the upper bmap layer output an error&#xA;message indicating corrupted b-tree metadata via&#xA;nilfs_bmap_convert_error(), and code -EIO will be eventually returned as&#xA;it should be.&#xA;CVE-2024-42104:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: add missing check for inode numbers on directory entries&#xA;Syzbot reported that mounting and unmounting a specific pattern of&#xA;corrupted nilfs2 filesystem images causes a use-after-free of metadata&#xA;file inodes, which triggers a kernel bug in lru_add_fn().&#xA;As Jan Kara pointed out, this is because the link count of a metadata file&#xA;gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),&#xA;tries to delete that inode (ifile inode in this case).&#xA;The inconsistency occurs because directories containing the inode numbers&#xA;of these metadata files that should not be visible in the namespace are&#xA;read without checking.&#xA;Fix this issue by treating the inode numbers of these internal files as&#xA;errors in the sanity check helper when reading directory folios/pages.&#xA;Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer&#xA;analysis.&#xA;CVE-2024-41059:In the Linux kernel, the following vulnerability has been resolved:&#xA;hfsplus: fix uninit-value in copy_name&#xA;[syzbot reported]&#xA;BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160&#xA; sized_strscpy+0xc4/0x160&#xA; copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411&#xA; hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750&#xA; vfs_listxattr fs/xattr.c:493 [inline]&#xA; listxattr+0x1f3/0x6b0 fs/xattr.c:840&#xA; path_listxattr fs/xattr.c:864 [inline]&#xA; __do_sys_listxattr fs/xattr.c:876 [inline]&#xA; __se_sys_listxattr fs/xattr.c:873 [inline]&#xA; __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873&#xA; x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was created at:&#xA; slab_post_alloc_hook mm/slub.c:3877 [inline]&#xA; slab_alloc_node mm/slub.c:3918 [inline]&#xA; kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065&#xA; kmalloc include/linux/slab.h:628 [inline]&#xA; hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699&#xA; vfs_listxattr fs/xattr.c:493 [inline]&#xA; listxattr+0x1f3/0x6b0 fs/xattr.c:840&#xA; path_listxattr fs/xattr.c:864 [inline]&#xA; __do_sys_listxattr fs/xattr.c:876 [inline]&#xA; __se_sys_listxattr fs/xattr.c:873 [inline]&#xA; __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873&#xA; x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[Fix]&#xA;When allocating memory to strbuf, initialize memory to 0.&#xA;CVE-2024-42292:In the Linux kernel, the following vulnerability has been resolved:&#xA;kobject_uevent: Fix OOB access within zap_modalias_env()&#xA;zap_modalias_env() wrongly calculates size of memory block to move, so&#xA;will cause OOB memory access issue if variable MODALIAS is not the last&#xA;one within its @env parameter, fixed by correcting size to memmove.&#xA;CVE-2024-41017:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: don&#39;t walk off the end of ealist&#xA;Add a check before visiting the members of ea to&#xA;make sure each ea stays within the ealist.&#xA;CVE-2024-42119:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Skip finding free audio for unknown engine_id&#xA;[WHY]&#xA;ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it&#xA;also means it is uninitialized and does not need free audio.&#xA;[HOW]&#xA;Skip and return NULL.&#xA;This fixes 2 OVERRUN issues reported by Coverity.&#xA;CVE-2024-36915:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies&#xA;syzbot reported unsafe calls to copy_from_sockptr() [1]&#xA;Use copy_safe_from_sockptr() instead.&#xA;[1]&#xA;BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]&#xA; BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255&#xA;Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078&#xA;CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0x169/0x550 mm/kasan/report.c:488&#xA;  kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA;  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]&#xA;  copy_from_sockptr include/linux/sockptr.h:55 [inline]&#xA;  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255&#xA;  do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311&#xA;  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334&#xA;  __do_sys_setsockopt net/socket.c:2343 [inline]&#xA;  __se_sys_setsockopt net/socket.c:2340 [inline]&#xA;  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340&#xA; do_syscall_64+0xfd/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;RIP: 0033:0x7f7fac07fd89&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036&#xA;RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89&#xA;RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004&#xA;RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000&#xA;R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;CVE-2024-44999:In the Linux kernel, the following vulnerability has been resolved:&#xA;gtp: pull network headers in gtp_dev_xmit()&#xA;syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]&#xA;We must make sure the IPv4 or Ipv6 header is pulled in skb-&gt;head&#xA;before accessing fields in them.&#xA;Use pskb_inet_may_pull() to fix this issue.&#xA;[1]&#xA;BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]&#xA; BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]&#xA; BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281&#xA;  ipv6_pdp_find drivers/net/gtp.c:220 [inline]&#xA;  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]&#xA;  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281&#xA;  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:4922 [inline]&#xA;  xmit_one net/core/dev.c:3580 [inline]&#xA;  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596&#xA;  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423&#xA;  dev_queue_xmit include/linux/netdevice.h:3105 [inline]&#xA;  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276&#xA;  packet_snd net/packet/af_packet.c:3145 [inline]&#xA;  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:745&#xA;  __sys_sendto+0x685/0x830 net/socket.c:2204&#xA;  __do_sys_sendto net/socket.c:2216 [inline]&#xA;  __se_sys_sendto net/socket.c:2212 [inline]&#xA;  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212&#xA;  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:3994 [inline]&#xA;  slab_alloc_node mm/slub.c:4037 [inline]&#xA;  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583&#xA;  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674&#xA;  alloc_skb include/linux/skbuff.h:1320 [inline]&#xA;  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526&#xA;  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815&#xA;  packet_alloc_skb net/packet/af_packet.c:2994 [inline]&#xA;  packet_snd net/packet/af_packet.c:3088 [inline]&#xA;  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:745&#xA;  __sys_sendto+0x685/0x830 net/socket.c:2204&#xA;  __do_sys_sendto net/socket.c:2216 [inline]&#xA;  __se_sys_sendto net/socket.c:2212 [inline]&#xA;  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212&#xA;  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024&#xA;CVE-2024-44974:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: pm: avoid possible UaF when selecting endp&#xA;select_local_address() and select_signal_address() both select an&#xA;endpoint entry from the list inside an RCU protected section, but return&#xA;a reference to it, to be read later on. If the entry is dereferenced&#xA;after the RCU unlock, reading info could cause a Use-after-Free.&#xA;A simple solution is to copy the required info while inside the RCU&#xA;protected section to avoid any risk of UaF later. The address ID might&#xA;need to be modified later to handle the ID0 case later, so a copy seems&#xA;OK to deal with.&#xA;CVE-2024-45003:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfs: Don&#39;t evict inode under the inode lru traversing context&#xA;The inode reclaiming process(See function prune_icache_sb) collects all&#xA;reclaimable inodes and mark them with I_FREEING flag at first, at that&#xA;time, other processes will be stuck if they try getting these inodes&#xA;(See function find_inode_fast), then the reclaiming process destroy the&#xA;inodes by function dispose_list(). Some filesystems(eg. ext4 with&#xA;ea_inode feature, ubifs with xattr) may do inode lookup in the inode&#xA;evicting callback function, if the inode lookup is operated under the&#xA;inode lru traversing context, deadlock problems may happen.&#xA;Case 1: In function ext4_evict_inode(), the ea inode lookup could happen&#xA;        if ea_inode feature is enabled, the lookup process will be stuck&#xA;&#x9;under the evicting context like this:&#xA; 1. File A has inode i_reg and an ea inode i_ea&#xA; 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&gt;i_ea&#xA; 3. Then, following three processes running like this:&#xA;    PA                              PB&#xA; echo 2 &gt; /proc/sys/vm/drop_caches&#xA;  shrink_slab&#xA;   prune_dcache_sb&#xA;   // i_reg is added into lru, lru-&gt;i_ea-&gt;i_reg&#xA;   prune_icache_sb&#xA;    list_lru_walk_one&#xA;     inode_lru_isolate&#xA;      i_ea-&gt;i_state |= I_FREEING // set inode state&#xA;     inode_lru_isolate&#xA;      __iget(i_reg)&#xA;      spin_unlock(&amp;i_reg-&gt;i_lock)&#xA;      spin_unlock(lru_lock)&#xA;                                     rm file A&#xA;                                      i_reg-&gt;nlink = 0&#xA;      iput(i_reg) // i_reg-&gt;nlink is 0, do evict&#xA;       ext4_evict_inode&#xA;        ext4_xattr_delete_inode&#xA;         ext4_xattr_inode_dec_ref_all&#xA;          ext4_xattr_inode_iget&#xA;           ext4_iget(i_ea-&gt;i_ino)&#xA;            iget_locked&#xA;             find_inode_fast&#xA;              __wait_on_freeing_inode(i_ea) ----? AA deadlock&#xA;    dispose_list // cannot be executed by prune_icache_sb&#xA;     wake_up_bit(&amp;i_ea-&gt;i_state)&#xA;Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file&#xA;        deleting process holds BASEHD&#39;s wbuf-&gt;io_mutex while getting the&#xA;&#x9;xattr inode, which could race with inode reclaiming process(The&#xA;        reclaiming process could try locking BASEHD&#39;s wbuf-&gt;io_mutex in&#xA;&#x9;inode evicting function), then an ABBA deadlock problem would&#xA;&#x9;happen as following:&#xA; 1. File A has inode ia and a xattr(with inode ixa), regular file B has&#xA;    inode ib and a xattr.&#xA; 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-&gt;ixa&#xA; 3. Then, following three processes running like this:&#xA;        PA                PB                        PC&#xA;                echo 2 &gt; /proc/sys/vm/drop_caches&#xA;                 shrink_slab&#xA;                  prune_dcache_sb&#xA;                  // ib and ia are added into lru, lru-&gt;ixa-&gt;ib-&gt;ia&#xA;                  prune_icache_sb&#xA;                   list_lru_walk_one&#xA;                    inode_lru_isolate&#xA;                     ixa-&gt;i_state |= I_FREEING // set inode state&#xA;                    inode_lru_isolate&#xA;                     __iget(ib)&#xA;                     spin_unlock(&amp;ib-&gt;i_lock)&#xA;                     spin_unlock(lru_lock)&#xA;                                                   rm file B&#xA;                                                    ib-&gt;nlink = 0&#xA; rm file A&#xA;  iput(ia)&#xA;   ubifs_evict_inode(ia)&#xA;    ubifs_jnl_delete_inode(ia)&#xA;     ubifs_jnl_write_inode(ia)&#xA;      make_reservation(BASEHD) // Lock wbuf-&gt;io_mutex&#xA;      ubifs_iget(ixa-&gt;i_ino)&#xA;       iget_locked&#xA;        find_inode_fast&#xA;         __wait_on_freeing_inode(ixa)&#xA;          |          iput(ib) // ib-&gt;nlink is 0, do evict&#xA;          |           ubifs_evict_inode&#xA;          |            ubifs_jnl_delete_inode(ib)&#xA;          ?             ubifs_jnl_write_inode&#xA;     ABBA deadlock ?-----make_reservation(BASEHD)&#xA;                   dispose_list // cannot be executed by prune_icache_sb&#xA;                    wake_up_bit(&amp;ixa-&gt;i_state)&#xA;Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING&#xA;to pin the inode in memory while inode_lru_isolate(&#xA;---truncated---&#xA;CVE-2024-46745:In the Linux kernel, the following vulnerability has been resolved:&#xA;Input: uinput - reject requests with unreasonable number of slots&#xA;When exercising uinput interface syzkaller may try setting up device&#xA;with a really large number of slots, which causes memory allocation&#xA;failure in input_mt_init_slots(). While this allocation failure is&#xA;handled properly and request is rejected, it results in syzkaller&#xA;reports. Additionally, such request may put undue burden on the&#xA;system which will try to free a lot of memory for a bogus request.&#xA;Fix it by limiting allowed number of slots to 100. This can easily&#xA;be extended if we see devices that can track more than 100 contacts.&#xA;CVE-2024-45028:In the Linux kernel, the following vulnerability has been resolved:&#xA;mmc: mmc_test: Fix NULL dereference on allocation failure&#xA;If the &#34;test-&gt;highmem = alloc_pages()&#34; allocation fails then calling&#xA;__free_pages(test-&gt;highmem) will result in a NULL dereference.  Also&#xA;change the error code to -ENOMEM instead of returning success.&#xA;CVE-2024-46723:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: fix ucode out-of-bounds read warning&#xA;Clear warning that read ucode[] may out-of-bounds.&#xA;CVE-2024-36270:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: tproxy: bail out if IP has been disabled on the device&#xA;syzbot reports:&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]&#xA;[..]&#xA;RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62&#xA;Call Trace:&#xA; nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]&#xA; nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168&#xA;__in_dev_get_rcu() can return NULL, so check for this.&#xA;CVE-2024-46747:In the Linux kernel, the following vulnerability has been resolved:&#xA;HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup&#xA;report_fixup for the Cougar 500k Gaming Keyboard was not verifying&#xA;that the report descriptor size was correct before accessing it&#xA;CVE-2024-44995:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hns3: fix a deadlock problem when config TC during resetting&#xA;When config TC during the reset process, may cause a deadlock, the flow is&#xA;as below:&#xA;                             pf reset start&#xA;                                 │&#xA;                                 ▼&#xA;                              ......&#xA;setup tc                         │&#xA;    │                            ▼&#xA;    ▼                      DOWN: napi_disable()&#xA;napi_disable()(skip)             │&#xA;    │                            │&#xA;    ▼                            ▼&#xA;  ......                      ......&#xA;    │                            │&#xA;    ▼                            │&#xA;napi_enable()                    │&#xA;                                 ▼&#xA;                           UINIT: netif_napi_del()&#xA;                                 │&#xA;                                 ▼&#xA;                              ......&#xA;                                 │&#xA;                                 ▼&#xA;                           INIT: netif_napi_add()&#xA;                                 │&#xA;                                 ▼&#xA;                              ......                 global reset start&#xA;                                 │                      │&#xA;                                 ▼                      ▼&#xA;                           UP: napi_enable()(skip)    ......&#xA;                                 │                      │&#xA;                                 ▼                      ▼&#xA;                              ......                 napi_disable()&#xA;In reset process, the driver will DOWN the port and then UINIT, in this&#xA;case, the setup tc process will UP the port before UINIT, so cause the&#xA;problem. Adds a DOWN process in UINIT to fix it.&#xA;CVE-2024-46714:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Skip wbscl_set_scaler_filter if filter is null&#xA;Callers can pass null in filter (i.e. from returned from the function&#xA;wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is&#xA;not the case.&#xA;This fixes 4 NULL_RETURNS issues reported by Coverity.&#xA;CVE-2024-46731:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/pm: fix the Out-of-bounds read warning&#xA;using index i - 1U may beyond element index&#xA;for mc_data[] when i = 0.&#xA;CVE-2024-44965:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/mm: Fix pti_clone_pgtable() alignment assumption&#xA;Guenter reported dodgy crashes on an i386-nosmp build using GCC-11&#xA;that had the form of endless traps until entry stack exhaust and then&#xA;#DF from the stack guard.&#xA;It turned out that pti_clone_pgtable() had alignment assumptions on&#xA;the start address, notably it hard assumes start is PMD aligned. This&#xA;is true on x86_64, but very much not true on i386.&#xA;These assumptions can cause the end condition to malfunction, leading&#xA;to a &#39;short&#39; clone. Guess what happens when the user mapping has a&#xA;short copy of the entry text?&#xA;Use the correct increment form for addr to avoid alignment&#xA;assumptions.&#xA;CVE-2024-46787:In the Linux kernel, the following vulnerability has been resolved:&#xA;userfaultfd: fix checks for huge PMDs&#xA;Patch series &#34;userfaultfd: fix races around pmd_trans_huge() check&#34;, v2.&#xA;The pmd_trans_huge() code in mfill_atomic() is wrong in three different&#xA;ways depending on kernel version:&#xA;1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit&#xA;   the right two race windows) - I&#39;ve tested this in a kernel build with&#xA;   some extra mdelay() calls. See the commit message for a description&#xA;   of the race scenario.&#xA;   On older kernels (before 6.5), I think the same bug can even&#xA;   theoretically lead to accessing transhuge page contents as a page table&#xA;   if you hit the right 5 narrow race windows (I haven&#39;t tested this case).&#xA;2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for&#xA;   detecting PMDs that don&#39;t point to page tables.&#xA;   On older kernels (before 6.5), you&#39;d just have to win a single fairly&#xA;   wide race to hit this.&#xA;   I&#39;ve tested this on 6.1 stable by racing migration (with a mdelay()&#xA;   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86&#xA;   VM, that causes a kernel oops in ptlock_ptr().&#xA;3. On newer kernels (&gt;=6.5), for shmem mappings, khugepaged is allowed&#xA;   to yank page tables out from under us (though I haven&#39;t tested that),&#xA;   so I think the BUG_ON() checks in mfill_atomic() are just wrong.&#xA;I decided to write two separate fixes for these (one fix for bugs 1+2, one&#xA;fix for bug 3), so that the first fix can be backported to kernels&#xA;affected by bugs 1+2.&#xA;This patch (of 2):&#xA;This fixes two issues.&#xA;I discovered that the following race can occur:&#xA;  mfill_atomic                other thread&#xA;  ============                ============&#xA;                              &lt;zap PMD&gt;&#xA;  pmdp_get_lockless() [reads none pmd]&#xA;  &lt;bail if trans_huge&gt;&#xA;  &lt;if none:&gt;&#xA;                              &lt;pagefault creates transhuge zeropage&gt;&#xA;    __pte_alloc [no-op]&#xA;                              &lt;zap PMD&gt;&#xA;  &lt;bail if pmd_trans_huge(*dst_pmd)&gt;&#xA;  BUG_ON(pmd_none(*dst_pmd))&#xA;I have experimentally verified this in a kernel with extra mdelay() calls;&#xA;the BUG_ON(pmd_none(*dst_pmd)) triggers.&#xA;On kernels newer than commit 0d940a9b270b (&#34;mm/pgtable: allow&#xA;pte_offset_map[_lock]() to fail&#34;), this can&#39;t lead to anything worse than&#xA;a BUG_ON(), since the page table access helpers are actually designed to&#xA;deal with page tables concurrently disappearing; but on older kernels&#xA;(&lt;=6.4), I think we could probably theoretically race past the two&#xA;BUG_ON() checks and end up treating a hugepage as a page table.&#xA;The second issue is that, as Qi Zheng pointed out, there are other types&#xA;of huge PMDs that pmd_trans_huge() can&#39;t catch: devmap PMDs and swap PMDs&#xA;(in particular, migration PMDs).&#xA;On &lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a&#xA;PMD that contains a migration entry (which just requires winning a single,&#xA;fairly wide race), it will pass the PMD to pte_offset_map_lock(), which&#xA;assumes that the PMD points to a page table.&#xA;Breakage follows: First, the kernel tries to take the PTE lock (which will&#xA;crash or maybe worse if there is no &#34;struct page&#34; for the address bits in&#xA;the migration entry PMD - I think at least on X86 there usually is no&#xA;corresponding &#34;struct page&#34; thanks to the PTE inversion mitigation, amd64&#xA;looks different).&#xA;If that didn&#39;t crash, the kernel would next try to write a PTE into what&#xA;it wrongly thinks is a page table.&#xA;As part of fixing these issues, get rid of the check for pmd_trans_huge()&#xA;before __pte_alloc() - that&#39;s redundant, we&#39;re going to have to check for&#xA;that after the __pte_alloc() anyway.&#xA;Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.&#xA;CVE-2024-46751:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: don&#39;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()&#xA;Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,&#xA;aborting the transaction and logging an error message.&#xA;CVE-2024-46752:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: replace BUG_ON() with error handling at update_ref_for_cow()&#xA;Instead of a BUG_ON() just return an error, log an error message and&#xA;abort the transaction in case we find an extent buffer belonging to the&#xA;relocation tree that doesn&#39;t have the full backref flag set. This is&#xA;unexpected and should never happen (save for bugs or a potential bad&#xA;memory).&#xA;CVE-2024-46733:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix qgroup reserve leaks in cow_file_range&#xA;In the buffered write path, the dirty page owns the qgroup reserve until&#xA;it creates an ordered_extent.&#xA;Therefore, any errors that occur before the ordered_extent is created&#xA;must free that reservation, or else the space is leaked. The fstest&#xA;generic/475 exercises various IO error paths, and is able to trigger&#xA;errors in cow_file_range where we fail to get to allocating the ordered&#xA;extent. Note that because we *do* clear delalloc, we are likely to&#xA;remove the inode from the delalloc list, so the inodes/pages to not have&#xA;invalidate/launder called on them in the commit abort path.&#xA;This results in failures at the unmount stage of the test that look like:&#xA;  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure&#xA;  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure&#xA;  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]&#xA;  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq&#xA;  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014&#xA;  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]&#xA;  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202&#xA;  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001&#xA;  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8&#xA;  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000&#xA;  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c&#xA;  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? close_ctree+0x222/0x4d0 [btrfs]&#xA;   ? __warn.cold+0x8e/0xea&#xA;   ? close_ctree+0x222/0x4d0 [btrfs]&#xA;   ? report_bug+0xff/0x140&#xA;   ? handle_bug+0x3b/0x70&#xA;   ? exc_invalid_op+0x17/0x70&#xA;   ? asm_exc_invalid_op+0x1a/0x20&#xA;   ? close_ctree+0x222/0x4d0 [btrfs]&#xA;   generic_shutdown_super+0x70/0x160&#xA;   kill_anon_super+0x11/0x40&#xA;   btrfs_kill_super+0x11/0x20 [btrfs]&#xA;   deactivate_locked_super+0x2e/0xa0&#xA;   cleanup_mnt+0xb5/0x150&#xA;   task_work_run+0x57/0x80&#xA;   syscall_exit_to_user_mode+0x121/0x130&#xA;   do_syscall_64+0xab/0x1a0&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;  RIP: 0033:0x7f916847a887&#xA;  ---[ end trace 0000000000000000 ]---&#xA;  BTRFS error (device dm-8 state EA): qgroup reserved space leaked&#xA;Cases 2 and 3 in the out_reserve path both pertain to this type of leak&#xA;and must free the reserved qgroup data. Because it is already an error&#xA;path, I opted not to handle the possible errors in&#xA;btrfs_free_qgroup_data.&#xA;CVE-2024-46744:In the Linux kernel, the following vulnerability has been resolved:&#xA;Squashfs: sanity check symbolic link size&#xA;Syzkiller reports a &#34;KMSAN: uninit-value in pick_link&#34; bug.&#xA;This is caused by an uninitialised page, which is ultimately caused&#xA;by a corrupted symbolic link size read from disk.&#xA;The reason why the corrupted symlink size causes an uninitialised&#xA;page is due to the following sequence of events:&#xA;1. squashfs_read_inode() is called to read the symbolic&#xA;   link from disk.  This assigns the corrupted value&#xA;   3875536935 to inode-&gt;i_size.&#xA;2. Later squashfs_symlink_read_folio() is called, which assigns&#xA;   this corrupted value to the length variable, which being a&#xA;   signed int, overflows producing a negative number.&#xA;3. The following loop that fills in the page contents checks that&#xA;   the copied bytes is less than length, which being negative means&#xA;   the loop is skipped, producing an uninitialised page.&#xA;This patch adds a sanity check which checks that the symbolic&#xA;link size is not larger than expected.&#xA;--&#xA;V2: fix spelling mistake.&#xA;CVE-2022-48721:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/smc: Forward wakeup to smc socket waitqueue after fallback&#xA;When we replace TCP with SMC and a fallback occurs, there may be&#xA;some socket waitqueue entries remaining in smc socket-&gt;wq, such&#xA;as eppoll_entries inserted by userspace applications.&#xA;After the fallback, data flows over TCP/IP and only clcsocket-&gt;wq&#xA;will be woken up. Applications can&#39;t be notified by the entries&#xA;which were inserted in smc socket-&gt;wq before fallback. So we need&#xA;a mechanism to wake up smc socket-&gt;wq at the same time if some&#xA;entries remaining in it.&#xA;The current workaround is to transfer the entries from smc socket-&gt;wq&#xA;to clcsock-&gt;wq during the fallback. But this may cause a crash&#xA;like this:&#xA; general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI&#xA; CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E     5.16.0+ #107&#xA; RIP: 0010:__wake_up_common+0x65/0x170&#xA; Call Trace:&#xA;  &lt;IRQ&gt;&#xA;  __wake_up_common_lock+0x7a/0xc0&#xA;  sock_def_readable+0x3c/0x70&#xA;  tcp_data_queue+0x4a7/0xc40&#xA;  tcp_rcv_established+0x32f/0x660&#xA;  ? sk_filter_trim_cap+0xcb/0x2e0&#xA;  tcp_v4_do_rcv+0x10b/0x260&#xA;  tcp_v4_rcv+0xd2a/0xde0&#xA;  ip_protocol_deliver_rcu+0x3b/0x1d0&#xA;  ip_local_deliver_finish+0x54/0x60&#xA;  ip_local_deliver+0x6a/0x110&#xA;  ? tcp_v4_early_demux+0xa2/0x140&#xA;  ? tcp_v4_early_demux+0x10d/0x140&#xA;  ip_sublist_rcv_finish+0x49/0x60&#xA;  ip_sublist_rcv+0x19d/0x230&#xA;  ip_list_rcv+0x13e/0x170&#xA;  __netif_receive_skb_list_core+0x1c2/0x240&#xA;  netif_receive_skb_list_internal+0x1e6/0x320&#xA;  napi_complete_done+0x11d/0x190&#xA;  mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]&#xA;  __napi_poll+0x3c/0x1b0&#xA;  net_rx_action+0x27c/0x300&#xA;  __do_softirq+0x114/0x2d2&#xA;  irq_exit_rcu+0xb4/0xe0&#xA;  common_interrupt+0xba/0xe0&#xA;  &lt;/IRQ&gt;&#xA;  &lt;TASK&gt;&#xA;The crash is caused by privately transferring waitqueue entries from&#xA;smc socket-&gt;wq to clcsock-&gt;wq. The owners of these entries, such as&#xA;epoll, have no idea that the entries have been transferred to a&#xA;different socket wait queue and still use original waitqueue spinlock&#xA;(smc socket-&gt;wq.wait.lock) to make the entries operation exclusive,&#xA;but it doesn&#39;t work. The operations to the entries, such as removing&#xA;from the waitqueue (now is clcsock-&gt;wq after fallback), may cause a&#xA;crash when clcsock waitqueue is being iterated over at the moment.&#xA;This patch tries to fix this by no longer transferring wait queue&#xA;entries privately, but introducing own implementations of clcsock&#39;s&#xA;callback functions in fallback situation. The callback functions will&#xA;forward the wakeup to smc socket-&gt;wq if clcsock-&gt;wq is actually woken&#xA;up and smc socket-&gt;wq has remaining entries.&#xA;CVE-2024-37021:In the Linux kernel, the following vulnerability has been resolved:&#xA;fpga: manager: add owner module and take its refcount&#xA;The current implementation of the fpga manager assumes that the low-level&#xA;module registers a driver for the parent device and uses its owner pointer&#xA;to take the module&#39;s refcount. This approach is problematic since it can&#xA;lead to a null pointer dereference while attempting to get the manager if&#xA;the parent device does not have a driver.&#xA;To address this problem, add a module owner pointer to the fpga_manager&#xA;struct and use it to take the module&#39;s refcount. Modify the functions for&#xA;registering the manager to take an additional owner module parameter and&#xA;rename them to avoid conflicts. Use the old function names for helper&#xA;macros that automatically set the module that registers the manager as the&#xA;owner. This ensures compatibility with existing low-level control modules&#xA;and reduces the chances of registering a manager without setting the owner.&#xA;Also, update the documentation to keep it consistent with the new interface&#xA;for registering an fpga manager.&#xA;Other changes: opportunistically move put_device() from __fpga_mgr_get() to&#xA;fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the&#xA;manager device is taken in these functions.&#xA;CVE-2021-47622:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: ufs: Fix a deadlock in the error handler&#xA;The following deadlock has been observed on a test setup:&#xA; - All tags allocated&#xA; - The SCSI error handler calls ufshcd_eh_host_reset_handler()&#xA; - ufshcd_eh_host_reset_handler() queues work that calls&#xA;   ufshcd_err_handler()&#xA; - ufshcd_err_handler() locks up as follows:&#xA;Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt&#xA;Call trace:&#xA; __switch_to+0x298/0x5d8&#xA; __schedule+0x6cc/0xa94&#xA; schedule+0x12c/0x298&#xA; blk_mq_get_tag+0x210/0x480&#xA; __blk_mq_alloc_request+0x1c8/0x284&#xA; blk_get_request+0x74/0x134&#xA; ufshcd_exec_dev_cmd+0x68/0x640&#xA; ufshcd_verify_dev_init+0x68/0x35c&#xA; ufshcd_probe_hba+0x12c/0x1cb8&#xA; ufshcd_host_reset_and_restore+0x88/0x254&#xA; ufshcd_reset_and_restore+0xd0/0x354&#xA; ufshcd_err_handler+0x408/0xc58&#xA; process_one_work+0x24c/0x66c&#xA; worker_thread+0x3e8/0xa4c&#xA; kthread+0x150/0x1b4&#xA; ret_from_fork+0x10/0x30&#xA;Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved&#xA;request.&#xA;CVE-2024-36479:In the Linux kernel, the following vulnerability has been resolved:&#xA;fpga: bridge: add owner module and take its refcount&#xA;The current implementation of the fpga bridge assumes that the low-level&#xA;module registers a driver for the parent device and uses its owner pointer&#xA;to take the module&#39;s refcount. This approach is problematic since it can&#xA;lead to a null pointer dereference while attempting to get the bridge if&#xA;the parent device does not have a driver.&#xA;To address this problem, add a module owner pointer to the fpga_bridge&#xA;struct and use it to take the module&#39;s refcount. Modify the function for&#xA;registering a bridge to take an additional owner module parameter and&#xA;rename it to avoid conflicts. Use the old function name for a helper macro&#xA;that automatically sets the module that registers the bridge as the owner.&#xA;This ensures compatibility with existing low-level control modules and&#xA;reduces the chances of registering a bridge without setting the owner.&#xA;Also, update the documentation to keep it consistent with the new interface&#xA;for registering an fpga bridge.&#xA;Other changes: opportunistically move put_device() from __fpga_bridge_get()&#xA;to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since&#xA;the bridge device is taken in these functions.&#xA;CVE-2024-40976:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/lima: mask irqs in timeout path before hard reset&#xA;There is a race condition in which a rendering job might take just long&#xA;enough to trigger the drm sched job timeout handler but also still&#xA;complete before the hard reset is done by the timeout handler.&#xA;This runs into race conditions not expected by the timeout handler.&#xA;In some very specific cases it currently may result in a refcount&#xA;imbalance on lima_pm_idle, with a stack dump such as:&#xA;[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0&#xA;...&#xA;[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0&#xA;...&#xA;[10136.669628] Call trace:&#xA;[10136.669634]  lima_devfreq_record_idle+0xa0/0xb0&#xA;[10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0&#xA;[10136.669656]  lima_gp_irq_handler+0xa8/0x120&#xA;[10136.669666]  __handle_irq_event_percpu+0x48/0x160&#xA;[10136.669679]  handle_irq_event+0x4c/0xc0&#xA;We can prevent that race condition entirely by masking the irqs at the&#xA;beginning of the timeout handler, at which point we give up on waiting&#xA;for that job entirely.&#xA;The irqs will be enabled again at the next hard reset which is already&#xA;done as a recovery by the timeout handler.&#xA;CVE-2024-42105:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix inode number range checks&#xA;Patch series &#34;nilfs2: fix potential issues related to reserved inodes&#34;.&#xA;This series fixes one use-after-free issue reported by syzbot, caused by&#xA;nilfs2&#39;s internal inode being exposed in the namespace on a corrupted&#xA;filesystem, and a couple of flaws that cause problems if the starting&#xA;number of non-reserved inodes written in the on-disk super block is&#xA;intentionally (or corruptly) changed from its default value.  &#xA;This patch (of 3):&#xA;In the current implementation of nilfs2, &#34;nilfs-&gt;ns_first_ino&#34;, which&#xA;gives the first non-reserved inode number, is read from the superblock,&#xA;but its lower limit is not checked.&#xA;As a result, if a number that overlaps with the inode number range of&#xA;reserved inodes such as the root directory or metadata files is set in the&#xA;super block parameter, the inode number test macros (NILFS_MDT_INODE and&#xA;NILFS_VALID_INODE) will not function properly.&#xA;In addition, these test macros use left bit-shift calculations using with&#xA;the inode number as the shift count via the BIT macro, but the result of a&#xA;shift calculation that exceeds the bit width of an integer is undefined in&#xA;the C specification, so if &#34;ns_first_ino&#34; is set to a large value other&#xA;than the default value NILFS_USER_INO (=11), the macros may potentially&#xA;malfunction depending on the environment.&#xA;Fix these issues by checking the lower bound of &#34;nilfs-&gt;ns_first_ino&#34; and&#xA;by preventing bit shifts equal to or greater than the NILFS_USER_INO&#xA;constant in the inode number test macros.&#xA;Also, change the type of &#34;ns_first_ino&#34; from signed integer to unsigned&#xA;integer to avoid the need for type casting in comparisons such as the&#xA;lower bound check introduced this time.&#xA;CVE-2024-42148:In the Linux kernel, the following vulnerability has been resolved:&#xA;bnx2x: Fix multiple UBSAN array-index-out-of-bounds&#xA;Fix UBSAN warnings that occur when using a system with 32 physical&#xA;cpu cores or more, or when the user defines a number of Ethernet&#xA;queues greater than or equal to FP_SB_MAX_E1x using the num_queues&#xA;module parameter.&#xA;Currently there is a read/write out of bounds that occurs on the array&#xA;&#34;struct stats_query_entry query&#34; present inside the &#34;bnx2x_fw_stats_req&#34;&#xA;struct in &#34;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h&#34;.&#xA;Looking at the definition of the &#34;struct stats_query_entry query&#34; array:&#xA;struct stats_query_entry query[FP_SB_MAX_E1x+&#xA;         BNX2X_FIRST_QUEUE_QUERY_IDX];&#xA;FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and&#xA;has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3&#xA;meaning the array has a total size of 19.&#xA;Since accesses to &#34;struct stats_query_entry query&#34; are offset-ted by&#xA;BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet&#xA;queues should not exceed FP_SB_MAX_E1x (16). However one of these queues&#xA;is reserved for FCOE and thus the number of Ethernet queues should be set&#xA;to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if&#xA;it is not.&#xA;This is also described in a comment in the source code in&#xA;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition&#xA;of FP_SB_MAX_E1x. Below is the part of this explanation that it important&#xA;for this patch&#xA;/*&#xA;  * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is&#xA;  * control by the number of fast-path status blocks supported by the&#xA;  * device (HW/FW). Each fast-path status block (FP-SB) aka non-default&#xA;  * status block represents an independent interrupts context that can&#xA;  * serve a regular L2 networking queue. However special L2 queues such&#xA;  * as the FCoE queue do not require a FP-SB and other components like&#xA;  * the CNIC may consume FP-SB reducing the number of possible L2 queues&#xA;  *&#xA;  * If the maximum number of FP-SB available is X then:&#xA;  * a. If CNIC is supported it consumes 1 FP-SB thus the max number of&#xA;  *    regular L2 queues is Y=X-1&#xA;  * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)&#xA;  * c. If the FCoE L2 queue is supported the actual number of L2 queues&#xA;  *    is Y+1&#xA;  * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for&#xA;  *    slow-path interrupts) or Y+2 if CNIC is supported (one additional&#xA;  *    FP interrupt context for the CNIC).&#xA;  * e. The number of HW context (CID count) is always X or X+1 if FCoE&#xA;  *    L2 queue is supported. The cid for the FCoE L2 queue is always X.&#xA;  */&#xA;However this driver also supports NICs that use the E2 controller which can&#xA;handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.&#xA;Looking at the commits when the E2 support was added, it was originally&#xA;using the E1x parameters: commit f2e0899f0f27 (&#34;bnx2x: Add 57712 support&#34;).&#xA;Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver&#xA;was later updated to take full advantage of the E2 instead of having it be&#xA;limited to the capabilities of the E1x. But as far as we can tell, the&#xA;array &#34;stats_query_entry query&#34; was still limited to using the FP-SB&#xA;available to the E1x cards as part of an oversignt when the driver was&#xA;updated to take full advantage of the E2, and now with the driver being&#xA;aware of the greater queue size supported by E2 NICs, it causes the UBSAN&#xA;warnings seen in the stack traces below.&#xA;This patch increases the size of the &#34;stats_query_entry query&#34; array by&#xA;replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle&#xA;both types of NICs.&#xA;Stack traces:&#xA;UBSAN: array-index-out-of-bounds in&#xA;       drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11&#xA;index 20 is out of range for type &#39;stats_query_entry [19]&#39;&#xA;CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic&#xA;&#x9;     #202405052133&#xA;Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 &#xA;---truncated---</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/kernel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/kernel-headers-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/kernel-devel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/kernel-tools-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/kernel-tools-devel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/perf-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-perf-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/bpftool-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/kernel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/kernel-headers-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/kernel-devel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/kernel-tools-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/kernel-tools-devel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/perf-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-perf-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/bpftool-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2319</id>
		<title>An update for libgsf is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36474" id="CVE-2024-36474" title="CVE-2024-36474" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42415" id="CVE-2024-42415" title="CVE-2024-42415" type="cve"></reference>
		</references>
		<description>CVE-2024-36474:An integer overflow vulnerability exists in the Compound Document Binary File format parser of the GNOME Project G Structured File Library (libgsf) version v1.14.52. A specially crafted file can result in an integer overflow when processing the directory from the file that allows for an out-of-bounds index to be used when reading and writing to an array. This can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.&#xA;CVE-2024-42415:An integer overflow vulnerability exists in the Compound Document Binary File format parser of v1.14.52 of the GNOME Project G Structured File Library (libgsf). A specially crafted file can result in an integer overflow that allows for a heap-based buffer overflow when processing the sector allocation table. This can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="libgsf" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-1.14.47-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libgsf-1.14.47-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgsf-devel" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-devel-1.14.47-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libgsf-devel-1.14.47-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgsf-help" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-help-1.14.47-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libgsf-help-1.14.47-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgsf" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-1.14.47-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libgsf-1.14.47-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgsf-devel" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-devel-1.14.47-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libgsf-devel-1.14.47-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgsf-help" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-help-1.14.47-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libgsf-help-1.14.47-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2320</id>
		<title>An update for libpcap is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7256" id="CVE-2023-7256" title="CVE-2023-7256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8006" id="CVE-2024-8006" title="CVE-2024-8006" type="cve"></reference>
		</references>
		<description>CVE-2023-7256:In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns.  This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block.  A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.&#xA;CVE-2024-8006:Remote packet capture support is disabled by default in libpcap.  When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex().  One of the function arguments can be a filesystem path, which normally means a directory with input data files.  When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="14" name="libpcap" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-1.10.1-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libpcap-1.10.1-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="14" name="libpcap-devel" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-devel-1.10.1-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libpcap-devel-1.10.1-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="14" name="libpcap-help" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-help-1.10.1-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/libpcap-help-1.10.1-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="libpcap" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-1.10.1-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libpcap-1.10.1-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="libpcap-devel" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-devel-1.10.1-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/libpcap-devel-1.10.1-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2321</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46809" id="CVE-2023-46809" title="CVE-2023-46809" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22019" id="CVE-2024-22019" title="CVE-2024-22019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22025" id="CVE-2024-22025" title="CVE-2024-22025" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27982" id="CVE-2024-27982" title="CVE-2024-27982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27983" id="CVE-2024-27983" title="CVE-2024-27983" type="cve"></reference>
		</references>
		<description>CVE-2023-46809:Node.js versions which bundle an unpatched version of OpenSSL or run against a dynamically linked version of OpenSSL which are unpatched are vulnerable to the Marvin Attack - https://people.redhat.com/~hkario/marvin/, if PCKS #1 v1.5 padding is allowed when performing RSA descryption using a private key.&#xA;CVE-2024-22019:A vulnerability in Node.js HTTP servers allows an attacker to send a specially crafted HTTP request with chunked encoding, leading to resource exhaustion and denial of service (DoS). The server reads an unbounded number of bytes from a single connection, exploiting the lack of limitations on chunk extension bytes. The issue can cause CPU and network bandwidth exhaustion, bypassing standard safeguards like timeouts and body size limits.&#xA;CVE-2024-22025:A vulnerability in Node.js has been identified, allowing for a Denial of Service (DoS) attack through resource exhaustion when using the fetch() function to retrieve content from an untrusted URL.&#xA;The vulnerability stems from the fact that the fetch() function in Node.js always decodes Brotli, making it possible for an attacker to cause resource exhaustion when fetching content from an untrusted URL.&#xA;An attacker controlling the URL passed into fetch() can exploit this vulnerability to exhaust memory, potentially leading to process termination, depending on the system configuration.&#xA;CVE-2024-27982:The team has identified a critical vulnerability in the http server of the most recent version of Node, where malformed headers can lead to HTTP request smuggling. Specifically, if a space is placed before a content-length header, it is not interpreted correctly, enabling attackers to smuggle in a second request within the body of the first.&#xA;CVE-2024-27983:An attacker can make the Node.js HTTP/2 server completely unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="1" name="nodejs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/nodejs-12.22.11-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/nodejs-devel-12.22.11-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/nodejs-libs-12.22.11-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/nodejs-full-i18n-12.22.11-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.10.u5.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/v8-devel-7.8.279.23-1.12.22.11.10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.10.u5.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/npm-6.14.16-1.12.22.11.10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-docs-12.22.11-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/nodejs-docs-12.22.11-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/nodejs-12.22.11-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/nodejs-devel-12.22.11-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/nodejs-libs-12.22.11-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/nodejs-full-i18n-12.22.11-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.10.u5.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/v8-devel-7.8.279.23-1.12.22.11.10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.10.u5.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/npm-6.14.16-1.12.22.11.10.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2322</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8925" id="CVE-2024-8925" title="CVE-2024-8925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8926" id="CVE-2024-8926" title="CVE-2024-8926" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8927" id="CVE-2024-8927" title="CVE-2024-8927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9026" id="CVE-2024-9026" title="CVE-2024-9026" type="cve"></reference>
		</references>
		<description>CVE-2024-8925:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, erroneous parsing of multipart form data contained in an HTTP POST request could lead to legitimate data not being processed. This could lead to malicious attacker able to control part of the submitted data being able to exclude portion of other data, potentially leading to erroneous application behavior.&#xA;CVE-2024-8926:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, when using a certain non-standard configurations of Windows codepages, the fixes for  CVE-2024-4577 https://github.com/advisories/GHSA-vxpp-6299-mxw3  may still be bypassed and the same command injection related to Windows &#34;Best Fit&#34; codepage behavior can be achieved. This may allow a malicious user to pass options to PHP binary being run, and thus reveal the source code of scripts, run arbitrary PHP code on the server, etc.&#xA;CVE-2024-8927:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, HTTP_REDIRECT_STATUS variable is used to check whether or not CGI binary is being run by the HTTP server. However, in certain scenarios, the content of this variable can be controlled by the request submitter via HTTP headers, which can lead to cgi.force_redirect option not being correctly applied. In certain configurations this may lead to arbitrary file inclusion in PHP.&#xA;CVE-2024-9026:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, when using PHP-FPM SAPI and it is configured to catch workers output through catch_workers_output = yes, it may be possible to pollute the final log or remove up to 4 characters from the log messages by manipulating log message content. Additionally, if PHP-FPM is configured to use syslog output, it may be possible to further remove log data using the same vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="php" release="6.u4.fos23" version="8.0.30">
					<filename>php-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="6.u4.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-cli-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="6.u4.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-dbg-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="6.u4.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-fpm-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="6.u4.fos23" version="8.0.30">
					<filename>php-common-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-common-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="6.u4.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-devel-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="6.u4.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-opcache-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="6.u4.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-ldap-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="6.u4.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-pdo-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="6.u4.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-mysqlnd-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="6.u4.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-pgsql-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="6.u4.fos23" version="8.0.30">
					<filename>php-process-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-process-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="6.u4.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-odbc-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="6.u4.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-soap-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-snmp-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="6.u4.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-xml-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="6.u4.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-mbstring-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="6.u4.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-gd-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="6.u4.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-bcmath-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-gmp-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="6.u4.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-dba-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="6.u4.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-tidy-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="6.u4.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-embedded-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="6.u4.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-intl-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="6.u4.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-enchant-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="6.u4.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-sodium-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="6.u4.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-ffi-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-help" release="6.u4.fos23" version="8.0.30">
					<filename>php-help-8.0.30-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/php-help-8.0.30-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="6.u4.fos23" version="8.0.30">
					<filename>php-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="6.u4.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-cli-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="6.u4.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-dbg-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="6.u4.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-fpm-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="6.u4.fos23" version="8.0.30">
					<filename>php-common-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-common-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="6.u4.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-devel-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="6.u4.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-opcache-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="6.u4.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-ldap-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="6.u4.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-pdo-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="6.u4.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-mysqlnd-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="6.u4.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-pgsql-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="6.u4.fos23" version="8.0.30">
					<filename>php-process-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-process-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="6.u4.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-odbc-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="6.u4.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-soap-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-snmp-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="6.u4.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-xml-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="6.u4.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-mbstring-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="6.u4.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-gd-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="6.u4.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-bcmath-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-gmp-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="6.u4.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-dba-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="6.u4.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-tidy-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="6.u4.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-embedded-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="6.u4.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-intl-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="6.u4.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-enchant-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="6.u4.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-sodium-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="6.u4.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-ffi-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-help" release="6.u4.fos23" version="8.0.30">
					<filename>php-help-8.0.30-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/php-help-8.0.30-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2323</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4141" id="CVE-2024-4141" title="CVE-2024-4141" type="cve"></reference>
		</references>
		<description>CVE-2024-4141:Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by an invalid character code in a Type 1 font. The root problem was a bounds check that was being optimized away by modern compilers.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="poppler" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-devel-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-glib-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-glib-devel-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-glib-doc-0.90.0-9.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-qt5-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-qt5-devel-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-cpp-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-cpp-devel-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-utils-0.90.0-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/poppler-help-0.90.0-9.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-devel-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-glib-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-glib-devel-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-qt5-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-qt5-devel-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-cpp-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-cpp-devel-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/poppler-utils-0.90.0-9.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2324</id>
		<title>An update for python-configobj is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26112" id="CVE-2023-26112" title="CVE-2023-26112" type="cve"></reference>
		</references>
		<description>CVE-2023-26112:All versions of the package configobj are vulnerable to Regular Expression Denial of Service (ReDoS) via the validate function, using (.+?)\((.*)\).&#xA;**Note:** This is only exploitable in the case of a developer, putting the offending value in a server side configuration file.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="noarch" epoch="0" name="python3-configobj" release="20.u2.fos23" version="5.0.6">
					<filename>python3-configobj-5.0.6-20.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-configobj-5.0.6-20.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2325</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6923" id="CVE-2024-6923" title="CVE-2024-6923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7592" id="CVE-2024-7592" title="CVE-2024-7592" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8088" id="CVE-2024-8088" title="CVE-2024-8088" type="cve"></reference>
		</references>
		<description>CVE-2024-6923:There is a MEDIUM severity vulnerability affecting CPython.&#xA;The &#xA;email module didn’t properly quote newlines for email headers when &#xA;serializing an email message allowing for header injection when an email&#xA; is serialized.&#xA;CVE-2024-7592:There is a LOW severity vulnerability affecting CPython, specifically the&#xA;&#39;http.cookies&#39; standard library module.&#xA;When parsing cookies that contained backslashes for quoted characters in&#xA;the cookie value, the parser would use an algorithm with quadratic&#xA;complexity, resulting in excess CPU resources being used while parsing the&#xA;value.&#xA;CVE-2024-8088:There is a HIGH severity vulnerability affecting the CPython &#34;zipfile&#34;&#xA;module affecting &#34;zipfile.Path&#34;. Note that the more common API &#34;zipfile.ZipFile&#34; class is unaffected.&#xA;When iterating over names of entries in a zip archive (for example, methods&#xA;of &#34;zipfile.Path&#34; like &#34;namelist()&#34;, &#34;iterdir()&#34;, etc)&#xA;the process can be put into an infinite loop with a maliciously crafted&#xA;zip archive. This defect applies when reading only metadata or extracting&#xA;the contents of the zip archive. Programs that are not handling&#xA;user-controlled zip archives are not affected.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="python3" release="31.u14.fos23" version="3.9.9">
					<filename>python3-3.9.9-31.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-3.9.9-31.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="31.u14.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-31.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-unversioned-command-3.9.9-31.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="31.u14.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-31.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-devel-3.9.9-31.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="31.u14.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-31.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-debug-3.9.9-31.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="31.u14.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-31.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-help-3.9.9-31.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="31.u14.fos23" version="3.9.9">
					<filename>python3-3.9.9-31.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-3.9.9-31.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="31.u14.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-31.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-unversioned-command-3.9.9-31.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="31.u14.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-31.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-devel-3.9.9-31.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="31.u14.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-31.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-debug-3.9.9-31.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2326</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31228" id="CVE-2024-31228" title="CVE-2024-31228" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31449" id="CVE-2024-31449" title="CVE-2024-31449" type="cve"></reference>
		</references>
		<description>CVE-2024-31228:Redis is an open source, in-memory database that persists on disk. Authenticated users can trigger a denial-of-service by using specially crafted, long string match patterns on supported commands such as `KEYS`, `SCAN`, `PSUBSCRIBE`, `FUNCTION LIST`, `COMMAND LIST` and ACL definitions. Matching of extremely long patterns may result in unbounded recursion, leading to stack overflow and process crash. This problem has been fixed in Redis versions 6.2.16, 7.2.6, and 7.4.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2024-31449:Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to trigger a stack buffer overflow in the bit library, which may potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This problem has been fixed in Redis versions 6.2.16, 7.2.6, and 7.4.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/redis6-6.2.7-3.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/redis6-devel-6.2.7-3.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/redis6-doc-6.2.7-3.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/redis6-6.2.7-3.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/redis6-devel-6.2.7-3.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2327</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47220" id="CVE-2024-47220" title="CVE-2024-47220" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39908" id="CVE-2024-39908" title="CVE-2024-39908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41123" id="CVE-2024-41123" title="CVE-2024-41123" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43398" id="CVE-2024-43398" title="CVE-2024-43398" type="cve"></reference>
		</references>
		<description>CVE-2024-47220:An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., &#34;GET /admin HTTP/1.1\r\n&#34; inside of a &#34;POST /user HTTP/1.1\r\n&#34; request. NOTE: the supplier&#39;s position is &#34;Webrick should not be used in production.&#34;&#xA;CVE-2024-39908:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.1 has some DoS vulnerabilities when it parses an XML that has many specific characters such as `&lt;`, `0` and `%&gt;`. If you need to parse untrusted XMLs, you many be impacted to these vulnerabilities. The REXML gem 3.3.2 or later include the patches to fix these vulnerabilities. Users are advised to upgrade. Users unable to upgrade should avoid parsing untrusted XML strings.&#xA;CVE-2024-41123:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.2 has some DoS vulnerabilities when it parses an XML that has many specific characters such as whitespace character, `&gt;]` and `]&gt;`. The REXML gem 3.3.3 or later include the patches to fix these vulnerabilities.&#xA;CVE-2024-43398:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.6 has a DoS vulnerability when it parses an XML that has many deep elements that have same local name attributes. If you need to parse untrusted XMLs with tree parser API like REXML::Document.new, you may be impacted to this vulnerability. If you use other parser APIs such as stream parser API and SAX2 parser API, this vulnerability is not affected. The REXML gem 3.3.6 or later include the patch to fix the vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="ruby" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-3.0.3-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ruby-3.0.3-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ruby-devel-3.0.3-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="140.u14.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygems-3.2.32-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="140.u14.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygems-devel-3.2.32-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="140.u14.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-rake-13.0.3-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="140.u14.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-rbs-1.4.0-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ruby-irb-3.0.3-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="140.u14.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-rdoc-6.3.3-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/ruby-help-3.0.3-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="140.u14.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-bigdecimal-3.0.0-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="140.u14.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-did_you_mean-1.5.0-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="140.u14.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-io-console-0.5.7-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="140.u14.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-json-2.5.1-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="140.u14.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-minitest-5.14.2-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="140.u14.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-openssl-2.2.1-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="140.u14.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-140.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-psych-3.3.2-140.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="140.u14.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-test-unit-3.3.7-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="140.u14.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-rexml-3.2.5-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="140.u14.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-rss-0.2.9-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="140.u14.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-140.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-typeprof-0.15.2-140.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-3.0.3-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ruby-3.0.3-140.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/ruby-devel-3.0.3-140.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="140.u14.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/rubygem-bigdecimal-3.0.0-140.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="140.u14.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/rubygem-io-console-0.5.7-140.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="140.u14.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/rubygem-json-2.5.1-140.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="140.u14.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/rubygem-openssl-2.2.1-140.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="140.u14.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-140.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/rubygem-psych-3.3.2-140.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2328</id>
		<title>An update for rubygem-webrick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47220" id="CVE-2024-47220" title="CVE-2024-47220" type="cve"></reference>
		</references>
		<description>CVE-2024-47220:An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., &#34;GET /admin HTTP/1.1\r\n&#34; inside of a &#34;POST /user HTTP/1.1\r\n&#34; request. NOTE: the supplier&#39;s position is &#34;Webrick should not be used in production.&#34;</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="noarch" epoch="0" name="rubygem-webrick" release="2.u1.fos23" version="1.7.0">
					<filename>rubygem-webrick-1.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-webrick-1.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-webrick-help" release="2.u1.fos23" version="1.7.0">
					<filename>rubygem-webrick-help-1.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/rubygem-webrick-help-1.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2329</id>
		<title>An update for scsi-target-utils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45751" id="CVE-2024-45751" title="CVE-2024-45751" type="cve"></reference>
		</references>
		<description>CVE-2024-45751:tgt (aka Linux target framework) before 1.0.93 attempts to achieve entropy by calling rand without srand. The PRNG seed is always 1, and thus the sequence of challenges is always identical.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="scsi-target-utils" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-1.0.79-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/scsi-target-utils-1.0.79-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="scsi-target-utils-rbd" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-rbd-1.0.79-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/scsi-target-utils-rbd-1.0.79-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="scsi-target-utils-gluster" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-gluster-1.0.79-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/scsi-target-utils-gluster-1.0.79-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="scsi-target-utils-help" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-help-1.0.79-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/scsi-target-utils-help-1.0.79-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="scsi-target-utils" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-1.0.79-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/scsi-target-utils-1.0.79-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="scsi-target-utils-rbd" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-rbd-1.0.79-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/scsi-target-utils-rbd-1.0.79-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="scsi-target-utils-gluster" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-gluster-1.0.79-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/scsi-target-utils-gluster-1.0.79-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2330</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25111" id="CVE-2024-25111" title="CVE-2024-25111" type="cve"></reference>
		</references>
		<description>CVE-2024-25111:Squid is a web proxy cache. Starting in version 3.5.27 and prior to version 6.8, Squid may be vulnerable to a Denial of Service attack against HTTP Chunked decoder due to an uncontrolled recursion bug. This problem allows a remote attacker to cause Denial of Service when sending a crafted, chunked, encoded HTTP Message. This bug is fixed in Squid version 6.8. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives. There is no workaround for this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="7" name="squid" release="26.u7.fos23" version="4.9">
					<filename>squid-4.9-26.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/squid-4.9-26.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="26.u7.fos23" version="4.9">
					<filename>squid-4.9-26.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/squid-4.9-26.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2331</id>
		<title>An update for texlive-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32700" id="CVE-2023-32700" title="CVE-2023-32700" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46048" id="CVE-2023-46048" title="CVE-2023-46048" type="cve"></reference>
		</references>
		<description>CVE-2023-32700:LuaTeX before 1.17.0 allows execution of arbitrary shell commands when compiling a TeX file obtained from an untrusted source. This occurs because luatex-core.lua lets the original io.popen be accessed. This also affects TeX Live before 2023 r66984 and MiKTeX before 23.5.&#xA;CVE-2023-46048:Tex Live 944e257 has a NULL pointer dereference in texk/web2c/pdftexdir/writet1.c. NOTE: this is disputed because it should be categorized as a usability problem.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="7" name="texlive-base" release="38.u3.fos23" version="20180414">
					<filename>texlive-base-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-base-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-a2ping" release="38.u3.fos23" version="20180414">
					<filename>texlive-a2ping-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-a2ping-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-accfonts" release="38.u3.fos23" version="20180414">
					<filename>texlive-accfonts-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-accfonts-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-adhocfilelist" release="38.u3.fos23" version="20180414">
					<filename>texlive-adhocfilelist-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-adhocfilelist-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-afm2pl" release="38.u3.fos23" version="20180414">
					<filename>texlive-afm2pl-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-afm2pl-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-aleph" release="38.u3.fos23" version="20180414">
					<filename>texlive-aleph-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-aleph-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-amstex" release="38.u3.fos23" version="20180414">
					<filename>texlive-amstex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-amstex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-arara" release="38.u3.fos23" version="20180414">
					<filename>texlive-arara-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-arara-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-authorindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-authorindex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-authorindex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-autosp" release="38.u3.fos23" version="20180414">
					<filename>texlive-autosp-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-autosp-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-axodraw2" release="38.u3.fos23" version="20180414">
					<filename>texlive-axodraw2-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-axodraw2-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bib2gls" release="38.u3.fos23" version="20180414">
					<filename>texlive-bib2gls-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-bib2gls-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bibexport" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibexport-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-bibexport-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-bibtex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtexu" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtexu-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-bibtexu-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex8" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex8-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-bibtex8-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bundledoc" release="38.u3.fos23" version="20180414">
					<filename>texlive-bundledoc-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-bundledoc-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cachepic" release="38.u3.fos23" version="20180414">
					<filename>texlive-cachepic-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-cachepic-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checkcites" release="38.u3.fos23" version="20180414">
					<filename>texlive-checkcites-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-checkcites-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checklistings" release="38.u3.fos23" version="20180414">
					<filename>texlive-checklistings-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-checklistings-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-chktex" release="38.u3.fos23" version="20180414">
					<filename>texlive-chktex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-chktex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cjkutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-cjkutils-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-cjkutils-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-context" release="38.u3.fos23" version="20180414">
					<filename>texlive-context-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-context-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-convbkmk" release="38.u3.fos23" version="20180414">
					<filename>texlive-convbkmk-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-convbkmk-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-crossrefware" release="38.u3.fos23" version="20180414">
					<filename>texlive-crossrefware-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-crossrefware-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cslatex" release="38.u3.fos23" version="20180414">
					<filename>texlive-cslatex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-cslatex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-csplain" release="38.u3.fos23" version="20180414">
					<filename>texlive-csplain-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-csplain-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctan-o-mat" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctan-o-mat-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ctan-o-mat-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctanify" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctanify-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ctanify-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ctie" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctie-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ctie-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cweb" release="38.u3.fos23" version="20180414">
					<filename>texlive-cweb-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-cweb-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cyrillic" release="38.u3.fos23" version="20180414">
					<filename>texlive-cyrillic-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-cyrillic-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-de-macro" release="38.u3.fos23" version="20180414">
					<filename>texlive-de-macro-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-de-macro-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-detex" release="38.u3.fos23" version="20180414">
					<filename>texlive-detex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-detex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-diadia" release="38.u3.fos23" version="20180414">
					<filename>texlive-diadia-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-diadia-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dosepsbin" release="38.u3.fos23" version="20180414">
					<filename>texlive-dosepsbin-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dosepsbin-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dtl" release="38.u3.fos23" version="20180414">
					<filename>texlive-dtl-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dtl-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dtxgen" release="38.u3.fos23" version="20180414">
					<filename>texlive-dtxgen-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dtxgen-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvi2tty" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvi2tty-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvi2tty-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviasm" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviasm-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dviasm-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvicopy" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvicopy-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvicopy-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvidvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvidvi-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvidvi-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviinfox" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviinfox-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dviinfox-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dviljk" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviljk-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dviljk-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipdfmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipdfmx-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvipdfmx-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipng" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipng-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvipng-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipos" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipos-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvipos-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvips" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvips-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvips-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvisvgm" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvisvgm-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-dvisvgm-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ebong" release="38.u3.fos23" version="20180414">
					<filename>texlive-ebong-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ebong-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-eplain" release="38.u3.fos23" version="20180414">
					<filename>texlive-eplain-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-eplain-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epspdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-epspdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-epspdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epstopdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-epstopdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-epstopdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fig4latex" release="38.u3.fos23" version="20180414">
					<filename>texlive-fig4latex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-fig4latex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-findhyph" release="38.u3.fos23" version="20180414">
					<filename>texlive-findhyph-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-findhyph-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontinst" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontinst-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-fontinst-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontools" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontools-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-fontools-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-fontware" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontware-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-fontware-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fragmaster" release="38.u3.fos23" version="20180414">
					<filename>texlive-fragmaster-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-fragmaster-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-getmap" release="38.u3.fos23" version="20180414">
					<filename>texlive-getmap-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-getmap-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glossaries" release="38.u3.fos23" version="20180414">
					<filename>texlive-glossaries-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-glossaries-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glyphlist" release="38.u3.fos23" version="20180414">
					<filename>texlive-glyphlist-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-glyphlist-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gregoriotex" release="38.u3.fos23" version="20180414">
					<filename>texlive-gregoriotex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-gregoriotex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gsftopk" release="38.u3.fos23" version="20180414">
					<filename>texlive-gsftopk-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-gsftopk-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-installfont" release="38.u3.fos23" version="20180414">
					<filename>texlive-installfont-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-installfont-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jadetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-jadetex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-jadetex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jfmutil" release="38.u3.fos23" version="20180414">
					<filename>texlive-jfmutil-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-jfmutil-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-kotex-utils" release="38.u3.fos23" version="20180414">
					<filename>texlive-kotex-utils-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-kotex-utils-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-kpathsea" release="38.u3.fos23" version="20180414">
					<filename>texlive-kpathsea-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-kpathsea-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-l3build" release="38.u3.fos23" version="20180414">
					<filename>texlive-l3build-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-l3build-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lacheck" release="38.u3.fos23" version="20180414">
					<filename>texlive-lacheck-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lacheck-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-git-log" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex-git-log-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latex-git-log-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-papersize" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex-papersize-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latex-papersize-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2man" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex2man-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latex2man-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2nemeth" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex2nemeth-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latex2nemeth-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexdiff" release="38.u3.fos23" version="20180414">
					<filename>texlive-latexdiff-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latexdiff-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexfileversion" release="38.u3.fos23" version="20180414">
					<filename>texlive-latexfileversion-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latexfileversion-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexpand" release="38.u3.fos23" version="20180414">
					<filename>texlive-latexpand-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-latexpand-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lcdftypetools" release="38.u3.fos23" version="20180414">
					<filename>texlive-lcdftypetools-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lcdftypetools-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lib-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib-devel" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-devel-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lib-devel-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lilyglyphs" release="38.u3.fos23" version="20180414">
					<filename>texlive-lilyglyphs-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lilyglyphs-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listbib" release="38.u3.fos23" version="20180414">
					<filename>texlive-listbib-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-listbib-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listings-ext" release="38.u3.fos23" version="20180414">
					<filename>texlive-listings-ext-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-listings-ext-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lollipop" release="38.u3.fos23" version="20180414">
					<filename>texlive-lollipop-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lollipop-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltxfileinfo" release="38.u3.fos23" version="20180414">
					<filename>texlive-ltxfileinfo-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ltxfileinfo-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltximg" release="38.u3.fos23" version="20180414">
					<filename>texlive-ltximg-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ltximg-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lua2dox" release="38.u3.fos23" version="20180414">
					<filename>texlive-lua2dox-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lua2dox-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-luaotfload" release="38.u3.fos23" version="20180414">
					<filename>texlive-luaotfload-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-luaotfload-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-luatex" release="38.u3.fos23" version="20180414">
					<filename>texlive-luatex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-luatex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lwarp" release="38.u3.fos23" version="20180414">
					<filename>texlive-lwarp-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lwarp-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lyluatex" release="38.u3.fos23" version="svn47584">
					<filename>texlive-lyluatex-svn47584-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-lyluatex-svn47584-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-make4ht" release="38.u3.fos23" version="20180414">
					<filename>texlive-make4ht-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-make4ht-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-makedtx" release="38.u3.fos23" version="20180414">
					<filename>texlive-makedtx-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-makedtx-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-makeindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-makeindex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-makeindex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-match_parens" release="38.u3.fos23" version="20180414">
					<filename>texlive-match_parens-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-match_parens-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mathspic" release="38.u3.fos23" version="20180414">
					<filename>texlive-mathspic-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mathspic-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metafont" release="38.u3.fos23" version="20180414">
					<filename>texlive-metafont-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-metafont-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metapost" release="38.u3.fos23" version="20180414">
					<filename>texlive-metapost-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-metapost-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mex" release="38.u3.fos23" version="20180414">
					<filename>texlive-mex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mflua" release="38.u3.fos23" version="20180414">
					<filename>texlive-mflua-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mflua-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mfware" release="38.u3.fos23" version="20180414">
					<filename>texlive-mfware-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mfware-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mf2pt1" release="38.u3.fos23" version="20180414">
					<filename>texlive-mf2pt1-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mf2pt1-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkgrkindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-mkgrkindex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mkgrkindex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkjobtexmf" release="38.u3.fos23" version="20180414">
					<filename>texlive-mkjobtexmf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mkjobtexmf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkpic" release="38.u3.fos23" version="20180414">
					<filename>texlive-mkpic-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mkpic-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mltex" release="38.u3.fos23" version="20180414">
					<filename>texlive-mltex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mltex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mptopdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-mptopdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-mptopdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-multibibliography" release="38.u3.fos23" version="20180414">
					<filename>texlive-multibibliography-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-multibibliography-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-musixtex" release="38.u3.fos23" version="20180414">
					<filename>texlive-musixtex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-musixtex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-musixtnt" release="38.u3.fos23" version="20180414">
					<filename>texlive-musixtnt-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-musixtnt-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-m-tx" release="38.u3.fos23" version="20180414">
					<filename>texlive-m-tx-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-m-tx-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-oberdiek" release="38.u3.fos23" version="20180414">
					<filename>texlive-oberdiek-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-oberdiek-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-omegaware" release="38.u3.fos23" version="20180414">
					<filename>texlive-omegaware-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-omegaware-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-patgen" release="38.u3.fos23" version="20180414">
					<filename>texlive-patgen-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-patgen-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pax" release="38.u3.fos23" version="20180414">
					<filename>texlive-pax-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pax-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfbook2" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfbook2-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdfbook2-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfcrop" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfcrop-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdfcrop-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfjam" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfjam-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdfjam-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdflatexpicscale" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdflatexpicscale-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdflatexpicscale-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdftex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftools-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdftools-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfxup" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfxup-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pdfxup-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pedigree-perl" release="38.u3.fos23" version="20180414">
					<filename>texlive-pedigree-perl-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pedigree-perl-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-perltex" release="38.u3.fos23" version="20180414">
					<filename>texlive-perltex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-perltex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-petri-nets" release="38.u3.fos23" version="20180414">
					<filename>texlive-petri-nets-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-petri-nets-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pfarrei" release="38.u3.fos23" version="20180414">
					<filename>texlive-pfarrei-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pfarrei-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix" release="38.u3.fos23" version="20180414">
					<filename>texlive-pkfix-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pkfix-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix-helper" release="38.u3.fos23" version="20180414">
					<filename>texlive-pkfix-helper-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pkfix-helper-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-pmx-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pmx-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pmxchords" release="38.u3.fos23" version="20180414">
					<filename>texlive-pmxchords-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pmxchords-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pstools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pstools-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pstools-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst2pdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-pst2pdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pst2pdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst-pdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-pst-pdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pst-pdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ps2pk" release="38.u3.fos23" version="20180414">
					<filename>texlive-ps2pk-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ps2pk-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ptex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex-fontmaps" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex-fontmaps-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ptex-fontmaps-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex2pdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex2pdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ptex2pdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-purifyeps" release="38.u3.fos23" version="20180414">
					<filename>texlive-purifyeps-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-purifyeps-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pygmentex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pygmentex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pygmentex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pythontex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pythontex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-pythontex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-rubik" release="38.u3.fos23" version="20180414">
					<filename>texlive-rubik-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-rubik-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-seetexk" release="38.u3.fos23" version="20180414">
					<filename>texlive-seetexk-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-seetexk-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-splitindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-splitindex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-splitindex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-srcredact" release="38.u3.fos23" version="20180414">
					<filename>texlive-srcredact-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-srcredact-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-sty2dtx" release="38.u3.fos23" version="20180414">
					<filename>texlive-sty2dtx-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-sty2dtx-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-svn-multi" release="38.u3.fos23" version="20180414">
					<filename>texlive-svn-multi-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-svn-multi-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-synctex" release="38.u3.fos23" version="20180414">
					<filename>texlive-synctex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-synctex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tetex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-tetex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-tex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tex4ebook" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex4ebook-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-tex4ebook-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex4ht" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex4ht-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-tex4ht-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texconfig" release="38.u3.fos23" version="20180414">
					<filename>texlive-texconfig-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texconfig-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texcount" release="38.u3.fos23" version="20180414">
					<filename>texlive-texcount-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texcount-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdef" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdef-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texdef-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdiff" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdiff-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texdiff-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdirflatten" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdirflatten-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texdirflatten-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoc" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdoc-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texdoc-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoctk" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdoctk-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texdoctk-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texfot" release="38.u3.fos23" version="20180414">
					<filename>texlive-texfot-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texfot-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texliveonfly" release="38.u3.fos23" version="20180414">
					<filename>texlive-texliveonfly-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texliveonfly-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-en" release="38.u3.fos23" version="20180414">
					<filename>texlive-texlive-en-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texlive-en-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-scripts" release="38.u3.fos23" version="20180414">
					<filename>texlive-texlive-scripts-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texlive-scripts-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive.infra" release="38.u3.fos23" version="20180414">
					<filename>texlive-texlive.infra-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texlive.infra-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texloganalyser" release="38.u3.fos23" version="20180414">
					<filename>texlive-texloganalyser-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texloganalyser-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texosquery" release="38.u3.fos23" version="20180414">
					<filename>texlive-texosquery-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texosquery-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texsis" release="38.u3.fos23" version="20180414">
					<filename>texlive-texsis-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texsis-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-texware" release="38.u3.fos23" version="20180414">
					<filename>texlive-texware-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-texware-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-thumbpdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-thumbpdf-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-thumbpdf-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tie" release="38.u3.fos23" version="20180414">
					<filename>texlive-tie-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-tie-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tpic2pdftex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tpic2pdftex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-tpic2pdftex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ttfutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-ttfutils-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ttfutils-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-typeoutfileinfo" release="38.u3.fos23" version="20180414">
					<filename>texlive-typeoutfileinfo-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-typeoutfileinfo-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ulqda" release="38.u3.fos23" version="20180414">
					<filename>texlive-ulqda-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-ulqda-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-uptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-uptex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-uptex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-urlbst" release="38.u3.fos23" version="20180414">
					<filename>texlive-urlbst-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-urlbst-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-velthuis" release="38.u3.fos23" version="20180414">
					<filename>texlive-velthuis-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-velthuis-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-vlna" release="38.u3.fos23" version="20180414">
					<filename>texlive-vlna-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-vlna-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-vpe" release="38.u3.fos23" version="20180414">
					<filename>texlive-vpe-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-vpe-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-web" release="38.u3.fos23" version="20180414">
					<filename>texlive-web-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-web-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-wordcount" release="38.u3.fos23" version="20180414">
					<filename>texlive-wordcount-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-wordcount-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xdvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-xdvi-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-xdvi-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-xetex-20180414-38.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-xetex-20180414-38.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-xmltex" release="38.u3.fos23" version="20180414">
					<filename>texlive-xmltex-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-xmltex-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-yplan" release="38.u3.fos23" version="20180414">
					<filename>texlive-yplan-20180414-38.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/texlive-yplan-20180414-38.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-base" release="38.u3.fos23" version="20180414">
					<filename>texlive-base-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-base-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-afm2pl" release="38.u3.fos23" version="20180414">
					<filename>texlive-afm2pl-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-afm2pl-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-aleph" release="38.u3.fos23" version="20180414">
					<filename>texlive-aleph-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-aleph-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-autosp" release="38.u3.fos23" version="20180414">
					<filename>texlive-autosp-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-autosp-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-axodraw2" release="38.u3.fos23" version="20180414">
					<filename>texlive-axodraw2-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-axodraw2-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-bibtex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtexu" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtexu-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-bibtexu-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex8" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex8-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-bibtex8-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-chktex" release="38.u3.fos23" version="20180414">
					<filename>texlive-chktex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-chktex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cjkutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-cjkutils-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-cjkutils-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ctie" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctie-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-ctie-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cweb" release="38.u3.fos23" version="20180414">
					<filename>texlive-cweb-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-cweb-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-detex" release="38.u3.fos23" version="20180414">
					<filename>texlive-detex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-detex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dtl" release="38.u3.fos23" version="20180414">
					<filename>texlive-dtl-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dtl-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvi2tty" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvi2tty-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvi2tty-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvicopy" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvicopy-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvicopy-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvidvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvidvi-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvidvi-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dviljk" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviljk-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dviljk-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipdfmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipdfmx-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvipdfmx-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipng" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipng-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvipng-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipos" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipos-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvipos-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvips" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvips-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvips-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvisvgm" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvisvgm-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-dvisvgm-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-fontware" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontware-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-fontware-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gregoriotex" release="38.u3.fos23" version="20180414">
					<filename>texlive-gregoriotex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-gregoriotex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gsftopk" release="38.u3.fos23" version="20180414">
					<filename>texlive-gsftopk-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-gsftopk-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-kpathsea" release="38.u3.fos23" version="20180414">
					<filename>texlive-kpathsea-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-kpathsea-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lacheck" release="38.u3.fos23" version="20180414">
					<filename>texlive-lacheck-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-lacheck-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lcdftypetools" release="38.u3.fos23" version="20180414">
					<filename>texlive-lcdftypetools-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-lcdftypetools-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-lib-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib-devel" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-devel-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-lib-devel-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-luatex" release="38.u3.fos23" version="20180414">
					<filename>texlive-luatex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-luatex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-makeindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-makeindex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-makeindex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metafont" release="38.u3.fos23" version="20180414">
					<filename>texlive-metafont-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-metafont-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metapost" release="38.u3.fos23" version="20180414">
					<filename>texlive-metapost-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-metapost-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mflua" release="38.u3.fos23" version="20180414">
					<filename>texlive-mflua-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-mflua-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mfware" release="38.u3.fos23" version="20180414">
					<filename>texlive-mfware-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-mfware-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-musixtnt" release="38.u3.fos23" version="20180414">
					<filename>texlive-musixtnt-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-musixtnt-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-m-tx" release="38.u3.fos23" version="20180414">
					<filename>texlive-m-tx-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-m-tx-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-omegaware" release="38.u3.fos23" version="20180414">
					<filename>texlive-omegaware-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-omegaware-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-patgen" release="38.u3.fos23" version="20180414">
					<filename>texlive-patgen-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-patgen-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-pdftex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftools-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-pdftools-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-pmx-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-pmx-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pstools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pstools-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-pstools-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ps2pk" release="38.u3.fos23" version="20180414">
					<filename>texlive-ps2pk-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-ps2pk-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-ptex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-seetexk" release="38.u3.fos23" version="20180414">
					<filename>texlive-seetexk-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-seetexk-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-synctex" release="38.u3.fos23" version="20180414">
					<filename>texlive-synctex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-synctex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-tex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex4ht" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex4ht-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-tex4ht-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-texware" release="38.u3.fos23" version="20180414">
					<filename>texlive-texware-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-texware-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tie" release="38.u3.fos23" version="20180414">
					<filename>texlive-tie-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-tie-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ttfutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-ttfutils-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-ttfutils-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-uptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-uptex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-uptex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-velthuis" release="38.u3.fos23" version="20180414">
					<filename>texlive-velthuis-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-velthuis-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-vlna" release="38.u3.fos23" version="20180414">
					<filename>texlive-vlna-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-vlna-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-web" release="38.u3.fos23" version="20180414">
					<filename>texlive-web-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-web-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xdvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-xdvi-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-xdvi-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-xetex-20180414-38.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/texlive-xetex-20180414-38.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2332</id>
		<title>An update for uboot-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2347" id="CVE-2022-2347" title="CVE-2022-2347" type="cve"></reference>
		</references>
		<description>CVE-2022-2347:There exists an unchecked length field in UBoot. The U-Boot DFU implementation does not bound the length field in USB DFU download setup packets, and it does not verify that the transfer direction corresponds to the specified command. Consequently, if a physical attacker crafts a USB DFU download setup packet with a `wLength` greater than 4096 bytes, they can write beyond the heap-allocated request buffer.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="uboot-tools" release="8.u1.fos23" version="2021.10">
					<filename>uboot-tools-2021.10-8.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/uboot-tools-2021.10-8.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uboot-tools-help" release="8.u1.fos23" version="2021.10">
					<filename>uboot-tools-help-2021.10-8.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/uboot-tools-help-2021.10-8.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-tools" release="8.u1.fos23" version="2021.10">
					<filename>uboot-tools-2021.10-8.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/uboot-tools-2021.10-8.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2333</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8508" id="CVE-2024-8508" title="CVE-2024-8508" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33655" id="CVE-2024-33655" title="CVE-2024-33655" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43168" id="CVE-2024-43168" title="CVE-2024-43168" type="cve"></reference>
		</references>
		<description>CVE-2024-8508:NLnet Labs Unbound up to and including version 1.21.0 contains a vulnerability when handling replies with very large RRsets that it needs to perform name compression for. Malicious upstreams responses with very large RRsets can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. The vulnerability can be exploited by a malicious actor querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long. This change should not affect normal DNS traffic.&#xA;CVE-2024-33655:The DNS protocol in RFC 1035 and updates allows remote attackers to cause a denial of service (resource consumption) by arranging for DNS queries to be accumulated for seconds, such that responses are later sent in a pulsing burst (which can be considered traffic amplification in some cases), aka the &#34;DNSBomb&#34; issue.&#xA;CVE-2024-43168:DISPUTE NOTE: this issue does not pose a security risk as it (according to analysis by the original software developer, NLnet Labs) falls within the expected functionality and security controls of the application. Red Hat has made a claim that there is a security risk within Red Hat products. NLnet Labs has no further information about the claim, and suggests that affected Red Hat customers refer to available Red Hat documentation or support channels. ORIGINAL DESCRIPTION: A heap-buffer-overflow flaw was found in the cfg_mark_ports function within Unbound&#39;s config_file.c, which can lead to memory corruption. This issue could allow an attacker with local access to provide specially crafted input, potentially causing the application to crash or allowing arbitrary code execution. This could result in a denial of service or unauthorized actions on the system.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="unbound" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-1.13.2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/unbound-1.13.2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/unbound-libs-1.13.2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/unbound-devel-1.13.2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="15.u8.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/python3-unbound-1.13.2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/unbound-help-1.13.2-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-1.13.2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/unbound-1.13.2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/unbound-libs-1.13.2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/unbound-devel-1.13.2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="15.u8.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/python3-unbound-1.13.2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/unbound-help-1.13.2-15.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2334</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8645" id="CVE-2024-8645" title="CVE-2024-8645" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24476" id="CVE-2024-24476" title="CVE-2024-24476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8250" id="CVE-2024-8250" title="CVE-2024-8250" type="cve"></reference>
		</references>
		<description>CVE-2024-8645:SPRT dissector crash in Wireshark 4.2.0 to 4.0.5 and 4.0.0 to 4.0.15 allows denial of service via packet injection or crafted capture file&#xA;CVE-2024-24476:A buffer overflow in Wireshark before 4.2.0 allows a remote attacker to cause a denial of service via the pan/addr_resolv.c, and ws_manuf_lookup_str(), size components. NOTE: this is disputed by the vendor because neither release 4.2.0 nor any other release was affected.&#xA;CVE-2024-8250:NTLMSSP dissector crash in Wireshark 4.2.0 to 4.0.6 and 4.0.0 to 4.0.16 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-11.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/wireshark-3.6.14-11.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-11.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/wireshark-devel-3.6.14-11.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-11.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/wireshark-help-3.6.14-11.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-11.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/wireshark-3.6.14-11.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-11.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/wireshark-devel-3.6.14-11.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-11.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/wireshark-help-3.6.14-11.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2335</id>
		<title>An update for wpa_supplicant is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5290" id="CVE-2024-5290" title="CVE-2024-5290" type="cve"></reference>
		</references>
		<description>CVE-2024-5290:An issue was discovered in Ubuntu wpa_supplicant that resulted in loading of arbitrary shared objects, which allows a local unprivileged attacker to escalate privileges to the user that wpa_supplicant runs as (usually root).&#xA;Membership in the netdev group or access to the dbus interface of wpa_supplicant allow an unprivileged user to specify an arbitrary path to a module to be loaded by the wpa_supplicant process; other escalation paths might exist.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="1" name="wpa_supplicant" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-2.6-32.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/wpa_supplicant-2.6-32.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-gui" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-gui-2.6-32.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/wpa_supplicant-gui-2.6-32.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-help" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-help-2.6-32.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/wpa_supplicant-help-2.6-32.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-2.6-32.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/wpa_supplicant-2.6-32.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-gui" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-gui-2.6-32.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/wpa_supplicant-gui-2.6-32.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-help" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-help-2.6-32.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/wpa_supplicant-help-2.6-32.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2336</id>
		<title>An update for xmlrpc-c is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45490" id="CVE-2024-45490" title="CVE-2024-45490" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45491" id="CVE-2024-45491" title="CVE-2024-45491" type="cve"></reference>
		</references>
		<description>CVE-2024-45490:An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.&#xA;CVE-2024-45491:An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="xmlrpc-c" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-1.51.08-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/xmlrpc-c-1.51.08-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xmlrpc-c-devel" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-devel-1.51.08-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/xmlrpc-c-devel-1.51.08-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xmlrpc-c-help" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-help-1.51.08-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/xmlrpc-c-help-1.51.08-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xmlrpc-c" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-1.51.08-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/xmlrpc-c-1.51.08-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xmlrpc-c-devel" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-devel-1.51.08-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/xmlrpc-c-devel-1.51.08-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2024-2337</id>
		<title>An update for xterm is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2024-11-15"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45063" id="CVE-2022-45063" title="CVE-2022-45063" type="cve"></reference>
		</references>
		<description>CVE-2022-45063:xterm before 375 allows code execution via font ops, e.g., because an OSC 50 response may have Ctrl-g and therefore lead to command execution within the vi line-editing mode of Zsh. NOTE: font ops are not allowed in the xterm default configurations of some Linux distributions.</description>
		<pkglist>
			<collection>
				<name>23.1.3.2</name>
				<package arch="x86_64" epoch="0" name="xterm" release="6.u2.fos23" version="363">
					<filename>xterm-363-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/xterm-363-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xterm-help" release="6.u2.fos23" version="363">
					<filename>xterm-help-363-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.3.2/xterm-help-363-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xterm" release="6.u2.fos23" version="363">
					<filename>xterm-363-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/xterm-363-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xterm-help" release="6.u2.fos23" version="363">
					<filename>xterm-help-363-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.3.2/xterm-help-363-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2001</id>
		<title>An update for NetworkManager-libreswan is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9050" id="CVE-2024-9050" title="CVE-2024-9050" type="cve"></reference>
		</references>
		<description>CVE-2024-9050:A flaw was found in the libreswan client plugin for NetworkManager (NetkworkManager-libreswan), where it fails to properly sanitize the VPN configuration from the local unprivileged user. In this configuration, composed by a key-value format, the plugin fails to escape special characters, leading the application to interpret values as keys. One of the most critical parameters that could be abused by a malicious user is the `leftupdown`key. This key takes an executable command as a value and is used to specify what executes as a callback in NetworkManager-libreswan to retrieve configuration settings back to NetworkManager. As NetworkManager uses Polkit to allow an unprivileged user to control the system&#39;s network configuration, a malicious actor could achieve local privilege escalation and potential code execution as root in the targeted machine by creating a malicious configuration.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="NetworkManager-libreswan" release="1.fos23" version="1.2.24">
					<filename>NetworkManager-libreswan-1.2.24-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/NetworkManager-libreswan-1.2.24-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="NetworkManager-libreswan-gnome" release="1.fos23" version="1.2.24">
					<filename>NetworkManager-libreswan-gnome-1.2.24-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/NetworkManager-libreswan-gnome-1.2.24-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="NetworkManager-libreswan" release="1.fos23" version="1.2.24">
					<filename>NetworkManager-libreswan-1.2.24-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/NetworkManager-libreswan-1.2.24-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="NetworkManager-libreswan-gnome" release="1.fos23" version="1.2.24">
					<filename>NetworkManager-libreswan-gnome-1.2.24-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/NetworkManager-libreswan-gnome-1.2.24-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2002</id>
		<title>An update for ansible is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8775" id="CVE-2024-8775" title="CVE-2024-8775" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9902" id="CVE-2024-9902" title="CVE-2024-9902" type="cve"></reference>
		</references>
		<description>CVE-2024-8775:A flaw was found in Ansible, where sensitive information stored in Ansible Vault files can be exposed in plaintext during the execution of a playbook. This occurs when using tasks such as include_vars to load vaulted variables without setting the no_log: true parameter, resulting in sensitive data being printed in the playbook output or logs. This can lead to the unintentional disclosure of secrets like passwords or API keys, compromising security and potentially allowing unauthorized access or actions.&#xA;CVE-2024-9902:A flaw was found in Ansible. The ansible-core `user` module can allow an unprivileged user to silently create or replace the contents of any file on any system path and take ownership of it when a privileged user executes the `user` module against the unprivileged user&#39;s home directory. If the unprivileged user has traversal permissions on the directory containing the exploited target file, they retain full control over the contents of the file as its owner.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="ansible" release="5.u6.fos23" version="2.9.27">
					<filename>ansible-2.9.27-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ansible-2.9.27-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ansible-help" release="5.u6.fos23" version="2.9.27">
					<filename>ansible-help-2.9.27-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ansible-help-2.9.27-5.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2003</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-48425" id="CVE-2024-48425" title="CVE-2024-48425" type="cve"></reference>
		</references>
		<description>CVE-2024-48425:A segmentation fault (SEGV) was detected in the Assimp::SplitLargeMeshesProcess_Triangle::UpdateNode function within the Assimp library during fuzz testing using AddressSanitizer. The crash occurs due to a read access violation at address 0x000000000460, which points to the zero page, indicating a null or invalid pointer dereference.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="assimp" release="4.u3.fos23" version="5.2.4">
					<filename>assimp-5.2.4-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/assimp-5.2.4-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="4.u3.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/assimp-devel-5.2.4-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-assimp" release="4.u3.fos23" version="5.2.4">
					<filename>python3-assimp-5.2.4-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-assimp-5.2.4-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="assimp-help" release="4.u3.fos23" version="5.2.4">
					<filename>assimp-help-5.2.4-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/assimp-help-5.2.4-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp" release="4.u3.fos23" version="5.2.4">
					<filename>assimp-5.2.4-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/assimp-5.2.4-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="4.u3.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/assimp-devel-5.2.4-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2004</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53589" id="CVE-2024-53589" title="CVE-2024-53589" type="cve"></reference>
		</references>
		<description>CVE-2024-53589:GNU objdump 2.43 is vulnerable to Buffer Overflow in the BFD (Binary File Descriptor) library&#39;s handling of tekhex format files.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="binutils" release="26.u13.fos23" version="2.37">
					<filename>binutils-2.37-26.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/binutils-2.37-26.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="26.u13.fos23" version="2.37">
					<filename>binutils-devel-2.37-26.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/binutils-devel-2.37-26.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="26.u13.fos23" version="2.37">
					<filename>binutils-help-2.37-26.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/binutils-help-2.37-26.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="26.u13.fos23" version="2.37">
					<filename>binutils-2.37-26.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/binutils-2.37-26.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="26.u13.fos23" version="2.37">
					<filename>binutils-devel-2.37-26.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/binutils-devel-2.37-26.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="26.u13.fos23" version="2.37">
					<filename>binutils-help-2.37-26.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/binutils-help-2.37-26.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2005</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-48916" id="CVE-2024-48916" title="CVE-2024-48916" type="cve"></reference>
		</references>
		<description>CVE-2024-48916:A vulnerability in the Ceph Rados Gateway (RadosGW) OIDC provider allows attackers to bypass JWT signature verification by supplying a token with &#34;none&#34; as the algorithm (alg). This occurs because the implementation fails to enforce strict signature validation, enabling attackers to forge valid tokens without a signature.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="2" name="ceph" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-base" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-base-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephadm" release="21.u11.fos23" version="16.2.7">
					<filename>cephadm-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cephadm-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-common" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-common-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mds" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mds-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mon" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mon-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mgr" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-dashboard" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-dashboard-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-dashboard-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-diskprediction-local" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-diskprediction-local-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-diskprediction-local-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-modules-core" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-modules-core-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-modules-core-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-rook" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-rook-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-rook-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-k8sevents" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-k8sevents-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-k8sevents-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-cephadm" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-cephadm-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-mgr-cephadm-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-fuse" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-fuse-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="cephfs-mirror" release="21.u11.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cephfs-mirror-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-fuse" release="21.u11.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rbd-fuse-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-mirror" release="21.u11.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rbd-mirror-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-immutable-object-cache" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-immutable-object-cache-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-nbd" release="21.u11.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rbd-nbd-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-radosgw" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-radosgw-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephfs-top" release="21.u11.fos23" version="16.2.7">
					<filename>cephfs-top-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cephfs-top-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-resource-agents" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-resource-agents-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-osd" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-osd-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados2" release="21.u11.fos23" version="16.2.7">
					<filename>librados2-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/librados2-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados-devel" release="21.u11.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/librados-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradospp-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libradospp-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw2" release="21.u11.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/librgw2-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw-devel" release="21.u11.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/librgw-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rgw" release="21.u11.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-rgw-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rados" release="21.u11.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-rados-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite" release="21.u11.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libcephsqlite-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libcephsqlite-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper1" release="21.u11.fos23" version="16.2.7">
					<filename>libradosstriper1-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libradosstriper1-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libradosstriper-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd1" release="21.u11.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/librbd1-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd-devel" release="21.u11.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/librbd-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rbd" release="21.u11.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-rbd-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs2" release="21.u11.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libcephfs2-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libcephfs-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-cephfs" release="21.u11.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-cephfs-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-argparse" release="21.u11.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-ceph-argparse-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-common" release="21.u11.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-ceph-common-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-test" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-test-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rados-objclass-devel" release="21.u11.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rados-objclass-devel-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-selinux" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-selinux-16.2.7-21.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-selinux-16.2.7-21.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-grafana-dashboards" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-grafana-dashboards-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-grafana-dashboards-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-prometheus-alerts" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-prometheus-alerts-16.2.7-21.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ceph-prometheus-alerts-16.2.7-21.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-base" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-base-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-base-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-common" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-common-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-common-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mds" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mds-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-mds-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mon" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mon-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-mon-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mgr" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-mgr-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-mgr-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-fuse" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-fuse-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-fuse-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="cephfs-mirror" release="21.u11.fos23" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cephfs-mirror-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-fuse" release="21.u11.fos23" version="16.2.7">
					<filename>rbd-fuse-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rbd-fuse-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-mirror" release="21.u11.fos23" version="16.2.7">
					<filename>rbd-mirror-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rbd-mirror-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-immutable-object-cache" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-immutable-object-cache-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-nbd" release="21.u11.fos23" version="16.2.7">
					<filename>rbd-nbd-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rbd-nbd-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-radosgw" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-radosgw-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-resource-agents" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-resource-agents-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-osd" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-osd-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-osd-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados2" release="21.u11.fos23" version="16.2.7">
					<filename>librados2-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/librados2-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados-devel" release="21.u11.fos23" version="16.2.7">
					<filename>librados-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/librados-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradospp-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libradospp-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libradospp-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw2" release="21.u11.fos23" version="16.2.7">
					<filename>librgw2-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/librgw2-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw-devel" release="21.u11.fos23" version="16.2.7">
					<filename>librgw-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/librgw-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rgw" release="21.u11.fos23" version="16.2.7">
					<filename>python3-rgw-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-rgw-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rados" release="21.u11.fos23" version="16.2.7">
					<filename>python3-rados-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-rados-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite" release="21.u11.fos23" version="16.2.7">
					<filename>libcephsqlite-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libcephsqlite-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libcephsqlite-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper1" release="21.u11.fos23" version="16.2.7">
					<filename>libradosstriper1-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libradosstriper1-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libradosstriper-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd1" release="21.u11.fos23" version="16.2.7">
					<filename>librbd1-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/librbd1-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd-devel" release="21.u11.fos23" version="16.2.7">
					<filename>librbd-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/librbd-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rbd" release="21.u11.fos23" version="16.2.7">
					<filename>python3-rbd-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-rbd-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs2" release="21.u11.fos23" version="16.2.7">
					<filename>libcephfs2-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libcephfs2-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs-devel" release="21.u11.fos23" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libcephfs-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-cephfs" release="21.u11.fos23" version="16.2.7">
					<filename>python3-cephfs-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-cephfs-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-argparse" release="21.u11.fos23" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-ceph-argparse-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-common" release="21.u11.fos23" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-ceph-common-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-test" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-test-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-test-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rados-objclass-devel" release="21.u11.fos23" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rados-objclass-devel-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-selinux" release="21.u11.fos23" version="16.2.7">
					<filename>ceph-selinux-16.2.7-21.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ceph-selinux-16.2.7-21.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2006</id>
		<title>An update for clamav is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20505" id="CVE-2024-20505" title="CVE-2024-20505" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20506" id="CVE-2024-20506" title="CVE-2024-20506" type="cve"></reference>
		</references>
		<description>CVE-2024-20505:A vulnerability in the PDF parsing module of Clam AntiVirus (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6 and prior versions, all 0.105.x versions, all 0.104.x versions, and 0.103.11 and all prior versions could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.&#xA;The vulnerability is due to an out of bounds read. An attacker could exploit this vulnerability by submitting a crafted PDF file to be scanned by ClamAV on an affected device. An exploit could allow the attacker to terminate the scanning process.&#xA;CVE-2024-20506:A vulnerability in the ClamD service module of Clam AntiVirus (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6 and prior versions, all 0.105.x versions, all 0.104.x versions, and 0.103.11 and all prior versions could allow an authenticated, local attacker to corrupt critical system files.&#xA;The vulnerability is due to allowing the ClamD process to write to its log file while privileged without checking if the logfile has been replaced with a symbolic link. An attacker could exploit this vulnerability if they replace the ClamD log file with a symlink to a critical system file and then find a way to restart the ClamD process. An exploit could allow the attacker to corrupt a critical system file by appending ClamD log messages after restart.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="clamav" release="1.fos23" version="0.103.12">
					<filename>clamav-0.103.12-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-0.103.12-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-devel" release="1.fos23" version="0.103.12">
					<filename>clamav-devel-0.103.12-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-devel-0.103.12-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-help" release="1.fos23" version="0.103.12">
					<filename>clamav-help-0.103.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-help-0.103.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-filesystem" release="1.fos23" version="0.103.12">
					<filename>clamav-filesystem-0.103.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-filesystem-0.103.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-data" release="1.fos23" version="0.103.12">
					<filename>clamav-data-0.103.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-data-0.103.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-update" release="1.fos23" version="0.103.12">
					<filename>clamav-update-0.103.12-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-update-0.103.12-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamd" release="1.fos23" version="0.103.12">
					<filename>clamd-0.103.12-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamd-0.103.12-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-milter" release="1.fos23" version="0.103.12">
					<filename>clamav-milter-0.103.12-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/clamav-milter-0.103.12-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav" release="1.fos23" version="0.103.12">
					<filename>clamav-0.103.12-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/clamav-0.103.12-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-devel" release="1.fos23" version="0.103.12">
					<filename>clamav-devel-0.103.12-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/clamav-devel-0.103.12-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-update" release="1.fos23" version="0.103.12">
					<filename>clamav-update-0.103.12-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/clamav-update-0.103.12-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamd" release="1.fos23" version="0.103.12">
					<filename>clamd-0.103.12-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/clamd-0.103.12-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-milter" release="1.fos23" version="0.103.12">
					<filename>clamav-milter-0.103.12-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/clamav-milter-0.103.12-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2007</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35235" id="CVE-2024-35235" title="CVE-2024-35235" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47175" id="CVE-2024-47175" title="CVE-2024-47175" type="cve"></reference>
		</references>
		<description>CVE-2024-35235:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.&#xA;CVE-2024-47175:CUPS is a standards-based, open-source printing system, and `libppd` can be used for legacy PPD file support. The `libppd` function `ppdCreatePPDFromIPP2` does not sanitize IPP attributes when creating the PPD buffer. When used in combination with other functions such as `cfGetPrinterAttributes5`, can result in user controlled input and ultimately code execution via Foomatic. This vulnerability can be part of an exploit chain leading to remote code execution (RCE), as described in CVE-2024-47176.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="1" name="cups" release="14.u6.fos23" version="2.4.0">
					<filename>cups-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="14.u6.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-client-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="14.u6.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-devel-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="14.u6.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-libs-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="14.u6.fos23" version="2.4.0">
					<filename>cups-filesystem-2.4.0-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-filesystem-2.4.0-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="14.u6.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-lpd-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="14.u6.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-ipptool-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="14.u6.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-14.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-printerapp-2.4.0-14.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="14.u6.fos23" version="2.4.0">
					<filename>cups-help-2.4.0-14.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-help-2.4.0-14.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="14.u6.fos23" version="2.4.0">
					<filename>cups-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="14.u6.fos23" version="2.4.0">
					<filename>cups-client-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-client-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="14.u6.fos23" version="2.4.0">
					<filename>cups-devel-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-devel-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="14.u6.fos23" version="2.4.0">
					<filename>cups-libs-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-libs-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="14.u6.fos23" version="2.4.0">
					<filename>cups-lpd-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-lpd-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="14.u6.fos23" version="2.4.0">
					<filename>cups-ipptool-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-ipptool-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="14.u6.fos23" version="2.4.0">
					<filename>cups-printerapp-2.4.0-14.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-printerapp-2.4.0-14.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2008</id>
		<title>An update for cups-filters is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47850" id="CVE-2024-47850" title="CVE-2024-47850" type="cve"></reference>
		</references>
		<description>CVE-2024-47850:CUPS cups-browsed before 2.5b1 will send an HTTP POST request to an arbitrary destination and port in response to a single IPP UDP packet requesting a printer to be added, a different vulnerability than CVE-2024-47176. (The request is meant to probe the new printer but can be used to create DDoS amplification attacks.)</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="cups-filters" release="5.u3.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-filters-1.28.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters-devel" release="5.u3.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-filters-devel-1.28.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cups-filters-help" release="5.u3.fos23" version="1.28.9">
					<filename>cups-filters-help-1.28.9-5.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/cups-filters-help-1.28.9-5.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters" release="5.u3.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-filters-1.28.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters-devel" release="5.u3.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/cups-filters-devel-1.28.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2009</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9681" id="CVE-2024-9681" title="CVE-2024-9681" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11053" id="CVE-2024-11053" title="CVE-2024-11053" type="cve"></reference>
		</references>
		<description>CVE-2024-9681:When curl is asked to use HSTS, the expiry time for a subdomain might&#xA;overwrite a parent domain&#39;s cache entry, making it end sooner or later than&#xA;otherwise intended.&#xA;This affects curl using applications that enable HSTS and use URLs with the&#xA;insecure `HTTP://` scheme and perform transfers with hosts like&#xA;`x.example.com` as well as `example.com` where the first host is a subdomain&#xA;of the second host.&#xA;(The HSTS cache either needs to have been populated manually or there needs to&#xA;have been previous HTTPS accesses done as the cache needs to have entries for&#xA;the domains involved to trigger this problem.)&#xA;When `x.example.com` responds with `Strict-Transport-Security:` headers, this&#xA;bug can make the subdomain&#39;s expiry timeout *bleed over* and get set for the&#xA;parent domain `example.com` in curl&#39;s HSTS cache.&#xA;The result of a triggered bug is that HTTP accesses to `example.com` get&#xA;converted to HTTPS for a different period of time than what was asked for by&#xA;the origin server. If `example.com` for example stops supporting HTTPS at its&#xA;expiry time, curl might then fail to access `http://example.com` until the&#xA;(wrongly set) timeout expires. This bug can also expire the parent&#39;s entry&#xA;*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier&#xA;than otherwise intended.&#xA;CVE-2024-11053:When asked to both use a `.netrc` file for credentials and to follow HTTP&#xA;redirects, curl could leak the password used for the first host to the&#xA;followed-to host under certain circumstances.&#xA;This flaw only manifests itself if the netrc file has an entry that matches&#xA;the redirect target hostname but the entry either omits just the password or&#xA;omits both login and password.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="curl" release="34.u21.fos23" version="7.79.1">
					<filename>curl-7.79.1-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/curl-7.79.1-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="34.u21.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libcurl-7.79.1-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="34.u21.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libcurl-devel-7.79.1-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="34.u21.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-34.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/curl-help-7.79.1-34.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="34.u21.fos23" version="7.79.1">
					<filename>curl-7.79.1-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/curl-7.79.1-34.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="34.u21.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libcurl-7.79.1-34.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="34.u21.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libcurl-devel-7.79.1-34.u21.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2010</id>
		<title>An update for dpdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11614" id="CVE-2024-11614" title="CVE-2024-11614" type="cve"></reference>
		</references>
		<description>CVE-2024-11614:An out-of-bounds read vulnerability was found in DPDK&#39;s Vhost library checksum offload feature. This issue enables an untrusted or compromised guest to crash the hypervisor&#39;s vSwitch by forging Virtio descriptors to cause out-of-bounds reads. This flaw allows an attacker with a malicious VM using a virtio driver to cause the vhost-user side to crash by sending a packet with a Tx checksum offload request and an invalid csum_start offset.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="dpdk" release="81.u16.fos23" version="21.11">
					<filename>dpdk-21.11-81.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/dpdk-21.11-81.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="dpdk-devel" release="81.u16.fos23" version="21.11">
					<filename>dpdk-devel-21.11-81.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/dpdk-devel-21.11-81.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="dpdk-doc" release="81.u16.fos23" version="21.11">
					<filename>dpdk-doc-21.11-81.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/dpdk-doc-21.11-81.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="dpdk-tools" release="81.u16.fos23" version="21.11">
					<filename>dpdk-tools-21.11-81.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/dpdk-tools-21.11-81.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dpdk" release="81.u16.fos23" version="21.11">
					<filename>dpdk-21.11-81.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/dpdk-21.11-81.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dpdk-devel" release="81.u16.fos23" version="21.11">
					<filename>dpdk-devel-21.11-81.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/dpdk-devel-21.11-81.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dpdk-tools" release="81.u16.fos23" version="21.11">
					<filename>dpdk-tools-21.11-81.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/dpdk-tools-21.11-81.u16.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2011</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38796" id="CVE-2024-38796" title="CVE-2024-38796" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-45236" id="CVE-2023-45236" title="CVE-2023-45236" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-45237" id="CVE-2023-45237" title="CVE-2023-45237" type="cve"></reference>
		</references>
		<description>CVE-2024-38796:EDK2 contains a vulnerability in the PeCoffLoaderRelocateImage(). An Attacker may cause memory corruption due to an overflow via an adjacent network. A successful exploit of this vulnerability may lead to a loss of Confidentiality, Integrity, and/or Availability.&#xA;CVE-2023-45236:EDK2&#39;s Network Package is susceptible to a predictable TCP Initial Sequence Number. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality.&#xA;CVE-2023-45237:EDK2&#39;s Network Package is susceptible to a predictable TCP Initial Sequence Number. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="22.u10.fos23" version="202011">
					<filename>edk2-devel-202011-22.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/edk2-devel-202011-22.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="22.u10.fos23" version="202011">
					<filename>python3-edk2-devel-202011-22.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-edk2-devel-202011-22.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="22.u10.fos23" version="202011">
					<filename>edk2-help-202011-22.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/edk2-help-202011-22.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="22.u10.fos23" version="202011">
					<filename>edk2-ovmf-202011-22.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/edk2-ovmf-202011-22.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="22.u10.fos23" version="202011">
					<filename>edk2-devel-202011-22.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/edk2-devel-202011-22.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="22.u10.fos23" version="202011">
					<filename>edk2-aarch64-202011-22.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/edk2-aarch64-202011-22.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2012</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45490" id="CVE-2024-45490" title="CVE-2024-45490" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45491" id="CVE-2024-45491" title="CVE-2024-45491" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45492" id="CVE-2024-45492" title="CVE-2024-45492" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50602" id="CVE-2024-50602" title="CVE-2024-50602" type="cve"></reference>
		</references>
		<description>CVE-2024-45490:An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.&#xA;CVE-2024-45491:An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).&#xA;CVE-2024-45492:An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).&#xA;CVE-2024-50602:An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="expat" release="14.u2.fos23" version="2.4.1">
					<filename>expat-2.4.1-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/expat-2.4.1-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat-devel" release="14.u2.fos23" version="2.4.1">
					<filename>expat-devel-2.4.1-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/expat-devel-2.4.1-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="expat-help" release="14.u2.fos23" version="2.4.1">
					<filename>expat-help-2.4.1-14.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/expat-help-2.4.1-14.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat" release="14.u2.fos23" version="2.4.1">
					<filename>expat-2.4.1-14.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/expat-2.4.1-14.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat-devel" release="14.u2.fos23" version="2.4.1">
					<filename>expat-devel-2.4.1-14.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/expat-devel-2.4.1-14.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2013</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35366" id="CVE-2024-35366" title="CVE-2024-35366" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35367" id="CVE-2024-35367" title="CVE-2024-35367" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36617" id="CVE-2024-36617" title="CVE-2024-36617" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36618" id="CVE-2024-36618" title="CVE-2024-36618" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35368" id="CVE-2024-35368" title="CVE-2024-35368" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36616" id="CVE-2024-36616" title="CVE-2024-36616" type="cve"></reference>
		</references>
		<description>CVE-2024-35366:FFmpeg n6.1.1 is Integer Overflow. The vulnerability exists in the parse_options function of sbgdec.c within the libavformat module. When parsing certain options, the software does not adequately validate the input. This allows for negative duration values to be accepted without proper bounds checking.&#xA;CVE-2024-35367:FFmpeg n6.1.1 has an Out-of-bounds Read via libavcodec/ppc/vp8dsp_altivec.c, static const vec_s8 h_subpel_filters_outer&#xA;CVE-2024-36617:FFmpeg n6.1.1 has an integer overflow vulnerability in the FFmpeg CAF decoder.&#xA;CVE-2024-36618:FFmpeg n6.1.1 has a vulnerability in the AVI demuxer of the libavformat library which allows for an integer overflow, potentially resulting in a denial-of-service (DoS) condition.&#xA;CVE-2024-35368:FFmpeg n7.0 is affected by a Double Free via the rkmpp_retrieve_frame function within libavcodec/rkmppdec.c.&#xA;CVE-2024-36616:An integer overflow in the component /libavformat/westwood_vqa.c of FFmpeg n6.1.1 allows attackers to cause a denial of service in the application via a crafted VQA file.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="21.u5.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-21.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ffmpeg-4.2.4-21.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="21.u5.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-21.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ffmpeg-libs-4.2.4-21.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="21.u5.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-21.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libavdevice-4.2.4-21.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="21.u5.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-21.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ffmpeg-devel-4.2.4-21.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="21.u5.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-21.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ffmpeg-4.2.4-21.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="21.u5.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-21.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ffmpeg-libs-4.2.4-21.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="21.u5.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-21.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libavdevice-4.2.4-21.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="21.u5.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-21.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ffmpeg-devel-4.2.4-21.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2014</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46953" id="CVE-2024-46953" title="CVE-2024-46953" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46952" id="CVE-2024-46952" title="CVE-2024-46952" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46951" id="CVE-2024-46951" title="CVE-2024-46951" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46956" id="CVE-2024-46956" title="CVE-2024-46956" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46955" id="CVE-2024-46955" title="CVE-2024-46955" type="cve"></reference>
		</references>
		<description>CVE-2024-46953:An issue was discovered in base/gsdevice.c in Artifex Ghostscript before 10.04.0. An integer overflow when parsing the filename format string (for the output filename) results in path truncation, and possible path traversal and code execution.&#xA;CVE-2024-46952:An issue was discovered in pdf/pdf_xref.c in Artifex Ghostscript before 10.04.0. There is a buffer overflow during handling of a PDF XRef stream (related to W array values).&#xA;CVE-2024-46951:An issue was discovered in psi/zcolor.c in Artifex Ghostscript before 10.04.0. An unchecked Implementation pointer in Pattern color space could lead to arbitrary code execution.&#xA;CVE-2024-46956:An issue was discovered in psi/zfile.c in Artifex Ghostscript before 10.04.0. Out-of-bounds data access in filenameforall can lead to arbitrary code execution.&#xA;CVE-2024-46955:An issue was discovered in psi/zcolor.c in Artifex Ghostscript before 10.04.0. There is an out-of-bounds read when reading color in Indexed color space.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ghostscript-9.55.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ghostscript-devel-9.55.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-17.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ghostscript-help-9.55.0-17.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ghostscript-tools-dvipdf-9.55.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ghostscript-9.55.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ghostscript-devel-9.55.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="17.u14.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ghostscript-tools-dvipdf-9.55.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2015</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52533" id="CVE-2024-52533" title="CVE-2024-52533" type="cve"></reference>
		</references>
		<description>CVE-2024-52533:gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing &#39;\0&#39; character.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="glib2" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-2.72.2-19.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/glib2-2.72.2-19.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-devel-2.72.2-19.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/glib2-devel-2.72.2-19.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-static" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-static-2.72.2-19.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/glib2-static-2.72.2-19.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-tests-2.72.2-19.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/glib2-tests-2.72.2-19.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-help-2.72.2-19.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/glib2-help-2.72.2-19.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-2.72.2-19.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/glib2-2.72.2-19.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-devel-2.72.2-19.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/glib2-devel-2.72.2-19.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-static" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-static-2.72.2-19.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/glib2-static-2.72.2-19.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="19.u14.fos23" version="2.72.2">
					<filename>glib2-tests-2.72.2-19.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/glib2-tests-2.72.2-19.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2016</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-24531" id="CVE-2023-24531" title="CVE-2023-24531" type="cve"></reference>
		</references>
		<description>CVE-2023-24531:Command go env is documented as outputting a shell script containing the Go environment. However, go env doesn&#39;t sanitize values, so executing its output as a shell script can cause various bad bahaviors, including executing arbitrary commands or inserting new environment variables. This issue is relatively minor because, in general, if an attacker can set arbitrary environment variables on a system, they have better attack vectors than making &#34;go env&#34; print them out.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u12.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/golang-1.20.5-3.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u12.fos23" version="1.20.5">
					<filename>golang-help-1.20.5-3.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/golang-help-1.20.5-3.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u12.fos23" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/golang-devel-1.20.5-3.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u12.fos23" version="1.20.5">
					<filename>golang-1.20.5-3.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/golang-1.20.5-3.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2017</id>
		<title>An update for gsl is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50610" id="CVE-2024-50610" title="CVE-2024-50610" type="cve"></reference>
		</references>
		<description>CVE-2024-50610:GSL (GNU Scientific Library) through 2.8 has an integer signedness error in gsl_siman_solve_many in siman/siman.c. When params.n_tries is negative, incorrect memory allocation occurs.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="gsl" release="10.u1.fos23" version="2.4">
					<filename>gsl-2.4-10.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gsl-2.4-10.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gsl-devel" release="10.u1.fos23" version="2.4">
					<filename>gsl-devel-2.4-10.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gsl-devel-2.4-10.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gsl-help" release="10.u1.fos23" version="2.4">
					<filename>gsl-help-2.4-10.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gsl-help-2.4-10.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gsl" release="10.u1.fos23" version="2.4">
					<filename>gsl-2.4-10.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/gsl-2.4-10.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gsl-devel" release="10.u1.fos23" version="2.4">
					<filename>gsl-devel-2.4-10.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/gsl-devel-2.4-10.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2018</id>
		<title>An update for gstreamer1-plugins-base is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37328" id="CVE-2023-37328" title="CVE-2023-37328" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47538" id="CVE-2024-47538" title="CVE-2024-47538" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47541" id="CVE-2024-47541" title="CVE-2024-47541" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47542" id="CVE-2024-47542" title="CVE-2024-47542" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47600" id="CVE-2024-47600" title="CVE-2024-47600" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47607" id="CVE-2024-47607" title="CVE-2024-47607" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47615" id="CVE-2024-47615" title="CVE-2024-47615" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47835" id="CVE-2024-47835" title="CVE-2024-47835" type="cve"></reference>
		</references>
		<description>CVE-2023-37328:GStreamer PGS File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.&#xA;The specific flaw exists within the parsing of PGS subtitle files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.&#xA;. Was ZDI-CAN-20994.&#xA;CVE-2024-47538:GStreamer is a library for constructing graphs of media-handling components. A stack-buffer overflow has been detected in the `vorbis_handle_identification_packet` function within `gstvorbisdec.c`. The position array is a stack-allocated buffer of size 64. If vd-&gt;vi.channels exceeds 64, the for loop will write beyond the boundaries of the position array. The value written will always be `GST_AUDIO_CHANNEL_POSITION_NONE`. This vulnerability allows someone to overwrite the EIP address allocated in the stack. Additionally, this bug can overwrite the `GstAudioInfo` info structure. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47541:GStreamer is a library for constructing graphs of media-handling components. An OOB-write vulnerability has been identified in the gst_ssa_parse_remove_override_codes function of the gstssaparse.c file. This function is responsible for parsing and removing SSA (SubStation Alpha) style override codes, which are enclosed in curly brackets ({}). The issue arises when a closing curly bracket &#34;}&#34; appears before an opening curly bracket &#34;{&#34; in the input string. In this case, memmove() incorrectly duplicates a substring. With each successive loop iteration, the size passed to memmove() becomes progressively larger (strlen(end+1)), leading to a write beyond the allocated memory bounds. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47542:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference has been discovered in the id3v2_read_synch_uint function, located in id3v2.c. If id3v2_read_synch_uint is called with a null work-&gt;hdr.frame_data, the pointer guint8 *data is accessed without validation, resulting in a null pointer dereference. This vulnerability can result in a Denial of Service (DoS) by triggering a segmentation fault (SEGV). This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47600:GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been detected in the format_channel_mask function in gst-discoverer.c. The vulnerability affects the local array position, which is defined with a fixed size of 64 elements. However, the function gst_discoverer_audio_info_get_channels may return a guint channels value greater than 64. This causes the for loop to attempt access beyond the bounds of the position array, resulting in an OOB-read when an index greater than 63 is used. This vulnerability can result in reading unintended bytes from the stack. Additionally, the dereference of value-&gt;value_nick after the OOB-read can lead to further memory corruption or undefined behavior. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47607:GStreamer is a library for constructing graphs of media-handling components.  stack-buffer overflow has been detected in the gst_opus_dec_parse_header function within `gstopusdec.c&#39;. The pos array is a stack-allocated buffer of size 64. If n_channels exceeds 64, the for loop will write beyond the boundaries of the pos array. The value written will always be GST_AUDIO_CHANNEL_POSITION_NONE. This bug allows to overwrite the EIP address allocated in the stack. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47615:GStreamer is a library for constructing graphs of media-handling components. An OOB-Write has been detected in the function gst_parse_vorbis_setup_packet within vorbis_parse.c. The integer size is read from the input file without proper validation. As a result, size can exceed the fixed size of the pad-&gt;vorbis_mode_sizes array (which size is 256). When this happens, the for loop overwrites the entire pad structure with 0s and 1s, affecting adjacent memory as well. This OOB-write can overwrite up to 380 bytes of memory beyond the boundaries of the pad-&gt;vorbis_mode_sizes array. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47835:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been detected in the parse_lrc function within gstsubparse.c. The parse_lrc function calls strchr() to find the character &#39;]&#39; in the string line. The pointer returned by this call is then passed to g_strdup(). However, if the string line does not contain the character &#39;]&#39;, strchr() returns NULL, and a call to g_strdup(start + 1) leads to a null pointer dereference. This vulnerability is fixed in 1.24.10.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base" release="8.u4.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gstreamer1-plugins-base-1.18.4-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base-devel" release="8.u4.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gstreamer1-plugins-base-devel-1.18.4-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-base-help" release="8.u4.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-help-1.18.4-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gstreamer1-plugins-base-help-1.18.4-8.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base" release="8.u4.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/gstreamer1-plugins-base-1.18.4-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base-devel" release="8.u4.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/gstreamer1-plugins-base-devel-1.18.4-8.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2019</id>
		<title>An update for gstreamer1-plugins-good is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47544" id="CVE-2024-47544" title="CVE-2024-47544" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47545" id="CVE-2024-47545" title="CVE-2024-47545" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47599" id="CVE-2024-47599" title="CVE-2024-47599" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47603" id="CVE-2024-47603" title="CVE-2024-47603" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47537" id="CVE-2024-47537" title="CVE-2024-47537" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47539" id="CVE-2024-47539" title="CVE-2024-47539" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47540" id="CVE-2024-47540" title="CVE-2024-47540" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47543" id="CVE-2024-47543" title="CVE-2024-47543" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47546" id="CVE-2024-47546" title="CVE-2024-47546" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47596" id="CVE-2024-47596" title="CVE-2024-47596" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47597" id="CVE-2024-47597" title="CVE-2024-47597" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47601" id="CVE-2024-47601" title="CVE-2024-47601" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47602" id="CVE-2024-47602" title="CVE-2024-47602" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47606" id="CVE-2024-47606" title="CVE-2024-47606" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47834" id="CVE-2024-47834" title="CVE-2024-47834" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47774" id="CVE-2024-47774" title="CVE-2024-47774" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47778" id="CVE-2024-47778" title="CVE-2024-47778" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47777" id="CVE-2024-47777" title="CVE-2024-47777" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47776" id="CVE-2024-47776" title="CVE-2024-47776" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47775" id="CVE-2024-47775" title="CVE-2024-47775" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47613" id="CVE-2024-47613" title="CVE-2024-47613" type="cve"></reference>
		</references>
		<description>CVE-2024-47544:GStreamer is a library for constructing graphs of media-handling components. The function qtdemux_parse_sbgp in qtdemux.c is affected by a null dereference vulnerability. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47545:GStreamer is a library for constructing graphs of media-handling components. An integer underflow has been detected in qtdemux_parse_trak function within qtdemux.c. During the strf parsing case, the subtraction size -= 40 can lead to a negative integer overflow if it is less than 40. If this happens, the subsequent call to gst_buffer_fill will invoke memcpy with a large tocopy size, resulting in an OOB-read. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47599:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_jpeg_dec_negotiate function in gstjpegdec.c. This function does not check for a NULL return value from gst_video_decoder_set_output_state. When this happens, dereferences of the outstate pointer will lead to a null pointer dereference. This vulnerability can result in a Denial of Service (DoS) by triggering a segmentation fault (SEGV). This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47603:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_matroska_demux_update_tracks function within matroska-demux.c. The vulnerability occurs when the gst_caps_is_equal function is called with invalid caps values. If this happen, then in the function gst_buffer_get_size the call to GST_BUFFER_MEM_PTR can return a null pointer. Attempting to dereference the size field of this null pointer results in a null pointer dereference. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47537:GStreamer is a library for constructing graphs of media-handling components. The program attempts to reallocate the memory pointed to by stream-&gt;samples to accommodate stream-&gt;n_samples + samples_count elements of type QtDemuxSample. The problem is that samples_count is read from the input file. And if this value is big enough, this can lead to an integer overflow during the addition. As a consequence, g_try_renew might allocate memory for a significantly smaller number of elements than intended. Following this, the program iterates through samples_count elements and attempts to write samples_count number of elements, potentially exceeding the actual allocated memory size and causing an OOB-write. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47539:GStreamer is a library for constructing graphs of media-handling components. An out-of-bounds write vulnerability was identified in the convert_to_s334_1a function in isomp4/qtdemux.c. The vulnerability arises due to a discrepancy between the size of memory allocated to the storage array and the loop condition i * 2 &lt; ccpair_size. Specifically, when ccpair_size is even, the allocated size in storage does not match the loop&#39;s expected bounds, resulting in an out-of-bounds write. This bug allows for the overwriting of up to 3 bytes beyond the allocated bounds of the storage array. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47540:GStreamer is a library for constructing graphs of media-handling components. An uninitialized stack variable vulnerability has been identified in the gst_matroska_demux_add_wvpk_header function within matroska-demux.c. When size &lt; 4, the program calls gst_buffer_unmap with an uninitialized map variable. Then, in the gst_memory_unmap function, the program will attempt to unmap the buffer using the uninitialized map variable, causing a function pointer hijack, as it will jump to mem-&gt;allocator-&gt;mem_unmap_full or mem-&gt;allocator-&gt;mem_unmap. This vulnerability could allow an attacker to hijack the execution flow, potentially leading to code execution. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47543:GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been discovered in qtdemux_parse_container function within qtdemux.c. In the parent function qtdemux_parse_node, the value of length is not well checked. So, if length is big enough, it causes the pointer end to point beyond the boundaries of buffer. Subsequently, in the qtdemux_parse_container function, the while loop can trigger an OOB-read, accessing memory beyond the bounds of buf. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47546:GStreamer is a library for constructing graphs of media-handling components. An integer underflow has been detected in extract_cc_from_data function within qtdemux.c. In the FOURCC_c708 case, the subtraction atom_length - 8 may result in an underflow if atom_length is less than 8. When that subtraction underflows, *cclen ends up being a large number, and then cclen is passed to g_memdup2 leading to an out-of-bounds (OOB) read. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47596:GStreamer is a library for constructing graphs of media-handling components. An OOB-read has been discovered in the qtdemux_parse_svq3_stsd_data function within qtdemux.c. In the FOURCC_SMI_ case, seqh_size is read from the input file without proper validation. If seqh_size is greater than the remaining size of the data buffer, it can lead to an OOB-read in the following call to gst_buffer_fill, which internally uses memcpy. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47597:GStreamer is a library for constructing graphs of media-handling components. An OOB-read has been detected in the function qtdemux_parse_samples within qtdemux.c. This issue arises when the function qtdemux_parse_samples reads data beyond the boundaries of the stream-&gt;stco buffer. The following code snippet shows the call to qt_atom_parser_get_offset_unchecked, which leads to the OOB-read when parsing the provided GHSL-2024-245_crash1.mp4 file. This issue may lead to read up to 8 bytes out-of-bounds. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47601:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_matroska_demux_parse_blockgroup_or_simpleblock function within matroska-demux.c. This function does not properly check the validity of the GstBuffer *sub pointer before performing dereferences. As a result, null pointer dereferences may occur. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47602:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_matroska_demux_add_wvpk_header function within matroska-demux.c. This function does not properly check the validity of the stream-&gt;codec_priv pointer in the following code. If stream-&gt;codec_priv is NULL, the call to GST_READ_UINT16_LE will attempt to dereference a null pointer, leading to a crash of the application. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47606:GStreamer is a library for constructing graphs of media-handling components. An integer underflow has been detected in the function qtdemux_parse_theora_extension within qtdemux.c. The vulnerability occurs due to an underflow of the gint size variable, which causes size to hold a large unintended value when cast to an unsigned integer. This 32-bit negative value is then cast to a 64-bit unsigned integer (0xfffffffffffffffa) in a subsequent call to gst_buffer_new_and_alloc. The function gst_buffer_new_allocate then attempts to allocate memory, eventually calling _sysmem_new_block. The function _sysmem_new_block adds alignment and header size to the (unsigned) size, causing the overflow of the &#39;slice_size&#39; variable. As a result, only 0x89 bytes are allocated, despite the large input size. When the following memcpy call occurs in gst_buffer_fill, the data from the input file will overwrite the content of the GstMapInfo info structure. Finally, during the call to gst_memory_unmap, the overwritten memory may cause a function pointer hijack, as the mem-&gt;allocator-&gt;mem_unmap_full function is called with a corrupted pointer. This function pointer overwrite could allow an attacker to alter the execution flow of the program, leading to arbitrary code execution. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47834:GStreamer is a library for constructing graphs of media-handling components. An Use-After-Free read vulnerability has been discovered affecting the processing of CodecPrivate elements in Matroska streams. In the GST_MATROSKA_ID_CODECPRIVATE case within the gst_matroska_demux_parse_stream function, a data chunk is allocated using gst_ebml_read_binary. Later, the allocated memory is freed in the gst_matroska_track_free function, by the call to g_free (track-&gt;codec_priv). Finally, the freed memory is accessed in the caps_serialize function through gst_value_serialize_buffer. The freed memory will be accessed in the gst_value_serialize_buffer function. This results in a UAF read vulnerability, as the function tries to process memory that has already been freed. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47774:GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been identified in the gst_avi_subtitle_parse_gab2_chunk function within gstavisubtitle.c. The function reads the name_length value directly from the input file without checking it properly. Then, the a condition, does not properly handle cases where name_length is greater than 0xFFFFFFFF - 17, causing an integer overflow. In such scenario, the function attempts to access memory beyond the buffer leading to an OOB-read. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47778:GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been discovered in gst_wavparse_adtl_chunk within gstwavparse.c. This vulnerability arises due to insufficient validation of the size parameter, which can exceed the bounds of the data buffer. As a result, an OOB read occurs in the following while loop. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47777:GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been identified in the gst_wavparse_smpl_chunk function within gstwavparse.c. This function attempts to read 4 bytes from the data + 12 offset without checking if the size of the data buffer is sufficient. If the buffer is too small, the function reads beyond its bounds. This vulnerability may result in reading 4 bytes out of the boundaries of the data buffer. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47776:GStreamer is a library for constructing graphs of media-handling components. An OOB-read has been discovered in gst_wavparse_cue_chunk within gstwavparse.c. The vulnerability happens due to a discrepancy between the size of the data buffer and the size value provided to the function. This mismatch causes the comparison  if (size &lt; 4 + ncues * 24) to fail in some cases, allowing the subsequent loop to access beyond the bounds of the data buffer. The root cause of this discrepancy stems from a miscalculation when clipping the chunk size based on upstream data size. This vulnerability allows reading beyond the bounds of the data buffer, potentially leading to a crash (denial of service) or the leak of sensitive data. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47775:GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been found in the parse_ds64 function within gstwavparse.c. The parse_ds64 function does not check that the buffer buf contains sufficient data before attempting to read from it, doing multiple GST_READ_UINT32_LE operations without performing boundary checks. This can lead to an OOB-read when buf is smaller than expected. This vulnerability allows reading beyond the bounds of the data buffer, potentially leading to a crash (denial of service) or the leak of sensitive data. This vulnerability is fixed in 1.24.10.&#xA;CVE-2024-47613:GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been identified in `gst_gdk_pixbuf_dec_flush` within `gstgdkpixbufdec.c`. This function invokes `memcpy`, using `out_pix` as the destination address. `out_pix` is expected to point to the frame 0 from the frame structure, which is read from the input file. However, in certain situations, it can points to a NULL frame, causing the subsequent call to `memcpy` to attempt writing to the null address (0x00), leading to a null pointer dereference. This vulnerability can result in a Denial of Service (DoS) by triggering a segmentation fault (SEGV). This vulnerability is fixed in 1.24.10.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good" release="8.u4.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gstreamer1-plugins-good-1.16.2-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good-gtk" release="8.u4.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gstreamer1-plugins-good-gtk-1.16.2-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-good-help" release="8.u4.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-help-1.16.2-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/gstreamer1-plugins-good-help-1.16.2-8.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good" release="8.u4.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/gstreamer1-plugins-good-1.16.2-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good-gtk" release="8.u4.fos23" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/gstreamer1-plugins-good-gtk-1.16.2-8.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2020</id>
		<title>An update for hadoop is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23454" id="CVE-2024-23454" title="CVE-2024-23454" type="cve"></reference>
		</references>
		<description>CVE-2024-23454:Apache Hadoop’s RunJar.run() does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content.&#xA;This is because, on unix-like systems, the system temporary directory is&#xA;shared between all local users. As such, files written in this directory,&#xA;without setting the correct posix permissions explicitly, may be viewable&#xA;by all other local users.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="hadoop-client" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-client-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-client-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-common" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-common-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-common-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-common-native" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-common-native-3.3.4-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-common-native-3.3.4-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-devel" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-devel-3.3.4-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-devel-3.3.4-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-hdfs" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-hdfs-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-hdfs-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-httpfs" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-httpfs-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-httpfs-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libhdfs" release="2.u4.fos23" version="3.3.4">
					<filename>libhdfs-3.3.4-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libhdfs-3.3.4-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-mapreduce" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-mapreduce-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-mapreduce-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-mapreduce-examples" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-mapreduce-examples-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-mapreduce-examples-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-maven-plugin" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-maven-plugin-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-maven-plugin-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-tests" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-tests-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-tests-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-yarn" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-yarn-3.3.4-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-yarn-3.3.4-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-yarn-security" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-yarn-security-3.3.4-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hadoop-yarn-security-3.3.4-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-common-native" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-common-native-3.3.4-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/hadoop-common-native-3.3.4-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-devel" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-devel-3.3.4-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/hadoop-devel-3.3.4-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libhdfs" release="2.u4.fos23" version="3.3.4">
					<filename>libhdfs-3.3.4-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libhdfs-3.3.4-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-yarn-security" release="2.u4.fos23" version="3.3.4">
					<filename>hadoop-yarn-security-3.3.4-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/hadoop-yarn-security-3.3.4-2.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2021</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53008" id="CVE-2024-53008" title="CVE-2024-53008" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53008" id="CVE-2024-53008" title="CVE-2024-53008" type="cve"></reference>
		</references>
		<description>CVE-2024-53008:Inconsistent interpretation of HTTP requests (&#39;HTTP Request/Response Smuggling&#39;) issue exists in HAProxy. If this vulnerability is exploited,  a remote attacker may access a path that is restricted by ACL (Access Control List) set on the product. As a result, the attacker may obtain sensitive information.&#xA;CVE-2024-53008:Inconsistent interpretation of HTTP requests (&#39;HTTP Request/Response Smuggling&#39;) issue exists in HAProxy. If this vulnerability is exploited,  a remote attacker may access a path that is restricted by ACL (Access Control List) set on the product. As a result, the attacker may obtain sensitive information.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="14.u12.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-14.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/haproxy-2.6.6-14.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="14.u12.fos23" version="2.6.6">
					<filename>haproxy-help-2.6.6-14.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/haproxy-help-2.6.6-14.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="14.u12.fos23" version="2.6.6">
					<filename>haproxy-2.6.6-14.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/haproxy-2.6.6-14.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2022</id>
		<title>An update for hplip is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-6923" id="CVE-2020-6923" title="CVE-2020-6923" type="cve"></reference>
		</references>
		<description>CVE-2020-6923:The HP Linux Imaging and Printing (HPLIP) software may potentially be affected by memory buffer overflow.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="hplip" release="2.u2.fos23" version="3.23.8">
					<filename>hplip-3.23.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/hplip-3.23.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hplip" release="2.u2.fos23" version="3.23.8">
					<filename>hplip-3.23.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/hplip-3.23.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2023</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40725" id="CVE-2024-40725" title="CVE-2024-40725" type="cve"></reference>
		</references>
		<description>CVE-2024-40725:A partial fix for  CVE-2024-39884 in the core of Apache HTTP Server 2.4.61 ignores some use of the legacy content-type based configuration of handlers. &#34;AddType&#34; and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted.&#xA;Users are recommended to upgrade to version 2.4.62, which fixes this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="httpd" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/httpd-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/httpd-devel-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-help-2.4.51-23.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/httpd-help-2.4.51-23.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-23.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/httpd-filesystem-2.4.51-23.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/httpd-tools-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="23.u14.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mod_ssl-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="23.u14.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mod_md-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="23.u14.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mod_proxy_html-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="23.u14.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mod_ldap-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="23.u14.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-23.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mod_session-2.4.51-23.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/httpd-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-devel-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/httpd-devel-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="23.u14.fos23" version="2.4.51">
					<filename>httpd-tools-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/httpd-tools-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="23.u14.fos23" version="2.4.51">
					<filename>mod_ssl-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mod_ssl-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="23.u14.fos23" version="2.4.51">
					<filename>mod_md-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mod_md-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="23.u14.fos23" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mod_proxy_html-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="23.u14.fos23" version="2.4.51">
					<filename>mod_ldap-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mod_ldap-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="23.u14.fos23" version="2.4.51">
					<filename>mod_session-2.4.51-23.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mod_session-2.4.51-23.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2024</id>
		<title>An update for iptraf-ng is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52949" id="CVE-2024-52949" title="CVE-2024-52949" type="cve"></reference>
		</references>
		<description>CVE-2024-52949:VUL-0: CVE-2024-52949: iptraf-ng: limit interface name lengths to IFNAMSIZ</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="iptraf-ng" release="4.u1.fos23" version="1.2.1">
					<filename>iptraf-ng-1.2.1-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/iptraf-ng-1.2.1-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="iptraf-ng-help" release="4.u1.fos23" version="1.2.1">
					<filename>iptraf-ng-help-1.2.1-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/iptraf-ng-help-1.2.1-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iptraf-ng" release="4.u1.fos23" version="1.2.1">
					<filename>iptraf-ng-1.2.1-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/iptraf-ng-1.2.1-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2025</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21211" id="CVE-2024-21211" title="CVE-2024-21211" type="cve"></reference>
		</references>
		<description>CVE-2024-21211:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-headless-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-headless-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-headless-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-devel-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-devel-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-demo-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-demo-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-demo-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-src-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-src-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-src-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.432.b06-0.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-javadoc-1.8.0.432.b06-0.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.432.b06-0.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-javadoc-zip-1.8.0.432.b06-0.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-accessibility-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-devel-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-headless-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-headless-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-headless-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-devel-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-devel-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-demo-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-demo-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-demo-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-src-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-src-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-src-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-accessibility-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-devel-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u5.fos23" version="1.8.0.432.b06">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.432.b06-0.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2026</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
		</references>
		<description>CVE-2024-21208:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-headless-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-headless-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-headless-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-headless-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-devel-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-devel-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-devel-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-devel-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-jmods-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-jmods-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-jmods-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-demo-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-demo-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-demo-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-demo-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-src-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-src-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-src-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-src-slowdebug-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-javadoc-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-javadoc-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-javadoc-zip-17.0.13.11-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-17-openjdk-javadoc-zip-17.0.13.11-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-headless-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-headless-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-headless-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-headless-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-devel-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-devel-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-devel-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-devel-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-jmods-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-jmods-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-jmods-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-demo-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-demo-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-demo-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-demo-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-src-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-src-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-src-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-src-slowdebug-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-javadoc-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-javadoc-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="2.u7.fos23" version="17.0.13.11">
					<filename>java-17-openjdk-javadoc-zip-17.0.13.11-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-17-openjdk-javadoc-zip-17.0.13.11-2.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2027</id>
		<title>An update for java-latest-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20923" id="CVE-2024-20923" title="CVE-2024-20923" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20925" id="CVE-2024-20925" title="CVE-2024-20925" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20922" id="CVE-2024-20922" title="CVE-2024-20922" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20932" id="CVE-2024-20932" title="CVE-2024-20932" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-20955" id="CVE-2024-20955" title="CVE-2024-20955" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21002" id="CVE-2024-21002" title="CVE-2024-21002" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21012" id="CVE-2024-21012" title="CVE-2024-21012" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21004" id="CVE-2024-21004" title="CVE-2024-21004" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21003" id="CVE-2024-21003" title="CVE-2024-21003" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21005" id="CVE-2024-21005" title="CVE-2024-21005" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14593" id="CVE-2020-14593" title="CVE-2020-14593" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14577" id="CVE-2020-14577" title="CVE-2020-14577" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14578" id="CVE-2020-14578" title="CVE-2020-14578" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14556" id="CVE-2020-14556" title="CVE-2020-14556" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14621" id="CVE-2020-14621" title="CVE-2020-14621" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14581" id="CVE-2020-14581" title="CVE-2020-14581" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14664" id="CVE-2020-14664" title="CVE-2020-14664" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14573" id="CVE-2020-14573" title="CVE-2020-14573" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-14562" id="CVE-2020-14562" title="CVE-2020-14562" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-42950" id="CVE-2023-42950" title="CVE-2023-42950" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21211" id="CVE-2024-21211" title="CVE-2024-21211" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
		</references>
		<description>CVE-2023-22025:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u381-perf, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 21.3.7 and  22.3.3. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition,.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2023-22081:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf, 11.0.20, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 20.3.11, 21.3.7 and  22.3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-20923:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).&#xA;CVE-2024-20921:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20925:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-20926:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Scripting).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21; Oracle GraalVM for JDK: 17.0.9; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20952:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2024-20918:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2024-20922:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-20919:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.9 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).&#xA;CVE-2024-20945:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N).&#xA;CVE-2024-20932:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security).  Supported versions that are affected are Oracle Java SE: 17.0.9; Oracle GraalVM for JDK: 17.0.9; Oracle GraalVM Enterprise Edition: 21.3.8 and  22.3.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N).&#xA;CVE-2024-20955:Vulnerability in the Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. CVSS 3.1 Base Score 3.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2024-21002:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21012:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21094:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21085:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21004:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21068:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2 and  22; Oracle GraalVM Enterprise Edition: 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21003:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21005:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21011:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22;   Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2020-14593:Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.4 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N).&#xA;CVE-2020-14577:Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JSSE). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2020-14578:Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u261 and 8u251; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2020-14556:Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2020-14621:Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JAXP). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2020-14581:Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2020-14664:Vulnerability in the Java SE product of Oracle Java SE (component: JavaFX). The supported version that is affected is Java SE: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).&#xA;CVE-2020-14573:Vulnerability in the Java SE product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2020-14562:Vulnerability in the Java SE product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2023-42950:A use after free issue was addressed with improved memory management. This issue is fixed in Safari 17.2, iOS 17.2 and iPadOS 17.2, tvOS 17.2, watchOS 10.2, macOS Sonoma 14.2. Processing maliciously crafted web content may lead to arbitrary code execution.&#xA;CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21208:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21211:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-headless" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-headless-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-headless-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-headless-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-headless-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-headless-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-devel" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-devel-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-devel-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-devel-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-devel-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-devel-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-jmods" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-jmods-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-jmods-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-jmods-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-jmods-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-jmods-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-demo" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-demo-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-demo-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-demo-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-demo-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-demo-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-src" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-src-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-src-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-src-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-src-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-src-slowdebug-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-javadoc" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-javadoc-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-javadoc-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-latest-openjdk-javadoc-zip" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-javadoc-zip-23.0.1.11-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/java-latest-openjdk-javadoc-zip-23.0.1.11-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-headless" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-headless-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-headless-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-headless-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-headless-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-headless-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-devel" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-devel-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-devel-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-devel-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-devel-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-devel-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-jmods" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-jmods-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-jmods-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-jmods-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-jmods-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-jmods-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-demo" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-demo-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-demo-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-demo-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-demo-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-demo-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-src" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-src-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-src-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-src-slowdebug" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-src-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-src-slowdebug-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-javadoc" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-javadoc-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-javadoc-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-latest-openjdk-javadoc-zip" release="1.u3.fos23" version="23.0.1.11">
					<filename>java-latest-openjdk-javadoc-zip-23.0.1.11-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/java-latest-openjdk-javadoc-zip-23.0.1.11-1.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2028</id>
		<title>An update for jetty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-2047" id="CVE-2022-2047" title="CVE-2022-2047" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-2048" id="CVE-2022-2048" title="CVE-2022-2048" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-26048" id="CVE-2023-26048" title="CVE-2023-26048" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-26049" id="CVE-2023-26049" title="CVE-2023-26049" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-36479" id="CVE-2023-36479" title="CVE-2023-36479" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-40167" id="CVE-2023-40167" title="CVE-2023-40167" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6762" id="CVE-2024-6762" title="CVE-2024-6762" type="cve"></reference>
		</references>
		<description>CVE-2022-2047:In Eclipse Jetty versions 9.4.0 thru 9.4.46, and 10.0.0 thru 10.0.9, and 11.0.0 thru 11.0.9 versions, the parsing of the authority segment of an http scheme URI, the Jetty HttpURI class improperly detects an invalid input as a hostname. This can lead to failures in a Proxy scenario.&#xA;CVE-2022-2048:In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.&#xA;CVE-2023-26048:Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).&#xA;CVE-2023-26049:Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `&#34;` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE=&#34;b; JSESSIONID=1337; c=d&#34;` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.&#xA;CVE-2023-36479:Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. This issue was patched in version 9.4.52, 10.0.16, 11.0.16 and 12.0.0-beta2.&#xA;CVE-2023-40167:Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.&#xA;CVE-2024-6762:Jetty PushSessionCacheFilter can be exploited by unauthenticated users &#xA;to launch remote DoS attacks by exhausting the server’s memory.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="jetty" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-client" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-client-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-client-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-continuation" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-continuation-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-continuation-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http-spi" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http-spi-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http-spi-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-io" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-io-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-io-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jaas" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jaas-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jaas-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jsp" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jsp-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jsp-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-security" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-security-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-security-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-server" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-server-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-server-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-servlet" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-servlet-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-servlet-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-util" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-util-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-util-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-webapp" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-webapp-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-webapp-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jmx" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jmx-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jmx-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-xml" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-xml-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-xml-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-project" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-project-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-project-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-deploy" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-deploy-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-deploy-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-annotations" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-annotations-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-annotations-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-ant" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-ant-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-ant-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-cdi" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-cdi-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-cdi-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-fcgi-client" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-fcgi-client-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-fcgi-client-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-fcgi-server" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-fcgi-server-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-fcgi-server-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-infinispan" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-infinispan-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-infinispan-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jaspi" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jaspi-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jaspi-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jndi" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jndi-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jndi-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jspc-maven-plugin" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jspc-maven-plugin-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jspc-maven-plugin-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-maven-plugin" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-maven-plugin-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-maven-plugin-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-plus" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-plus-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-plus-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-proxy" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-proxy-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-proxy-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-rewrite" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-rewrite-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-rewrite-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-servlets" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-servlets-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-servlets-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-spring" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-spring-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-spring-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-start" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-start-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-start-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-unixsocket" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-unixsocket-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-unixsocket-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-util-ajax" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-util-ajax-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-util-ajax-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-api" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-websocket-api-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-websocket-api-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-client" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-websocket-client-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-websocket-client-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-common" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-websocket-common-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-websocket-common-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-server" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-websocket-server-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-websocket-server-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-websocket-servlet" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-websocket-servlet-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-websocket-servlet-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-javax-websocket-client-impl" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-javax-websocket-client-impl-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-javax-websocket-client-impl-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-javax-websocket-server-impl" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-javax-websocket-server-impl-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-javax-websocket-server-impl-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-nosql" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-nosql-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-nosql-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-httpservice" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-httpservice-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-httpservice-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-boot" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-osgi-boot-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-osgi-boot-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-boot-warurl" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-osgi-boot-warurl-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-osgi-boot-warurl-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-boot-jsp" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-osgi-boot-jsp-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-osgi-boot-jsp-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-osgi-alpn" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-osgi-alpn-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-osgi-alpn-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-quickstart" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-quickstart-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-quickstart-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-alpn-client" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-alpn-client-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-alpn-client-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-alpn-server" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-alpn-server-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-alpn-server-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-client" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http2-client-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http2-client-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-common" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http2-common-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http2-common-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-hpack" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http2-hpack-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http2-hpack-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-http-client-transport" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http2-http-client-transport-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http2-http-client-transport-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-http2-server" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-http2-server-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-http2-server-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-jstl" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-jstl-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-jstl-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jetty-javadoc" release="8.u3.fos23" version="9.4.16">
					<filename>jetty-javadoc-9.4.16-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/jetty-javadoc-9.4.16-8.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2029</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27436" id="CVE-2024-27436" title="CVE-2024-27436" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36894" id="CVE-2024-36894" title="CVE-2024-36894" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38560" id="CVE-2024-38560" title="CVE-2024-38560" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38659" id="CVE-2024-38659" title="CVE-2024-38659" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39482" id="CVE-2024-39482" title="CVE-2024-39482" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40978" id="CVE-2024-40978" title="CVE-2024-40978" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39501" id="CVE-2024-39501" title="CVE-2024-39501" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41030" id="CVE-2024-41030" title="CVE-2024-41030" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41095" id="CVE-2024-41095" title="CVE-2024-41095" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43846" id="CVE-2024-43846" title="CVE-2024-43846" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43863" id="CVE-2024-43863" title="CVE-2024-43863" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44939" id="CVE-2024-44939" title="CVE-2024-44939" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43900" id="CVE-2024-43900" title="CVE-2024-43900" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44958" id="CVE-2024-44958" title="CVE-2024-44958" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44952" id="CVE-2024-44952" title="CVE-2024-44952" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44954" id="CVE-2024-44954" title="CVE-2024-44954" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45008" id="CVE-2024-45008" title="CVE-2024-45008" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44982" id="CVE-2024-44982" title="CVE-2024-44982" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44950" id="CVE-2024-44950" title="CVE-2024-44950" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45016" id="CVE-2024-45016" title="CVE-2024-45016" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45025" id="CVE-2024-45025" title="CVE-2024-45025" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46681" id="CVE-2024-46681" title="CVE-2024-46681" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46679" id="CVE-2024-46679" title="CVE-2024-46679" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46695" id="CVE-2024-46695" title="CVE-2024-46695" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46707" id="CVE-2024-46707" title="CVE-2024-46707" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46673" id="CVE-2024-46673" title="CVE-2024-46673" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46674" id="CVE-2024-46674" title="CVE-2024-46674" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46715" id="CVE-2024-46715" title="CVE-2024-46715" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46719" id="CVE-2024-46719" title="CVE-2024-46719" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46726" id="CVE-2024-46726" title="CVE-2024-46726" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46725" id="CVE-2024-46725" title="CVE-2024-46725" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46721" id="CVE-2024-46721" title="CVE-2024-46721" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46732" id="CVE-2024-46732" title="CVE-2024-46732" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46771" id="CVE-2024-46771" title="CVE-2024-46771" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46739" id="CVE-2024-46739" title="CVE-2024-46739" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46759" id="CVE-2024-46759" title="CVE-2024-46759" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46795" id="CVE-2024-46795" title="CVE-2024-46795" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46750" id="CVE-2024-46750" title="CVE-2024-46750" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46761" id="CVE-2024-46761" title="CVE-2024-46761" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46774" id="CVE-2024-46774" title="CVE-2024-46774" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46791" id="CVE-2024-46791" title="CVE-2024-46791" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46743" id="CVE-2024-46743" title="CVE-2024-46743" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46742" id="CVE-2024-46742" title="CVE-2024-46742" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46751" id="CVE-2024-46751" title="CVE-2024-46751" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46800" id="CVE-2024-46800" title="CVE-2024-46800" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46777" id="CVE-2024-46777" title="CVE-2024-46777" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46756" id="CVE-2024-46756" title="CVE-2024-46756" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46738" id="CVE-2024-46738" title="CVE-2024-46738" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46740" id="CVE-2024-46740" title="CVE-2024-46740" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46798" id="CVE-2024-46798" title="CVE-2024-46798" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46781" id="CVE-2024-46781" title="CVE-2024-46781" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46737" id="CVE-2024-46737" title="CVE-2024-46737" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46780" id="CVE-2024-46780" title="CVE-2024-46780" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46755" id="CVE-2024-46755" title="CVE-2024-46755" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46753" id="CVE-2024-46753" title="CVE-2024-46753" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46758" id="CVE-2024-46758" title="CVE-2024-46758" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46816" id="CVE-2024-46816" title="CVE-2024-46816" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46841" id="CVE-2024-46841" title="CVE-2024-46841" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46829" id="CVE-2024-46829" title="CVE-2024-46829" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46818" id="CVE-2024-46818" title="CVE-2024-46818" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46821" id="CVE-2024-46821" title="CVE-2024-46821" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46844" id="CVE-2024-46844" title="CVE-2024-46844" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46804" id="CVE-2024-46804" title="CVE-2024-46804" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46857" id="CVE-2024-46857" title="CVE-2024-46857" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46848" id="CVE-2024-46848" title="CVE-2024-46848" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46849" id="CVE-2024-46849" title="CVE-2024-46849" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46814" id="CVE-2024-46814" title="CVE-2024-46814" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47709" id="CVE-2024-47709" title="CVE-2024-47709" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42067" id="CVE-2024-42067" title="CVE-2024-42067" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43855" id="CVE-2024-43855" title="CVE-2024-43855" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48893" id="CVE-2022-48893" title="CVE-2022-48893" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44940" id="CVE-2024-44940" title="CVE-2024-44940" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44969" id="CVE-2024-44969" title="CVE-2024-44969" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45006" id="CVE-2024-45006" title="CVE-2024-45006" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44998" id="CVE-2024-44998" title="CVE-2024-44998" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45026" id="CVE-2024-45026" title="CVE-2024-45026" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46676" id="CVE-2024-46676" title="CVE-2024-46676" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46754" id="CVE-2024-46754" title="CVE-2024-46754" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46770" id="CVE-2024-46770" title="CVE-2024-46770" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46858" id="CVE-2024-46858" title="CVE-2024-46858" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46855" id="CVE-2024-46855" title="CVE-2024-46855" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46840" id="CVE-2024-46840" title="CVE-2024-46840" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46854" id="CVE-2024-46854" title="CVE-2024-46854" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46819" id="CVE-2024-46819" title="CVE-2024-46819" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46828" id="CVE-2024-46828" title="CVE-2024-46828" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47658" id="CVE-2024-47658" title="CVE-2024-47658" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47671" id="CVE-2024-47671" title="CVE-2024-47671" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47664" id="CVE-2024-47664" title="CVE-2024-47664" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47672" id="CVE-2024-47672" title="CVE-2024-47672" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27403" id="CVE-2024-27403" title="CVE-2024-27403" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35789" id="CVE-2024-35789" title="CVE-2024-35789" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35829" id="CVE-2024-35829" title="CVE-2024-35829" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35871" id="CVE-2024-35871" title="CVE-2024-35871" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36007" id="CVE-2024-36007" title="CVE-2024-36007" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36004" id="CVE-2024-36004" title="CVE-2024-36004" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-47484" id="CVE-2021-47484" title="CVE-2021-47484" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52881" id="CVE-2023-52881" title="CVE-2023-52881" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38608" id="CVE-2024-38608" title="CVE-2024-38608" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38612" id="CVE-2024-38612" title="CVE-2024-38612" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36244" id="CVE-2024-36244" title="CVE-2024-36244" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39495" id="CVE-2024-39495" title="CVE-2024-39495" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40958" id="CVE-2024-40958" title="CVE-2024-40958" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42321" id="CVE-2024-42321" title="CVE-2024-42321" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42289" id="CVE-2024-42289" title="CVE-2024-42289" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43880" id="CVE-2024-43880" title="CVE-2024-43880" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44931" id="CVE-2024-44931" title="CVE-2024-44931" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44990" id="CVE-2024-44990" title="CVE-2024-44990" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44989" id="CVE-2024-44989" title="CVE-2024-44989" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45018" id="CVE-2024-45018" title="CVE-2024-45018" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46716" id="CVE-2024-46716" title="CVE-2024-46716" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46826" id="CVE-2024-46826" title="CVE-2024-46826" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46822" id="CVE-2024-46822" title="CVE-2024-46822" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46859" id="CVE-2024-46859" title="CVE-2024-46859" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46817" id="CVE-2024-46817" title="CVE-2024-46817" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47661" id="CVE-2024-47661" title="CVE-2024-47661" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50015" id="CVE-2024-50015" title="CVE-2024-50015" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26917" id="CVE-2024-26917" title="CVE-2024-26917" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35878" id="CVE-2024-35878" title="CVE-2024-35878" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52754" id="CVE-2023-52754" title="CVE-2023-52754" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38635" id="CVE-2024-38635" title="CVE-2024-38635" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36286" id="CVE-2024-36286" title="CVE-2024-36286" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38667" id="CVE-2024-38667" title="CVE-2024-38667" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40965" id="CVE-2024-40965" title="CVE-2024-40965" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41015" id="CVE-2024-41015" title="CVE-2024-41015" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42152" id="CVE-2024-42152" title="CVE-2024-42152" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43841" id="CVE-2024-43841" title="CVE-2024-43841" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43858" id="CVE-2024-43858" title="CVE-2024-43858" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42301" id="CVE-2024-42301" title="CVE-2024-42301" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43867" id="CVE-2024-43867" title="CVE-2024-43867" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43871" id="CVE-2024-43871" title="CVE-2024-43871" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48916" id="CVE-2022-48916" title="CVE-2022-48916" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43894" id="CVE-2024-43894" title="CVE-2024-43894" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46675" id="CVE-2024-46675" title="CVE-2024-46675" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46689" id="CVE-2024-46689" title="CVE-2024-46689" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46724" id="CVE-2024-46724" title="CVE-2024-46724" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46722" id="CVE-2024-46722" title="CVE-2024-46722" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46757" id="CVE-2024-46757" title="CVE-2024-46757" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46830" id="CVE-2024-46830" title="CVE-2024-46830" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46802" id="CVE-2024-46802" title="CVE-2024-46802" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46853" id="CVE-2024-46853" title="CVE-2024-46853" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47667" id="CVE-2024-47667" title="CVE-2024-47667" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47669" id="CVE-2024-47669" title="CVE-2024-47669" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47720" id="CVE-2024-47720" title="CVE-2024-47720" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47698" id="CVE-2024-47698" title="CVE-2024-47698" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47695" id="CVE-2024-47695" title="CVE-2024-47695" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47684" id="CVE-2024-47684" title="CVE-2024-47684" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47685" id="CVE-2024-47685" title="CVE-2024-47685" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47710" id="CVE-2024-47710" title="CVE-2024-47710" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52917" id="CVE-2023-52917" title="CVE-2023-52917" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47737" id="CVE-2024-47737" title="CVE-2024-47737" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47757" id="CVE-2024-47757" title="CVE-2024-47757" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47756" id="CVE-2024-47756" title="CVE-2024-47756" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49875" id="CVE-2024-49875" title="CVE-2024-49875" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49911" id="CVE-2024-49911" title="CVE-2024-49911" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49900" id="CVE-2024-49900" title="CVE-2024-49900" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49894" id="CVE-2024-49894" title="CVE-2024-49894" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49974" id="CVE-2024-49974" title="CVE-2024-49974" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49895" id="CVE-2024-49895" title="CVE-2024-49895" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49867" id="CVE-2024-49867" title="CVE-2024-49867" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49902" id="CVE-2024-49902" title="CVE-2024-49902" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49866" id="CVE-2024-49866" title="CVE-2024-49866" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49969" id="CVE-2024-49969" title="CVE-2024-49969" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50007" id="CVE-2024-50007" title="CVE-2024-50007" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49868" id="CVE-2024-49868" title="CVE-2024-49868" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49903" id="CVE-2024-49903" title="CVE-2024-49903" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49985" id="CVE-2024-49985" title="CVE-2024-49985" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49927" id="CVE-2024-49927" title="CVE-2024-49927" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49966" id="CVE-2024-49966" title="CVE-2024-49966" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49019" id="CVE-2022-49019" title="CVE-2022-49019" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50049" id="CVE-2024-50049" title="CVE-2024-50049" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48994" id="CVE-2022-48994" title="CVE-2022-48994" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49029" id="CVE-2022-49029" title="CVE-2022-49029" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48991" id="CVE-2022-48991" title="CVE-2022-48991" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48946" id="CVE-2022-48946" title="CVE-2022-48946" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48986" id="CVE-2022-48986" title="CVE-2022-48986" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48967" id="CVE-2022-48967" title="CVE-2022-48967" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49030" id="CVE-2022-49030" title="CVE-2022-49030" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48973" id="CVE-2022-48973" title="CVE-2022-48973" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49007" id="CVE-2022-49007" title="CVE-2022-49007" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48952" id="CVE-2022-48952" title="CVE-2022-48952" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50025" id="CVE-2024-50025" title="CVE-2024-50025" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50036" id="CVE-2024-50036" title="CVE-2024-50036" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49033" id="CVE-2022-49033" title="CVE-2022-49033" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52918" id="CVE-2023-52918" title="CVE-2023-52918" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49006" id="CVE-2022-49006" title="CVE-2022-49006" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50074" id="CVE-2024-50074" title="CVE-2024-50074" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45021" id="CVE-2024-45021" title="CVE-2024-45021" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46677" id="CVE-2024-46677" title="CVE-2024-46677" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46809" id="CVE-2024-46809" title="CVE-2024-46809" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47660" id="CVE-2024-47660" title="CVE-2024-47660" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47659" id="CVE-2024-47659" title="CVE-2024-47659" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47668" id="CVE-2024-47668" title="CVE-2024-47668" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47673" id="CVE-2024-47673" title="CVE-2024-47673" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47692" id="CVE-2024-47692" title="CVE-2024-47692" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47703" id="CVE-2024-47703" title="CVE-2024-47703" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47705" id="CVE-2024-47705" title="CVE-2024-47705" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47691" id="CVE-2024-47691" title="CVE-2024-47691" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47696" id="CVE-2024-47696" title="CVE-2024-47696" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47701" id="CVE-2024-47701" title="CVE-2024-47701" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47690" id="CVE-2024-47690" title="CVE-2024-47690" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47699" id="CVE-2024-47699" title="CVE-2024-47699" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47693" id="CVE-2024-47693" title="CVE-2024-47693" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49860" id="CVE-2024-49860" title="CVE-2024-49860" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49855" id="CVE-2024-49855" title="CVE-2024-49855" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47742" id="CVE-2024-47742" title="CVE-2024-47742" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47723" id="CVE-2024-47723" title="CVE-2024-47723" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47748" id="CVE-2024-47748" title="CVE-2024-47748" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47739" id="CVE-2024-47739" title="CVE-2024-47739" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49858" id="CVE-2024-49858" title="CVE-2024-49858" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49863" id="CVE-2024-49863" title="CVE-2024-49863" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49882" id="CVE-2024-49882" title="CVE-2024-49882" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49886" id="CVE-2024-49886" title="CVE-2024-49886" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49879" id="CVE-2024-49879" title="CVE-2024-49879" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49889" id="CVE-2024-49889" title="CVE-2024-49889" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49950" id="CVE-2024-49950" title="CVE-2024-49950" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49917" id="CVE-2024-49917" title="CVE-2024-49917" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49884" id="CVE-2024-49884" title="CVE-2024-49884" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49940" id="CVE-2024-49940" title="CVE-2024-49940" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49973" id="CVE-2024-49973" title="CVE-2024-49973" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49996" id="CVE-2024-49996" title="CVE-2024-49996" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49995" id="CVE-2024-49995" title="CVE-2024-49995" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49958" id="CVE-2024-49958" title="CVE-2024-49958" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49877" id="CVE-2024-49877" title="CVE-2024-49877" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49913" id="CVE-2024-49913" title="CVE-2024-49913" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49992" id="CVE-2024-49992" title="CVE-2024-49992" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49978" id="CVE-2024-49978" title="CVE-2024-49978" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49934" id="CVE-2024-49934" title="CVE-2024-49934" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49936" id="CVE-2024-49936" title="CVE-2024-49936" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50008" id="CVE-2024-50008" title="CVE-2024-50008" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50016" id="CVE-2024-50016" title="CVE-2024-50016" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49965" id="CVE-2024-49965" title="CVE-2024-49965" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49981" id="CVE-2024-49981" title="CVE-2024-49981" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49955" id="CVE-2024-49955" title="CVE-2024-49955" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49883" id="CVE-2024-49883" title="CVE-2024-49883" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49924" id="CVE-2024-49924" title="CVE-2024-49924" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49933" id="CVE-2024-49933" title="CVE-2024-49933" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49922" id="CVE-2024-49922" title="CVE-2024-49922" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49954" id="CVE-2024-49954" title="CVE-2024-49954" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49975" id="CVE-2024-49975" title="CVE-2024-49975" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48960" id="CVE-2022-48960" title="CVE-2022-48960" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50035" id="CVE-2024-50035" title="CVE-2024-50035" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49021" id="CVE-2022-49021" title="CVE-2022-49021" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48966" id="CVE-2022-48966" title="CVE-2022-48966" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49031" id="CVE-2022-49031" title="CVE-2022-49031" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50047" id="CVE-2024-50047" title="CVE-2024-50047" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49032" id="CVE-2022-49032" title="CVE-2022-49032" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50058" id="CVE-2024-50058" title="CVE-2024-50058" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49023" id="CVE-2022-49023" title="CVE-2022-49023" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50046" id="CVE-2024-50046" title="CVE-2024-50046" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50059" id="CVE-2024-50059" title="CVE-2024-50059" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50028" id="CVE-2024-50028" title="CVE-2024-50028" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49011" id="CVE-2022-49011" title="CVE-2022-49011" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48992" id="CVE-2022-48992" title="CVE-2022-48992" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49005" id="CVE-2022-49005" title="CVE-2022-49005" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50060" id="CVE-2024-50060" title="CVE-2024-50060" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49017" id="CVE-2022-49017" title="CVE-2022-49017" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48958" id="CVE-2022-48958" title="CVE-2022-48958" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48962" id="CVE-2022-48962" title="CVE-2022-48962" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48956" id="CVE-2022-48956" title="CVE-2022-48956" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50033" id="CVE-2024-50033" title="CVE-2024-50033" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50063" id="CVE-2024-50063" title="CVE-2024-50063" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49004" id="CVE-2022-49004" title="CVE-2022-49004" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48975" id="CVE-2022-48975" title="CVE-2022-48975" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48982" id="CVE-2022-48982" title="CVE-2022-48982" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48981" id="CVE-2022-48981" title="CVE-2022-48981" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48972" id="CVE-2022-48972" title="CVE-2022-48972" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48961" id="CVE-2022-48961" title="CVE-2022-48961" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49020" id="CVE-2022-49020" title="CVE-2022-49020" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48995" id="CVE-2022-48995" title="CVE-2022-48995" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49881" id="CVE-2024-49881" title="CVE-2024-49881" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50067" id="CVE-2024-50067" title="CVE-2024-50067" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50083" id="CVE-2024-50083" title="CVE-2024-50083" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46685" id="CVE-2024-46685" title="CVE-2024-46685" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46702" id="CVE-2024-46702" title="CVE-2024-46702" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46815" id="CVE-2024-46815" title="CVE-2024-46815" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47679" id="CVE-2024-47679" title="CVE-2024-47679" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47726" id="CVE-2024-47726" title="CVE-2024-47726" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49859" id="CVE-2024-49859" title="CVE-2024-49859" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50002" id="CVE-2024-50002" title="CVE-2024-50002" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49983" id="CVE-2024-49983" title="CVE-2024-49983" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49948" id="CVE-2024-49948" title="CVE-2024-49948" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49896" id="CVE-2024-49896" title="CVE-2024-49896" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49949" id="CVE-2024-49949" title="CVE-2024-49949" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50013" id="CVE-2024-50013" title="CVE-2024-50013" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50006" id="CVE-2024-50006" title="CVE-2024-50006" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50014" id="CVE-2024-50014" title="CVE-2024-50014" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49967" id="CVE-2024-49967" title="CVE-2024-49967" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49878" id="CVE-2024-49878" title="CVE-2024-49878" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49960" id="CVE-2024-49960" title="CVE-2024-49960" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50082" id="CVE-2024-50082" title="CVE-2024-50082" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50095" id="CVE-2024-50095" title="CVE-2024-50095" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50133" id="CVE-2024-50133" title="CVE-2024-50133" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50131" id="CVE-2024-50131" title="CVE-2024-50131" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50154" id="CVE-2024-50154" title="CVE-2024-50154" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50142" id="CVE-2024-50142" title="CVE-2024-50142" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35833" id="CVE-2024-35833" title="CVE-2024-35833" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36005" id="CVE-2024-36005" title="CVE-2024-36005" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36950" id="CVE-2024-36950" title="CVE-2024-36950" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48878" id="CVE-2022-48878" title="CVE-2022-48878" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43911" id="CVE-2024-43911" title="CVE-2024-43911" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47663" id="CVE-2024-47663" title="CVE-2024-47663" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47666" id="CVE-2024-47666" title="CVE-2024-47666" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47728" id="CVE-2024-47728" title="CVE-2024-47728" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49982" id="CVE-2024-49982" title="CVE-2024-49982" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49945" id="CVE-2024-49945" title="CVE-2024-49945" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49914" id="CVE-2024-49914" title="CVE-2024-49914" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49963" id="CVE-2024-49963" title="CVE-2024-49963" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48953" id="CVE-2022-48953" title="CVE-2022-48953" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49026" id="CVE-2022-49026" title="CVE-2022-49026" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50099" id="CVE-2024-50099" title="CVE-2024-50099" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50138" id="CVE-2024-50138" title="CVE-2024-50138" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50115" id="CVE-2024-50115" title="CVE-2024-50115" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50195" id="CVE-2024-50195" title="CVE-2024-50195" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50184" id="CVE-2024-50184" title="CVE-2024-50184" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50210" id="CVE-2024-50210" title="CVE-2024-50210" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50198" id="CVE-2024-50198" title="CVE-2024-50198" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50247" id="CVE-2024-50247" title="CVE-2024-50247" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50242" id="CVE-2024-50242" title="CVE-2024-50242" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50237" id="CVE-2024-50237" title="CVE-2024-50237" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50245" id="CVE-2024-50245" title="CVE-2024-50245" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50246" id="CVE-2024-50246" title="CVE-2024-50246" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52784" id="CVE-2023-52784" title="CVE-2023-52784" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52885" id="CVE-2023-52885" title="CVE-2023-52885" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46713" id="CVE-2024-46713" title="CVE-2024-46713" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47735" id="CVE-2024-47735" title="CVE-2024-47735" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47749" id="CVE-2024-47749" title="CVE-2024-47749" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47747" id="CVE-2024-47747" title="CVE-2024-47747" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47745" id="CVE-2024-47745" title="CVE-2024-47745" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49899" id="CVE-2024-49899" title="CVE-2024-49899" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49929" id="CVE-2024-49929" title="CVE-2024-49929" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49952" id="CVE-2024-49952" title="CVE-2024-49952" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50038" id="CVE-2024-50038" title="CVE-2024-50038" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50045" id="CVE-2024-50045" title="CVE-2024-50045" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50062" id="CVE-2024-50062" title="CVE-2024-50062" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48969" id="CVE-2022-48969" title="CVE-2022-48969" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50073" id="CVE-2024-50073" title="CVE-2024-50073" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50089" id="CVE-2024-50089" title="CVE-2024-50089" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50143" id="CVE-2024-50143" title="CVE-2024-50143" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50179" id="CVE-2024-50179" title="CVE-2024-50179" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50180" id="CVE-2024-50180" title="CVE-2024-50180" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50192" id="CVE-2024-50192" title="CVE-2024-50192" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50202" id="CVE-2024-50202" title="CVE-2024-50202" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50205" id="CVE-2024-50205" title="CVE-2024-50205" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50229" id="CVE-2024-50229" title="CVE-2024-50229" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50262" id="CVE-2024-50262" title="CVE-2024-50262" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50248" id="CVE-2024-50248" title="CVE-2024-50248" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50244" id="CVE-2024-50244" title="CVE-2024-50244" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50241" id="CVE-2024-50241" title="CVE-2024-50241" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50230" id="CVE-2024-50230" title="CVE-2024-50230" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50151" id="CVE-2024-50151" title="CVE-2024-50151" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50301" id="CVE-2024-50301" title="CVE-2024-50301" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50289" id="CVE-2024-50289" title="CVE-2024-50289" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50273" id="CVE-2024-50273" title="CVE-2024-50273" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50269" id="CVE-2024-50269" title="CVE-2024-50269" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50265" id="CVE-2024-50265" title="CVE-2024-50265" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53052" id="CVE-2024-53052" title="CVE-2024-53052" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53066" id="CVE-2024-53066" title="CVE-2024-53066" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53061" id="CVE-2024-53061" title="CVE-2024-53061" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46813" id="CVE-2024-46813" title="CVE-2024-46813" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47707" id="CVE-2024-47707" title="CVE-2024-47707" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47718" id="CVE-2024-47718" title="CVE-2024-47718" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49930" id="CVE-2024-49930" title="CVE-2024-49930" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49977" id="CVE-2024-49977" title="CVE-2024-49977" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49891" id="CVE-2024-49891" title="CVE-2024-49891" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49938" id="CVE-2024-49938" title="CVE-2024-49938" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49997" id="CVE-2024-49997" title="CVE-2024-49997" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49944" id="CVE-2024-49944" title="CVE-2024-49944" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50024" id="CVE-2024-50024" title="CVE-2024-50024" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50044" id="CVE-2024-50044" title="CVE-2024-50044" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50039" id="CVE-2024-50039" title="CVE-2024-50039" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50135" id="CVE-2024-50135" title="CVE-2024-50135" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50171" id="CVE-2024-50171" title="CVE-2024-50171" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50148" id="CVE-2024-50148" title="CVE-2024-50148" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50208" id="CVE-2024-50208" title="CVE-2024-50208" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50209" id="CVE-2024-50209" title="CVE-2024-50209" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50196" id="CVE-2024-50196" title="CVE-2024-50196" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50236" id="CVE-2024-50236" title="CVE-2024-50236" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50234" id="CVE-2024-50234" title="CVE-2024-50234" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50299" id="CVE-2024-50299" title="CVE-2024-50299" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53059" id="CVE-2024-53059" title="CVE-2024-53059" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53073" id="CVE-2024-53073" title="CVE-2024-53073" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53063" id="CVE-2024-53063" title="CVE-2024-53063" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53090" id="CVE-2024-53090" title="CVE-2024-53090" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53099" id="CVE-2024-53099" title="CVE-2024-53099" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53101" id="CVE-2024-53101" title="CVE-2024-53101" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47713" id="CVE-2024-47713" title="CVE-2024-47713" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49861" id="CVE-2024-49861" title="CVE-2024-49861" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49906" id="CVE-2024-49906" title="CVE-2024-49906" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49993" id="CVE-2024-49993" title="CVE-2024-49993" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49923" id="CVE-2024-49923" title="CVE-2024-49923" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50127" id="CVE-2024-50127" title="CVE-2024-50127" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50103" id="CVE-2024-50103" title="CVE-2024-50103" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50134" id="CVE-2024-50134" title="CVE-2024-50134" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50201" id="CVE-2024-50201" title="CVE-2024-50201" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50278" id="CVE-2024-50278" title="CVE-2024-50278" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50267" id="CVE-2024-50267" title="CVE-2024-50267" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50292" id="CVE-2024-50292" title="CVE-2024-50292" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50302" id="CVE-2024-50302" title="CVE-2024-50302" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50290" id="CVE-2024-50290" title="CVE-2024-50290" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53054" id="CVE-2024-53054" title="CVE-2024-53054" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53095" id="CVE-2024-53095" title="CVE-2024-53095" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52922" id="CVE-2023-52922" title="CVE-2023-52922" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53104" id="CVE-2024-53104" title="CVE-2024-53104" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53110" id="CVE-2024-53110" title="CVE-2024-53110" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53112" id="CVE-2024-53112" title="CVE-2024-53112" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53125" id="CVE-2024-53125" title="CVE-2024-53125" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53130" id="CVE-2024-53130" title="CVE-2024-53130" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48868" id="CVE-2022-48868" title="CVE-2022-48868" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53142" id="CVE-2024-53142" title="CVE-2024-53142" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48868" id="CVE-2022-48868" title="CVE-2022-48868" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46765" id="CVE-2024-46765" title="CVE-2024-46765" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49022" id="CVE-2022-49022" title="CVE-2022-49022" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49028" id="CVE-2022-49028" title="CVE-2022-49028" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49014" id="CVE-2022-49014" title="CVE-2022-49014" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48971" id="CVE-2022-48971" title="CVE-2022-48971" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48949" id="CVE-2022-48949" title="CVE-2022-48949" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49015" id="CVE-2022-49015" title="CVE-2022-49015" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50086" id="CVE-2024-50086" title="CVE-2024-50086" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50218" id="CVE-2024-50218" title="CVE-2024-50218" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53142" id="CVE-2024-53142" title="CVE-2024-53142" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53150" id="CVE-2024-53150" title="CVE-2024-53150" type="cve"></reference>
		</references>
		<description>CVE-2024-27436:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: usb-audio: Stop parsing channels bits when all channels are found.&#xA;If a usb audio device sets more bits than the amount of channels&#xA;it could write outside of the map array.&#xA;CVE-2024-36894:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete&#xA;FFS based applications can utilize the aio_cancel() callback to dequeue&#xA;pending USB requests submitted to the UDC.  There is a scenario where the&#xA;FFS application issues an AIO cancel call, while the UDC is handling a&#xA;soft disconnect.  For a DWC3 based implementation, the callstack looks&#xA;like the following:&#xA;    DWC3 Gadget                               FFS Application&#xA;dwc3_gadget_soft_disconnect()              ...&#xA;  --&gt; dwc3_stop_active_transfers()&#xA;    --&gt; dwc3_gadget_giveback(-ESHUTDOWN)&#xA;      --&gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()&#xA;        --&gt; usb_ep_free_request()            --&gt; usb_ep_dequeue()&#xA;There is currently no locking implemented between the AIO completion&#xA;handler and AIO cancel, so the issue occurs if the completion routine is&#xA;running in parallel to an AIO cancel call coming from the FFS application.&#xA;As the completion call frees the USB request (io_data-&gt;req) the FFS&#xA;application is also referencing it for the usb_ep_dequeue() call.  This can&#xA;lead to accessing a stale/hanging pointer.&#xA;commit b566d38857fc (&#34;usb: gadget: f_fs: use io_data-&gt;status consistently&#34;)&#xA;relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().&#xA;However, in order to properly implement locking to mitigate this issue, the&#xA;spinlock can&#39;t be added to ffs_epfile_async_io_complete(), as&#xA;usb_ep_dequeue() (if successfully dequeuing a USB request) will call the&#xA;function driver&#39;s completion handler in the same context.  Hence, leading&#xA;into a deadlock.&#xA;Fix this issue by moving the usb_ep_free_request() back to&#xA;ffs_user_copy_worker(), and ensuring that it explicitly sets io_data-&gt;req&#xA;to NULL after freeing it within the ffs-&gt;eps_lock.  This resolves the race&#xA;condition above, as the ffs_aio_cancel() routine will not continue&#xA;attempting to dequeue a request that has already been freed, or the&#xA;ffs_user_copy_work() not freeing the USB request until the AIO cancel is&#xA;done referencing it.&#xA;This fix depends on&#xA;  commit b566d38857fc (&#34;usb: gadget: f_fs: use io_data-&gt;status&#xA;  consistently&#34;)&#xA;CVE-2024-38560:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: bfa: Ensure the copied buf is NUL terminated&#xA;Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from&#xA;userspace to that buffer. Later, we use sscanf on this buffer but we don&#39;t&#xA;ensure that the string is terminated inside the buffer, this can lead to&#xA;OOB read when using sscanf. Fix this issue by using memdup_user_nul instead&#xA;of memdup_user.&#xA;CVE-2024-38659:In the Linux kernel, the following vulnerability has been resolved:&#xA;enic: Validate length of nl attributes in enic_set_vf_port&#xA;enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE&#xA;is of length PORT_PROFILE_MAX and that the nl attributes&#xA;IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.&#xA;These attributes are validated (in the function do_setlink in rtnetlink.c)&#xA;using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE&#xA;as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and&#xA;IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation&#xA;using the policy is for the max size of the attributes and not on exact&#xA;size so the length of these attributes might be less than the sizes that&#xA;enic_set_vf_port expects. This might cause an out of bands&#xA;read access in the memcpys of the data of these&#xA;attributes in enic_set_vf_port.&#xA;CVE-2024-39482:In the Linux kernel, the following vulnerability has been resolved:&#xA;bcache: fix variable length array abuse in btree_iter&#xA;btree_iter is used in two ways: either allocated on the stack with a&#xA;fixed size MAX_BSETS, or from a mempool with a dynamic size based on the&#xA;specific cache set. Previously, the struct had a fixed-length array of&#xA;size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized&#xA;iterators, which causes UBSAN to complain.&#xA;This patch uses the same approach as in bcachefs&#39;s sort_iter and splits&#xA;the iterator into a btree_iter with a flexible array member and a&#xA;btree_iter_stack which embeds a btree_iter as well as a fixed-length&#xA;data array.&#xA;CVE-2024-40978:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qedi: Fix crash while reading debugfs attribute&#xA;The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly&#xA;on a __user pointer, which results into the crash.&#xA;To fix this issue, use a small local stack buffer for sprintf() and then&#xA;call simple_read_from_buffer(), which in turns make the copy_to_user()&#xA;call.&#xA;BUG: unable to handle page fault for address: 00007f4801111000&#xA;PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0&#xA;Oops: 0002 [#1] PREEMPT SMP PTI&#xA;Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023&#xA;RIP: 0010:memcpy_orig+0xcd/0x130&#xA;RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202&#xA;RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f&#xA;RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000&#xA;RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572&#xA;R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff&#xA;R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af&#xA;FS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body+0x1a/0x60&#xA; ? page_fault_oops+0x183/0x510&#xA; ? exc_page_fault+0x69/0x150&#xA; ? asm_exc_page_fault+0x22/0x30&#xA; ? memcpy_orig+0xcd/0x130&#xA; vsnprintf+0x102/0x4c0&#xA; sprintf+0x51/0x80&#xA; qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]&#xA; full_proxy_read+0x50/0x80&#xA; vfs_read+0xa5/0x2e0&#xA; ? folio_add_new_anon_rmap+0x44/0xa0&#xA; ? set_pte_at+0x15/0x30&#xA; ? do_pte_missing+0x426/0x7f0&#xA; ksys_read+0xa5/0xe0&#xA; do_syscall_64+0x58/0x80&#xA; ? __count_memcg_events+0x46/0x90&#xA; ? count_memcg_event_mm+0x3d/0x60&#xA; ? handle_mm_fault+0x196/0x2f0&#xA; ? do_user_addr_fault+0x267/0x890&#xA; ? exc_page_fault+0x69/0x150&#xA; entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;RIP: 0033:0x7f4800f20b4d&#xA;CVE-2024-39501:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers: core: synchronize really_probe() and dev_uevent()&#xA;Synchronize the dev-&gt;driver usage in really_probe() and dev_uevent().&#xA;These can run in different threads, what can result in the following&#xA;race condition for dev-&gt;driver uninitialization:&#xA;Thread #1:&#xA;==========&#xA;really_probe() {&#xA;...&#xA;probe_failed:&#xA;...&#xA;device_unbind_cleanup(dev) {&#xA;    ...&#xA;    dev-&gt;driver = NULL;   // &lt;= Failed probe sets dev-&gt;driver to NULL&#xA;    ...&#xA;    }&#xA;...&#xA;}&#xA;Thread #2:&#xA;==========&#xA;dev_uevent() {&#xA;...&#xA;if (dev-&gt;driver)&#xA;      // If dev-&gt;driver is NULLed from really_probe() from here on,&#xA;      // after above check, the system crashes&#xA;      add_uevent_var(env, &#34;DRIVER=%s&#34;, dev-&gt;driver-&gt;name);&#xA;...&#xA;}&#xA;really_probe() holds the lock, already. So nothing needs to be done&#xA;there. dev_uevent() is called with lock held, often, too. But not&#xA;always. What implies that we can&#39;t add any locking in dev_uevent()&#xA;itself. So fix this race by adding the lock to the non-protected&#xA;path. This is the path where above race is observed:&#xA; dev_uevent+0x235/0x380&#xA; uevent_show+0x10c/0x1f0  &lt;= Add lock here&#xA; dev_attr_show+0x3a/0xa0&#xA; sysfs_kf_seq_show+0x17c/0x250&#xA; kernfs_seq_show+0x7c/0x90&#xA; seq_read_iter+0x2d7/0x940&#xA; kernfs_fop_read_iter+0xc6/0x310&#xA; vfs_read+0x5bc/0x6b0&#xA; ksys_read+0xeb/0x1b0&#xA; __x64_sys_read+0x42/0x50&#xA; x64_sys_call+0x27ad/0x2d30&#xA; do_syscall_64+0xcd/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Similar cases are reported by syzkaller in&#xA;https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a&#xA;But these are regarding the *initialization* of dev-&gt;driver&#xA;dev-&gt;driver = drv;&#xA;As this switches dev-&gt;driver to non-NULL these reports can be considered&#xA;to be false-positives (which should be &#34;fixed&#34; by this commit, as well,&#xA;though).&#xA;The same issue was reported and tried to be fixed back in 2015 in&#xA;https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/&#xA;already.&#xA;CVE-2024-41030:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: discard write access to the directory open&#xA;may_open() does not allow a directory to be opened with the write access.&#xA;However, some writing flags set by client result in adding write access&#xA;on server, making ksmbd incompatible with FUSE file system. Simply, let&#39;s&#xA;discard the write access when opening a directory.&#xA;list_add corruption. next is NULL.&#xA;------------[ cut here ]------------&#xA;kernel BUG at lib/list_debug.c:26!&#xA;pc : __list_add_valid+0x88/0xbc&#xA;lr : __list_add_valid+0x88/0xbc&#xA;Call trace:&#xA;__list_add_valid+0x88/0xbc&#xA;fuse_finish_open+0x11c/0x170&#xA;fuse_open_common+0x284/0x5e8&#xA;fuse_dir_open+0x14/0x24&#xA;do_dentry_open+0x2a4/0x4e0&#xA;dentry_open+0x50/0x80&#xA;smb2_open+0xbe4/0x15a4&#xA;handle_ksmbd_work+0x478/0x5ec&#xA;process_one_work+0x1b4/0x448&#xA;worker_thread+0x25c/0x430&#xA;kthread+0x104/0x1d4&#xA;ret_from_fork+0x10/0x20&#xA;CVE-2024-41095:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes&#xA;In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is&#xA;assigned to mode, which will lead to a possible NULL pointer dereference&#xA;on failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2024-43846:In the Linux kernel, the following vulnerability has been resolved:&#xA;lib: objagg: Fix general protection fault&#xA;The library supports aggregation of objects into other objects only if&#xA;the parent object does not have a parent itself. That is, nesting is not&#xA;supported.&#xA;Aggregation happens in two cases: Without and with hints, where hints&#xA;are a pre-computed recommendation on how to aggregate the provided&#xA;objects.&#xA;Nesting is not possible in the first case due to a check that prevents&#xA;it, but in the second case there is no check because the assumption is&#xA;that nesting cannot happen when creating objects based on hints. The&#xA;violation of this assumption leads to various warnings and eventually to&#xA;a general protection fault [1].&#xA;Before fixing the root cause, error out when nesting happens and warn.&#xA;[1]&#xA;general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work&#xA;RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0&#xA; mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0&#xA; mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510&#xA; process_one_work+0x151/0x370&#xA; worker_thread+0x2cb/0x3e0&#xA; kthread+0xd0/0x100&#xA; ret_from_fork+0x34/0x50&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;CVE-2024-43863:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vmwgfx: Fix a deadlock in dma buf fence polling&#xA;Introduce a version of the fence ops that on release doesn&#39;t remove&#xA;the fence from the pending list, and thus doesn&#39;t require a lock to&#xA;fix poll-&gt;fence wait-&gt;fence unref deadlocks.&#xA;vmwgfx overwrites the wait callback to iterate over the list of all&#xA;fences and update their status, to do that it holds a lock to prevent&#xA;the list modifcations from other threads. The fence destroy callback&#xA;both deletes the fence and removes it from the list of pending&#xA;fences, for which it holds a lock.&#xA;dma buf polling cb unrefs a fence after it&#39;s been signaled: so the poll&#xA;calls the wait, which signals the fences, which are being destroyed.&#xA;The destruction tries to acquire the lock on the pending fences list&#xA;which it can never get because it&#39;s held by the wait from which it&#xA;was called.&#xA;Old bug, but not a lot of userspace apps were using dma-buf polling&#xA;interfaces. Fix those, in particular this fixes KDE stalls/deadlock.&#xA;CVE-2024-44939:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix null ptr deref in dtInsertEntry&#xA;[syzbot reported]&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713&#xA;...&#xA;[Analyze]&#xA;In dtInsertEntry(), when the pointer h has the same value as p, after writing&#xA;name in UniStrncpy_to_le(), p-&gt;header.flag will be cleared. This will cause the&#xA;previously true judgment &#34;p-&gt;header.flag &amp; BT-LEAF&#34; to change to no after writing&#xA;the name operation, this leads to entering an incorrect branch and accessing the&#xA;uninitialized object ih when judging this condition for the second time.&#xA;[Fix]&#xA;After got the page, check freelist first, if freelist == 0 then exit dtInsert()&#xA;and return -EINVAL.&#xA;CVE-2024-43900:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: xc2028: avoid use-after-free in load_firmware_cb()&#xA;syzkaller reported use-after-free in load_firmware_cb() [1].&#xA;The reason is because the module allocated a struct tuner in tuner_probe(),&#xA;and then the module initialization failed, the struct tuner was released.&#xA;A worker which created during module initialization accesses this struct&#xA;tuner later, it caused use-after-free.&#xA;The process is as follows:&#xA;task-6504           worker_thread&#xA;tuner_probe                             &lt;= alloc dvb_frontend [2]&#xA;...&#xA;request_firmware_nowait                 &lt;= create a worker&#xA;...&#xA;tuner_remove                            &lt;= free dvb_frontend&#xA;...&#xA;                    request_firmware_work_func  &lt;= the firmware is ready&#xA;                    load_firmware_cb    &lt;= but now the dvb_frontend has been freed&#xA;To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is&#xA;null, report a warning and just return.&#xA;[1]:&#xA;    ==================================================================&#xA;     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0&#xA;     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504&#xA;     Call trace:&#xA;      load_firmware_cb+0x1310/0x17a0&#xA;      request_firmware_work_func+0x128/0x220&#xA;      process_one_work+0x770/0x1824&#xA;      worker_thread+0x488/0xea0&#xA;      kthread+0x300/0x430&#xA;      ret_from_fork+0x10/0x20&#xA;     Allocated by task 6504:&#xA;      kzalloc&#xA;      tuner_probe+0xb0/0x1430&#xA;      i2c_device_probe+0x92c/0xaf0&#xA;      really_probe+0x678/0xcd0&#xA;      driver_probe_device+0x280/0x370&#xA;      __device_attach_driver+0x220/0x330&#xA;      bus_for_each_drv+0x134/0x1c0&#xA;      __device_attach+0x1f4/0x410&#xA;      device_initial_probe+0x20/0x30&#xA;      bus_probe_device+0x184/0x200&#xA;      device_add+0x924/0x12c0&#xA;      device_register+0x24/0x30&#xA;      i2c_new_device+0x4e0/0xc44&#xA;      v4l2_i2c_new_subdev_board+0xbc/0x290&#xA;      v4l2_i2c_new_subdev+0xc8/0x104&#xA;      em28xx_v4l2_init+0x1dd0/0x3770&#xA;     Freed by task 6504:&#xA;      kfree+0x238/0x4e4&#xA;      tuner_remove+0x144/0x1c0&#xA;      i2c_device_remove+0xc8/0x290&#xA;      __device_release_driver+0x314/0x5fc&#xA;      device_release_driver+0x30/0x44&#xA;      bus_remove_device+0x244/0x490&#xA;      device_del+0x350/0x900&#xA;      device_unregister+0x28/0xd0&#xA;      i2c_unregister_device+0x174/0x1d0&#xA;      v4l2_device_unregister+0x224/0x380&#xA;      em28xx_v4l2_init+0x1d90/0x3770&#xA;     The buggy address belongs to the object at ffff8000d7ca2000&#xA;      which belongs to the cache kmalloc-2k of size 2048&#xA;     The buggy address is located 776 bytes inside of&#xA;      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)&#xA;     The buggy address belongs to the page:&#xA;     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0&#xA;     flags: 0x7ff800000000100(slab)&#xA;     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000&#xA;     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000&#xA;     page dumped because: kasan: bad access detected&#xA;     Memory state around the buggy address:&#xA;      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;     &gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;                           ^&#xA;      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;     ==================================================================&#xA;[2]&#xA;    Actually, it is allocated for struct tuner, and dvb_frontend is inside.&#xA;CVE-2024-44958:In the Linux kernel, the following vulnerability has been resolved:&#xA;sched/smt: Fix unbalance sched_smt_present dec/inc&#xA;I got the following warn report while doing stress test:&#xA;jump label: negative count!&#xA;WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __static_key_slow_dec_cpuslocked+0x16/0x70&#xA; sched_cpu_deactivate+0x26e/0x2a0&#xA; cpuhp_invoke_callback+0x3ad/0x10d0&#xA; cpuhp_thread_fun+0x3f5/0x680&#xA; smpboot_thread_fn+0x56d/0x8d0&#xA; kthread+0x309/0x400&#xA; ret_from_fork+0x41/0x70&#xA; ret_from_fork_asm+0x1b/0x30&#xA; &lt;/TASK&gt;&#xA;Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),&#xA;the cpu offline failed, but sched_smt_present is decremented before&#xA;calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so&#xA;fix it by incrementing sched_smt_present in the error path.&#xA;CVE-2024-44952:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-44954:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: line6: Fix racy access to midibuf&#xA;There can be concurrent accesses to line6 midibuf from both the URB&#xA;completion callback and the rawmidi API access.  This could be a cause&#xA;of KMSAN warning triggered by syzkaller below (so put as reported-by&#xA;here).&#xA;This patch protects the midibuf call of the former code path with a&#xA;spinlock for avoiding the possible races.&#xA;CVE-2024-45008:In the Linux kernel, the following vulnerability has been resolved:&#xA;Input: MT - limit max slots&#xA;syzbot is reporting too large allocation at input_mt_init_slots(), for&#xA;num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).&#xA;Since nobody knows possible max slots, this patch chose 1024.&#xA;CVE-2024-44982:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails&#xA;If the dpu_format_populate_layout() fails, then FB is prepared, but not&#xA;cleaned up. This ends up leaking the pin_count on the GEM object and&#xA;causes a splat during DRM file closure:&#xA;msm_obj-&gt;pin_count&#xA;WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc&#xA;[...]&#xA;Call trace:&#xA; update_lru_locked+0xc4/0xcc&#xA; put_pages+0xac/0x100&#xA; msm_gem_free_object+0x138/0x180&#xA; drm_gem_object_free+0x1c/0x30&#xA; drm_gem_object_handle_put_unlocked+0x108/0x10c&#xA; drm_gem_object_release_handle+0x58/0x70&#xA; idr_for_each+0x68/0xec&#xA; drm_gem_release+0x28/0x40&#xA; drm_file_free+0x174/0x234&#xA; drm_release+0xb0/0x160&#xA; __fput+0xc0/0x2c8&#xA; __fput_sync+0x50/0x5c&#xA; __arm64_sys_close+0x38/0x7c&#xA; invoke_syscall+0x48/0x118&#xA; el0_svc_common.constprop.0+0x40/0xe0&#xA; do_el0_svc+0x1c/0x28&#xA; el0_svc+0x4c/0x120&#xA; el0t_64_sync_handler+0x100/0x12c&#xA; el0t_64_sync+0x190/0x194&#xA;irq event stamp: 129818&#xA;hardirqs last  enabled at (129817): [&lt;ffffa5f6d953fcc0&gt;] console_unlock+0x118/0x124&#xA;hardirqs last disabled at (129818): [&lt;ffffa5f6da7dcf04&gt;] el1_dbg+0x24/0x8c&#xA;softirqs last  enabled at (129808): [&lt;ffffa5f6d94afc18&gt;] handle_softirqs+0x4c8/0x4e8&#xA;softirqs last disabled at (129785): [&lt;ffffa5f6d94105e4&gt;] __do_softirq+0x14/0x20&#xA;Patchwork: https://patchwork.freedesktop.org/patch/600714/&#xA;CVE-2024-44950:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: sc16is7xx: fix invalid FIFO access with special register set&#xA;When enabling access to the special register set, Receiver time-out and&#xA;RHR interrupts can happen. In this case, the IRQ handler will try to read&#xA;from the FIFO thru the RHR register at address 0x00, but address 0x00 is&#xA;mapped to DLL register, resulting in erroneous FIFO reading.&#xA;Call graph example:&#xA;    sc16is7xx_startup(): entry&#xA;    sc16is7xx_ms_proc(): entry&#xA;    sc16is7xx_set_termios(): entry&#xA;    sc16is7xx_set_baud(): DLH/DLL = $009C --&gt; access special register set&#xA;    sc16is7xx_port_irq() entry            --&gt; IIR is 0x0C&#xA;    sc16is7xx_handle_rx() entry&#xA;    sc16is7xx_fifo_read(): --&gt; unable to access FIFO (RHR) because it is&#xA;                               mapped to DLL (LCR=LCR_CONF_MODE_A)&#xA;    sc16is7xx_set_baud(): exit --&gt; Restore access to general register set&#xA;Fix the problem by claiming the efr_lock mutex when accessing the Special&#xA;register set.&#xA;CVE-2024-45016:In the Linux kernel, the following vulnerability has been resolved:&#xA;netem: fix return value if duplicate enqueue fails&#xA;There is a bug in netem_enqueue() introduced by&#xA;commit 5845f706388a (&#34;net: netem: fix skb length BUG_ON in __skb_to_sgvec&#34;)&#xA;that can lead to a use-after-free.&#xA;This commit made netem_enqueue() always return NET_XMIT_SUCCESS&#xA;when a packet is duplicated, which can cause the parent qdisc&#39;s q.qlen&#xA;to be mistakenly incremented. When this happens qlen_notify() may be&#xA;skipped on the parent during destruction, leaving a dangling pointer&#xA;for some classful qdiscs like DRR.&#xA;There are two ways for the bug happen:&#xA;- If the duplicated packet is dropped by rootq-&gt;enqueue() and then&#xA;  the original packet is also dropped.&#xA;- If rootq-&gt;enqueue() sends the duplicated packet to a different qdisc&#xA;  and the original packet is dropped.&#xA;In both cases NET_XMIT_SUCCESS is returned even though no packets&#xA;are enqueued at the netem qdisc.&#xA;The fix is to defer the enqueue of the duplicate packet until after&#xA;the original packet has been guaranteed to return NET_XMIT_SUCCESS.&#xA;CVE-2024-45025:In the Linux kernel, the following vulnerability has been resolved:&#xA;fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE&#xA;copy_fd_bitmaps(new, old, count) is expected to copy the first&#xA;count/BITS_PER_LONG bits from old-&gt;full_fds_bits[] and fill&#xA;the rest with zeroes.  What it does is copying enough words&#xA;(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.&#xA;That works fine, *if* all bits past the cutoff point are&#xA;clear.  Otherwise we are risking garbage from the last word&#xA;we&#39;d copied.&#xA;For most of the callers that is true - expand_fdtable() has&#xA;count equal to old-&gt;max_fds, so there&#39;s no open descriptors&#xA;past count, let alone fully occupied words in -&gt;open_fds[],&#xA;which is what bits in -&gt;full_fds_bits[] correspond to.&#xA;The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),&#xA;which is the smallest multiple of BITS_PER_LONG that covers all&#xA;opened descriptors below max_fds.  In the common case (copying on&#xA;fork()) max_fds is ~0U, so all opened descriptors will be below&#xA;it and we are fine, by the same reasons why the call in expand_fdtable()&#xA;is safe.&#xA;Unfortunately, there is a case where max_fds is less than that&#xA;and where we might, indeed, end up with junk in -&gt;full_fds_bits[] -&#xA;close_range(from, to, CLOSE_RANGE_UNSHARE) with&#xA;&#x9;* descriptor table being currently shared&#xA;&#x9;* &#39;to&#39; being above the current capacity of descriptor table&#xA;&#x9;* &#39;from&#39; being just under some chunk of opened descriptors.&#xA;In that case we end up with observably wrong behaviour - e.g. spawn&#xA;a child with CLONE_FILES, get all descriptors in range 0..127 open,&#xA;then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending&#xA;up with descriptor #128, despite #64 being observably not open.&#xA;The minimally invasive fix would be to deal with that in dup_fd().&#xA;If this proves to add measurable overhead, we can go that way, but&#xA;let&#39;s try to fix copy_fd_bitmaps() first.&#xA;* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).&#xA;* make copy_fd_bitmaps() take the bitmap size in words, rather than&#xA;bits; it&#39;s &#39;count&#39; argument is always a multiple of BITS_PER_LONG,&#xA;so we are not losing any information, and that way we can use the&#xA;same helper for all three bitmaps - compiler will see that count&#xA;is a multiple of BITS_PER_LONG for the large ones, so it&#39;ll generate&#xA;plain memcpy()+memset().&#xA;Reproducer added to tools/testing/selftests/core/close_range_test.c&#xA;CVE-2024-46681:In the Linux kernel, the following vulnerability has been resolved:&#xA;pktgen: use cpus_read_lock() in pg_net_init()&#xA;I have seen the WARN_ON(smp_processor_id() != cpu) firing&#xA;in pktgen_thread_worker() during tests.&#xA;We must use cpus_read_lock()/cpus_read_unlock()&#xA;around the for_each_online_cpu(cpu) loop.&#xA;While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&#xA;CVE-2024-46679:In the Linux kernel, the following vulnerability has been resolved:&#xA;ethtool: check device is present when getting link settings&#xA;A sysfs reader can race with a device reset or removal, attempting to&#xA;read device state when the device is not actually present. eg:&#xA;     [exception RIP: qed_get_current_link+17]&#xA;  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]&#xA;  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3&#xA; #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4&#xA; #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300&#xA; #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c&#xA; #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b&#xA; #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3&#xA; #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1&#xA; #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f&#xA; #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb&#xA; crash&gt; struct net_device.state ffff9a9d21336000&#xA;    state = 5,&#xA;state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).&#xA;The device is not present, note lack of __LINK_STATE_PRESENT (0b10).&#xA;This is the same sort of panic as observed in commit 4224cfd7fb65&#xA;(&#34;net-sysfs: add check for netdevice being present to speed_show&#34;).&#xA;There are many other callers of __ethtool_get_link_ksettings() which&#xA;don&#39;t have a device presence check.&#xA;Move this check into ethtool to protect all callers.&#xA;CVE-2024-46695:In the Linux kernel, the following vulnerability has been resolved:&#xA;selinux,smack: don&#39;t bypass permissions check in inode_setsecctx hook&#xA;Marek Gresko reports that the root user on an NFS client is able to&#xA;change the security labels on files on an NFS filesystem that is&#xA;exported with root squashing enabled.&#xA;The end of the kerneldoc comment for __vfs_setxattr_noperm() states:&#xA; *  This function requires the caller to lock the inode&#39;s i_mutex before it&#xA; *  is executed. It also assumes that the caller will make the appropriate&#xA; *  permission checks.&#xA;nfsd_setattr() does do permissions checking via fh_verify() and&#xA;nfsd_permission(), but those don&#39;t do all the same permissions checks&#xA;that are done by security_inode_setxattr() and its related LSM hooks do.&#xA;Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),&#xA;simplest solution appears to be to replace the call to&#xA;__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This&#xA;fixes the above issue and has the added benefit of causing nfsd to&#xA;recall conflicting delegations on a file when a client tries to change&#xA;its security label.&#xA;CVE-2024-46707:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3&#xA;On a system with a GICv3, if a guest hasn&#39;t been configured with&#xA;GICv3 and that the host is not capable of GICv2 emulation,&#xA;a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.&#xA;We therefore try to emulate the SGI access, only to hit a NULL&#xA;pointer as no private interrupt is allocated (no GIC, remember?).&#xA;The obvious fix is to give the guest what it deserves, in the&#xA;shape of a UNDEF exception.&#xA;CVE-2024-46673:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: aacraid: Fix double-free on probe failure&#xA;aac_probe_one() calls hardware-specific init functions through the&#xA;aac_driver_ident::init pointer, all of which eventually call down to&#xA;aac_init_adapter().&#xA;If aac_init_adapter() fails after allocating memory for aac_dev::queues,&#xA;it frees the memory but does not clear that member.&#xA;After the hardware-specific init function returns an error,&#xA;aac_probe_one() goes down an error path that frees the memory pointed to&#xA;by aac_dev::queues, resulting.in a double-free.&#xA;CVE-2024-46674:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: dwc3: st: fix probed platform device ref count on probe error path&#xA;The probe function never performs any paltform device allocation, thus&#xA;error path &#34;undo_platform_dev_alloc&#34; is entirely bogus.  It drops the&#xA;reference count from the platform device being probed.  If error path is&#xA;triggered, this will lead to unbalanced device reference counts and&#xA;premature release of device resources, thus possible use-after-free when&#xA;releasing remaining devm-managed resources.&#xA;CVE-2024-46715:In the Linux kernel, the following vulnerability has been resolved:&#xA;driver: iio: add missing checks on iio_info&#39;s callback access&#xA;Some callbacks from iio_info structure are accessed without any check, so&#xA;if a driver doesn&#39;t implement them trying to access the corresponding&#xA;sysfs entries produce a kernel oops such as:&#xA;[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute&#xA;[...]&#xA;[ 2203.783416] Call trace:&#xA;[ 2203.783429]  iio_read_channel_info_avail from dev_attr_show+0x18/0x48&#xA;[ 2203.789807]  dev_attr_show from sysfs_kf_seq_show+0x90/0x120&#xA;[ 2203.794181]  sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4&#xA;[ 2203.798555]  seq_read_iter from vfs_read+0x238/0x2a0&#xA;[ 2203.802236]  vfs_read from ksys_read+0xa4/0xd4&#xA;[ 2203.805385]  ksys_read from ret_fast_syscall+0x0/0x54&#xA;[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)&#xA;[ 2203.812880] dfa0:                   00000003 b6f10f80 00000003 b6eab000 00020000 00000000&#xA;[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000&#xA;[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0&#xA;[ 2203.830363] Code: bad PC value&#xA;[ 2203.832695] ---[ end trace 0000000000000000 ]---&#xA;CVE-2024-46719:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: typec: ucsi: Fix null pointer dereference in trace&#xA;ucsi_register_altmode checks IS_ERR for the alt pointer and treats&#xA;NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,&#xA;ucsi_register_displayport returns NULL which causes a NULL pointer&#xA;dereference in trace. Rather than return NULL, call&#xA;typec_port_register_altmode to register DisplayPort alternate mode&#xA;as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.&#xA;CVE-2024-46726:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Ensure index calculation will not overflow&#xA;[WHY &amp; HOW]&#xA;Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will&#xA;never overflow and exceess array size.&#xA;This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.&#xA;CVE-2024-46725:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix out-of-bounds write warning&#xA;Check the ring type value to fix the out-of-bounds&#xA;write warning&#xA;CVE-2024-46721:In the Linux kernel, the following vulnerability has been resolved:&#xA;apparmor: fix possible NULL pointer dereference&#xA;profile-&gt;parent-&gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made&#xA;from __create_missing_ancestors(..) and &#39;ent-&gt;old&#39; is NULL in&#xA;aa_replace_profiles(..).&#xA;In that case, it must return an error code and the code, -ENOENT represents&#xA;its state that the path of its parent is not existed yet.&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000030&#xA;PGD 0 P4D 0&#xA;PREEMPT SMP PTI&#xA;CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014&#xA;RIP: 0010:aafs_create.constprop.0+0x7f/0x130&#xA;Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae&#xA;RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_regs+0x6d/0x80&#xA; ? __die+0x24/0x80&#xA; ? page_fault_oops+0x99/0x1b0&#xA; ? kernelmode_fixup_or_oops+0xb2/0x140&#xA; ? __bad_area_nosemaphore+0x1a5/0x2c0&#xA; ? find_vma+0x34/0x60&#xA; ? bad_area_nosemaphore+0x16/0x30&#xA; ? do_user_addr_fault+0x2a2/0x6b0&#xA; ? exc_page_fault+0x83/0x1b0&#xA; ? asm_exc_page_fault+0x27/0x30&#xA; ? aafs_create.constprop.0+0x7f/0x130&#xA; ? aafs_create.constprop.0+0x51/0x130&#xA; __aafs_profile_mkdir+0x3d6/0x480&#xA; aa_replace_profiles+0x83f/0x1270&#xA; policy_update+0xe3/0x180&#xA; profile_load+0xbc/0x150&#xA; ? rw_verify_area+0x47/0x140&#xA; vfs_write+0x100/0x480&#xA; ? __x64_sys_openat+0x55/0xa0&#xA; ? syscall_exit_to_user_mode+0x86/0x260&#xA; ksys_write+0x73/0x100&#xA; __x64_sys_write+0x19/0x30&#xA; x64_sys_call+0x7e/0x25c0&#xA; do_syscall_64+0x7f/0x180&#xA; entry_SYSCALL_64_after_hwframe+0x78/0x80&#xA;RIP: 0033:0x7be9f211c574&#xA;Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89&#xA;RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574&#xA;RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004&#xA;RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000&#xA;R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80&#xA;R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30&#xA; &lt;/TASK&gt;&#xA;Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas&#xA;CR2: 0000000000000030&#xA;---[ end trace 0000000000000000 ]---&#xA;RIP: 0010:aafs_create.constprop.0+0x7f/0x130&#xA;Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae&#xA;RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000&#xA;---truncated---&#xA;CVE-2024-46732:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Assign linear_pitch_alignment even for VM&#xA;[Description]&#xA;Assign linear_pitch_alignment so we don&#39;t cause a divide by 0&#xA;error in VM environments&#xA;CVE-2024-46771:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: bcm: Remove proc entry when dev is unregistered.&#xA;syzkaller reported a warning in bcm_connect() below. [0]&#xA;The repro calls connect() to vxcan1, removes vxcan1, and calls&#xA;connect() with ifindex == 0.&#xA;Calling connect() for a BCM socket allocates a proc entry.&#xA;Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().&#xA;However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0&#xA;in bcm_notify().&#xA;The 2nd connect() tries to allocate a proc entry with the same&#xA;name and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking the&#xA;original proc entry.&#xA;Since the proc entry is available only for connect()ed sockets,&#xA;let&#39;s clean up the entry when the bound netdev is unregistered.&#xA;[0]:&#xA;proc_dir_entry &#39;can-bcm/2456&#39; already registered&#xA;WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375&#xA;Modules linked in:&#xA;CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375&#xA;Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 &lt;0f&gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48&#xA;RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246&#xA;RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002&#xA;RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0&#xA;R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec&#xA;FS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220&#xA; bcm_connect+0x472/0x840 net/can/bcm.c:1673&#xA; __sys_connect_file net/socket.c:2049 [inline]&#xA; __sys_connect+0x5d2/0x690 net/socket.c:2066&#xA; __do_sys_connect net/socket.c:2076 [inline]&#xA; __se_sys_connect net/socket.c:2073 [inline]&#xA; __x64_sys_connect+0x8f/0x100 net/socket.c:2073&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;RIP: 0033:0x7fbd708b0e5d&#xA;Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48&#xA;RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a&#xA;RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d&#xA;RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003&#xA;RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040&#xA;R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098&#xA;R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000&#xA; &lt;/TASK&gt;&#xA;remove_proc_entry: removing non-empty directory &#39;net/can-bcm&#39;, leaking at least &#39;2456&#39;&#xA;CVE-2024-46739:In the Linux kernel, the following vulnerability has been resolved:&#xA;uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind&#xA;For primary VM Bus channels, primary_channel pointer is always NULL. This&#xA;pointer is valid only for the secondary channels. Also, rescind callback&#xA;is meant for primary channels only.&#xA;Fix NULL pointer dereference by retrieving the device_obj from the parent&#xA;for the primary channel.&#xA;CVE-2024-46759:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (adc128d818) Fix underflows seen when writing limit attributes&#xA;DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large&#xA;negative number such as -9223372036854775808 is provided by the user.&#xA;Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.&#xA;CVE-2024-46795:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: unset the binding mark of a reused connection&#xA;Steve French reported null pointer dereference error from sha256 lib.&#xA;cifs.ko can send session setup requests on reused connection.&#xA;If reused connection is used for binding session, conn-&gt;binding can&#xA;still remain true and generate_preauth_hash() will not set&#xA;sess-&gt;Preauth_HashValue and it will be NULL.&#xA;It is used as a material to create an encryption key in&#xA;ksmbd_gen_smb311_encryptionkey. -&gt;Preauth_HashValue cause null pointer&#xA;dereference error from crypto_shash_update().&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;#PF: supervisor read access in kernel mode&#xA;#PF: error_code(0x0000) - not-present page&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 8 PID: 429254 Comm: kworker/8:39&#xA;Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )&#xA;Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]&#xA;RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]&#xA;&lt;TASK&gt;&#xA;? show_regs+0x6d/0x80&#xA;? __die+0x24/0x80&#xA;? page_fault_oops+0x99/0x1b0&#xA;? do_user_addr_fault+0x2ee/0x6b0&#xA;? exc_page_fault+0x83/0x1b0&#xA;? asm_exc_page_fault+0x27/0x30&#xA;? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]&#xA;? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]&#xA;? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]&#xA;? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]&#xA;_sha256_update+0x77/0xa0 [sha256_ssse3]&#xA;sha256_avx2_update+0x15/0x30 [sha256_ssse3]&#xA;crypto_shash_update+0x1e/0x40&#xA;hmac_update+0x12/0x20&#xA;crypto_shash_update+0x1e/0x40&#xA;generate_key+0x234/0x380 [ksmbd]&#xA;generate_smb3encryptionkey+0x40/0x1c0 [ksmbd]&#xA;ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]&#xA;ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]&#xA;smb2_sess_setup+0x952/0xaa0 [ksmbd]&#xA;__process_request+0xa3/0x1d0 [ksmbd]&#xA;__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]&#xA;handle_ksmbd_work+0x2d/0xa0 [ksmbd]&#xA;process_one_work+0x16c/0x350&#xA;worker_thread+0x306/0x440&#xA;? __pfx_worker_thread+0x10/0x10&#xA;kthread+0xef/0x120&#xA;? __pfx_kthread+0x10/0x10&#xA;ret_from_fork+0x44/0x70&#xA;? __pfx_kthread+0x10/0x10&#xA;ret_from_fork_asm+0x1b/0x30&#xA;&lt;/TASK&gt;&#xA;CVE-2024-46750:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: Add missing bridge lock to pci_bus_lock()&#xA;One of the true positives that the cfg_access_lock lockdep effort&#xA;identified is this sequence:&#xA;  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70&#xA;  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? __warn+0x8c/0x190&#xA;   ? pci_bridge_secondary_bus_reset+0x5d/0x70&#xA;   ? report_bug+0x1f8/0x200&#xA;   ? handle_bug+0x3c/0x70&#xA;   ? exc_invalid_op+0x18/0x70&#xA;   ? asm_exc_invalid_op+0x1a/0x20&#xA;   ? pci_bridge_secondary_bus_reset+0x5d/0x70&#xA;   pci_reset_bus+0x1d8/0x270&#xA;   vmd_probe+0x778/0xa10&#xA;   pci_device_probe+0x95/0x120&#xA;Where pci_reset_bus() users are triggering unlocked secondary bus resets.&#xA;Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses&#xA;pci_bus_lock() before issuing the reset which locks everything *but* the&#xA;bridge itself.&#xA;For the same motivation as adding:&#xA;  bridge = pci_upstream_bridge(dev);&#xA;  if (bridge)&#xA;    pci_dev_lock(bridge);&#xA;to pci_reset_function() for the &#34;bus&#34; and &#34;cxl_bus&#34; reset cases, add&#xA;pci_dev_lock() for @bus-&gt;self to pci_bus_lock().&#xA;[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:&#xA;https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]&#xA;CVE-2024-46761:In the Linux kernel, the following vulnerability has been resolved:&#xA;pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv&#xA;The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel&#xA;crash when we try to hot-unplug/disable the PCIe switch/bridge from&#xA;the PHB.&#xA;The crash occurs because although the MSI data structure has been&#xA;released during disable/hot-unplug path and it has been assigned&#xA;with NULL, still during unregistration the code was again trying to&#xA;explicitly disable the MSI which causes the NULL pointer dereference and&#xA;kernel crash.&#xA;The patch fixes the check during unregistration path to prevent invoking&#xA;pci_disable_msi/msix() since its data structure is already freed.&#xA;CVE-2024-46774:In the Linux kernel, the following vulnerability has been resolved:&#xA;powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()&#xA;Smatch warns:&#xA;  arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential&#xA;  spectre issue &#39;args.args&#39; [r] (local cap)&#xA;The &#39;nargs&#39; and &#39;nret&#39; locals come directly from a user-supplied&#xA;buffer and are used as indexes into a small stack-based array and as&#xA;inputs to copy_to_user() after they are subject to bounds checks.&#xA;Use array_index_nospec() after the bounds checks to clamp these values&#xA;for speculative execution.&#xA;CVE-2024-46791:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open&#xA;The mcp251x_hw_wake() function is called with the mpc_lock mutex held and&#xA;disables the interrupt handler so that no interrupts can be processed while&#xA;waking the device. If an interrupt has already occurred then waiting for&#xA;the interrupt handler to complete will deadlock because it will be trying&#xA;to acquire the same mutex.&#xA;CPU0                           CPU1&#xA;----                           ----&#xA;mcp251x_open()&#xA; mutex_lock(&amp;priv-&gt;mcp_lock)&#xA;  request_threaded_irq()&#xA;                               &lt;interrupt&gt;&#xA;                               mcp251x_can_ist()&#xA;                                mutex_lock(&amp;priv-&gt;mcp_lock)&#xA;  mcp251x_hw_wake()&#xA;   disable_irq() &lt;-- deadlock&#xA;Use disable_irq_nosync() instead because the interrupt handler does&#xA;everything while holding the mutex so it doesn&#39;t matter if it&#39;s still&#xA;running.&#xA;CVE-2024-46743:In the Linux kernel, the following vulnerability has been resolved:&#xA;of/irq: Prevent device address out-of-bounds read in interrupt map walk&#xA;When of_irq_parse_raw() is invoked with a device address smaller than&#xA;the interrupt parent node (from #address-cells property), KASAN detects&#xA;the following out-of-bounds read when populating the initial match table&#xA;(dyndbg=&#34;func of_irq_parse_* +p&#34;):&#xA;  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0&#xA;  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2&#xA;  OF:  intspec=4&#xA;  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2&#xA;  OF:  -&gt; addrsize=3&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0&#xA;  Read of size 4 at addr ffffff81beca5608 by task bash/764&#xA;  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1&#xA;  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023&#xA;  Call trace:&#xA;   dump_backtrace+0xdc/0x130&#xA;   show_stack+0x1c/0x30&#xA;   dump_stack_lvl+0x6c/0x84&#xA;   print_report+0x150/0x448&#xA;   kasan_report+0x98/0x140&#xA;   __asan_load4+0x78/0xa0&#xA;   of_irq_parse_raw+0x2b8/0x8d0&#xA;   of_irq_parse_one+0x24c/0x270&#xA;   parse_interrupts+0xc0/0x120&#xA;   of_fwnode_add_links+0x100/0x2d0&#xA;   fw_devlink_parse_fwtree+0x64/0xc0&#xA;   device_add+0xb38/0xc30&#xA;   of_device_add+0x64/0x90&#xA;   of_platform_device_create_pdata+0xd0/0x170&#xA;   of_platform_bus_create+0x244/0x600&#xA;   of_platform_notify+0x1b0/0x254&#xA;   blocking_notifier_call_chain+0x9c/0xd0&#xA;   __of_changeset_entry_notify+0x1b8/0x230&#xA;   __of_changeset_apply_notify+0x54/0xe4&#xA;   of_overlay_fdt_apply+0xc04/0xd94&#xA;   ...&#xA;  The buggy address belongs to the object at ffffff81beca5600&#xA;   which belongs to the cache kmalloc-128 of size 128&#xA;  The buggy address is located 8 bytes inside of&#xA;   128-byte region [ffffff81beca5600, ffffff81beca5680)&#xA;  The buggy address belongs to the physical page:&#xA;  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4&#xA;  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0&#xA;  flags: 0x8000000000010200(slab|head|zone=2)&#xA;  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300&#xA;  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000&#xA;  page dumped because: kasan: bad access detected&#xA;  Memory state around the buggy address:&#xA;   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;  &gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;                        ^&#xA;   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc&#xA;  ==================================================================&#xA;  OF:  -&gt; got it !&#xA;Prevent the out-of-bounds read by copying the device address into a&#xA;buffer of sufficient size.&#xA;CVE-2024-46742:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()&#xA;null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)&#xA;and parse_lease_state() return NULL.&#xA;Fix this by check if &#39;lease_ctx_info&#39; is NULL.&#xA;Additionally, remove the redundant parentheses in&#xA;parse_durable_handle_context().&#xA;CVE-2024-46751:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: don&#39;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()&#xA;Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,&#xA;aborting the transaction and logging an error message.&#xA;CVE-2024-46800:In the Linux kernel, the following vulnerability has been resolved:&#xA;sch/netem: fix use after free in netem_dequeue&#xA;If netem_dequeue() enqueues packet to inner qdisc and that qdisc&#xA;returns __NET_XMIT_STOLEN. The packet is dropped but&#xA;qdisc_tree_reduce_backlog() is not called to update the parent&#39;s&#xA;q.qlen, leading to the similar use-after-free as Commit&#xA;e04991a48dbaf382 (&#34;netem: fix return value if duplicate enqueue&#xA;fails&#34;)&#xA;Commands to trigger KASAN UaF:&#xA;ip link add type dummy&#xA;ip link set lo up&#xA;ip link set dummy0 up&#xA;tc qdisc add dev lo parent root handle 1: drr&#xA;tc filter add dev lo parent 1: basic classid 1:1&#xA;tc class add dev lo classid 1:1 drr&#xA;tc qdisc add dev lo parent 1:1 handle 2: netem&#xA;tc qdisc add dev lo parent 2: handle 3: drr&#xA;tc filter add dev lo parent 3: basic classid 3:1 action mirred egress&#xA;redirect dev dummy0&#xA;tc class add dev lo classid 3:1 drr&#xA;ping -c1 -W0.01 localhost # Trigger bug&#xA;tc class del dev lo classid 1:1&#xA;tc class add dev lo classid 1:1 drr&#xA;ping -c1 -W0.01 localhost # UaF&#xA;CVE-2024-46777:In the Linux kernel, the following vulnerability has been resolved:&#xA;udf: Avoid excessive partition lengths&#xA;Avoid mounting filesystems where the partition would overflow the&#xA;32-bits used for block number. Also refuse to mount filesystems where&#xA;the partition length is so large we cannot safely index bits in a&#xA;block bitmap.&#xA;CVE-2024-46756:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (w83627ehf) Fix underflows seen when writing limit attributes&#xA;DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large&#xA;negative number such as -9223372036854775808 is provided by the user.&#xA;Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.&#xA;CVE-2024-46738:In the Linux kernel, the following vulnerability has been resolved:&#xA;VMCI: Fix use-after-free when removing resource in vmci_resource_remove()&#xA;When removing a resource from vmci_resource_table in&#xA;vmci_resource_remove(), the search is performed using the resource&#xA;handle by comparing context and resource fields.&#xA;It is possible though to create two resources with different types&#xA;but same handle (same context and resource fields).&#xA;When trying to remove one of the resources, vmci_resource_remove()&#xA;may not remove the intended one, but the object will still be freed&#xA;as in the case of the datagram type in vmci_datagram_destroy_handle().&#xA;vmci_resource_table will still hold a pointer to this freed resource&#xA;leading to a use-after-free vulnerability.&#xA;BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]&#xA;BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147&#xA;Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106&#xA; print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239&#xA; __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425&#xA; kasan_report+0x38/0x51 mm/kasan/report.c:442&#xA; vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]&#xA; vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147&#xA; vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182&#xA; ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444&#xA; kref_put include/linux/kref.h:65 [inline]&#xA; vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]&#xA; vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195&#xA; vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143&#xA; __fput+0x261/0xa34 fs/file_table.c:282&#xA; task_work_run+0xf0/0x194 kernel/task_work.c:164&#xA; tracehook_notify_resume include/linux/tracehook.h:189 [inline]&#xA; exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187&#xA; exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220&#xA; __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]&#xA; syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313&#xA; do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0x0&#xA;This change ensures the type is also checked when removing&#xA;the resource from vmci_resource_table in vmci_resource_remove().&#xA;CVE-2024-46740:In the Linux kernel, the following vulnerability has been resolved:&#xA;binder: fix UAF caused by offsets overwrite&#xA;Binder objects are processed and copied individually into the target&#xA;buffer during transactions. Any raw data in-between these objects is&#xA;copied as well. However, this raw data copy lacks an out-of-bounds&#xA;check. If the raw data exceeds the data section size then the copy&#xA;overwrites the offsets section. This eventually triggers an error that&#xA;attempts to unwind the processed objects. However, at this point the&#xA;offsets used to index these objects are now corrupted.&#xA;Unwinding with corrupted offsets can result in decrements of arbitrary&#xA;nodes and lead to their premature release. Other users of such nodes are&#xA;left with a dangling pointer triggering a use-after-free. This issue is&#xA;made evident by the following KASAN report (trimmed):&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c&#xA;  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743&#xA;  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1&#xA;  Hardware name: linux,dummy-virt (DT)&#xA;  Call trace:&#xA;   _raw_spin_lock+0xe4/0x19c&#xA;   binder_free_buf+0x128/0x434&#xA;   binder_thread_write+0x8a4/0x3260&#xA;   binder_ioctl+0x18f0/0x258c&#xA;  [...]&#xA;  Allocated by task 743:&#xA;   __kmalloc_cache_noprof+0x110/0x270&#xA;   binder_new_node+0x50/0x700&#xA;   binder_transaction+0x413c/0x6da8&#xA;   binder_thread_write+0x978/0x3260&#xA;   binder_ioctl+0x18f0/0x258c&#xA;  [...]&#xA;  Freed by task 745:&#xA;   kfree+0xbc/0x208&#xA;   binder_thread_read+0x1c5c/0x37d4&#xA;   binder_ioctl+0x16d8/0x258c&#xA;  [...]&#xA;  ==================================================================&#xA;To avoid this issue, let&#39;s check that the raw data copy is within the&#xA;boundaries of the data section.&#xA;CVE-2024-46798:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object&#xA;When using kernel with the following extra config,&#xA;  - CONFIG_KASAN=y&#xA;  - CONFIG_KASAN_GENERIC=y&#xA;  - CONFIG_KASAN_INLINE=y&#xA;  - CONFIG_KASAN_VMALLOC=y&#xA;  - CONFIG_FRAME_WARN=4096&#xA;kernel detects that snd_pcm_suspend_all() access a freed&#xA;&#39;snd_soc_pcm_runtime&#39; object when the system is suspended, which&#xA;leads to a use-after-free bug:&#xA;[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270&#xA;[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330&#xA;[   52.047785] Call trace:&#xA;[   52.047787]  dump_backtrace+0x0/0x3c0&#xA;[   52.047794]  show_stack+0x34/0x50&#xA;[   52.047797]  dump_stack_lvl+0x68/0x8c&#xA;[   52.047802]  print_address_description.constprop.0+0x74/0x2c0&#xA;[   52.047809]  kasan_report+0x210/0x230&#xA;[   52.047815]  __asan_report_load1_noabort+0x3c/0x50&#xA;[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270&#xA;[   52.047824]  snd_soc_suspend+0x19c/0x4e0&#xA;The snd_pcm_sync_stop() has a NULL check on &#39;substream-&gt;runtime&#39; before&#xA;making any access. So we need to always set &#39;substream-&gt;runtime&#39; to NULL&#xA;everytime we kfree() it.&#xA;CVE-2024-46781:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix missing cleanup on rollforward recovery error&#xA;In an error injection test of a routine for mount-time recovery, KASAN&#xA;found a use-after-free bug.&#xA;It turned out that if data recovery was performed using partial logs&#xA;created by dsync writes, but an error occurred before starting the log&#xA;writer to create a recovered checkpoint, the inodes whose data had been&#xA;recovered were left in the ns_dirty_files list of the nilfs object and&#xA;were not freed.&#xA;Fix this issue by cleaning up inodes that have read the recovery data if&#xA;the recovery routine fails midway before the log writer starts.&#xA;CVE-2024-46737:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvmet-tcp: fix kernel crash if commands allocation fails&#xA;If the commands allocation fails in nvmet_tcp_alloc_cmds()&#xA;the kernel crashes in nvmet_tcp_release_queue_work() because of&#xA;a NULL pointer dereference.&#xA;  nvmet: failed to install queue 0 cntlid 1 ret 6&#xA;  Unable to handle kernel NULL pointer dereference at&#xA;         virtual address 0000000000000008&#xA;Fix the bug by setting queue-&gt;nr_cmds to zero in case&#xA;nvmet_tcp_alloc_cmd() fails.&#xA;CVE-2024-46780:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: protect references to superblock parameters exposed in sysfs&#xA;The superblock buffers of nilfs2 can not only be overwritten at runtime&#xA;for modifications/repairs, but they are also regularly swapped, replaced&#xA;during resizing, and even abandoned when degrading to one side due to&#xA;backing device issues.  So, accessing them requires mutual exclusion using&#xA;the reader/writer semaphore &#34;nilfs-&gt;ns_sem&#34;.&#xA;Some sysfs attribute show methods read this superblock buffer without the&#xA;necessary mutual exclusion, which can cause problems with pointer&#xA;dereferencing and memory access, so fix it.&#xA;CVE-2024-46755:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()&#xA;mwifiex_get_priv_by_id() returns the priv pointer corresponding to&#xA;the bss_num and bss_type, but without checking if the priv is actually&#xA;currently in use.&#xA;Unused priv pointers do not have a wiphy attached to them which can&#xA;lead to NULL pointer dereferences further down the callstack.  Fix&#xA;this by returning only used priv pointers which have priv-&gt;bss_mode&#xA;set to something else than NL80211_IFTYPE_UNSPECIFIED.&#xA;Said NULL pointer dereference happened when an Accesspoint was started&#xA;with wpa_supplicant -i mlan0 with this config:&#xA;network={&#xA;        ssid=&#34;somessid&#34;&#xA;        mode=2&#xA;        frequency=2412&#xA;        key_mgmt=WPA-PSK WPA-PSK-SHA256&#xA;        proto=RSN&#xA;        group=CCMP&#xA;        pairwise=CCMP&#xA;        psk=&#34;12345678&#34;&#xA;}&#xA;When waiting for the AP to be established, interrupting wpa_supplicant&#xA;with &lt;ctrl-c&gt; and starting it again this happens:&#xA;| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140&#xA;| Mem abort info:&#xA;|   ESR = 0x0000000096000004&#xA;|   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;|   SET = 0, FnV = 0&#xA;|   EA = 0, S1PTW = 0&#xA;|   FSC = 0x04: level 0 translation fault&#xA;| Data abort info:&#xA;|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000&#xA;|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000&#xA;| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000&#xA;| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP&#xA;| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio&#xA;+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs&#xA;+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6&#xA;| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18&#xA;| Hardware name: somemachine (DT)&#xA;| Workqueue: events sdio_irq_work&#xA;| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]&#xA;| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]&#xA;| sp : ffff8000818b3a70&#xA;| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004&#xA;| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9&#xA;| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000&#xA;| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000&#xA;| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517&#xA;| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1&#xA;| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157&#xA;| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124&#xA;| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000&#xA;| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000&#xA;| Call trace:&#xA;|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]&#xA;|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]&#xA;|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]&#xA;|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]&#xA;|  mwifiex_process_event+0x110/0x238 [mwifiex]&#xA;|  mwifiex_main_process+0x428/0xa44 [mwifiex]&#xA;|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]&#xA;|  process_sdio_pending_irqs+0x64/0x1b8&#xA;|  sdio_irq_work+0x4c/0x7c&#xA;|  process_one_work+0x148/0x2a0&#xA;|  worker_thread+0x2fc/0x40c&#xA;|  kthread+0x110/0x114&#xA;|  ret_from_fork+0x10/0x20&#xA;| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)&#xA;| ---[ end trace 0000000000000000 ]---&#xA;CVE-2024-46753:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: handle errors from btrfs_dec_ref() properly&#xA;In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is&#xA;incorrect, we have proper error handling here, return the error.&#xA;CVE-2024-46758:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (lm95234) Fix underflows seen when writing limit attributes&#xA;DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large&#xA;negative number such as -9223372036854775808 is provided by the user.&#xA;Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.&#xA;CVE-2024-46816:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links&#xA;[Why]&#xA;Coverity report OVERRUN warning. There are&#xA;only max_links elements within dc-&gt;links. link&#xA;count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.&#xA;[How]&#xA;Make sure link count less than max_links.&#xA;CVE-2024-46841:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: don&#39;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()&#xA;We handle errors here properly, ENOMEM isn&#39;t fatal, return the error.&#xA;CVE-2024-46829:In the Linux kernel, the following vulnerability has been resolved:&#xA;rtmutex: Drop rt_mutex::wait_lock before scheduling&#xA;rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the&#xA;good case it returns with the lock held and in the deadlock case it emits a&#xA;warning and goes into an endless scheduling loop with the lock held, which&#xA;triggers the &#39;scheduling in atomic&#39; warning.&#xA;Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning&#xA;and dropping into the schedule for ever loop.&#xA;[ tglx: Moved unlock before the WARN(), removed the pointless comment,&#xA;  &#x9;massaged changelog, added Fixes tag ]&#xA;CVE-2024-46818:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check gpio_id before used as array index&#xA;[WHY &amp; HOW]&#xA;GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore&#xA;should be checked in advance.&#xA;This fixes 5 OVERRUN issues reported by Coverity.&#xA;CVE-2024-46821:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/pm: Fix negative array index read&#xA;Avoid using the negative values&#xA;for clk_idex as an index into an array pptable-&gt;DpmDescriptor.&#xA;V2: fix clk_index return check (Tim Huang)&#xA;CVE-2024-46844:In the Linux kernel, the following vulnerability has been resolved:&#xA;um: line: always fill *error_out in setup_one_line()&#xA;The pointer isn&#39;t initialized by callers, but I have&#xA;encountered cases where it&#39;s still printed; initialize&#xA;it in all possible cases in setup_one_line().&#xA;CVE-2024-46804:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add array index check for hdcp ddc access&#xA;[Why]&#xA;Coverity reports OVERRUN warning. Do not check if array&#xA;index valid.&#xA;[How]&#xA;Check msg_id valid and valid array index.&#xA;CVE-2024-46857:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5: Fix bridge mode operations when there are no VFs&#xA;Currently, trying to set the bridge mode attribute when numvfs=0 leads to a&#xA;crash:&#xA;bridge link set dev eth2 hwmode vepa&#xA;[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030&#xA;[...]&#xA;[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]&#xA;[...]&#xA;[  168.976037] Call Trace:&#xA;[  168.976188]  &lt;TASK&gt;&#xA;[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]&#xA;[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]&#xA;[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0&#xA;[  168.979714]  rtnetlink_rcv_msg+0x159/0x400&#xA;[  168.980451]  netlink_rcv_skb+0x54/0x100&#xA;[  168.980675]  netlink_unicast+0x241/0x360&#xA;[  168.980918]  netlink_sendmsg+0x1f6/0x430&#xA;[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0&#xA;[  168.982155]  ___sys_sendmsg+0x88/0xd0&#xA;[  168.985036]  __sys_sendmsg+0x59/0xa0&#xA;[  168.985477]  do_syscall_64+0x79/0x150&#xA;[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[  168.987773] RIP: 0033:0x7f8f7950f917&#xA;(esw-&gt;fdb_table.legacy.vepa_fdb is null)&#xA;The bridge mode is only relevant when there are multiple functions per&#xA;port. Therefore, prevent setting and getting this setting when there are no&#xA;VFs.&#xA;Note that after this change, there are no settings to change on the PF&#xA;interface using `bridge link` when there are no VFs, so the interface no&#xA;longer appears in the `bridge link` output.&#xA;CVE-2024-46848:In the Linux kernel, the following vulnerability has been resolved:&#xA;perf/x86/intel: Limit the period on Haswell&#xA;Running the ltp test cve-2015-3290 concurrently reports the following&#xA;warnings.&#xA;perfevents: irq loop stuck!&#xA;  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174&#xA;  intel_pmu_handle_irq+0x285/0x370&#xA;  Call Trace:&#xA;   &lt;NMI&gt;&#xA;   ? __warn+0xa4/0x220&#xA;   ? intel_pmu_handle_irq+0x285/0x370&#xA;   ? __report_bug+0x123/0x130&#xA;   ? intel_pmu_handle_irq+0x285/0x370&#xA;   ? __report_bug+0x123/0x130&#xA;   ? intel_pmu_handle_irq+0x285/0x370&#xA;   ? report_bug+0x3e/0xa0&#xA;   ? handle_bug+0x3c/0x70&#xA;   ? exc_invalid_op+0x18/0x50&#xA;   ? asm_exc_invalid_op+0x1a/0x20&#xA;   ? irq_work_claim+0x1e/0x40&#xA;   ? intel_pmu_handle_irq+0x285/0x370&#xA;   perf_event_nmi_handler+0x3d/0x60&#xA;   nmi_handle+0x104/0x330&#xA;Thanks to Thomas Gleixner&#39;s analysis, the issue is caused by the low&#xA;initial period (1) of the frequency estimation algorithm, which triggers&#xA;the defects of the HW, specifically erratum HSW11 and HSW143. (For the&#xA;details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)&#xA;The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL&#xA;event, but the initial period in the freq mode is 1. The erratum is the&#xA;same as the BDM11, which has been supported in the kernel. A minimum&#xA;period of 128 is enforced as well on HSW.&#xA;HSW143 is regarding that the fixed counter 1 may overcount 32 with the&#xA;Hyper-Threading is enabled. However, based on the test, the hardware&#xA;has more issues than it tells. Besides the fixed counter 1, the message&#xA;&#39;interrupt took too long&#39; can be observed on any counter which was armed&#xA;with a period &lt; 32 and two events expired in the same NMI. A minimum&#xA;period of 32 is enforced for the rest of the events.&#xA;The recommended workaround code of the HSW143 is not implemented.&#xA;Because it only addresses the issue for the fixed counter. It brings&#xA;extra overhead through extra MSR writing. No related overcounting issue&#xA;has been reported so far.&#xA;CVE-2024-46849:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: meson: axg-card: fix &#39;use-after-free&#39;&#xA;Buffer &#39;card-&gt;dai_link&#39; is reallocated in &#39;meson_card_reallocate_links()&#39;,&#xA;so move &#39;pad&#39; pointer initialization after this function when memory is&#xA;already reallocated.&#xA;Kasan bug report:&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc&#xA;Read of size 8 at addr ffff000000e8b260 by task modprobe/356&#xA;CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1&#xA;Call trace:&#xA; dump_backtrace+0x94/0xec&#xA; show_stack+0x18/0x24&#xA; dump_stack_lvl+0x78/0x90&#xA; print_report+0xfc/0x5c0&#xA; kasan_report+0xb8/0xfc&#xA; __asan_load8+0x9c/0xb8&#xA; axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]&#xA; meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]&#xA; platform_probe+0x8c/0xf4&#xA; really_probe+0x110/0x39c&#xA; __driver_probe_device+0xb8/0x18c&#xA; driver_probe_device+0x108/0x1d8&#xA; __driver_attach+0xd0/0x25c&#xA; bus_for_each_dev+0xe0/0x154&#xA; driver_attach+0x34/0x44&#xA; bus_add_driver+0x134/0x294&#xA; driver_register+0xa8/0x1e8&#xA; __platform_driver_register+0x44/0x54&#xA; axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]&#xA; do_one_initcall+0xdc/0x25c&#xA; do_init_module+0x10c/0x334&#xA; load_module+0x24c4/0x26cc&#xA; init_module_from_file+0xd4/0x128&#xA; __arm64_sys_finit_module+0x1f4/0x41c&#xA; invoke_syscall+0x60/0x188&#xA; el0_svc_common.constprop.0+0x78/0x13c&#xA; do_el0_svc+0x30/0x40&#xA; el0_svc+0x38/0x78&#xA; el0t_64_sync_handler+0x100/0x12c&#xA; el0t_64_sync+0x190/0x194&#xA;CVE-2024-46814:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check msg_id before processing transcation&#xA;[WHY &amp; HOW]&#xA;HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid&#xA;array index, and it needs checking before used.&#xA;This fixes 4 OVERRUN issues reported by Coverity.&#xA;CVE-2024-47709:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: bcm: Clear bo-&gt;bcm_proc_read after remove_proc_entry().&#xA;syzbot reported a warning in bcm_release(). [0]&#xA;The blamed change fixed another warning that is triggered when&#xA;connect() is issued again for a socket whose connect()ed device has&#xA;been unregistered.&#xA;However, if the socket is just close()d without the 2nd connect(), the&#xA;remaining bo-&gt;bcm_proc_read triggers unnecessary remove_proc_entry()&#xA;in bcm_release().&#xA;Let&#39;s clear bo-&gt;bcm_proc_read after remove_proc_entry() in bcm_notify().&#xA;[0]&#xA;name &#39;4986&#39;&#xA;WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711&#xA;Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 &lt;0f&gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07&#xA;RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246&#xA;RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a&#xA;R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640&#xA;R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000&#xA;FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; bcm_release+0x250/0x880 net/can/bcm.c:1578&#xA; __sock_release net/socket.c:659 [inline]&#xA; sock_close+0xbc/0x240 net/socket.c:1421&#xA; __fput+0x24a/0x8a0 fs/file_table.c:422&#xA; task_work_run+0x24f/0x310 kernel/task_work.c:228&#xA; exit_task_work include/linux/task_work.h:40 [inline]&#xA; do_exit+0xa2f/0x27f0 kernel/exit.c:882&#xA; do_group_exit+0x207/0x2c0 kernel/exit.c:1031&#xA; __do_sys_exit_group kernel/exit.c:1042 [inline]&#xA; __se_sys_exit_group kernel/exit.c:1040 [inline]&#xA; __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040&#xA; x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7fcfb51ee969&#xA;Code: Unable to access opcode bytes at 0x7fcfb51ee93f.&#xA;RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7&#xA;RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969&#xA;RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001&#xA;RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000&#xA;R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0&#xA;R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160&#xA; &lt;/TASK&gt;&#xA;CVE-2024-42067:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()&#xA;set_memory_rox() can fail, leaving memory unprotected.&#xA;Check return and bail out when bpf_jit_binary_lock_ro() returns&#xA;an error.&#xA;CVE-2024-43855:In the Linux kernel, the following vulnerability has been resolved:&#xA;md: fix deadlock between mddev_suspend and flush bio&#xA;Deadlock occurs when mddev is being suspended while some flush bio is in&#xA;progress. It is a complex issue.&#xA;T1. the first flush is at the ending stage, it clears &#39;mddev-&gt;flush_bio&#39;&#xA;    and tries to submit data, but is blocked because mddev is suspended&#xA;    by T4.&#xA;T2. the second flush sets &#39;mddev-&gt;flush_bio&#39;, and attempts to queue&#xA;    md_submit_flush_data(), which is already running (T1) and won&#39;t&#xA;    execute again if on the same CPU as T1.&#xA;T3. the third flush inc active_io and tries to flush, but is blocked because&#xA;    &#39;mddev-&gt;flush_bio&#39; is not NULL (set by T2).&#xA;T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc&#xA;    by T3.&#xA;  T1&#x9;&#x9;T2&#x9;&#x9;T3&#x9;&#x9;T4&#xA;  (flush 1)&#x9;(flush 2)&#x9;(third 3)&#x9;(suspend)&#xA;  md_submit_flush_data&#xA;   mddev-&gt;flush_bio = NULL;&#xA;   .&#xA;   .&#x9; &#x9;md_flush_request&#xA;   .&#x9;  &#x9; mddev-&gt;flush_bio = bio&#xA;   .&#x9;  &#x9; queue submit_flushes&#xA;   .&#x9;&#x9; .&#xA;   .&#x9;&#x9; .&#x9;&#x9;md_handle_request&#xA;   .&#x9;&#x9; .&#x9;&#x9; active_io + 1&#xA;   .&#x9;&#x9; .&#x9;&#x9; md_flush_request&#xA;   .&#x9;&#x9; .&#x9;&#x9;  wait !mddev-&gt;flush_bio&#xA;   .&#x9;&#x9; .&#xA;   .&#x9;&#x9; .&#x9;&#x9;&#x9;&#x9;mddev_suspend&#xA;   .&#x9;&#x9; .&#x9;&#x9;&#x9;&#x9; wait !active_io&#xA;   .&#x9;&#x9; .&#xA;   .&#x9;&#x9; submit_flushes&#xA;   .&#x9;&#x9; queue_work md_submit_flush_data&#xA;   .&#x9;&#x9; //md_submit_flush_data is already running (T1)&#xA;   .&#xA;   md_handle_request&#xA;    wait resume&#xA;The root issue is non-atomic inc/dec of active_io during flush process.&#xA;active_io is dec before md_submit_flush_data is queued, and inc soon&#xA;after md_submit_flush_data() run.&#xA;  md_flush_request&#xA;    active_io + 1&#xA;    submit_flushes&#xA;      active_io - 1&#xA;      md_submit_flush_data&#xA;        md_handle_request&#xA;        active_io + 1&#xA;          make_request&#xA;        active_io - 1&#xA;If active_io is dec after md_handle_request() instead of within&#xA;submit_flushes(), make_request() can be called directly intead of&#xA;md_handle_request() in md_submit_flush_data(), and active_io will&#xA;only inc and dec once in the whole flush process. Deadlock will be&#xA;fixed.&#xA;Additionally, the only difference between fixing the issue and before is&#xA;that there is no return error handling of make_request(). But after&#xA;previous patch cleaned md_write_start(), make_requst() only return error&#xA;in raid5_make_request() by dm-raid, see commit 41425f96d7aa (&#34;dm-raid456,&#xA;md/raid456: fix a deadlock for dm-raid456 while io concurrent with&#xA;reshape)&#34;. Since dm always splits data and flush operation into two&#xA;separate io, io size of flush submitted by dm always is 0, make_request()&#xA;will not be called in md_submit_flush_data(). To prevent future&#xA;modifications from introducing issues, add WARN_ON to ensure&#xA;make_request() no error is returned in this context.&#xA;CVE-2022-48893:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/i915/gt: Cleanup partial engine discovery failures&#xA;If we abort driver initialisation in the middle of gt/engine discovery,&#xA;some engines will be fully setup and some not. Those incompletely setup&#xA;engines only have &#39;engine-&gt;release == NULL&#39; and so will leak any of the&#xA;common objects allocated.&#xA;v2:&#xA; - Drop the destroy_pinned_context() helper for now.  It&#39;s not really&#xA;   worth it with just a single callsite at the moment.  (Janusz)&#xA;CVE-2024-44940:In the Linux kernel, the following vulnerability has been resolved:&#xA;fou: remove warn in gue_gro_receive on unsupported protocol&#xA;Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is&#xA;not known or does not have a GRO handler.&#xA;Such a packet is easily constructed. Syzbot generates them and sets&#xA;off this warning.&#xA;Remove the warning as it is expected and not actionable.&#xA;The warning was previously reduced from WARN_ON to WARN_ON_ONCE in&#xA;commit 270136613bf7 (&#34;fou: Do WARN_ON_ONCE in gue_gro_receive for bad&#xA;proto callbacks&#34;).&#xA;CVE-2024-44969:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/sclp: Prevent release of buffer in I/O&#xA;When a task waiting for completion of a Store Data operation is&#xA;interrupted, an attempt is made to halt this operation. If this attempt&#xA;fails due to a hardware or firmware problem, there is a chance that the&#xA;SCLP facility might store data into buffers referenced by the original&#xA;operation at a later time.&#xA;Handle this situation by not releasing the referenced data buffers if&#xA;the halt attempt fails. For current use cases, this might result in a&#xA;leak of few pages of memory in case of a rare hardware/firmware&#xA;malfunction.&#xA;CVE-2024-45006:In the Linux kernel, the following vulnerability has been resolved:&#xA;xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration&#xA;re-enumerating full-speed devices after a failed address device command&#xA;can trigger a NULL pointer dereference.&#xA;Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size&#xA;value during enumeration. Usb core calls usb_ep0_reinit() in this case,&#xA;which ends up calling xhci_configure_endpoint().&#xA;On Panther point xHC the xhci_configure_endpoint() function will&#xA;additionally check and reserve bandwidth in software. Other hosts do&#xA;this in hardware&#xA;If xHC address device command fails then a new xhci_virt_device structure&#xA;is allocated as part of re-enabling the slot, but the bandwidth table&#xA;pointers are not set up properly here.&#xA;This triggers the NULL pointer dereference the next time usb_ep0_reinit()&#xA;is called and xhci_configure_endpoint() tries to check and reserve&#xA;bandwidth&#xA;[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd&#xA;[46710.713699] usb 3-1: Device not responding to setup address.&#xA;[46710.917684] usb 3-1: Device not responding to setup address.&#xA;[46711.125536] usb 3-1: device not accepting address 5, error -71&#xA;[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008&#xA;[46711.125600] #PF: supervisor read access in kernel mode&#xA;[46711.125603] #PF: error_code(0x0000) - not-present page&#xA;[46711.125606] PGD 0 P4D 0&#xA;[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI&#xA;[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1&#xA;[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.&#xA;[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]&#xA;[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c&#xA;Fix this by making sure bandwidth table pointers are set up correctly&#xA;after a failed address device command, and additionally by avoiding&#xA;checking for bandwidth in cases like this where no actual endpoints are&#xA;added or removed, i.e. only context for default control endpoint 0 is&#xA;evaluated.&#xA;CVE-2024-44998:In the Linux kernel, the following vulnerability has been resolved:&#xA;atm: idt77252: prevent use after free in dequeue_rx()&#xA;We can&#39;t dereference &#34;skb&#34; after calling vcc-&gt;push() because the skb&#xA;is released.&#xA;CVE-2024-45026:In the Linux kernel, the following vulnerability has been resolved:&#xA;s390/dasd: fix error recovery leading to data corruption on ESE devices&#xA;Extent Space Efficient (ESE) or thin provisioned volumes need to be&#xA;formatted on demand during usual IO processing.&#xA;The dasd_ese_needs_format function checks for error codes that signal&#xA;the non existence of a proper track format.&#xA;The check for incorrect length is to imprecise since other error cases&#xA;leading to transport of insufficient data also have this flag set.&#xA;This might lead to data corruption in certain error cases for example&#xA;during a storage server warmstart.&#xA;Fix by removing the check for incorrect length and replacing by&#xA;explicitly checking for invalid track format in transport mode.&#xA;Also remove the check for file protected since this is not a valid&#xA;ESE handling case.&#xA;CVE-2024-46676:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfc: pn533: Add poll mod list filling check&#xA;In case of im_protocols value is 1 and tm_protocols value is 0 this&#xA;combination successfully passes the check&#xA;&#39;if (!im_protocols &amp;&amp; !tm_protocols)&#39; in the nfc_start_poll().&#xA;But then after pn533_poll_create_mod_list() call in pn533_start_poll()&#xA;poll mod list will remain empty and dev-&gt;poll_mod_count will remain 0&#xA;which lead to division by zero.&#xA;Normally no im protocol has value 1 in the mask, so this combination is&#xA;not expected by driver. But these protocol values actually come from&#xA;userspace via Netlink interface (NFC_CMD_START_POLL operation). So a&#xA;broken or malicious program may pass a message containing a &#34;bad&#34;&#xA;combination of protocol parameter values so that dev-&gt;poll_mod_count&#xA;is not incremented inside pn533_poll_create_mod_list(), thus leading&#xA;to division by zero.&#xA;Call trace looks like:&#xA;nfc_genl_start_poll()&#xA;  nfc_start_poll()&#xA;    -&gt;start_poll()&#xA;    pn533_start_poll()&#xA;Add poll mod list filling check.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-46754:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Remove tst_run from lwt_seg6local_prog_ops.&#xA;The syzbot reported that the lwt_seg6 related BPF ops can be invoked&#xA;via bpf_test_run() without without entering input_action_end_bpf()&#xA;first.&#xA;Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL&#xA;probably didn&#39;t work since it was introduced in commit 04d4b274e2a&#xA;(&#34;ipv6: sr: Add seg6local action End.BPF&#34;). The reason is that the&#xA;per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self&#xA;test case but each BPF function expects it.&#xA;Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.&#xA;CVE-2024-46770:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: Add netif_device_attach/detach into PF reset flow&#xA;Ethtool callbacks can be executed while reset is in progress and try to&#xA;access deleted resources, e.g. getting coalesce settings can result in a&#xA;NULL pointer dereference seen below.&#xA;Reproduction steps:&#xA;Once the driver is fully initialized, trigger reset:&#xA;&#x9;# echo 1 &gt; /sys/class/net/&lt;interface&gt;/device/reset&#xA;when reset is in progress try to get coalesce settings using ethtool:&#xA;&#x9;# ethtool -c &lt;interface&gt;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000020&#xA;PGD 0 P4D 0&#xA;Oops: Oops: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7&#xA;RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]&#xA;RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206&#xA;RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588&#xA;RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000&#xA;R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40&#xA;FS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;ice_get_coalesce+0x17/0x30 [ice]&#xA;coalesce_prepare_data+0x61/0x80&#xA;ethnl_default_doit+0xde/0x340&#xA;genl_family_rcv_msg_doit+0xf2/0x150&#xA;genl_rcv_msg+0x1b3/0x2c0&#xA;netlink_rcv_skb+0x5b/0x110&#xA;genl_rcv+0x28/0x40&#xA;netlink_unicast+0x19c/0x290&#xA;netlink_sendmsg+0x222/0x490&#xA;__sys_sendto+0x1df/0x1f0&#xA;__x64_sys_sendto+0x24/0x30&#xA;do_syscall_64+0x82/0x160&#xA;entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;RIP: 0033:0x7faee60d8e27&#xA;Calling netif_device_detach() before reset makes the net core not call&#xA;the driver when ethtool command is issued, the attempt to execute an&#xA;ethtool command during reset will result in the following message:&#xA;    netlink error: No such device&#xA;instead of NULL pointer dereference. Once reset is done and&#xA;ice_rebuild() is executing, the netif_device_attach() is called to allow&#xA;for ethtool operations to occur again in a safe manner.&#xA;CVE-2024-46858:In the Linux kernel, the following vulnerability has been resolved:&#xA;mptcp: pm: Fix uaf in __timer_delete_sync&#xA;There are two paths to access mptcp_pm_del_add_timer, result in a race&#xA;condition:&#xA;     CPU1&#x9;&#x9;&#x9;&#x9;CPU2&#xA;     ====                               ====&#xA;     net_rx_action&#xA;     napi_poll                          netlink_sendmsg&#xA;     __napi_poll                        netlink_unicast&#xA;     process_backlog                    netlink_unicast_kernel&#xA;     __netif_receive_skb                genl_rcv&#xA;     __netif_receive_skb_one_core       netlink_rcv_skb&#xA;     NF_HOOK                            genl_rcv_msg&#xA;     ip_local_deliver_finish            genl_family_rcv_msg&#xA;     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit&#xA;     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit&#xA;     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list&#xA;     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows&#xA;     tcp_data_queue                     remove_anno_list_by_saddr&#xA;     mptcp_incoming_options             mptcp_pm_del_add_timer&#xA;     mptcp_pm_del_add_timer             kfree(entry)&#xA;In remove_anno_list_by_saddr(running on CPU2), after leaving the critical&#xA;zone protected by &#34;pm.lock&#34;, the entry will be released, which leads to the&#xA;occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).&#xA;Keeping a reference to add_timer inside the lock, and calling&#xA;sk_stop_timer_sync() with this reference, instead of &#34;entry-&gt;add_timer&#34;.&#xA;Move list_del(&amp;entry-&gt;list) to mptcp_pm_del_add_timer and inside the pm lock,&#xA;do not directly access any members of the entry outside the pm lock, which&#xA;can avoid similar &#34;entry-&gt;x&#34; uaf.&#xA;CVE-2024-46855:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_socket: fix sk refcount leaks&#xA;We must put &#39;sk&#39; reference before returning.&#xA;CVE-2024-46840:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: clean up our handling of refs == 0 in snapshot delete&#xA;In reada we BUG_ON(refs == 0), which could be unkind since we aren&#39;t&#xA;holding a lock on the extent leaf and thus could get a transient&#xA;incorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which&#xA;could happen if we have extent tree corruption.  Change that to return&#xA;-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,&#xA;however we return -EIO, which -EUCLEAN is a more appropriate error code.&#xA;Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert&#xA;that to proper error handling.  Also adjust the error message so we can&#xA;actually do something with the information.&#xA;CVE-2024-46854:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: dpaa: Pad packets to ETH_ZLEN&#xA;When sending packets under 60 bytes, up to three bytes of the buffer&#xA;following the data may be leaked. Avoid this by extending all packets to&#xA;ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be&#xA;reproduced by running&#xA;&#x9;$ ping -s 11 destination&#xA;CVE-2024-46819:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: the warning dereferencing obj for nbio_v7_4&#xA;if ras_manager obj null, don&#39;t print NBIO err data&#xA;CVE-2024-46828:In the Linux kernel, the following vulnerability has been resolved:&#xA;sched: sch_cake: fix bulk flow accounting logic for host fairness&#xA;In sch_cake, we keep track of the count of active bulk flows per host,&#xA;when running in dst/src host fairness mode, which is used as the&#xA;round-robin weight when iterating through flows. The count of active&#xA;bulk flows is updated whenever a flow changes state.&#xA;This has a peculiar interaction with the hash collision handling: when a&#xA;hash collision occurs (after the set-associative hashing), the state of&#xA;the hash bucket is simply updated to match the new packet that collided,&#xA;and if host fairness is enabled, that also means assigning new per-host&#xA;state to the flow. For this reason, the bulk flow counters of the&#xA;host(s) assigned to the flow are decremented, before new state is&#xA;assigned (and the counters, which may not belong to the same host&#xA;anymore, are incremented again).&#xA;Back when this code was introduced, the host fairness mode was always&#xA;enabled, so the decrement was unconditional. When the configuration&#xA;flags were introduced the *increment* was made conditional, but&#xA;the *decrement* was not. Which of course can lead to a spurious&#xA;decrement (and associated wrap-around to U16_MAX).&#xA;AFAICT, when host fairness is disabled, the decrement and wrap-around&#xA;happens as soon as a hash collision occurs (which is not that common in&#xA;itself, due to the set-associative hashing). However, in most cases this&#xA;is harmless, as the value is only used when host fairness mode is&#xA;enabled. So in order to trigger an array overflow, sch_cake has to first&#xA;be configured with host fairness disabled, and while running in this&#xA;mode, a hash collision has to occur to cause the overflow. Then, the&#xA;qdisc has to be reconfigured to enable host fairness, which leads to the&#xA;array out-of-bounds because the wrapped-around value is retained and&#xA;used as an array index. It seems that syzbot managed to trigger this,&#xA;which is quite impressive in its own right.&#xA;This patch fixes the issue by introducing the same conditional check on&#xA;decrement as is used on increment.&#xA;The original bug predates the upstreaming of cake, but the commit listed&#xA;in the Fixes tag touched that code, meaning that this patch won&#39;t apply&#xA;before that.&#xA;CVE-2024-47658:In the Linux kernel, the following vulnerability has been resolved:&#xA;crypto: stm32/cryp - call finalize with bh disabled&#xA;The finalize operation in interrupt mode produce a produces a spinlock&#xA;recursion warning. The reason is the fact that BH must be disabled&#xA;during this process.&#xA;CVE-2024-47671:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: usbtmc: prevent kernel-usb-infoleak&#xA;The syzbot reported a kernel-usb-infoleak in usbtmc_write,&#xA;we need to clear the structure before filling fields.&#xA;CVE-2024-47664:In the Linux kernel, the following vulnerability has been resolved:&#xA;spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware&#xA;If the value of max_speed_hz is 0, it may cause a division by zero&#xA;error in hisi_calc_effective_speed().&#xA;The value of max_speed_hz is provided by firmware.&#xA;Firmware is generally considered as a trusted domain. However, as&#xA;division by zero errors can cause system failure, for defense measure,&#xA;the value of max_speed is validated here. So 0 is regarded as invalid&#xA;and an error code is returned.&#xA;CVE-2024-47672:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: don&#39;t wait for tx queues if firmware is dead&#xA;There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was&#xA;recently converted from just a message), that can be hit if we&#xA;wait for TX queues to become empty after firmware died. Clearly,&#xA;we can&#39;t expect anything from the firmware after it&#39;s declared dead.&#xA;Don&#39;t call iwl_trans_wait_tx_queues_empty() in this case. While it could&#xA;be a good idea to stop the flow earlier, the flush functions do some&#xA;maintenance work that is not related to the firmware, so keep that part&#xA;of the code running even when the firmware is not running.&#xA;[edit commit message]&#xA;CVE-2024-27403:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nft_flow_offload: reset dst in route object after setting up flow&#xA;dst is transferred to the flow object, route object does not own it&#xA;anymore.  Reset dst in route object, otherwise if flow_offload_add()&#xA;fails, error path releases dst twice, leading to a refcount underflow.&#xA;CVE-2024-35789:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes&#xA;When moving a station out of a VLAN and deleting the VLAN afterwards, the&#xA;fast_rx entry still holds a pointer to the VLAN&#39;s netdev, which can cause&#xA;use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx&#xA;after the VLAN change.&#xA;CVE-2024-35829:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/lima: fix a memleak in lima_heap_alloc&#xA;When lima_vm_map_bo fails, the resources need to be deallocated, or&#xA;there will be memleaks.&#xA;CVE-2024-35871:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: process: Fix kernel gp leakage&#xA;childregs represents the registers which are active for the new thread&#xA;in user context. For a kernel thread, childregs-&gt;gp is never used since&#xA;the kernel gp is not touched by switch_to. For a user mode helper, the&#xA;gp value can be observed in user space after execve or possibly by other&#xA;means.&#xA;[From the email thread]&#xA;The /* Kernel thread */ comment is somewhat inaccurate in that it is also used&#xA;for user_mode_helper threads, which exec a user process, e.g. /sbin/init or&#xA;when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have&#xA;PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.&#xA;childregs is the *user* context during syscall execution and it is observable&#xA;from userspace in at least five ways:&#xA;1. kernel_execve does not currently clear integer registers, so the starting&#xA;   register state for PID 1 and other user processes started by the kernel has&#xA;   sp = user stack, gp = kernel __global_pointer$, all other integer registers&#xA;   zeroed by the memset in the patch comment.&#xA;   This is a bug in its own right, but I&#39;m unwilling to bet that it is the only&#xA;   way to exploit the issue addressed by this patch.&#xA;2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread&#xA;   before it execs, but ptrace requires SIGSTOP to be delivered which can only&#xA;   happen at user/kernel boundaries.&#xA;3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for&#xA;   user_mode_helpers before the exec completes, but gp is not one of the&#xA;   registers it returns.&#xA;4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel&#xA;   addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses&#xA;   are also exposed via PERF_SAMPLE_REGS_USER which is permitted under&#xA;   LOCKDOWN_PERF. I have not attempted to write exploit code.&#xA;5. Much of the tracing infrastructure allows access to user registers. I have&#xA;   not attempted to determine which forms of tracing allow access to user&#xA;   registers without already allowing access to kernel registers.&#xA;CVE-2024-36007:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_tcam: Fix warning during rehash&#xA;As previously explained, the rehash delayed work migrates filters from&#xA;one region to another. This is done by iterating over all chunks (all&#xA;the filters with the same priority) in the region and in each chunk&#xA;iterating over all the filters.&#xA;When the work runs out of credits it stores the current chunk and entry&#xA;as markers in the per-work context so that it would know where to resume&#xA;the migration from the next time the work is scheduled.&#xA;Upon error, the chunk marker is reset to NULL, but without resetting the&#xA;entry markers despite being relative to it. This can result in migration&#xA;being resumed from an entry that does not belong to the chunk being&#xA;migrated. In turn, this will eventually lead to a chunk being iterated&#xA;over as if it is an entry. Because of how the two structures happen to&#xA;be defined, this does not lead to KASAN splats, but to warnings such as&#xA;[1].&#xA;Fix by creating a helper that resets all the markers and call it from&#xA;all the places the currently only reset the chunk marker. For good&#xA;measures also call it when starting a completely new rehash. Add a&#xA;warning to avoid future cases.&#xA;[1]&#xA;WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0&#xA;Modules linked in:&#xA;CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G        W          6.9.0-rc3-custom-00880-g29e61d91b77b #29&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work&#xA;RIP: 0010:mlxsw_afk_encode+0x242/0x2f0&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0&#xA; mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0&#xA; mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470&#xA; process_one_work+0x151/0x370&#xA; worker_thread+0x2cb/0x3e0&#xA; kthread+0xd0/0x100&#xA; ret_from_fork+0x34/0x50&#xA; &lt;/TASK&gt;&#xA;CVE-2024-36004:In the Linux kernel, the following vulnerability has been resolved:&#xA;i40e: Do not use WQ_MEM_RECLAIM flag for workqueue&#xA;Issue reported by customer during SRIOV testing, call trace:&#xA;When both i40e and the i40iw driver are loaded, a warning&#xA;in check_flush_dependency is being triggered. This seems&#xA;to be because of the i40e driver workqueue is allocated with&#xA;the WQ_MEM_RECLAIM flag, and the i40iw one is not.&#xA;Similar error was encountered on ice too and it was fixed by&#xA;removing the flag. Do the same for i40e too.&#xA;[Feb 9 09:08] ------------[ cut here ]------------&#xA;[  +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is&#xA;flushing !WQ_MEM_RECLAIM infiniband:0x0&#xA;[  +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966&#xA;check_flush_dependency+0x10b/0x120&#xA;[  +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq&#xA;snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4&#xA;nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr&#xA;rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma&#xA;intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif&#xA;isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal&#xA;intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core&#xA;iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore&#xA;ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich&#xA;intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad&#xA;xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe&#xA;drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel&#xA;libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror&#xA;dm_region_hash dm_log dm_mod fuse&#xA;[  +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not&#xA;tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1&#xA;[  +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS&#xA;SE5C620.86B.02.01.0013.121520200651 12/15/2020&#xA;[  +0.000001] Workqueue: i40e i40e_service_task [i40e]&#xA;[  +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120&#xA;[  +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48&#xA;81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd&#xA;ff &lt;0f&gt; 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90&#xA;[  +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282&#xA;[  +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:&#xA;0000000000000027&#xA;[  +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:&#xA;ffff94d47f620bc0&#xA;[  +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:&#xA;00000000ffff7fff&#xA;[  +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:&#xA;ffff94c5451ea180&#xA;[  +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:&#xA;ffff94c5f1330ab0&#xA;[  +0.000001] FS:  0000000000000000(0000) GS:ffff94d47f600000(0000)&#xA;knlGS:0000000000000000&#xA;[  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:&#xA;00000000007706f0&#xA;[  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:&#xA;0000000000000000&#xA;[  +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:&#xA;0000000000000400&#xA;[  +0.000001] PKRU: 55555554&#xA;[  +0.000001] Call Trace:&#xA;[  +0.000001]  &lt;TASK&gt;&#xA;[  +0.000002]  ? __warn+0x80/0x130&#xA;[  +0.000003]  ? check_flush_dependency+0x10b/0x120&#xA;[  +0.000002]  ? report_bug+0x195/0x1a0&#xA;[  +0.000005]  ? handle_bug+0x3c/0x70&#xA;[  +0.000003]  ? exc_invalid_op+0x14/0x70&#xA;[  +0.000002]  ? asm_exc_invalid_op+0x16/0x20&#xA;[  +0.000006]  ? check_flush_dependency+0x10b/0x120&#xA;[  +0.000002]  ? check_flush_dependency+0x10b/0x120&#xA;[  +0.000002]  __flush_workqueue+0x126/0x3f0&#xA;[  +0.000015]  ib_cache_cleanup_one+0x1c/0xe0 [ib_core]&#xA;[  +0.000056]  __ib_unregister_device+0x6a/0xb0 [ib_core]&#xA;[  +0.000023]  ib_unregister_device_and_put+0x34/0x50 [ib_core]&#xA;[  +0.000020]  i40iw_close+0x4b/0x90 [irdma]&#xA;[  +0.000022]  i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]&#xA;[  +0.000035]  i40e_service_task+0x126/0x190 [i40e]&#xA;[  +0.000024]  process_one_work+0x174/0x340&#xA;[  +0.000003]  worker_th&#xA;---truncated---&#xA;CVE-2021-47484:In the Linux kernel, the following vulnerability has been resolved:&#xA;octeontx2-af: Fix possible null pointer dereference.&#xA;This patch fixes possible null pointer dereference in files&#xA;&#34;rvu_debugfs.c&#34; and &#34;rvu_nix.c&#34;&#xA;CVE-2023-52881:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: do not accept ACK of bytes we never sent&#xA;This patch is based on a detailed report and ideas from Yepeng Pan&#xA;and Christian Rossow.&#xA;ACK seq validation is currently following RFC 5961 5.2 guidelines:&#xA;   The ACK value is considered acceptable only if&#xA;   it is in the range of ((SND.UNA - MAX.SND.WND) &lt;= SEG.ACK &lt;=&#xA;   SND.NXT).  All incoming segments whose ACK value doesn&#39;t satisfy the&#xA;   above condition MUST be discarded and an ACK sent back.  It needs to&#xA;   be noted that RFC 793 on page 72 (fifth check) says: &#34;If the ACK is a&#xA;   duplicate (SEG.ACK &lt; SND.UNA), it can be ignored.  If the ACK&#xA;   acknowledges something not yet sent (SEG.ACK &gt; SND.NXT) then send an&#xA;   ACK, drop the segment, and return&#34;.  The &#34;ignored&#34; above implies that&#xA;   the processing of the incoming data segment continues, which means&#xA;   the ACK value is treated as acceptable.  This mitigation makes the&#xA;   ACK check more stringent since any ACK &lt; SND.UNA wouldn&#39;t be&#xA;   accepted, instead only ACKs that are in the range ((SND.UNA -&#xA;   MAX.SND.WND) &lt;= SEG.ACK &lt;= SND.NXT) get through.&#xA;This can be refined for new (and possibly spoofed) flows,&#xA;by not accepting ACK for bytes that were never sent.&#xA;This greatly improves TCP security at a little cost.&#xA;I added a Fixes: tag to make sure this patch will reach stable trees,&#xA;even if the &#39;blamed&#39; patch was adhering to the RFC.&#xA;tp-&gt;bytes_acked was added in linux-4.2&#xA;Following packetdrill test (courtesy of Yepeng Pan) shows&#xA;the issue at hand:&#xA;0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3&#xA;+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0&#xA;+0 bind(3, ..., ...) = 0&#xA;+0 listen(3, 1024) = 0&#xA;// ---------------- Handshake ------------------- //&#xA;// when window scale is set to 14 the window size can be extended to&#xA;// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet&#xA;// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)&#xA;// ,though this ack number acknowledges some data never&#xA;// sent by the server.&#xA;+0 &lt; S 0:0(0) win 65535 &lt;mss 1400,nop,wscale 14&gt;&#xA;+0 &gt; S. 0:0(0) ack 1 &lt;...&gt;&#xA;+0 &lt; . 1:1(0) ack 1 win 65535&#xA;+0 accept(3, ..., ...) = 4&#xA;// For the established connection, we send an ACK packet,&#xA;// the ack packet uses ack number 1 - 1073725300 + 2^32,&#xA;// where 2^32 is used to wrap around.&#xA;// Note: we used 1073725300 instead of 1073725440 to avoid possible&#xA;// edge cases.&#xA;// 1 - 1073725300 + 2^32 = 3221241997&#xA;// Oops, old kernels happily accept this packet.&#xA;+0 &lt; . 1:1001(1000) ack 3221241997 win 65535&#xA;// After the kernel fix the following will be replaced by a challenge ACK,&#xA;// and prior malicious frame would be dropped.&#xA;+0 &gt; . 1:1(0) ack 1001&#xA;CVE-2024-38608:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/mlx5e: Fix netif state handling&#xA;mlx5e_suspend cleans resources only if netif_device_present() returns&#xA;true. However, mlx5e_resume changes the state of netif, via&#xA;mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.&#xA;In the below case, the above leads to NULL-ptr Oops[1] and memory&#xA;leaks:&#xA;mlx5e_probe&#xA; _mlx5e_resume&#xA;  mlx5e_attach_netdev&#xA;   mlx5e_nic_enable  &lt;-- netdev not reg, not calling netif_device_attach()&#xA;  register_netdev &lt;-- failed for some reason.&#xA;ERROR_FLOW:&#xA; _mlx5e_suspend &lt;-- netif_device_present return false, resources aren&#39;t freed :(&#xA;Hence, clean resources in this case as well.&#xA;[1]&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;PGD 0 P4D 0&#xA;Oops: 0010 [#1] SMP&#xA;CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:0x0&#xA;Code: Unable to access opcode bytes at0xffffffffffffffd6.&#xA;RSP: 0018:ffff888178aaf758 EFLAGS: 00010246&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die+0x20/0x60&#xA; ? page_fault_oops+0x14c/0x3c0&#xA; ? exc_page_fault+0x75/0x140&#xA; ? asm_exc_page_fault+0x22/0x30&#xA; notifier_call_chain+0x35/0xb0&#xA; blocking_notifier_call_chain+0x3d/0x60&#xA; mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]&#xA; mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core]&#xA; mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib]&#xA; mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib]&#xA; __mlx5_ib_add+0x34/0xd0 [mlx5_ib]&#xA; mlx5r_probe+0xe1/0x210 [mlx5_ib]&#xA; ? auxiliary_match_id+0x6a/0x90&#xA; auxiliary_bus_probe+0x38/0x80&#xA; ? driver_sysfs_add+0x51/0x80&#xA; really_probe+0xc9/0x3e0&#xA; ? driver_probe_device+0x90/0x90&#xA; __driver_probe_device+0x80/0x160&#xA; driver_probe_device+0x1e/0x90&#xA; __device_attach_driver+0x7d/0x100&#xA; bus_for_each_drv+0x80/0xd0&#xA; __device_attach+0xbc/0x1f0&#xA; bus_probe_device+0x86/0xa0&#xA; device_add+0x637/0x840&#xA; __auxiliary_device_add+0x3b/0xa0&#xA; add_adev+0xc9/0x140 [mlx5_core]&#xA; mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core]&#xA; mlx5_register_device+0x53/0xa0 [mlx5_core]&#xA; mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core]&#xA; mlx5_init_one+0x3b/0x60 [mlx5_core]&#xA; probe_one+0x44c/0x730 [mlx5_core]&#xA; local_pci_probe+0x3e/0x90&#xA; pci_device_probe+0xbf/0x210&#xA; ? kernfs_create_link+0x5d/0xa0&#xA; ? sysfs_do_create_link_sd+0x60/0xc0&#xA; really_probe+0xc9/0x3e0&#xA; ? driver_probe_device+0x90/0x90&#xA; __driver_probe_device+0x80/0x160&#xA; driver_probe_device+0x1e/0x90&#xA; __device_attach_driver+0x7d/0x100&#xA; bus_for_each_drv+0x80/0xd0&#xA; __device_attach+0xbc/0x1f0&#xA; pci_bus_add_device+0x54/0x80&#xA; pci_iov_add_virtfn+0x2e6/0x320&#xA; sriov_enable+0x208/0x420&#xA; mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core]&#xA; sriov_numvfs_store+0xae/0x1a0&#xA; kernfs_fop_write_iter+0x10c/0x1a0&#xA; vfs_write+0x291/0x3c0&#xA; ksys_write+0x5f/0xe0&#xA; do_syscall_64+0x3d/0x90&#xA; entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA; CR2: 0000000000000000&#xA; ---[ end trace 0000000000000000  ]---&#xA;CVE-2024-38612:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: sr: fix invalid unregister error path&#xA;The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL&#xA;is not defined. In that case if seg6_hmac_init() fails, the&#xA;genl_unregister_family() isn&#39;t called.&#xA;This issue exist since commit 46738b1317e1 (&#34;ipv6: sr: add option to control&#xA;lwtunnel support&#34;), and commit 5559cea2d5aa (&#34;ipv6: sr: fix possible&#xA;use-after-free and null-ptr-deref&#34;) replaced unregister_pernet_subsys()&#xA;with genl_unregister_family() in this error path.&#xA;CVE-2024-36244:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: taprio: extend minimum interval restriction to entire cycle too&#xA;It is possible for syzbot to side-step the restriction imposed by the&#xA;blamed commit in the Fixes: tag, because the taprio UAPI permits a&#xA;cycle-time different from (and potentially shorter than) the sum of&#xA;entry intervals.&#xA;We need one more restriction, which is that the cycle time itself must&#xA;be larger than N * ETH_ZLEN bit times, where N is the number of schedule&#xA;entries. This restriction needs to apply regardless of whether the cycle&#xA;time came from the user or was the implicit, auto-calculated value, so&#xA;we move the existing &#34;cycle == 0&#34; check outside the &#34;if &#34;(!new-&gt;cycle_time)&#34;&#xA;branch. This way covers both conditions and scenarios.&#xA;Add a selftest which illustrates the issue triggered by syzbot.&#xA;CVE-2024-39495:In the Linux kernel, the following vulnerability has been resolved:&#xA;greybus: Fix use-after-free bug in gb_interface_release due to race condition.&#xA;In gb_interface_create, &amp;intf-&gt;mode_switch_completion is bound with&#xA;gb_interface_mode_switch_work. Then it will be started by&#xA;gb_interface_request_mode_switch. Here is the relevant code.&#xA;if (!queue_work(system_long_wq, &amp;intf-&gt;mode_switch_work)) {&#xA;&#x9;...&#xA;}&#xA;If we call gb_interface_release to make cleanup, there may be an&#xA;unfinished work. This function will call kfree to free the object&#xA;&#34;intf&#34;. However, if gb_interface_mode_switch_work is scheduled to&#xA;run after kfree, it may cause use-after-free error as&#xA;gb_interface_mode_switch_work will use the object &#34;intf&#34;.&#xA;The possible execution flow that may lead to the issue is as follows:&#xA;CPU0                            CPU1&#xA;                            |   gb_interface_create&#xA;                            |   gb_interface_request_mode_switch&#xA;gb_interface_release        |&#xA;kfree(intf) (free)          |&#xA;                            |   gb_interface_mode_switch_work&#xA;                            |   mutex_lock(&amp;intf-&gt;mutex) (use)&#xA;Fix it by canceling the work before kfree.&#xA;CVE-2024-40958:In the Linux kernel, the following vulnerability has been resolved:&#xA;netns: Make get_net_ns() handle zero refcount net&#xA;Syzkaller hit a warning:&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0&#xA;Modules linked in:&#xA;CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;RIP: 0010:refcount_warn_saturate+0xdf/0x1d0&#xA;Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 &lt;0f&gt; 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1&#xA;RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac&#xA;RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001&#xA;RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139&#xA;R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4&#xA;R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040&#xA;FS:  00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_regs+0xa3/0xc0&#xA; ? __warn+0xa5/0x1c0&#xA; ? refcount_warn_saturate+0xdf/0x1d0&#xA; ? report_bug+0x1fc/0x2d0&#xA; ? refcount_warn_saturate+0xdf/0x1d0&#xA; ? handle_bug+0xa1/0x110&#xA; ? exc_invalid_op+0x3c/0xb0&#xA; ? asm_exc_invalid_op+0x1f/0x30&#xA; ? __warn_printk+0xcc/0x140&#xA; ? __warn_printk+0xd5/0x140&#xA; ? refcount_warn_saturate+0xdf/0x1d0&#xA; get_net_ns+0xa4/0xc0&#xA; ? __pfx_get_net_ns+0x10/0x10&#xA; open_related_ns+0x5a/0x130&#xA; __tun_chr_ioctl+0x1616/0x2370&#xA; ? __sanitizer_cov_trace_switch+0x58/0xa0&#xA; ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30&#xA; ? __pfx_tun_chr_ioctl+0x10/0x10&#xA; tun_chr_ioctl+0x2f/0x40&#xA; __x64_sys_ioctl+0x11b/0x160&#xA; x64_sys_call+0x1211/0x20d0&#xA; do_syscall_64+0x9e/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f5b28f165d7&#xA;Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8&#xA;RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7&#xA;RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003&#xA;RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0&#xA;R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730&#xA;R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000&#xA; &lt;/TASK&gt;&#xA;Kernel panic - not syncing: kernel: panic_on_warn set ...&#xA;This is trigger as below:&#xA;          ns0                                    ns1&#xA;tun_set_iff() //dev is tun0&#xA;   tun-&gt;dev = dev&#xA;//ip link set tun0 netns ns1&#xA;                                       put_net() //ref is 0&#xA;__tun_chr_ioctl() //TUNGETDEVNETNS&#xA;   net = dev_net(tun-&gt;dev);&#xA;   open_related_ns(&amp;net-&gt;ns, get_net_ns); //ns1&#xA;     get_net_ns()&#xA;        get_net() //addition on 0&#xA;Use maybe_get_net() in get_net_ns in case net&#39;s ref is zero to fix this&#xA;CVE-2024-42321:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE&#xA;The following splat is easy to reproduce upstream as well as in -stable&#xA;kernels. Florian Westphal provided the following commit:&#xA;  d1dab4f71d37 (&#34;net: add and use __skb_get_hash_symmetric_net&#34;)&#xA;but this complementary fix has been also suggested by Willem de Bruijn&#xA;and it can be easily backported to -stable kernel which consists in&#xA;using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat&#xA;given __skb_get_hash() is used by the nftables tracing infrastructure to&#xA;to identify packets in traces.&#xA;[69133.561393] ------------[ cut here ]------------&#xA;[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/&#xA;[...]&#xA;[69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379&#xA;[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0&#xA;[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff&#xA;ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff &lt;0f&gt; 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8&#xA;[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246&#xA;[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19&#xA;[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418&#xA;[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000&#xA;[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400&#xA;[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28&#xA;[69133.562020] FS:  00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000&#xA;[69133.562027] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0&#xA;[69133.562040] Call Trace:&#xA;[69133.562044]  &lt;IRQ&gt;&#xA;[69133.562049]  ? __warn+0x9f/0x1a0&#xA;[ 1211.841384]  ? __skb_flow_dissect+0x107e/0x2860&#xA;[...]&#xA;[ 1211.841496]  ? bpf_flow_dissect+0x160/0x160&#xA;[ 1211.841753]  __skb_get_hash+0x97/0x280&#xA;[ 1211.841765]  ? __skb_get_hash_symmetric+0x230/0x230&#xA;[ 1211.841776]  ? mod_find+0xbf/0xe0&#xA;[ 1211.841786]  ? get_stack_info_noinstr+0x12/0xe0&#xA;[ 1211.841798]  ? bpf_ksym_find+0x56/0xe0&#xA;[ 1211.841807]  ? __rcu_read_unlock+0x2a/0x70&#xA;[ 1211.841819]  nft_trace_init+0x1b9/0x1c0 [nf_tables]&#xA;[ 1211.841895]  ? nft_trace_notify+0x830/0x830 [nf_tables]&#xA;[ 1211.841964]  ? get_stack_info+0x2b/0x80&#xA;[ 1211.841975]  ? nft_do_chain_arp+0x80/0x80 [nf_tables]&#xA;[ 1211.842044]  nft_do_chain+0x79c/0x850 [nf_tables]&#xA;CVE-2024-42289:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: qla2xxx: During vport delete send async logout explicitly&#xA;During vport delete, it is observed that during unload we hit a crash&#xA;because of stale entries in outstanding command array.  For all these stale&#xA;I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but&#xA;I/Os could not complete while vport delete is in process of deleting.&#xA;  BUG: kernel NULL pointer dereference, address: 000000000000001c&#xA;  #PF: supervisor read access in kernel mode&#xA;  #PF: error_code(0x0000) - not-present page&#xA;  PGD 0 P4D 0&#xA;  Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]&#xA;  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0&#xA;  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046&#xA;  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001&#xA;  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0&#xA;  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8&#xA;  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000&#xA;  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000&#xA;  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0&#xA;  Call Trace:&#xA;  &lt;TASK&gt;&#xA;  qla2xxx_qpair_sp_free_dma+0x417/0x4e0&#xA;  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0&#xA;  ? qla2x00_status_entry+0x768/0x2830&#xA;  ? newidle_balance+0x2f0/0x430&#xA;  ? dequeue_entity+0x100/0x3c0&#xA;  ? qla24xx_process_response_queue+0x6a1/0x19e0&#xA;  ? __schedule+0x2d5/0x1140&#xA;  ? qla_do_work+0x47/0x60&#xA;  ? process_one_work+0x267/0x440&#xA;  ? process_one_work+0x440/0x440&#xA;  ? worker_thread+0x2d/0x3d0&#xA;  ? process_one_work+0x440/0x440&#xA;  ? kthread+0x156/0x180&#xA;  ? set_kthread_struct+0x50/0x50&#xA;  ? ret_from_fork+0x22/0x30&#xA;  &lt;/TASK&gt;&#xA;Send out async logout explicitly for all the ports during vport delete.&#xA;CVE-2024-43880:In the Linux kernel, the following vulnerability has been resolved:&#xA;mlxsw: spectrum_acl_erp: Fix object nesting warning&#xA;ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM&#xA;(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can&#xA;contain more ACLs (i.e., tc filters), but the number of masks in each&#xA;region (i.e., tc chain) is limited.&#xA;In order to mitigate the effects of the above limitation, the device&#xA;allows filters to share a single mask if their masks only differ in up&#xA;to 8 consecutive bits. For example, dst_ip/25 can be represented using&#xA;dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the&#xA;number of masks being used (and therefore does not support mask&#xA;aggregation), but can contain a limited number of filters.&#xA;The driver uses the &#34;objagg&#34; library to perform the mask aggregation by&#xA;passing it objects that consist of the filter&#39;s mask and whether the&#xA;filter is to be inserted into the A-TCAM or the C-TCAM since filters in&#xA;different TCAMs cannot share a mask.&#xA;The set of created objects is dependent on the insertion order of the&#xA;filters and is not necessarily optimal. Therefore, the driver will&#xA;periodically ask the library to compute a more optimal set (&#34;hints&#34;) by&#xA;looking at all the existing objects.&#xA;When the library asks the driver whether two objects can be aggregated&#xA;the driver only compares the provided masks and ignores the A-TCAM /&#xA;C-TCAM indication. This is the right thing to do since the goal is to&#xA;move as many filters as possible to the A-TCAM. The driver also forbids&#xA;two identical masks from being aggregated since this can only happen if&#xA;one was intentionally put in the C-TCAM to avoid a conflict in the&#xA;A-TCAM.&#xA;The above can result in the following set of hints:&#xA;H1: {mask X, A-TCAM} -&gt; H2: {mask Y, A-TCAM} // X is Y + delta&#xA;H3: {mask Y, C-TCAM} -&gt; H4: {mask Z, A-TCAM} // Y is Z + delta&#xA;After getting the hints from the library the driver will start migrating&#xA;filters from one region to another while consulting the computed hints&#xA;and instructing the device to perform a lookup in both regions during&#xA;the transition.&#xA;Assuming a filter with mask X is being migrated into the A-TCAM in the&#xA;new region, the hints lookup will return H1. Since H2 is the parent of&#xA;H1, the library will try to find the object associated with it and&#xA;create it if necessary in which case another hints lookup (recursive)&#xA;will be performed. This hints lookup for {mask Y, A-TCAM} will either&#xA;return H2 or H3 since the driver passes the library an object comparison&#xA;function that ignores the A-TCAM / C-TCAM indication.&#xA;This can eventually lead to nested objects which are not supported by&#xA;the library [1].&#xA;Fix by removing the object comparison function from both the driver and&#xA;the library as the driver was the only user. That way the lookup will&#xA;only return exact matches.&#xA;I do not have a reliable reproducer that can reproduce the issue in a&#xA;timely manner, but before the fix the issue would reproduce in several&#xA;minutes and with the fix it does not reproduce in over an hour.&#xA;Note that the current usefulness of the hints is limited because they&#xA;include the C-TCAM indication and represent aggregation that cannot&#xA;actually happen. This will be addressed in net-next.&#xA;[1]&#xA;WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0&#xA;Modules linked in:&#xA;CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42&#xA;Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018&#xA;Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work&#xA;RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __objagg_obj_get+0x2bb/0x580&#xA; objagg_obj_get+0xe/0x80&#xA; mlxsw_sp_acl_erp_mask_get+0xb5/0xf0&#xA; mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0&#xA; mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0&#xA; mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270&#xA; mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510&#xA; process_one_work+0x151/0x370&#xA;CVE-2024-44931:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpio: prevent potential speculation leaks in gpio_device_get_desc()&#xA;Userspace may trigger a speculative read of an address outside the gpio&#xA;descriptor array.&#xA;Users can do that by calling gpio_ioctl() with an offset out of range.&#xA;Offset is copied from user and then used as an array index to get&#xA;the gpio descriptor without sanitization in gpio_device_get_desc().&#xA;This change ensures that the offset is sanitized by using&#xA;array_index_nospec() to mitigate any possibility of speculative&#xA;information leaks.&#xA;This bug was discovered and resolved using Coverity Static Analysis&#xA;Security Testing (SAST) by Synopsys, Inc.&#xA;CVE-2024-44990:In the Linux kernel, the following vulnerability has been resolved:&#xA;bonding: fix null pointer deref in bond_ipsec_offload_ok&#xA;We must check if there is an active slave before dereferencing the pointer.&#xA;CVE-2024-44989:In the Linux kernel, the following vulnerability has been resolved:&#xA;bonding: fix xfrm real_dev null pointer dereference&#xA;We shouldn&#39;t set real_dev to NULL because packets can be in transit and&#xA;xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume&#xA;real_dev is set.&#xA; Example trace:&#xA; kernel: BUG: unable to handle page fault for address: 0000000000001030&#xA; kernel: bond0: (slave eni0np1): making interface the new active one&#xA; kernel: #PF: supervisor write access in kernel mode&#xA; kernel: #PF: error_code(0x0002) - not-present page&#xA; kernel: PGD 0 P4D 0&#xA; kernel: Oops: 0002 [#1] PREEMPT SMP&#xA; kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12&#xA; kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014&#xA; kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]&#xA; kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA&#xA; kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 &lt;83&gt; 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f&#xA; kernel: bond0: (slave eni0np1): making interface the new active one&#xA; kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246&#xA; kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA&#xA; kernel:&#xA; kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60&#xA; kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00&#xA; kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014&#xA; kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000&#xA; kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000&#xA; kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000&#xA; kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0&#xA; kernel: bond0: (slave eni0np1): making interface the new active one&#xA; kernel: Call Trace:&#xA; kernel:  &lt;TASK&gt;&#xA; kernel:  ? __die+0x1f/0x60&#xA; kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA&#xA; kernel:  ? page_fault_oops+0x142/0x4c0&#xA; kernel:  ? do_user_addr_fault+0x65/0x670&#xA; kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50&#xA; kernel: bond0: (slave eni0np1): making interface the new active one&#xA; kernel:  ? exc_page_fault+0x7b/0x180&#xA; kernel:  ? asm_exc_page_fault+0x22/0x30&#xA; kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim]&#xA; kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA&#xA; kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]&#xA; kernel: bond0: (slave eni0np1): making interface the new active one&#xA; kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding]&#xA; kernel:  xfrm_output+0x61/0x3b0&#xA; kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA&#xA; kernel:  ip_push_pending_frames+0x56/0x80&#xA;CVE-2024-45018:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: flowtable: initialise extack before use&#xA;Fix missing initialisation of extack in flow offload.&#xA;CVE-2024-46716:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor&#xA;Remove list_del call in msgdma_chan_desc_cleanup, this should be the role&#xA;of msgdma_free_descriptor. In consequence replace list_add_tail with&#xA;list_move_tail in msgdma_free_descriptor.&#xA;This fixes the path:&#xA;   msgdma_free_chan_resources -&gt; msgdma_free_descriptors -&gt;&#xA;   msgdma_free_desc_list -&gt; msgdma_free_descriptor&#xA;which does not correctly free the descriptors as first nodes were not&#xA;removed from the list.&#xA;CVE-2024-46826:In the Linux kernel, the following vulnerability has been resolved:&#xA;ELF: fix kernel.randomize_va_space double read&#xA;ELF loader uses &#34;randomize_va_space&#34; twice. It is sysctl and can change&#xA;at any moment, so 2 loads could see 2 different values in theory with&#xA;unpredictable consequences.&#xA;Issue exactly one load for consistent value across one exec.&#xA;CVE-2024-46822:In the Linux kernel, the following vulnerability has been resolved:&#xA;arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry&#xA;In a review discussion of the changes to support vCPU hotplug where&#xA;a check was added on the GICC being enabled if was online, it was&#xA;noted that there is need to map back to the cpu and use that to index&#xA;into a cpumask. As such, a valid ID is needed.&#xA;If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible&#xA;for the entry in cpu_madt_gicc[cpu] == NULL.  This function would&#xA;then cause a NULL pointer dereference.   Whilst a path to trigger&#xA;this has not been established, harden this caller against the&#xA;possibility.&#xA;CVE-2024-46859:In the Linux kernel, the following vulnerability has been resolved:&#xA;platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses&#xA;The panasonic laptop code in various places uses the SINF array with index&#xA;values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array&#xA;is big enough.&#xA;Not all panasonic laptops have this many SINF array entries, for example&#xA;the Toughbook CF-18 model only has 10 SINF array entries. So it only&#xA;supports the AC+DC brightness entries and mute.&#xA;Check that the SINF array has a minimum size which covers all AC+DC&#xA;brightness entries and refuse to load if the SINF array is smaller.&#xA;For higher SINF indexes hide the sysfs attributes when the SINF array&#xA;does not contain an entry for that attribute, avoiding show()/store()&#xA;accessing the array out of bounds and add bounds checking to the probe()&#xA;and resume() code accessing these.&#xA;CVE-2024-46817:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6&#xA;[Why]&#xA;Coverity reports OVERRUN warning. Should abort amdgpu_dm&#xA;initialize.&#xA;[How]&#xA;Return failure to amdgpu_dm_init.&#xA;CVE-2024-47661:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Avoid overflow from uint32_t to uint8_t&#xA;[WHAT &amp; HOW]&#xA;dmub_rb_cmd&#39;s ramping_boundary has size of uint8_t and it is assigned&#xA;0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.&#xA;This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.&#xA;CVE-2024-50015:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: dax: fix overflowing extents beyond inode size when partially writing&#xA;The dax_iomap_rw() does two things in each iteration: map written blocks&#xA;and copy user data to blocks. If the process is killed by user(See signal&#xA;handling in dax_iomap_iter()), the copied data will be returned and added&#xA;on inode size, which means that the length of written extents may exceed&#xA;the inode size, then fsck will fail. An example is given as:&#xA;dd if=/dev/urandom of=file bs=4M count=1&#xA; dax_iomap_rw&#xA;  iomap_iter // round 1&#xA;   ext4_iomap_begin&#xA;    ext4_iomap_alloc // allocate 0~2M extents(written flag)&#xA;  dax_iomap_iter // copy 2M data&#xA;  iomap_iter // round 2&#xA;   iomap_iter_advance&#xA;    iter-&gt;pos += iter-&gt;processed // iter-&gt;pos = 2M&#xA;   ext4_iomap_begin&#xA;    ext4_iomap_alloc // allocate 2~4M extents(written flag)&#xA;  dax_iomap_iter&#xA;   fatal_signal_pending&#xA;  done = iter-&gt;pos - iocb-&gt;ki_pos // done = 2M&#xA; ext4_handle_inode_extension&#xA;  ext4_update_inode_size // inode size = 2M&#xA;fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?&#xA;Fix the problem by truncating extents if the written length is smaller&#xA;than expected.&#xA;CVE-2024-26917:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: Revert &#34;scsi: fcoe: Fix potential deadlock on &amp;fip-&gt;ctlr_lock&#34;&#xA;This reverts commit 1a1975551943f681772720f639ff42fbaa746212.&#xA;This commit causes interrupts to be lost for FCoE devices, since it changed&#xA;sping locks from &#34;bh&#34; to &#34;irqsave&#34;.&#xA;Instead, a work queue should be used, and will be addressed in a separate&#xA;commit.&#xA;CVE-2024-35878:In the Linux kernel, the following vulnerability has been resolved:&#xA;of: module: prevent NULL pointer dereference in vsnprintf()&#xA;In of_modalias(), we can get passed the str and len parameters which would&#xA;cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr&#xA;when the length is also 0. Also, we need to filter out the negative values&#xA;of the len parameter as these will result in a really huge buffer since&#xA;snprintf() takes size_t parameter while ours is ssize_t...&#xA;Found by Linux Verification Center (linuxtesting.org) with the Svace static&#xA;analysis tool.&#xA;CVE-2023-52754:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: imon: fix access to invalid resource for the second interface&#xA;imon driver probes two USB interfaces, and at the probe of the second&#xA;interface, the driver assumes blindly that the first interface got&#xA;bound with the same imon driver.  It&#39;s usually true, but it&#39;s still&#xA;possible that the first interface is bound with another driver via a&#xA;malformed descriptor.  Then it may lead to a memory corruption, as&#xA;spotted by syzkaller; imon driver accesses the data from drvdata as&#xA;struct imon_context object although it&#39;s a completely different one&#xA;that was assigned by another driver.&#xA;This patch adds a sanity check -- whether the first interface is&#xA;really bound with the imon driver or not -- for avoiding the problem&#xA;above at the probe time.&#xA;CVE-2024-38635:In the Linux kernel, the following vulnerability has been resolved:&#xA;soundwire: cadence: fix invalid PDI offset&#xA;For some reason, we add an offset to the PDI, presumably to skip the&#xA;PDI0 and PDI1 which are reserved for BPT.&#xA;This code is however completely wrong and leads to an out-of-bounds&#xA;access. We were just lucky so far since we used only a couple of PDIs&#xA;and remained within the PDI array bounds.&#xA;A Fixes: tag is not provided since there are no known platforms where&#xA;the out-of-bounds would be accessed, and the initial code had problems&#xA;as well.&#xA;A follow-up patch completely removes this useless offset.&#xA;CVE-2024-36286:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()&#xA;syzbot reported that nf_reinject() could be called without rcu_read_lock() :&#xA;WARNING: suspicious RCU usage&#xA;6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted&#xA;net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!&#xA;other info that might help us debug this:&#xA;rcu_scheduler_active = 2, debug_locks = 1&#xA;2 locks held by syz-executor.4/13427:&#xA;  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]&#xA;  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]&#xA;  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471&#xA;  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA;  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]&#xA;  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172&#xA;stack backtrace:&#xA;CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA;  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712&#xA;  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]&#xA;  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397&#xA;  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]&#xA;  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172&#xA;  rcu_do_batch kernel/rcu/tree.c:2196 [inline]&#xA;  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471&#xA;  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554&#xA;  __do_softirq kernel/softirq.c:588 [inline]&#xA;  invoke_softirq kernel/softirq.c:428 [inline]&#xA;  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637&#xA;  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649&#xA;  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]&#xA;  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA;CVE-2024-38667:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: prevent pt_regs corruption for secondary idle threads&#xA;Top of the kernel thread stack should be reserved for pt_regs. However&#xA;this is not the case for the idle threads of the secondary boot harts.&#xA;Their stacks overlap with their pt_regs, so both may get corrupted.&#xA;Similar issue has been fixed for the primary hart, see c7cdd96eca28&#xA;(&#34;riscv: prevent stack corruption by reserving task_pt_regs(p) early&#34;).&#xA;However that fix was not propagated to the secondary harts. The problem&#xA;has been noticed in some CPU hotplug tests with V enabled. The function&#xA;smp_callin stored several registers on stack, corrupting top of pt_regs&#xA;structure including status field. As a result, kernel attempted to save&#xA;or restore inexistent V context.&#xA;CVE-2024-40965:In the Linux kernel, the following vulnerability has been resolved:&#xA;i2c: lpi2c: Avoid calling clk_get_rate during transfer&#xA;Instead of repeatedly calling clk_get_rate for each transfer, lock&#xA;the clock rate and cache the value.&#xA;A deadlock has been observed while adding tlv320aic32x4 audio codec to&#xA;the system. When this clock provider adds its clock, the clk mutex is&#xA;locked already, it needs to access i2c, which in return needs the mutex&#xA;for clk_get_rate as well.&#xA;CVE-2024-41015:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: add bounds checking to ocfs2_check_dir_entry()&#xA;This adds sanity checks for ocfs2_dir_entry to make sure all members of&#xA;ocfs2_dir_entry don&#39;t stray beyond valid memory region.&#xA;CVE-2024-42152:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvmet: fix a possible leak when destroy a ctrl during qp establishment&#xA;In nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL we&#xA;know that a ctrl was allocated (in the admin connect request handler)&#xA;and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl&#xA;(for nvme-loop primarily), and drop the final reference on the ctrl.&#xA;However, a small window is possible where nvmet_sq_destroy starts (as&#xA;a result of the client giving up and disconnecting) concurrently with&#xA;the nvme admin connect cmd (which may be in an early stage). But *before*&#xA;kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sq&#xA;live reference). In this case, sq-&gt;ctrl was allocated however after it was&#xA;captured in a local variable in nvmet_sq_destroy.&#xA;This prevented the final reference drop on the ctrl.&#xA;Solve this by re-capturing the sq-&gt;ctrl after all inflight request has&#xA;completed, where for sure sq-&gt;ctrl reference is final, and move forward&#xA;based on that.&#xA;This issue was observed in an environment with many hosts connecting&#xA;multiple ctrls simoutanuosly, creating a delay in allocating a ctrl&#xA;leading up to this race window.&#xA;CVE-2024-43841:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: virt_wifi: avoid reporting connection success with wrong SSID&#xA;When user issues a connection with a different SSID than the one&#xA;virt_wifi has advertised, the __cfg80211_connect_result() will&#xA;trigger the warning: WARN_ON(bss_not_found).&#xA;The issue is because the connection code in virt_wifi does not&#xA;check the SSID from user space (it only checks the BSSID), and&#xA;virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS&#xA;even if the SSID is different from the one virt_wifi has advertised.&#xA;Eventually cfg80211 won&#39;t be able to find the cfg80211_bss and generate&#xA;the warning.&#xA;Fixed it by checking the SSID (from user space) in the connection code.&#xA;CVE-2024-43858:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: Fix array-index-out-of-bounds in diFree&#xA;CVE-2024-42301:In the Linux kernel, the following vulnerability has been resolved:&#xA;dev/parport: fix the array out-of-bounds risk&#xA;Fixed array out-of-bounds issues caused by sprintf&#xA;by replacing it with snprintf for safer data copying,&#xA;ensuring the destination buffer is not overflowed.&#xA;Below is the stack trace I encountered during the actual issue:&#xA;[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:&#xA;Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]&#xA;[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:&#xA;QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2&#xA;[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp&#xA;[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun&#xA;PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024&#xA;[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:&#xA;[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0&#xA;[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20&#xA;[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c&#xA;[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc&#xA;[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38&#xA;[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]&#xA;CVE-2024-43867:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/nouveau: prime: fix refcount underflow&#xA;Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and&#xA;hence the backing ttm_bo) leads to a refcount underflow.&#xA;Instead of calling nouveau_bo_ref() in the unwind path of&#xA;drm_gem_object_init(), clean things up manually.&#xA;(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)&#xA;CVE-2024-43871:In the Linux kernel, the following vulnerability has been resolved:&#xA;devres: Fix memory leakage caused by driver API devm_free_percpu()&#xA;It will cause memory leakage when use driver API devm_free_percpu()&#xA;to free memory allocated by devm_alloc_percpu(), fixed by using&#xA;devres_release() instead of devres_destroy() within devm_free_percpu().&#xA;CVE-2022-48916:In the Linux kernel, the following vulnerability has been resolved:&#xA;iommu/vt-d: Fix double list_add when enabling VMD in scalable mode&#xA;When enabling VMD and IOMMU scalable mode, the following kernel panic&#xA;call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids&#xA;CPU) during booting:&#xA;pci 0000:59:00.5: Adding to iommu group 42&#xA;...&#xA;vmd 0000:59:00.5: PCI host bridge to bus 10000:80&#xA;pci 10000:80:01.0: [8086:352a] type 01 class 0x060400&#xA;pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]&#xA;pci 10000:80:01.0: enabling Extended Tags&#xA;pci 10000:80:01.0: PME# supported from D0 D3hot D3cold&#xA;pci 10000:80:01.0: DMAR: Setup RID2PASID failed&#xA;pci 10000:80:01.0: Failed to add to iommu group 42: -16&#xA;pci 10000:80:03.0: [8086:352b] type 01 class 0x060400&#xA;pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]&#xA;pci 10000:80:03.0: enabling Extended Tags&#xA;pci 10000:80:03.0: PME# supported from D0 D3hot D3cold&#xA;------------[ cut here ]------------&#xA;kernel BUG at lib/list_debug.c:29!&#xA;invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7&#xA;Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022&#xA;Workqueue: events work_for_cpu_fn&#xA;RIP: 0010:__list_add_valid.cold+0x26/0x3f&#xA;Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f&#xA;      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1&#xA;      fe ff &lt;0f&gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9&#xA;      9e e8 8b b1 fe&#xA;RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246&#xA;RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8&#xA;RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20&#xA;RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888&#xA;R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0&#xA;R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70&#xA;FS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; intel_pasid_alloc_table+0x9c/0x1d0&#xA; dmar_insert_one_dev_info+0x423/0x540&#xA; ? device_to_iommu+0x12d/0x2f0&#xA; intel_iommu_attach_device+0x116/0x290&#xA; __iommu_attach_device+0x1a/0x90&#xA; iommu_group_add_device+0x190/0x2c0&#xA; __iommu_probe_device+0x13e/0x250&#xA; iommu_probe_device+0x24/0x150&#xA; iommu_bus_notifier+0x69/0x90&#xA; blocking_notifier_call_chain+0x5a/0x80&#xA; device_add+0x3db/0x7b0&#xA; ? arch_memremap_can_ram_remap+0x19/0x50&#xA; ? memremap+0x75/0x140&#xA; pci_device_add+0x193/0x1d0&#xA; pci_scan_single_device+0xb9/0xf0&#xA; pci_scan_slot+0x4c/0x110&#xA; pci_scan_child_bus_extend+0x3a/0x290&#xA; vmd_enable_domain.constprop.0+0x63e/0x820&#xA; vmd_probe+0x163/0x190&#xA; local_pci_probe+0x42/0x80&#xA; work_for_cpu_fn+0x13/0x20&#xA; process_one_work+0x1e2/0x3b0&#xA; worker_thread+0x1c4/0x3a0&#xA; ? rescuer_thread+0x370/0x370&#xA; kthread+0xc7/0xf0&#xA; ? kthread_complete_and_exit+0x20/0x20&#xA; ret_from_fork+0x1f/0x30&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;---[ end trace 0000000000000000 ]---&#xA;...&#xA;Kernel panic - not syncing: Fatal exception&#xA;Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)&#xA;---[ end Kernel panic - not syncing: Fatal exception ]---&#xA;The following &#39;lspci&#39; output shows devices &#39;10000:80:*&#39; are subdevices of&#xA;the VMD device 0000:59:00.5:&#xA;  $ lspci&#xA;  ...&#xA;  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)&#xA;  ...&#xA;  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)&#xA;  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)&#xA;  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)&#xA;  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)&#xA;  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]&#xA;  10000:82:00&#xA;---truncated---&#xA;CVE-2024-43894:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/client: fix null pointer dereference in drm_client_modeset_probe&#xA;In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is&#xA;assigned to modeset-&gt;mode, which will lead to a possible NULL pointer&#xA;dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2024-46675:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: dwc3: core: Prevent USB core invalid event buffer address access&#xA;This commit addresses an issue where the USB core could access an&#xA;invalid event buffer address during runtime suspend, potentially causing&#xA;SMMU faults and other memory issues in Exynos platforms. The problem&#xA;arises from the following sequence.&#xA;        1. In dwc3_gadget_suspend, there is a chance of a timeout when&#xA;        moving the USB core to the halt state after clearing the&#xA;        run/stop bit by software.&#xA;        2. In dwc3_core_exit, the event buffer is cleared regardless of&#xA;        the USB core&#39;s status, which may lead to an SMMU faults and&#xA;        other memory issues. if the USB core tries to access the event&#xA;        buffer address.&#xA;To prevent this hardware quirk on Exynos platforms, this commit ensures&#xA;that the event buffer address is not cleared by software  when the USB&#xA;core is active during runtime suspend by checking its status before&#xA;clearing the buffer address.&#xA;CVE-2024-46689:In the Linux kernel, the following vulnerability has been resolved:&#xA;soc: qcom: cmd-db: Map shared memory as WC, not WB&#xA;Linux does not write into cmd-db region. This region of memory is write&#xA;protected by XPU. XPU may sometime falsely detect clean cache eviction&#xA;as &#34;write&#34; into the write protected region leading to secure interrupt&#xA;which causes an endless loop somewhere in Trust Zone.&#xA;The only reason it is working right now is because Qualcomm Hypervisor&#xA;maps the same region as Non-Cacheable memory in Stage 2 translation&#xA;tables. The issue manifests if we want to use another hypervisor (like&#xA;Xen or KVM), which does not know anything about those specific mappings.&#xA;Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC&#xA;removes dependency on correct mappings in Stage 2 tables. This patch&#xA;fixes the issue by updating the mapping to MEMREMAP_WC.&#xA;I tested this on SA8155P with Xen.&#xA;CVE-2024-46724:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number&#xA;Check the fb_channel_number range to avoid the array out-of-bounds&#xA;read error&#xA;CVE-2024-46722:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amdgpu: fix mc_data out-of-bounds read warning&#xA;Clear warning that read mc_data[i-1] may out-of-bounds.&#xA;CVE-2024-46757:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (nct6775-core) Fix underflows seen when writing limit attributes&#xA;DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large&#xA;negative number such as -9223372036854775808 is provided by the user.&#xA;Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.&#xA;CVE-2024-46830:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: x86: Acquire kvm-&gt;srcu when handling KVM_SET_VCPU_EVENTS&#xA;Grab kvm-&gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly&#xA;leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX&#xA;reads guest memory.&#xA;Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN&#xA;via sync_regs(), which already holds SRCU.  I.e. trying to precisely use&#xA;kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause&#xA;problems.  Acquiring SRCU isn&#39;t all that expensive, so for simplicity,&#xA;grab it unconditionally for KVM_SET_VCPU_EVENTS.&#xA; =============================&#xA; WARNING: suspicious RCU usage&#xA; 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted&#xA; -----------------------------&#xA; include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!&#xA; other info that might help us debug this:&#xA; rcu_scheduler_active = 2, debug_locks = 1&#xA; 1 lock held by repro/1071:&#xA;  #0: ffff88811e424430 (&amp;vcpu-&gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]&#xA; stack backtrace:&#xA; CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  dump_stack_lvl+0x7f/0x90&#xA;  lockdep_rcu_suspicious+0x13f/0x1a0&#xA;  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]&#xA;  kvm_vcpu_read_guest+0x3e/0x90 [kvm]&#xA;  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]&#xA;  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]&#xA;  vmx_leave_nested+0x30/0x40 [kvm_intel]&#xA;  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]&#xA;  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]&#xA;  ? mark_held_locks+0x49/0x70&#xA;  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]&#xA;  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]&#xA;  kvm_vcpu_ioctl+0x497/0x970 [kvm]&#xA;  ? lock_acquire+0xba/0x2d0&#xA;  ? find_held_lock+0x2b/0x80&#xA;  ? do_user_addr_fault+0x40c/0x6f0&#xA;  ? lock_release+0xb7/0x270&#xA;  __x64_sys_ioctl+0x82/0xb0&#xA;  do_syscall_64+0x6c/0x170&#xA;  entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA; RIP: 0033:0x7ff11eb1b539&#xA;  &lt;/TASK&gt;&#xA;CVE-2024-46802:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: added NULL check at start of dc_validate_stream&#xA;[Why]&#xA;prevent invalid memory access&#xA;[How]&#xA;check if dc and stream are NULL&#xA;CVE-2024-46853:In the Linux kernel, the following vulnerability has been resolved:&#xA;spi: nxp-fspi: fix the KASAN report out-of-bounds bug&#xA;Change the memcpy length to fix the out-of-bounds issue when writing the&#xA;data that is not 4 byte aligned to TX FIFO.&#xA;To reproduce the issue, write 3 bytes data to NOR chip.&#xA;dd if=3b of=/dev/mtd0&#xA;[   36.926103] ==================================================================&#xA;[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838&#xA;[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455&#xA;[   36.946721]&#xA;[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070&#xA;[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)&#xA;[   36.961260] Call trace:&#xA;[   36.963723]  dump_backtrace+0x90/0xe8&#xA;[   36.967414]  show_stack+0x18/0x24&#xA;[   36.970749]  dump_stack_lvl+0x78/0x90&#xA;[   36.974451]  print_report+0x114/0x5cc&#xA;[   36.978151]  kasan_report+0xa4/0xf0&#xA;[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28&#xA;[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838&#xA;[   36.990800]  spi_mem_exec_op+0x8ec/0xd30&#xA;[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0&#xA;[   36.999323]  spi_mem_dirmap_write+0x238/0x32c&#xA;[   37.003710]  spi_nor_write_data+0x220/0x374&#xA;[   37.007932]  spi_nor_write+0x110/0x2e8&#xA;[   37.011711]  mtd_write_oob_std+0x154/0x1f0&#xA;[   37.015838]  mtd_write_oob+0x104/0x1d0&#xA;[   37.019617]  mtd_write+0xb8/0x12c&#xA;[   37.022953]  mtdchar_write+0x224/0x47c&#xA;[   37.026732]  vfs_write+0x1e4/0x8c8&#xA;[   37.030163]  ksys_write+0xec/0x1d0&#xA;[   37.033586]  __arm64_sys_write+0x6c/0x9c&#xA;[   37.037539]  invoke_syscall+0x6c/0x258&#xA;[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c&#xA;[   37.046244]  do_el0_svc+0x44/0x5c&#xA;[   37.049589]  el0_svc+0x38/0x78&#xA;[   37.052681]  el0t_64_sync_handler+0x13c/0x158&#xA;[   37.057077]  el0t_64_sync+0x190/0x194&#xA;[   37.060775]&#xA;[   37.062274] Allocated by task 455:&#xA;[   37.065701]  kasan_save_stack+0x2c/0x54&#xA;[   37.069570]  kasan_save_track+0x20/0x3c&#xA;[   37.073438]  kasan_save_alloc_info+0x40/0x54&#xA;[   37.077736]  __kasan_kmalloc+0xa0/0xb8&#xA;[   37.081515]  __kmalloc_noprof+0x158/0x2f8&#xA;[   37.085563]  mtd_kmalloc_up_to+0x120/0x154&#xA;[   37.089690]  mtdchar_write+0x130/0x47c&#xA;[   37.093469]  vfs_write+0x1e4/0x8c8&#xA;[   37.096901]  ksys_write+0xec/0x1d0&#xA;[   37.100332]  __arm64_sys_write+0x6c/0x9c&#xA;[   37.104287]  invoke_syscall+0x6c/0x258&#xA;[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c&#xA;[   37.112972]  do_el0_svc+0x44/0x5c&#xA;[   37.116319]  el0_svc+0x38/0x78&#xA;[   37.119401]  el0t_64_sync_handler+0x13c/0x158&#xA;[   37.123788]  el0t_64_sync+0x190/0x194&#xA;[   37.127474]&#xA;[   37.128977] The buggy address belongs to the object at ffff00081037c2a0&#xA;[   37.128977]  which belongs to the cache kmalloc-8 of size 8&#xA;[   37.141177] The buggy address is located 0 bytes inside of&#xA;[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)&#xA;[   37.153465]&#xA;[   37.154971] The buggy address belongs to the physical page:&#xA;[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c&#xA;[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)&#xA;[   37.175149] page_type: 0xfdffffff(slab)&#xA;[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000&#xA;[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000&#xA;[   37.194553] page dumped because: kasan: bad access detected&#xA;[   37.200144]&#xA;[   37.201647] Memory state around the buggy address:&#xA;[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc&#xA;[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc&#xA;[   37.220946] &gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc&#xA;[   37.228186]                                ^&#xA;[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;[   37.246962] ==============================================================&#xA;---truncated---&#xA;CVE-2024-47667:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)&#xA;Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0&#xA;(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an&#xA;inbound PCIe TLP spans more than two internal AXI 128-byte bursts,&#xA;the bus may corrupt the packet payload and the corrupt data may&#xA;cause associated applications or the processor to hang.&#xA;The workaround for Errata #i2037 is to limit the maximum read&#xA;request size and maximum payload size to 128 bytes. Add workaround&#xA;for Errata #i2037 here.&#xA;The errata and workaround is applicable only to AM65x SR 1.0 and&#xA;later versions of the silicon will have this fixed.&#xA;[1] -&gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf&#xA;CVE-2024-47669:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix state management in error path of log writing function&#xA;After commit a694291a6211 (&#34;nilfs2: separate wait function from&#xA;nilfs_segctor_write&#34;) was applied, the log writing function&#xA;nilfs_segctor_do_construct() was able to issue I/O requests continuously&#xA;even if user data blocks were split into multiple logs across segments,&#xA;but two potential flaws were introduced in its error handling.&#xA;First, if nilfs_segctor_begin_construction() fails while creating the&#xA;second or subsequent logs, the log writing function returns without&#xA;calling nilfs_segctor_abort_construction(), so the writeback flag set on&#xA;pages/folios will remain uncleared.  This causes page cache operations to&#xA;hang waiting for the writeback flag.  For example,&#xA;truncate_inode_pages_final(), which is called via nilfs_evict_inode() when&#xA;an inode is evicted from memory, will hang.&#xA;Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. &#xA;As a result, if the next log write involves checkpoint creation, that&#39;s&#xA;fine, but if a partial log write is performed that does not, inodes with&#xA;NILFS_I_COLLECTED set are erroneously removed from the &#34;sc_dirty_files&#34;&#xA;list, and their data and b-tree blocks may not be written to the device,&#xA;corrupting the block mapping.&#xA;Fix these issues by uniformly calling nilfs_segctor_abort_construction()&#xA;on failure of each step in the loop in nilfs_segctor_do_construct(),&#xA;having it clean up logs and segment usages according to progress, and&#xA;correcting the conditions for calling nilfs_redirty_inodes() to ensure&#xA;that the NILFS_I_COLLECTED flag is cleared.&#xA;CVE-2024-47720:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func&#xA;This commit adds a null check for the set_output_gamma function pointer&#xA;in the  dcn30_set_output_transfer_func function. Previously,&#xA;set_output_gamma was being checked for nullity at line 386, but then it&#xA;was being dereferenced without any nullity check at line 401. This&#xA;could potentially lead to a null pointer dereference error if&#xA;set_output_gamma is indeed null.&#xA;To fix this, we now ensure that set_output_gamma is not null before&#xA;dereferencing it. We do this by adding a nullity check for&#xA;set_output_gamma before the call to set_output_gamma at line 401. If&#xA;set_output_gamma is null, we log an error message and do not call the&#xA;function.&#xA;This fix prevents a potential null pointer dereference error.&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func()&#xA;error: we previously assumed &#39;mpc-&gt;funcs-&gt;set_output_gamma&#39; could be null (see line 386)&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c&#xA;    373 bool dcn30_set_output_transfer_func(struct dc *dc,&#xA;    374                                 struct pipe_ctx *pipe_ctx,&#xA;    375                                 const struct dc_stream_state *stream)&#xA;    376 {&#xA;    377         int mpcc_id = pipe_ctx-&gt;plane_res.hubp-&gt;inst;&#xA;    378         struct mpc *mpc = pipe_ctx-&gt;stream_res.opp-&gt;ctx-&gt;dc-&gt;res_pool-&gt;mpc;&#xA;    379         const struct pwl_params *params = NULL;&#xA;    380         bool ret = false;&#xA;    381&#xA;    382         /* program OGAM or 3DLUT only for the top pipe*/&#xA;    383         if (pipe_ctx-&gt;top_pipe == NULL) {&#xA;    384                 /*program rmu shaper and 3dlut in MPC*/&#xA;    385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);&#xA;    386                 if (ret == false &amp;&amp; mpc-&gt;funcs-&gt;set_output_gamma) {&#xA;                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL&#xA;    387                         if (stream-&gt;out_transfer_func.type == TF_TYPE_HWPWL)&#xA;    388                                 params = &amp;stream-&gt;out_transfer_func.pwl;&#xA;    389                         else if (pipe_ctx-&gt;stream-&gt;out_transfer_func.type ==&#xA;    390                                         TF_TYPE_DISTRIBUTED_POINTS &amp;&amp;&#xA;    391                                         cm3_helper_translate_curve_to_hw_format(&#xA;    392                                         &amp;stream-&gt;out_transfer_func,&#xA;    393                                         &amp;mpc-&gt;blender_params, false))&#xA;    394                                 params = &amp;mpc-&gt;blender_params;&#xA;    395                          /* there are no ROM LUTs in OUTGAM */&#xA;    396                         if (stream-&gt;out_transfer_func.type == TF_TYPE_PREDEFINED)&#xA;    397                                 BREAK_TO_DEBUGGER();&#xA;    398                 }&#xA;    399         }&#xA;    400&#xA;--&gt; 401         mpc-&gt;funcs-&gt;set_output_gamma(mpc, mpcc_id, params);&#xA;                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash&#xA;    402         return ret;&#xA;    403 }&#xA;CVE-2024-47698:In the Linux kernel, the following vulnerability has been resolved:&#xA;drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error&#xA;Ensure index in rtl2832_pid_filter does not exceed 31 to prevent&#xA;out-of-bounds access.&#xA;dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should&#xA;only operate on indices from 0 to 31. If index is 32, it will attempt to&#xA;access a non-existent 33rd bit, leading to out-of-bounds access.&#xA;Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this&#xA;issue.&#xA;[hverkuil: added fixes tag, rtl2830_pid_filter -&gt; rtl2832_pid_filter in logmsg]&#xA;CVE-2024-47695:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds&#xA;In the function init_conns(), after the create_con() and create_cm() for&#xA;loop if something fails. In the cleanup for loop after the destroy tag, we&#xA;access out of bound memory because cid is set to clt_path-&gt;s.con_num.&#xA;This commits resets the cid to clt_path-&gt;s.con_num - 1, to stay in bounds&#xA;in the cleanup loop later.&#xA;CVE-2024-47684:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: check skb is non-NULL in tcp_rto_delta_us()&#xA;We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic&#xA;kernel that are running ceph and recently hit a null ptr dereference in&#xA;tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also&#xA;saw it getting hit from the RACK case as well. Here are examples of the oops&#xA;messages we saw in each of those cases:&#xA;Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020&#xA;Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode&#xA;Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page&#xA;Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0&#xA;Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI&#xA;Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu&#xA;Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023&#xA;Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160&#xA;Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 &lt;48&gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3&#xA;Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246&#xA;Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000&#xA;Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60&#xA;Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8&#xA;Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900&#xA;Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30&#xA;Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000&#xA;Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0&#xA;Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554&#xA;Jul 26 15:05:02 rx [11061395.916786] Call Trace:&#xA;Jul 26 15:05:02 rx [11061395.919488]&#xA;Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f&#xA;Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9&#xA;Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380&#xA;Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0&#xA;Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50&#xA;Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0&#xA;Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20&#xA;Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450&#xA;Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140&#xA;Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90&#xA;Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0&#xA;Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40&#xA;Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160&#xA;Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160&#xA;Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220&#xA;Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240&#xA;Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0&#xA;Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240&#xA;Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130&#xA;Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280&#xA;Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10&#xA;Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30&#xA;Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even&#xA;---truncated---&#xA;CVE-2024-47685:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()&#xA;syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending&#xA;garbage on the four reserved tcp bits (th-&gt;res1)&#xA;Use skb_put_zero() to clear the whole TCP header,&#xA;as done in nf_reject_ip_tcphdr_put()&#xA;BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255&#xA;  nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255&#xA;  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344&#xA;  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48&#xA;  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]&#xA;  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288&#xA;  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161&#xA;  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA;  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626&#xA;  nf_hook include/linux/netfilter.h:269 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:312 [inline]&#xA;  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310&#xA;  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]&#xA;  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775&#xA;  process_backlog+0x4ad/0xa50 net/core/dev.c:6108&#xA;  __napi_poll+0xe7/0x980 net/core/dev.c:6772&#xA;  napi_poll net/core/dev.c:6841 [inline]&#xA;  net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963&#xA;  handle_softirqs+0x1ce/0x800 kernel/softirq.c:554&#xA;  __do_softirq+0x14/0x1a kernel/softirq.c:588&#xA;  do_softirq+0x9a/0x100 kernel/softirq.c:455&#xA;  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382&#xA;  local_bh_enable include/linux/bottom_half.h:33 [inline]&#xA;  rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]&#xA;  __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450&#xA;  dev_queue_xmit include/linux/netdevice.h:3105 [inline]&#xA;  neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565&#xA;  neigh_output include/net/neighbour.h:542 [inline]&#xA;  ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141&#xA;  __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]&#xA;  ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226&#xA;  NF_HOOK_COND include/linux/netfilter.h:303 [inline]&#xA;  ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247&#xA;  dst_output include/net/dst.h:450 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:314 [inline]&#xA;  ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366&#xA;  inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135&#xA;  __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466&#xA;  tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]&#xA;  tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143&#xA;  tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333&#xA;  __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679&#xA;  inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750&#xA;  __sys_connect_file net/socket.c:2061 [inline]&#xA;  __sys_connect+0x606/0x690 net/socket.c:2078&#xA;  __do_sys_connect net/socket.c:2088 [inline]&#xA;  __se_sys_connect net/socket.c:2085 [inline]&#xA;  __x64_sys_connect+0x91/0xe0 net/socket.c:2085&#xA;  x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was stored to memory at:&#xA;  nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249&#xA;  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344&#xA;  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48&#xA;  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]&#xA;  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288&#xA;  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161&#xA;  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA;  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626&#xA;  nf_hook include/linux/netfilter.h:269 [inline]&#xA;  NF_HOOK include/linux/netfilter.h:312 [inline]&#xA;  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310&#xA;  __netif_receive_skb_one_core&#xA;---truncated---&#xA;CVE-2024-47710:In the Linux kernel, the following vulnerability has been resolved:&#xA;sock_map: Add a cond_resched() in sock_hash_free()&#xA;Several syzbot soft lockup reports all have in common sock_hash_free()&#xA;If a map with a large number of buckets is destroyed, we need to yield&#xA;the cpu when needed.&#xA;CVE-2023-52917:In the Linux kernel, the following vulnerability has been resolved:&#xA;ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()&#xA;The debugfs_create_dir() function returns error pointers.&#xA;It never returns NULL. So use IS_ERR() to check it.&#xA;CVE-2024-47737:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfsd: call cache_put if xdr_reserve_space returns NULL&#xA;If not enough buffer space available, but idmap_lookup has triggered&#xA;lookup_fn which calls cache_get and returns successfully. Then we&#xA;missed to call cache_put here which pairs with cache_get.&#xA;Reviwed-by: Jeff Layton &lt;jlayton@kernel.org&gt;&#xA;CVE-2024-47757:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential oob read in nilfs_btree_check_delete()&#xA;The function nilfs_btree_check_delete(), which checks whether degeneration&#xA;to direct mapping occurs before deleting a b-tree entry, causes memory&#xA;access outside the block buffer when retrieving the maximum key if the&#xA;root node has no entries.&#xA;This does not usually happen because b-tree mappings with 0 child nodes&#xA;are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen&#xA;if the b-tree root node read from a device is configured that way, so fix&#xA;this potential issue by adding a check for that case.&#xA;CVE-2024-47756:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: keystone: Fix if-statement expression in ks_pcie_quirk()&#xA;This code accidentally uses &amp;&amp; where || was intended.  It potentially&#xA;results in a NULL dereference.&#xA;Thus, fix the if-statement expression to use the correct condition.&#xA;[kwilczynski: commit log]&#xA;CVE-2024-49875:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfsd: map the EBADMSG to nfserr_io to avoid warning&#xA;Ext4 will throw -EBADMSG through ext4_readdir when a checksum error&#xA;occurs, resulting in the following WARNING.&#xA;Fix it by mapping EBADMSG to nfserr_io.&#xA;nfsd_buffered_readdir&#xA; iterate_dir // -EBADMSG -74&#xA;  ext4_readdir // .iterate_shared&#xA;   ext4_dx_readdir&#xA;    ext4_htree_fill_tree&#xA;     htree_dirblock_to_tree&#xA;      ext4_read_dirblock&#xA;       __ext4_read_dirblock&#xA;        ext4_dirblock_csum_verify&#xA;         warn_no_space_for_csum&#xA;          __warn_no_space_for_csum&#xA;        return ERR_PTR(-EFSBADCRC) // -EBADMSG -74&#xA; nfserrno // WARNING&#xA;[  161.115610] ------------[ cut here ]------------&#xA;[  161.116465] nfsd: non-standard errno: -74&#xA;[  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0&#xA;[  161.118596] Modules linked in:&#xA;[  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138&#xA;[  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe&#xA;mu.org 04/01/2014&#xA;[  161.123601] RIP: 0010:nfserrno+0x9d/0xd0&#xA;[  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6&#xA; 05 ce 2b 61 03 01 e8 99 20 d8 00 &lt;0f&gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33&#xA;[  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286&#xA;[  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000&#xA;[  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a&#xA;[  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827&#xA;[  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021&#xA;[  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8&#xA;[  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000&#xA;[  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0&#xA;[  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  161.141519] PKRU: 55555554&#xA;[  161.142076] Call Trace:&#xA;[  161.142575]  ? __warn+0x9b/0x140&#xA;[  161.143229]  ? nfserrno+0x9d/0xd0&#xA;[  161.143872]  ? report_bug+0x125/0x150&#xA;[  161.144595]  ? handle_bug+0x41/0x90&#xA;[  161.145284]  ? exc_invalid_op+0x14/0x70&#xA;[  161.146009]  ? asm_exc_invalid_op+0x12/0x20&#xA;[  161.146816]  ? nfserrno+0x9d/0xd0&#xA;[  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0&#xA;[  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380&#xA;[  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0&#xA;[  161.150093]  ? wait_for_concurrent_writes+0x170/0x170&#xA;[  161.151004]  ? generic_file_llseek_size+0x48/0x160&#xA;[  161.151895]  nfsd_readdir+0x132/0x190&#xA;[  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380&#xA;[  161.153516]  ? nfsd_unlink+0x380/0x380&#xA;[  161.154256]  ? override_creds+0x45/0x60&#xA;[  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0&#xA;[  161.155850]  ? nfsd4_encode_readlink+0x210/0x210&#xA;[  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0&#xA;[  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0&#xA;[  161.158494]  ? lock_downgrade+0x90/0x90&#xA;[  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10&#xA;[  161.160092]  nfsd4_encode_operation+0x15a/0x440&#xA;[  161.160959]  nfsd4_proc_compound+0x718/0xe90&#xA;[  161.161818]  nfsd_dispatch+0x18e/0x2c0&#xA;[  161.162586]  svc_process_common+0x786/0xc50&#xA;[  161.163403]  ? nfsd_svc+0x380/0x380&#xA;[  161.164137]  ? svc_printk+0x160/0x160&#xA;[  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380&#xA;[  161.165808]  ? nfsd_svc+0x380/0x380&#xA;[  161.166523]  ? rcu_is_watching+0x23/0x40&#xA;[  161.167309]  svc_process+0x1a5/0x200&#xA;[  161.168019]  nfsd+0x1f5/0x380&#xA;[  161.168663]  ? nfsd_shutdown_threads+0x260/0x260&#xA;[  161.169554]  kthread+0x1c4/0x210&#xA;[  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80&#xA;[  161.171246]  ret_from_fork+0x1f/0x30&#xA;CVE-2024-49911:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func&#xA;This commit adds a null check for the set_output_gamma function pointer&#xA;in the dcn20_set_output_transfer_func function. Previously,&#xA;set_output_gamma was being checked for null at line 1030, but then it&#xA;was being dereferenced without any null check at line 1048. This could&#xA;potentially lead to a null pointer dereference error if set_output_gamma&#xA;is null.&#xA;To fix this, we now ensure that set_output_gamma is not null before&#xA;dereferencing it. We do this by adding a null check for set_output_gamma&#xA;before the call to set_output_gamma at line 1048.&#xA;CVE-2024-49900:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: Fix uninit-value access of new_ea in ea_buffer&#xA;syzbot reports that lzo1x_1_do_compress is using uninit-value:&#xA;=====================================================&#xA;BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178&#xA;...&#xA;Uninit was stored to memory at:&#xA; ea_put fs/jfs/xattr.c:639 [inline]&#xA;...&#xA;Local variable ea_buf created at:&#xA; __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662&#xA; __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934&#xA;=====================================================&#xA;The reason is ea_buf-&gt;new_ea is not initialized properly.&#xA;Fix this by using memset to empty its content at the beginning&#xA;in ea_get().&#xA;CVE-2024-49894:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix index out of bounds in degamma hardware format translation&#xA;Fixes index out of bounds issue in&#xA;`cm_helper_translate_curve_to_degamma_hw_format` function. The issue&#xA;could occur when the index &#39;i&#39; exceeds the number of transfer function&#xA;points (TRANSFER_FUNC_POINTS).&#xA;The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the&#xA;transfer function points. If &#39;i&#39; is out of bounds the function returns&#xA;false to indicate an error.&#xA;Reported by smatch:&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max&#xA;CVE-2024-49974:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSD: Limit the number of concurrent async COPY operations&#xA;Nothing appears to limit the number of concurrent async COPY&#xA;operations that clients can start. In addition, AFAICT each async&#xA;COPY can copy an unlimited number of 4MB chunks, so can run for a&#xA;long time. Thus IMO async COPY can become a DoS vector.&#xA;Add a restriction mechanism that bounds the number of concurrent&#xA;background COPY operations. Start simple and try to be fair -- this&#xA;patch implements a per-namespace limit.&#xA;An async COPY request that occurs while this limit is exceeded gets&#xA;NFS4ERR_DELAY. The requesting client can choose to send the request&#xA;again after a delay or fall back to a traditional read/write style&#xA;copy.&#xA;If there is need to make the mechanism more sophisticated, we can&#xA;visit that in future patches.&#xA;CVE-2024-49895:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation&#xA;This commit addresses a potential index out of bounds issue in the&#xA;`cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30&#xA;color  management module. The issue could occur when the index &#39;i&#39;&#xA;exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).&#xA;The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the&#xA;transfer function points. If &#39;i&#39; is out of bounds, the function returns&#xA;false to indicate an error.&#xA;Reported by smatch:&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max&#xA;CVE-2024-49867:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: wait for fixup workers before stopping cleaner kthread during umount&#xA;During unmount, at close_ctree(), we have the following steps in this order:&#xA;1) Park the cleaner kthread - this doesn&#39;t destroy the kthread, it basically&#xA;   halts its execution (wake ups against it work but do nothing);&#xA;2) We stop the cleaner kthread - this results in freeing the respective&#xA;   struct task_struct;&#xA;3) We call btrfs_stop_all_workers() which waits for any jobs running in all&#xA;   the work queues and then free the work queues.&#xA;Syzbot reported a case where a fixup worker resulted in a crash when doing&#xA;a delayed iput on its inode while attempting to wake up the cleaner at&#xA;btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread&#xA;was already freed. This can happen during unmount because we don&#39;t wait&#xA;for any fixup workers still running before we call kthread_stop() against&#xA;the cleaner kthread, which stops and free all its resources.&#xA;Fix this by waiting for any fixup workers at close_ctree() before we call&#xA;kthread_stop() against the cleaner and run pending delayed iputs.&#xA;The stack traces reported by syzbot were the following:&#xA;  BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065&#xA;  Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52&#xA;  CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0&#xA;  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;  Workqueue: btrfs-fixup btrfs_work_helper&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   __dump_stack lib/dump_stack.c:94 [inline]&#xA;   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA;   print_address_description mm/kasan/report.c:377 [inline]&#xA;   print_report+0x169/0x550 mm/kasan/report.c:488&#xA;   kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA;   __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065&#xA;   lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825&#xA;   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]&#xA;   _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162&#xA;   class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]&#xA;   try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154&#xA;   btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842&#xA;   btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314&#xA;   process_one_work kernel/workqueue.c:3229 [inline]&#xA;   process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310&#xA;   worker_thread+0x870/0xd30 kernel/workqueue.c:3391&#xA;   kthread+0x2f0/0x390 kernel/kthread.c:389&#xA;   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;   &lt;/TASK&gt;&#xA;  Allocated by task 2:&#xA;   kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;   unpoison_slab_object mm/kasan/common.c:319 [inline]&#xA;   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345&#xA;   kasan_slab_alloc include/linux/kasan.h:247 [inline]&#xA;   slab_post_alloc_hook mm/slub.c:4086 [inline]&#xA;   slab_alloc_node mm/slub.c:4135 [inline]&#xA;   kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187&#xA;   alloc_task_struct_node kernel/fork.c:180 [inline]&#xA;   dup_task_struct+0x57/0x8c0 kernel/fork.c:1107&#xA;   copy_process+0x5d1/0x3d50 kernel/fork.c:2206&#xA;   kernel_clone+0x223/0x880 kernel/fork.c:2787&#xA;   kernel_thread+0x1bc/0x240 kernel/fork.c:2849&#xA;   create_kthread kernel/kthread.c:412 [inline]&#xA;   kthreadd+0x60d/0x810 kernel/kthread.c:765&#xA;   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;  Freed by task 61:&#xA;   kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579&#xA;   poison_slab_object mm/kasan/common.c:247 [inline]&#xA;   __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264&#xA;   kasan_slab_free include/linux/kasan.h:230 [inline]&#xA;   slab_free_h&#xA;---truncated---&#xA;CVE-2024-49902:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: check if leafidx greater than num leaves per dmap tree&#xA;syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater&#xA;than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.&#xA;Shaggy:&#xA;Modified sanity check to apply to control pages as well as leaf pages.&#xA;CVE-2024-49866:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing/timerlat: Fix a race during cpuhp processing&#xA;There is another found exception that the &#34;timerlat/1&#34; thread was&#xA;scheduled on CPU0, and lead to timer corruption finally:&#xA;```&#xA;ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220&#xA;WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014&#xA;RIP: 0010:debug_print_object+0x7d/0xb0&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __warn+0x7c/0x110&#xA; ? debug_print_object+0x7d/0xb0&#xA; ? report_bug+0xf1/0x1d0&#xA; ? prb_read_valid+0x17/0x20&#xA; ? handle_bug+0x3f/0x70&#xA; ? exc_invalid_op+0x13/0x60&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? debug_print_object+0x7d/0xb0&#xA; ? debug_print_object+0x7d/0xb0&#xA; ? __pfx_timerlat_irq+0x10/0x10&#xA; __debug_object_init+0x110/0x150&#xA; hrtimer_init+0x1d/0x60&#xA; timerlat_main+0xab/0x2d0&#xA; ? __pfx_timerlat_main+0x10/0x10&#xA; kthread+0xb7/0xe0&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x2d/0x40&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;```&#xA;After tracing the scheduling event, it was discovered that the migration&#xA;of the &#34;timerlat/1&#34; thread was performed during thread creation. Further&#xA;analysis confirmed that it is because the CPU online processing for&#xA;osnoise is implemented through workers, which is asynchronous with the&#xA;offline processing. When the worker was scheduled to create a thread, the&#xA;CPU may has already been removed from the cpu_online_mask during the offline&#xA;process, resulting in the inability to select the right CPU:&#xA;T1                       | T2&#xA;[CPUHP_ONLINE]           | cpu_device_down()&#xA;osnoise_hotplug_workfn() |&#xA;                         |     cpus_write_lock()&#xA;                         |     takedown_cpu(1)&#xA;                         |     cpus_write_unlock()&#xA;[CPUHP_OFFLINE]          |&#xA;    cpus_read_lock()     |&#xA;    start_kthread(1)     |&#xA;    cpus_read_unlock()   |&#xA;To fix this, skip online processing if the CPU is already offline.&#xA;CVE-2024-49969:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Fix index out of bounds in DCN30 color transformation&#xA;This commit addresses a potential index out of bounds issue in the&#xA;`cm3_helper_translate_curve_to_hw_format` function in the DCN30 color&#xA;management module. The issue could occur when the index &#39;i&#39; exceeds the&#xA;number of transfer function points (TRANSFER_FUNC_POINTS).&#xA;The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the&#xA;transfer function points. If &#39;i&#39; is out of bounds, the function returns&#xA;false to indicate an error.&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max&#xA;CVE-2024-50007:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: asihpi: Fix potential OOB array access&#xA;ASIHPI driver stores some values in the static array upon a response&#xA;from the driver, and its index depends on the firmware.  We shouldn&#39;t&#xA;trust it blindly.&#xA;This patch adds a sanity check of the array index to fit in the array&#xA;size.&#xA;CVE-2024-49868:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: fix a NULL pointer dereference when failed to start a new trasacntion&#xA;[BUG]&#xA;Syzbot reported a NULL pointer dereference with the following crash:&#xA;  FAULT_INJECTION: forcing a failure.&#xA;   start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676&#xA;   prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642&#xA;   relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678&#xA;  ...&#xA;  BTRFS info (device loop0): balance: ended with status: -12&#xA;  Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;  KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]&#xA;  RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496&#xA;   btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430&#xA;   del_balance_item fs/btrfs/volumes.c:3678 [inline]&#xA;   reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742&#xA;   btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574&#xA;   btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673&#xA;   vfs_ioctl fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893&#xA;   do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[CAUSE]&#xA;The allocation failure happens at the start_transaction() inside&#xA;prepare_to_relocate(), and during the error handling we call&#xA;unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.&#xA;Then we continue the error path cleanup in btrfs_balance() by calling&#xA;reset_balance_state() which will call del_balance_item() to fully delete&#xA;the balance item in the root tree.&#xA;However during the small window between set_reloc_contrl() and&#xA;unset_reloc_control(), we can have a subvolume tree update and created a&#xA;reloc_root for that subvolume.&#xA;Then we go into the final btrfs_commit_transaction() of&#xA;del_balance_item(), and into btrfs_update_reloc_root() inside&#xA;commit_fs_roots().&#xA;That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree&#xA;stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer&#xA;dereference.&#xA;[FIX]&#xA;Just add extra check on fs_info-&gt;reloc_ctl inside&#xA;btrfs_update_reloc_root(), before checking&#xA;fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.&#xA;That DEAD_RELOC_TREE handling is to prevent further modification to the&#xA;reloc tree during merge stage, but since there is no reloc_ctl at all,&#xA;we do not need to bother that.&#xA;CVE-2024-49903:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: Fix uaf in dbFreeBits&#xA;[syzbot reported]&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]&#xA;BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752&#xA;Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216&#xA;CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:93 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0x169/0x550 mm/kasan/report.c:488&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA; __mutex_lock_common kernel/locking/mutex.c:587 [inline]&#xA; __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752&#xA; dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390&#xA; dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]&#xA; dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409&#xA; dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650&#xA; jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100&#xA; jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA; __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA;Freed by task 5218:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA; kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579&#xA; poison_slab_object+0xe0/0x150 mm/kasan/common.c:240&#xA; __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256&#xA; kasan_slab_free include/linux/kasan.h:184 [inline]&#xA; slab_free_hook mm/slub.c:2252 [inline]&#xA; slab_free mm/slub.c:4473 [inline]&#xA; kfree+0x149/0x360 mm/slub.c:4594&#xA; dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278&#xA; jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247&#xA; jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454&#xA; reconfigure_super+0x445/0x880 fs/super.c:1083&#xA; vfs_cmd_reconfigure fs/fsopen.c:263 [inline]&#xA; vfs_fsconfig_locked fs/fsopen.c:292 [inline]&#xA; __do_sys_fsconfig fs/fsopen.c:473 [inline]&#xA; __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[Analysis]&#xA;There are two paths (dbUnmount and jfs_ioc_trim) that generate race&#xA;condition when accessing bmap, which leads to the occurrence of uaf.&#xA;Use the lock s_umount to synchronize them, in order to avoid uaf caused&#xA;by race condition.&#xA;CVE-2024-49985:In the Linux kernel, the following vulnerability has been resolved:&#xA;i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume&#xA;In case there is any sort of clock controller attached to this I2C bus&#xA;controller, for example Versaclock or even an AIC32x4 I2C codec, then&#xA;an I2C transfer triggered from the clock controller clk_ops .prepare&#xA;callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.&#xA;This is because the clock controller first grabs the prepare_lock mutex&#xA;and then performs the prepare operation, including its I2C access. The&#xA;I2C access resumes this I2C bus controller via .runtime_resume callback,&#xA;which calls clk_prepare_enable(), which attempts to grab the prepare_lock&#xA;mutex again and deadlocks.&#xA;Since the clock are already prepared since probe() and unprepared in&#xA;remove(), use simple clk_enable()/clk_disable() calls to enable and&#xA;disable the clock on runtime suspend and resume, to avoid hitting the&#xA;prepare_lock mutex.&#xA;CVE-2024-49927:In the Linux kernel, the following vulnerability has been resolved:&#xA;x86/ioapic: Handle allocation failures gracefully&#xA;Breno observed panics when using failslab under certain conditions during&#xA;runtime:&#xA;   can not alloc irq_pin_list (-1,0,20)&#xA;   Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed&#xA;   panic+0x4e9/0x590&#xA;   mp_irqdomain_alloc+0x9ab/0xa80&#xA;   irq_domain_alloc_irqs_locked+0x25d/0x8d0&#xA;   __irq_domain_alloc_irqs+0x80/0x110&#xA;   mp_map_pin_to_irq+0x645/0x890&#xA;   acpi_register_gsi_ioapic+0xe6/0x150&#xA;   hpet_open+0x313/0x480&#xA;That&#39;s a pointless panic which is a leftover of the historic IO/APIC code&#xA;which panic&#39;ed during early boot when the interrupt allocation failed.&#xA;The only place which might justify panic is the PIT/HPET timer_check() code&#xA;which tries to figure out whether the timer interrupt is delivered through&#xA;the IO/APIC. But that code does not require to handle interrupt allocation&#xA;failures. If the interrupt cannot be allocated then timer delivery fails&#xA;and it either panics due to that or falls back to legacy mode.&#xA;Cure this by removing the panic wrapper around __add_pin_to_irq_node() and&#xA;making mp_irqdomain_alloc() aware of the failure condition and handle it as&#xA;any other failure in this function gracefully.&#xA;CVE-2024-49966:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: cancel dqi_sync_work before freeing oinfo&#xA;ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the&#xA;end, if error occurs after successfully reading global quota, it will&#xA;trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:&#xA;ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c&#xA;This reports that there is an active delayed work when freeing oinfo in&#xA;error handling, so cancel dqi_sync_work first.  BTW, return status instead&#xA;of -1 when .read_file_info fails.&#xA;CVE-2022-49019:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ethernet: nixge: fix NULL dereference&#xA;In function nixge_hw_dma_bd_release() dereference of NULL pointer&#xA;priv-&gt;rx_bd_v is possible for the case of its allocation failure in&#xA;nixge_hw_dma_bd_init().&#xA;Move for() loop with priv-&gt;rx_bd_v dereference under the check for&#xA;its validity.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-50049:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check null pointer before dereferencing se&#xA;[WHAT &amp; HOW]&#xA;se is null checked previously in the same function, indicating&#xA;it might be null; therefore, it must be checked when used again.&#xA;This fixes 1 FORWARD_NULL issue reported by Coverity.&#xA;CVE-2022-48994:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event&#xA;With clang&#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),&#xA;indirect call targets are validated against the expected function&#xA;pointer prototype to make sure the call target is valid to help mitigate&#xA;ROP attacks. If they are not identical, there is a failure at run time,&#xA;which manifests as either a kernel panic or thread getting killed.&#xA;seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes&#xA;matching snd_seq_dump_func_t. Adjust this and remove the casts. There&#xA;are not resulting binary output differences.&#xA;This was found as a result of Clang&#39;s new -Wcast-function-type-strict&#xA;flag, which is more sensitive than the simpler -Wcast-function-type,&#xA;which only checks for type width mismatches.&#xA;CVE-2022-49029:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails&#xA;Smatch report warning as follows:&#xA;drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:&#xA;  &#39;&amp;data-&gt;list&#39; not removed from list&#xA;If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will&#xA;be freed, but data-&gt;list will not be removed from driver_data.bmc_data,&#xA;then list traversal may cause UAF.&#xA;Fix by removeing it from driver_data.bmc_data before free().&#xA;CVE-2022-48991:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths&#xA;Any codepath that zaps page table entries must invoke MMU notifiers to&#xA;ensure that secondary MMUs (like KVM) don&#39;t keep accessing pages which&#xA;aren&#39;t mapped anymore.  Secondary MMUs don&#39;t hold their own references to&#xA;pages that are mirrored over, so failing to notify them can lead to page&#xA;use-after-free.&#xA;I&#39;m marking this as addressing an issue introduced in commit f3f0e1d2150b&#xA;(&#34;khugepaged: add support of collapse for tmpfs/shmem pages&#34;), but most of&#xA;the security impact of this only came in commit 27e1f8273113 (&#34;khugepaged:&#xA;enable collapse pmd for pte-mapped THP&#34;), which actually omitted flushes&#xA;for the removal of present PTEs, not just for the removal of empty page&#xA;tables.&#xA;CVE-2022-48946:In the Linux kernel, the following vulnerability has been resolved:&#xA;udf: Fix preallocation discarding at indirect extent boundary&#xA;When preallocation extent is the first one in the extent block, the&#xA;code would corrupt extent tree header instead. Fix the problem and use&#xA;udf_delete_aext() for deleting extent to avoid some code duplication.&#xA;CVE-2022-48986:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm/gup: fix gup_pud_range() for dax&#xA;For dax pud, pud_huge() returns true on x86. So the function works as long&#xA;as hugetlb is configured. However, dax doesn&#39;t depend on hugetlb.&#xA;Commit 414fd080d125 (&#34;mm/gup: fix gup_pmd_range() for dax&#34;) fixed&#xA;devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as&#xA;well.&#xA;This fixes the below kernel panic:&#xA;general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP&#xA;&#x9;&lt; snip &gt;&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;get_user_pages_fast+0x1f/0x40&#xA;iov_iter_get_pages+0xc6/0x3b0&#xA;? mempool_alloc+0x5d/0x170&#xA;bio_iov_iter_get_pages+0x82/0x4e0&#xA;? bvec_alloc+0x91/0xc0&#xA;? bio_alloc_bioset+0x19a/0x2a0&#xA;blkdev_direct_IO+0x282/0x480&#xA;? __io_complete_rw_common+0xc0/0xc0&#xA;? filemap_range_has_page+0x82/0xc0&#xA;generic_file_direct_write+0x9d/0x1a0&#xA;? inode_update_time+0x24/0x30&#xA;__generic_file_write_iter+0xbd/0x1e0&#xA;blkdev_write_iter+0xb4/0x150&#xA;? io_import_iovec+0x8d/0x340&#xA;io_write+0xf9/0x300&#xA;io_issue_sqe+0x3c3/0x1d30&#xA;? sysvec_reschedule_ipi+0x6c/0x80&#xA;__io_queue_sqe+0x33/0x240&#xA;? fget+0x76/0xa0&#xA;io_submit_sqes+0xe6a/0x18d0&#xA;? __fget_light+0xd1/0x100&#xA;__x64_sys_io_uring_enter+0x199/0x880&#xA;? __context_tracking_enter+0x1f/0x70&#xA;? irqentry_exit_to_user_mode+0x24/0x30&#xA;? irqentry_exit+0x1d/0x30&#xA;? __context_tracking_exit+0xe/0x70&#xA;do_syscall_64+0x3b/0x90&#xA;entry_SYSCALL_64_after_hwframe+0x61/0xcb&#xA;RIP: 0033:0x7fc97c11a7be&#xA;&#x9;&lt; snip &gt;&#xA;&lt;/TASK&gt;&#xA;---[ end trace 48b2e0e67debcaeb ]---&#xA;RIP: 0010:internal_get_user_pages_fast+0x340/0x990&#xA;&#x9;&lt; snip &gt;&#xA;Kernel panic - not syncing: Fatal exception&#xA;Kernel Offset: disabled&#xA;CVE-2022-48967:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFC: nci: Bounds check struct nfc_target arrays&#xA;While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:&#xA;  memcpy: detected field-spanning write (size 129) of single field &#34;target-&gt;sensf_res&#34; at net/nfc/nci/ntf.c:260 (size 18)&#xA;This appears to be a legitimate lack of bounds checking in&#xA;nci_add_new_protocol(). Add the missing checks.&#xA;CVE-2022-49030:In the Linux kernel, the following vulnerability has been resolved:&#xA;libbpf: Handle size overflow for ringbuf mmap&#xA;The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries&#xA;will overflow u32 when mapping producer page and data pages. Only&#xA;casting max_entries to size_t is not enough, because for 32-bits&#xA;application on 64-bits kernel the size of read-only mmap region&#xA;also could overflow size_t.&#xA;So fixing it by casting the size of read-only mmap region into a __u64&#xA;and checking whether or not there will be overflow during mmap.&#xA;CVE-2022-48973:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpio: amd8111: Fix PCI device reference count leak&#xA;for_each_pci_dev() is implemented by pci_get_device(). The comment of&#xA;pci_get_device() says that it will increase the reference count for the&#xA;returned pci_dev and also decrease the reference count for the input&#xA;pci_dev @from if it is not NULL.&#xA;If we break for_each_pci_dev() loop with pdev not NULL, we need to call&#xA;pci_dev_put() to decrease the reference count. Add the missing&#xA;pci_dev_put() after the &#39;out&#39; label. Since pci_dev_put() can handle NULL&#xA;input parameter, there is no problem for the &#39;Device not found&#39; branch.&#xA;For the normal path, add pci_dev_put() in amd_gpio_exit().&#xA;CVE-2022-49007:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()&#xA;Syzbot reported a null-ptr-deref bug:&#xA; NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP&#xA; frequency &lt; 30 seconds&#xA; general protection fault, probably for non-canonical address&#xA; 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN&#xA; KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]&#xA; CPU: 1 PID: 3603 Comm: segctord Not tainted&#xA; 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0&#xA; Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google&#xA; 10/11/2022&#xA; RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0&#xA; fs/nilfs2/alloc.c:608&#xA; Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00&#xA; 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02&#xA; 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7&#xA; RSP: 0018:ffffc90003dff830 EFLAGS: 00010212&#xA; RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d&#xA; RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010&#xA; RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f&#xA; R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158&#xA; R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004&#xA; FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)&#xA; knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]&#xA;  nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193&#xA;  nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236&#xA;  nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940&#xA;  nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]&#xA;  nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]&#xA;  nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088&#xA;  nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337&#xA;  nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568&#xA;  nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018&#xA;  nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067&#xA;  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]&#xA;  nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]&#xA;  nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045&#xA;  nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379&#xA;  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]&#xA;  nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570&#xA;  kthread+0x2e4/0x3a0 kernel/kthread.c:376&#xA;  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306&#xA;  &lt;/TASK&gt;&#xA; ...&#xA;If DAT metadata file is corrupted on disk, there is a case where&#xA;req-&gt;pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during&#xA;a b-tree operation that cascadingly updates ancestor nodes of the b-tree,&#xA;because nilfs_dat_commit_alloc() for a lower level block can initialize&#xA;the blocknr on the same DAT entry between nilfs_dat_prepare_end() and&#xA;nilfs_dat_commit_end().&#xA;If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free()&#xA;without valid buffer heads in req-&gt;pr_desc_bh and req-&gt;pr_bitmap_bh, and&#xA;causes the NULL pointer dereference above in&#xA;nilfs_palloc_commit_free_entry() function, which leads to a crash.&#xA;Fix this by adding a NULL check on req-&gt;pr_desc_bh and req-&gt;pr_bitmap_bh&#xA;before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().&#xA;This also calls nilfs_error() in that case to notify that there is a fatal&#xA;flaw in the filesystem metadata and prevent further operations.&#xA;CVE-2022-48952:In the Linux kernel, the following vulnerability has been resolved:&#xA;PCI: mt7621: Add sentinel to quirks table&#xA;Current driver is missing a sentinel in the struct soc_device_attribute&#xA;array, which causes an oops when assessed by the&#xA;soc_device_match(mt7621_pcie_quirks_match) call.&#xA;This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr&#xA;was fixed to register the SOC as a device, in:&#xA;commit 7c18b64bba3b (&#34;mips: ralink: mt7621: do not use kzalloc too early&#34;)&#xA;Fix it by adding the required sentinel.&#xA;CVE-2024-50025:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: fnic: Move flush_work initialization out of if block&#xA;After commit 379a58caa199 (&#34;scsi: fnic: Move fnic_fnic_flush_tx() to a&#xA;work queue&#34;), it can happen that a work item is sent to an uninitialized&#xA;work queue.  This may has the effect that the item being queued is never&#xA;actually queued, and any further actions depending on it will not&#xA;proceed.&#xA;The following warning is observed while the fnic driver is loaded:&#xA;kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410&#xA;kernel:  &lt;IRQ&gt;&#xA;kernel:  queue_work_on+0x3a/0x50&#xA;kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]&#xA;kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]&#xA;kernel:  __handle_irq_event_percpu+0x36/0x1a0&#xA;kernel:  handle_irq_event_percpu+0x30/0x70&#xA;kernel:  handle_irq_event+0x34/0x60&#xA;kernel:  handle_edge_irq+0x7e/0x1a0&#xA;kernel:  __common_interrupt+0x3b/0xb0&#xA;kernel:  common_interrupt+0x58/0xa0&#xA;kernel:  &lt;/IRQ&gt;&#xA;It has been observed that this may break the rediscovery of Fibre&#xA;Channel devices after a temporary fabric failure.&#xA;This patch fixes it by moving the work queue initialization out of&#xA;an if block in fnic_probe().&#xA;CVE-2024-50036:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: do not delay dst_entries_add() in dst_release()&#xA;dst_entries_add() uses per-cpu data that might be freed at netns&#xA;dismantle from ip6_route_net_exit() calling dst_entries_destroy()&#xA;Before ip6_route_net_exit() can be called, we release all&#xA;the dsts associated with this netns, via calls to dst_release(),&#xA;which waits an rcu grace period before calling dst_destroy()&#xA;dst_entries_add() use in dst_destroy() is racy, because&#xA;dst_entries_destroy() could have been called already.&#xA;Decrementing the number of dsts must happen sooner.&#xA;Notes:&#xA;1) in CONFIG_XFRM case, dst_destroy() can call&#xA;   dst_release_immediate(child), this might also cause UAF&#xA;   if the child does not have DST_NOCOUNT set.&#xA;   IPSEC maintainers might take a look and see how to address this.&#xA;2) There is also discussion about removing this count of dst,&#xA;   which might happen in future kernels.&#xA;CVE-2022-49033:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()&#xA;Syzkaller reported BUG as follows:&#xA;  BUG: sleeping function called from invalid context at&#xA;       include/linux/sched/mm.h:274&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0xcd/0x134&#xA;   __might_resched.cold+0x222/0x26b&#xA;   kmem_cache_alloc+0x2e7/0x3c0&#xA;   update_qgroup_limit_item+0xe1/0x390&#xA;   btrfs_qgroup_inherit+0x147b/0x1ee0&#xA;   create_subvol+0x4eb/0x1710&#xA;   btrfs_mksubvol+0xfe5/0x13f0&#xA;   __btrfs_ioctl_snap_create+0x2b0/0x430&#xA;   btrfs_ioctl_snap_create_v2+0x25a/0x520&#xA;   btrfs_ioctl+0x2a1c/0x5ce0&#xA;   __x64_sys_ioctl+0x193/0x200&#xA;   do_syscall_64+0x35/0x80&#xA;Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in&#xA;btrfs_run_qgroups() later outside of the spinlock context.&#xA;CVE-2023-52918:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: pci: cx23885: check cx23885_vdev_init() return&#xA;cx23885_vdev_init() can return a NULL pointer, but that pointer&#xA;is used in the next line without a check.&#xA;Add a NULL pointer check and go to the error unwind if it is NULL.&#xA;CVE-2022-49006:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing: Free buffers when a used dynamic event is removed&#xA;After 65536 dynamic events have been added and removed, the &#34;type&#34; field&#xA;of the event then uses the first type number that is available (not&#xA;currently used by other events). A type number is the identifier of the&#xA;binary blobs in the tracing ring buffer (known as events) to map them to&#xA;logic that can parse the binary blob.&#xA;The issue is that if a dynamic event (like a kprobe event) is traced and&#xA;is in the ring buffer, and then that event is removed (because it is&#xA;dynamic, which means it can be created and destroyed), if another dynamic&#xA;event is created that has the same number that new event&#39;s logic on&#xA;parsing the binary blob will be used.&#xA;To show how this can be an issue, the following can crash the kernel:&#xA; # cd /sys/kernel/tracing&#xA; # for i in `seq 65536`; do&#xA;     echo &#39;p:kprobes/foo do_sys_openat2 $arg1:u32&#39; &gt; kprobe_events&#xA; # done&#xA;For every iteration of the above, the writing to the kprobe_events will&#xA;remove the old event and create a new one (with the same format) and&#xA;increase the type number to the next available on until the type number&#xA;reaches over 65535 which is the max number for the 16 bit type. After it&#xA;reaches that number, the logic to allocate a new number simply looks for&#xA;the next available number. When an dynamic event is removed, that number&#xA;is then available to be reused by the next dynamic event created. That is,&#xA;once the above reaches the max number, the number assigned to the event in&#xA;that loop will remain the same.&#xA;Now that means deleting one dynamic event and created another will reuse&#xA;the previous events type number. This is where bad things can happen.&#xA;After the above loop finishes, the kprobes/foo event which reads the&#xA;do_sys_openat2 function call&#39;s first parameter as an integer.&#xA; # echo 1 &gt; kprobes/foo/enable&#xA; # cat /etc/passwd &gt; /dev/null&#xA; # cat trace&#xA;             cat-2211    [005] ....  2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196&#xA;             cat-2211    [005] ....  2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196&#xA;             cat-2211    [005] ....  2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196&#xA;             cat-2211    [005] ....  2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196&#xA; # echo 0 &gt; kprobes/foo/enable&#xA;Now if we delete the kprobe and create a new one that reads a string:&#xA; # echo &#39;p:kprobes/foo do_sys_openat2 +0($arg2):string&#39; &gt; kprobe_events&#xA;And now we can the trace:&#xA; # cat trace&#xA;        sendmail-1942    [002] .....   530.136320: foo: (do_sys_openat2+0x0/0x240) arg1=             cat-2046    [004] .....   530.930817: foo: (do_sys_openat2+0x0/0x240) arg1=&#34;������������������������������������������������������������������������������������������������&#34;&#xA;             cat-2046    [004] .....   530.930961: foo: (do_sys_openat2+0x0/0x240) arg1=&#34;������������������������������������������������������������������������������������������������&#34;&#xA;             cat-2046    [004] .....   530.934278: foo: (do_sys_openat2+0x0/0x240) arg1=&#34;������������������������������������������������������������������������������������������������&#34;&#xA;             cat-2046    [004] .....   530.934563: foo: (do_sys_openat2+0x0/0x240) arg1=&#34;���������������������������������������&#xA;---truncated---&#xA;CVE-2024-50074:In the Linux kernel, the following vulnerability has been resolved:&#xA;parport: Proper fix for array out-of-bounds access&#xA;The recent fix for array out-of-bounds accesses replaced sprintf()&#xA;calls blindly with snprintf().  However, since snprintf() returns the&#xA;would-be-printed size, not the actually output size, the length&#xA;calculation can still go over the given limit.&#xA;Use scnprintf() instead of snprintf(), which returns the actually&#xA;output letters, for addressing the potential out-of-bounds access&#xA;properly.&#xA;CVE-2024-45021:In the Linux kernel, the following vulnerability has been resolved:&#xA;memcg_write_event_control(): fix a user-triggerable oops&#xA;we are *not* guaranteed that anything past the terminating NUL&#xA;is mapped (let alone initialized with anything sane).&#xA;CVE-2024-46677:In the Linux kernel, the following vulnerability has been resolved:&#xA;gtp: fix a potential NULL pointer dereference&#xA;When sockfd_lookup() fails, gtp_encap_enable_socket() returns a&#xA;NULL pointer, but its callers only check for error pointers thus miss&#xA;the NULL pointer case.&#xA;Fix it by returning an error pointer with the error code carried from&#xA;sockfd_lookup().&#xA;(I found this bug during code inspection.)&#xA;CVE-2024-46809:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check BIOS images before it is used&#xA;BIOS images may fail to load and null checks are added before they are&#xA;used.&#xA;This fixes 6 NULL_RETURNS issues reported by Coverity.&#xA;CVE-2024-47660:In the Linux kernel, the following vulnerability has been resolved:&#xA;fsnotify: clear PARENT_WATCHED flags lazily&#xA;In some setups directories can have many (usually negative) dentries.&#xA;Hence __fsnotify_update_child_dentry_flags() function can take a&#xA;significant amount of time. Since the bulk of this function happens&#xA;under inode-&gt;i_lock this causes a significant contention on the lock&#xA;when we remove the watch from the directory as the&#xA;__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()&#xA;races with __fsnotify_update_child_dentry_flags() calls from&#xA;__fsnotify_parent() happening on children. This can lead upto softlockup&#xA;reports reported by users.&#xA;Fix the problem by calling fsnotify_update_children_dentry_flags() to&#xA;set PARENT_WATCHED flags only when parent starts watching children.&#xA;When parent stops watching children, clear false positive PARENT_WATCHED&#xA;flags lazily in __fsnotify_parent() for each accessed child.&#xA;CVE-2024-47659:In the Linux kernel, the following vulnerability has been resolved:&#xA;smack: tcp: ipv4, fix incorrect labeling&#xA;Currently, Smack mirrors the label of incoming tcp/ipv4 connections:&#xA;when a label &#39;foo&#39; connects to a label &#39;bar&#39; with tcp/ipv4,&#xA;&#39;foo&#39; always gets &#39;foo&#39; in returned ipv4 packets. So,&#xA;1) returned packets are incorrectly labeled (&#39;foo&#39; instead of &#39;bar&#39;)&#xA;2) &#39;bar&#39; can write to &#39;foo&#39; without being authorized to write.&#xA;Here is a scenario how to see this:&#xA;* Take two machines, let&#39;s call them C and S,&#xA;   with active Smack in the default state&#xA;   (no settings, no rules, no labeled hosts, only builtin labels)&#xA;* At S, add Smack rule &#39;foo bar w&#39;&#xA;   (labels &#39;foo&#39; and &#39;bar&#39; are instantiated at S at this moment)&#xA;* At S, at label &#39;bar&#39;, launch a program&#xA;   that listens for incoming tcp/ipv4 connections&#xA;* From C, at label &#39;foo&#39;, connect to the listener at S.&#xA;   (label &#39;foo&#39; is instantiated at C at this moment)&#xA;   Connection succeedes and works.&#xA;* Send some data in both directions.&#xA;* Collect network traffic of this connection.&#xA;All packets in both directions are labeled with the CIPSO&#xA;of the label &#39;foo&#39;. Hence, label &#39;bar&#39; writes to &#39;foo&#39; without&#xA;being authorized, and even without ever being known at C.&#xA;If anybody cares: exactly the same happens with DCCP.&#xA;This behavior 1st manifested in release 2.6.29.4 (see Fixes below)&#xA;and it looks unintentional. At least, no explanation was provided.&#xA;I changed returned packes label into the &#39;bar&#39;,&#xA;to bring it into line with the Smack documentation claims.&#xA;CVE-2024-47668:In the Linux kernel, the following vulnerability has been resolved:&#xA;lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()&#xA;If we need to increase the tree depth, allocate a new node, and then&#xA;race with another thread that increased the tree depth before us, we&#39;ll&#xA;still have a preallocated node that might be used later.&#xA;If we then use that node for a new non-root node, it&#39;ll still have a&#xA;pointer to the old root instead of being zeroed - fix this by zeroing it&#xA;in the cmpxchg failure path.&#xA;CVE-2024-47673:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: pause TCM when the firmware is stopped&#xA;Not doing so will make us send a host command to the transport while the&#xA;firmware is not alive, which will trigger a WARNING.&#xA;bad state = 0&#xA;WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]&#xA;RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]&#xA; iwl_mvm_config_scan+0x198/0x260 [iwlmvm]&#xA; iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]&#xA; iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]&#xA; process_one_work+0x29e/0x640&#xA; worker_thread+0x2df/0x690&#xA; ? rescuer_thread+0x540/0x540&#xA; kthread+0x192/0x1e0&#xA; ? set_kthread_struct+0x90/0x90&#xA; ret_from_fork+0x22/0x30&#xA;CVE-2024-47692:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfsd: return -EINVAL when namelen is 0&#xA;When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may&#xA;result in namelen being 0, which will cause memdup_user() to return&#xA;ZERO_SIZE_PTR.&#xA;When we access the name.data that has been assigned the value of&#xA;ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is&#xA;triggered.&#xA;[ T1205] ==================================================================&#xA;[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260&#xA;[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205&#xA;[ T1205]&#xA;[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406&#xA;[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014&#xA;[ T1205] Call Trace:&#xA;[ T1205]  dump_stack+0x9a/0xd0&#xA;[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260&#xA;[ T1205]  __kasan_report.cold+0x34/0x84&#xA;[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260&#xA;[ T1205]  kasan_report+0x3a/0x50&#xA;[ T1205]  nfs4_client_to_reclaim+0xe9/0x260&#xA;[ T1205]  ? nfsd4_release_lockowner+0x410/0x410&#xA;[ T1205]  cld_pipe_downcall+0x5ca/0x760&#xA;[ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0&#xA;[ T1205]  ? down_write_killable_nested+0x170/0x170&#xA;[ T1205]  ? avc_policy_seqno+0x28/0x40&#xA;[ T1205]  ? selinux_file_permission+0x1b4/0x1e0&#xA;[ T1205]  rpc_pipe_write+0x84/0xb0&#xA;[ T1205]  vfs_write+0x143/0x520&#xA;[ T1205]  ksys_write+0xc9/0x170&#xA;[ T1205]  ? __ia32_sys_read+0x50/0x50&#xA;[ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110&#xA;[ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110&#xA;[ T1205]  do_syscall_64+0x33/0x40&#xA;[ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;[ T1205] RIP: 0033:0x7fdbdb761bc7&#xA;[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 514&#xA;[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7&#xA;[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008&#xA;[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001&#xA;[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b&#xA;[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000&#xA;[ T1205] ==================================================================&#xA;Fix it by checking namelen.&#xA;CVE-2024-47703:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf, lsm: Add check for BPF LSM return value&#xA;A bpf prog returning a positive number attached to file_alloc_security&#xA;hook makes kernel panic.&#xA;This happens because file system can not filter out the positive number&#xA;returned by the LSM prog using IS_ERR, and misinterprets this positive&#xA;number as a file pointer.&#xA;Given that hook file_alloc_security never returned positive number&#xA;before the introduction of BPF LSM, and other BPF LSM hooks may&#xA;encounter similar issues, this patch adds LSM return value check&#xA;in verifier, to ensure no unexpected value is returned.&#xA;CVE-2024-47705:In the Linux kernel, the following vulnerability has been resolved:&#xA;block: fix potential invalid pointer dereference in blk_add_partition&#xA;The blk_add_partition() function initially used a single if-condition&#xA;(IS_ERR(part)) to check for errors when adding a partition. This was&#xA;modified to handle the specific case of -ENXIO separately, allowing the&#xA;function to proceed without logging the error in this case. However,&#xA;this change unintentionally left a path where md_autodetect_dev()&#xA;could be called without confirming that part is a valid pointer.&#xA;This commit separates the error handling logic by splitting the&#xA;initial if-condition, improving code readability and handling specific&#xA;error scenarios explicitly. The function now distinguishes the general&#xA;error case from -ENXIO without altering the existing behavior of&#xA;md_autodetect_dev() calls.&#xA;CVE-2024-47691:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()&#xA;syzbot reports a f2fs bug as below:&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114&#xA; print_report+0xe8/0x550 mm/kasan/report.c:491&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA; kasan_check_range+0x282/0x290 mm/kasan/generic.c:189&#xA; instrument_atomic_read_write include/linux/instrumented.h:96 [inline]&#xA; atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]&#xA; __refcount_add include/linux/refcount.h:184 [inline]&#xA; __refcount_inc include/linux/refcount.h:241 [inline]&#xA; refcount_inc include/linux/refcount.h:258 [inline]&#xA; get_task_struct include/linux/sched/task.h:118 [inline]&#xA; kthread_stop+0xca/0x630 kernel/kthread.c:704&#xA; f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210&#xA; f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283&#xA; f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]&#xA; __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA; __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;The root cause is below race condition, it may cause use-after-free&#xA;issue in sbi-&gt;gc_th pointer.&#xA;- remount&#xA; - f2fs_remount&#xA;  - f2fs_stop_gc_thread&#xA;   - kfree(gc_th)&#xA;&#x9;&#x9;&#x9;&#x9;- f2fs_ioc_shutdown&#xA;&#x9;&#x9;&#x9;&#x9; - f2fs_do_shutdown&#xA;&#x9;&#x9;&#x9;&#x9;  - f2fs_stop_gc_thread&#xA;&#x9;&#x9;&#x9;&#x9;   - kthread_stop(gc_th-&gt;f2fs_gc_task)&#xA;   : sbi-&gt;gc_thread = NULL;&#xA;We will call f2fs_do_shutdown() in two paths:&#xA;- for f2fs_ioc_shutdown() path, we should grab sb-&gt;s_umount semaphore&#xA;for fixing.&#xA;- for f2fs_shutdown() path, it&#39;s safe since caller has already grabbed&#xA;sb-&gt;s_umount semaphore.&#xA;CVE-2024-47696:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency&#xA;In the commit aee2424246f9 (&#34;RDMA/iwcm: Fix a use-after-free related to&#xA;destroying CM IDs&#34;), the function flush_workqueue is invoked to flush the&#xA;work queue iwcm_wq.&#xA;But at that time, the work queue iwcm_wq was created via the function&#xA;alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.&#xA;Because the current process is trying to flush the whole iwcm_wq, if&#xA;iwcm_wq doesn&#39;t have the flag WQ_MEM_RECLAIM, verify that the current&#xA;process is not reclaiming memory or running on a workqueue which doesn&#39;t&#xA;have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee&#xA;leading to a deadlock.&#xA;The call trace is as below:&#xA;[  125.350876][ T1430] Call Trace:&#xA;[  125.356281][ T1430]  &lt;TASK&gt;&#xA;[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)&#xA;[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))&#xA;[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)&#xA;[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)&#xA;[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))&#xA;[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)&#xA;[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))&#xA;[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))&#xA;[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)&#xA;[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)&#xA;[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm&#xA;[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)&#xA;[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)&#xA;[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)&#xA;[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm&#xA;[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma&#xA;[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma&#xA;[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)&#xA;[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)&#xA;[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)&#xA;[ 125.531837][ T1430] kthread (kernel/kthread.c:389)&#xA;[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)&#xA;[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)&#xA;[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)&#xA;[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)&#xA;[  125.566487][ T1430]  &lt;/TASK&gt;&#xA;[  125.566488][ T1430] ---[ end trace 0000000000000000 ]---&#xA;CVE-2024-47701:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: avoid OOB when system.data xattr changes underneath the filesystem&#xA;When looking up for an entry in an inlined directory, if e_value_offs is&#xA;changed underneath the filesystem by some change in the block device, it&#xA;will lead to an out-of-bounds access that KASAN detects as an UAF.&#xA;EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.&#xA;loop0: detected capacity change from 2048 to 2047&#xA;==================================================================&#xA;BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500&#xA;Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103&#xA;CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:93 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0x169/0x550 mm/kasan/report.c:488&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA; ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500&#xA; ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697&#xA; __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573&#xA; ext4_lookup_entry fs/ext4/namei.c:1727 [inline]&#xA; ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795&#xA; lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633&#xA; filename_create+0x297/0x540 fs/namei.c:3980&#xA; do_symlinkat+0xf9/0x3a0 fs/namei.c:4587&#xA; __do_sys_symlinkat fs/namei.c:4610 [inline]&#xA; __se_sys_symlinkat fs/namei.c:4607 [inline]&#xA; __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f3e73ced469&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a&#xA;RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469&#xA;RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0&#xA;RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290&#xA;R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c&#xA;R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0&#xA; &lt;/TASK&gt;&#xA;Calling ext4_xattr_ibody_find right after reading the inode with&#xA;ext4_get_inode_loc will lead to a check of the validity of the xattrs,&#xA;avoiding this problem.&#xA;CVE-2024-47690:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: get rid of online repaire on corrupted directory&#xA;syzbot reports a f2fs bug as below:&#xA;kernel BUG at fs/f2fs/inode.c:896!&#xA;RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896&#xA;Call Trace:&#xA; evict+0x532/0x950 fs/inode.c:704&#xA; dispose_list fs/inode.c:747 [inline]&#xA; evict_inodes+0x5f9/0x690 fs/inode.c:797&#xA; generic_shutdown_super+0x9d/0x2d0 fs/super.c:627&#xA; kill_block_super+0x44/0x90 fs/super.c:1696&#xA; kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898&#xA; deactivate_locked_super+0xc4/0x130 fs/super.c:473&#xA; cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373&#xA; task_work_run+0x24f/0x310 kernel/task_work.c:228&#xA; ptrace_notify+0x2d2/0x380 kernel/signal.c:2402&#xA; ptrace_report_syscall include/linux/ptrace.h:415 [inline]&#xA; ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]&#xA; syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173&#xA; syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]&#xA; __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]&#xA; syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218&#xA; do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896&#xA;Online repaire on corrupted directory in f2fs_lookup() can generate&#xA;dirty data/meta while racing w/ readonly remount, it may leave dirty&#xA;inode after filesystem becomes readonly, however, checkpoint() will&#xA;skips flushing dirty inode in a state of readonly mode, result in&#xA;above panic.&#xA;Let&#39;s get rid of online repaire in f2fs_lookup(), and leave the work&#xA;to fsck.f2fs.&#xA;CVE-2024-47699:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()&#xA;Patch series &#34;nilfs2: fix potential issues with empty b-tree nodes&#34;.&#xA;This series addresses three potential issues with empty b-tree nodes that&#xA;can occur with corrupted filesystem images, including one recently&#xA;discovered by syzbot.&#xA;This patch (of 3):&#xA;If a b-tree is broken on the device, and the b-tree height is greater than&#xA;2 (the level of the root node is greater than 1) even if the number of&#xA;child nodes of the b-tree root is 0, a NULL pointer dereference occurs in&#xA;nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().&#xA;This is because, when the number of child nodes of the b-tree root is 0,&#xA;nilfs_btree_do_lookup() does not set the block buffer head in any of&#xA;path[x].bp_bh, leaving it as the initial value of NULL, but if the level&#xA;of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),&#xA;which accesses the buffer memory of path[x].bp_bh, is called.&#xA;Fix this issue by adding a check to nilfs_btree_root_broken(), which&#xA;performs sanity checks when reading the root node from the device, to&#xA;detect this inconsistency.&#xA;Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause&#xA;early on.&#xA;CVE-2024-47693:In the Linux kernel, the following vulnerability has been resolved:&#xA;IB/core: Fix ib_cache_setup_one error flow cleanup&#xA;When ib_cache_update return an error, we exit ib_cache_setup_one&#xA;instantly with no proper cleanup, even though before this we had&#xA;already successfully done gid_table_setup_one, that results in&#xA;the kernel WARN below.&#xA;Do proper cleanup using gid_table_cleanup_one before returning&#xA;the err in order to fix the issue.&#xA;WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0&#xA;Modules linked in:&#xA;CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:gid_table_release_one+0x181/0x1a0&#xA;Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff &lt;0f&gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41&#xA;RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527&#xA;RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001&#xA;RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631&#xA;R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001&#xA;R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001&#xA;FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_regs+0x94/0xa0&#xA; ? __warn+0x9e/0x1c0&#xA; ? gid_table_release_one+0x181/0x1a0&#xA; ? report_bug+0x1f9/0x340&#xA; ? gid_table_release_one+0x181/0x1a0&#xA; ? handle_bug+0xa2/0x110&#xA; ? exc_invalid_op+0x31/0xa0&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? __warn_printk+0xc7/0x180&#xA; ? __warn_printk+0xd4/0x180&#xA; ? gid_table_release_one+0x181/0x1a0&#xA; ib_device_release+0x71/0xe0&#xA; ? __pfx_ib_device_release+0x10/0x10&#xA; device_release+0x44/0xd0&#xA; kobject_put+0x135/0x3d0&#xA; put_device+0x20/0x30&#xA; rxe_net_add+0x7d/0xa0&#xA; rxe_newlink+0xd7/0x190&#xA; nldev_newlink+0x1b0/0x2a0&#xA; ? __pfx_nldev_newlink+0x10/0x10&#xA; rdma_nl_rcv_msg+0x1ad/0x2e0&#xA; rdma_nl_rcv_skb.constprop.0+0x176/0x210&#xA; netlink_unicast+0x2de/0x400&#xA; netlink_sendmsg+0x306/0x660&#xA; __sock_sendmsg+0x110/0x120&#xA; ____sys_sendmsg+0x30e/0x390&#xA; ___sys_sendmsg+0x9b/0xf0&#xA; ? kstrtouint+0x6e/0xa0&#xA; ? kstrtouint_from_user+0x7c/0xb0&#xA; ? get_pid_task+0xb0/0xd0&#xA; ? proc_fail_nth_write+0x5b/0x140&#xA; ? __fget_light+0x9a/0x200&#xA; ? preempt_count_add+0x47/0xa0&#xA; __sys_sendmsg+0x61/0xd0&#xA; do_syscall_64+0x50/0x110&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2024-49860:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPI: sysfs: validate return type of _STR method&#xA;Only buffer objects are valid return values of _STR.&#xA;If something else is returned description_show() will access invalid&#xA;memory.&#xA;CVE-2024-49855:In the Linux kernel, the following vulnerability has been resolved:&#xA;nbd: fix race between timeout and normal completion&#xA;If request timetout is handled by nbd_requeue_cmd(), normal completion&#xA;has to be stopped for avoiding to complete this requeued request, other&#xA;use-after-free can be triggered.&#xA;Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime&#xA;make sure that cmd-&gt;lock is grabbed for clearing the flag and the&#xA;requeue.&#xA;CVE-2024-47742:In the Linux kernel, the following vulnerability has been resolved:&#xA;firmware_loader: Block path traversal&#xA;Most firmware names are hardcoded strings, or are constructed from fairly&#xA;constrained format strings where the dynamic parts are just some hex&#xA;numbers or such.&#xA;However, there are a couple codepaths in the kernel where firmware file&#xA;names contain string components that are passed through from a device or&#xA;semi-privileged userspace; the ones I could find (not counting interfaces&#xA;that require root privileges) are:&#xA; - lpfc_sli4_request_firmware_update() seems to construct the firmware&#xA;   filename from &#34;ModelName&#34;, a string that was previously parsed out of&#xA;   some descriptor (&#34;Vital Product Data&#34;) in lpfc_fill_vpd()&#xA; - nfp_net_fw_find() seems to construct a firmware filename from a model&#xA;   name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, &#34;nffw.partno&#34;), which I&#xA;   think parses some descriptor that was read from the device.&#xA;   (But this case likely isn&#39;t exploitable because the format string looks&#xA;   like &#34;netronome/nic_%s&#34;, and there shouldn&#39;t be any *folders* starting&#xA;   with &#34;netronome/nic_&#34;. The previous case was different because there,&#xA;   the &#34;%s&#34; is *at the start* of the format string.)&#xA; - module_flash_fw_schedule() is reachable from the&#xA;   ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as&#xA;   GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is&#xA;   enough to pass the privilege check), and takes a userspace-provided&#xA;   firmware name.&#xA;   (But I think to reach this case, you need to have CAP_NET_ADMIN over a&#xA;   network namespace that a special kind of ethernet device is mapped into,&#xA;   so I think this is not a viable attack path in practice.)&#xA;Fix it by rejecting any firmware names containing &#34;..&#34; path components.&#xA;For what it&#39;s worth, I went looking and haven&#39;t found any USB device&#xA;drivers that use the firmware loader dangerously.&#xA;CVE-2024-47723:In the Linux kernel, the following vulnerability has been resolved:&#xA;jfs: fix out-of-bounds in dbNextAG() and diAlloc()&#xA;In dbNextAG() , there is no check for the case where bmp-&gt;db_numag is&#xA;greater or same than MAXAG due to a polluted image, which causes an&#xA;out-of-bounds. Therefore, a bounds check should be added in dbMount().&#xA;And in dbNextAG(), a check for the case where agpref is greater than&#xA;bmp-&gt;db_numag should be added, so an out-of-bounds exception should be&#xA;prevented.&#xA;Additionally, a check for the case where agno is greater or same than&#xA;MAXAG should be added in diAlloc() to prevent out-of-bounds.&#xA;CVE-2024-47748:In the Linux kernel, the following vulnerability has been resolved:&#xA;vhost_vdpa: assign irq bypass producer token correctly&#xA;We used to call irq_bypass_unregister_producer() in&#xA;vhost_vdpa_setup_vq_irq() which is problematic as we don&#39;t know if the&#xA;token pointer is still valid or not.&#xA;Actually, we use the eventfd_ctx as the token so the life cycle of the&#xA;token should be bound to the VHOST_SET_VRING_CALL instead of&#xA;vhost_vdpa_setup_vq_irq() which could be called by set_status().&#xA;Fixing this by setting up irq bypass producer&#39;s token when handling&#xA;VHOST_SET_VRING_CALL and un-registering the producer before calling&#xA;vhost_vring_ioctl() to prevent a possible use after free as eventfd&#xA;could have been released in vhost_vring_ioctl(). And such registering&#xA;and unregistering will only be done if DRIVER_OK is set.&#xA;CVE-2024-47739:In the Linux kernel, the following vulnerability has been resolved:&#xA;padata: use integer wrap around to prevent deadlock on seq_nr overflow&#xA;When submitting more than 2^32 padata objects to padata_do_serial, the&#xA;current sorting implementation incorrectly sorts padata objects with&#xA;overflowed seq_nr, causing them to be placed before existing objects in&#xA;the reorder list. This leads to a deadlock in the serialization process&#xA;as padata_find_next cannot match padata-&gt;seq_nr and pd-&gt;processed&#xA;because the padata instance with overflowed seq_nr will be selected&#xA;next.&#xA;To fix this, we use an unsigned integer wrap around to correctly sort&#xA;padata objects in scenarios with integer overflow.&#xA;CVE-2024-49858:In the Linux kernel, the following vulnerability has been resolved:&#xA;efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption&#xA;The TPM event log table is a Linux specific construct, where the data&#xA;produced by the GetEventLog() boot service is cached in memory, and&#xA;passed on to the OS using an EFI configuration table.&#xA;The use of EFI_LOADER_DATA here results in the region being left&#xA;unreserved in the E820 memory map constructed by the EFI stub, and this&#xA;is the memory description that is passed on to the incoming kernel by&#xA;kexec, which is therefore unaware that the region should be reserved.&#xA;Even though the utility of the TPM2 event log after a kexec is&#xA;questionable, any corruption might send the parsing code off into the&#xA;weeds and crash the kernel. So let&#39;s use EFI_ACPI_RECLAIM_MEMORY&#xA;instead, which is always treated as reserved by the E820 conversion&#xA;logic.&#xA;CVE-2024-49863:In the Linux kernel, the following vulnerability has been resolved:&#xA;vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()&#xA;Since commit 3f8ca2e115e5 (&#34;vhost/scsi: Extract common handling code&#xA;from control queue handler&#34;) a null pointer dereference bug can be&#xA;triggered when guest sends an SCSI AN request.&#xA;In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with&#xA;`&amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to&#xA;vhost_scsi_get_req() which extracts `vc-&gt;req` and `tpg`. However, for&#xA;a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is&#xA;set to NULL in this branch. Later, in vhost_scsi_get_req(),&#xA;`vc-&gt;target` is dereferenced without being checked, leading to a null&#xA;pointer dereference bug. This bug can be triggered from guest.&#xA;When this bug occurs, the vhost_worker process is killed while holding&#xA;`vq-&gt;mutex` and the corresponding tpg will remain occupied&#xA;indefinitely.&#xA;Below is the KASAN report:&#xA;Oops: general protection fault, probably for non-canonical address&#xA;0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1&#xA;Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS&#xA;1.16.3-debian-1.16.3-2 04/01/2014&#xA;RIP: 0010:vhost_scsi_get_req+0x165/0x3a0&#xA;Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00&#xA;48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 &lt;0f&gt; b6&#xA;04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00&#xA;RSP: 0018:ffff888017affb50 EFLAGS: 00010246&#xA;RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8&#xA;RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000&#xA;R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000&#xA;FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_regs+0x86/0xa0&#xA; ? die_addr+0x4b/0xd0&#xA; ? exc_general_protection+0x163/0x260&#xA; ? asm_exc_general_protection+0x27/0x30&#xA; ? vhost_scsi_get_req+0x165/0x3a0&#xA; vhost_scsi_ctl_handle_vq+0x2a4/0xca0&#xA; ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10&#xA; ? __switch_to+0x721/0xeb0&#xA; ? __schedule+0xda5/0x5710&#xA; ? __kasan_check_write+0x14/0x30&#xA; ? _raw_spin_lock+0x82/0xf0&#xA; vhost_scsi_ctl_handle_kick+0x52/0x90&#xA; vhost_run_work_list+0x134/0x1b0&#xA; vhost_task_fn+0x121/0x350&#xA;...&#xA; &lt;/TASK&gt;&#xA;---[ end trace 0000000000000000 ]---&#xA;Let&#39;s add a check in vhost_scsi_get_req.&#xA;[whitespace fixes]&#xA;CVE-2024-49882:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix double brelse() the buffer of the extents path&#xA;In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been&#xA;released, otherwise it may be released twice. An example of what triggers&#xA;this is as follows:&#xA;  split2    map    split1&#xA;|--------|-------|--------|&#xA;ext4_ext_map_blocks&#xA; ext4_ext_handle_unwritten_extents&#xA;  ext4_split_convert_extents&#xA;   // path-&gt;p_depth == 0&#xA;   ext4_split_extent&#xA;     // 1. do split1&#xA;     ext4_split_extent_at&#xA;       |ext4_ext_insert_extent&#xA;       |  ext4_ext_create_new_leaf&#xA;       |    ext4_ext_grow_indepth&#xA;       |      le16_add_cpu(&amp;neh-&gt;eh_depth, 1)&#xA;       |    ext4_find_extent&#xA;       |      // return -ENOMEM&#xA;       |// get error and try zeroout&#xA;       |path = ext4_find_extent&#xA;       |  path-&gt;p_depth = 1&#xA;       |ext4_ext_try_to_merge&#xA;       |  ext4_ext_try_to_merge_up&#xA;       |    path-&gt;p_depth = 0&#xA;       |    brelse(path[1].p_bh)  ---&gt; not set to NULL here&#xA;       |// zeroout success&#xA;     // 2. update path&#xA;     ext4_find_extent&#xA;     // 3. do split2&#xA;     ext4_split_extent_at&#xA;       ext4_ext_insert_extent&#xA;         ext4_ext_create_new_leaf&#xA;           ext4_ext_grow_indepth&#xA;             le16_add_cpu(&amp;neh-&gt;eh_depth, 1)&#xA;           ext4_find_extent&#xA;             path[0].p_bh = NULL;&#xA;             path-&gt;p_depth = 1&#xA;             read_extent_tree_block  ---&gt; return err&#xA;             // path[1].p_bh is still the old value&#xA;             ext4_free_ext_path&#xA;               ext4_ext_drop_refs&#xA;                 // path-&gt;p_depth == 1&#xA;                 brelse(path[1].p_bh)  ---&gt; brelse a buffer twice&#xA;Finally got the following WARRNING when removing the buffer from lru:&#xA;============================================&#xA;VFS: brelse: Trying to free free buffer&#xA;WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90&#xA;CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716&#xA;RIP: 0010:__brelse+0x58/0x90&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __find_get_block+0x6e7/0x810&#xA; bdev_getblk+0x2b/0x480&#xA; __ext4_get_inode_loc+0x48a/0x1240&#xA; ext4_get_inode_loc+0xb2/0x150&#xA; ext4_reserve_inode_write+0xb7/0x230&#xA; __ext4_mark_inode_dirty+0x144/0x6a0&#xA; ext4_ext_insert_extent+0x9c8/0x3230&#xA; ext4_ext_map_blocks+0xf45/0x2dc0&#xA; ext4_map_blocks+0x724/0x1700&#xA; ext4_do_writepages+0x12d6/0x2a70&#xA;[...]&#xA;============================================&#xA;CVE-2024-49886:In the Linux kernel, the following vulnerability has been resolved:&#xA;platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug&#xA;Attaching SST PCI device to VM causes &#34;BUG: KASAN: slab-out-of-bounds&#34;.&#xA;kasan report:&#xA;[   19.411889] ==================================================================&#xA;[   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]&#xA;[   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113&#xA;[   19.417368]&#xA;[   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10&#xA;[   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022&#xA;[   19.422687] Call Trace:&#xA;[   19.424091]  &lt;TASK&gt;&#xA;[   19.425448]  dump_stack_lvl+0x5d/0x80&#xA;[   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]&#xA;[   19.428694]  print_report+0x19d/0x52e&#xA;[   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10&#xA;[   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]&#xA;[   19.433539]  kasan_report+0xf0/0x170&#xA;[   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]&#xA;[   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]&#xA;[   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10&#xA;[   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common]&#xA;[   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common]&#xA;[   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360&#xA;[   19.444797]  cpuhp_invoke_callback+0x221/0xec0&#xA;[   19.446337]  cpuhp_thread_fun+0x21b/0x610&#xA;[   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10&#xA;[   19.449354]  smpboot_thread_fn+0x2e7/0x6e0&#xA;[   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10&#xA;[   19.452405]  kthread+0x29c/0x350&#xA;[   19.453817]  ? __pfx_kthread+0x10/0x10&#xA;[   19.455253]  ret_from_fork+0x31/0x70&#xA;[   19.456685]  ? __pfx_kthread+0x10/0x10&#xA;[   19.458114]  ret_from_fork_asm+0x1a/0x30&#xA;[   19.459573]  &lt;/TASK&gt;&#xA;[   19.460853]&#xA;[   19.462055] Allocated by task 1198:&#xA;[   19.463410]  kasan_save_stack+0x30/0x50&#xA;[   19.464788]  kasan_save_track+0x14/0x30&#xA;[   19.466139]  __kasan_kmalloc+0xaa/0xb0&#xA;[   19.467465]  __kmalloc+0x1cd/0x470&#xA;[   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common]&#xA;[   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr]&#xA;[   19.471670]  do_one_initcall+0xa4/0x380&#xA;[   19.472903]  do_init_module+0x238/0x760&#xA;[   19.474105]  load_module+0x5239/0x6f00&#xA;[   19.475285]  init_module_from_file+0xd1/0x130&#xA;[   19.476506]  idempotent_init_module+0x23b/0x650&#xA;[   19.477725]  __x64_sys_finit_module+0xbe/0x130&#xA;[   19.476506]  idempotent_init_module+0x23b/0x650&#xA;[   19.477725]  __x64_sys_finit_module+0xbe/0x130&#xA;[   19.478920]  do_syscall_64+0x82/0x160&#xA;[   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[   19.481292]&#xA;[   19.482205] The buggy address belongs to the object at ffff888829e65000&#xA; which belongs to the cache kmalloc-512 of size 512&#xA;[   19.484818] The buggy address is located 0 bytes to the right of&#xA; allocated 512-byte region [ffff888829e65000, ffff888829e65200)&#xA;[   19.487447]&#xA;[   19.488328] The buggy address belongs to the physical page:&#xA;[   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60&#xA;[   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0&#xA;[   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)&#xA;[   19.493914] page_type: 0xffffffff()&#xA;[   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001&#xA;[   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000&#xA;[   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001&#xA;[   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000&#xA;[   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff&#xA;[   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000&#xA;[   19.503784] page dumped because: k&#xA;---truncated---&#xA;CVE-2024-49879:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm: omapdrm: Add missing check for alloc_ordered_workqueue&#xA;As it may return NULL pointer and cause NULL pointer dereference. Add check&#xA;for the return value of alloc_ordered_workqueue.&#xA;CVE-2024-49889:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: avoid use-after-free in ext4_ext_show_leaf()&#xA;In ext4_find_extent(), path may be freed by error or be reallocated, so&#xA;using a previously saved *ppath may have been freed and thus may trigger&#xA;use-after-free, as follows:&#xA;ext4_split_extent&#xA;  path = *ppath;&#xA;  ext4_split_extent_at(ppath)&#xA;  path = ext4_find_extent(ppath)&#xA;  ext4_split_extent_at(ppath)&#xA;    // ext4_find_extent fails to free path&#xA;    // but zeroout succeeds&#xA;  ext4_ext_show_leaf(inode, path)&#xA;    eh = path[depth].p_hdr&#xA;    // path use-after-free !!!&#xA;Similar to ext4_split_extent_at(), we use *ppath directly as an input to&#xA;ext4_ext_show_leaf(). Fix a spelling error by the way.&#xA;Same problem in ext4_ext_handle_unwritten_extents(). Since &#39;path&#39; is only&#xA;used in ext4_ext_show_leaf(), remove &#39;path&#39; and use *ppath directly.&#xA;This issue is triggered only when EXT_DEBUG is defined and therefore does&#xA;not affect functionality.&#xA;CVE-2024-49950:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: L2CAP: Fix uaf in l2cap_connect&#xA;[Syzbot reported]&#xA;BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949&#xA;Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54&#xA;CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;Workqueue: hci2 hci_rx_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:93 [inline]&#xA; dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0xc3/0x620 mm/kasan/report.c:488&#xA; kasan_report+0xd9/0x110 mm/kasan/report.c:601&#xA; l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949&#xA; l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]&#xA; l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]&#xA; l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]&#xA; l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825&#xA; l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514&#xA; hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]&#xA; hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028&#xA; process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231&#xA; process_scheduled_works kernel/workqueue.c:3312 [inline]&#xA; worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389&#xA; kthread+0x2c1/0x3a0 kernel/kthread.c:389&#xA; ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;...&#xA;Freed by task 5245:&#xA; kasan_save_stack+0x33/0x60 mm/kasan/common.c:47&#xA; kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA; kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579&#xA; poison_slab_object+0xf7/0x160 mm/kasan/common.c:240&#xA; __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256&#xA; kasan_slab_free include/linux/kasan.h:184 [inline]&#xA; slab_free_hook mm/slub.c:2256 [inline]&#xA; slab_free mm/slub.c:4477 [inline]&#xA; kfree+0x12a/0x3b0 mm/slub.c:4598&#xA; l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]&#xA; kref_put include/linux/kref.h:65 [inline]&#xA; l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]&#xA; l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802&#xA; l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241&#xA; hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]&#xA; hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265&#xA; hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583&#xA; abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917&#xA; hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328&#xA; process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231&#xA; process_scheduled_works kernel/workqueue.c:3312 [inline]&#xA; worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389&#xA; kthread+0x2c1/0x3a0 kernel/kthread.c:389&#xA; ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;CVE-2024-49917:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&gt;funcs in dcn30_init_hw&#xA;This commit addresses a potential null pointer dereference issue in the&#xA;`dcn30_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` or&#xA;`dc-&gt;clk_mgr-&gt;funcs` is null.&#xA;The fix adds a check to ensure `dc-&gt;clk_mgr` and `dc-&gt;clk_mgr-&gt;funcs` is&#xA;not null before accessing its functions. This prevents a potential null&#xA;pointer dereference.&#xA;Reported by smatch:&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed &#39;dc-&gt;clk_mgr&#39; could be null (see line 628)&#xA;CVE-2024-49884:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix slab-use-after-free in ext4_split_extent_at()&#xA;We hit the following use-after-free:&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0&#xA;Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40&#xA;CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; kasan_report+0x93/0xc0&#xA; ext4_split_extent_at+0xba8/0xcc0&#xA; ext4_split_extent.isra.0+0x18f/0x500&#xA; ext4_split_convert_extents+0x275/0x750&#xA; ext4_ext_handle_unwritten_extents+0x73e/0x1580&#xA; ext4_ext_map_blocks+0xe20/0x2dc0&#xA; ext4_map_blocks+0x724/0x1700&#xA; ext4_do_writepages+0x12d6/0x2a70&#xA;[...]&#xA;Allocated by task 40:&#xA; __kmalloc_noprof+0x1ac/0x480&#xA; ext4_find_extent+0xf3b/0x1e70&#xA; ext4_ext_map_blocks+0x188/0x2dc0&#xA; ext4_map_blocks+0x724/0x1700&#xA; ext4_do_writepages+0x12d6/0x2a70&#xA;[...]&#xA;Freed by task 40:&#xA; kfree+0xf1/0x2b0&#xA; ext4_find_extent+0xa71/0x1e70&#xA; ext4_ext_insert_extent+0xa22/0x3260&#xA; ext4_split_extent_at+0x3ef/0xcc0&#xA; ext4_split_extent.isra.0+0x18f/0x500&#xA; ext4_split_convert_extents+0x275/0x750&#xA; ext4_ext_handle_unwritten_extents+0x73e/0x1580&#xA; ext4_ext_map_blocks+0xe20/0x2dc0&#xA; ext4_map_blocks+0x724/0x1700&#xA; ext4_do_writepages+0x12d6/0x2a70&#xA;[...]&#xA;==================================================================&#xA;The flow of issue triggering is as follows:&#xA;ext4_split_extent_at&#xA;  path = *ppath&#xA;  ext4_ext_insert_extent(ppath)&#xA;    ext4_ext_create_new_leaf(ppath)&#xA;      ext4_find_extent(orig_path)&#xA;        path = *orig_path&#xA;        read_extent_tree_block&#xA;          // return -ENOMEM or -EIO&#xA;        ext4_free_ext_path(path)&#xA;          kfree(path)&#xA;        *orig_path = NULL&#xA;  a. If err is -ENOMEM:&#xA;  ext4_ext_dirty(path + path-&gt;p_depth)&#xA;  // path use-after-free !!!&#xA;  b. If err is -EIO and we have EXT_DEBUG defined:&#xA;  ext4_ext_show_leaf(path)&#xA;    eh = path[depth].p_hdr&#xA;    // path also use-after-free !!!&#xA;So when trying to zeroout or fix the extent length, call ext4_find_extent()&#xA;to update the path.&#xA;In addition we use *ppath directly as an ext4_ext_show_leaf() input to&#xA;avoid possible use-after-free when EXT_DEBUG is defined, and to avoid&#xA;unnecessary path updates.&#xA;CVE-2024-49940:In the Linux kernel, the following vulnerability has been resolved:&#xA;l2tp: prevent possible tunnel refcount underflow&#xA;When a session is created, it sets a backpointer to its tunnel. When&#xA;the session refcount drops to 0, l2tp_session_free drops the tunnel&#xA;refcount if session-&gt;tunnel is non-NULL. However, session-&gt;tunnel is&#xA;set in l2tp_session_create, before the tunnel refcount is incremented&#xA;by l2tp_session_register, which leaves a small window where&#xA;session-&gt;tunnel is non-NULL when the tunnel refcount hasn&#39;t been&#xA;bumped.&#xA;Moving the assignment to l2tp_session_register is trivial but&#xA;l2tp_session_create calls l2tp_session_set_header_len which uses&#xA;session-&gt;tunnel to get the tunnel&#39;s encap. Add an encap arg to&#xA;l2tp_session_set_header_len to avoid using session-&gt;tunnel.&#xA;If l2tpv3 sessions have colliding IDs, it is possible for&#xA;l2tp_v3_session_get to race with l2tp_session_register and fetch a&#xA;session which doesn&#39;t yet have session-&gt;tunnel set. Add a check for&#xA;this case.&#xA;CVE-2024-49973:In the Linux kernel, the following vulnerability has been resolved:&#xA;r8169: add tally counter fields added with RTL8125&#xA;RTL8125 added fields to the tally counter, what may result in the chip&#xA;dma&#39;ing these new fields to unallocated memory. Therefore make sure&#xA;that the allocated memory area is big enough to hold all of the&#xA;tally counter values, even if we use only parts of it.&#xA;CVE-2024-49996:In the Linux kernel, the following vulnerability has been resolved:&#xA;cifs: Fix buffer overflow when parsing NFS reparse points&#xA;ReparseDataLength is sum of the InodeType size and DataBuffer size.&#xA;So to get DataBuffer size it is needed to subtract InodeType&#39;s size from&#xA;ReparseDataLength.&#xA;Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer&#xA;at position after the end of the buffer because it does not subtract&#xA;InodeType size from the length. Fix this problem and correctly subtract&#xA;variable len.&#xA;Member InodeType is present only when reparse buffer is large enough. Check&#xA;for ReparseDataLength before accessing InodeType to prevent another invalid&#xA;memory access.&#xA;Major and minor rdev values are present also only when reparse buffer is&#xA;large enough. Check for reparse buffer size before calling reparse_mkdev().&#xA;CVE-2024-49995:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: guard against string buffer overrun&#xA;Smatch reports that copying media_name and if_name to name_parts may&#xA;overwrite the destination.&#xA; .../bearer.c:166 bearer_name_validate() error: strcpy() &#39;media_name&#39; too large for &#39;name_parts-&gt;media_name&#39; (32 vs 16)&#xA; .../bearer.c:167 bearer_name_validate() error: strcpy() &#39;if_name&#39; too large for &#39;name_parts-&gt;if_name&#39; (1010102 vs 16)&#xA;This does seem to be the case so guard against this possibility by using&#xA;strscpy() and failing if truncation occurs.&#xA;Introduced by commit b97bf3fd8f6a (&#34;[TIPC] Initial merge&#34;)&#xA;Compile tested only.&#xA;CVE-2024-49958:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: reserve space for inline xattr before attaching reflink tree&#xA;One of our customers reported a crash and a corrupted ocfs2 filesystem. &#xA;The crash was due to the detection of corruption.  Upon troubleshooting,&#xA;the fsck -fn output showed the below corruption&#xA;[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,&#xA;but fsck believes the largest valid value is 227.  Clamp the next record value? n&#xA;The stat output from the debugfs.ocfs2 showed the following corruption&#xA;where the &#34;Next Free Rec:&#34; had overshot the &#34;Count:&#34; in the root metadata&#xA;block.&#xA;        Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)&#xA;        FS Generation: 904309833 (0x35e6ac49)&#xA;        CRC32: 00000000   ECC: 0000&#xA;        Type: Regular   Attr: 0x0   Flags: Valid&#xA;        Dynamic Features: (0x16) HasXattr InlineXattr Refcounted&#xA;        Extended Attributes Block: 0  Extended Attributes Inline Size: 256&#xA;        User: 0 (root)   Group: 0 (root)   Size: 281320357888&#xA;        Links: 1   Clusters: 141738&#xA;        ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024&#xA;        atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024&#xA;        mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024&#xA;        dtime: 0x0 -- Wed Dec 31 17:00:00 1969&#xA;        Refcount Block: 2777346&#xA;        Last Extblk: 2886943   Orphan Slot: 0&#xA;        Sub Alloc Slot: 0   Sub Alloc Bit: 14&#xA;        Tree Depth: 1   Count: 227   Next Free Rec: 230&#xA;        ## Offset        Clusters       Block#&#xA;        0  0             2310           2776351&#xA;        1  2310          2139           2777375&#xA;        2  4449          1221           2778399&#xA;        3  5670          731            2779423&#xA;        4  6401          566            2780447&#xA;        .......          ....           .......&#xA;        .......          ....           .......&#xA;The issue was in the reflink workfow while reserving space for inline&#xA;xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the&#xA;time this function is called the reflink tree is already recreated at the&#xA;destination inode from the source inode.  At this point, this function&#xA;reserves space for inline xattrs at the destination inode without even&#xA;checking if there is space at the root metadata block.  It simply reduces&#xA;the l_count from 243 to 227 thereby making space of 256 bytes for inline&#xA;xattr whereas the inode already has extents beyond this index (in this&#xA;case up to 230), thereby causing corruption.&#xA;The fix for this is to reserve space for inline metadata at the destination&#xA;inode before the reflink tree gets recreated. The customer has verified the&#xA;fix.&#xA;CVE-2024-49877:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate&#xA;When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger&#xA;NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if&#xA;bh is NULL.&#xA;CVE-2024-49913:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream&#xA;This commit addresses a null pointer dereference issue in the&#xA;`commit_planes_for_stream` function at line 4140. The issue could occur&#xA;when `top_pipe_to_program` is null.&#xA;The fix adds a check to ensure `top_pipe_to_program` is not null before&#xA;accessing its stream_res. This prevents a null pointer dereference.&#xA;Reported by smatch:&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed &#39;top_pipe_to_program&#39; could be null (see line 3906)&#xA;CVE-2024-49992:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/stm: Avoid use-after-free issues with crtc and plane&#xA;ltdc_load() calls functions drm_crtc_init_with_planes(),&#xA;drm_universal_plane_init() and drm_encoder_init(). These functions&#xA;should not be called with parameters allocated with devm_kzalloc()&#xA;to avoid use-after-free issues [1].&#xA;Use allocations managed by the DRM framework.&#xA;Found by Linux Verification Center (linuxtesting.org).&#xA;[1]&#xA;https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/&#xA;CVE-2024-49978:In the Linux kernel, the following vulnerability has been resolved:&#xA;gso: fix udp gso fraglist segmentation after pull from frag_list&#xA;Detect gso fraglist skbs with corrupted geometry (see below) and&#xA;pass these to skb_segment instead of skb_segment_list, as the first&#xA;can segment them correctly.&#xA;Valid SKB_GSO_FRAGLIST skbs&#xA;- consist of two or more segments&#xA;- the head_skb holds the protocol headers plus first gso_size&#xA;- one or more frag_list skbs hold exactly one segment&#xA;- all but the last must be gso_size&#xA;Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can&#xA;modify these skbs, breaking these invariants.&#xA;In extreme cases they pull all data into skb linear. For UDP, this&#xA;causes a NULL ptr deref in __udpv4_gso_segment_list_csum at&#xA;udp_hdr(seg-&gt;next)-&gt;dest.&#xA;Detect invalid geometry due to pull, by checking head_skb size.&#xA;Don&#39;t just drop, as this may blackhole a destination. Convert to be&#xA;able to pass to regular skb_segment.&#xA;CVE-2024-49934:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name&#xA;It&#39;s observed that a crash occurs during hot-remove a memory device,&#xA;in which user is accessing the hugetlb. See calltrace as following:&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790&#xA;Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s&#xA;mirror dm_region_hash dm_log dm_mod&#xA;CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:do_user_addr_fault+0x2a0/0x790&#xA;Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff &lt;0f&gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41&#xA;RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046&#xA;RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000&#xA;RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36&#xA;RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658&#xA;R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000&#xA;FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __warn+0x8d/0x190&#xA; ? do_user_addr_fault+0x2a0/0x790&#xA; ? report_bug+0x1c3/0x1d0&#xA; ? handle_bug+0x3c/0x70&#xA; ? exc_invalid_op+0x14/0x70&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? do_user_addr_fault+0x2a0/0x790&#xA; ? exc_page_fault+0x31/0x200&#xA; exc_page_fault+0x68/0x200&#xA;&lt;...snip...&gt;&#xA;BUG: unable to handle page fault for address: 0000000000001000&#xA; #PF: supervisor read access in kernel mode&#xA; #PF: error_code(0x0000) - not-present page&#xA; PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0&#xA; Oops: Oops: 0000 [#1] PREEMPT SMP PTI&#xA; ---[ end trace 0000000000000000 ]---&#xA; BUG: unable to handle page fault for address: 0000000000001000&#xA; #PF: supervisor read access in kernel mode&#xA; #PF: error_code(0x0000) - not-present page&#xA; PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0&#xA; Oops: Oops: 0000 [#1] PREEMPT SMP PTI&#xA; CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA; RIP: 0010:dentry_name+0x1f4/0x440&#xA;&lt;...snip...&gt;&#xA;? dentry_name+0x2fa/0x440&#xA;vsnprintf+0x1f3/0x4f0&#xA;vprintk_store+0x23a/0x540&#xA;vprintk_emit+0x6d/0x330&#xA;_printk+0x58/0x80&#xA;dump_mapping+0x10b/0x1a0&#xA;? __pfx_free_object_rcu+0x10/0x10&#xA;__dump_page+0x26b/0x3e0&#xA;? vprintk_emit+0xe0/0x330&#xA;? _printk+0x58/0x80&#xA;? dump_page+0x17/0x50&#xA;dump_page+0x17/0x50&#xA;do_migrate_range+0x2f7/0x7f0&#xA;? do_migrate_range+0x42/0x7f0&#xA;? offline_pages+0x2f4/0x8c0&#xA;offline_pages+0x60a/0x8c0&#xA;memory_subsys_offline+0x9f/0x1c0&#xA;? lockdep_hardirqs_on+0x77/0x100&#xA;? _raw_spin_unlock_irqrestore+0x38/0x60&#xA;device_offline+0xe3/0x110&#xA;state_store+0x6e/0xc0&#xA;kernfs_fop_write_iter+0x143/0x200&#xA;vfs_write+0x39f/0x560&#xA;ksys_write+0x65/0xf0&#xA;do_syscall_64+0x62/0x130&#xA;Previously, some sanity check have been done in dump_mapping() before&#xA;the print facility parsing &#39;%pd&#39; though, it&#39;s still possible to run into&#xA;an invalid dentry.d_name.name.&#xA;Since dump_mapping() only needs to dump the filename only, retrieve it&#xA;by itself in a safer way to prevent an unnecessary crash.&#xA;Note that either retrieving the filename with &#39;%pd&#39; or&#xA;strncpy_from_kernel_nofault(), the filename could be unreliable.&#xA;CVE-2024-49936:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/xen-netback: prevent UAF in xenvif_flush_hash()&#xA;During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,&#xA;kfree_rcu does not exist inside the rcu read critical section, so if&#xA;kfree_rcu is called when the rcu grace period ends during the iteration,&#xA;UAF occurs when accessing head-&gt;next after the entry becomes free.&#xA;Therefore, to solve this, you need to change it to list_for_each_entry_safe.&#xA;CVE-2024-50008:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()&#xA;Replace one-element array with a flexible-array member in&#xA;`struct host_cmd_ds_802_11_scan_ext`.&#xA;With this, fix the following warning:&#xA;elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------&#xA;elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field &#34;ext_scan-&gt;tlv_buffer&#34; at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1)&#xA;elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]&#xA;CVE-2024-50016:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Avoid overflow assignment in link_dp_cts&#xA;sampling_rate is an uint8_t but is assigned an unsigned int, and thus it&#xA;can overflow. As a result, sampling_rate is changed to uint32_t.&#xA;Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should&#xA;only be assigned to a value less or equal than 4.&#xA;This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.&#xA;CVE-2024-49965:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: remove unreasonable unlock in ocfs2_read_blocks&#xA;Patch series &#34;Misc fixes for ocfs2_read_blocks&#34;, v5.&#xA;This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix&#xA;the issue reported by syzbot, which detects bad unlock balance in&#xA;ocfs2_read_blocks().  The second patch fixes an issue reported by Heming&#xA;Zhao when reviewing above fix.&#xA;This patch (of 2):&#xA;There was a lock release before exiting, so remove the unreasonable unlock.&#xA;CVE-2024-49981:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: venus: fix use after free bug in venus_remove due to race condition&#xA;in venus_probe, core-&gt;work is bound with venus_sys_error_handler, which is&#xA;used to handle error. The code use core-&gt;sys_err_done to make sync work.&#xA;The core-&gt;work is started in venus_event_notify.&#xA;If we call venus_remove, there might be an unfished work. The possible&#xA;sequence is as follows:&#xA;CPU0                  CPU1&#xA;                     |venus_sys_error_handler&#xA;venus_remove         |&#xA;hfi_destroy&#x9; &#x9;&#x9; |&#xA;venus_hfi_destroy&#x9; |&#xA;kfree(hdev);&#x9;     |&#xA;                     |hfi_reinit&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; |venus_hfi_queues_reinit&#xA;                     |//use hdev&#xA;Fix it by canceling the work in venus_remove.&#xA;CVE-2024-49955:In the Linux kernel, the following vulnerability has been resolved:&#xA;ACPI: battery: Fix possible crash when unregistering a battery hook&#xA;When a battery hook returns an error when adding a new battery, then&#xA;the battery hook is automatically unregistered.&#xA;However the battery hook provider cannot know that, so it will later&#xA;call battery_hook_unregister() on the already unregistered battery&#xA;hook, resulting in a crash.&#xA;Fix this by using the list head to mark already unregistered battery&#xA;hooks as already being unregistered so that they can be ignored by&#xA;battery_hook_unregister().&#xA;CVE-2024-49883:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: aovid use-after-free in ext4_ext_insert_extent()&#xA;As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is&#xA;reallocated in ext4_ext_create_new_leaf(), we&#39;ll use the stale path and&#xA;cause UAF. Below is a sample trace with dummy values:&#xA;ext4_ext_insert_extent&#xA;  path = *ppath = 2000&#xA;  ext4_ext_create_new_leaf(ppath)&#xA;    ext4_find_extent(ppath)&#xA;      path = *ppath = 2000&#xA;      if (depth &gt; path[0].p_maxdepth)&#xA;            kfree(path = 2000);&#xA;            *ppath = path = NULL;&#xA;      path = kcalloc() = 3000&#xA;      *ppath = 3000;&#xA;      return path;&#xA;  /* here path is still 2000, UAF! */&#xA;  eh = path[depth].p_hdr&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330&#xA;Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179&#xA;CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ext4_ext_insert_extent+0x26d4/0x3330&#xA; ext4_ext_map_blocks+0xe22/0x2d40&#xA; ext4_map_blocks+0x71e/0x1700&#xA; ext4_do_writepages+0x1290/0x2800&#xA;[...]&#xA;Allocated by task 179:&#xA; ext4_find_extent+0x81c/0x1f70&#xA; ext4_ext_map_blocks+0x146/0x2d40&#xA; ext4_map_blocks+0x71e/0x1700&#xA; ext4_do_writepages+0x1290/0x2800&#xA; ext4_writepages+0x26d/0x4e0&#xA; do_writepages+0x175/0x700&#xA;[...]&#xA;Freed by task 179:&#xA; kfree+0xcb/0x240&#xA; ext4_find_extent+0x7c0/0x1f70&#xA; ext4_ext_insert_extent+0xa26/0x3330&#xA; ext4_ext_map_blocks+0xe22/0x2d40&#xA; ext4_map_blocks+0x71e/0x1700&#xA; ext4_do_writepages+0x1290/0x2800&#xA; ext4_writepages+0x26d/0x4e0&#xA; do_writepages+0x175/0x700&#xA;[...]&#xA;==================================================================&#xA;So use *ppath to update the path to avoid the above problem.&#xA;CVE-2024-49924:In the Linux kernel, the following vulnerability has been resolved:&#xA;fbdev: pxafb: Fix possible use after free in pxafb_task()&#xA;In the pxafb_probe function, it calls the pxafb_init_fbinfo function,&#xA;after which &amp;fbi-&gt;task is associated with pxafb_task. Moreover,&#xA;within this pxafb_init_fbinfo function, the pxafb_blank function&#xA;within the &amp;pxafb_ops struct is capable of scheduling work.&#xA;If we remove the module which will call pxafb_remove to make cleanup,&#xA;it will call unregister_framebuffer function which can call&#xA;do_unregister_framebuffer to free fbi-&gt;fb through&#xA;put_fb_info(fb_info), while the work mentioned above will be used.&#xA;The sequence of operations that may lead to a UAF bug is as follows:&#xA;CPU0                                                CPU1&#xA;                                   | pxafb_task&#xA;pxafb_remove                       |&#xA;unregister_framebuffer(info)       |&#xA;do_unregister_framebuffer(fb_info) |&#xA;put_fb_info(fb_info)               |&#xA;// free fbi-&gt;fb                    | set_ctrlr_state(fbi, state)&#xA;                                   | __pxafb_lcd_power(fbi, 0)&#xA;                                   | fbi-&gt;lcd_power(on, &amp;fbi-&gt;fb.var)&#xA;                                   | //use fbi-&gt;fb&#xA;Fix it by ensuring that the work is canceled before proceeding&#xA;with the cleanup in pxafb_remove.&#xA;Note that only root user can remove the driver at runtime.&#xA;CVE-2024-49933:In the Linux kernel, the following vulnerability has been resolved:&#xA;blk_iocost: fix more out of bound shifts&#xA;Recently running UBSAN caught few out of bound shifts in the&#xA;ioc_forgive_debts() function:&#xA;UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38&#xA;shift exponent 80 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long&#xA;long&#39;)&#xA;...&#xA;UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30&#xA;shift exponent 80 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long&#xA;long&#39;)&#xA;...&#xA;Call Trace:&#xA;&lt;IRQ&gt;&#xA;dump_stack_lvl+0xca/0x130&#xA;__ubsan_handle_shift_out_of_bounds+0x22c/0x280&#xA;? __lock_acquire+0x6441/0x7c10&#xA;ioc_timer_fn+0x6cec/0x7750&#xA;? blk_iocost_init+0x720/0x720&#xA;? call_timer_fn+0x5d/0x470&#xA;call_timer_fn+0xfa/0x470&#xA;? blk_iocost_init+0x720/0x720&#xA;__run_timer_base+0x519/0x700&#xA;...&#xA;Actual impact of this issue was not identified but I propose to fix the&#xA;undefined behaviour.&#xA;The proposed fix to prevent those out of bound shifts consist of&#xA;precalculating exponent before using it the shift operations by taking&#xA;min value from the actual exponent and maximum possible number of bits.&#xA;CVE-2024-49922:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check null pointers before using them&#xA;[WHAT &amp; HOW]&#xA;These pointers are null checked previously in the same function,&#xA;indicating they might be null as reported by Coverity. As a result,&#xA;they need to be checked when used again.&#xA;This fixes 3 FORWARD_NULL issue reported by Coverity.&#xA;CVE-2024-49954:In the Linux kernel, the following vulnerability has been resolved:&#xA;static_call: Replace pointless WARN_ON() in static_call_module_notify()&#xA;static_call_module_notify() triggers a WARN_ON(), when memory allocation&#xA;fails in __static_call_add_module().&#xA;That&#39;s not really justified, because the failure case must be correctly&#xA;handled by the well known call chain and the error code is passed&#xA;through to the initiating userspace application.&#xA;A memory allocation fail is not a fatal problem, but the WARN_ON() takes&#xA;the machine out when panic_on_warn is set.&#xA;Replace it with a pr_warn().&#xA;CVE-2024-49975:In the Linux kernel, the following vulnerability has been resolved:&#xA;uprobes: fix kernel info leak via &#34;[uprobes]&#34; vma&#xA;xol_add_vma() maps the uninitialized page allocated by __create_xol_area()&#xA;into userspace. On some architectures (x86) this memory is readable even&#xA;without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,&#xA;although this doesn&#39;t really matter, debugger can read this memory anyway.&#xA;CVE-2022-48960:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hisilicon: Fix potential use-after-free in hix5hd2_rx()&#xA;The skb is delivered to napi_gro_receive() which may free it, after&#xA;calling this, dereferencing skb may trigger use-after-free.&#xA;CVE-2024-50035:In the Linux kernel, the following vulnerability has been resolved:&#xA;ppp: fix ppp_async_encode() illegal access&#xA;syzbot reported an issue in ppp_async_encode() [1]&#xA;In this case, pppoe_sendmsg() is called with a zero size.&#xA;Then ppp_async_encode() is called with an empty skb.&#xA;BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]&#xA; BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675&#xA;  ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]&#xA;  ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675&#xA;  ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634&#xA;  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]&#xA;  ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304&#xA;  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379&#xA;  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113&#xA;  __release_sock+0x1da/0x330 net/core/sock.c:3072&#xA;  release_sock+0x6b/0x250 net/core/sock.c:3626&#xA;  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903&#xA;  sock_sendmsg_nosec net/socket.c:729 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:744&#xA;  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602&#xA;  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656&#xA;  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742&#xA;  __do_sys_sendmmsg net/socket.c:2771 [inline]&#xA;  __se_sys_sendmmsg net/socket.c:2768 [inline]&#xA;  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768&#xA;  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:4092 [inline]&#xA;  slab_alloc_node mm/slub.c:4135 [inline]&#xA;  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587&#xA;  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678&#xA;  alloc_skb include/linux/skbuff.h:1322 [inline]&#xA;  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732&#xA;  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867&#xA;  sock_sendmsg_nosec net/socket.c:729 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:744&#xA;  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602&#xA;  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656&#xA;  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742&#xA;  __do_sys_sendmmsg net/socket.c:2771 [inline]&#xA;  __se_sys_sendmmsg net/socket.c:2768 [inline]&#xA;  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768&#xA;  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;CVE-2022-49021:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: phy: fix null-ptr-deref while probe() failed&#xA;I got a null-ptr-deref report as following when doing fault injection test:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000058&#xA;Oops: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014&#xA;RIP: 0010:klist_put+0x2d/0xd0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; klist_remove+0xf1/0x1c0&#xA; device_release_driver_internal+0x23e/0x2d0&#xA; bus_remove_device+0x1bd/0x240&#xA; device_del+0x357/0x770&#xA; phy_device_remove+0x11/0x30&#xA; mdiobus_unregister+0xa5/0x140&#xA; release_nodes+0x6a/0xa0&#xA; devres_release_all+0xf8/0x150&#xA; device_unbind_cleanup+0x19/0xd0&#xA;//probe path:&#xA;phy_device_register()&#xA;  device_add()&#xA;phy_connect&#xA;  phy_attach_direct() //set device driver&#xA;    probe() //it&#39;s failed, driver is not bound&#xA;    device_bind_driver() // probe failed, it&#39;s not called&#xA;//remove path:&#xA;phy_device_remove()&#xA;  device_del()&#xA;    device_release_driver_internal()&#xA;      __device_release_driver() //dev-&gt;drv is not NULL&#xA;        klist_remove() &lt;- knode_driver is not added yet, cause null-ptr-deref&#xA;In phy_attach_direct(), after setting the &#39;dev-&gt;driver&#39;, probe() fails,&#xA;device_bind_driver() is not called, so the knode_driver-&gt;n_klist is not&#xA;set, then it causes null-ptr-deref in __device_release_driver() while&#xA;deleting device. Fix this by setting dev-&gt;driver to NULL in the error&#xA;path in phy_attach_direct().&#xA;CVE-2022-48966:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: mvneta: Prevent out of bounds read in mvneta_config_rss()&#xA;The pp-&gt;indir[0] value comes from the user.  It is passed to:&#xA;&#x9;if (cpu_online(pp-&gt;rxq_def))&#xA;inside the mvneta_percpu_elect() function.  It needs bounds checkeding&#xA;to ensure that it is not beyond the end of the cpu bitmap.&#xA;CVE-2022-49031:In the Linux kernel, the following vulnerability has been resolved:&#xA;iio: health: afe4403: Fix oob read in afe4403_read_raw&#xA;KASAN report out-of-bounds read as follows:&#xA;BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0&#xA;Read of size 4 at addr ffffffffc02ac638 by task cat/279&#xA;Call Trace:&#xA; afe4403_read_raw&#xA; iio_read_channel_info&#xA; dev_attr_show&#xA;The buggy address belongs to the variable:&#xA; afe4403_channel_leds+0x18/0xffffffffffffe9e0&#xA;This issue can be reproduced by singe command:&#xA; $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw&#xA;The array size of afe4403_channel_leds is less than channels, so access&#xA;with chan-&gt;address cause OOB read in afe4403_read_raw. Fix it by moving&#xA;access before use it.&#xA;CVE-2024-50047:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix UAF in async decryption&#xA;Doing an async decryption (large read) crashes with a&#xA;slab-use-after-free way down in the crypto API.&#xA;Reproducer:&#xA;    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt&#xA;    # dd if=/mnt/largefile of=/dev/null&#xA;    ...&#xA;    [  194.196391] ==================================================================&#xA;    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110&#xA;    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899&#xA;    [  194.197707]&#xA;    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43&#xA;    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014&#xA;    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]&#xA;    [  194.200032] Call Trace:&#xA;    [  194.200191]  &lt;TASK&gt;&#xA;    [  194.200327]  dump_stack_lvl+0x4e/0x70&#xA;    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110&#xA;    [  194.200809]  print_report+0x174/0x505&#xA;    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10&#xA;    [  194.201352]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0&#xA;    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110&#xA;    [  194.202128]  kasan_report+0xc8/0x150&#xA;    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110&#xA;    [  194.202616]  gf128mul_4k_lle+0xc1/0x110&#xA;    [  194.202863]  ghash_update+0x184/0x210&#xA;    [  194.203103]  shash_ahash_update+0x184/0x2a0&#xA;    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10&#xA;    [  194.203651]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340&#xA;    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140&#xA;    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]&#xA;    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]&#xA;    [  194.208507]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.209205]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.209925]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.210443]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]&#xA;    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]&#xA;    [  194.214670]  ? srso_return_thunk+0x5/0x5f&#xA;    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]&#xA;This is because TFM is being used in parallel.&#xA;Fix this by allocating a new AEAD TFM for async decryption, but keep&#xA;the existing one for synchronous READ cases (similar to what is done&#xA;in smb3_calc_signature()).&#xA;Also remove the calls to aead_request_set_callback() and&#xA;crypto_wait_req() since it&#39;s always going to be a synchronous operation.&#xA;CVE-2022-49032:In the Linux kernel, the following vulnerability has been resolved:&#xA;iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw&#xA;KASAN report out-of-bounds read as follows:&#xA;BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380&#xA;Read of size 4 at addr ffffffffc00e4658 by task cat/278&#xA;Call Trace:&#xA; afe4404_read_raw&#xA; iio_read_channel_info&#xA; dev_attr_show&#xA;The buggy address belongs to the variable:&#xA; afe4404_channel_leds+0x18/0xffffffffffffe9c0&#xA;This issue can be reproduce by singe command:&#xA; $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw&#xA;The array size of afe4404_channel_leds and afe4404_channel_offdacs&#xA;are less than channels, so access with chan-&gt;address cause OOB read&#xA;in afe4404_[read|write]_raw. Fix it by moving access before use them.&#xA;CVE-2024-50058:In the Linux kernel, the following vulnerability has been resolved:&#xA;serial: protect uart_port_dtr_rts() in uart_shutdown() too&#xA;Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part&#xA;3) added few uport == NULL checks. It added one to uart_shutdown(), so&#xA;the commit assumes, uport can be NULL in there. But right after that&#xA;protection, there is an unprotected &#34;uart_port_dtr_rts(uport, false);&#34;&#xA;call. That is invoked only if HUPCL is set, so I assume that is the&#xA;reason why we do not see lots of these reports.&#xA;Or it cannot be NULL at this point at all for some reason :P.&#xA;Until the above is investigated, stay on the safe side and move this&#xA;dereference to the if too.&#xA;I got this inconsistency from Coverity under CID 1585130. Thanks.&#xA;CVE-2022-49023:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: cfg80211: fix buffer overflow in elem comparison&#xA;For vendor elements, the code here assumes that 5 octets&#xA;are present without checking. Since the element itself is&#xA;already checked to fit, we only need to check the length.&#xA;CVE-2024-50046:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()&#xA;On the node of an NFS client, some files saved in the mountpoint of the&#xA;NFS server were copied to another location of the same NFS server.&#xA;Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference&#xA;crash with the following syslog:&#xA;[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116&#xA;[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116&#xA;[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058&#xA;[232066.588586] Mem abort info:&#xA;[232066.588701]   ESR = 0x0000000096000007&#xA;[232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[232066.589084]   SET = 0, FnV = 0&#xA;[232066.589216]   EA = 0, S1PTW = 0&#xA;[232066.589340]   FSC = 0x07: level 3 translation fault&#xA;[232066.589559] Data abort info:&#xA;[232066.589683]   ISV = 0, ISS = 0x00000007&#xA;[232066.589842]   CM = 0, WnR = 0&#xA;[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400&#xA;[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000&#xA;[232066.590757] Internal error: Oops: 96000007 [#1] SMP&#xA;[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2&#xA;[232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs&#xA;[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1&#xA;[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06&#xA;[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]&#xA;[232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]&#xA;[232066.598595] sp : ffff8000f568fc70&#xA;[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000&#xA;[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001&#xA;[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050&#xA;[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000&#xA;[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000&#xA;[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6&#xA;[232066.600498] x11: 00000000000000&#xA;---truncated---&#xA;CVE-2024-50059:In the Linux kernel, the following vulnerability has been resolved:&#xA;ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition&#xA;In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev&#xA;function, then &amp;sndev-&gt;check_link_status_work is bound with&#xA;check_link_status_work. switchtec_ntb_link_notification may be called&#xA;to start the work.&#xA;If we remove the module which will call switchtec_ntb_remove to make&#xA;cleanup, it will free sndev through kfree(sndev), while the work&#xA;mentioned above will be used. The sequence of operations that may lead&#xA;to a UAF bug is as follows:&#xA;CPU0                                 CPU1&#xA;                        | check_link_status_work&#xA;switchtec_ntb_remove    |&#xA;kfree(sndev);           |&#xA;                        | if (sndev-&gt;link_force_down)&#xA;                        | // use sndev&#xA;Fix it by ensuring that the work is canceled before proceeding with&#xA;the cleanup in switchtec_ntb_remove.&#xA;CVE-2024-50028:In the Linux kernel, the following vulnerability has been resolved:&#xA;thermal: core: Reference count the zone in thermal_zone_get_by_id()&#xA;There are places in the thermal netlink code where nothing prevents&#xA;the thermal zone object from going away while being accessed after it&#xA;has been returned by thermal_zone_get_by_id().&#xA;To address this, make thermal_zone_get_by_id() get a reference on the&#xA;thermal zone device object to be returned with the help of get_device(),&#xA;under thermal_list_lock, and adjust all of its callers to this change&#xA;with the help of the cleanup.h infrastructure.&#xA;CVE-2022-49011:In the Linux kernel, the following vulnerability has been resolved:&#xA;hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()&#xA;As comment of pci_get_domain_bus_and_slot() says, it returns&#xA;a pci device with refcount increment, when finish using it,&#xA;the caller must decrement the reference count by calling&#xA;pci_dev_put(). So call it after using to avoid refcount leak.&#xA;CVE-2022-48992:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: soc-pcm: Add NULL check in BE reparenting&#xA;Add NULL check in dpcm_be_reparent API, to handle&#xA;kernel NULL pointer dereference error.&#xA;The issue occurred in fuzzing test.&#xA;CVE-2022-49005:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: ops: Fix bounds check for _sx controls&#xA;For _sx controls the semantics of the max field is not the usual one, max&#xA;is the number of steps rather than the maximum value. This means that our&#xA;check in snd_soc_put_volsw_sx() needs to just check against the maximum&#xA;value.&#xA;CVE-2024-50060:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring: check if we need to reschedule during overflow flush&#xA;In terms of normal application usage, this list will always be empty.&#xA;And if an application does overflow a bit, it&#39;ll have a few entries.&#xA;However, nothing obviously prevents syzbot from running a test case&#xA;that generates a ton of overflow entries, and then flushing them can&#xA;take quite a while.&#xA;Check for needing to reschedule while flushing, and drop our locks and&#xA;do so if necessary. There&#39;s no state to maintain here as overflows&#xA;always prune from head-of-list, hence it&#39;s fine to drop and reacquire&#xA;the locks at the end of the loop.&#xA;CVE-2022-49017:In the Linux kernel, the following vulnerability has been resolved:&#xA;tipc: re-fetch skb cb after tipc_msg_validate&#xA;As the call trace shows, the original skb was freed in tipc_msg_validate(),&#xA;and dereferencing the old skb cb would cause an use-after-free crash.&#xA;  BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]&#xA;   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]&#xA;   tipc_rcv+0x744/0x1150 [tipc]&#xA;  ...&#xA;  Allocated by task 47078:&#xA;   kmem_cache_alloc_node+0x158/0x4d0&#xA;   __alloc_skb+0x1c1/0x270&#xA;   tipc_buf_acquire+0x1e/0xe0 [tipc]&#xA;   tipc_msg_create+0x33/0x1c0 [tipc]&#xA;   tipc_link_build_proto_msg+0x38a/0x2100 [tipc]&#xA;   tipc_link_timeout+0x8b8/0xef0 [tipc]&#xA;   tipc_node_timeout+0x2a1/0x960 [tipc]&#xA;   call_timer_fn+0x2d/0x1c0&#xA;  ...&#xA;  Freed by task 47078:&#xA;   tipc_msg_validate+0x7b/0x440 [tipc]&#xA;   tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]&#xA;   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]&#xA;   tipc_rcv+0x744/0x1150 [tipc]&#xA;This patch fixes it by re-fetching the skb cb from the new allocated skb&#xA;after calling tipc_msg_validate().&#xA;CVE-2022-48958:In the Linux kernel, the following vulnerability has been resolved:&#xA;ethernet: aeroflex: fix potential skb leak in greth_init_rings()&#xA;The greth_init_rings() function won&#39;t free the newly allocated skb when&#xA;dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.&#xA;Compile tested only.&#xA;CVE-2022-48962:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hisilicon: Fix potential use-after-free in hisi_femac_rx()&#xA;The skb is delivered to napi_gro_receive() which may free it, after&#xA;calling this, dereferencing skb may trigger use-after-free.&#xA;CVE-2022-48956:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: avoid use-after-free in ip6_fragment()&#xA;Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.&#xA;It seems to not be always true, at least for UDP stack.&#xA;syzbot reported:&#xA;BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]&#xA;BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951&#xA;Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618&#xA;CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:284 [inline]&#xA; print_report+0x15e/0x45d mm/kasan/report.c:395&#xA; kasan_report+0xbf/0x1f0 mm/kasan/report.c:495&#xA; ip6_dst_idev include/net/ip6_fib.h:245 [inline]&#xA; ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951&#xA; __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]&#xA; ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206&#xA; NF_HOOK_COND include/linux/netfilter.h:291 [inline]&#xA; ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227&#xA; dst_output include/net/dst.h:445 [inline]&#xA; ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161&#xA; ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966&#xA; udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286&#xA; udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313&#xA; udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606&#xA; inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665&#xA; sock_sendmsg_nosec net/socket.c:714 [inline]&#xA; sock_sendmsg+0xd3/0x120 net/socket.c:734&#xA; sock_write_iter+0x295/0x3d0 net/socket.c:1108&#xA; call_write_iter include/linux/fs.h:2191 [inline]&#xA; new_sync_write fs/read_write.c:491 [inline]&#xA; vfs_write+0x9ed/0xdd0 fs/read_write.c:584&#xA; ksys_write+0x1ec/0x250 fs/read_write.c:637&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;RIP: 0033:0x7fde3588c0d9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9&#xA;RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a&#xA;RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000&#xA; &lt;/TASK&gt;&#xA;Allocated by task 7618:&#xA; kasan_save_stack+0x22/0x40 mm/kasan/common.c:45&#xA; kasan_set_track+0x25/0x30 mm/kasan/common.c:52&#xA; __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325&#xA; kasan_slab_alloc include/linux/kasan.h:201 [inline]&#xA; slab_post_alloc_hook mm/slab.h:737 [inline]&#xA; slab_alloc_node mm/slub.c:3398 [inline]&#xA; slab_alloc mm/slub.c:3406 [inline]&#xA; __kmem_cache_alloc_lru mm/slub.c:3413 [inline]&#xA; kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422&#xA; dst_alloc+0x14a/0x1f0 net/core/dst.c:92&#xA; ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344&#xA; ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]&#xA; rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]&#xA; ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254&#xA; pol_lookup_func include/net/ip6_fib.h:582 [inline]&#xA; fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121&#xA; ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625&#xA; ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638&#xA; ip6_route_output include/net/ip6_route.h:98 [inline]&#xA; ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092&#xA; ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222&#xA; ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260&#xA; udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554&#xA; inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665&#xA; sock_sendmsg_nosec n&#xA;---truncated---&#xA;CVE-2024-50033:In the Linux kernel, the following vulnerability has been resolved:&#xA;slip: make slhc_remember() more robust against malicious packets&#xA;syzbot found that slhc_remember() was missing checks against&#xA;malicious packets [1].&#xA;slhc_remember() only checked the size of the packet was at least 20,&#xA;which is not good enough.&#xA;We need to make sure the packet includes the IPv4 and TCP header&#xA;that are supposed to be carried.&#xA;Add iph and th pointers to make the code more readable.&#xA;[1]&#xA;BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666&#xA;  slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666&#xA;  ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455&#xA;  ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]&#xA;  ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212&#xA;  ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327&#xA;  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379&#xA;  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113&#xA;  __release_sock+0x1da/0x330 net/core/sock.c:3072&#xA;  release_sock+0x6b/0x250 net/core/sock.c:3626&#xA;  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903&#xA;  sock_sendmsg_nosec net/socket.c:729 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:744&#xA;  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602&#xA;  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656&#xA;  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742&#xA;  __do_sys_sendmmsg net/socket.c:2771 [inline]&#xA;  __se_sys_sendmmsg net/socket.c:2768 [inline]&#xA;  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768&#xA;  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:4091 [inline]&#xA;  slab_alloc_node mm/slub.c:4134 [inline]&#xA;  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587&#xA;  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678&#xA;  alloc_skb include/linux/skbuff.h:1322 [inline]&#xA;  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732&#xA;  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867&#xA;  sock_sendmsg_nosec net/socket.c:729 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:744&#xA;  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602&#xA;  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656&#xA;  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742&#xA;  __do_sys_sendmmsg net/socket.c:2771 [inline]&#xA;  __se_sys_sendmmsg net/socket.c:2768 [inline]&#xA;  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768&#xA;  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;CVE-2024-50063:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Prevent tail call between progs attached to different hooks&#xA;bpf progs can be attached to kernel functions, and the attached functions&#xA;can take different parameters or return different return values. If&#xA;prog attached to one kernel function tail calls prog attached to another&#xA;kernel function, the ctx access or return value verification could be&#xA;bypassed.&#xA;For example, if prog1 is attached to func1 which takes only 1 parameter&#xA;and prog2 is attached to func2 which takes two parameters. Since verifier&#xA;assumes the bpf ctx passed to prog2 is constructed based on func2&#39;s&#xA;prototype, verifier allows prog2 to access the second parameter from&#xA;the bpf ctx passed to it. The problem is that verifier does not prevent&#xA;prog1 from passing its bpf ctx to prog2 via tail call. In this case,&#xA;the bpf ctx passed to prog2 is constructed from func1 instead of func2,&#xA;that is, the assumption for ctx access verification is bypassed.&#xA;Another example, if BPF LSM prog1 is attached to hook file_alloc_security,&#xA;and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier&#xA;knows the return value rules for these two hooks, e.g. it is legal for&#xA;bpf_lsm_audit_rule_known to return positive number 1, and it is illegal&#xA;for file_alloc_security to return positive number. So verifier allows&#xA;prog2 to return positive number 1, but does not allow prog1 to return&#xA;positive number. The problem is that verifier does not prevent prog1&#xA;from calling prog2 via tail call. In this case, prog2&#39;s return value 1&#xA;will be used as the return value for prog1&#39;s hook file_alloc_security.&#xA;That is, the return value rule is bypassed.&#xA;This patch adds restriction for tail call to prevent such bypasses.&#xA;CVE-2022-49004:In the Linux kernel, the following vulnerability has been resolved:&#xA;riscv: Sync efi page table&#39;s kernel mappings before switching&#xA;The EFI page table is initially created as a copy of the kernel page table.&#xA;With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:&#xA;if the stack is allocated in a new PGD (one that was not present at the&#xA;moment of the efi page table creation or not synced in a previous vmalloc&#xA;fault), the kernel will take a trap when switching to the efi page table&#xA;when the vmalloc kernel stack is accessed, resulting in a kernel panic.&#xA;Fix that by updating the efi kernel mappings before switching to the efi&#xA;page table.&#xA;CVE-2022-48975:In the Linux kernel, the following vulnerability has been resolved:&#xA;gpiolib: fix memory leak in gpiochip_setup_dev()&#xA;Here is a backtrace report about memory leak detected in&#xA;gpiochip_setup_dev():&#xA;unreferenced object 0xffff88810b406400 (size 512):&#xA;  comm &#34;python3&#34;, pid 1682, jiffies 4295346908 (age 24.090s)&#xA;  backtrace:&#xA;    kmalloc_trace&#xA;    device_add&#x9;&#x9;device_private_init at drivers/base/core.c:3361&#xA;&#x9;&#x9;&#x9;(inlined by) device_add at drivers/base/core.c:3411&#xA;    cdev_device_add&#xA;    gpiolib_cdev_register&#xA;    gpiochip_setup_dev&#xA;    gpiochip_add_data_with_key&#xA;gcdev_register() &amp; gcdev_unregister() would call device_add() &amp;&#xA;device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to&#xA;register/unregister device.&#xA;However, if device_add() succeeds, some resource (like&#xA;struct device_private allocated by device_private_init())&#xA;is not released by device_del().&#xA;Therefore, after device_add() succeeds by gcdev_register(), it&#xA;needs to call put_device() to release resource in the error handle&#xA;path.&#xA;Here we move forward the register of release function, and let it&#xA;release every piece of resource by put_device() instead of kfree().&#xA;While at it, fix another subtle issue, i.e. when gc-&gt;ngpio is equal&#xA;to 0, we still call kcalloc() and, in case of further error, kfree()&#xA;on the ZERO_PTR pointer, which is not NULL. It&#39;s not a bug per se,&#xA;but rather waste of the resources and potentially wrong expectation&#xA;about contents of the gdev-&gt;descs variable.&#xA;CVE-2022-48982:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: Fix crash when replugging CSR fake controllers&#xA;It seems fake CSR 5.0 clones can cause the suspend notifier to be&#xA;registered twice causing the following kernel panic:&#xA;[   71.986122] Call Trace:&#xA;[   71.986124]  &lt;TASK&gt;&#xA;[   71.986125]  blocking_notifier_chain_register+0x33/0x60&#xA;[   71.986130]  hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da]&#xA;[   71.986154]  btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477]&#xA;[   71.986159]  ? __pm_runtime_set_status+0x1a9/0x300&#xA;[   71.986162]  ? ktime_get_mono_fast_ns+0x3e/0x90&#xA;[   71.986167]  usb_probe_interface+0xe3/0x2b0&#xA;[   71.986171]  really_probe+0xdb/0x380&#xA;[   71.986174]  ? pm_runtime_barrier+0x54/0x90&#xA;[   71.986177]  __driver_probe_device+0x78/0x170&#xA;[   71.986180]  driver_probe_device+0x1f/0x90&#xA;[   71.986183]  __device_attach_driver+0x89/0x110&#xA;[   71.986186]  ? driver_allows_async_probing+0x70/0x70&#xA;[   71.986189]  bus_for_each_drv+0x8c/0xe0&#xA;[   71.986192]  __device_attach+0xb2/0x1e0&#xA;[   71.986195]  bus_probe_device+0x92/0xb0&#xA;[   71.986198]  device_add+0x422/0x9a0&#xA;[   71.986201]  ? sysfs_merge_group+0xd4/0x110&#xA;[   71.986205]  usb_set_configuration+0x57a/0x820&#xA;[   71.986208]  usb_generic_driver_probe+0x4f/0x70&#xA;[   71.986211]  usb_probe_device+0x3a/0x110&#xA;[   71.986213]  really_probe+0xdb/0x380&#xA;[   71.986216]  ? pm_runtime_barrier+0x54/0x90&#xA;[   71.986219]  __driver_probe_device+0x78/0x170&#xA;[   71.986221]  driver_probe_device+0x1f/0x90&#xA;[   71.986224]  __device_attach_driver+0x89/0x110&#xA;[   71.986227]  ? driver_allows_async_probing+0x70/0x70&#xA;[   71.986230]  bus_for_each_drv+0x8c/0xe0&#xA;[   71.986232]  __device_attach+0xb2/0x1e0&#xA;[   71.986235]  bus_probe_device+0x92/0xb0&#xA;[   71.986237]  device_add+0x422/0x9a0&#xA;[   71.986239]  ? _dev_info+0x7d/0x98&#xA;[   71.986242]  ? blake2s_update+0x4c/0xc0&#xA;[   71.986246]  usb_new_device.cold+0x148/0x36d&#xA;[   71.986250]  hub_event+0xa8a/0x1910&#xA;[   71.986255]  process_one_work+0x1c4/0x380&#xA;[   71.986259]  worker_thread+0x51/0x390&#xA;[   71.986262]  ? rescuer_thread+0x3b0/0x3b0&#xA;[   71.986264]  kthread+0xdb/0x110&#xA;[   71.986266]  ? kthread_complete_and_exit+0x20/0x20&#xA;[   71.986268]  ret_from_fork+0x1f/0x30&#xA;[   71.986273]  &lt;/TASK&gt;&#xA;[   71.986274] ---[ end trace 0000000000000000 ]---&#xA;[   71.986284] btusb: probe of 2-1.6:1.0 failed with error -17&#xA;CVE-2022-48981:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/shmem-helper: Remove errant put in error path&#xA;drm_gem_shmem_mmap() doesn&#39;t own this reference, resulting in the GEM&#xA;object getting prematurely freed leading to a later use-after-free.&#xA;CVE-2022-48972:In the Linux kernel, the following vulnerability has been resolved:&#xA;mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()&#xA;Kernel fault injection test reports null-ptr-deref as follows:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000008&#xA;RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87&#xA; call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944&#xA; unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982&#xA; unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879&#xA; register_netdevice+0x9a8/0xb90 net/core/dev.c:10083&#xA; ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659&#xA; ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229&#xA; mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316&#xA;ieee802154_if_add() allocates wpan_dev as netdev&#39;s private data, but not&#xA;init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage&#xA;the list when device register/unregister, and may lead to null-ptr-deref.&#xA;Use INIT_LIST_HEAD() on it to initialize it correctly.&#xA;CVE-2022-48961:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: mdio: fix unbalanced fwnode reference count in mdio_device_release()&#xA;There is warning report about of_node refcount leak&#xA;while probing mdio device:&#xA;OF: ERROR: memory leak, expected refcount 1 instead of 2,&#xA;of_node_get()/of_node_put() unbalanced - destroy cset entry:&#xA;attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4&#xA;In of_mdiobus_register_device(), we increase fwnode refcount&#xA;by fwnode_handle_get() before associating the of_node with&#xA;mdio device, but it has never been decreased in normal path.&#xA;Since that, in mdio_device_release(), it needs to call&#xA;fwnode_handle_put() in addition instead of calling kfree()&#xA;directly.&#xA;After above, just calling mdio_device_free() in the error handle&#xA;path of of_mdiobus_register_device() is enough to keep the&#xA;refcount balanced.&#xA;CVE-2022-49020:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/9p: Fix a potential socket leak in p9_socket_open&#xA;Both p9_fd_create_tcp() and p9_fd_create_unix() will call&#xA;p9_socket_open(). If the creation of p9_trans_fd fails,&#xA;p9_fd_create_tcp() and p9_fd_create_unix() will return an&#xA;error directly instead of releasing the cscoket, which will&#xA;result in a socket leak.&#xA;This patch adds sock_release() to fix the leak issue.&#xA;CVE-2022-48995:In the Linux kernel, the following vulnerability has been resolved:&#xA;Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()&#xA;There is a kmemleak when test the raydium_i2c_ts with bpf mock device:&#xA;  unreferenced object 0xffff88812d3675a0 (size 8):&#xA;    comm &#34;python3&#34;, pid 349, jiffies 4294741067 (age 95.695s)&#xA;    hex dump (first 8 bytes):&#xA;      11 0e 10 c0 01 00 04 00                          ........&#xA;    backtrace:&#xA;      [&lt;0000000068427125&gt;] __kmalloc+0x46/0x1b0&#xA;      [&lt;0000000090180f91&gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]&#xA;      [&lt;000000006e631aee&gt;] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]&#xA;      [&lt;00000000dc6fcf38&gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]&#xA;      [&lt;00000000a310de16&gt;] i2c_device_probe+0x651/0x680&#xA;      [&lt;00000000f5a96bf3&gt;] really_probe+0x17c/0x3f0&#xA;      [&lt;00000000096ba499&gt;] __driver_probe_device+0xe3/0x170&#xA;      [&lt;00000000c5acb4d9&gt;] driver_probe_device+0x49/0x120&#xA;      [&lt;00000000264fe082&gt;] __device_attach_driver+0xf7/0x150&#xA;      [&lt;00000000f919423c&gt;] bus_for_each_drv+0x114/0x180&#xA;      [&lt;00000000e067feca&gt;] __device_attach+0x1e5/0x2d0&#xA;      [&lt;0000000054301fc2&gt;] bus_probe_device+0x126/0x140&#xA;      [&lt;00000000aad93b22&gt;] device_add+0x810/0x1130&#xA;      [&lt;00000000c086a53f&gt;] i2c_new_client_device+0x352/0x4e0&#xA;      [&lt;000000003c2c248c&gt;] of_i2c_register_device+0xf1/0x110&#xA;      [&lt;00000000ffec4177&gt;] of_i2c_notify+0x100/0x160&#xA;  unreferenced object 0xffff88812d3675c8 (size 8):&#xA;    comm &#34;python3&#34;, pid 349, jiffies 4294741070 (age 95.692s)&#xA;    hex dump (first 8 bytes):&#xA;      22 00 36 2d 81 88 ff ff                          &#34;.6-....&#xA;    backtrace:&#xA;      [&lt;0000000068427125&gt;] __kmalloc+0x46/0x1b0&#xA;      [&lt;0000000090180f91&gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]&#xA;      [&lt;000000001d5c9620&gt;] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]&#xA;      [&lt;00000000dc6fcf38&gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]&#xA;      [&lt;00000000a310de16&gt;] i2c_device_probe+0x651/0x680&#xA;      [&lt;00000000f5a96bf3&gt;] really_probe+0x17c/0x3f0&#xA;      [&lt;00000000096ba499&gt;] __driver_probe_device+0xe3/0x170&#xA;      [&lt;00000000c5acb4d9&gt;] driver_probe_device+0x49/0x120&#xA;      [&lt;00000000264fe082&gt;] __device_attach_driver+0xf7/0x150&#xA;      [&lt;00000000f919423c&gt;] bus_for_each_drv+0x114/0x180&#xA;      [&lt;00000000e067feca&gt;] __device_attach+0x1e5/0x2d0&#xA;      [&lt;0000000054301fc2&gt;] bus_probe_device+0x126/0x140&#xA;      [&lt;00000000aad93b22&gt;] device_add+0x810/0x1130&#xA;      [&lt;00000000c086a53f&gt;] i2c_new_client_device+0x352/0x4e0&#xA;      [&lt;000000003c2c248c&gt;] of_i2c_register_device+0xf1/0x110&#xA;      [&lt;00000000ffec4177&gt;] of_i2c_notify+0x100/0x160&#xA;After BANK_SWITCH command from i2c BUS, no matter success or error&#xA;happened, the tx_buf should be freed.&#xA;CVE-2024-49881:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: update orig_path in ext4_find_extent()&#xA;In ext4_find_extent(), if the path is not big enough, we free it and set&#xA;*orig_path to NULL. But after reallocating and successfully initializing&#xA;the path, we don&#39;t update *orig_path, in which case the caller gets a&#xA;valid path but a NULL ppath, and this may cause a NULL pointer dereference&#xA;or a path memory leak. For example:&#xA;ext4_split_extent&#xA;  path = *ppath = 2000&#xA;  ext4_find_extent&#xA;    if (depth &gt; path[0].p_maxdepth)&#xA;      kfree(path = 2000);&#xA;      *orig_path = path = NULL;&#xA;      path = kcalloc() = 3000&#xA;  ext4_split_extent_at(*ppath = NULL)&#xA;    path = *ppath;&#xA;    ex = path[depth].p_ext;&#xA;    // NULL pointer dereference!&#xA;==================================================================&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000010&#xA;CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847&#xA;RIP: 0010:ext4_split_extent_at+0x6d/0x560&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ext4_split_extent.isra.0+0xcb/0x1b0&#xA; ext4_ext_convert_to_initialized+0x168/0x6c0&#xA; ext4_ext_handle_unwritten_extents+0x325/0x4d0&#xA; ext4_ext_map_blocks+0x520/0xdb0&#xA; ext4_map_blocks+0x2b0/0x690&#xA; ext4_iomap_begin+0x20e/0x2c0&#xA;[...]&#xA;==================================================================&#xA;Therefore, *orig_path is updated when the extent lookup succeeds, so that&#xA;the caller can safely use path or *ppath.&#xA;CVE-2024-50067:In the Linux kernel, the following vulnerability has been resolved:&#xA;uprobe: avoid out-of-bounds memory access of fetching args&#xA;Uprobe needs to fetch args into a percpu buffer, and then copy to ring&#xA;buffer to avoid non-atomic context problem.&#xA;Sometimes user-space strings, arrays can be very large, but the size of&#xA;percpu buffer is only page size. And store_trace_args() won&#39;t check&#xA;whether these data exceeds a single page or not, caused out-of-bounds&#xA;memory access.&#xA;It could be reproduced by following steps:&#xA;1. build kernel with CONFIG_KASAN enabled&#xA;2. save follow program as test.c&#xA;```&#xA;\#include &lt;stdio.h&gt;&#xA;\#include &lt;stdlib.h&gt;&#xA;\#include &lt;string.h&gt;&#xA;// If string length large than MAX_STRING_SIZE, the fetch_store_strlen()&#xA;// will return 0, cause __get_data_size() return shorter size, and&#xA;// store_trace_args() will not trigger out-of-bounds access.&#xA;// So make string length less than 4096.&#xA;\#define STRLEN 4093&#xA;void generate_string(char *str, int n)&#xA;{&#xA;    int i;&#xA;    for (i = 0; i &lt; n; ++i)&#xA;    {&#xA;        char c = i % 26 + &#39;a&#39;;&#xA;        str[i] = c;&#xA;    }&#xA;    str[n-1] = &#39;\0&#39;;&#xA;}&#xA;void print_string(char *str)&#xA;{&#xA;    printf(&#34;%s\n&#34;, str);&#xA;}&#xA;int main()&#xA;{&#xA;    char tmp[STRLEN];&#xA;    generate_string(tmp, STRLEN);&#xA;    print_string(tmp);&#xA;    return 0;&#xA;}&#xA;```&#xA;3. compile program&#xA;`gcc -o test test.c`&#xA;4. get the offset of `print_string()`&#xA;```&#xA;objdump -t test | grep -w print_string&#xA;0000000000401199 g     F .text  000000000000001b              print_string&#xA;```&#xA;5. configure uprobe with offset 0x1199&#xA;```&#xA;off=0x1199&#xA;cd /sys/kernel/debug/tracing/&#xA;echo &#34;p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring&#34;&#xA; &gt; uprobe_events&#xA;echo 1 &gt; events/uprobes/enable&#xA;echo 1 &gt; tracing_on&#xA;```&#xA;6. run `test`, and kasan will report error.&#xA;==================================================================&#xA;BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0&#xA;Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18&#xA;Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x55/0x70&#xA; print_address_description.constprop.0+0x27/0x310&#xA; kasan_report+0x10f/0x120&#xA; ? strncpy_from_user+0x1d6/0x1f0&#xA; strncpy_from_user+0x1d6/0x1f0&#xA; ? rmqueue.constprop.0+0x70d/0x2ad0&#xA; process_fetch_insn+0xb26/0x1470&#xA; ? __pfx_process_fetch_insn+0x10/0x10&#xA; ? _raw_spin_lock+0x85/0xe0&#xA; ? __pfx__raw_spin_lock+0x10/0x10&#xA; ? __pte_offset_map+0x1f/0x2d0&#xA; ? unwind_next_frame+0xc5f/0x1f80&#xA; ? arch_stack_walk+0x68/0xf0&#xA; ? is_bpf_text_address+0x23/0x30&#xA; ? kernel_text_address.part.0+0xbb/0xd0&#xA; ? __kernel_text_address+0x66/0xb0&#xA; ? unwind_get_return_address+0x5e/0xa0&#xA; ? __pfx_stack_trace_consume_entry+0x10/0x10&#xA; ? arch_stack_walk+0xa2/0xf0&#xA; ? _raw_spin_lock_irqsave+0x8b/0xf0&#xA; ? __pfx__raw_spin_lock_irqsave+0x10/0x10&#xA; ? depot_alloc_stack+0x4c/0x1f0&#xA; ? _raw_spin_unlock_irqrestore+0xe/0x30&#xA; ? stack_depot_save_flags+0x35d/0x4f0&#xA; ? kasan_save_stack+0x34/0x50&#xA; ? kasan_save_stack+0x24/0x50&#xA; ? mutex_lock+0x91/0xe0&#xA; ? __pfx_mutex_lock+0x10/0x10&#xA; prepare_uprobe_buffer.part.0+0x2cd/0x500&#xA; uprobe_dispatcher+0x2c3/0x6a0&#xA; ? __pfx_uprobe_dispatcher+0x10/0x10&#xA; ? __kasan_slab_alloc+0x4d/0x90&#xA; handler_chain+0xdd/0x3e0&#xA; handle_swbp+0x26e/0x3d0&#xA; ? __pfx_handle_swbp+0x10/0x10&#xA; ? uprobe_pre_sstep_notifier+0x151/0x1b0&#xA; irqentry_exit_to_user_mode+0xe2/0x1b0&#xA; asm_exc_int3+0x39/0x40&#xA;RIP: 0033:0x401199&#xA;Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce&#xA;RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206&#xA;RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2&#xA;RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0&#xA;RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20&#xA;R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040&#xA;R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000&#xA; &lt;/TASK&gt;&#xA;This commit enforces the buffer&#39;s maxlen less than a page-size to avoid&#xA;store_trace_args() out-of-memory access.&#xA;CVE-2024-50083:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp: fix mptcp DSS corruption due to large pmtu xmit&#xA;Syzkaller was able to trigger a DSS corruption:&#xA;  TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695&#xA;  Modules linked in:&#xA;  CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0&#xA;  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;  RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695&#xA;  Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 &lt;0f&gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff&#xA;  RSP: 0018:ffffc90000006db8 EFLAGS: 00010246&#xA;  RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00&#xA;  RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0&#xA;  RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8&#xA;  R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000&#xA;  R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5&#xA;  FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0&#xA;  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   move_skbs_to_msk net/mptcp/protocol.c:811 [inline]&#xA;   mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854&#xA;   subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490&#xA;   tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283&#xA;   tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237&#xA;   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915&#xA;   tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350&#xA;   ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205&#xA;   ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233&#xA;   NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314&#xA;   NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314&#xA;   __netif_receive_skb_one_core net/core/dev.c:5662 [inline]&#xA;   __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775&#xA;   process_backlog+0x662/0x15b0 net/core/dev.c:6107&#xA;   __napi_poll+0xcb/0x490 net/core/dev.c:6771&#xA;   napi_poll net/core/dev.c:6840 [inline]&#xA;   net_rx_action+0x89b/0x1240 net/core/dev.c:6962&#xA;   handle_softirqs+0x2c5/0x980 kernel/softirq.c:554&#xA;   do_softirq+0x11b/0x1e0 kernel/softirq.c:455&#xA;   &lt;/IRQ&gt;&#xA;   &lt;TASK&gt;&#xA;   __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382&#xA;   local_bh_enable include/linux/bottom_half.h:33 [inline]&#xA;   rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]&#xA;   __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451&#xA;   dev_queue_xmit include/linux/netdevice.h:3094 [inline]&#xA;   neigh_hh_output include/net/neighbour.h:526 [inline]&#xA;   neigh_output include/net/neighbour.h:540 [inline]&#xA;   ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236&#xA;   ip_local_out net/ipv4/ip_output.c:130 [inline]&#xA;   __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536&#xA;   __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466&#xA;   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]&#xA;   tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]&#xA;   tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752&#xA;   __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015&#xA;   tcp_push_pending_frames include/net/tcp.h:2107 [inline]&#xA;   tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]&#xA;   tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239&#xA;   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915&#xA;   sk_backlog_rcv include/net/sock.h:1113 [inline]&#xA;   __release_sock+0x214/0x350 net/core/sock.c:3072&#xA;   release_sock+0x61/0x1f0 net/core/sock.c:3626&#xA;   mptcp_push_&#xA;---truncated---&#xA;CVE-2024-46685:In the Linux kernel, the following vulnerability has been resolved:&#xA;pinctrl: single: fix potential NULL dereference in pcs_get_function()&#xA;pinmux_generic_get_function() can return NULL and the pointer &#39;function&#39;&#xA;was dereferenced without checking against NULL. Add checking of pointer&#xA;&#39;function&#39; in pcs_get_function().&#xA;Found by code review.&#xA;CVE-2024-46702:In the Linux kernel, the following vulnerability has been resolved:&#xA;thunderbolt: Mark XDomain as unplugged when router is removed&#xA;I noticed that when we do discrete host router NVM upgrade and it gets&#xA;hot-removed from the PCIe side as a result of NVM firmware authentication,&#xA;if there is another host connected with enabled paths we hang in tearing&#xA;them down. This is due to fact that the Thunderbolt networking driver&#xA;also tries to cleanup the paths and ends up blocking in&#xA;tb_disconnect_xdomain_paths() waiting for the domain lock.&#xA;However, at this point we already cleaned the paths in tb_stop() so&#xA;there is really no need for tb_disconnect_xdomain_paths() to do that&#xA;anymore. Furthermore it already checks if the XDomain is unplugged and&#xA;bails out early so take advantage of that and mark the XDomain as&#xA;unplugged when we remove the parent router.&#xA;CVE-2024-46815:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]&#xA;[WHY &amp; HOW]&#xA;num_valid_sets needs to be checked to avoid a negative index when&#xA;accessing reader_wm_sets[num_valid_sets - 1].&#xA;This fixes an OVERRUN issue reported by Coverity.&#xA;CVE-2024-47679:In the Linux kernel, the following vulnerability has been resolved:&#xA;vfs: fix race between evice_inodes() and find_inode()&amp;iput()&#xA;Hi, all&#xA;Recently I noticed a bug[1] in btrfs, after digged it into&#xA;and I believe it&#39;a race in vfs.&#xA;Let&#39;s assume there&#39;s a inode (ie ino 261) with i_count 1 is&#xA;called by iput(), and there&#39;s a concurrent thread calling&#xA;generic_shutdown_super().&#xA;cpu0:                              cpu1:&#xA;iput() // i_count is 1&#xA;  -&gt;spin_lock(inode)&#xA;  -&gt;dec i_count to 0&#xA;  -&gt;iput_final()                    generic_shutdown_super()&#xA;    -&gt;__inode_add_lru()               -&gt;evict_inodes()&#xA;      // cause some reason[2]           -&gt;if (atomic_read(inode-&gt;i_count)) continue;&#xA;      // return before                  // inode 261 passed the above check&#xA;      // list_lru_add_obj()             // and then schedule out&#xA;   -&gt;spin_unlock()&#xA;// note here: the inode 261&#xA;// was still at sb list and hash list,&#xA;// and I_FREEING|I_WILL_FREE was not been set&#xA;btrfs_iget()&#xA;  // after some function calls&#xA;  -&gt;find_inode()&#xA;    // found the above inode 261&#xA;    -&gt;spin_lock(inode)&#xA;   // check I_FREEING|I_WILL_FREE&#xA;   // and passed&#xA;      -&gt;__iget()&#xA;    -&gt;spin_unlock(inode)                // schedule back&#xA;                                        -&gt;spin_lock(inode)&#xA;                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,&#xA;                                        // passed and set I_FREEING&#xA;iput()                                  -&gt;spin_unlock(inode)&#xA;  -&gt;spin_lock(inode)&#x9;&#x9;&#x9;  -&gt;evict()&#xA;  // dec i_count to 0&#xA;  -&gt;iput_final()&#xA;    -&gt;spin_unlock()&#xA;    -&gt;evict()&#xA;Now, we have two threads simultaneously evicting&#xA;the same inode, which may trigger the BUG(inode-&gt;i_state &amp; I_CLEAR)&#xA;statement both within clear_inode() and iput().&#xA;To fix the bug, recheck the inode-&gt;i_count after holding i_lock.&#xA;Because in the most scenarios, the first check is valid, and&#xA;the overhead of spin_lock() can be reduced.&#xA;If there is any misunderstanding, please let me know, thanks.&#xA;[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/&#xA;[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()&#xA;return false when I reproduced the bug.&#xA;CVE-2024-47726:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to wait dio completion&#xA;It should wait all existing dio write IOs before block removal,&#xA;otherwise, previous direct write IO may overwrite data in the&#xA;block which may be reused by other inode.&#xA;CVE-2024-49859:In the Linux kernel, the following vulnerability has been resolved:&#xA;f2fs: fix to check atomic_file in f2fs ioctl interfaces&#xA;Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(),&#xA;f2fs_move_file_range(), and f2fs_defragment_range() missed to&#xA;check atomic_write status, which may cause potential race issue,&#xA;fix it.&#xA;CVE-2024-50002:In the Linux kernel, the following vulnerability has been resolved:&#xA;static_call: Handle module init failure correctly in static_call_del_module()&#xA;Module insertion invokes static_call_add_module() to initialize the static&#xA;calls in a module. static_call_add_module() invokes __static_call_init(),&#xA;which allocates a struct static_call_mod to either encapsulate the built-in&#xA;static call sites of the associated key into it so further modules can be&#xA;added or to append the module to the module chain.&#xA;If that allocation fails the function returns with an error code and the&#xA;module core invokes static_call_del_module() to clean up eventually added&#xA;static_call_mod entries.&#xA;This works correctly, when all keys used by the module were converted over&#xA;to a module chain before the failure. If not then static_call_del_module()&#xA;causes a #GP as it blindly assumes that key::mods points to a valid struct&#xA;static_call_mod.&#xA;The problem is that key::mods is not a individual struct member of struct&#xA;static_call_key, it&#39;s part of a union to save space:&#xA;        union {&#xA;                /* bit 0: 0 = mods, 1 = sites */&#xA;                unsigned long type;&#xA;                struct static_call_mod *mods;&#xA;                struct static_call_site *sites;&#xA;&#x9;};&#xA;key::sites is a pointer to the list of built-in usage sites of the static&#xA;call. The type of the pointer is differentiated by bit 0. A mods pointer&#xA;has the bit clear, the sites pointer has the bit set.&#xA;As static_call_del_module() blidly assumes that the pointer is a valid&#xA;static_call_mod type, it fails to check for this failure case and&#xA;dereferences the pointer to the list of built-in call sites, which is&#xA;obviously bogus.&#xA;Cure it by checking whether the key has a sites or a mods pointer.&#xA;If it&#39;s a sites pointer then the key is not to be touched. As the sites are&#xA;walked in the same order as in __static_call_init() the site walk can be&#xA;terminated because all subsequent sites have not been touched by the init&#xA;code due to the error exit.&#xA;If it was converted before the allocation fail, then the inner loop which&#xA;searches for a module match will find nothing.&#xA;A fail in the second allocation in __static_call_init() is harmless and&#xA;does not require special treatment. The first allocation succeeded and&#xA;converted the key to a module chain. That first entry has mod::mod == NULL&#xA;and mod::next == NULL, so the inner loop of static_call_del_module() will&#xA;neither find a module match nor a module chain. The next site in the walk&#xA;was either already converted, but can&#39;t match the module, or it will exit&#xA;the outer loop because it has a static_call_site pointer and not a&#xA;static_call_mod pointer.&#xA;CVE-2024-49983:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free&#xA;When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),&#xA;the &#39;ppath&#39; is updated but it is the &#39;path&#39; that is freed, thus potentially&#xA;triggering a double-free in the following process:&#xA;ext4_ext_replay_update_ex&#xA;  ppath = path&#xA;  ext4_force_split_extent_at(&amp;ppath)&#xA;    ext4_split_extent_at&#xA;      ext4_ext_insert_extent&#xA;        ext4_ext_create_new_leaf&#xA;          ext4_ext_grow_indepth&#xA;            ext4_find_extent&#xA;              if (depth &gt; path[0].p_maxdepth)&#xA;                kfree(path)                 ---&gt; path First freed&#xA;                *orig_path = path = NULL    ---&gt; null ppath&#xA;  kfree(path)                               ---&gt; path double-free !!!&#xA;So drop the unnecessary ppath and use path directly to avoid this problem.&#xA;And use ext4_find_extent() directly to update path, avoiding unnecessary&#xA;memory allocation and freeing. Also, propagate the error returned by&#xA;ext4_find_extent() instead of using strange error codes.&#xA;CVE-2024-49948:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: add more sanity checks to qdisc_pkt_len_init()&#xA;One path takes care of SKB_GSO_DODGY, assuming&#xA;skb-&gt;len is bigger than hdr_len.&#xA;virtio_net_hdr_to_skb() does not fully dissect TCP headers,&#xA;it only make sure it is at least 20 bytes.&#xA;It is possible for an user to provide a malicious &#39;GSO&#39; packet,&#xA;total length of 80 bytes.&#xA;- 20 bytes of IPv4 header&#xA;- 60 bytes TCP header&#xA;- a small gso_size like 8&#xA;virtio_net_hdr_to_skb() would declare this packet as a normal&#xA;GSO packet, because it would see 40 bytes of payload,&#xA;bigger than gso_size.&#xA;We need to make detect this case to not underflow&#xA;qdisc_skb_cb(skb)-&gt;pkt_len.&#xA;CVE-2024-49896:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check stream before comparing them&#xA;[WHAT &amp; HOW]&#xA;amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is&#xA;necessary to check for null before dereferencing them.&#xA;This fixes 1 FORWARD_NULL issue reported by Coverity.&#xA;CVE-2024-49949:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: avoid potential underflow in qdisc_pkt_len_init() with UFO&#xA;After commit 7c6d2ecbda83 (&#34;net: be more gentle about silly gso&#xA;requests coming from user&#34;) virtio_net_hdr_to_skb() had sanity check&#xA;to detect malicious attempts from user space to cook a bad GSO packet.&#xA;Then commit cf9acc90c80ec (&#34;net: virtio_net_hdr_to_skb: count&#xA;transport header in UFO&#34;) while fixing one issue, allowed user space&#xA;to cook a GSO packet with the following characteristic :&#xA;IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.&#xA;When this packet arrives in qdisc_pkt_len_init(), we end up&#xA;with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len&#xA;Then the following sets gso_segs to 0 :&#xA;gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,&#xA;                        shinfo-&gt;gso_size);&#xA;Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/&#xA;qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;&#xA;This leads to the following crash in fq_codel [1]&#xA;qdisc_pkt_len_init() is best effort, we only want an estimation&#xA;of the bytes sent on the wire, not crashing the kernel.&#xA;This patch is fixing this particular issue, a following one&#xA;adds more sanity checks for another potential bug.&#xA;[1]&#xA;[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[   70.724561] #PF: supervisor read access in kernel mode&#xA;[   70.724561] #PF: error_code(0x0000) - not-present page&#xA;[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0&#xA;[   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI&#xA;[   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991&#xA;[   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel&#xA;[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 &lt;49&gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49&#xA;All code&#xA;========&#xA;   0:&#x9;24 08                &#x9;and    $0x8,%al&#xA;   2:&#x9;49 c1 e1 06          &#x9;shl    $0x6,%r9&#xA;   6:&#x9;44 89 7c 24 18       &#x9;mov    %r15d,0x18(%rsp)&#xA;   b:&#x9;45 31 ed             &#x9;xor    %r13d,%r13d&#xA;   e:&#x9;45 31 c0             &#x9;xor    %r8d,%r8d&#xA;  11:&#x9;31 ff                &#x9;xor    %edi,%edi&#xA;  13:&#x9;89 44 24 14          &#x9;mov    %eax,0x14(%rsp)&#xA;  17:&#x9;4c 03 8b 90 01 00 00 &#x9;add    0x190(%rbx),%r9&#xA;  1e:&#x9;eb 04                &#x9;jmp    0x24&#xA;  20:&#x9;39 ca                &#x9;cmp    %ecx,%edx&#xA;  22:&#x9;73 37                &#x9;jae    0x5b&#xA;  24:&#x9;4d 8b 39             &#x9;mov    (%r9),%r15&#xA;  27:&#x9;83 c7 01             &#x9;add    $0x1,%edi&#xA;  2a:*&#x9;49 8b 17             &#x9;mov    (%r15),%rdx&#x9;&#x9;&lt;-- trapping instruction&#xA;  2d:&#x9;49 89 11             &#x9;mov    %rdx,(%r9)&#xA;  30:&#x9;41 8b 57 28          &#x9;mov    0x28(%r15),%edx&#xA;  34:&#x9;45 8b 5f 34          &#x9;mov    0x34(%r15),%r11d&#xA;  38:&#x9;49 c7 07 00 00 00 00 &#x9;movq   $0x0,(%r15)&#xA;  3f:&#x9;49                   &#x9;rex.WB&#xA;Code starting with the faulting instruction&#xA;===========================================&#xA;   0:&#x9;49 8b 17             &#x9;mov    (%r15),%rdx&#xA;   3:&#x9;49 89 11             &#x9;mov    %rdx,(%r9)&#xA;   6:&#x9;41 8b 57 28          &#x9;mov    0x28(%r15),%edx&#xA;   a:&#x9;45 8b 5f 34          &#x9;mov    0x34(%r15),%r11d&#xA;   e:&#x9;49 c7 07 00 00 00 00 &#x9;movq   $0x0,(%r15)&#xA;  15:&#x9;49                   &#x9;rex.WB&#xA;[   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202&#xA;[   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000&#xA;[   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001&#xA;[   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000&#xA;[   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58&#xA;[   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000&#xA;[   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000&#xA;[   70.724561] CS:  0010 DS: 0000 ES: 0000 C&#xA;---truncated---&#xA;CVE-2024-50013:In the Linux kernel, the following vulnerability has been resolved:&#xA;exfat: fix memory leak in exfat_load_bitmap()&#xA;If the first directory entry in the root directory is not a bitmap&#xA;directory entry, &#39;bh&#39; will not be released and reassigned, which&#xA;will cause a memory leak.&#xA;CVE-2024-50006:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix i_data_sem unlock order in ext4_ind_migrate()&#xA;Fuzzing reports a possible deadlock in jbd2_log_wait_commit.&#xA;This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require&#xA;synchronous updates because the file descriptor is opened with O_SYNC.&#xA;This can lead to the jbd2_journal_stop() function calling&#xA;jbd2_might_wait_for_commit(), potentially causing a deadlock if the&#xA;EXT4_IOC_MIGRATE call races with a write(2) system call.&#xA;This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this&#xA;case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the&#xA;jbd2_journal_stop function while i_data_sem is locked. This triggers&#xA;lockdep because the jbd2_journal_start function might also lock the same&#xA;jbd2_handle simultaneously.&#xA;Found by Linux Verification Center (linuxtesting.org) with syzkaller.&#xA;Rule: add&#xA;CVE-2024-50014:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix access to uninitialised lock in fc replay path&#xA;The following kernel trace can be triggered with fstest generic/629 when&#xA;executed against a filesystem with fast-commit feature enabled:&#xA;INFO: trying to register non-static key.&#xA;The code is fine but needs lockdep annotation, or maybe&#xA;you didn&#39;t initialize this object before use?&#xA;turning off the locking correctness validator.&#xA;CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x66/0x90&#xA; register_lock_class+0x759/0x7d0&#xA; __lock_acquire+0x85/0x2630&#xA; ? __find_get_block+0xb4/0x380&#xA; lock_acquire+0xd1/0x2d0&#xA; ? __ext4_journal_get_write_access+0xd5/0x160&#xA; _raw_spin_lock+0x33/0x40&#xA; ? __ext4_journal_get_write_access+0xd5/0x160&#xA; __ext4_journal_get_write_access+0xd5/0x160&#xA; ext4_reserve_inode_write+0x61/0xb0&#xA; __ext4_mark_inode_dirty+0x79/0x270&#xA; ? ext4_ext_replay_set_iblocks+0x2f8/0x450&#xA; ext4_ext_replay_set_iblocks+0x330/0x450&#xA; ext4_fc_replay+0x14c8/0x1540&#xA; ? jread+0x88/0x2e0&#xA; ? rcu_is_watching+0x11/0x40&#xA; do_one_pass+0x447/0xd00&#xA; jbd2_journal_recover+0x139/0x1b0&#xA; jbd2_journal_load+0x96/0x390&#xA; ext4_load_and_init_journal+0x253/0xd40&#xA; ext4_fill_super+0x2cc6/0x3180&#xA;...&#xA;In the replay path there&#39;s an attempt to lock sbi-&gt;s_bdev_wb_lock in&#xA;function ext4_check_bdev_write_error().  Unfortunately, at this point this&#xA;spinlock has not been initialized yet.  Moving it&#39;s initialization to an&#xA;earlier point in __ext4_fill_super() fixes this splat.&#xA;CVE-2024-49967:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: no need to continue when the number of entries is 1&#xA;CVE-2024-49878:In the Linux kernel, the following vulnerability has been resolved:&#xA;resource: fix region_intersects() vs add_memory_driver_managed()&#xA;On a system with CXL memory, the resource tree (/proc/iomem) related to&#xA;CXL memory may look like something as follows.&#xA;490000000-50fffffff : CXL Window 0&#xA;  490000000-50fffffff : region0&#xA;    490000000-50fffffff : dax0.0&#xA;      490000000-50fffffff : System RAM (kmem)&#xA;Because drivers/dax/kmem.c calls add_memory_driver_managed() during&#xA;onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL&#xA;Window X&#34;.  This confuses region_intersects(), which expects all &#34;System&#xA;RAM&#34; resources to be at the top level of iomem_resource.  This can lead to&#xA;bugs.&#xA;For example, when the following command line is executed to write some&#xA;memory in CXL memory range via /dev/mem,&#xA; $ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1&#xA; dd: error writing &#39;/dev/mem&#39;: Bad address&#xA; 1+0 records in&#xA; 0+0 records out&#xA; 0 bytes copied, 0.0283507 s, 0.0 kB/s&#xA;the command fails as expected.  However, the error code is wrong.  It&#xA;should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;.  More&#xA;seriously, the /dev/mem permission checking in devmem_is_allowed() passes&#xA;incorrectly.  Although the accessing is prevented later because ioremap()&#xA;isn&#39;t allowed to map system RAM, it is a potential security issue.  During&#xA;command executing, the following warning is reported in the kernel log for&#xA;calling ioremap() on system RAM.&#xA; ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff&#xA; WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d&#xA; Call Trace:&#xA;  memremap+0xcb/0x184&#xA;  xlate_dev_mem_ptr+0x25/0x2f&#xA;  write_mem+0x94/0xfb&#xA;  vfs_write+0x128/0x26d&#xA;  ksys_write+0xac/0xfe&#xA;  do_syscall_64+0x9a/0xfd&#xA;  entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;The details of command execution process are as follows.  In the above&#xA;resource tree, &#34;System RAM&#34; is a descendant of &#34;CXL Window 0&#34; instead of a&#xA;top level resource.  So, region_intersects() will report no System RAM&#xA;resources in the CXL memory region incorrectly, because it only checks the&#xA;top level resources.  Consequently, devmem_is_allowed() will return 1&#xA;(allow access via /dev/mem) for CXL memory region incorrectly. &#xA;Fortunately, ioremap() doesn&#39;t allow to map System RAM and reject the&#xA;access.&#xA;So, region_intersects() needs to be fixed to work correctly with the&#xA;resource tree with &#34;System RAM&#34; not at top level as above.  To fix it, if&#xA;we found a unmatched resource in the top level, we will continue to search&#xA;matched resources in its descendant resources.  So, we will not miss any&#xA;matched resources in resource tree anymore.&#xA;In the new implementation, an example resource tree&#xA;|------------- &#34;CXL Window 0&#34; ------------|&#xA;|-- &#34;System RAM&#34; --|&#xA;will behave similar as the following fake resource tree for&#xA;region_intersects(, IORESOURCE_SYSTEM_RAM, ),&#xA;|-- &#34;System RAM&#34; --||-- &#34;CXL Window 0a&#34; --|&#xA;Where &#34;CXL Window 0a&#34; is part of the original &#34;CXL Window 0&#34; that&#xA;isn&#39;t covered by &#34;System RAM&#34;.&#xA;CVE-2024-49960:In the Linux kernel, the following vulnerability has been resolved:&#xA;ext4: fix timer use-after-free on failed mount&#xA;Syzbot has found an ODEBUG bug in ext4_fill_super&#xA;The del_timer_sync function cancels the s_err_report timer,&#xA;which reminds about filesystem errors daily. We should&#xA;guarantee the timer is no longer active before kfree(sbi).&#xA;When filesystem mounting fails, the flow goes to failed_mount3,&#xA;where an error occurs when ext4_stop_mmpd is called, causing&#xA;a read I/O failure. This triggers the ext4_handle_error function&#xA;that ultimately re-arms the timer,&#xA;leaving the s_err_report timer active before kfree(sbi) is called.&#xA;Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.&#xA;CVE-2024-50082:In the Linux kernel, the following vulnerability has been resolved:&#xA;blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race&#xA;We&#39;re seeing crashes from rq_qos_wake_function that look like this:&#xA;  BUG: unable to handle page fault for address: ffffafe180a40084&#xA;  #PF: supervisor write access in kernel mode&#xA;  #PF: error_code(0x0002) - not-present page&#xA;  PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0&#xA;  Oops: Oops: 0002 [#1] PREEMPT SMP PTI&#xA;  CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;  RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40&#xA;  Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 &lt;f0&gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00&#xA;  RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046&#xA;  RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011&#xA;  RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084&#xA;  RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011&#xA;  R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002&#xA;  R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003&#xA;  FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0&#xA;  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;  PKRU: 55555554&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   try_to_wake_up+0x5a/0x6a0&#xA;   rq_qos_wake_function+0x71/0x80&#xA;   __wake_up_common+0x75/0xa0&#xA;   __wake_up+0x36/0x60&#xA;   scale_up.part.0+0x50/0x110&#xA;   wb_timer_fn+0x227/0x450&#xA;   ...&#xA;So rq_qos_wake_function() calls wake_up_process(data-&gt;task), which calls&#xA;try_to_wake_up(), which faults in raw_spin_lock_irqsave(&amp;p-&gt;pi_lock).&#xA;p comes from data-&gt;task, and data comes from the waitqueue entry, which&#xA;is stored on the waiter&#39;s stack in rq_qos_wait(). Analyzing the core&#xA;dump with drgn, I found that the waiter had already woken up and moved&#xA;on to a completely unrelated code path, clobbering what was previously&#xA;data-&gt;task. Meanwhile, the waker was passing the clobbered garbage in&#xA;data-&gt;task to wake_up_process(), leading to the crash.&#xA;What&#39;s happening is that in between rq_qos_wake_function() deleting the&#xA;waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding&#xA;that it already got a token and returning. The race looks like this:&#xA;rq_qos_wait()                           rq_qos_wake_function()&#xA;==============================================================&#xA;prepare_to_wait_exclusive()&#xA;                                        data-&gt;got_token = true;&#xA;                                        list_del_init(&amp;curr-&gt;entry);&#xA;if (data.got_token)&#xA;        break;&#xA;finish_wait(&amp;rqw-&gt;wait, &amp;data.wq);&#xA;  ^- returns immediately because&#xA;     list_empty_careful(&amp;wq_entry-&gt;entry)&#xA;     is true&#xA;... return, go do something else ...&#xA;                                        wake_up_process(data-&gt;task)&#xA;                                          (NO LONGER VALID!)-^&#xA;Normally, finish_wait() is supposed to synchronize against the waker.&#xA;But, as noted above, it is returning immediately because the waitqueue&#xA;entry has already been removed from the waitqueue.&#xA;The bug is that rq_qos_wake_function() is accessing the waitqueue entry&#xA;AFTER deleting it. Note that autoremove_wake_function() wakes the waiter&#xA;and THEN deletes the waitqueue entry, which is the proper order.&#xA;Fix it by swapping the order. We also need to use&#xA;list_del_init_careful() to match the list_empty_careful() in&#xA;finish_wait().&#xA;CVE-2024-50095:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/mad: Improve handling of timed out WRs of mad agent&#xA;Current timeout handler of mad agent acquires/releases mad_agent_priv&#xA;lock for every timed out WRs. This causes heavy locking contention&#xA;when higher no. of WRs are to be handled inside timeout handler.&#xA;This leads to softlockup with below trace in some use cases where&#xA;rdma-cm path is used to establish connection between peer nodes&#xA;Trace:&#xA;-----&#xA; BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]&#xA; CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE&#xA;     -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1&#xA; Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019&#xA; Workqueue: ib_mad1 timeout_sends [ib_core]&#xA; RIP: 0010:__do_softirq+0x78/0x2ac&#xA; RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246&#xA; RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f&#xA; RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b&#xA; RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000&#xA; R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000&#xA; R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040&#xA; FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; PKRU: 55555554&#xA; Call Trace:&#xA;  &lt;IRQ&gt;&#xA;  ? show_trace_log_lvl+0x1c4/0x2df&#xA;  ? show_trace_log_lvl+0x1c4/0x2df&#xA;  ? __irq_exit_rcu+0xa1/0xc0&#xA;  ? watchdog_timer_fn+0x1b2/0x210&#xA;  ? __pfx_watchdog_timer_fn+0x10/0x10&#xA;  ? __hrtimer_run_queues+0x127/0x2c0&#xA;  ? hrtimer_interrupt+0xfc/0x210&#xA;  ? __sysvec_apic_timer_interrupt+0x5c/0x110&#xA;  ? sysvec_apic_timer_interrupt+0x37/0x90&#xA;  ? asm_sysvec_apic_timer_interrupt+0x16/0x20&#xA;  ? __do_softirq+0x78/0x2ac&#xA;  ? __do_softirq+0x60/0x2ac&#xA;  __irq_exit_rcu+0xa1/0xc0&#xA;  sysvec_call_function_single+0x72/0x90&#xA;  &lt;/IRQ&gt;&#xA;  &lt;TASK&gt;&#xA;  asm_sysvec_call_function_single+0x16/0x20&#xA; RIP: 0010:_raw_spin_unlock_irq+0x14/0x30&#xA; RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247&#xA; RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800&#xA; RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c&#xA; RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000&#xA; R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538&#xA; R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c&#xA;  cm_process_send_error+0x122/0x1d0 [ib_cm]&#xA;  timeout_sends+0x1dd/0x270 [ib_core]&#xA;  process_one_work+0x1e2/0x3b0&#xA;  ? __pfx_worker_thread+0x10/0x10&#xA;  worker_thread+0x50/0x3a0&#xA;  ? __pfx_worker_thread+0x10/0x10&#xA;  kthread+0xdd/0x100&#xA;  ? __pfx_kthread+0x10/0x10&#xA;  ret_from_fork+0x29/0x50&#xA;  &lt;/TASK&gt;&#xA;Simplified timeout handler by creating local list of timed out WRs&#xA;and invoke send handler post creating the list. The new method acquires/&#xA;releases lock once to fetch the list and hence helps to reduce locking&#xA;contetiong when processing higher no. of WRs&#xA;CVE-2024-50133:In the Linux kernel, the following vulnerability has been resolved:&#xA;LoongArch: Don&#39;t crash in stack_top() for tasks without vDSO&#xA;Not all tasks have a vDSO mapped, for example kthreads never do. If such&#xA;a task ever ends up calling stack_top(), it will derefence the NULL vdso&#xA;pointer and crash.&#xA;This can for example happen when using kunit:&#xA;&#x9;[&lt;9000000000203874&gt;] stack_top+0x58/0xa8&#xA;&#x9;[&lt;90000000002956cc&gt;] arch_pick_mmap_layout+0x164/0x220&#xA;&#x9;[&lt;90000000003c284c&gt;] kunit_vm_mmap_init+0x108/0x12c&#xA;&#x9;[&lt;90000000003c1fbc&gt;] __kunit_add_resource+0x38/0x8c&#xA;&#x9;[&lt;90000000003c2704&gt;] kunit_vm_mmap+0x88/0xc8&#xA;&#x9;[&lt;9000000000410b14&gt;] usercopy_test_init+0xbc/0x25c&#xA;&#x9;[&lt;90000000003c1db4&gt;] kunit_try_run_case+0x5c/0x184&#xA;&#x9;[&lt;90000000003c3d54&gt;] kunit_generic_run_threadfn_adapter+0x24/0x48&#xA;&#x9;[&lt;900000000022e4bc&gt;] kthread+0xc8/0xd4&#xA;&#x9;[&lt;9000000000200ce8&gt;] ret_from_kernel_thread+0xc/0xa4&#xA;CVE-2024-50131:In the Linux kernel, the following vulnerability has been resolved:&#xA;tracing: Consider the NULL character when validating the event length&#xA;strlen() returns a string length excluding the null byte. If the string&#xA;length equals to the maximum buffer length, the buffer will have no&#xA;space for the NULL terminating character.&#xA;This commit checks this condition and returns failure for it.&#xA;CVE-2024-50154:In the Linux kernel, the following vulnerability has been resolved:&#xA;tcp/dccp: Don&#39;t use timer_pending() in reqsk_queue_unlink().&#xA;Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().&#xA;  &#34;&#34;&#34;&#xA;  We are seeing a use-after-free from a bpf prog attached to&#xA;  trace_tcp_retransmit_synack. The program passes the req-&gt;sk to the&#xA;  bpf_sk_storage_get_tracing kernel helper which does check for null&#xA;  before using it.&#xA;  &#34;&#34;&#34;&#xA;The commit 83fccfc3940c (&#34;inet: fix potential deadlock in&#xA;reqsk_queue_unlink()&#34;) added timer_pending() in reqsk_queue_unlink() not&#xA;to call del_timer_sync() from reqsk_timer_handler(), but it introduced a&#xA;small race window.&#xA;Before the timer is called, expire_timers() calls detach_timer(timer, true)&#xA;to clear timer-&gt;entry.pprev and marks it as not pending.&#xA;If reqsk_queue_unlink() checks timer_pending() just after expire_timers()&#xA;calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will&#xA;continue running and send multiple SYN+ACKs until it expires.&#xA;The reported UAF could happen if req-&gt;sk is close()d earlier than the timer&#xA;expiration, which is 63s by default.&#xA;The scenario would be&#xA;  1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),&#xA;     but del_timer_sync() is missed&#xA;  2. reqsk timer is executed and scheduled again&#xA;  3. req-&gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but&#xA;     reqsk timer still has another one, and inet_csk_accept() does not&#xA;     clear req-&gt;sk for non-TFO sockets&#xA;  4. sk is close()d&#xA;  5. reqsk timer is executed again, and BPF touches req-&gt;sk&#xA;Let&#39;s not use timer_pending() by passing the caller context to&#xA;__inet_csk_reqsk_queue_drop().&#xA;Note that reqsk timer is pinned, so the issue does not happen in most&#xA;use cases. [1]&#xA;[0]&#xA;BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0&#xA;Use-after-free read at 0x00000000a891fb3a (in kfence-#1):&#xA;bpf_sk_storage_get_tracing+0x2e/0x1b0&#xA;bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda&#xA;bpf_trace_run2+0x4c/0xc0&#xA;tcp_rtx_synack+0xf9/0x100&#xA;reqsk_timer_handler+0xda/0x3d0&#xA;run_timer_softirq+0x292/0x8a0&#xA;irq_exit_rcu+0xf5/0x320&#xA;sysvec_apic_timer_interrupt+0x6d/0x80&#xA;asm_sysvec_apic_timer_interrupt+0x16/0x20&#xA;intel_idle_irq+0x5a/0xa0&#xA;cpuidle_enter_state+0x94/0x273&#xA;cpu_startup_entry+0x15e/0x260&#xA;start_secondary+0x8a/0x90&#xA;secondary_startup_64_no_verify+0xfa/0xfb&#xA;kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6&#xA;allocated by task 0 on cpu 9 at 260507.901592s:&#xA;sk_prot_alloc+0x35/0x140&#xA;sk_clone_lock+0x1f/0x3f0&#xA;inet_csk_clone_lock+0x15/0x160&#xA;tcp_create_openreq_child+0x1f/0x410&#xA;tcp_v6_syn_recv_sock+0x1da/0x700&#xA;tcp_check_req+0x1fb/0x510&#xA;tcp_v6_rcv+0x98b/0x1420&#xA;ipv6_list_rcv+0x2258/0x26e0&#xA;napi_complete_done+0x5b1/0x2990&#xA;mlx5e_napi_poll+0x2ae/0x8d0&#xA;net_rx_action+0x13e/0x590&#xA;irq_exit_rcu+0xf5/0x320&#xA;common_interrupt+0x80/0x90&#xA;asm_common_interrupt+0x22/0x40&#xA;cpuidle_enter_state+0xfb/0x273&#xA;cpu_startup_entry+0x15e/0x260&#xA;start_secondary+0x8a/0x90&#xA;secondary_startup_64_no_verify+0xfa/0xfb&#xA;freed by task 0 on cpu 9 at 260507.927527s:&#xA;rcu_core_si+0x4ff/0xf10&#xA;irq_exit_rcu+0xf5/0x320&#xA;sysvec_apic_timer_interrupt+0x6d/0x80&#xA;asm_sysvec_apic_timer_interrupt+0x16/0x20&#xA;cpuidle_enter_state+0xfb/0x273&#xA;cpu_startup_entry+0x15e/0x260&#xA;start_secondary+0x8a/0x90&#xA;secondary_startup_64_no_verify+0xfa/0xfb&#xA;CVE-2024-50142:In the Linux kernel, the following vulnerability has been resolved:&#xA;xfrm: validate new SA&#39;s prefixlen using SA family when sel.family is unset&#xA;This expands the validation introduced in commit 07bf7908950a (&#34;xfrm:&#xA;Validate address prefix lengths in the xfrm selector.&#34;)&#xA;syzbot created an SA with&#xA;    usersa.sel.family = AF_UNSPEC&#xA;    usersa.sel.prefixlen_s = 128&#xA;    usersa.family = AF_INET&#xA;Because of the AF_UNSPEC selector, verify_newsa_info doesn&#39;t put&#xA;limits on prefixlen_{s,d}. But then copy_from_user_state sets&#xA;x-&gt;sel.family to usersa.family (AF_INET). Do the same conversion in&#xA;verify_newsa_info before validating prefixlen_{s,d}, since that&#39;s how&#xA;prefixlen is going to be used later on.&#xA;CVE-2024-35833:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA&#xA;This dma_alloc_coherent() is undone neither in the remove function, nor in&#xA;the error handling path of fsl_qdma_probe().&#xA;Switch to the managed version to fix both issues.&#xA;CVE-2024-36005:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: honor table dormant flag from netdev release event path&#xA;Check for table dormant flag otherwise netdev release event path tries&#xA;to unregister an already unregistered hook.&#xA;[524854.857999] ------------[ cut here ]------------&#xA;[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260&#xA;[...]&#xA;[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365&#xA;[524854.858869] Workqueue: netns cleanup_net&#xA;[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260&#xA;[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff &lt;0f&gt; 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41&#xA;[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246&#xA;[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a&#xA;[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438&#xA;[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34&#xA;[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005&#xA;[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00&#xA;[524854.858971] FS:  0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000&#xA;[524854.858982] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0&#xA;[524854.859000] Call Trace:&#xA;[524854.859006]  &lt;TASK&gt;&#xA;[524854.859013]  ? __warn+0x9f/0x1a0&#xA;[524854.859027]  ? __nf_unregister_net_hook+0x21a/0x260&#xA;[524854.859044]  ? report_bug+0x1b1/0x1e0&#xA;[524854.859060]  ? handle_bug+0x3c/0x70&#xA;[524854.859071]  ? exc_invalid_op+0x17/0x40&#xA;[524854.859083]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[524854.859100]  ? __nf_unregister_net_hook+0x6a/0x260&#xA;[524854.859116]  ? __nf_unregister_net_hook+0x21a/0x260&#xA;[524854.859135]  nf_tables_netdev_event+0x337/0x390 [nf_tables]&#xA;[524854.859304]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]&#xA;[524854.859461]  ? packet_notifier+0xb3/0x360&#xA;[524854.859476]  ? _raw_spin_unlock_irqrestore+0x11/0x40&#xA;[524854.859489]  ? dcbnl_netdevice_event+0x35/0x140&#xA;[524854.859507]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]&#xA;[524854.859661]  notifier_call_chain+0x7d/0x140&#xA;[524854.859677]  unregister_netdevice_many_notify+0x5e1/0xae0&#xA;CVE-2024-36950:In the Linux kernel, the following vulnerability has been resolved:&#xA;firewire: ohci: mask bus reset interrupts between ISR and bottom half&#xA;In the FireWire OHCI interrupt handler, if a bus reset interrupt has&#xA;occurred, mask bus reset interrupts until bus_reset_work has serviced and&#xA;cleared the interrupt.&#xA;Normally, we always leave bus reset interrupts masked. We infer the bus&#xA;reset from the self-ID interrupt that happens shortly thereafter. A&#xA;scenario where we unmask bus reset interrupts was introduced in 2008 in&#xA;a007bb857e0b26f5d8b73c2ff90782d9c0972620: If&#xA;OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we&#xA;will unmask bus reset interrupts so we can log them.&#xA;irq_handler logs the bus reset interrupt. However, we can&#39;t clear the bus&#xA;reset event flag in irq_handler, because we won&#39;t service the event until&#xA;later. irq_handler exits with the event flag still set. If the&#xA;corresponding interrupt is still unmasked, the first bus reset will&#xA;usually freeze the system due to irq_handler being called again each&#xA;time it exits. This freeze can be reproduced by loading firewire_ohci&#xA;with &#34;modprobe firewire_ohci debug=-1&#34; (to enable all debugging output).&#xA;Apparently there are also some cases where bus_reset_work will get called&#xA;soon enough to clear the event, and operation will continue normally.&#xA;This freeze was first reported a few months after a007bb85 was committed,&#xA;but until now it was never fixed. The debug level could safely be set&#xA;to -1 through sysfs after the module was loaded, but this would be&#xA;ineffectual in logging bus reset interrupts since they were only&#xA;unmasked during initialization.&#xA;irq_handler will now leave the event flag set but mask bus reset&#xA;interrupts, so irq_handler won&#39;t be called again and there will be no&#xA;freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will&#xA;unmask the interrupt after servicing the event, so future interrupts&#xA;will be caught as desired.&#xA;As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be&#xA;enabled through sysfs in addition to during initial module loading.&#xA;However, when enabled through sysfs, logging of bus reset interrupts will&#xA;be effective only starting with the second bus reset, after&#xA;bus_reset_work has executed.&#xA;CVE-2022-48878:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: hci_qca: Fix driver shutdown on closed serdev&#xA;The driver shutdown callback (which sends EDL_SOC_RESET to the device&#xA;over serdev) should not be invoked when HCI device is not open (e.g. if&#xA;hci_dev_open_sync() failed), because the serdev and its TTY are not open&#xA;either.  Also skip this step if device is powered off&#xA;(qca_power_shutdown()).&#xA;The shutdown callback causes use-after-free during system reboot with&#xA;Qualcomm Atheros Bluetooth:&#xA;  Unable to handle kernel paging request at virtual address&#xA;  0072662f67726fd7&#xA;  ...&#xA;  CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G        W&#xA;  6.1.0-rt5-00325-g8a5f56bcfcca #8&#xA;  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)&#xA;  Call trace:&#xA;   tty_driver_flush_buffer+0x4/0x30&#xA;   serdev_device_write_flush+0x24/0x34&#xA;   qca_serdev_shutdown+0x80/0x130 [hci_uart]&#xA;   device_shutdown+0x15c/0x260&#xA;   kernel_restart+0x48/0xac&#xA;KASAN report:&#xA;  BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50&#xA;  Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1&#xA;  CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted&#xA;  6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28&#xA;  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)&#xA;  Call trace:&#xA;   dump_backtrace.part.0+0xdc/0xf0&#xA;   show_stack+0x18/0x30&#xA;   dump_stack_lvl+0x68/0x84&#xA;   print_report+0x188/0x488&#xA;   kasan_report+0xa4/0xf0&#xA;   __asan_load8+0x80/0xac&#xA;   tty_driver_flush_buffer+0x1c/0x50&#xA;   ttyport_write_flush+0x34/0x44&#xA;   serdev_device_write_flush+0x48/0x60&#xA;   qca_serdev_shutdown+0x124/0x274&#xA;   device_shutdown+0x1e8/0x350&#xA;   kernel_restart+0x48/0xb0&#xA;   __do_sys_reboot+0x244/0x2d0&#xA;   __arm64_sys_reboot+0x54/0x70&#xA;   invoke_syscall+0x60/0x190&#xA;   el0_svc_common.constprop.0+0x7c/0x160&#xA;   do_el0_svc+0x44/0xf0&#xA;   el0_svc+0x2c/0x6c&#xA;   el0t_64_sync_handler+0xbc/0x140&#xA;   el0t_64_sync+0x190/0x194&#xA;CVE-2024-43911:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: fix NULL dereference at band check in starting tx ba session&#xA;In MLD connection, link_data/link_conf are dynamically allocated. They&#xA;don&#39;t point to vif-&gt;bss_conf. So, there will be no chanreq assigned to&#xA;vif-&gt;bss_conf and then the chan will be NULL. Tweak the code to check&#xA;ht_supported/vht_supported/has_he/has_eht on sta deflink.&#xA;Crash log (with rtw89 version under MLO development):&#xA;[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[ 9890.526102] #PF: supervisor read access in kernel mode&#xA;[ 9890.526105] #PF: error_code(0x0000) - not-present page&#xA;[ 9890.526109] PGD 0 P4D 0&#xA;[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI&#xA;[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G           OE      6.9.0 #1&#xA;[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018&#xA;[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]&#xA;[ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211&#xA;[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 &lt;83&gt; 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3&#xA;All code&#xA;========&#xA;   0:&#x9;f7 e8                &#x9;imul   %eax&#xA;   2:&#x9;d5                   &#x9;(bad)&#xA;   3:&#x9;93                   &#x9;xchg   %eax,%ebx&#xA;   4:&#x9;3e ea                &#x9;ds (bad)&#xA;   6:&#x9;48 83 c4 28          &#x9;add    $0x28,%rsp&#xA;   a:&#x9;89 d8                &#x9;mov    %ebx,%eax&#xA;   c:&#x9;5b                   &#x9;pop    %rbx&#xA;   d:&#x9;41 5c                &#x9;pop    %r12&#xA;   f:&#x9;41 5d                &#x9;pop    %r13&#xA;  11:&#x9;41 5e                &#x9;pop    %r14&#xA;  13:&#x9;41 5f                &#x9;pop    %r15&#xA;  15:&#x9;5d                   &#x9;pop    %rbp&#xA;  16:&#x9;c3                   &#x9;retq&#xA;  17:&#x9;cc                   &#x9;int3&#xA;  18:&#x9;cc                   &#x9;int3&#xA;  19:&#x9;cc                   &#x9;int3&#xA;  1a:&#x9;cc                   &#x9;int3&#xA;  1b:&#x9;49 8b 84 24 e0 f1 ff &#x9;mov    -0xe20(%r12),%rax&#xA;  22:&#x9;ff&#xA;  23:&#x9;48 8b 80 90 1b 00 00 &#x9;mov    0x1b90(%rax),%rax&#xA;  2a:*&#x9;83 38 03             &#x9;cmpl   $0x3,(%rax)&#x9;&#x9;&lt;-- trapping instruction&#xA;  2d:&#x9;0f 84 37 fe ff ff    &#x9;je     0xfffffffffffffe6a&#xA;  33:&#x9;bb ea ff ff ff       &#x9;mov    $0xffffffea,%ebx&#xA;  38:&#x9;eb cc                &#x9;jmp    0x6&#xA;  3a:&#x9;49                   &#x9;rex.WB&#xA;  3b:&#x9;8b                   &#x9;.byte 0x8b&#xA;  3c:&#x9;84 24 10             &#x9;test   %ah,(%rax,%rdx,1)&#xA;  3f:&#x9;f3                   &#x9;repz&#xA;Code starting with the faulting instruction&#xA;===========================================&#xA;   0:&#x9;83 38 03             &#x9;cmpl   $0x3,(%rax)&#xA;   3:&#x9;0f 84 37 fe ff ff    &#x9;je     0xfffffffffffffe40&#xA;   9:&#x9;bb ea ff ff ff       &#x9;mov    $0xffffffea,%ebx&#xA;   e:&#x9;eb cc                &#x9;jmp    0xffffffffffffffdc&#xA;  10:&#x9;49                   &#x9;rex.WB&#xA;  11:&#x9;8b                   &#x9;.byte 0x8b&#xA;  12:&#x9;84 24 10             &#x9;test   %ah,(%rax,%rdx,1)&#xA;  15:&#x9;f3                   &#x9;repz&#xA;[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246&#xA;[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8&#xA;[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685&#xA;[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873&#xA;[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70&#xA;[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000&#xA;[ 9890.526313] FS:  0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000&#xA;[ 9890.526316] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0&#xA;[ 9890.526321] Call Trace:&#xA;[ 9890.526324]  &lt;TASK&gt;&#xA;[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)&#xA;[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)&#xA;[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)&#xA;[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator&#xA;---truncated---&#xA;CVE-2024-47663:In the Linux kernel, the following vulnerability has been resolved:&#xA;staging: iio: frequency: ad9834: Validate frequency parameter value&#xA;In ad9834_write_frequency() clk_get_rate() can return 0. In such case&#xA;ad9834_calc_freqreg() call will lead to division by zero. Checking&#xA;&#39;if (fout &gt; (clk_freq / 2))&#39; doesn&#39;t protect in case of &#39;fout&#39; is 0.&#xA;ad9834_write_frequency() is called from ad9834_write(), where fout is&#xA;taken from text buffer, which can contain any value.&#xA;Modify parameters checking.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-47666:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: pm80xx: Set phy-&gt;enable_completion only when we wait for it&#xA;pm8001_phy_control() populates the enable_completion pointer with a stack&#xA;address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and&#xA;returns. The problem arises when a phy control response comes late.  After&#xA;300 ms the pm8001_phy_control() function returns and the passed&#xA;enable_completion stack address is no longer valid. Late phy control&#xA;response invokes complete() on a dangling enable_completion pointer which&#xA;leads to a kernel crash.&#xA;CVE-2024-47728:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error&#xA;For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input&#xA;arguments, zero the value for the case of an error as otherwise it could leak&#xA;memory. For tracing, it is not needed given CAP_PERFMON can already read all&#xA;kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped&#xA;in here.&#xA;Also, the MTU helpers mtu_len pointer value is being written but also read.&#xA;Technically, the MEM_UNINIT should not be there in order to always force init.&#xA;Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now&#xA;implies two things actually: i) write into memory, ii) memory does not have&#xA;to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,&#xA;ii) memory must be initialized. This means that for bpf_*_check_mtu() we&#39;re&#xA;readding the issue we&#39;re trying to fix, that is, it would then be able to&#xA;write back into things like .rodata BPF maps. Follow-up work will rework the&#xA;MEM_UNINIT semantics such that the intent can be better expressed. For now&#xA;just clear the *mtu_len on error path which can be lifted later again.&#xA;CVE-2024-49982:In the Linux kernel, the following vulnerability has been resolved:&#xA;aoe: fix the potential use-after-free problem in more places&#xA;For fixing CVE-2023-6270, f98364e92662 (&#34;aoe: fix the potential&#xA;use-after-free problem in aoecmd_cfg_pkts&#34;) makes tx() calling dev_put()&#xA;instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs&#xA;into use-after-free.&#xA;Then Nicolai Stange found more places in aoe have potential use-after-free&#xA;problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe()&#xA;and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push&#xA;packet to tx queue. So they should also use dev_hold() to increase the&#xA;refcnt of skb-&gt;dev.&#xA;On the other hand, moving dev_put() to tx() causes that the refcnt of&#xA;skb-&gt;dev be reduced to a negative value, because corresponding&#xA;dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(),&#xA;probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.&#xA;CVE-2024-49945:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/ncsi: Disable the ncsi work before freeing the associated structure&#xA;The work function can run after the ncsi device is freed, resulting&#xA;in use-after-free bugs or kernel panic.&#xA;CVE-2024-49914:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe&#xA;This commit addresses a null pointer dereference issue in the&#xA;`dcn20_program_pipe` function. The issue could occur when&#xA;`pipe_ctx-&gt;plane_state` is null.&#xA;The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null&#xA;before accessing. This prevents a null pointer dereference.&#xA;Reported by smatch:&#xA;drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed &#39;pipe_ctx-&gt;plane_state&#39; could be null (see line 1877)&#xA;CVE-2024-49963:In the Linux kernel, the following vulnerability has been resolved:&#xA;mailbox: bcm2835: Fix timeout during suspend mode&#xA;During noirq suspend phase the Raspberry Pi power driver suffer of&#xA;firmware property timeouts. The reason is that the IRQ of the underlying&#xA;BCM2835 mailbox is disabled and rpi_firmware_property_list() will always&#xA;run into a timeout [1].&#xA;Since the VideoCore side isn&#39;t consider as a wakeup source, set the&#xA;IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled&#xA;during suspend-resume cycle.&#xA;[1]&#xA;PM: late suspend of devices complete after 1.754 msecs&#xA;WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128&#xA; rpi_firmware_property_list+0x204/0x22c&#xA;Firmware transaction 0x00028001 timeout&#xA;Modules linked in:&#xA;CPU: 0 PID: 438 Comm: bash Tainted: G         C         6.9.3-dirty #17&#xA;Hardware name: BCM2835&#xA;Call trace:&#xA;unwind_backtrace from show_stack+0x18/0x1c&#xA;show_stack from dump_stack_lvl+0x34/0x44&#xA;dump_stack_lvl from __warn+0x88/0xec&#xA;__warn from warn_slowpath_fmt+0x7c/0xb0&#xA;warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c&#xA;rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c&#xA;rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0&#xA;rpi_firmware_set_power from _genpd_power_off+0xe4/0x148&#xA;_genpd_power_off from genpd_sync_power_off+0x7c/0x11c&#xA;genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0&#xA;genpd_finish_suspend from dpm_run_callback+0x78/0xd0&#xA;dpm_run_callback from device_suspend_noirq+0xc0/0x238&#xA;device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168&#xA;dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac&#xA;suspend_devices_and_enter from pm_suspend+0x254/0x2e4&#xA;pm_suspend from state_store+0xa8/0xd4&#xA;state_store from kernfs_fop_write_iter+0x154/0x1a0&#xA;kernfs_fop_write_iter from vfs_write+0x12c/0x184&#xA;vfs_write from ksys_write+0x78/0xc0&#xA;ksys_write from ret_fast_syscall+0x0/0x54&#xA;Exception stack(0xcc93dfa8 to 0xcc93dff0)&#xA;[...]&#xA;PM: noirq suspend of devices complete after 3095.584 msecs&#xA;CVE-2022-48953:In the Linux kernel, the following vulnerability has been resolved:&#xA;rtc: cmos: Fix event handler registration ordering issue&#xA;Because acpi_install_fixed_event_handler() enables the event&#xA;automatically on success, it is incorrect to call it before the&#xA;handler routine passed to it is ready to handle events.&#xA;Unfortunately, the rtc-cmos driver does exactly the incorrect thing&#xA;by calling cmos_wake_setup(), which passes rtc_handler() to&#xA;acpi_install_fixed_event_handler(), before cmos_do_probe(), because&#xA;rtc_handler() uses dev_get_drvdata() to get to the cmos object&#xA;pointer and the driver data pointer is only populated in&#xA;cmos_do_probe().&#xA;This leads to a NULL pointer dereference in rtc_handler() on boot&#xA;if the RTC fixed event happens to be active at the init time.&#xA;To address this issue, change the initialization ordering of the&#xA;driver so that cmos_wake_setup() is always called after a successful&#xA;cmos_do_probe() call.&#xA;While at it, change cmos_pnp_probe() to call cmos_do_probe() after&#xA;the initial if () statement used for computing the IRQ argument to&#xA;be passed to cmos_do_probe() which is cleaner than calling it in&#xA;each branch of that if () (local variable &#34;irq&#34; can be of type int,&#xA;because it is passed to that function as an argument of type int).&#xA;Note that commit 6492fed7d8c9 (&#34;rtc: rtc-cmos: Do not check&#xA;ACPI_FADT_LOW_POWER_S0&#34;) caused this issue to affect a larger number&#xA;of systems, because previously it only affected systems with&#xA;ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that&#xA;commit.&#xA;CVE-2022-49026:In the Linux kernel, the following vulnerability has been resolved:&#xA;e100: Fix possible use after free in e100_xmit_prepare&#xA;In e100_xmit_prepare(), if we can&#39;t map the skb, then return -ENOMEM, so&#xA;e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will&#xA;resend the skb. But the skb is already freed, which will cause UAF bug&#xA;when the upper layer resends the skb.&#xA;Remove the harmful free.&#xA;CVE-2024-50099:In the Linux kernel, the following vulnerability has been resolved:&#xA;arm64: probes: Remove broken LDR (literal) uprobe support&#xA;The simulate_ldr_literal() and simulate_ldrsw_literal() functions are&#xA;unsafe to use for uprobes. Both functions were originally written for&#xA;use with kprobes, and access memory with plain C accesses. When uprobes&#xA;was added, these were reused unmodified even though they cannot safely&#xA;access user memory.&#xA;There are three key problems:&#xA;1) The plain C accesses do not have corresponding extable entries, and&#xA;   thus if they encounter a fault the kernel will treat these as&#xA;   unintentional accesses to user memory, resulting in a BUG() which&#xA;   will kill the kernel thread, and likely lead to further issues (e.g.&#xA;   lockup or panic()).&#xA;2) The plain C accesses are subject to HW PAN and SW PAN, and so when&#xA;   either is in use, any attempt to simulate an access to user memory&#xA;   will fault. Thus neither simulate_ldr_literal() nor&#xA;   simulate_ldrsw_literal() can do anything useful when simulating a&#xA;   user instruction on any system with HW PAN or SW PAN.&#xA;3) The plain C accesses are privileged, as they run in kernel context,&#xA;   and in practice can access a small range of kernel virtual addresses.&#xA;   The instructions they simulate have a range of +/-1MiB, and since the&#xA;   simulated instructions must itself be a user instructions in the&#xA;   TTBR0 address range, these can address the final 1MiB of the TTBR1&#xA;   acddress range by wrapping downwards from an address in the first&#xA;   1MiB of the TTBR0 address range.&#xA;   In contemporary kernels the last 8MiB of TTBR1 address range is&#xA;   reserved, and accesses to this will always fault, meaning this is no&#xA;   worse than (1).&#xA;   Historically, it was theoretically possible for the linear map or&#xA;   vmemmap to spill into the final 8MiB of the TTBR1 address range, but&#xA;   in practice this is extremely unlikely to occur as this would&#xA;   require either:&#xA;   * Having enough physical memory to fill the entire linear map all the&#xA;     way to the final 1MiB of the TTBR1 address range.&#xA;   * Getting unlucky with KASLR randomization of the linear map such&#xA;     that the populated region happens to overlap with the last 1MiB of&#xA;     the TTBR address range.&#xA;   ... and in either case if we were to spill into the final page there&#xA;   would be larger problems as the final page would alias with error&#xA;   pointers.&#xA;Practically speaking, (1) and (2) are the big issues. Given there have&#xA;been no reports of problems since the broken code was introduced, it&#xA;appears that no-one is relying on probing these instructions with&#xA;uprobes.&#xA;Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW&#xA;(literal), limiting the use of simulate_ldr_literal() and&#xA;simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR&#xA;(literal) and LDRSW (literal) will be rejected as&#xA;arm_probe_decode_insn() will return INSN_REJECTED. In future we can&#xA;consider introducing working uprobes support for these instructions, but&#xA;this will require more significant work.&#xA;CVE-2024-50138:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Use raw_spinlock_t in ringbuf&#xA;The function __bpf_ringbuf_reserve is invoked from a tracepoint, which&#xA;disables preemption. Using spinlock_t in this context can lead to a&#xA;&#34;sleep in atomic&#34; warning in the RT variant. This issue is illustrated&#xA;in the example below:&#xA;BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48&#xA;in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs&#xA;preempt_count: 1, expected: 0&#xA;RCU nest depth: 1, expected: 1&#xA;INFO: lockdep is turned off.&#xA;Preemption disabled at:&#xA;[&lt;ffffd33a5c88ea44&gt;] migrate_enable+0xc0/0x39c&#xA;CPU: 7 PID: 556208 Comm: test_progs Tainted: G&#xA;Hardware name: Qualcomm SA8775P Ride (DT)&#xA;Call trace:&#xA; dump_backtrace+0xac/0x130&#xA; show_stack+0x1c/0x30&#xA; dump_stack_lvl+0xac/0xe8&#xA; dump_stack+0x18/0x30&#xA; __might_resched+0x3bc/0x4fc&#xA; rt_spin_lock+0x8c/0x1a4&#xA; __bpf_ringbuf_reserve+0xc4/0x254&#xA; bpf_ringbuf_reserve_dynptr+0x5c/0xdc&#xA; bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238&#xA; trace_call_bpf+0x238/0x774&#xA; perf_call_bpf_enter.isra.0+0x104/0x194&#xA; perf_syscall_enter+0x2f8/0x510&#xA; trace_sys_enter+0x39c/0x564&#xA; syscall_trace_enter+0x220/0x3c0&#xA; do_el0_svc+0x138/0x1dc&#xA; el0_svc+0x54/0x130&#xA; el0t_64_sync_handler+0x134/0x150&#xA; el0t_64_sync+0x17c/0x180&#xA;Switch the spinlock to raw_spinlock_t to avoid this error.&#xA;CVE-2024-50115:In the Linux kernel, the following vulnerability has been resolved:&#xA;KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory&#xA;Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits&#xA;4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn&#39;t&#xA;enforce 32-byte alignment of nCR3.&#xA;In the absolute worst case scenario, failure to ignore bits 4:0 can result&#xA;in an out-of-bounds read, e.g. if the target page is at the end of a&#xA;memslot, and the VMM isn&#39;t using guard pages.&#xA;Per the APM:&#xA;  The CR3 register points to the base address of the page-directory-pointer&#xA;  table. The page-directory-pointer table is aligned on a 32-byte boundary,&#xA;  with the low 5 address bits 4:0 assumed to be 0.&#xA;And the SDM&#39;s much more explicit:&#xA;  4:0    Ignored&#xA;Note, KVM gets this right when loading PDPTRs, it&#39;s only the nSVM flow&#xA;that is broken.&#xA;CVE-2024-50195:In the Linux kernel, the following vulnerability has been resolved:&#xA;posix-clock: Fix missing timespec64 check in pc_clock_settime()&#xA;As Andrew pointed out, it will make sense that the PTP core&#xA;checked timespec64 struct&#39;s tv_sec and tv_nsec range before calling&#xA;ptp-&gt;info-&gt;settime64().&#xA;As the man manual of clock_settime() said, if tp.tv_sec is negative or&#xA;tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,&#xA;which include dynamic clocks which handles PTP clock, and the condition is&#xA;consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()&#xA;only check the timespec is valid, but not ensure that the time is&#xA;in a valid range, so check it ahead using timespec64_valid_strict()&#xA;in pc_clock_settime() and return -EINVAL if not valid.&#xA;There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to&#xA;write registers without validity checks and assume that the higher layer&#xA;has checked it, which is dangerous and will benefit from this, such as&#xA;hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),&#xA;and some drivers can remove the checks of itself.&#xA;CVE-2024-50184:In the Linux kernel, the following vulnerability has been resolved:&#xA;virtio_pmem: Check device status before requesting flush&#xA;If a pmem device is in a bad status, the driver side could wait for&#xA;host ack forever in virtio_pmem_flush(), causing the system to hang.&#xA;So add a status check in the beginning of virtio_pmem_flush() to return&#xA;early if the device is not activated.&#xA;CVE-2024-50210:In the Linux kernel, the following vulnerability has been resolved:&#xA;posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()&#xA;If get_clock_desc() succeeds, it calls fget() for the clockid&#39;s fd,&#xA;and get the clk-&gt;rwsem read lock, so the error path should release&#xA;the lock to make the lock balance and fput the clockid&#39;s fd to make&#xA;the refcount balance and release the fd related resource.&#xA;However the below commit left the error path locked behind resulting in&#xA;unbalanced locking. Check timespec64_valid_strict() before&#xA;get_clock_desc() to fix it, because the &#34;ts&#34; is not changed&#xA;after that.&#xA;[pabeni@redhat.com: fixed commit message typo]&#xA;CVE-2024-50198:In the Linux kernel, the following vulnerability has been resolved:&#xA;iio: light: veml6030: fix IIO device retrieval from embedded device&#xA;The dev pointer that is received as an argument in the&#xA;in_illuminance_period_available_show function references the device&#xA;embedded in the IIO device, not in the i2c client.&#xA;dev_to_iio_dev() must be used to accessthe right data. The current&#xA;implementation leads to a segmentation fault on every attempt to read&#xA;the attribute because indio_dev gets a NULL assignment.&#xA;This bug has been present since the first appearance of the driver,&#xA;apparently since the last version (V6) before getting applied. A&#xA;constant attribute was used until then, and the last modifications might&#xA;have not been tested again.&#xA;CVE-2024-50247:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Check if more than chunk-size bytes are written&#xA;A incorrectly formatted chunk may decompress into&#xA;more than LZNT_CHUNK_SIZE bytes and a index out of bounds&#xA;will occur in s_max_off.&#xA;CVE-2024-50242:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Additional check in ntfs_file_release&#xA;CVE-2024-50237:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower&#xA;Avoid potentially crashing in the driver because of uninitialized private data&#xA;CVE-2024-50245:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Fix possible deadlock in mi_read&#xA;Mutex lock with another subclass used in ni_lock_dir().&#xA;CVE-2024-50246:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Add rough attr alloc_size check&#xA;CVE-2023-52784:In the Linux kernel, the following vulnerability has been resolved:&#xA;bonding: stop the device in bond_setup_by_slave()&#xA;Commit 9eed321cde22 (&#34;net: lapbether: only support ethernet devices&#34;)&#xA;has been able to keep syzbot away from net/lapb, until today.&#xA;In the following splat [1], the issue is that a lapbether device has&#xA;been created on a bonding device without members. Then adding a non&#xA;ARPHRD_ETHER member forced the bonding master to change its type.&#xA;The fix is to make sure we call dev_close() in bond_setup_by_slave()&#xA;so that the potential linked lapbether devices (or any other devices&#xA;having assumptions on the physical device) are removed.&#xA;A similar bug has been addressed in commit 40baec225765&#xA;(&#34;bonding: fix panic on non-ARPHRD_ETHER enslave failure&#34;)&#xA;[1]&#xA;skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0&#xA;kernel BUG at net/core/skbuff.c:192 !&#xA;Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP&#xA;Modules linked in:&#xA;CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023&#xA;pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : skb_panic net/core/skbuff.c:188 [inline]&#xA;pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202&#xA;lr : skb_panic net/core/skbuff.c:188 [inline]&#xA;lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202&#xA;sp : ffff800096a06aa0&#xA;x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000&#xA;x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea&#xA;x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140&#xA;x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100&#xA;x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001&#xA;x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000&#xA;x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00&#xA;x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001&#xA;x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c&#xA;x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086&#xA;Call trace:&#xA;skb_panic net/core/skbuff.c:188 [inline]&#xA;skb_under_panic+0x13c/0x140 net/core/skbuff.c:202&#xA;skb_push+0xf0/0x108 net/core/skbuff.c:2446&#xA;ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384&#xA;dev_hard_header include/linux/netdevice.h:3136 [inline]&#xA;lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257&#xA;lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447&#xA;lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149&#xA;lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251&#xA;__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326&#xA;lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492&#xA;notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93&#xA;raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461&#xA;call_netdevice_notifiers_info net/core/dev.c:1970 [inline]&#xA;call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]&#xA;call_netdevice_notifiers net/core/dev.c:2022 [inline]&#xA;__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508&#xA;dev_close_many+0x1e0/0x470 net/core/dev.c:1559&#xA;dev_close+0x174/0x250 net/core/dev.c:1585&#xA;lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466&#xA;notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93&#xA;raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461&#xA;call_netdevice_notifiers_info net/core/dev.c:1970 [inline]&#xA;call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]&#xA;call_netdevice_notifiers net/core/dev.c:2022 [inline]&#xA;__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508&#xA;dev_close_many+0x1e0/0x470 net/core/dev.c:1559&#xA;dev_close+0x174/0x250 net/core/dev.c:1585&#xA;bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332&#xA;bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539&#xA;dev_ifsioc+0x754/0x9ac&#xA;dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786&#xA;sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217&#xA;sock_ioctl+0x4e8/0x834 net/socket.c:1322&#xA;vfs_ioctl fs/ioctl.c:51 [inline]&#xA;__do_&#xA;---truncated---&#xA;CVE-2023-52885:In the Linux kernel, the following vulnerability has been resolved:&#xA;SUNRPC: Fix UAF in svc_tcp_listen_data_ready()&#xA;After the listener svc_sock is freed, and before invoking svc_tcp_accept()&#xA;for the established child sock, there is a window that the newsock&#xA;retaining a freed listener svc_sock in sk_user_data which cloning from&#xA;parent. In the race window, if data is received on the newsock, we will&#xA;observe use-after-free report in svc_tcp_listen_data_ready().&#xA;Reproduce by two tasks:&#xA;1. while :; do rpc.nfsd 0 ; rpc.nfsd; done&#xA;2. while :; do echo &#34;&#34; | ncat -4 127.0.0.1 2049 ; done&#xA;KASAN report:&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]&#xA;  Read of size 8 at addr ffff888139d96228 by task nc/102553&#xA;  CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18&#xA;  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   dump_stack_lvl+0x33/0x50&#xA;   print_address_description.constprop.0+0x27/0x310&#xA;   print_report+0x3e/0x70&#xA;   kasan_report+0xae/0xe0&#xA;   svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]&#xA;   tcp_data_queue+0x9f4/0x20e0&#xA;   tcp_rcv_established+0x666/0x1f60&#xA;   tcp_v4_do_rcv+0x51c/0x850&#xA;   tcp_v4_rcv+0x23fc/0x2e80&#xA;   ip_protocol_deliver_rcu+0x62/0x300&#xA;   ip_local_deliver_finish+0x267/0x350&#xA;   ip_local_deliver+0x18b/0x2d0&#xA;   ip_rcv+0x2fb/0x370&#xA;   __netif_receive_skb_one_core+0x166/0x1b0&#xA;   process_backlog+0x24c/0x5e0&#xA;   __napi_poll+0xa2/0x500&#xA;   net_rx_action+0x854/0xc90&#xA;   __do_softirq+0x1bb/0x5de&#xA;   do_softirq+0xcb/0x100&#xA;   &lt;/IRQ&gt;&#xA;   &lt;TASK&gt;&#xA;   ...&#xA;   &lt;/TASK&gt;&#xA;  Allocated by task 102371:&#xA;   kasan_save_stack+0x1e/0x40&#xA;   kasan_set_track+0x21/0x30&#xA;   __kasan_kmalloc+0x7b/0x90&#xA;   svc_setup_socket+0x52/0x4f0 [sunrpc]&#xA;   svc_addsock+0x20d/0x400 [sunrpc]&#xA;   __write_ports_addfd+0x209/0x390 [nfsd]&#xA;   write_ports+0x239/0x2c0 [nfsd]&#xA;   nfsctl_transaction_write+0xac/0x110 [nfsd]&#xA;   vfs_write+0x1c3/0xae0&#xA;   ksys_write+0xed/0x1c0&#xA;   do_syscall_64+0x38/0x90&#xA;   entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;  Freed by task 102551:&#xA;   kasan_save_stack+0x1e/0x40&#xA;   kasan_set_track+0x21/0x30&#xA;   kasan_save_free_info+0x2a/0x50&#xA;   __kasan_slab_free+0x106/0x190&#xA;   __kmem_cache_free+0x133/0x270&#xA;   svc_xprt_free+0x1e2/0x350 [sunrpc]&#xA;   svc_xprt_destroy_all+0x25a/0x440 [sunrpc]&#xA;   nfsd_put+0x125/0x240 [nfsd]&#xA;   nfsd_svc+0x2cb/0x3c0 [nfsd]&#xA;   write_threads+0x1ac/0x2a0 [nfsd]&#xA;   nfsctl_transaction_write+0xac/0x110 [nfsd]&#xA;   vfs_write+0x1c3/0xae0&#xA;   ksys_write+0xed/0x1c0&#xA;   do_syscall_64+0x38/0x90&#xA;   entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready()&#xA;if state != TCP_LISTEN, that will avoid dereferencing svsk for all&#xA;child socket.&#xA;CVE-2024-46713:In the Linux kernel, the following vulnerability has been resolved:&#xA;perf/aux: Fix AUX buffer serialization&#xA;Ole reported that event-&gt;mmap_mutex is strictly insufficient to&#xA;serialize the AUX buffer, add a per RB mutex to fully serialize it.&#xA;Note that in the lock order comment the perf_event::mmap_mutex order&#xA;was already wrong, that is, it nesting under mmap_lock is not new with&#xA;this patch.&#xA;CVE-2024-47735:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled&#xA;Fix missuse of spin_lock_irq()/spin_unlock_irq() when&#xA;spin_lock_irqsave()/spin_lock_irqrestore() was hold.&#xA;This was discovered through the lock debugging, and the corresponding&#xA;log is as follows:&#xA;raw_local_irq_restore() called with IRQs enabled&#xA;WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40&#xA;...&#xA;Call trace:&#xA; warn_bogus_irq_restore+0x30/0x40&#xA; _raw_spin_unlock_irqrestore+0x84/0xc8&#xA; add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]&#xA; hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]&#xA; hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]&#xA; create_qp+0x138/0x258&#xA; ib_create_qp_kernel+0x50/0xe8&#xA; create_mad_qp+0xa8/0x128&#xA; ib_mad_port_open+0x218/0x448&#xA; ib_mad_init_device+0x70/0x1f8&#xA; add_client_context+0xfc/0x220&#xA; enable_device_and_get+0xd0/0x140&#xA; ib_register_device.part.0+0xf4/0x1c8&#xA; ib_register_device+0x34/0x50&#xA; hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]&#xA; hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]&#xA; __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]&#xA; hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]&#xA;CVE-2024-47749:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/cxgb4: Added NULL check for lookup_atid&#xA;The lookup_atid() function can return NULL if the ATID is&#xA;invalid or does not exist in the identifier table, which&#xA;could lead to dereferencing a null pointer without a&#xA;check in the `act_establish()` and `act_open_rpl()` functions.&#xA;Add a NULL check to prevent null pointer dereferencing.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-47747:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition&#xA;In the ether3_probe function, a timer is initialized with a callback&#xA;function ether3_ledoff, bound to &amp;prev(dev)-&gt;timer. Once the timer is&#xA;started, there is a risk of a race condition if the module or device&#xA;is removed, triggering the ether3_remove function to perform cleanup.&#xA;The sequence of operations that may lead to a UAF bug is as follows:&#xA;CPU0                                    CPU1&#xA;                      |  ether3_ledoff&#xA;ether3_remove         |&#xA;  free_netdev(dev);   |&#xA;  put_devic           |&#xA;  kfree(dev);         |&#xA; |  ether3_outw(priv(dev)-&gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2);&#xA;                      | // use dev&#xA;Fix it by ensuring that the timer is canceled before proceeding with&#xA;the cleanup in ether3_remove.&#xA;CVE-2024-47745:In the Linux kernel, the following vulnerability has been resolved:&#xA;mm: call the security_mmap_file() LSM hook in remap_file_pages()&#xA;The remap_file_pages syscall handler calls do_mmap() directly, which&#xA;doesn&#39;t contain the LSM security check. And if the process has called&#xA;personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for&#xA;RW pages, this will actually result in remapping the pages to RWX,&#xA;bypassing a W^X policy enforced by SELinux.&#xA;So we should check prot by security_mmap_file LSM hook in the&#xA;remap_file_pages syscall handler before do_mmap() is called. Otherwise, it&#xA;potentially permits an attacker to bypass a W^X policy enforced by&#xA;SELinux.&#xA;The bypass is similar to CVE-2016-10044, which bypass the same thing via&#xA;AIO and can be found in [1].&#xA;The PoC:&#xA;$ cat &gt; test.c&#xA;int main(void) {&#xA;&#x9;size_t pagesz = sysconf(_SC_PAGE_SIZE);&#xA;&#x9;int mfd = syscall(SYS_memfd_create, &#34;test&#34;, 0);&#xA;&#x9;const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,&#xA;&#x9;&#x9;MAP_SHARED, mfd, 0);&#xA;&#x9;unsigned int old = syscall(SYS_personality, 0xffffffff);&#xA;&#x9;syscall(SYS_personality, READ_IMPLIES_EXEC | old);&#xA;&#x9;syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);&#xA;&#x9;syscall(SYS_personality, old);&#xA;&#x9;// show the RWX page exists even if W^X policy is enforced&#xA;&#x9;int fd = open(&#34;/proc/self/maps&#34;, O_RDONLY);&#xA;&#x9;unsigned char buf2[1024];&#xA;&#x9;while (1) {&#xA;&#x9;&#x9;int ret = read(fd, buf2, 1024);&#xA;&#x9;&#x9;if (ret &lt;= 0) break;&#xA;&#x9;&#x9;write(1, buf2, ret);&#xA;&#x9;}&#xA;&#x9;close(fd);&#xA;}&#xA;$ gcc test.c -o test&#xA;$ ./test | grep rwx&#xA;7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)&#xA;[PM: subject line tweaks]&#xA;CVE-2024-49899:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Initialize denominators&#39; default to 1&#xA;[WHAT &amp; HOW]&#xA;Variables used as denominators and maybe not assigned to other values,&#xA;should not be 0. Change their default to 1 so they are never 0.&#xA;This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.&#xA;CVE-2024-49929:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: avoid NULL pointer dereference&#xA;iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta&#xA;pointer is not NULL.&#xA;It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is&#xA;dereferencing the ieee80211_sta pointer.&#xA;If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL&#xA;pointer.&#xA;Fix this by checking the sta pointer before retrieving the mvmsta&#xA;from it. If sta is not NULL, then mvmsta isn&#39;t either.&#xA;CVE-2024-49952:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: nf_tables: prevent nf_skb_duplicated corruption&#xA;syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write&#xA;per-cpu variable nf_skb_duplicated in an unsafe way [1].&#xA;Disabling preemption as hinted by the splat is not enough,&#xA;we have to disable soft interrupts as well.&#xA;[1]&#xA;BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316&#xA; caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87&#xA;CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:93 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119&#xA;  check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49&#xA;  nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87&#xA;  nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30&#xA;  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]&#xA;  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288&#xA;  nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23&#xA;  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA;  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626&#xA;  nf_hook+0x2c4/0x450 include/linux/netfilter.h:269&#xA;  NF_HOOK_COND include/linux/netfilter.h:302 [inline]&#xA;  ip_output+0x185/0x230 net/ipv4/ip_output.c:433&#xA;  ip_local_out net/ipv4/ip_output.c:129 [inline]&#xA;  ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495&#xA;  udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981&#xA;  udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x1a6/0x270 net/socket.c:745&#xA;  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597&#xA;  ___sys_sendmsg net/socket.c:2651 [inline]&#xA;  __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737&#xA;  __do_sys_sendmmsg net/socket.c:2766 [inline]&#xA;  __se_sys_sendmmsg net/socket.c:2763 [inline]&#xA;  __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f4ce4f7def9&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133&#xA;RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9&#xA;RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006&#xA;RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68&#xA; &lt;/TASK&gt;&#xA;CVE-2024-50038:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: xtables: avoid NFPROTO_UNSPEC where needed&#xA;syzbot managed to call xt_cluster match via ebtables:&#xA; WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780&#xA; [..]&#xA; ebt_do_table+0x174b/0x2a40&#xA;Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet&#xA;processing.  As this is only useful to restrict locally terminating&#xA;TCP/UDP traffic, register this for ipv4 and ipv6 family only.&#xA;Pablo points out that this is a general issue, direct users of the&#xA;set/getsockopt interface can call into targets/matches that were only&#xA;intended for use with ip(6)tables.&#xA;Check all UNSPEC matches and targets for similar issues:&#xA;- matches and targets are fine except if they assume skb_network_header()&#xA;  is valid -- this is only true when called from inet layer: ip(6) stack&#xA;  pulls the ip/ipv6 header into linear data area.&#xA;- targets that return XT_CONTINUE or other xtables verdicts must be&#xA;  restricted too, they are incompatbile with the ebtables traverser, e.g.&#xA;  EBT_CONTINUE is a completely different value than XT_CONTINUE.&#xA;Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as&#xA;they are provided for use by ip(6)tables.&#xA;The MARK target is also used by arptables, so register for NFPROTO_ARP too.&#xA;While at it, bail out if connbytes fails to enable the corresponding&#xA;conntrack family.&#xA;This change passes the selftests in iptables.git.&#xA;CVE-2024-50045:In the Linux kernel, the following vulnerability has been resolved:&#xA;netfilter: br_netfilter: fix panic with metadata_dst skb&#xA;Fix a kernel panic in the br_netfilter module when sending untagged&#xA;traffic via a VxLAN device.&#xA;This happens during the check for fragmentation in br_nf_dev_queue_xmit.&#xA;It is dependent on:&#xA;1) the br_netfilter module being loaded;&#xA;2) net.bridge.bridge-nf-call-iptables set to 1;&#xA;3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;&#xA;4) untagged frames with size higher than the VxLAN MTU forwarded/flooded&#xA;When forwarding the untagged packet to the VxLAN bridge port, before&#xA;the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and&#xA;changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type&#xA;of dst, i.e., skb_valid_dst(skb) is false, and metadata-&gt;dst.dev is NULL.&#xA;Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there&#39;s a check&#xA;for frames that needs to be fragmented: frames with higher MTU than the&#xA;VxLAN device end up calling br_nf_ip_fragment, which in turns call&#xA;ip_skb_dst_mtu.&#xA;The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst&#xA;with valid dst-&gt;dev, thus the crash.&#xA;This case was never supported in the first place, so drop the packet&#xA;instead.&#xA;PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.&#xA;[  176.291791] Unable to handle kernel NULL pointer dereference at&#xA;virtual address 0000000000000110&#xA;[  176.292101] Mem abort info:&#xA;[  176.292184]   ESR = 0x0000000096000004&#xA;[  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[  176.292530]   SET = 0, FnV = 0&#xA;[  176.292709]   EA = 0, S1PTW = 0&#xA;[  176.292862]   FSC = 0x04: level 0 translation fault&#xA;[  176.293013] Data abort info:&#xA;[  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000&#xA;[  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;[  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;[  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000&#xA;[  176.294166] [0000000000000110] pgd=0000000000000000,&#xA;p4d=0000000000000000&#xA;[  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP&#xA;[  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth&#xA;br_netfilter bridge stp llc ipv6 crct10dif_ce&#xA;[  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted&#xA;6.8.0-rc3-g5b3fbd61b9d1 #2&#xA;[  176.296314] Hardware name: linux,dummy-virt (DT)&#xA;[  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS&#xA;BTYPE=--)&#xA;[  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]&#xA;[  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]&#xA;[  176.297636] sp : ffff800080003630&#xA;[  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:&#xA;ffff6828c49ad9f8&#xA;[  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:&#xA;00000000000003e8&#xA;[  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:&#xA;ffff6828c3b16d28&#xA;[  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:&#xA;0000000000000014&#xA;[  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:&#xA;0000000095744632&#xA;[  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:&#xA;ffffb7e137926a70&#xA;[  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :&#xA;0000000000000000&#xA;[  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :&#xA;f20e0100bebafeca&#xA;[  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :&#xA;0000000000000000&#xA;[  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :&#xA;ffff6828c7f918f0&#xA;[  176.300889] Call trace:&#xA;[  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]&#xA;[  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]&#xA;[  176.301703]  nf_hook_slow+0x48/0x124&#xA;[  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]&#xA;[  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]&#xA;[  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]&#xA;[  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]&#xA;[  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]&#xA;[  176.303359]  nf_hook_slow+0x48/0x124&#xA;[  176.303&#xA;---truncated---&#xA;CVE-2024-50062:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/rtrs-srv: Avoid null pointer deref during path establishment&#xA;For RTRS path establishment, RTRS client initiates and completes con_num&#xA;of connections. After establishing all its connections, the information&#xA;is exchanged between the client and server through the info_req message.&#xA;During this exchange, it is essential that all connections have been&#xA;established, and the state of the RTRS srv path is CONNECTED.&#xA;So add these sanity checks, to make sure we detect and abort process in&#xA;error scenarios to avoid null pointer deref.&#xA;CVE-2022-48969:In the Linux kernel, the following vulnerability has been resolved:&#xA;xen-netfront: Fix NULL sring after live migration&#xA;A NAPI is setup for each network sring to poll data to kernel&#xA;The sring with source host is destroyed before live migration and&#xA;new sring with target host is setup after live migration.&#xA;The NAPI for the old sring is not deleted until setup new sring&#xA;with target host after migration. With busy_poll/busy_read enabled,&#xA;the NAPI can be polled before got deleted when resume VM.&#xA;BUG: unable to handle kernel NULL pointer dereference at&#xA;0000000000000008&#xA;IP: xennet_poll+0xae/0xd20&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] SMP PTI&#xA;Call Trace:&#xA; finish_task_switch+0x71/0x230&#xA; timerqueue_del+0x1d/0x40&#xA; hrtimer_try_to_cancel+0xb5/0x110&#xA; xennet_alloc_rx_buffers+0x2a0/0x2a0&#xA; napi_busy_loop+0xdb/0x270&#xA; sock_poll+0x87/0x90&#xA; do_sys_poll+0x26f/0x580&#xA; tracing_map_insert+0x1d4/0x2f0&#xA; event_hist_trigger+0x14a/0x260&#xA; finish_task_switch+0x71/0x230&#xA; __schedule+0x256/0x890&#xA; recalc_sigpending+0x1b/0x50&#xA; xen_sched_clock+0x15/0x20&#xA; __rb_reserve_next+0x12d/0x140&#xA; ring_buffer_lock_reserve+0x123/0x3d0&#xA; event_triggers_call+0x87/0xb0&#xA; trace_event_buffer_commit+0x1c4/0x210&#xA; xen_clocksource_get_cycles+0x15/0x20&#xA; ktime_get_ts64+0x51/0xf0&#xA; SyS_ppoll+0x160/0x1a0&#xA; SyS_ppoll+0x160/0x1a0&#xA; do_syscall_64+0x73/0x130&#xA; entry_SYSCALL_64_after_hwframe+0x41/0xa6&#xA;...&#xA;RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900&#xA;CR2: 0000000000000008&#xA;---[ end trace f8601785b354351c ]---&#xA;xen frontend should remove the NAPIs for the old srings before live&#xA;migration as the bond srings are destroyed&#xA;There is a tiny window between the srings are set to NULL and&#xA;the NAPIs are disabled, It is safe as the NAPI threads are still&#xA;frozen at that time&#xA;CVE-2024-50073:In the Linux kernel, the following vulnerability has been resolved:&#xA;tty: n_gsm: Fix use-after-free in gsm_cleanup_mux&#xA;BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0&#xA;drivers/tty/n_gsm.c:3160 [n_gsm]&#xA;Read of size 8 at addr ffff88815fe99c00 by task poc/3379&#xA;CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56&#xA;Hardware name: VMware, Inc. VMware Virtual Platform/440BX&#xA;Desktop Reference Platform, BIOS 6.00 11/12/2020&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]&#xA; __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]&#xA; __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389&#xA; update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500&#xA; __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846&#xA; __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161&#xA; gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]&#xA; _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107&#xA; __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]&#xA; ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195&#xA; ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79&#xA; __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338&#xA; __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805&#xA; tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818&#xA;Allocated by task 65:&#xA; gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]&#xA; gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]&#xA; gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]&#xA; gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]&#xA; tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391&#xA; tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39&#xA; flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445&#xA; process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229&#xA; worker_thread+0x3dc/0x950 kernel/workqueue.c:3391&#xA; kthread+0x2a3/0x370 kernel/kthread.c:389&#xA; ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257&#xA;Freed by task 3367:&#xA; kfree+0x126/0x420 mm/slub.c:4580&#xA; gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]&#xA; gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]&#xA; tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818&#xA;[Analysis]&#xA;gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux&#xA;can be freed by multi threads through ioctl,which leads&#xA;to the occurrence of uaf. Protect it by gsm tx lock.&#xA;CVE-2024-50089:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-50143:In the Linux kernel, the following vulnerability has been resolved:&#xA;udf: fix uninit-value use in udf_get_fileshortad&#xA;Check for overflow when computing alen in udf_current_aext to mitigate&#xA;later uninit-value use in udf_get_fileshortad KMSAN bug[1].&#xA;After applying the patch reproducer did not trigger any issue[2].&#xA;[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df&#xA;[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000&#xA;CVE-2024-50179:In the Linux kernel, the following vulnerability has been resolved:&#xA;ceph: remove the incorrect Fw reference check when dirtying pages&#xA;When doing the direct-io reads it will also try to mark pages dirty,&#xA;but for the read path it won&#39;t hold the Fw caps and there is case&#xA;will it get the Fw reference.&#xA;CVE-2024-50180:In the Linux kernel, the following vulnerability has been resolved:&#xA;fbdev: sisfb: Fix strbuf array overflow&#xA;The values of the variables xres and yres are placed in strbuf.&#xA;These variables are obtained from strbuf1.&#xA;The strbuf1 array contains digit characters&#xA;and a space if the array contains non-digit characters.&#xA;Then, when executing sprintf(strbuf, &#34;%ux%ux8&#34;, xres, yres);&#xA;more than 16 bytes will be written to strbuf.&#xA;It is suggested to increase the size of the strbuf array to 24.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-50192:In the Linux kernel, the following vulnerability has been resolved:&#xA;irqchip/gic-v4: Don&#39;t allow a VMOVP on a dying VPE&#xA;Kunkun Jiang reported that there is a small window of opportunity for&#xA;userspace to force a change of affinity for a VPE while the VPE has already&#xA;been unmapped, but the corresponding doorbell interrupt still visible in&#xA;/proc/irq/.&#xA;Plug the race by checking the value of vmapp_count, which tracks whether&#xA;the VPE is mapped ot not, and returning an error in this case.&#xA;This involves making vmapp_count common to both GICv4.1 and its v4.0&#xA;ancestor.&#xA;CVE-2024-50202:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: propagate directory read errors from nilfs_find_entry()&#xA;Syzbot reported that a task hang occurs in vcs_open() during a fuzzing&#xA;test for nilfs2.&#xA;The root cause of this problem is that in nilfs_find_entry(), which&#xA;searches for directory entries, ignores errors when loading a directory&#xA;page/folio via nilfs_get_folio() fails.&#xA;If the filesystem images is corrupted, and the i_size of the directory&#xA;inode is large, and the directory page/folio is successfully read but&#xA;fails the sanity check, for example when it is zero-filled,&#xA;nilfs_check_folio() may continue to spit out error messages in bursts.&#xA;Fix this issue by propagating the error to the callers when loading a&#xA;page/folio fails in nilfs_find_entry().&#xA;The current interface of nilfs_find_entry() and its callers is outdated&#xA;and cannot propagate error codes such as -EIO and -ENOMEM returned via&#xA;nilfs_find_entry(), so fix it together.&#xA;CVE-2024-50205:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()&#xA;The step variable is initialized to zero. It is changed in the loop,&#xA;but if it&#39;s not changed it will remain zero. Add a variable check&#xA;before the division.&#xA;The observed behavior was introduced by commit 826b5de90c0b&#xA;(&#34;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size&#34;),&#xA;and it is difficult to show that any of the interval parameters will&#xA;satisfy the snd_interval_test() condition with data from the&#xA;amdtp_rate_table[] table.&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-50229:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix potential deadlock with newly created symlinks&#xA;Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers&#xA;memory reclamation involving the filesystem layer, which can result in&#xA;circular lock dependencies among the reader/writer semaphore&#xA;nilfs-&gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the&#xA;fs_reclaim pseudo lock.&#xA;This is because after commit 21fc61c73c39 (&#34;don&#39;t put symlink bodies in&#xA;pagecache into highmem&#34;), the gfp flags of the page cache for symbolic&#xA;links are overwritten to GFP_KERNEL via inode_nohighmem().&#xA;This is not a problem for symlinks read from the backing device, because&#xA;the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,&#xA;when a new symlink is created with nilfs_symlink(), the gfp flags remain&#xA;overwritten to GFP_KERNEL.  Then, memory allocation called from&#xA;page_symlink() etc.  triggers memory reclamation including the FS layer,&#xA;which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can&#xA;cause a deadlock if they are called while nilfs-&gt;ns_segctor_sem is held:&#xA;Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags&#xA;of newly created symlinks in the same way that nilfs_new_inode() and&#xA;__nilfs_read_inode() do, as a workaround until we adopt nofs allocation&#xA;scope consistently or improve the locking constraints.&#xA;CVE-2024-50262:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix out-of-bounds write in trie_get_next_key()&#xA;trie_get_next_key() allocates a node stack with size trie-&gt;max_prefixlen,&#xA;while it writes (trie-&gt;max_prefixlen + 1) nodes to the stack when it has&#xA;full paths from the root to leaves. For example, consider a trie with&#xA;max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...&#xA;0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with&#xA;.prefixlen = 8 make 9 nodes be written on the node stack with size 8.&#xA;CVE-2024-50248:In the Linux kernel, the following vulnerability has been resolved:&#xA;ntfs3: Add bounds checking to mi_enum_attr()&#xA;Added bounds checking to make sure that every attr don&#39;t stray beyond&#xA;valid memory region.&#xA;CVE-2024-50244:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs/ntfs3: Additional check in ni_clear()&#xA;Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to&#xA;uninitialized bitmap during replay process.&#xA;CVE-2024-50241:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSD: Initialize struct nfsd4_copy earlier&#xA;Ensure the refcount and async_copies fields are initialized early.&#xA;cleanup_async_copy() will reference these fields if an error occurs&#xA;in nfsd4_copy(). If they are not correctly initialized, at the very&#xA;least, a refcount underflow occurs.&#xA;CVE-2024-50230:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix kernel bug due to missing clearing of checked flag&#xA;Syzbot reported that in directory operations after nilfs2 detects&#xA;filesystem corruption and degrades to read-only,&#xA;__block_write_begin_int(), which is called to prepare block writes, may&#xA;fail the BUG_ON check for accesses exceeding the folio/page size,&#xA;triggering a kernel bug.&#xA;This was found to be because the &#34;checked&#34; flag of a page/folio was not&#xA;cleared when it was discarded by nilfs2&#39;s own routine, which causes the&#xA;sanity check of directory entries to be skipped when the directory&#xA;page/folio is reloaded.  So, fix that.&#xA;This was necessary when the use of nilfs2&#39;s own page discard routine was&#xA;applied to more than just metadata files.&#xA;CVE-2024-50151:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: fix OOBs when building SMB2_IOCTL request&#xA;When using encryption, either enforced by the server or when using&#xA;&#39;seal&#39; mount option, the client will squash all compound request buffers&#xA;down for encryption into a single iov in smb2_set_next_command().&#xA;SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the&#xA;SMB2_IOCTL request in the first iov, and if the user passes an input&#xA;buffer that is greater than 328 bytes, smb2_set_next_command() will&#xA;end up writing off the end of @rqst-&gt;iov[0].iov_base as shown below:&#xA;  mount.cifs //srv/share /mnt -o ...,seal&#xA;  ln -s $(perl -e &#34;print(&#39;a&#39;)for 1..1024&#34;) /mnt/link&#xA;  BUG: KASAN: slab-out-of-bounds in&#xA;  smb2_set_next_command.cold+0x1d6/0x24c [cifs]&#xA;  Write of size 4116 at addr ffff8881148fcab8 by task ln/859&#xA;  CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1&#xA;  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS&#xA;  1.16.3-2.fc40 04/01/2014&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x5d/0x80&#xA;   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]&#xA;   print_report+0x156/0x4d9&#xA;   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]&#xA;   ? __virt_addr_valid+0x145/0x310&#xA;   ? __phys_addr+0x46/0x90&#xA;   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]&#xA;   kasan_report+0xda/0x110&#xA;   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]&#xA;   kasan_check_range+0x10f/0x1f0&#xA;   __asan_memcpy+0x3c/0x60&#xA;   smb2_set_next_command.cold+0x1d6/0x24c [cifs]&#xA;   smb2_compound_op+0x238c/0x3840 [cifs]&#xA;   ? kasan_save_track+0x14/0x30&#xA;   ? kasan_save_free_info+0x3b/0x70&#xA;   ? vfs_symlink+0x1a1/0x2c0&#xA;   ? do_symlinkat+0x108/0x1c0&#xA;   ? __pfx_smb2_compound_op+0x10/0x10 [cifs]&#xA;   ? kmem_cache_free+0x118/0x3e0&#xA;   ? cifs_get_writable_path+0xeb/0x1a0 [cifs]&#xA;   smb2_get_reparse_inode+0x423/0x540 [cifs]&#xA;   ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs]&#xA;   ? rcu_is_watching+0x20/0x50&#xA;   ? __kmalloc_noprof+0x37c/0x480&#xA;   ? smb2_create_reparse_symlink+0x257/0x490 [cifs]&#xA;   ? smb2_create_reparse_symlink+0x38f/0x490 [cifs]&#xA;   smb2_create_reparse_symlink+0x38f/0x490 [cifs]&#xA;   ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs]&#xA;   ? find_held_lock+0x8a/0xa0&#xA;   ? hlock_class+0x32/0xb0&#xA;   ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs]&#xA;   cifs_symlink+0x24f/0x960 [cifs]&#xA;   ? __pfx_make_vfsuid+0x10/0x10&#xA;   ? __pfx_cifs_symlink+0x10/0x10 [cifs]&#xA;   ? make_vfsgid+0x6b/0xc0&#xA;   ? generic_permission+0x96/0x2d0&#xA;   vfs_symlink+0x1a1/0x2c0&#xA;   do_symlinkat+0x108/0x1c0&#xA;   ? __pfx_do_symlinkat+0x10/0x10&#xA;   ? strncpy_from_user+0xaa/0x160&#xA;   __x64_sys_symlinkat+0xb9/0xf0&#xA;   do_syscall_64+0xbb/0x1d0&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;  RIP: 0033:0x7f08d75c13bb&#xA;CVE-2024-50301:In the Linux kernel, the following vulnerability has been resolved:&#xA;security/keys: fix slab-out-of-bounds in key_task_permission&#xA;KASAN reports an out of bounds read:&#xA;BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36&#xA;BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410&#xA;security/keys/permission.c:54&#xA;Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362&#xA;CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15&#xA;Call Trace:&#xA; __dump_stack lib/dump_stack.c:82 [inline]&#xA; dump_stack+0x107/0x167 lib/dump_stack.c:123&#xA; print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400&#xA; __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560&#xA; kasan_report+0x3a/0x50 mm/kasan/report.c:585&#xA; __kuid_val include/linux/uidgid.h:36 [inline]&#xA; uid_eq include/linux/uidgid.h:63 [inline]&#xA; key_task_permission+0x394/0x410 security/keys/permission.c:54&#xA; search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793&#xA;This issue was also reported by syzbot.&#xA;It can be reproduced by following these steps(more details [1]):&#xA;1. Obtain more than 32 inputs that have similar hashes, which ends with the&#xA;   pattern &#39;0xxxxxxxe6&#39;.&#xA;2. Reboot and add the keys obtained in step 1.&#xA;The reproducer demonstrates how this issue happened:&#xA;1. In the search_nested_keyrings function, when it iterates through the&#xA;   slots in a node(below tag ascend_to_node), if the slot pointer is meta&#xA;   and node-&gt;back_pointer != NULL(it means a root), it will proceed to&#xA;   descend_to_node. However, there is an exception. If node is the root,&#xA;   and one of the slots points to a shortcut, it will be treated as a&#xA;   keyring.&#xA;2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.&#xA;   However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as&#xA;   ASSOC_ARRAY_PTR_SUBTYPE_MASK.&#xA;3. When 32 keys with the similar hashes are added to the tree, the ROOT&#xA;   has keys with hashes that are not similar (e.g. slot 0) and it splits&#xA;   NODE A without using a shortcut. When NODE A is filled with keys that&#xA;   all hashes are xxe6, the keys are similar, NODE A will split with a&#xA;   shortcut. Finally, it forms the tree as shown below, where slot 6 points&#xA;   to a shortcut.&#xA;                      NODE A&#xA;              +------&gt;+---+&#xA;      ROOT    |       | 0 | xxe6&#xA;      +---+   |       +---+&#xA; xxxx | 0 | shortcut  :   : xxe6&#xA;      +---+   |       +---+&#xA; xxe6 :   :   |       |   | xxe6&#xA;      +---+   |       +---+&#xA;      | 6 |---+       :   : xxe6&#xA;      +---+           +---+&#xA; xxe6 :   :           | f | xxe6&#xA;      +---+           +---+&#xA; xxe6 | f |&#xA;      +---+&#xA;4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,&#xA;   it may be mistakenly transferred to a key*, leading to a read&#xA;   out-of-bounds read.&#xA;To fix this issue, one should jump to descend_to_node if the ptr is a&#xA;shortcut, regardless of whether the node is root or not.&#xA;[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/&#xA;[jarkko: tweaked the commit message a bit to have an appropriate closes&#xA; tag.]&#xA;CVE-2024-50289:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: av7110: fix a spectre vulnerability&#xA;As warned by smatch:&#xA;&#x9;drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue &#39;av7110-&gt;ci_slot&#39; [w] (local cap)&#xA;There is a spectre-related vulnerability at the code. Fix it.&#xA;CVE-2024-50273:In the Linux kernel, the following vulnerability has been resolved:&#xA;btrfs: reinitialize delayed ref list after deleting it from the list&#xA;At insert_delayed_ref() if we need to update the action of an existing&#xA;ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head&#39;s&#xA;ref_add_list using list_del(), which leaves the ref&#39;s add_list member&#xA;not reinitialized, as list_del() sets the next and prev members of the&#xA;list to LIST_POISON1 and LIST_POISON2, respectively.&#xA;If later we end up calling drop_delayed_ref() against the ref, which can&#xA;happen during merging or when destroying delayed refs due to a transaction&#xA;abort, we can trigger a crash since at drop_delayed_ref() we call&#xA;list_empty() against the ref&#39;s add_list, which returns false since&#xA;the list was not reinitialized after the list_del() and as a consequence&#xA;we call list_del() again at drop_delayed_ref(). This results in an&#xA;invalid list access since the next and prev members are set to poison&#xA;pointers, resulting in a splat if CONFIG_LIST_HARDENED and&#xA;CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences&#xA;otherwise.&#xA;So fix this by deleting from the list with list_del_init() instead.&#xA;CVE-2024-50269:In the Linux kernel, the following vulnerability has been resolved:&#xA;usb: musb: sunxi: Fix accessing an released usb phy&#xA;Commit 6ed05c68cbca (&#34;usb: musb: sunxi: Explicitly release USB PHY on&#xA;exit&#34;) will cause that usb phy @glue-&gt;xceiv is accessed after released.&#xA;1) register platform driver @sunxi_musb_driver&#xA;// get the usb phy @glue-&gt;xceiv&#xA;sunxi_musb_probe() -&gt; devm_usb_get_phy().&#xA;2) register and unregister platform driver @musb_driver&#xA;musb_probe() -&gt; sunxi_musb_init()&#xA;use the phy here&#xA;//the phy is released here&#xA;musb_remove() -&gt; sunxi_musb_exit() -&gt; devm_usb_put_phy()&#xA;3) register @musb_driver again&#xA;musb_probe() -&gt; sunxi_musb_init()&#xA;use the phy here but the phy has been released at 2).&#xA;...&#xA;Fixed by reverting the commit, namely, removing devm_usb_put_phy()&#xA;from sunxi_musb_exit().&#xA;CVE-2024-50265:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()&#xA;Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():&#xA;[   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12&#xA;[   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry&#xA;[   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004&#xA;[...]&#xA;[   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0&#xA;[...]&#xA;[   57.331328] Call Trace:&#xA;[   57.331477]  &lt;TASK&gt;&#xA;[...]&#xA;[   57.333511]  ? do_user_addr_fault+0x3e5/0x740&#xA;[   57.333778]  ? exc_page_fault+0x70/0x170&#xA;[   57.334016]  ? asm_exc_page_fault+0x2b/0x30&#xA;[   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10&#xA;[   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0&#xA;[   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0&#xA;[   57.335164]  ocfs2_xa_set+0x704/0xcf0&#xA;[   57.335381]  ? _raw_spin_unlock+0x1a/0x40&#xA;[   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20&#xA;[   57.335915]  ? trace_preempt_on+0x1e/0x70&#xA;[   57.336153]  ? start_this_handle+0x16c/0x500&#xA;[   57.336410]  ? preempt_count_sub+0x50/0x80&#xA;[   57.336656]  ? _raw_read_unlock+0x20/0x40&#xA;[   57.336906]  ? start_this_handle+0x16c/0x500&#xA;[   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0&#xA;[   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0&#xA;[   57.337706]  ? ocfs2_start_trans+0x13d/0x290&#xA;[   57.337971]  ocfs2_xattr_set+0xb13/0xfb0&#xA;[   57.338207]  ? dput+0x46/0x1c0&#xA;[   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30&#xA;[   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30&#xA;[   57.338948]  __vfs_removexattr+0x92/0xc0&#xA;[   57.339182]  __vfs_removexattr_locked+0xd5/0x190&#xA;[   57.339456]  ? preempt_count_sub+0x50/0x80&#xA;[   57.339705]  vfs_removexattr+0x5f/0x100&#xA;[...]&#xA;Reproducer uses faultinject facility to fail ocfs2_xa_remove() -&gt;&#xA;ocfs2_xa_value_truncate() with -ENOMEM.&#xA;In this case the comment mentions that we can return 0 if&#xA;ocfs2_xa_cleanup_value_truncate() is going to wipe the entry&#xA;anyway. But the following &#39;rc&#39; check is wrong and execution flow do&#xA;&#39;ocfs2_xa_remove_entry(loc);&#39; twice:&#xA;* 1st: in ocfs2_xa_cleanup_value_truncate();&#xA;* 2nd: returning back to ocfs2_xa_remove() instead of going to &#39;out&#39;.&#xA;Fix this by skipping the 2nd removal of the same entry and making&#xA;syzkaller repro happy.&#xA;CVE-2024-53052:In the Linux kernel, the following vulnerability has been resolved:&#xA;io_uring/rw: fix missing NOWAIT check for O_DIRECT start write&#xA;When io_uring starts a write, it&#39;ll call kiocb_start_write() to bump the&#xA;super block rwsem, preventing any freezes from happening while that&#xA;write is in-flight. The freeze side will grab that rwsem for writing,&#xA;excluding any new writers from happening and waiting for existing writes&#xA;to finish. But io_uring unconditionally uses kiocb_start_write(), which&#xA;will block if someone is currently attempting to freeze the mount point.&#xA;This causes a deadlock where freeze is waiting for previous writes to&#xA;complete, but the previous writes cannot complete, as the task that is&#xA;supposed to complete them is blocked waiting on starting a new write.&#xA;This results in the following stuck trace showing that dependency with&#xA;the write blocked starting a new write:&#xA;task:fio             state:D stack:0     pid:886   tgid:886   ppid:876&#xA;Call trace:&#xA; __switch_to+0x1d8/0x348&#xA; __schedule+0x8e8/0x2248&#xA; schedule+0x110/0x3f0&#xA; percpu_rwsem_wait+0x1e8/0x3f8&#xA; __percpu_down_read+0xe8/0x500&#xA; io_write+0xbb8/0xff8&#xA; io_issue_sqe+0x10c/0x1020&#xA; io_submit_sqes+0x614/0x2110&#xA; __arm64_sys_io_uring_enter+0x524/0x1038&#xA; invoke_syscall+0x74/0x268&#xA; el0_svc_common.constprop.0+0x160/0x238&#xA; do_el0_svc+0x44/0x60&#xA; el0_svc+0x44/0xb0&#xA; el0t_64_sync_handler+0x118/0x128&#xA; el0t_64_sync+0x168/0x170&#xA;INFO: task fsfreeze:7364 blocked for more than 15 seconds.&#xA;      Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963&#xA;with the attempting freezer stuck trying to grab the rwsem:&#xA;task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995&#xA;Call trace:&#xA; __switch_to+0x1d8/0x348&#xA; __schedule+0x8e8/0x2248&#xA; schedule+0x110/0x3f0&#xA; percpu_down_write+0x2b0/0x680&#xA; freeze_super+0x248/0x8a8&#xA; do_vfs_ioctl+0x149c/0x1b18&#xA; __arm64_sys_ioctl+0xd0/0x1a0&#xA; invoke_syscall+0x74/0x268&#xA; el0_svc_common.constprop.0+0x160/0x238&#xA; do_el0_svc+0x44/0x60&#xA; el0_svc+0x44/0xb0&#xA; el0t_64_sync_handler+0x118/0x128&#xA; el0t_64_sync+0x168/0x170&#xA;Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a&#xA;blocking grab of the super block rwsem if it isn&#39;t set. For normal issue&#xA;where IOCB_NOWAIT would always be set, this returns -EAGAIN which will&#xA;have io_uring core issue a blocking attempt of the write. That will in&#xA;turn also get completions run, ensuring forward progress.&#xA;Since freezing requires CAP_SYS_ADMIN in the first place, this isn&#39;t&#xA;something that can be triggered by a regular user.&#xA;CVE-2024-53066:In the Linux kernel, the following vulnerability has been resolved:&#xA;nfs: Fix KMSAN warning in decode_getfattr_attrs()&#xA;Fix the following KMSAN warning:&#xA;CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B&#xA;Tainted: [B]=BAD_PAGE&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)&#xA;=====================================================&#xA;=====================================================&#xA;BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90&#xA; decode_getfattr_attrs+0x2d6d/0x2f90&#xA; decode_getfattr_generic+0x806/0xb00&#xA; nfs4_xdr_dec_getattr+0x1de/0x240&#xA; rpcauth_unwrap_resp_decode+0xab/0x100&#xA; rpcauth_unwrap_resp+0x95/0xc0&#xA; call_decode+0x4ff/0xb50&#xA; __rpc_execute+0x57b/0x19d0&#xA; rpc_execute+0x368/0x5e0&#xA; rpc_run_task+0xcfe/0xee0&#xA; nfs4_proc_getattr+0x5b5/0x990&#xA; __nfs_revalidate_inode+0x477/0xd00&#xA; nfs_access_get_cached+0x1021/0x1cc0&#xA; nfs_do_access+0x9f/0xae0&#xA; nfs_permission+0x1e4/0x8c0&#xA; inode_permission+0x356/0x6c0&#xA; link_path_walk+0x958/0x1330&#xA; path_lookupat+0xce/0x6b0&#xA; filename_lookup+0x23e/0x770&#xA; vfs_statx+0xe7/0x970&#xA; vfs_fstatat+0x1f2/0x2c0&#xA; __se_sys_newfstatat+0x67/0x880&#xA; __x64_sys_newfstatat+0xbd/0x120&#xA; x64_sys_call+0x1826/0x3cf0&#xA; do_syscall_64+0xd0/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;The KMSAN warning is triggered in decode_getfattr_attrs(), when calling&#xA;decode_attr_mdsthreshold(). It appears that fattr-&gt;mdsthreshold is not&#xA;initialized.&#xA;Fix the issue by initializing fattr-&gt;mdsthreshold to NULL in&#xA;nfs_fattr_init().&#xA;CVE-2024-53061:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: s5p-jpeg: prevent buffer overflows&#xA;The current logic allows word to be less than 2. If this happens,&#xA;there will be buffer overflows, as reported by smatch. Add extra&#xA;checks to prevent it.&#xA;While here, remove an unused word = 0 assignment.&#xA;CVE-2024-46813:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check link_index before accessing dc-&gt;links[]&#xA;[WHY &amp; HOW]&#xA;dc-&gt;links[] has max size of MAX_LINKS and NULL is return when trying to&#xA;access with out-of-bound index.&#xA;This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.&#xA;CVE-2024-47707:In the Linux kernel, the following vulnerability has been resolved:&#xA;ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()&#xA;Blamed commit accidentally removed a check for rt-&gt;rt6i_idev being NULL,&#xA;as spotted by syzbot:&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA; RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]&#xA; RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914&#xA;Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06&#xA;RSP: 0018:ffffc900047374e0 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0&#xA;RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c&#xA;R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18&#xA;R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930&#xA;FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856&#xA; addrconf_notify+0x3cb/0x1020&#xA;  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93&#xA;  call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]&#xA;  call_netdevice_notifiers net/core/dev.c:2046 [inline]&#xA;  unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352&#xA;  unregister_netdevice_many net/core/dev.c:11414 [inline]&#xA;  unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289&#xA;  unregister_netdevice include/linux/netdevice.h:3129 [inline]&#xA;  __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685&#xA;  tun_detach drivers/net/tun.c:701 [inline]&#xA;  tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510&#xA;  __fput+0x24a/0x8a0 fs/file_table.c:422&#xA;  task_work_run+0x24f/0x310 kernel/task_work.c:228&#xA;  exit_task_work include/linux/task_work.h:40 [inline]&#xA;  do_exit+0xa2f/0x27f0 kernel/exit.c:882&#xA;  do_group_exit+0x207/0x2c0 kernel/exit.c:1031&#xA;  __do_sys_exit_group kernel/exit.c:1042 [inline]&#xA;  __se_sys_exit_group kernel/exit.c:1040 [inline]&#xA;  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040&#xA;  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f1acc77def9&#xA;Code: Unable to access opcode bytes at 0x7f1acc77decf.&#xA;RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7&#xA;RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043&#xA;RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001&#xA;R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;---[ end trace 0000000000000000 ]---&#xA; RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]&#xA; RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914&#xA;Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06&#xA;RSP: 0018:ffffc900047374e0 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0&#xA;R&#xA;---truncated---&#xA;CVE-2024-47718:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: rtw88: always wait for both firmware loading attempts&#xA;In &#39;rtw_wait_firmware_completion()&#39;, always wait for both (regular and&#xA;wowlan) firmware loading attempts. Otherwise if &#39;rtw_usb_intf_init()&#39;&#xA;has failed in &#39;rtw_usb_probe()&#39;, &#39;rtw_usb_disconnect()&#39; may issue&#xA;&#39;ieee80211_free_hw()&#39; when one of &#39;rtw_load_firmware_cb()&#39; (usually&#xA;the wowlan one) is still in progress, causing UAF detected by KASAN.&#xA;CVE-2024-49930:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath11k: fix array out-of-bound access in SoC stats&#xA;Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a&#xA;maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()&#xA;function access ath11k_soc_dp_stats::hal_reo_error using the REO&#xA;destination SRNG ring ID, which is incorrect. SRNG ring ID differ from&#xA;normal ring ID, and this usage leads to out-of-bounds array access. To fix&#xA;this issue, modify ath11k_dp_process_rx() to use the normal ring ID&#xA;directly instead of the SRNG ring ID to avoid out-of-bounds array access.&#xA;Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1&#xA;CVE-2024-49977:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: stmmac: Fix zero-division error when disabling tc cbs&#xA;The commit b8c43360f6e4 (&#34;net: stmmac: No need to calculate speed divider&#xA;when offload is disabled&#34;) allows the &#34;port_transmit_rate_kbps&#34; to be&#xA;set to a value of 0, which is then passed to the &#34;div_s64&#34; function when&#xA;tc-cbs is disabled. This leads to a zero-division error.&#xA;When tc-cbs is disabled, the idleslope, sendslope, and credit values the&#xA;credit values are not required to be configured. Therefore, adding a return&#xA;statement after setting the txQ mode to DCB when tc-cbs is disabled would&#xA;prevent a zero-division error.&#xA;CVE-2024-49891:In the Linux kernel, the following vulnerability has been resolved:&#xA;scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths&#xA;When the HBA is undergoing a reset or is handling an errata event, NULL ptr&#xA;dereference crashes may occur in routines such as&#xA;lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or&#xA;lpfc_abort_handler().&#xA;Add NULL ptr checks before dereferencing hdwq pointers that may have been&#xA;freed due to operations colliding with a reset or errata event handler.&#xA;CVE-2024-49938:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit&#xA;Syzbot points out that skb_trim() has a sanity check on the existing length of&#xA;the skb, which can be uninitialised in some error paths. The intent here is&#xA;clearly just to reset the length to zero before resubmitting, so switch to&#xA;calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()&#xA;already contains a call to skb_reset_tail_pointer(), so remove the redundant&#xA;call.&#xA;The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there&#39;s a similar&#xA;usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we&#39;re at it.&#xA;CVE-2024-49997:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: ethernet: lantiq_etop: fix memory disclosure&#xA;When applying padding, the buffer is not zeroed, which results in memory&#xA;disclosure. The mentioned data is observed on the wire. This patch uses&#xA;skb_put_padto() to pad Ethernet frames properly. The mentioned function&#xA;zeroes the expanded buffer.&#xA;In case the packet cannot be padded it is silently dropped. Statistics&#xA;are also not incremented. This driver does not support statistics in the&#xA;old 32-bit format or the new 64-bit format. These will be added in the&#xA;future. In its current form, the patch should be easily backported to&#xA;stable versions.&#xA;Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets&#xA;in hardware, so software padding must be applied.&#xA;CVE-2024-49944:In the Linux kernel, the following vulnerability has been resolved:&#xA;sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start&#xA;In sctp_listen_start() invoked by sctp_inet_listen(), it should set the&#xA;sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.&#xA;Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)-&gt;reuse&#xA;is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)-&gt;bind_hash will&#xA;be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash&#xA;is NULL.&#xA;  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;  RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   __sys_listen_socket net/socket.c:1883 [inline]&#xA;   __sys_listen+0x1b7/0x230 net/socket.c:1894&#xA;   __do_sys_listen net/socket.c:1902 [inline]&#xA;CVE-2024-50024:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: Fix an unsafe loop on the list&#xA;The kernel may crash when deleting a genetlink family if there are still&#xA;listeners for that family:&#xA;Oops: Kernel access of bad area, sig: 11 [#1]&#xA;  ...&#xA;  NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0&#xA;  LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0&#xA;  Call Trace:&#xA;__netlink_clear_multicast_users+0x74/0xc0&#xA;genl_unregister_family+0xd4/0x2d0&#xA;Change the unsafe loop on the list to a safe one, because inside the&#xA;loop there is an element removal from this list.&#xA;CVE-2024-50044:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change&#xA;rfcomm_sk_state_change attempts to use sock_lock so it must never be&#xA;called with it locked but rfcomm_sock_ioctl always attempt to lock it&#xA;causing the following trace:&#xA;======================================================&#xA;WARNING: possible circular locking dependency detected&#xA;6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted&#xA;------------------------------------------------------&#xA;syz-executor386/5093 is trying to acquire lock:&#xA;ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]&#xA;ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73&#xA;but task is already holding lock:&#xA;ffff88807badfd28 (&amp;d-&gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491&#xA;CVE-2024-50039:In the Linux kernel, the following vulnerability has been resolved:&#xA;net/sched: accept TCA_STAB only for root qdisc&#xA;Most qdiscs maintain their backlog using qdisc_pkt_len(skb)&#xA;on the assumption it is invariant between the enqueue()&#xA;and dequeue() handlers.&#xA;Unfortunately syzbot can crash a host rather easily using&#xA;a TBF + SFQ combination, with an STAB on SFQ [1]&#xA;We can&#39;t support TCA_STAB on arbitrary level, this would&#xA;require to maintain per-qdisc storage.&#xA;[1]&#xA;[   88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[   88.798611] #PF: supervisor read access in kernel mode&#xA;[   88.799014] #PF: error_code(0x0000) - not-present page&#xA;[   88.799506] PGD 0 P4D 0&#xA;[   88.799829] Oops: Oops: 0000 [#1] SMP NOPTI&#xA;[   88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117&#xA;[   88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq&#xA;[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a &lt;4c&gt; 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00&#xA;All code&#xA;========&#xA;   0:&#x9;0f b7 50 12          &#x9;movzwl 0x12(%rax),%edx&#xA;   4:&#x9;48 8d 04 d5 00 00 00 &#x9;lea    0x0(,%rdx,8),%rax&#xA;   b:&#x9;00&#xA;   c:&#x9;48 89 d6             &#x9;mov    %rdx,%rsi&#xA;   f:&#x9;48 29 d0             &#x9;sub    %rdx,%rax&#xA;  12:&#x9;48 8b 91 c0 01 00 00 &#x9;mov    0x1c0(%rcx),%rdx&#xA;  19:&#x9;48 c1 e0 03          &#x9;shl    $0x3,%rax&#xA;  1d:&#x9;48 01 c2             &#x9;add    %rax,%rdx&#xA;  20:&#x9;66 83 7a 1a 00       &#x9;cmpw   $0x0,0x1a(%rdx)&#xA;  25:&#x9;7e c0                &#x9;jle    0xffffffffffffffe7&#xA;  27:&#x9;48 8b 3a             &#x9;mov    (%rdx),%rdi&#xA;  2a:*&#x9;4c 8b 07             &#x9;mov    (%rdi),%r8&#x9;&#x9;&lt;-- trapping instruction&#xA;  2d:&#x9;4c 89 02             &#x9;mov    %r8,(%rdx)&#xA;  30:&#x9;49 89 50 08          &#x9;mov    %rdx,0x8(%r8)&#xA;  34:&#x9;48 c7 47 08 00 00 00 &#x9;movq   $0x0,0x8(%rdi)&#xA;  3b:&#x9;00&#xA;  3c:&#x9;48                   &#x9;rex.W&#xA;  3d:&#x9;c7                   &#x9;.byte 0xc7&#xA;  3e:&#x9;07                   &#x9;(bad)&#xA;&#x9;...&#xA;Code starting with the faulting instruction&#xA;===========================================&#xA;   0:&#x9;4c 8b 07             &#x9;mov    (%rdi),%r8&#xA;   3:&#x9;4c 89 02             &#x9;mov    %r8,(%rdx)&#xA;   6:&#x9;49 89 50 08          &#x9;mov    %rdx,0x8(%r8)&#xA;   a:&#x9;48 c7 47 08 00 00 00 &#x9;movq   $0x0,0x8(%rdi)&#xA;  11:&#x9;00&#xA;  12:&#x9;48                   &#x9;rex.W&#xA;  13:&#x9;c7                   &#x9;.byte 0xc7&#xA;  14:&#x9;07                   &#x9;(bad)&#xA;&#x9;...&#xA;[   88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206&#xA;[   88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800&#xA;[   88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000&#xA;[   88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f&#xA;[   88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140&#xA;[   88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac&#xA;[   88.806734] FS:  00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000&#xA;[   88.807225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0&#xA;[   88.808165] Call Trace:&#xA;[   88.808459]  &lt;TASK&gt;&#xA;[   88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)&#xA;[   88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)&#xA;[   88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)&#xA;[   88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)&#xA;[   88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq&#xA;[   88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq&#xA;[   88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g&#xA;---truncated---&#xA;CVE-2024-50135:In the Linux kernel, the following vulnerability has been resolved:&#xA;nvme-pci: fix race condition between reset and nvme_dev_disable()&#xA;nvme_dev_disable() modifies the dev-&gt;online_queues field, therefore&#xA;nvme_pci_update_nr_queues() should avoid racing against it, otherwise&#xA;we could end up passing invalid values to blk_mq_update_nr_hw_queues().&#xA; WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347&#xA;          pci_irq_get_affinity+0x187/0x210&#xA; Workqueue: nvme-reset-wq nvme_reset_work [nvme]&#xA; RIP: 0010:pci_irq_get_affinity+0x187/0x210&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? blk_mq_pci_map_queues+0x87/0x3c0&#xA;  ? pci_irq_get_affinity+0x187/0x210&#xA;  blk_mq_pci_map_queues+0x87/0x3c0&#xA;  nvme_pci_map_queues+0x189/0x460 [nvme]&#xA;  blk_mq_update_nr_hw_queues+0x2a/0x40&#xA;  nvme_reset_work+0x1be/0x2a0 [nvme]&#xA;Fix the bug by locking the shutdown_lock mutex before using&#xA;dev-&gt;online_queues. Give up if nvme_dev_disable() is running or if&#xA;it has been executed already.&#xA;CVE-2024-50171:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: systemport: fix potential memory leak in bcm_sysport_xmit()&#xA;The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb&#xA;in case of dma_map_single() fails, add dev_kfree_skb() to fix it.&#xA;CVE-2024-50148:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: bnep: fix wild-memory-access in proto_unregister&#xA;There&#39;s issue as follows:&#xA;  KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]&#xA;  CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W&#xA;  RIP: 0010:proto_unregister+0xee/0x400&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   __do_sys_delete_module+0x318/0x580&#xA;   do_syscall_64+0xc1/0x1d0&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;As bnep_init() ignore bnep_sock_init()&#39;s return value, and bnep_sock_init()&#xA;will cleanup all resource. Then when remove bnep module will call&#xA;bnep_sock_cleanup() to cleanup sock&#39;s resource.&#xA;To solve above issue just return bnep_sock_init()&#39;s return value in&#xA;bnep_exit().&#xA;CVE-2024-50208:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages&#xA;Avoid memory corruption while setting up Level-2 PBL pages for the non MR&#xA;resources when num_pages &gt; 256K.&#xA;There will be a single PDE page address (contiguous pages in the case of &gt;&#xA;PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid&#xA;memory access after 256K PBL entries in the PDE.&#xA;CVE-2024-50209:In the Linux kernel, the following vulnerability has been resolved:&#xA;RDMA/bnxt_re: Add a check for memory allocation&#xA;__alloc_pbl() can return error when memory allocation fails.&#xA;Driver is not checking the status on one of the instances.&#xA;CVE-2024-50196:In the Linux kernel, the following vulnerability has been resolved:&#xA;pinctrl: ocelot: fix system hang on level based interrupts&#xA;The current implementation only calls chained_irq_enter() and&#xA;chained_irq_exit() if it detects pending interrupts.&#xA;```&#xA;for (i = 0; i &lt; info-&gt;stride; i++) {&#xA;&#x9;uregmap_read(info-&gt;map, id_reg + 4 * i, &amp;reg);&#xA;&#x9;if (!reg)&#xA;&#x9;&#x9;continue;&#xA;&#x9;chained_irq_enter(parent_chip, desc);&#xA;```&#xA;However, in case of GPIO pin configured in level mode and the parent&#xA;controller configured in edge mode, GPIO interrupt might be lowered by the&#xA;hardware. In the result, if the interrupt is short enough, the parent&#xA;interrupt is still pending while the GPIO interrupt is cleared;&#xA;chained_irq_enter() never gets called and the system hangs trying to&#xA;service the parent interrupt.&#xA;Moving chained_irq_enter() and chained_irq_exit() outside the for loop&#xA;ensures that they are called even when GPIO interrupt is lowered by the&#xA;hardware.&#xA;The similar code with chained_irq_enter() / chained_irq_exit() functions&#xA;wrapping interrupt checking loop may be found in many other drivers:&#xA;```&#xA;grep -r -A 10 chained_irq_enter drivers/pinctrl&#xA;```&#xA;CVE-2024-50236:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: ath10k: Fix memory leak in management tx&#xA;In the current logic, memory is allocated for storing the MSDU context&#xA;during management packet TX but this memory is not being freed during&#xA;management TX completion. Similar leaks are seen in the management TX&#xA;cleanup logic.&#xA;Kmemleak reports this problem as below,&#xA;unreferenced object 0xffffff80b64ed250 (size 16):&#xA;  comm &#34;kworker/u16:7&#34;, pid 148, jiffies 4294687130 (age 714.199s)&#xA;  hex dump (first 16 bytes):&#xA;    00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......&#xA;  backtrace:&#xA;    [&lt;ffffffe6e7b245dc&gt;] __kmem_cache_alloc_node+0x1e4/0x2d8&#xA;    [&lt;ffffffe6e7adde88&gt;] kmalloc_trace+0x48/0x110&#xA;    [&lt;ffffffe6bbd765fc&gt;] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]&#xA;    [&lt;ffffffe6bbd3eed4&gt;] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]&#xA;    [&lt;ffffffe6e78d5974&gt;] process_scheduled_works+0x1ac/0x400&#xA;    [&lt;ffffffe6e78d60b8&gt;] worker_thread+0x208/0x328&#xA;    [&lt;ffffffe6e78dc890&gt;] kthread+0x100/0x1c0&#xA;    [&lt;ffffffe6e78166c0&gt;] ret_from_fork+0x10/0x20&#xA;Free the memory during completion and cleanup to fix the leak.&#xA;Protect the mgmt_pending_tx idr_remove() operation in&#xA;ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-&gt;data_lock similar to&#xA;other instances.&#xA;Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1&#xA;CVE-2024-50234:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlegacy: Clear stale interrupts before resuming device&#xA;iwl4965 fails upon resume from hibernation on my laptop. The reason&#xA;seems to be a stale interrupt which isn&#39;t being cleared out before&#xA;interrupts are enabled. We end up with a race beween the resume&#xA;trying to bring things back up, and the restart work (queued form&#xA;the interrupt handler) trying to bring things down. Eventually&#xA;the whole thing blows up.&#xA;Fix the problem by clearing out any stale interrupts before&#xA;interrupts get enabled during resume.&#xA;Here&#39;s a debug log of the indicent:&#xA;[   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000&#xA;[   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000&#xA;[   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.&#xA;[   12.042653] iwl4965 0000:10:00.0: On demand firmware reload&#xA;[   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282&#xA;[   12.052207] ieee80211 phy0: il4965_mac_start enter&#xA;[   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff&#xA;[   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready&#xA;[   12.052324] ieee80211 phy0: il_apm_init Init card&#39;s basic functions&#xA;[   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S&#xA;[   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm&#xA;[   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm&#xA;[   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK&#xA;[   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations&#xA;[   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up&#xA;[   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.&#xA;[   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down&#xA;[   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout&#xA;[   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort&#xA;[   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver&#xA;[   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared&#xA;[   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state&#xA;[   12.058827] ieee80211 phy0: _il_apm_stop_master stop master&#xA;[   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.&#xA;[   12.058869] ieee80211 phy0: Hardware restart was requested&#xA;[   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.&#xA;[   16.132303] ------------[ cut here ]------------&#xA;[   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.&#xA;[   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]&#xA;[   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev&#xA;[   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143&#xA;[   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010&#xA;[   16.132463] Workqueue: async async_run_entry_fn&#xA;[   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]&#xA;[   16.132501] Code: da 02 00 0&#xA;---truncated---&#xA;CVE-2024-50299:In the Linux kernel, the following vulnerability has been resolved:&#xA;sctp: properly validate chunk size in sctp_sf_ootb()&#xA;A size validation fix similar to that in Commit 50619dbf8db7 (&#34;sctp: add&#xA;size validation when walking chunks&#34;) is also required in sctp_sf_ootb()&#xA;to address a crash reported by syzbot:&#xA;  BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712&#xA;  sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712&#xA;  sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166&#xA;  sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407&#xA;  sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88&#xA;  sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243&#xA;  sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159&#xA;  ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205&#xA;  ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233&#xA;CVE-2024-53059:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()&#xA;1. The size of the response packet is not validated.&#xA;2. The response buffer is not freed.&#xA;Resolve these issues by switching to iwl_mvm_send_cmd_status(),&#xA;which handles both size validation and frees the buffer.&#xA;CVE-2024-53073:In the Linux kernel, the following vulnerability has been resolved:&#xA;NFSD: Never decrement pending_async_copies on error&#xA;The error flow in nfsd4_copy() calls cleanup_async_copy(), which&#xA;already decrements nn-&gt;pending_async_copies.&#xA;CVE-2024-53063:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: dvbdev: prevent the risk of out of memory access&#xA;The dvbdev contains a static variable used to store dvb minors.&#xA;The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set&#xA;or not. When not set, dvb_register_device() won&#39;t check for&#xA;boundaries, as it will rely that a previous call to&#xA;dvb_register_adapter() would already be enforcing it.&#xA;On a similar way, dvb_device_open() uses the assumption&#xA;that the register functions already did the needed checks.&#xA;This can be fragile if some device ends using different&#xA;calls. This also generate warnings on static check analysers&#xA;like Coverity.&#xA;So, add explicit guards to prevent potential risk of OOM issues.&#xA;CVE-2024-53090:In the Linux kernel, the following vulnerability has been resolved:&#xA;afs: Fix lock recursion&#xA;afs_wake_up_async_call() can incur lock recursion.  The problem is that it&#xA;is called from AF_RXRPC whilst holding the -&gt;notify_lock, but it tries to&#xA;take a ref on the afs_call struct in order to pass it to a work queue - but&#xA;if the afs_call is already queued, we then have an extraneous ref that must&#xA;be put... calling afs_put_call() may call back down into AF_RXRPC through&#xA;rxrpc_kernel_shutdown_call(), however, which might try taking the&#xA;-&gt;notify_lock again.&#xA;This case isn&#39;t very common, however, so defer it to a workqueue.  The oops&#xA;looks something like:&#xA;  BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646&#xA;   lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0&#xA;  CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351&#xA;  Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x47/0x70&#xA;   do_raw_spin_lock+0x3c/0x90&#xA;   rxrpc_kernel_shutdown_call+0x83/0xb0&#xA;   afs_put_call+0xd7/0x180&#xA;   rxrpc_notify_socket+0xa0/0x190&#xA;   rxrpc_input_split_jumbo+0x198/0x1d0&#xA;   rxrpc_input_data+0x14b/0x1e0&#xA;   ? rxrpc_input_call_packet+0xc2/0x1f0&#xA;   rxrpc_input_call_event+0xad/0x6b0&#xA;   rxrpc_input_packet_on_conn+0x1e1/0x210&#xA;   rxrpc_input_packet+0x3f2/0x4d0&#xA;   rxrpc_io_thread+0x243/0x410&#xA;   ? __pfx_rxrpc_io_thread+0x10/0x10&#xA;   kthread+0xcf/0xe0&#xA;   ? __pfx_kthread+0x10/0x10&#xA;   ret_from_fork+0x24/0x40&#xA;   ? __pfx_kthread+0x10/0x10&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;   &lt;/TASK&gt;&#xA;CVE-2024-53099:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Check validity of link-&gt;type in bpf_link_show_fdinfo()&#xA;If a newly-added link type doesn&#39;t invoke BPF_LINK_TYPE(), accessing&#xA;bpf_link_type_strs[link-&gt;type] may result in an out-of-bounds access.&#xA;To spot such missed invocations early in the future, checking the&#xA;validity of link-&gt;type in bpf_link_show_fdinfo() and emitting a warning&#xA;when such invocations are missed.&#xA;CVE-2024-53101:In the Linux kernel, the following vulnerability has been resolved:&#xA;fs: Fix uninitialized value issue in from_kuid and from_kgid&#xA;ocfs2_setattr() uses attr-&gt;ia_mode, attr-&gt;ia_uid and attr-&gt;ia_gid in&#xA;a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren&#39;t set.&#xA;Initialize all fields of newattrs to avoid uninitialized variables, by&#xA;checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.&#xA;CVE-2024-47713:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()&#xA;Since &#39;__dev_queue_xmit()&#39; should be called with interrupts enabled,&#xA;the following backtrace:&#xA;ieee80211_do_stop()&#xA; ...&#xA; spin_lock_irqsave(&amp;local-&gt;queue_stop_reason_lock, flags)&#xA; ...&#xA; ieee80211_free_txskb()&#xA;  ieee80211_report_used_skb()&#xA;   ieee80211_report_ack_skb()&#xA;    cfg80211_mgmt_tx_status_ext()&#xA;     nl80211_frame_tx_status()&#xA;      genlmsg_multicast_netns()&#xA;       genlmsg_multicast_netns_filtered()&#xA;        nlmsg_multicast_filtered()&#xA;&#x9; netlink_broadcast_filtered()&#xA;&#x9;  do_one_broadcast()&#xA;&#x9;   netlink_broadcast_deliver()&#xA;&#x9;    __netlink_sendskb()&#xA;&#x9;     netlink_deliver_tap()&#xA;&#x9;      __netlink_deliver_tap_skb()&#xA;&#x9;       dev_queue_xmit()&#xA;&#x9;        __dev_queue_xmit() ; with IRQS disabled&#xA; ...&#xA; spin_unlock_irqrestore(&amp;local-&gt;queue_stop_reason_lock, flags)&#xA;issues the warning (as reported by syzbot reproducer):&#xA;WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120&#xA;Fix this by implementing a two-phase skb reclamation in&#xA;&#39;ieee80211_do_stop()&#39;, where actual work is performed&#xA;outside of a section with interrupts disabled.&#xA;CVE-2024-49861:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: Fix helper writes to read-only maps&#xA;Lonial found an issue that despite user- and BPF-side frozen BPF map&#xA;(like in case of .rodata), it was still possible to write into it from&#xA;a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}&#xA;as arguments.&#xA;In check_func_arg() when the argument is as mentioned, the meta-&gt;raw_mode&#xA;is never set. Later, check_helper_mem_access(), under the case of&#xA;PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the&#xA;subsequent call to check_map_access_type() and given the BPF map is&#xA;read-only it succeeds.&#xA;The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT&#xA;when results are written into them as opposed to read out of them. The&#xA;latter indicates that it&#39;s okay to pass a pointer to uninitialized memory&#xA;as the memory is written to anyway.&#xA;However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM&#xA;just with additional alignment requirement. So it is better to just get&#xA;rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the&#xA;fixed size memory types. For this, add MEM_ALIGNED to additionally ensure&#xA;alignment given these helpers write directly into the args via *&lt;ptr&gt; = val.&#xA;The .arg*_size has been initialized reflecting the actual sizeof(*&lt;ptr&gt;).&#xA;MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated&#xA;argument types, since in !MEM_FIXED_SIZE cases the verifier does not know&#xA;the buffer size a priori and therefore cannot blindly write *&lt;ptr&gt; = val.&#xA;CVE-2024-49906:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Check null pointer before try to access it&#xA;[why &amp; how]&#xA;Change the order of the pipe_ctx-&gt;plane_state check to ensure that&#xA;plane_state is not null before accessing it.&#xA;CVE-2024-49993:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-49923:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags&#xA;[WHAT &amp; HOW]&#xA;&#34;dcn20_validate_apply_pipe_split_flags&#34; dereferences merge, and thus it&#xA;cannot be a null pointer. Let&#39;s pass a valid pointer to avoid null&#xA;dereference.&#xA;This fixes 2 FORWARD_NULL issues reported by Coverity.&#xA;CVE-2024-50127:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: sched: fix use-after-free in taprio_change()&#xA;In &#39;taprio_change()&#39;, &#39;admin&#39; pointer may become dangling due to sched&#xA;switch / removal caused by &#39;advance_sched()&#39;, and critical section&#xA;protected by &#39;q-&gt;current_entry_lock&#39; is too small to prevent from such&#xA;a scenario (which causes use-after-free detected by KASAN). Fix this&#xA;by prefer &#39;rcu_replace_pointer()&#39; over &#39;rcu_assign_pointer()&#39; to update&#xA;&#39;admin&#39; immediately before an attempt to schedule freeing.&#xA;CVE-2024-50103:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()&#xA;A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could&#xA;possibly return NULL pointer. NULL Pointer Dereference may be&#xA;triggerred without addtional check.&#xA;Add a NULL check for the returned pointer.&#xA;CVE-2024-50134:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA&#xA;Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with&#xA;a real VLA to fix a &#34;memcpy: detected field-spanning write error&#34; warning:&#xA;[   13.319813] memcpy: detected field-spanning write (size 16896) of single field &#34;p-&gt;data&#34; at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)&#xA;[   13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo]&#xA;[   13.320038] Call Trace:&#xA;[   13.320173]  hgsmi_update_pointer_shape [vboxvideo]&#xA;[   13.320184]  vbox_cursor_atomic_update [vboxvideo]&#xA;Note as mentioned in the added comment it seems the original length&#xA;calculation for the allocated and send hgsmi buffer is 4 bytes too large.&#xA;Changing this is not the goal of this patch, so this behavior is kept.&#xA;CVE-2024-50201:In the Linux kernel, the following vulnerability has been resolved:&#xA;drm/radeon: Fix encoder-&gt;possible_clones&#xA;Include the encoder itself in its possible_clones bitmask.&#xA;In the past nothing validated that drivers were populating&#xA;possible_clones correctly, but that changed in commit&#xA;74d2aacbe840 (&#34;drm: Validate encoder-&gt;possible_clones&#34;).&#xA;Looks like radeon never got the memo and is still not&#xA;following the rules 100% correctly.&#xA;This results in some warnings during driver initialization:&#xA;Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)&#xA;WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c&#xA;...&#xA;(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)&#xA;CVE-2024-50278:In the Linux kernel, the following vulnerability has been resolved:&#xA;dm cache: fix potential out-of-bounds access on the first resume&#xA;Out-of-bounds access occurs if the fast device is expanded unexpectedly&#xA;before the first-time resume of the cache table. This happens because&#xA;expanding the fast device requires reloading the cache table for&#xA;cache_create to allocate new in-core data structures that fit the new&#xA;size, and the check in cache_preresume is not performed during the&#xA;first resume, leading to the issue.&#xA;Reproduce steps:&#xA;1. prepare component devices:&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;&#xA;dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34;&#xA;dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct&#xA;2. load a cache table of 512 cache blocks, and deliberately expand the&#xA;   fast device before resuming the cache, making the in-core data&#xA;   structures inadequate.&#xA;dmsetup create cache --notable&#xA;dmsetup reload cache --table &#34;0 524288 cache /dev/mapper/cmeta \&#xA;/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;&#xA;dmsetup reload cdata --table &#34;0 131072 linear /dev/sdc 8192&#34;&#xA;dmsetup resume cdata&#xA;dmsetup resume cache&#xA;3. suspend the cache to write out the in-core dirty bitset and hint&#xA;   array, leading to out-of-bounds access to the dirty bitset at offset&#xA;   0x40:&#xA;dmsetup suspend cache&#xA;KASAN reports:&#xA;  BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80&#xA;  Read of size 8 at addr ffffc90000085040 by task dmsetup/90&#xA;  (...snip...)&#xA;  The buggy address belongs to the virtual mapping at&#xA;   [ffffc90000085000, ffffc90000087000) created by:&#xA;   cache_ctr+0x176a/0x35f0&#xA;  (...snip...)&#xA;  Memory state around the buggy address:&#xA;   ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;   ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;  &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8&#xA;                                             ^&#xA;   ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;   ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;Fix by checking the size change on the first resume.&#xA;CVE-2024-50267:In the Linux kernel, the following vulnerability has been resolved:&#xA;USB: serial: io_edgeport: fix use after free in debug printk&#xA;The &#34;dev_dbg(&amp;urb-&gt;dev-&gt;dev, ...&#34; which happens after usb_free_urb(urb)&#xA;is a use after free of the &#34;urb&#34; pointer.  Store the &#34;dev&#34; pointer at the&#xA;start of the function to avoid this issue.&#xA;CVE-2024-50292:In the Linux kernel, the following vulnerability has been resolved:&#xA;ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove&#xA;In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not&#xA;null. So the release of the dma channel leads to the following issue:&#xA;[    4.879000] st,stm32-spdifrx 500d0000.audio-controller:&#xA;dma_request_slave_channel error -19&#xA;[    4.888975] Unable to handle kernel NULL pointer dereference&#xA;at virtual address 000000000000003d&#xA;[...]&#xA;[    5.096577] Call trace:&#xA;[    5.099099]  dma_release_channel+0x24/0x100&#xA;[    5.103235]  stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx]&#xA;[    5.109494]  stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]&#xA;To avoid this issue, release channel only if the pointer is valid.&#xA;CVE-2024-50302:In the Linux kernel, the following vulnerability has been resolved:&#xA;HID: core: zero-initialize the report buffer&#xA;Since the report buffer is used by all kinds of drivers in various ways, let&#39;s&#xA;zero-initialize it during allocation to make sure that it can&#39;t be ever used&#xA;to leak kernel memory via specially-crafted report.&#xA;CVE-2024-50290:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: cx24116: prevent overflows on SNR calculus&#xA;as reported by Coverity, if reading SNR registers fail, a negative&#xA;number will be returned, causing an underflow when reading SNR&#xA;registers.&#xA;Prevent that.&#xA;CVE-2024-53054:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-53095:In the Linux kernel, the following vulnerability has been resolved:&#xA;smb: client: Fix use-after-free of network namespace.&#xA;Recently, we got a customer report that CIFS triggers oops while&#xA;reconnecting to a server.  [0]&#xA;The workload runs on Kubernetes, and some pods mount CIFS servers&#xA;in non-root network namespaces.  The problem rarely happened, but&#xA;it was always while the pod was dying.&#xA;The root cause is wrong reference counting for network namespace.&#xA;CIFS uses kernel sockets, which do not hold refcnt of the netns that&#xA;the socket belongs to.  That means CIFS must ensure the socket is&#xA;always freed before its netns; otherwise, use-after-free happens.&#xA;The repro steps are roughly:&#xA;  1. mount CIFS in a non-root netns&#xA;  2. drop packets from the netns&#xA;  3. destroy the netns&#xA;  4. unmount CIFS&#xA;We can reproduce the issue quickly with the script [1] below and see&#xA;the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.&#xA;When the socket is TCP, it is hard to guarantee the netns lifetime&#xA;without holding refcnt due to async timers.&#xA;Let&#39;s hold netns refcnt for each socket as done for SMC in commit&#xA;9744d2bf1976 (&#34;smc: Fix use-after-free in tcp_write_timer_handler().&#34;).&#xA;Note that we need to move put_net() from cifs_put_tcp_session() to&#xA;clean_demultiplex_info(); otherwise, __sock_create() still could touch a&#xA;freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().&#xA;Also, maybe_get_net() cannot be put just before __sock_create() because&#xA;the code is not under RCU and there is a small chance that the same&#xA;address happened to be reallocated to another netns.&#xA;[0]:&#xA;CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...&#xA;CIFS: Serverclose failed 4 times, giving up&#xA;Unable to handle kernel paging request at virtual address 14de99e461f84a07&#xA;Mem abort info:&#xA;  ESR = 0x0000000096000004&#xA;  EC = 0x25: DABT (current EL), IL = 32 bits&#xA;  SET = 0, FnV = 0&#xA;  EA = 0, S1PTW = 0&#xA;  FSC = 0x04: level 0 translation fault&#xA;Data abort info:&#xA;  ISV = 0, ISS = 0x00000004&#xA;  CM = 0, WnR = 0&#xA;[14de99e461f84a07] address between user and kernel address ranges&#xA;Internal error: Oops: 0000000096000004 [#1] SMP&#xA;Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs&#xA;CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1&#xA;Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018&#xA;pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : fib_rules_lookup+0x44/0x238&#xA;lr : __fib_lookup+0x64/0xbc&#xA;sp : ffff8000265db790&#xA;x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01&#xA;x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580&#xA;x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500&#xA;x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000&#xA;x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002&#xA;x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294&#xA;x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000&#xA;x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0&#xA;x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500&#xA;Call trace:&#xA; fib_rules_lookup+0x44/0x238&#xA; __fib_lookup+0x64/0xbc&#xA; ip_route_output_key_hash_rcu+0x2c4/0x398&#xA; ip_route_output_key_hash+0x60/0x8c&#xA; tcp_v4_connect+0x290/0x488&#xA; __inet_stream_connect+0x108/0x3d0&#xA; inet_stream_connect+0x50/0x78&#xA; kernel_connect+0x6c/0xac&#xA; generic_ip_conne&#xA;---truncated---&#xA;CVE-2023-52922:In the Linux kernel, the following vulnerability has been resolved:&#xA;can: bcm: Fix UAF in bcm_proc_show()&#xA;BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80&#xA;Read of size 8 at addr ffff888155846230 by task cat/7862&#xA;CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0xd5/0x150&#xA; print_report+0xc1/0x5e0&#xA; kasan_report+0xba/0xf0&#xA; bcm_proc_show+0x969/0xa80&#xA; seq_read_iter+0x4f6/0x1260&#xA; seq_read+0x165/0x210&#xA; proc_reg_read+0x227/0x300&#xA; vfs_read+0x1d5/0x8d0&#xA; ksys_read+0x11e/0x240&#xA; do_syscall_64+0x35/0xb0&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;Allocated by task 7846:&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_set_track+0x21/0x30&#xA; __kasan_kmalloc+0x9e/0xa0&#xA; bcm_sendmsg+0x264b/0x44e0&#xA; sock_sendmsg+0xda/0x180&#xA; ____sys_sendmsg+0x735/0x920&#xA; ___sys_sendmsg+0x11d/0x1b0&#xA; __sys_sendmsg+0xfa/0x1d0&#xA; do_syscall_64+0x35/0xb0&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;Freed by task 7846:&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_set_track+0x21/0x30&#xA; kasan_save_free_info+0x27/0x40&#xA; ____kasan_slab_free+0x161/0x1c0&#xA; slab_free_freelist_hook+0x119/0x220&#xA; __kmem_cache_free+0xb4/0x2e0&#xA; rcu_core+0x809/0x1bd0&#xA;bcm_op is freed before procfs entry be removed in bcm_release(),&#xA;this lead to bcm_proc_show() may read the freed bcm_op.&#xA;CVE-2024-53104:In the Linux kernel, the following vulnerability has been resolved:&#xA;media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format&#xA;This can lead to out of bounds writes since frames of this type were not&#xA;taken into account when calculating the size of the frames buffer in&#xA;uvc_parse_streaming.&#xA;CVE-2024-53110:In the Linux kernel, the following vulnerability has been resolved:&#xA;vp_vdpa: fix id_table array not null terminated error&#xA;Allocate one extra virtio_device_id as null terminator, otherwise&#xA;vdpa_mgmtdev_get_classes() may iterate multiple times and visit&#xA;undefined memory.&#xA;CVE-2024-53112:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: uncache inode which has failed entering the group&#xA;Syzbot has reported the following BUG:&#xA;kernel BUG at fs/ocfs2/uptodate.c:509!&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body+0x5f/0xb0&#xA; ? die+0x9e/0xc0&#xA; ? do_trap+0x15a/0x3a0&#xA; ? ocfs2_set_new_buffer_uptodate+0x145/0x160&#xA; ? do_error_trap+0x1dc/0x2c0&#xA; ? ocfs2_set_new_buffer_uptodate+0x145/0x160&#xA; ? __pfx_do_error_trap+0x10/0x10&#xA; ? handle_invalid_op+0x34/0x40&#xA; ? ocfs2_set_new_buffer_uptodate+0x145/0x160&#xA; ? exc_invalid_op+0x38/0x50&#xA; ? asm_exc_invalid_op+0x1a/0x20&#xA; ? ocfs2_set_new_buffer_uptodate+0x2e/0x160&#xA; ? ocfs2_set_new_buffer_uptodate+0x144/0x160&#xA; ? ocfs2_set_new_buffer_uptodate+0x145/0x160&#xA; ocfs2_group_add+0x39f/0x15a0&#xA; ? __pfx_ocfs2_group_add+0x10/0x10&#xA; ? __pfx_lock_acquire+0x10/0x10&#xA; ? mnt_get_write_access+0x68/0x2b0&#xA; ? __pfx_lock_release+0x10/0x10&#xA; ? rcu_read_lock_any_held+0xb7/0x160&#xA; ? __pfx_rcu_read_lock_any_held+0x10/0x10&#xA; ? smack_log+0x123/0x540&#xA; ? mnt_get_write_access+0x68/0x2b0&#xA; ? mnt_get_write_access+0x68/0x2b0&#xA; ? mnt_get_write_access+0x226/0x2b0&#xA; ocfs2_ioctl+0x65e/0x7d0&#xA; ? __pfx_ocfs2_ioctl+0x10/0x10&#xA; ? smack_file_ioctl+0x29e/0x3a0&#xA; ? __pfx_smack_file_ioctl+0x10/0x10&#xA; ? lockdep_hardirqs_on_prepare+0x43d/0x780&#xA; ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10&#xA; ? __pfx_ocfs2_ioctl+0x10/0x10&#xA; __se_sys_ioctl+0xfb/0x170&#xA; do_syscall_64+0xf3/0x230&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;...&#xA; &lt;/TASK&gt;&#xA;When &#39;ioctl(OCFS2_IOC_GROUP_ADD, ...)&#39; has failed for the particular&#xA;inode in &#39;ocfs2_verify_group_and_input()&#39;, corresponding buffer head&#xA;remains cached and subsequent call to the same &#39;ioctl()&#39; for the same&#xA;inode issues the BUG() in &#39;ocfs2_set_new_buffer_uptodate()&#39; (trying&#xA;to cache the same buffer head of that inode). Fix this by uncaching&#xA;the buffer head with &#39;ocfs2_remove_from_cache()&#39; on error path in&#xA;&#39;ocfs2_group_add()&#39;.&#xA;CVE-2024-53125:In the Linux kernel, the following vulnerability has been resolved:&#xA;bpf: sync_linked_regs() must preserve subreg_def&#xA;Range propagation must not affect subreg_def marks, otherwise the&#xA;following example is rewritten by verifier incorrectly when&#xA;BPF_F_TEST_RND_HI32 flag is set:&#xA;  0: call bpf_ktime_get_ns                   call bpf_ktime_get_ns&#xA;  1: r0 &amp;= 0x7fffffff       after verifier   r0 &amp;= 0x7fffffff&#xA;  2: w1 = w0                rewrites         w1 = w0&#xA;  3: if w0 &lt; 10 goto +0     --------------&gt;  r11 = 0x2f5674a6     (r)&#xA;  4: r1 &gt;&gt;= 32                               r11 &lt;&lt;= 32           (r)&#xA;  5: r0 = r1                                 r1 |= r11            (r)&#xA;  6: exit;                                   if w0 &lt; 0xa goto pc+0&#xA;                                             r1 &gt;&gt;= 32&#xA;                                             r0 = r1&#xA;                                             exit&#xA;(or zero extension of w1 at (2) is missing for architectures that&#xA; require zero extension for upper register half).&#xA;The following happens w/o this patch:&#xA;- r0 is marked as not a subreg at (0);&#xA;- w1 is marked as subreg at (2);&#xA;- w1 subreg_def is overridden at (3) by copy_register_state();&#xA;- w1 is read at (5) but mark_insn_zext() does not mark (2)&#xA;  for zero extension, because w1 subreg_def is not set;&#xA;- because of BPF_F_TEST_RND_HI32 flag verifier inserts random&#xA;  value for hi32 bits of (2) (marked (r));&#xA;- this random value is read at (5).&#xA;CVE-2024-53130:In the Linux kernel, the following vulnerability has been resolved:&#xA;nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint&#xA;When using the &#34;block:block_dirty_buffer&#34; tracepoint, mark_buffer_dirty()&#xA;may cause a NULL pointer dereference, or a general protection fault when&#xA;KASAN is enabled.&#xA;This happens because, since the tracepoint was added in&#xA;mark_buffer_dirty(), it references the dev_t member bh-&gt;b_bdev-&gt;bd_dev&#xA;regardless of whether the buffer head has a pointer to a block_device&#xA;structure.&#xA;In the current implementation, nilfs_grab_buffer(), which grabs a buffer&#xA;to read (or create) a block of metadata, including b-tree node blocks,&#xA;does not set the block device, but instead does so only if the buffer is&#xA;not in the &#34;uptodate&#34; state for each of its caller block reading&#xA;functions.  However, if the uptodate flag is set on a folio/page, and the&#xA;buffer heads are detached from it by try_to_free_buffers(), and new buffer&#xA;heads are then attached by create_empty_buffers(), the uptodate flag may&#xA;be restored to each buffer without the block device being set to&#xA;bh-&gt;b_bdev, and mark_buffer_dirty() may be called later in that state,&#xA;resulting in the bug mentioned above.&#xA;Fix this issue by making nilfs_grab_buffer() always set the block device&#xA;of the super block structure to the buffer head, regardless of the state&#xA;of the buffer&#39;s uptodate flag.&#xA;CVE-2022-48868:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: idxd: Let probe fail when workqueue cannot be enabled&#xA;The workqueue is enabled when the appropriate driver is loaded and&#xA;disabled when the driver is removed. When the driver is removed it&#xA;assumes that the workqueue was enabled successfully and proceeds to&#xA;free allocations made during workqueue enabling.&#xA;Failure during workqueue enabling does not prevent the driver from&#xA;being loaded. This is because the error path within drv_enable_wq()&#xA;returns success unless a second failure is encountered&#xA;during the error path. By returning success it is possible to load&#xA;the driver even if the workqueue cannot be enabled and&#xA;allocations that do not exist are attempted to be freed during&#xA;driver remove.&#xA;Some examples of problematic flows:&#xA;(a)&#xA; idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():&#xA; In above flow, if idxd_wq_request_irq() fails then&#xA; idxd_wq_unmap_portal() is called on error exit path, but&#xA; drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The&#xA; driver is thus loaded successfully.&#xA; idxd_dmaengine_drv_remove()-&gt;drv_disable_wq()-&gt;idxd_wq_unmap_portal()&#xA; Above flow on driver unload triggers the WARN in devm_iounmap() because&#xA; the device resource has already been removed during error path of&#xA; drv_enable_wq().&#xA;(b)&#xA; idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():&#xA; In above flow, if idxd_wq_request_irq() fails then&#xA; idxd_wq_init_percpu_ref() is never called to initialize the percpu&#xA; counter, yet the driver loads successfully because drv_enable_wq()&#xA; returns 0.&#xA; idxd_dmaengine_drv_remove()-&gt;__idxd_wq_quiesce()-&gt;percpu_ref_kill():&#xA; Above flow on driver unload triggers a BUG when attempting to drop the&#xA; initial ref of the uninitialized percpu ref:&#xA; BUG: kernel NULL pointer dereference, address: 0000000000000010&#xA;Fix the drv_enable_wq() error path by returning the original error that&#xA;indicates failure of workqueue enabling. This ensures that the probe&#xA;fails when an error is encountered and the driver remove paths are only&#xA;attempted when the workqueue was enabled successfully.&#xA;CVE-2024-53142:In the Linux kernel, the following vulnerability has been resolved:&#xA;initramfs: avoid filename buffer overrun&#xA;The initramfs filename field is defined in&#xA;Documentation/driver-api/early-userspace/buffer-format.rst as:&#xA; 37 cpio_file := ALGN(4) + cpio_header + filename + &#34;\0&#34; + ALGN(4) + data&#xA;...&#xA; 55 ============= ================== =========================&#xA; 56 Field name    Field size         Meaning&#xA; 57 ============= ================== =========================&#xA;...&#xA; 70 c_namesize    8 bytes            Length of filename, including final \0&#xA;When extracting an initramfs cpio archive, the kernel&#39;s do_name() path&#xA;handler assumes a zero-terminated path at @collected, passing it&#xA;directly to filp_open() / init_mkdir() / init_mknod().&#xA;If a specially crafted cpio entry carries a non-zero-terminated filename&#xA;and is followed by uninitialized memory, then a file may be created with&#xA;trailing characters that represent the uninitialized memory. The ability&#xA;to create an initramfs entry would imply already having full control of&#xA;the system, so the buffer overrun shouldn&#39;t be considered a security&#xA;vulnerability.&#xA;Append the output of the following bash script to an existing initramfs&#xA;and observe any created /initramfs_test_fname_overrunAA* path. E.g.&#xA;  ./reproducer.sh | gzip &gt;&gt; /myinitramfs&#xA;It&#39;s easiest to observe non-zero uninitialized memory when the output is&#xA;gzipped, as it&#39;ll overflow the heap allocated @out_buf in __gunzip(),&#xA;rather than the initrd_start+initrd_size block.&#xA;---- reproducer.sh ----&#xA;nilchar=&#34;A&#34;&#x9;# change to &#34;\0&#34; to properly zero terminate / pad&#xA;magic=&#34;070701&#34;&#xA;ino=1&#xA;mode=$(( 0100777 ))&#xA;uid=0&#xA;gid=0&#xA;nlink=1&#xA;mtime=1&#xA;filesize=0&#xA;devmajor=0&#xA;devminor=1&#xA;rdevmajor=0&#xA;rdevminor=0&#xA;csum=0&#xA;fname=&#34;initramfs_test_fname_overrun&#34;&#xA;namelen=$(( ${#fname} + 1 ))&#x9;# plus one to account for terminator&#xA;printf &#34;%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s&#34; \&#xA;&#x9;$magic $ino $mode $uid $gid $nlink $mtime $filesize \&#xA;&#x9;$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname&#xA;termpadlen=$(( 1 + ((4 - ((110 + $namelen) &amp; 3)) % 4) ))&#xA;printf &#34;%.s${nilchar}&#34; $(seq 1 $termpadlen)&#xA;---- reproducer.sh ----&#xA;Symlink filename fields handled in do_symlink() won&#39;t overrun past the&#xA;data segment, due to the explicit zero-termination of the symlink&#xA;target.&#xA;Fix filename buffer overrun by aborting the initramfs FSM if any cpio&#xA;entry doesn&#39;t carry a zero-terminator at the expected (name_len - 1)&#xA;offset.&#xA;CVE-2022-48868:In the Linux kernel, the following vulnerability has been resolved:&#xA;dmaengine: idxd: Let probe fail when workqueue cannot be enabled&#xA;The workqueue is enabled when the appropriate driver is loaded and&#xA;disabled when the driver is removed. When the driver is removed it&#xA;assumes that the workqueue was enabled successfully and proceeds to&#xA;free allocations made during workqueue enabling.&#xA;Failure during workqueue enabling does not prevent the driver from&#xA;being loaded. This is because the error path within drv_enable_wq()&#xA;returns success unless a second failure is encountered&#xA;during the error path. By returning success it is possible to load&#xA;the driver even if the workqueue cannot be enabled and&#xA;allocations that do not exist are attempted to be freed during&#xA;driver remove.&#xA;Some examples of problematic flows:&#xA;(a)&#xA; idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():&#xA; In above flow, if idxd_wq_request_irq() fails then&#xA; idxd_wq_unmap_portal() is called on error exit path, but&#xA; drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The&#xA; driver is thus loaded successfully.&#xA; idxd_dmaengine_drv_remove()-&gt;drv_disable_wq()-&gt;idxd_wq_unmap_portal()&#xA; Above flow on driver unload triggers the WARN in devm_iounmap() because&#xA; the device resource has already been removed during error path of&#xA; drv_enable_wq().&#xA;(b)&#xA; idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():&#xA; In above flow, if idxd_wq_request_irq() fails then&#xA; idxd_wq_init_percpu_ref() is never called to initialize the percpu&#xA; counter, yet the driver loads successfully because drv_enable_wq()&#xA; returns 0.&#xA; idxd_dmaengine_drv_remove()-&gt;__idxd_wq_quiesce()-&gt;percpu_ref_kill():&#xA; Above flow on driver unload triggers a BUG when attempting to drop the&#xA; initial ref of the uninitialized percpu ref:&#xA; BUG: kernel NULL pointer dereference, address: 0000000000000010&#xA;Fix the drv_enable_wq() error path by returning the original error that&#xA;indicates failure of workqueue enabling. This ensures that the probe&#xA;fails when an error is encountered and the driver remove paths are only&#xA;attempted when the workqueue was enabled successfully.&#xA;CVE-2024-46765:In the Linux kernel, the following vulnerability has been resolved:&#xA;ice: protect XDP configuration with a mutex&#xA;The main threat to data consistency in ice_xdp() is a possible asynchronous&#xA;PF reset. It can be triggered by a user or by TX timeout handler.&#xA;XDP setup and PF reset code access the same resources in the following&#xA;sections:&#xA;* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked&#xA;* ice_vsi_rebuild() for the PF VSI - not protected&#xA;* ice_vsi_open() - already rtnl-locked&#xA;With an unfortunate timing, such accesses can result in a crash such as the&#xA;one below:&#xA;[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14&#xA;[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18&#xA;[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms&#xA;[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001&#xA;[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14&#xA;[ +0.394718] ice 0000:b1:00.0: PTP reset successful&#xA;[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098&#xA;[ +0.000045] #PF: supervisor read access in kernel mode&#xA;[ +0.000023] #PF: error_code(0x0000) - not-present page&#xA;[ +0.000023] PGD 0 P4D 0&#xA;[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1&#xA;[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021&#xA;[ +0.000036] Workqueue: ice ice_service_task [ice]&#xA;[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]&#xA;[...]&#xA;[ +0.000013] Call Trace:&#xA;[ +0.000016] &lt;TASK&gt;&#xA;[ +0.000014] ? __die+0x1f/0x70&#xA;[ +0.000029] ? page_fault_oops+0x171/0x4f0&#xA;[ +0.000029] ? schedule+0x3b/0xd0&#xA;[ +0.000027] ? exc_page_fault+0x7b/0x180&#xA;[ +0.000022] ? asm_exc_page_fault+0x22/0x30&#xA;[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]&#xA;[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]&#xA;[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]&#xA;[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]&#xA;[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]&#xA;[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]&#xA;[ +0.000145] ice_rebuild+0x18c/0x840 [ice]&#xA;[ +0.000145] ? delay_tsc+0x4a/0xc0&#xA;[ +0.000022] ? delay_tsc+0x92/0xc0&#xA;[ +0.000020] ice_do_reset+0x140/0x180 [ice]&#xA;[ +0.000886] ice_service_task+0x404/0x1030 [ice]&#xA;[ +0.000824] process_one_work+0x171/0x340&#xA;[ +0.000685] worker_thread+0x277/0x3a0&#xA;[ +0.000675] ? preempt_count_add+0x6a/0xa0&#xA;[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50&#xA;[ +0.000679] ? __pfx_worker_thread+0x10/0x10&#xA;[ +0.000653] kthread+0xf0/0x120&#xA;[ +0.000635] ? __pfx_kthread+0x10/0x10&#xA;[ +0.000616] ret_from_fork+0x2d/0x50&#xA;[ +0.000612] ? __pfx_kthread+0x10/0x10&#xA;[ +0.000604] ret_from_fork_asm+0x1b/0x30&#xA;[ +0.000604] &lt;/TASK&gt;&#xA;The previous way of handling this through returning -EBUSY is not viable,&#xA;particularly when destroying AF_XDP socket, because the kernel proceeds&#xA;with removal anyway.&#xA;There is plenty of code between those calls and there is no need to create&#xA;a large critical section that covers all of them, same as there is no need&#xA;to protect ice_vsi_rebuild() with rtnl_lock().&#xA;Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().&#xA;Leaving unprotected sections in between would result in two states that&#xA;have to be considered:&#xA;1. when the VSI is closed, but not yet rebuild&#xA;2. when VSI is already rebuild, but not yet open&#xA;The latter case is actually already handled through !netif_running() case,&#xA;we just need to adjust flag checking a little. The former one is not as&#xA;trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of&#xA;hardware interaction happens, this can make adding/deleting rings exit&#xA;with an error. Luckily, VSI rebuild is pending and can apply new&#xA;configuration for us in a managed fashion.&#xA;Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to&#xA;indicate that ice_x&#xA;---truncated---&#xA;CVE-2022-49022:In the Linux kernel, the following vulnerability has been resolved:&#xA;wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration&#xA;Fix possible out-of-bound access in ieee80211_get_rate_duration routine&#xA;as reported by the following UBSAN report:&#xA;UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47&#xA;index 15 is out of range for type &#39;u16 [12]&#39;&#xA;CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic&#xA;Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017&#xA;Workqueue: mt76 mt76u_tx_status_data [mt76_usb]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; show_stack+0x4e/0x61&#xA; dump_stack_lvl+0x4a/0x6f&#xA; dump_stack+0x10/0x18&#xA; ubsan_epilogue+0x9/0x43&#xA; __ubsan_handle_out_of_bounds.cold+0x42/0x47&#xA;ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211]&#xA; ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211]&#xA; ieee80211_calc_rx_airtime+0xda/0x120 [mac80211]&#xA; ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211]&#xA; mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib]&#xA; mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib]&#xA; mt76u_tx_status_data+0x67/0xd0 [mt76_usb]&#xA; process_one_work+0x225/0x400&#xA; worker_thread+0x50/0x3e0&#xA; ? process_one_work+0x400/0x400&#xA; kthread+0xe9/0x110&#xA; ? kthread_complete_and_exit+0x20/0x20&#xA; ret_from_fork+0x22/0x30&#xA;CVE-2022-49028:In the Linux kernel, the following vulnerability has been resolved:&#xA;ixgbevf: Fix resource leak in ixgbevf_init_module()&#xA;ixgbevf_init_module() won&#39;t destroy the workqueue created by&#xA;create_singlethread_workqueue() when pci_register_driver() failed. Add&#xA;destroy_workqueue() in fail path to prevent the resource leak.&#xA;Similar to the handling of u132_hcd_init in commit f276e002793c&#xA;(&#34;usb: u132-hcd: fix resource leak&#34;)&#xA;CVE-2022-49014:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: tun: Fix use-after-free in tun_detach()&#xA;syzbot reported use-after-free in tun_detach() [1].  This causes call&#xA;trace like below:&#xA;==================================================================&#xA;BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75&#xA;Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673&#xA;CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:284 [inline]&#xA; print_report+0x15e/0x461 mm/kasan/report.c:395&#xA; kasan_report+0xbf/0x1f0 mm/kasan/report.c:495&#xA; notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75&#xA; call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942&#xA; call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]&#xA; call_netdevice_notifiers net/core/dev.c:1997 [inline]&#xA; netdev_wait_allrefs_any net/core/dev.c:10237 [inline]&#xA; netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351&#xA; tun_detach drivers/net/tun.c:704 [inline]&#xA; tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467&#xA; __fput+0x27c/0xa90 fs/file_table.c:320&#xA; task_work_run+0x16f/0x270 kernel/task_work.c:179&#xA; exit_task_work include/linux/task_work.h:38 [inline]&#xA; do_exit+0xb3d/0x2a30 kernel/exit.c:820&#xA; do_group_exit+0xd4/0x2a0 kernel/exit.c:950&#xA; get_signal+0x21b1/0x2440 kernel/signal.c:2858&#xA; arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869&#xA; exit_to_user_mode_loop kernel/entry/common.c:168 [inline]&#xA; exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203&#xA; __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]&#xA; syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296&#xA; do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;The cause of the issue is that sock_put() from __tun_detach() drops&#xA;last reference count for struct net, and then notifier_call_chain()&#xA;from netdev_state_change() accesses that struct net.&#xA;This patch fixes the issue by calling sock_put() from tun_detach()&#xA;after all necessary accesses for the struct net has done.&#xA;CVE-2022-48971:In the Linux kernel, the following vulnerability has been resolved:&#xA;Bluetooth: Fix not cleanup led when bt_init fails&#xA;bt_init() calls bt_leds_init() to register led, but if it fails later,&#xA;bt_leds_cleanup() is not called to unregister it.&#xA;This can cause panic if the argument &#34;bluetooth-power&#34; in text is freed&#xA;and then another led_trigger_register() tries to access it:&#xA;BUG: unable to handle page fault for address: ffffffffc06d3bc0&#xA;RIP: 0010:strcmp+0xc/0x30&#xA;  Call Trace:&#xA;    &lt;TASK&gt;&#xA;    led_trigger_register+0x10d/0x4f0&#xA;    led_trigger_register_simple+0x7d/0x100&#xA;    bt_init+0x39/0xf7 [bluetooth]&#xA;    do_one_initcall+0xd0/0x4e0&#xA;CVE-2022-48949:In the Linux kernel, the following vulnerability has been resolved:&#xA;igb: Initialize mailbox message for VF reset&#xA;When a MAC address is not assigned to the VF, that portion of the message&#xA;sent to the VF is not set. The memory, however, is allocated from the&#xA;stack meaning that information may be leaked to the VM. Initialize the&#xA;message buffer to 0 so that no information is passed to the VM in this&#xA;case.&#xA;CVE-2022-49015:In the Linux kernel, the following vulnerability has been resolved:&#xA;net: hsr: Fix potential use-after-free&#xA;The skb is delivered to netif_rx() which may free it, after calling this,&#xA;dereferencing skb may trigger use-after-free.&#xA;CVE-2024-50086:In the Linux kernel, the following vulnerability has been resolved:&#xA;ksmbd: fix user-after-free from session log off&#xA;There is racy issue between smb2 session log off and smb2 session setup.&#xA;It will cause user-after-free from session log off.&#xA;This add session_lock when setting SMB2_SESSION_EXPIRED and referece&#xA;count to session struct not to free session while it is being used.&#xA;CVE-2024-50218:In the Linux kernel, the following vulnerability has been resolved:&#xA;ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow&#xA;Syzbot reported a kernel BUG in ocfs2_truncate_inline.  There are two&#xA;reasons for this: first, the parameter value passed is greater than&#xA;ocfs2_max_inline_data_with_xattr, second, the start and end parameters of&#xA;ocfs2_truncate_inline are &#34;unsigned int&#34;.&#xA;So, we need to add a sanity check for byte_start and byte_len right before&#xA;ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater&#xA;than ocfs2_max_inline_data_with_xattr return -EINVAL.&#xA;CVE-2024-53142:In the Linux kernel, the following vulnerability has been resolved:&#xA;initramfs: avoid filename buffer overrun&#xA;The initramfs filename field is defined in&#xA;Documentation/driver-api/early-userspace/buffer-format.rst as:&#xA; 37 cpio_file := ALGN(4) + cpio_header + filename + &#34;\0&#34; + ALGN(4) + data&#xA;...&#xA; 55 ============= ================== =========================&#xA; 56 Field name    Field size         Meaning&#xA; 57 ============= ================== =========================&#xA;...&#xA; 70 c_namesize    8 bytes            Length of filename, including final \0&#xA;When extracting an initramfs cpio archive, the kernel&#39;s do_name() path&#xA;handler assumes a zero-terminated path at @collected, passing it&#xA;directly to filp_open() / init_mkdir() / init_mknod().&#xA;If a specially crafted cpio entry carries a non-zero-terminated filename&#xA;and is followed by uninitialized memory, then a file may be created with&#xA;trailing characters that represent the uninitialized memory. The ability&#xA;to create an initramfs entry would imply already having full control of&#xA;the system, so the buffer overrun shouldn&#39;t be considered a security&#xA;vulnerability.&#xA;Append the output of the following bash script to an existing initramfs&#xA;and observe any created /initramfs_test_fname_overrunAA* path. E.g.&#xA;  ./reproducer.sh | gzip &gt;&gt; /myinitramfs&#xA;It&#39;s easiest to observe non-zero uninitialized memory when the output is&#xA;gzipped, as it&#39;ll overflow the heap allocated @out_buf in __gunzip(),&#xA;rather than the initrd_start+initrd_size block.&#xA;---- reproducer.sh ----&#xA;nilchar=&#34;A&#34;&#x9;# change to &#34;\0&#34; to properly zero terminate / pad&#xA;magic=&#34;070701&#34;&#xA;ino=1&#xA;mode=$(( 0100777 ))&#xA;uid=0&#xA;gid=0&#xA;nlink=1&#xA;mtime=1&#xA;filesize=0&#xA;devmajor=0&#xA;devminor=1&#xA;rdevmajor=0&#xA;rdevminor=0&#xA;csum=0&#xA;fname=&#34;initramfs_test_fname_overrun&#34;&#xA;namelen=$(( ${#fname} + 1 ))&#x9;# plus one to account for terminator&#xA;printf &#34;%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s&#34; \&#xA;&#x9;$magic $ino $mode $uid $gid $nlink $mtime $filesize \&#xA;&#x9;$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname&#xA;termpadlen=$(( 1 + ((4 - ((110 + $namelen) &amp; 3)) % 4) ))&#xA;printf &#34;%.s${nilchar}&#34; $(seq 1 $termpadlen)&#xA;---- reproducer.sh ----&#xA;Symlink filename fields handled in do_symlink() won&#39;t overrun past the&#xA;data segment, due to the explicit zero-termination of the symlink&#xA;target.&#xA;Fix filename buffer overrun by aborting the initramfs FSM if any cpio&#xA;entry doesn&#39;t carry a zero-terminator at the expected (name_len - 1)&#xA;offset.&#xA;CVE-2024-53150:In the Linux kernel, the following vulnerability has been resolved:&#xA;ALSA: usb-audio: Fix out of bounds reads when finding clock sources&#xA;The current USB-audio driver code doesn&#39;t check bLength of each&#xA;descriptor at traversing for clock descriptors.  That is, when a&#xA;device provides a bogus descriptor with a shorter bLength, the driver&#xA;might hit out-of-bounds reads.&#xA;For addressing it, this patch adds sanity checks to the validator&#xA;functions for the clock descriptor traversal.  When the descriptor&#xA;length is shorter than expected, it&#39;s skipped in the loop.&#xA;For the clock source and clock multiplier descriptors, we can just&#xA;check bLength against the sizeof() of each descriptor type.&#xA;OTOH, the clock selector descriptor of UAC2 and UAC3 has an array&#xA;of bNrInPins elements and two more fields at its tail, hence those&#xA;have to be checked in addition to the sizeof() check.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/kernel-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/kernel-headers-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/kernel-devel-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/kernel-tools-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/kernel-tools-devel-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perf-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-perf-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/bpftool-5.10.0-136.107.0.187.u153.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/kernel-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/kernel-headers-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/kernel-devel-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/kernel-tools-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/kernel-tools-devel-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/perf-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-perf-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.107.0.187.u153.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/bpftool-5.10.0-136.107.0.187.u153.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2030</id>
		<title>An update for libpq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10976" id="CVE-2024-10976" title="CVE-2024-10976" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10977" id="CVE-2024-10977" title="CVE-2024-10977" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10978" id="CVE-2024-10978" title="CVE-2024-10978" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10979" id="CVE-2024-10979" title="CVE-2024-10979" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7348" id="CVE-2024-7348" title="CVE-2024-7348" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0985" id="CVE-2024-0985" title="CVE-2024-0985" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5870" id="CVE-2023-5870" title="CVE-2023-5870" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5868" id="CVE-2023-5868" title="CVE-2023-5868" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5869" id="CVE-2023-5869" title="CVE-2023-5869" type="cve"></reference>
		</references>
		<description>CVE-2024-10976:Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended.  CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes.  They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy.  This has the same consequences as the two earlier CVEs.  That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles.  This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs.  Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications.  This affects only databases that have used CREATE POLICY to define a row security policy.  An attacker must tailor an attack to a particular application&#39;s pattern of query plan reuse, user ID changes, and role-specific row security policies.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-10977:Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application.  For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results.  This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-10978:Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended.  An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature.  The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker.  If that query reacts to current_setting(&#39;role&#39;) or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION.  The attacker does not control which incorrect user ID applies.  Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-10979:Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH).  That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-7348:Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.&#xA;CVE-2024-0985:Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker&#39;s roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker&#39;s materialized view. Versions before PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 are affected.&#xA;CVE-2023-5870:A flaw was found in PostgreSQL involving the pg_cancel_backend role that signals background workers, including the logical replication launcher, autovacuum workers, and the autovacuum launcher. Successful exploitation requires a non-core extension with a less-resilient background worker and would affect that specific background worker only. This issue may allow a remote high privileged user to launch a denial of service (DoS) attack.&#xA;CVE-2023-5868:A memory disclosure vulnerability was found in PostgreSQL that allows remote users to access sensitive information by exploiting certain aggregate function calls with &#39;unknown&#39;-type arguments. Handling &#39;unknown&#39;-type values from string literals without type designation can disclose bytes, potentially revealing notable and confidential information. This issue exists due to excessive data output in aggregate function calls, enabling remote users to read some portion of system memory.&#xA;CVE-2023-5869:A flaw was found in PostgreSQL that allows authenticated database users to execute arbitrary code through missing overflow checks during SQL array value modification. This issue exists due to an integer overflow during array modification where a remote user can trigger the overflow by providing specially crafted data. This enables the execution of arbitrary code on the target system, allowing users to write arbitrary bytes to memory and extensively read the server&#39;s memory.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="libpq" release="1.u2.fos23" version="13.17">
					<filename>libpq-13.17-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libpq-13.17-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libpq-devel" release="1.u2.fos23" version="13.17">
					<filename>libpq-devel-13.17-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libpq-devel-13.17-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libpq" release="1.u2.fos23" version="13.17">
					<filename>libpq-13.17-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libpq-13.17-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libpq-devel" release="1.u2.fos23" version="13.17">
					<filename>libpq-devel-13.17-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libpq-devel-13.17-1.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2031</id>
		<title>An update for libsndfile is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50612" id="CVE-2024-50612" title="CVE-2024-50612" type="cve"></reference>
		</references>
		<description>CVE-2024-50612:libsndfile through 1.2.2 has an ogg_vorbis.c vorbis_analysis_wrote out-of-bounds read.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="libsndfile" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-1.0.31-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsndfile-1.0.31-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsndfile-devel" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-devel-1.0.31-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsndfile-devel-1.0.31-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsndfile-utils" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-utils-1.0.31-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsndfile-utils-1.0.31-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libsndfile-utils-help" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-utils-help-1.0.31-4.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsndfile-utils-help-1.0.31-4.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-1.0.31-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libsndfile-1.0.31-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile-devel" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-devel-1.0.31-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libsndfile-devel-1.0.31-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsndfile-utils" release="4.u4.fos23" version="1.0.31">
					<filename>libsndfile-utils-1.0.31-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libsndfile-utils-1.0.31-4.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2032</id>
		<title>An update for libsoup is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52530" id="CVE-2024-52530" title="CVE-2024-52530" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52531" id="CVE-2024-52531" title="CVE-2024-52531" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52532" id="CVE-2024-52532" title="CVE-2024-52532" type="cve"></reference>
		</references>
		<description>CVE-2024-52530:GNOME libsoup before 3.6.0 allows HTTP request smuggling in some configurations because &#39;\0&#39; characters at the end of header names are ignored, i.e., a &#34;Transfer-Encoding\0: chunked&#34; header is treated the same as a &#34;Transfer-Encoding: chunked&#34; header.&#xA;CVE-2024-52531:GNOME libsoup before 3.6.1 allows a buffer overflow in applications that perform conversion to UTF-8 in soup_header_parse_param_list_strict. Input received over the network cannot trigger this.&#xA;CVE-2024-52532:GNOME libsoup before 3.6.1 has an infinite loop, and memory consumption. during the reading of certain patterns of WebSocket data from clients.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="libsoup" release="5.u1.fos23" version="2.74.2">
					<filename>libsoup-2.74.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsoup-2.74.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsoup-devel" release="5.u1.fos23" version="2.74.2">
					<filename>libsoup-devel-2.74.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsoup-devel-2.74.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libsoup-help" release="5.u1.fos23" version="2.74.2">
					<filename>libsoup-help-2.74.2-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/libsoup-help-2.74.2-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsoup" release="5.u1.fos23" version="2.74.2">
					<filename>libsoup-2.74.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libsoup-2.74.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsoup-devel" release="5.u1.fos23" version="2.74.2">
					<filename>libsoup-devel-2.74.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/libsoup-devel-2.74.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2033</id>
		<title>An update for linux-firmware is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-20584" id="CVE-2023-20584" title="CVE-2023-20584" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-31356" id="CVE-2023-31356" title="CVE-2023-31356" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-31315" id="CVE-2023-31315" title="CVE-2023-31315" type="cve"></reference>
		</references>
		<description>CVE-2023-20584:IOMMU improperly handles certain special address&#xA;ranges with invalid device table entries (DTEs), which may allow an attacker&#xA;with privileges and a compromised Hypervisor to&#xA;induce DTE faults to bypass RMP checks in SEV-SNP, potentially leading to a&#xA;loss of guest integrity.&#xA;CVE-2023-31356:Incomplete system memory cleanup in SEV firmware could&#xA;allow a privileged attacker to corrupt guest private memory, potentially&#xA;resulting in a loss of data integrity.&#xA;CVE-2023-31315:Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="linux-firmware" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-ath" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-ath-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-ath-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-libertas" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-libertas-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-libertas-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-mediatek" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-mediatek-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-mediatek-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-mrvl" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-mrvl-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-mrvl-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-cypress" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-cypress-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-cypress-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-netronome" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-netronome-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-netronome-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-ti-connectivity" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-ti-connectivity-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-ti-connectivity-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-iwlwifi" release="1.u5.fos23" version="20241017">
					<filename>linux-firmware-iwlwifi-20241017-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/linux-firmware-iwlwifi-20241017-1.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2034</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24853" id="CVE-2024-24853" title="CVE-2024-24853" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-25939" id="CVE-2024-25939" title="CVE-2024-25939" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24980" id="CVE-2024-24980" title="CVE-2024-24980" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-42667" id="CVE-2023-42667" title="CVE-2023-42667" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-49141" id="CVE-2023-49141" title="CVE-2023-49141" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23984" id="CVE-2024-23984" title="CVE-2024-23984" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24968" id="CVE-2024-24968" title="CVE-2024-24968" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21853" id="CVE-2024-21853" title="CVE-2024-21853" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23918" id="CVE-2024-23918" title="CVE-2024-23918" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21820" id="CVE-2024-21820" title="CVE-2024-21820" type="cve"></reference>
		</references>
		<description>CVE-2024-24853:Incorrect behavior order in transition between executive monitor and SMI transfer monitor (STM) in some Intel(R) Processor may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2024-25939:Mirrored regions with different values in 3rd Generation Intel(R) Xeon(R) Scalable Processors may allow a privileged user to potentially enable denial of service via local access.&#xA;CVE-2024-24980:Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel(R) Xeon(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2023-42667:Improper isolation in the Intel(R) Core(TM) Ultra Processor stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access.&#xA;CVE-2023-49141:Improper isolation in some Intel(R) Processors stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access.&#xA;CVE-2024-23984:Observable discrepancy in RAPL interface for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.&#xA;CVE-2024-24968:Improper finite state machines (FSMs) in hardware logic in some Intel(R) Processors may allow an privileged user to potentially enable a denial of service via local access.&#xA;CVE-2024-21853:Improper finite state machines (FSMs) in the hardware logic in some 4th and 5th Generation Intel(R) Xeon(R) Processors may allow an authorized user to potentially enable denial of service via local access.&#xA;CVE-2024-23918:Improper conditions check in some Intel(R) Xeon(R) processor memory controller configurations when using Intel(R) SGX may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2024-21820:Incorrect default permissions in some Intel(R) Xeon(R) processor memory controller configurations when using Intel(R) SGX may allow a privileged user to potentially enable escalation of privilege via local access.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="1.u3.fos23" version="20241112">
					<filename>microcode_ctl-20241112-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/microcode_ctl-20241112-1.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2035</id>
		<title>An update for mpg123 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10573" id="CVE-2024-10573" title="CVE-2024-10573" type="cve"></reference>
		</references>
		<description>CVE-2024-10573:An out-of-bounds write flaw was found in mpg123 when handling crafted streams. When decoding PCM, the libmpg123 may write past the end of a heap-located buffer. Consequently, heap corruption may happen, and arbitrary code execution is not discarded. The complexity required to exploit this flaw is considered high as the payload must be validated by the MPEG decoder and the PCM synth before execution. Additionally, to successfully execute the attack, the user must scan through the stream, making web live stream content (such as web radios) a very unlikely attack vector.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="mpg123" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-1.29.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-1.29.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mpg123-plugins-pulseaudio" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-plugins-pulseaudio-1.29.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-plugins-pulseaudio-1.29.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mpg123-plugins-jack" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-plugins-jack-1.29.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-plugins-jack-1.29.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mpg123-plugins-portaudio" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-plugins-portaudio-1.29.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-plugins-portaudio-1.29.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mpg123-libs" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-libs-1.29.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-libs-1.29.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mpg123-devel" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-devel-1.29.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-devel-1.29.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="mpg123-help" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-help-1.29.3-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mpg123-help-1.29.3-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mpg123" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-1.29.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mpg123-1.29.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mpg123-plugins-pulseaudio" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-plugins-pulseaudio-1.29.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mpg123-plugins-pulseaudio-1.29.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mpg123-plugins-jack" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-plugins-jack-1.29.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mpg123-plugins-jack-1.29.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mpg123-plugins-portaudio" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-plugins-portaudio-1.29.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mpg123-plugins-portaudio-1.29.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mpg123-libs" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-libs-1.29.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mpg123-libs-1.29.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mpg123-devel" release="4.u1.fos23" version="1.29.3">
					<filename>mpg123-devel-1.29.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mpg123-devel-1.29.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2036</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21218" id="CVE-2024-21218" title="CVE-2024-21218" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21196" id="CVE-2024-21196" title="CVE-2024-21196" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21207" id="CVE-2024-21207" title="CVE-2024-21207" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21198" id="CVE-2024-21198" title="CVE-2024-21198" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21203" id="CVE-2024-21203" title="CVE-2024-21203" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21213" id="CVE-2024-21213" title="CVE-2024-21213" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21239" id="CVE-2024-21239" title="CVE-2024-21239" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21199" id="CVE-2024-21199" title="CVE-2024-21199" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21197" id="CVE-2024-21197" title="CVE-2024-21197" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21247" id="CVE-2024-21247" title="CVE-2024-21247" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21193" id="CVE-2024-21193" title="CVE-2024-21193" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21212" id="CVE-2024-21212" title="CVE-2024-21212" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21241" id="CVE-2024-21241" title="CVE-2024-21241" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21230" id="CVE-2024-21230" title="CVE-2024-21230" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21236" id="CVE-2024-21236" title="CVE-2024-21236" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21194" id="CVE-2024-21194" title="CVE-2024-21194" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21238" id="CVE-2024-21238" title="CVE-2024-21238" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21237" id="CVE-2024-21237" title="CVE-2024-21237" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21201" id="CVE-2024-21201" title="CVE-2024-21201" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21231" id="CVE-2024-21231" title="CVE-2024-21231" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21219" id="CVE-2024-21219" title="CVE-2024-21219" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21185" id="CVE-2024-21185" title="CVE-2024-21185" type="cve"></reference>
		</references>
		<description>CVE-2024-21218:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21196:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: X Plugin).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21207:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.38 and prior, 8.4.1 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21198:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21203:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21213:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.2 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21239:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21199:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21197:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21247:Vulnerability in the MySQL Client product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Client.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Client accessible data as well as  unauthorized read access to a subset of MySQL Client accessible data. CVSS 3.1 Base Score 3.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2024-21193:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: PS).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21212:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Health Monitor).  Supported versions that are affected are 8.0.39 and prior and  8.4.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21241:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21230:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21236:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21194:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21238:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.0.39 and prior, 8.4.1 and prior and  9.0.1 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21237:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication GCS).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.2 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21201:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21231:Vulnerability in the MySQL Server product of Oracle MySQL (component: Client programs).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 3.1 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2024-21219:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2024-21185:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.38, 8.4.1 and  9.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="mysql" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-libs-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-libs-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-config-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-config-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-common-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-common-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-errmsg-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-errmsg-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-server-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-server-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-devel-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-devel-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-test-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-test-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-help-8.0.40-2.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/mysql-help-8.0.40-2.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-libs-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-libs-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-config-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-config-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-common-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-common-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-errmsg-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-errmsg-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-server-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-server-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-devel-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-devel-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-test-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-test-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="2.u3.fos23" version="8.0.40">
					<filename>mysql-help-8.0.40-2.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/mysql-help-8.0.40-2.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2037</id>
		<title>An update for netpbm is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2008-3522" id="CVE-2008-3522" title="CVE-2008-3522" type="cve"></reference>
		</references>
		<description>CVE-2008-3522:Buffer overflow in the jas_stream_printf function in libjasper/base/jas_stream.c in JasPer 1.900.1 might allow context-dependent attackers to have an unknown impact via vectors related to the mif_hdr_put function and use of vsprintf.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="netpbm" release="6.u1.fos23" version="10.83.01">
					<filename>netpbm-10.83.01-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/netpbm-10.83.01-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="netpbm-devel" release="6.u1.fos23" version="10.83.01">
					<filename>netpbm-devel-10.83.01-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/netpbm-devel-10.83.01-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="netpbm-help" release="6.u1.fos23" version="10.83.01">
					<filename>netpbm-help-10.83.01-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/netpbm-help-10.83.01-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netpbm" release="6.u1.fos23" version="10.83.01">
					<filename>netpbm-10.83.01-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/netpbm-10.83.01-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netpbm-devel" release="6.u1.fos23" version="10.83.01">
					<filename>netpbm-devel-10.83.01-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/netpbm-devel-10.83.01-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netpbm-help" release="6.u1.fos23" version="10.83.01">
					<filename>netpbm-help-10.83.01-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/netpbm-help-10.83.01-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2038</id>
		<title>An update for netty is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29025" id="CVE-2024-29025" title="CVE-2024-29025" type="cve"></reference>
		</references>
		<description>CVE-2024-29025:Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. The `HttpPostRequestDecoder` can be tricked to accumulate data. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits. This vulnerability is fixed in 4.1.108.Final.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="netty" release="22.u3.fos23" version="4.1.13">
					<filename>netty-4.1.13-22.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/netty-4.1.13-22.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="netty-help" release="22.u3.fos23" version="4.1.13">
					<filename>netty-help-4.1.13-22.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/netty-help-4.1.13-22.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netty" release="22.u3.fos23" version="4.1.13">
					<filename>netty-4.1.13-22.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/netty-4.1.13-22.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2039</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9143" id="CVE-2024-9143" title="CVE-2024-9143" type="cve"></reference>
		</references>
		<description>CVE-2024-9143:Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted&#xA;explicit values for the field polynomial can lead to out-of-bounds memory reads&#xA;or writes.&#xA;Impact summary: Out of bound memory writes can lead to an application crash or&#xA;even a possibility of a remote code execution, however, in all the protocols&#xA;involving Elliptic Curve Cryptography that we&#39;re aware of, either only &#34;named&#xA;curves&#34; are supported, or, if explicit curve parameters are supported, they&#xA;specify an X9.62 encoding of binary (GF(2^m)) curves that can&#39;t represent&#xA;problematic input values. Thus the likelihood of existence of a vulnerable&#xA;application is low.&#xA;In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,&#xA;so problematic inputs cannot occur in the context of processing X.509&#xA;certificates.  Any problematic use-cases would have to be using an &#34;exotic&#34;&#xA;curve encoding.&#xA;The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),&#xA;and various supporting BN_GF2m_*() functions.&#xA;Applications working with &#34;exotic&#34; explicit binary (GF(2^m)) curve parameters,&#xA;that make it possible to represent invalid field polynomials with a zero&#xA;constant term, via the above or similar APIs, may terminate abruptly as a&#xA;result of reading or writing outside of array bounds.  Remote code execution&#xA;cannot easily be ruled out.&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u7.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/openresty-openssl111-asan-1.1.1h-2.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u7.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/openresty-openssl111-asan-1.1.1h-2.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2040</id>
		<title>An update for opensc is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-40660" id="CVE-2023-40660" title="CVE-2023-40660" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-40661" id="CVE-2023-40661" title="CVE-2023-40661" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5992" id="CVE-2023-5992" title="CVE-2023-5992" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45615" id="CVE-2024-45615" title="CVE-2024-45615" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45616" id="CVE-2024-45616" title="CVE-2024-45616" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45617" id="CVE-2024-45617" title="CVE-2024-45617" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45618" id="CVE-2024-45618" title="CVE-2024-45618" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45619" id="CVE-2024-45619" title="CVE-2024-45619" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45620" id="CVE-2024-45620" title="CVE-2024-45620" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8443" id="CVE-2024-8443" title="CVE-2024-8443" type="cve"></reference>
		</references>
		<description>CVE-2023-40660:A flaw was found in OpenSC packages that allow a potential PIN bypass. When a token/card is authenticated by one process, it can perform cryptographic operations in other processes when an empty zero-length pin is passed. This issue poses a security risk, particularly for OS logon/screen unlock and for small, permanently connected tokens to computers. Additionally, the token can internally track login status. This flaw allows an attacker to gain unauthorized access, carry out malicious actions, or compromise the system without the user&#39;s awareness.&#xA;CVE-2023-40661:Several memory vulnerabilities were identified within the OpenSC packages, particularly in the card enrollment process using pkcs15-init when a user or administrator enrolls cards. To take advantage of these flaws, an attacker must have physical access to the computer system and employ a custom-crafted USB device or smart card to manipulate responses to APDUs. This manipulation can potentially allow &#xA;compromise key generation, certificate loading, and other card management operations during enrollment.&#xA;CVE-2023-5992:A vulnerability was found in OpenSC where PKCS#1 encryption padding removal is not implemented as side-channel resistant. This issue may result in the potential leak of private data.&#xA;CVE-2024-45615:A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. &#xA;The problem is missing  initialization of variables expected to be initialized (as arguments to other functions, etc.).&#xA;CVE-2024-45616:A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. &#xA;The following problems were caused by insufficient control of the response APDU buffer and its length when communicating with the card.&#xA;CVE-2024-45617:A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. &#xA;Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized.&#xA;CVE-2024-45618:A vulnerability was found in pkcs15-init in OpenSC. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. &#xA;Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized.&#xA;CVE-2024-45619:A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. When buffers are partially filled with data, initialized parts of the buffer can be incorrectly accessed.&#xA;CVE-2024-45620:A vulnerability was found in the pkcs15-init tool in OpenSC. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. When buffers are partially filled with data, initialized parts of the buffer can be incorrectly accessed.&#xA;CVE-2024-8443:A heap-based buffer overflow vulnerability was found in the libopensc OpenPGP driver. A crafted USB device or smart card with malicious responses to the APDUs during the card enrollment process using the `pkcs15-init` tool may lead to out-of-bound rights, possibly resulting in arbitrary code execution.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="opensc" release="11.u4.fos23" version="0.21.0">
					<filename>opensc-0.21.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/opensc-0.21.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="opensc-help" release="11.u4.fos23" version="0.21.0">
					<filename>opensc-help-0.21.0-11.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/opensc-help-0.21.0-11.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opensc" release="11.u4.fos23" version="0.21.0">
					<filename>opensc-0.21.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/opensc-0.21.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2041</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9143" id="CVE-2024-9143" title="CVE-2024-9143" type="cve"></reference>
		</references>
		<description>CVE-2024-9143:Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted&#xA;explicit values for the field polynomial can lead to out-of-bounds memory reads&#xA;or writes.&#xA;Impact summary: Out of bound memory writes can lead to an application crash or&#xA;even a possibility of a remote code execution, however, in all the protocols&#xA;involving Elliptic Curve Cryptography that we&#39;re aware of, either only &#34;named&#xA;curves&#34; are supported, or, if explicit curve parameters are supported, they&#xA;specify an X9.62 encoding of binary (GF(2^m)) curves that can&#39;t represent&#xA;problematic input values. Thus the likelihood of existence of a vulnerable&#xA;application is low.&#xA;In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,&#xA;so problematic inputs cannot occur in the context of processing X.509&#xA;certificates.  Any problematic use-cases would have to be using an &#34;exotic&#34;&#xA;curve encoding.&#xA;The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),&#xA;and various supporting BN_GF2m_*() functions.&#xA;Applications working with &#34;exotic&#34; explicit binary (GF(2^m)) curve parameters,&#xA;that make it possible to represent invalid field polynomials with a zero&#xA;constant term, via the above or similar APIs, may terminate abruptly as a&#xA;result of reading or writing outside of array bounds.  Remote code execution&#xA;cannot easily be ruled out.&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="1" name="openssl" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/openssl-1.1.1m-39.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/openssl-libs-1.1.1m-39.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/openssl-perl-1.1.1m-39.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/openssl-devel-1.1.1m-39.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-help-1.1.1m-39.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/openssl-help-1.1.1m-39.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/openssl-1.1.1m-39.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/openssl-libs-1.1.1m-39.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/openssl-perl-1.1.1m-39.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="39.u19.fos23" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/openssl-devel-1.1.1m-39.u19.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2042</id>
		<title>An update for pam is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10963" id="CVE-2024-10963" title="CVE-2024-10963" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10041" id="CVE-2024-10041" title="CVE-2024-10041" type="cve"></reference>
		</references>
		<description>CVE-2024-10963:A flaw was found in pam_access, where certain rules in its configuration file are mistakenly treated as hostnames. This vulnerability allows attackers to trick the system by pretending to be a trusted hostname, gaining unauthorized access. This issue poses a risk for systems that rely on this feature to control who can access certain services or terminals.&#xA;CVE-2024-10041:A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="pam" release="10.u7.fos23" version="1.5.2">
					<filename>pam-1.5.2-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pam-1.5.2-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam-devel" release="10.u7.fos23" version="1.5.2">
					<filename>pam-devel-1.5.2-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pam-devel-1.5.2-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pam-help" release="10.u7.fos23" version="1.5.2">
					<filename>pam-help-1.5.2-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pam-help-1.5.2-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam" release="10.u7.fos23" version="1.5.2">
					<filename>pam-1.5.2-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pam-1.5.2-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam-devel" release="10.u7.fos23" version="1.5.2">
					<filename>pam-devel-1.5.2-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pam-devel-1.5.2-10.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2043</id>
		<title>An update for pcp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45769" id="CVE-2024-45769" title="CVE-2024-45769" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45770" id="CVE-2024-45770" title="CVE-2024-45770" type="cve"></reference>
		</references>
		<description>CVE-2024-45769:A vulnerability was found in Performance Co-Pilot (PCP).  This flaw allows an attacker to send specially crafted data to the system, which could cause the program to misbehave or crash.&#xA;CVE-2024-45770:A vulnerability was found in Performance Co-Pilot (PCP). This flaw can only be exploited if an attacker has access to a compromised PCP system account. The issue is related to the pmpost tool, which is used to log messages in the system. Under certain conditions, it runs with high-level privileges.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-conf" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-conf-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-conf-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-devel" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-devel-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-devel-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pcp-help" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-help-5.3.7-6.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-help-5.3.7-6.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-PMDA" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-PMDA-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-PCP-PMDA-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-MMV" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-MMV-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-PCP-MMV-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-LogImport" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-LogImport-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-PCP-LogImport-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-PCP-LogSummary" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-LogSummary-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-PCP-LogSummary-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-sar2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-sar2pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-import-sar2pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-iostat2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-iostat2pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-import-iostat2pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-mrtg2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-mrtg2pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-import-mrtg2pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-ganglia2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-ganglia2pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-import-ganglia2pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-import-collectl2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-collectl2pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-import-collectl2pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-zabbix-agent" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-zabbix-agent-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-zabbix-agent-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2elasticsearch" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2elasticsearch-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2elasticsearch-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2graphite" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2graphite-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2graphite-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2influxdb" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2influxdb-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2influxdb-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2json" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2json-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2json-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2spark" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2spark-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2spark-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2xml" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2xml-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2xml-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-export-pcp2zabbix" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2zabbix-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-export-pcp2zabbix-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-podman" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-podman-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-podman-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-perfevent" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-perfevent-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-perfevent-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-infiniband" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-infiniband-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-infiniband-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-activemq" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-activemq-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-activemq-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bind2" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bind2-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-bind2-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-redis" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-redis-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-redis-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nutcracker" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nutcracker-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-nutcracker-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bonding" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bonding-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-bonding-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-dbping" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-dbping-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-dbping-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-ds389" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-ds389-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-ds389log" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389log-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-ds389log-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-elasticsearch" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-elasticsearch-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-elasticsearch-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gpfs" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gpfs-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-gpfs-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gpsd" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gpsd-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-gpsd-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-denki" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-denki-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-denki-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-docker" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-docker-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-docker-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lustre" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lustre-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-lustre-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lustrecomm" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lustrecomm-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-lustrecomm-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-memcache" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-memcache-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-memcache-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mysql" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mysql-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-mysql-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-named" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-named-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-named-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-netfilter" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-netfilter-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-netfilter-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-news" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-news-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-news-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nginx" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nginx-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-nginx-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nfsclient" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nfsclient-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-nfsclient-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-oracle" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-oracle-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-oracle-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-pdns" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-pdns-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-pdns-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-postfix" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-postfix-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-postfix-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-postgresql" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-postgresql-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-postgresql-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-rsyslog" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-rsyslog-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-rsyslog-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-samba" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-samba-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-samba-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-slurm" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-slurm-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-slurm-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-snmp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-snmp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-snmp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-zimbra" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-zimbra-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-zimbra-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-dm" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-dm-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-dm-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bcc" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bcc-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-bcc-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bpf" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bpf-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-bpf-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bpftrace" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bpftrace-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-bpftrace-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gluster" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gluster-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-gluster-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-zswap" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-zswap-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-zswap-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-unbound" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-unbound-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-unbound-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mic" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mic-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-mic-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-haproxy" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-haproxy-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-haproxy-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-libvirt" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-libvirt-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-libvirt-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-openvswitch" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-openvswitch-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-openvswitch-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-rabbitmq" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-rabbitmq-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-rabbitmq-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lio" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lio-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-lio-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-openmetrics" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-openmetrics-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-openmetrics-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-netcheck" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-netcheck-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-netcheck-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mongodb" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mongodb-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-mongodb-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mssql" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mssql-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-mssql-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-json" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-json-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-json-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-apache" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-apache-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-apache-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-bash" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bash-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-bash-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-cifs" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-cifs-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-cifs-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-cisco" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-cisco-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-cisco-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-gfs2" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gfs2-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-gfs2-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-lmsensors" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lmsensors-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-lmsensors-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-logger" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-logger-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-logger-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mailq" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mailq-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-mailq-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-mounts" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mounts-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-mounts-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-nvidia-gpu" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nvidia-gpu-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-nvidia-gpu-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-roomtemp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-roomtemp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-roomtemp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-sendmail" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-sendmail-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-sendmail-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-shping" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-shping-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-shping-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-smart" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-smart-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-smart-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-sockets" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-sockets-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-sockets-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-hacluster" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-hacluster-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-hacluster-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-summary" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-summary-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-summary-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-systemd" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-systemd-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-systemd-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-trace" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-trace-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-trace-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-pmda-weblog" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-weblog-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-pmda-weblog-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-zeroconf" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-zeroconf-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-zeroconf-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pcp" release="6.u6.fos23" version="5.3.7">
					<filename>python3-pcp-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-pcp-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-system-tools" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-system-tools-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-system-tools-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-gui" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-gui-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-gui-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pcp-selinux" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-selinux-5.3.7-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/pcp-selinux-5.3.7-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-conf" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-conf-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-conf-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-devel" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-devel-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-devel-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-PMDA" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-PMDA-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/perl-PCP-PMDA-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-MMV" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-MMV-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/perl-PCP-MMV-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-LogImport" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-LogImport-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/perl-PCP-LogImport-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-PCP-LogSummary" release="6.u6.fos23" version="5.3.7">
					<filename>perl-PCP-LogSummary-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/perl-PCP-LogSummary-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-sar2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-sar2pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-import-sar2pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-iostat2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-iostat2pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-import-iostat2pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-mrtg2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-mrtg2pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-import-mrtg2pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-ganglia2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-ganglia2pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-import-ganglia2pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-import-collectl2pcp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-import-collectl2pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-import-collectl2pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-zabbix-agent" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-zabbix-agent-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-zabbix-agent-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2elasticsearch" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2elasticsearch-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2elasticsearch-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2graphite" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2graphite-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2graphite-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2influxdb" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2influxdb-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2influxdb-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2json" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2json-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2json-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2spark" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2spark-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2spark-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2xml" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2xml-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2xml-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-export-pcp2zabbix" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-export-pcp2zabbix-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-export-pcp2zabbix-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-podman" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-podman-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-podman-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-perfevent" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-perfevent-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-perfevent-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-infiniband" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-infiniband-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-infiniband-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-activemq" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-activemq-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-activemq-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bind2" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bind2-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-bind2-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-redis" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-redis-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-redis-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nutcracker" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nutcracker-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-nutcracker-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bonding" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bonding-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-bonding-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-dbping" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-dbping-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-dbping-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-ds389" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-ds389-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-ds389log" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-ds389log-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-ds389log-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-elasticsearch" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-elasticsearch-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-elasticsearch-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gpfs" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gpfs-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-gpfs-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gpsd" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gpsd-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-gpsd-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-denki" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-denki-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-denki-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-docker" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-docker-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-docker-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lustre" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lustre-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-lustre-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lustrecomm" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lustrecomm-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-lustrecomm-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-memcache" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-memcache-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-memcache-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mysql" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mysql-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-mysql-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-named" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-named-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-named-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-netfilter" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-netfilter-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-netfilter-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-news" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-news-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-news-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nginx" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nginx-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-nginx-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nfsclient" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nfsclient-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-nfsclient-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-oracle" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-oracle-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-oracle-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-pdns" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-pdns-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-pdns-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-postfix" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-postfix-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-postfix-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-postgresql" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-postgresql-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-postgresql-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-rsyslog" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-rsyslog-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-rsyslog-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-samba" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-samba-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-samba-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-slurm" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-slurm-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-slurm-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-snmp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-snmp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-snmp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-zimbra" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-zimbra-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-zimbra-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-dm" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-dm-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-dm-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bpf" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bpf-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-bpf-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bpftrace" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bpftrace-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-bpftrace-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gluster" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gluster-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-gluster-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-zswap" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-zswap-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-zswap-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-unbound" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-unbound-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-unbound-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mic" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mic-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-mic-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-haproxy" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-haproxy-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-haproxy-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-libvirt" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-libvirt-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-libvirt-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-openvswitch" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-openvswitch-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-openvswitch-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-rabbitmq" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-rabbitmq-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-rabbitmq-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lio" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lio-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-lio-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-openmetrics" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-openmetrics-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-openmetrics-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-netcheck" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-netcheck-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-netcheck-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mongodb" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mongodb-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-mongodb-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-json" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-json-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-json-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-apache" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-apache-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-apache-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-bash" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-bash-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-bash-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-cifs" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-cifs-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-cifs-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-cisco" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-cisco-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-cisco-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-gfs2" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-gfs2-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-gfs2-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-lmsensors" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-lmsensors-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-lmsensors-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-logger" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-logger-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-logger-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mailq" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mailq-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-mailq-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-mounts" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-mounts-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-mounts-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-nvidia-gpu" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-nvidia-gpu-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-nvidia-gpu-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-roomtemp" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-roomtemp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-roomtemp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-sendmail" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-sendmail-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-sendmail-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-shping" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-shping-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-shping-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-smart" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-smart-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-smart-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-sockets" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-sockets-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-sockets-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-hacluster" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-hacluster-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-hacluster-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-summary" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-summary-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-summary-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-systemd" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-systemd-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-systemd-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-trace" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-trace-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-trace-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-pmda-weblog" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-pmda-weblog-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-pmda-weblog-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-zeroconf" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-zeroconf-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-zeroconf-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pcp" release="6.u6.fos23" version="5.3.7">
					<filename>python3-pcp-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-pcp-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-system-tools" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-system-tools-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-system-tools-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-gui" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-gui-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-gui-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pcp-selinux" release="6.u6.fos23" version="5.3.7">
					<filename>pcp-selinux-5.3.7-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/pcp-selinux-5.3.7-6.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2044</id>
		<title>An update for perl-Module-ScanDeps is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10224" id="CVE-2024-10224" title="CVE-2024-10224" type="cve"></reference>
		</references>
		<description>CVE-2024-10224:Qualys discovered that if unsanitized input was used with the library Modules::ScanDeps, before version 1.36 a local attacker could possibly execute arbitrary shell commands by open()ing a &#34;pesky pipe&#34; (such as passing &#34;commands|&#34; as a filename) or by passing arbitrary strings to eval().</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="perl-Module-ScanDeps" release="2.u1.fos23" version="1.31">
					<filename>perl-Module-ScanDeps-1.31-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-Module-ScanDeps-1.31-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Module-ScanDeps-help" release="2.u1.fos23" version="1.31">
					<filename>perl-Module-ScanDeps-help-1.31-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-Module-ScanDeps-help-1.31-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2045</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8929" id="CVE-2024-8929" title="CVE-2024-8929" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11233" id="CVE-2024-11233" title="CVE-2024-11233" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11234" id="CVE-2024-11234" title="CVE-2024-11234" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11236" id="CVE-2024-11236" title="CVE-2024-11236" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8932" id="CVE-2024-8932" title="CVE-2024-8932" type="cve"></reference>
		</references>
		<description>CVE-2024-8929:In PHP versions 8.1.* before 8.1.31, 8.2.* before 8.2.26, 8.3.* before 8.3.14, a hostile MySQL server can cause the client to disclose the content of its heap containing data from other SQL requests and possible other data belonging to different users of the same server.&#xA;CVE-2024-11233:In PHP versions 8.1.* before 8.1.31, 8.2.* before 8.2.26, 8.3.* before 8.3.14, due to an error in convert.quoted-printable-decode filter certain data can lead to buffer overread by one byte, which can in certain circumstances lead to crashes or disclose content of other memory areas.&#xA;CVE-2024-11234:In PHP versions 8.1.* before 8.1.31, 8.2.* before 8.2.26, 8.3.* before 8.3.14, when using streams with configured proxy and &#34;request_fulluri&#34; option, the URI is not properly sanitized which can lead to HTTP request smuggling and allow the attacker to use the proxy to perform arbitrary HTTP requests originating from the server, thus potentially gaining access to resources not normally available to the external user.&#xA;CVE-2024-11236:In PHP versions 8.1.* before 8.1.31, 8.2.* before 8.2.26, 8.3.* before 8.3.14, uncontrolled long string inputs to ldap_escape() function on 32-bit systems can cause an integer overflow, resulting in an out-of-bounds write.&#xA;CVE-2024-8932:In PHP versions 8.1.* before 8.1.31, 8.2.* before 8.2.26, 8.3.* before 8.3.14, uncontrolled long string inputs to ldap_escape() function on 32-bit systems can cause an integer overflow, resulting in an out-of-bounds write.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="php" release="8.u6.fos23" version="8.0.30">
					<filename>php-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="8.u6.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-cli-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="8.u6.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-dbg-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="8.u6.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-fpm-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="8.u6.fos23" version="8.0.30">
					<filename>php-common-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-common-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="8.u6.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-devel-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="8.u6.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-opcache-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="8.u6.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-ldap-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="8.u6.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-pdo-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="8.u6.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-mysqlnd-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="8.u6.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-pgsql-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="8.u6.fos23" version="8.0.30">
					<filename>php-process-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-process-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="8.u6.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-odbc-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="8.u6.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-soap-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="8.u6.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-snmp-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="8.u6.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-xml-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="8.u6.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-mbstring-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="8.u6.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-gd-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="8.u6.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-bcmath-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="8.u6.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-gmp-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="8.u6.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-dba-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="8.u6.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-tidy-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="8.u6.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-embedded-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="8.u6.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-intl-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="8.u6.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-enchant-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="8.u6.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-sodium-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="8.u6.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-ffi-8.0.30-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="php-help" release="8.u6.fos23" version="8.0.30">
					<filename>php-help-8.0.30-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/php-help-8.0.30-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="8.u6.fos23" version="8.0.30">
					<filename>php-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="8.u6.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-cli-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="8.u6.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-dbg-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="8.u6.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-fpm-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="8.u6.fos23" version="8.0.30">
					<filename>php-common-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-common-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="8.u6.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-devel-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="8.u6.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-opcache-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="8.u6.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-ldap-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="8.u6.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-pdo-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="8.u6.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-mysqlnd-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="8.u6.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-pgsql-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="8.u6.fos23" version="8.0.30">
					<filename>php-process-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-process-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="8.u6.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-odbc-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="8.u6.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-soap-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="8.u6.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-snmp-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="8.u6.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-xml-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="8.u6.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-mbstring-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="8.u6.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-gd-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="8.u6.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-bcmath-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="8.u6.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-gmp-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="8.u6.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-dba-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="8.u6.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-tidy-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="8.u6.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-embedded-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="8.u6.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-intl-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="8.u6.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-enchant-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="8.u6.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-sodium-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="8.u6.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/php-ffi-8.0.30-8.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2046</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56378" id="CVE-2024-56378" title="CVE-2024-56378" type="cve"></reference>
		</references>
		<description>CVE-2024-56378:libpoppler.so in Poppler through 24.12.0 has an out-of-bounds read vulnerability within the JBIG2Bitmap::combine function in JBIG2Stream.cc.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="poppler" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-devel-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-glib-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-glib-devel-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-glib-doc-0.90.0-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-qt5-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-qt5-devel-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-cpp-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-cpp-devel-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-utils-0.90.0-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/poppler-help-0.90.0-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-devel-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-glib-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-glib-devel-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-qt5-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-qt5-devel-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-cpp-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-cpp-devel-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="10.u7.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/poppler-utils-0.90.0-10.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2047</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10978" id="CVE-2024-10978" title="CVE-2024-10978" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10979" id="CVE-2024-10979" title="CVE-2024-10979" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10976" id="CVE-2024-10976" title="CVE-2024-10976" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10977" id="CVE-2024-10977" title="CVE-2024-10977" type="cve"></reference>
		</references>
		<description>CVE-2024-10978:Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended.  An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature.  The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker.  If that query reacts to current_setting(&#39;role&#39;) or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION.  The attacker does not control which incorrect user ID applies.  Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-10979:Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH).  That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-10976:Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended.  CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes.  They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy.  This has the same consequences as the two earlier CVEs.  That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles.  This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs.  Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications.  This affects only databases that have used CREATE POLICY to define a row security policy.  An attacker must tailor an attack to a particular application&#39;s pattern of query plan reuse, user ID changes, and role-specific row security policies.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.&#xA;CVE-2024-10977:Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application.  For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results.  This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u4.fos23" version="13.18">
					<filename>postgresql-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u4.fos23" version="13.18">
					<filename>postgresql-private-libs-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-private-libs-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u4.fos23" version="13.18">
					<filename>postgresql-private-devel-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-private-devel-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u4.fos23" version="13.18">
					<filename>postgresql-server-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-server-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u4.fos23" version="13.18">
					<filename>postgresql-docs-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-docs-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u4.fos23" version="13.18">
					<filename>postgresql-contrib-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-contrib-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u4.fos23" version="13.18">
					<filename>postgresql-server-devel-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-server-devel-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u4.fos23" version="13.18">
					<filename>postgresql-test-rpm-macros-13.18-1.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-test-rpm-macros-13.18-1.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u4.fos23" version="13.18">
					<filename>postgresql-static-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-static-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u4.fos23" version="13.18">
					<filename>postgresql-plperl-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-plperl-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u4.fos23" version="13.18">
					<filename>postgresql-plpython3-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-plpython3-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u4.fos23" version="13.18">
					<filename>postgresql-pltcl-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-pltcl-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u4.fos23" version="13.18">
					<filename>postgresql-test-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-test-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u4.fos23" version="13.18">
					<filename>postgresql-llvmjit-13.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/postgresql-llvmjit-13.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u4.fos23" version="13.18">
					<filename>postgresql-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u4.fos23" version="13.18">
					<filename>postgresql-private-libs-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-private-libs-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u4.fos23" version="13.18">
					<filename>postgresql-private-devel-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-private-devel-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u4.fos23" version="13.18">
					<filename>postgresql-server-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-server-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u4.fos23" version="13.18">
					<filename>postgresql-docs-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-docs-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u4.fos23" version="13.18">
					<filename>postgresql-contrib-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-contrib-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u4.fos23" version="13.18">
					<filename>postgresql-server-devel-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-server-devel-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u4.fos23" version="13.18">
					<filename>postgresql-static-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-static-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u4.fos23" version="13.18">
					<filename>postgresql-plperl-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-plperl-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u4.fos23" version="13.18">
					<filename>postgresql-plpython3-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-plpython3-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u4.fos23" version="13.18">
					<filename>postgresql-pltcl-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-pltcl-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u4.fos23" version="13.18">
					<filename>postgresql-test-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-test-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u4.fos23" version="13.18">
					<filename>postgresql-llvmjit-13.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/postgresql-llvmjit-13.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2048</id>
		<title>An update for proftpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-48651" id="CVE-2024-48651" title="CVE-2024-48651" type="cve"></reference>
		</references>
		<description>CVE-2024-48651:In ProFTPD through 1.3.8b before cec01cc, supplemental group inheritance grants unintended access to GID 0 because of the lack of supplemental groups from mod_sql.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="proftpd" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-devel" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-devel-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-devel-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-ldap" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-ldap-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-ldap-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-mysql" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-mysql-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-mysql-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-postgresql" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-postgresql-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-postgresql-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-sqlite" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-sqlite-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-sqlite-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-utils" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-utils-1.3.8b-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/proftpd-utils-1.3.8b-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-devel" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-devel-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-devel-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-ldap" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-ldap-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-ldap-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-mysql" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-mysql-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-mysql-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-postgresql" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-postgresql-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-postgresql-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-sqlite" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-sqlite-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-sqlite-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-utils" release="5.u2.fos23" version="1.3.8b">
					<filename>proftpd-utils-1.3.8b-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/proftpd-utils-1.3.8b-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2049</id>
		<title>An update for python-jinja2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56201" id="CVE-2024-56201" title="CVE-2024-56201" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56326" id="CVE-2024-56326" title="CVE-2024-56326" type="cve"></reference>
		</references>
		<description>CVE-2024-56201:Jinja is an extensible templating engine. Prior to 3.1.5, a bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja&#39;s sandbox is used. To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename. This vulnerability is fixed in 3.1.5.&#xA;CVE-2024-56326:Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja&#39;s sandbox does catch calls to str.format and ensures they don&#39;t escape the sandbox. However, it&#39;s possible to store a reference to a malicious string&#39;s format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="python3-jinja2" release="6.u4.fos23" version="3.0.3">
					<filename>python3-jinja2-3.0.3-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-jinja2-3.0.3-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-jinja2-help" release="6.u4.fos23" version="3.0.3">
					<filename>python-jinja2-help-3.0.3-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python-jinja2-help-3.0.3-6.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2050</id>
		<title>An update for python-requests is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1682" id="CVE-2024-1682" title="CVE-2024-1682" type="cve"></reference>
		</references>
		<description>CVE-2024-1682:An unclaimed Amazon S3 bucket, &#39;codeconf&#39;, is referenced in an audio file link within the .rst documentation file. This bucket has been claimed by an external party. The use of this unclaimed S3 bucket could lead to data integrity issues, data leakage, availability problems, loss of trustworthiness, and potential further attacks if the bucket is used to host malicious content or as a pivot point for further attacks.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="python3-requests" release="9.u6.fos23" version="2.26.0">
					<filename>python3-requests-2.26.0-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-requests-2.26.0-9.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-requests-help" release="9.u6.fos23" version="2.26.0">
					<filename>python-requests-help-2.26.0-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python-requests-help-2.26.0-9.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2051</id>
		<title>An update for python-tornado is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52804" id="CVE-2024-52804" title="CVE-2024-52804" type="cve"></reference>
		</references>
		<description>CVE-2024-52804:Tornado is a Python web framework and asynchronous networking library. The algorithm used for parsing HTTP cookies in Tornado versions prior to 6.4.2 sometimes has quadratic complexity, leading to excessive CPU consumption when parsing maliciously-crafted cookie headers. This parsing occurs in the event loop thread and may block the processing of other requests. Version 6.4.2 fixes the issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="python3-tornado" release="3.u2.fos23" version="6.1">
					<filename>python3-tornado-6.1-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-tornado-6.1-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python-tornado-help" release="3.u2.fos23" version="6.1">
					<filename>python-tornado-help-6.1-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python-tornado-help-6.1-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-tornado" release="3.u2.fos23" version="6.1">
					<filename>python3-tornado-6.1-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-tornado-6.1-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python-tornado-help" release="3.u2.fos23" version="6.1">
					<filename>python-tornado-help-6.1-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python-tornado-help-6.1-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2052</id>
		<title>An update for python-waitress is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49768" id="CVE-2024-49768" title="CVE-2024-49768" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49769" id="CVE-2024-49769" title="CVE-2024-49769" type="cve"></reference>
		</references>
		<description>CVE-2024-49768:Waitress is a Web Server Gateway Interface server for Python 2 and 3. A remote client may send a request that is exactly recv_bytes (defaults to 8192) long, followed by a secondary request using HTTP pipelining. When request lookahead is disabled (default) we won&#39;t read any more requests, and when the first request fails due to a parsing error, we simply close the connection. However when request lookahead is enabled, it is possible to process and receive the first request, start sending the error message back to the client while we read the next request and queue it. This will allow the secondary request to be serviced by the worker thread while the connection should be closed. Waitress 3.0.1 fixes the race condition. As a workaround, disable channel_request_lookahead, this is set to 0 by default disabling this feature.&#xA;CVE-2024-49769:Waitress is a Web Server Gateway Interface server for Python 2 and 3. When a remote client closes the connection before waitress has had the opportunity to call getpeername() waitress won&#39;t correctly clean up the connection leading to the main thread attempting to write to a socket that no longer exists, but not removing it from the list of sockets to attempt to process. This leads to a busy-loop calling the write function. A remote attacker could run waitress out of available sockets with very little resources required. Waitress 3.0.1 contains fixes that remove the race condition.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="python3-waitress" release="5.u2.fos23" version="2.0.0">
					<filename>python3-waitress-2.0.0-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-waitress-2.0.0-5.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2053</id>
		<title>An update for python-werkzeug is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49767" id="CVE-2024-49767" title="CVE-2024-49767" type="cve"></reference>
		</references>
		<description>CVE-2024-49767:Werkzeug is a Web Server Gateway Interface web application library. Applications using `werkzeug.formparser.MultiPartParser` corresponding to a version of Werkzeug prior to 3.0.6 to parse `multipart/form-data` requests (e.g. all flask applications) are vulnerable to a relatively simple but effective resource exhaustion (denial of service) attack. A specifically crafted form submission request can cause the parser to allocate and block 3 to 8 times the upload size in main memory. There is no upper limit; a single upload at 1 Gbit/s can exhaust 32 GB of RAM in less than 60 seconds. Werkzeug version 3.0.6 fixes this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="python3-werkzeug" release="5.u4.fos23" version="2.0.3">
					<filename>python3-werkzeug-2.0.3-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-werkzeug-2.0.3-5.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-werkzeug-help" release="5.u4.fos23" version="2.0.3">
					<filename>python-werkzeug-help-2.0.3-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python-werkzeug-help-2.0.3-5.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2054</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6232" id="CVE-2024-6232" title="CVE-2024-6232" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3219" id="CVE-2024-3219" title="CVE-2024-3219" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0450" id="CVE-2024-0450" title="CVE-2024-0450" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6597" id="CVE-2023-6597" title="CVE-2023-6597" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4032" id="CVE-2024-4032" title="CVE-2024-4032" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11168" id="CVE-2024-11168" title="CVE-2024-11168" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9287" id="CVE-2024-9287" title="CVE-2024-9287" type="cve"></reference>
		</references>
		<description>CVE-2024-6232:There is a MEDIUM severity vulnerability affecting CPython.&#xA;Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.&#xA;CVE-2024-3219:The&#xA; “socket” module provides a pure-Python fallback to the &#xA;socket.socketpair() function for platforms that don’t support AF_UNIX, &#xA;such as Windows. This pure-Python implementation uses AF_INET or &#xA;AF_INET6 to create a local connected pair of sockets. The connection &#xA;between the two sockets was not verified before passing the two sockets &#xA;back to the user, which leaves the server socket vulnerable to a &#xA;connection race from a malicious local peer.&#xA;Platforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability. Versions prior to CPython 3.5 are not affected due to the vulnerable API not being included.&#xA;CVE-2024-0450:An issue was found in the CPython `zipfile` module affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.&#xA;The zipfile module is vulnerable to “quoted-overlap” zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.&#xA;CVE-2023-6597:An issue was found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.&#xA;The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.&#xA;CVE-2024-4032:The “ipaddress” module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as “globally reachable” or “private”. This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn’t be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.&#xA;CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.&#xA;CVE-2024-11168:The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren&#39;t IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.&#xA;CVE-2024-9287:A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment &#34;activation&#34; scripts (ie &#34;source venv/bin/activate&#34;). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren&#39;t activated before being used (ie &#34;./venv/bin/python&#34;) are not affected.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="python3" release="36.u18.fos23" version="3.9.9">
					<filename>python3-3.9.9-36.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-3.9.9-36.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="36.u18.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-36.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-unversioned-command-3.9.9-36.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="36.u18.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-36.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-devel-3.9.9-36.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="36.u18.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-36.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-debug-3.9.9-36.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="36.u18.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-36.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-help-3.9.9-36.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="36.u18.fos23" version="3.9.9">
					<filename>python3-3.9.9-36.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-3.9.9-36.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="36.u18.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-36.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-unversioned-command-3.9.9-36.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="36.u18.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-36.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-devel-3.9.9-36.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="36.u18.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-36.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-debug-3.9.9-36.u18.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2055</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6505" id="CVE-2024-6505" title="CVE-2024-6505" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7409" id="CVE-2024-7409" title="CVE-2024-7409" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8612" id="CVE-2024-8612" title="CVE-2024-8612" type="cve"></reference>
		</references>
		<description>CVE-2024-6505:A flaw was found in the virtio-net device in QEMU. When enabling the RSS feature on the virtio-net network card, the indirections_table data within RSS becomes controllable. Setting excessively large values may cause an index out-of-bounds issue, potentially resulting in heap overflow access. This flaw allows a privileged user in the guest to crash the QEMU process on the host.&#xA;CVE-2024-7409:A flaw was found in the QEMU NBD Server. This vulnerability allows a denial of service (DoS) attack via improper synchronization during socket closure when a client keeps a socket open as the server is taken offline.&#xA;CVE-2024-8612:A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="10" name="qemu" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-guest-agent-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-101.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-help-6.2.0-101.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-img-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-block-rbd-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-block-ssh-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-block-iscsi-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-block-curl-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-hw-usb-host-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-seabios-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-system-aarch64-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-system-arm-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-system-x86_64-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-101.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qemu-system-riscv-6.2.0-101.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-guest-agent-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-img-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-block-rbd-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-block-ssh-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-block-iscsi-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-block-curl-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-hw-usb-host-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-system-aarch64-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-system-arm-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-system-x86_64-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="101.u20.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-101.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qemu-system-riscv-6.2.0-101.u20.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2056</id>
		<title>An update for qpdf is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-34503" id="CVE-2022-34503" title="CVE-2022-34503" type="cve"></reference>
		</references>
		<description>CVE-2022-34503:QPDF v8.4.2 was discovered to contain a heap buffer overflow via the function QPDF::processXRefStream. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="qpdf" release="5.u2.fos23" version="8.4.2">
					<filename>qpdf-8.4.2-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qpdf-8.4.2-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qpdf-devel" release="5.u2.fos23" version="8.4.2">
					<filename>qpdf-devel-8.4.2-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qpdf-devel-8.4.2-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qpdf-help" release="5.u2.fos23" version="8.4.2">
					<filename>qpdf-help-8.4.2-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/qpdf-help-8.4.2-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qpdf" release="5.u2.fos23" version="8.4.2">
					<filename>qpdf-8.4.2-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qpdf-8.4.2-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qpdf-devel" release="5.u2.fos23" version="8.4.2">
					<filename>qpdf-devel-8.4.2-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/qpdf-devel-8.4.2-5.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2057</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-31228" id="CVE-2024-31228" title="CVE-2024-31228" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-31449" id="CVE-2024-31449" title="CVE-2024-31449" type="cve"></reference>
		</references>
		<description>CVE-2024-31228:Redis is an open source, in-memory database that persists on disk. Authenticated users can trigger a denial-of-service by using specially crafted, long string match patterns on supported commands such as `KEYS`, `SCAN`, `PSUBSCRIBE`, `FUNCTION LIST`, `COMMAND LIST` and ACL definitions. Matching of extremely long patterns may result in unbounded recursion, leading to stack overflow and process crash. This problem has been fixed in Redis versions 6.2.16, 7.2.6, and 7.4.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2024-31449:Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to trigger a stack buffer overflow in the bit library, which may potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This problem has been fixed in Redis versions 6.2.16, 7.2.6, and 7.4.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u9.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/redis5-5.0.7-6.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u9.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/redis5-devel-5.0.7-6.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u9.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/redis5-doc-5.0.7-6.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u9.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/redis5-5.0.7-6.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u9.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/redis5-devel-5.0.7-6.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2058</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49761" id="CVE-2024-49761" title="CVE-2024-49761" type="cve"></reference>
		</references>
		<description>CVE-2024-49761:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.9 has a ReDoS vulnerability when it parses an XML that has many digits between &amp;# and x...; in a hex numeric character reference (&amp;#x...;). This does not happen with Ruby 3.2 or later. Ruby 3.1 is the only affected maintained Ruby. The REXML gem 3.3.9 or later include the patch to fix the vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="ruby" release="141.u15.fos23" version="3.0.3">
					<filename>ruby-3.0.3-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ruby-3.0.3-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="141.u15.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ruby-devel-3.0.3-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="141.u15.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygems-3.2.32-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="141.u15.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygems-devel-3.2.32-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="141.u15.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-rake-13.0.3-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="141.u15.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-rbs-1.4.0-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="141.u15.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ruby-irb-3.0.3-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="141.u15.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-rdoc-6.3.3-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="141.u15.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ruby-help-3.0.3-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="141.u15.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-bigdecimal-3.0.0-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="141.u15.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-did_you_mean-1.5.0-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="141.u15.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-io-console-0.5.7-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="141.u15.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-json-2.5.1-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="141.u15.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-minitest-5.14.2-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="141.u15.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-openssl-2.2.1-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="141.u15.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-141.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-psych-3.3.2-141.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="141.u15.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-test-unit-3.3.7-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="141.u15.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-rexml-3.2.5-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="141.u15.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-rss-0.2.9-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="141.u15.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-141.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-typeprof-0.15.2-141.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="141.u15.fos23" version="3.0.3">
					<filename>ruby-3.0.3-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ruby-3.0.3-141.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="141.u15.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ruby-devel-3.0.3-141.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="141.u15.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rubygem-bigdecimal-3.0.0-141.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="141.u15.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rubygem-io-console-0.5.7-141.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="141.u15.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rubygem-json-2.5.1-141.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="141.u15.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rubygem-openssl-2.2.1-141.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="141.u15.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-141.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rubygem-psych-3.3.2-141.u15.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2059</id>
		<title>An update for rubygem-actionmailer is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47889" id="CVE-2024-47889" title="CVE-2024-47889" type="cve"></reference>
		</references>
		<description>CVE-2024-47889:Action Mailer is a framework for designing email service layers. Starting in version 3.0.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in the block_format helper in Action Mailer. Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. As a workaround, users can avoid calling the `block_format` helper or upgrade to Ruby 3.2. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="1" name="rubygem-actionmailer" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-actionmailer-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-actionmailer-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-actionmailer-doc" release="2.u1.fos23" version="6.1.4.1">
					<filename>rubygem-actionmailer-doc-6.1.4.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-actionmailer-doc-6.1.4.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2060</id>
		<title>An update for rubygem-actionpack is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41128" id="CVE-2024-41128" title="CVE-2024-41128" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47887" id="CVE-2024-47887" title="CVE-2024-47887" type="cve"></reference>
		</references>
		<description>CVE-2024-41128:Action Pack is a framework for handling and responding to web requests. Starting in version 3.1.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to version 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. One may use Ruby 3.2 as a workaround. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.&#xA;CVE-2024-47887:Action Pack is a framework for handling and responding to web requests. Starting in version 4.0.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in Action Controller&#39;s HTTP Token authentication. For applications using HTTP Token authentication via `authenticate_or_request_with_http_token` or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. One may choose to use Ruby 3.2 as a workaround.Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="1" name="rubygem-actionpack" release="7.u4.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-6.1.4.1-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-actionpack-6.1.4.1-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-actionpack-doc" release="7.u4.fos23" version="6.1.4.1">
					<filename>rubygem-actionpack-doc-6.1.4.1-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-actionpack-doc-6.1.4.1-7.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2061</id>
		<title>An update for rubygem-puma is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45614" id="CVE-2024-45614" title="CVE-2024-45614" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-24790" id="CVE-2022-24790" title="CVE-2022-24790" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-40175" id="CVE-2023-40175" title="CVE-2023-40175" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21647" id="CVE-2024-21647" title="CVE-2024-21647" type="cve"></reference>
		</references>
		<description>CVE-2024-45614:Puma is a Ruby/Rack web server built for parallelism. In affected versions clients could clobber values set by intermediate proxies (such as X-Forwarded-For) by providing a underscore version of the same header (X-Forwarded_For). Any users relying on proxy set variables is affected. v6.4.3/v5.6.9 now discards any headers using underscores if the non-underscore version also exists. Effectively, allowing the proxy defined headers to always win. Users are advised to upgrade. Nginx has a underscores_in_headers configuration variable to discard these headers at the proxy level as a mitigation. Any users that are implicitly trusting the proxy defined headers for security should immediately cease doing so until upgraded to the fixed versions.&#xA;CVE-2022-24790:Puma is a simple, fast, multi-threaded, parallel HTTP 1.1 server for Ruby/Rack applications. When using Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230 standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow requests to be smuggled via the front-end proxy to Puma. The vulnerability has been fixed in 5.6.4 and 4.3.12. Users are advised to upgrade as soon as possible. Workaround: when deploying a proxy in front of Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.&#xA;CVE-2023-40175:Puma is a Ruby/Rack web server built for parallelism. Prior to versions 6.3.1 and 5.6.7, puma exhibited incorrect behavior when parsing chunked transfer encoding bodies and zero-length Content-Length headers in a way that allowed HTTP request smuggling. Severity of this issue is highly dependent on the nature of the web site using puma is. This could be caused by either incorrect parsing of trailing fields in chunked transfer encoding bodies or by parsing of blank/zero-length Content-Length headers. Both issues have been addressed and this vulnerability has been fixed in versions 6.3.1 and 5.6.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;CVE-2024-21647:Puma is a web server for Ruby/Rack applications built for parallelism. Prior to version 6.4.2, puma exhibited incorrect behavior when parsing chunked transfer encoding bodies in a way that allowed HTTP request smuggling. Fixed versions limits the size of chunk extensions. Without this limit, an attacker could cause unbounded resource (CPU, network bandwidth) consumption. This vulnerability has been fixed in versions 6.4.2 and 5.6.8.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="rubygem-puma" release="3.u3.fos23" version="5.6.5">
					<filename>rubygem-puma-5.6.5-3.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-puma-5.6.5-3.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-puma-doc" release="3.u3.fos23" version="5.6.5">
					<filename>rubygem-puma-doc-5.6.5-3.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-puma-doc-5.6.5-3.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-puma" release="3.u3.fos23" version="5.6.5">
					<filename>rubygem-puma-5.6.5-3.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rubygem-puma-5.6.5-3.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2062</id>
		<title>An update for rubygem-sinatra is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45442" id="CVE-2022-45442" title="CVE-2022-45442" type="cve"></reference>
		</references>
		<description>CVE-2022-45442:Sinatra is a domain-specific language for creating web applications in Ruby. An issue was discovered in Sinatra 2.0 before 2.2.3 and 3.0 before 3.0.4. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a response when the filename is derived from user-supplied input. Version 2.2.3 and 3.0.4 contain patches for this issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="1" name="rubygem-sinatra" release="3.u2.fos23" version="2.0.8.1">
					<filename>rubygem-sinatra-2.0.8.1-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-sinatra-2.0.8.1-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-sinatra-help" release="3.u2.fos23" version="2.0.8.1">
					<filename>rubygem-sinatra-help-2.0.8.1-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rubygem-sinatra-help-2.0.8.1-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2063</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45310" id="CVE-2024-45310" title="CVE-2024-45310" type="cve"></reference>
		</references>
		<description>CVE-2024-45310:runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack&#39;s scope but the exact scope of protection hasn&#39;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.&#xA;Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual&#xA;user on the host (such as with rootless containers that don&#39;t use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="runc" release="31.u10.fos23" version="1.1.3">
					<filename>runc-1.1.3-31.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/runc-1.1.3-31.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="runc" release="31.u10.fos23" version="1.1.3">
					<filename>runc-1.1.3-31.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/runc-1.1.3-31.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2064</id>
		<title>An update for socat is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-54661" id="CVE-2024-54661" title="CVE-2024-54661" type="cve"></reference>
		</references>
		<description>CVE-2024-54661:readline.sh in socat through 1.8.0.1 relies on the /tmp/$USER/stderr2 file.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="socat" release="9.u1.fos23" version="1.7.3.2">
					<filename>socat-1.7.3.2-9.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/socat-1.7.3.2-9.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="socat-help" release="9.u1.fos23" version="1.7.3.2">
					<filename>socat-help-1.7.3.2-9.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/socat-help-1.7.3.2-9.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="socat" release="9.u1.fos23" version="1.7.3.2">
					<filename>socat-1.7.3.2-9.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/socat-1.7.3.2-9.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2065</id>
		<title>An update for sox is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-13590" id="CVE-2019-13590" title="CVE-2019-13590" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-8354" id="CVE-2019-8354" title="CVE-2019-8354" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-8355" id="CVE-2019-8355" title="CVE-2019-8355" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-8356" id="CVE-2019-8356" title="CVE-2019-8356" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-8357" id="CVE-2019-8357" title="CVE-2019-8357" type="cve"></reference>
		</references>
		<description>CVE-2019-13590:An issue was discovered in libsox.a in SoX 14.4.2. In sox-fmt.h (startread function), there is an integer overflow on the result of integer addition (wraparound to 0) fed into the lsx_calloc macro that wraps malloc. When a NULL pointer is returned, it is used without a prior check that it is a valid pointer, leading to a NULL pointer dereference on lsx_readbuf in formats_i.c.&#xA;CVE-2019-8354:An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.&#xA;CVE-2019-8355:An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.&#xA;CVE-2019-8356:An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.&#xA;CVE-2019-8357:An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="sox" release="31.u2.fos23" version="14.4.2.0">
					<filename>sox-14.4.2.0-31.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/sox-14.4.2.0-31.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sox-devel" release="31.u2.fos23" version="14.4.2.0">
					<filename>sox-devel-14.4.2.0-31.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/sox-devel-14.4.2.0-31.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sox-help" release="31.u2.fos23" version="14.4.2.0">
					<filename>sox-help-14.4.2.0-31.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/sox-help-14.4.2.0-31.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sox" release="31.u2.fos23" version="14.4.2.0">
					<filename>sox-14.4.2.0-31.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/sox-14.4.2.0-31.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sox-devel" release="31.u2.fos23" version="14.4.2.0">
					<filename>sox-devel-14.4.2.0-31.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/sox-devel-14.4.2.0-31.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2066</id>
		<title>An update for spark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23945" id="CVE-2024-23945" title="CVE-2024-23945" type="cve"></reference>
		</references>
		<description>CVE-2024-23945:Signing cookies is an application security feature that adds a digital signature to cookie data to verify its authenticity and integrity. The signature helps prevent malicious actors from modifying the cookie value, which can lead to security vulnerabilities and exploitation. Apache Hive’s service component accidentally exposes the signed cookie to the end user when there is a mismatch in signature between the current and expected cookie. Exposing the correct cookie signature can lead to further exploitation.&#xA;The vulnerable CookieSigner logic was introduced in Apache Hive by HIVE-9710 (1.2.0) and in Apache Spark by SPARK-14987 (2.0.0). The affected components are the following:&#xA;* org.apache.hive:hive-service&#xA;* org.apache.spark:spark-hive-thriftserver_2.11&#xA;* org.apache.spark:spark-hive-thriftserver_2.12</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="spark" release="1.u1.fos23" version="3.2.2">
					<filename>spark-3.2.2-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/spark-3.2.2-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="spark" release="1.u1.fos23" version="3.2.2">
					<filename>spark-3.2.2-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/spark-3.2.2-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2067</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45802" id="CVE-2024-45802" title="CVE-2024-45802" type="cve"></reference>
		</references>
		<description>CVE-2024-45802:Squid is an open source caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to Input Validation, Premature Release of Resource During Expected Lifetime, and Missing Release of Resource after Effective Lifetime bugs, Squid is vulnerable to Denial of Service attacks by a trusted server against all clients using the proxy. This bug is fixed in the default build configuration of Squid version 6.10.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="7" name="squid" release="27.u8.fos23" version="4.9">
					<filename>squid-4.9-27.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/squid-4.9-27.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="27.u8.fos23" version="4.9">
					<filename>squid-4.9-27.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/squid-4.9-27.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2068</id>
		<title>An update for subversion is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45720" id="CVE-2024-45720" title="CVE-2024-45720" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46901" id="CVE-2024-46901" title="CVE-2024-46901" type="cve"></reference>
		</references>
		<description>CVE-2024-45720:On Windows platforms, a &#34;best fit&#34; character encoding conversion of command line arguments to Subversion&#39;s executables (e.g., svn.exe, etc.) may lead to unexpected command line argument interpretation, including argument injection and execution of other programs, if a specially crafted command line argument string is processed.&#xA;All versions of Subversion up to and including Subversion 1.14.3 are affected on Windows platforms only. Users are recommended to upgrade to version Subversion 1.14.4, which fixes this issue.&#xA;Subversion is not affected on UNIX-like platforms.&#xA;CVE-2024-46901:Insufficient validation of filenames against control characters in Apache Subversion repositories served via mod_dav_svn allows authenticated users with commit access to commit a corrupted revision, leading to disruption for users of the repository.&#xA;All versions of Subversion up to and including Subversion 1.14.4 are affected if serving repositories via mod_dav_svn. Users are recommended to upgrade to version 1.14.5, which fixes this issue.&#xA;Repositories served via other access methods are not affected.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="subversion" release="5.u4.fos23" version="1.14.2">
					<filename>subversion-1.14.2-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/subversion-1.14.2-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="subversion-devel" release="5.u4.fos23" version="1.14.2">
					<filename>subversion-devel-1.14.2-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/subversion-devel-1.14.2-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="subversion-help" release="5.u4.fos23" version="1.14.2">
					<filename>subversion-help-1.14.2-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/subversion-help-1.14.2-5.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-subversion" release="5.u4.fos23" version="1.14.2">
					<filename>python3-subversion-1.14.2-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/python3-subversion-1.14.2-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perl-subversion" release="5.u4.fos23" version="1.14.2">
					<filename>perl-subversion-1.14.2-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/perl-subversion-1.14.2-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-subversion" release="5.u4.fos23" version="1.14.2">
					<filename>ruby-subversion-1.14.2-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/ruby-subversion-1.14.2-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="subversion" release="5.u4.fos23" version="1.14.2">
					<filename>subversion-1.14.2-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/subversion-1.14.2-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="subversion-devel" release="5.u4.fos23" version="1.14.2">
					<filename>subversion-devel-1.14.2-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/subversion-devel-1.14.2-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-subversion" release="5.u4.fos23" version="1.14.2">
					<filename>python3-subversion-1.14.2-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/python3-subversion-1.14.2-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perl-subversion" release="5.u4.fos23" version="1.14.2">
					<filename>perl-subversion-1.14.2-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/perl-subversion-1.14.2-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-subversion" release="5.u4.fos23" version="1.14.2">
					<filename>ruby-subversion-1.14.2-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/ruby-subversion-1.14.2-5.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2069</id>
		<title>An update for syslinux is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-2501" id="CVE-2011-2501" title="CVE-2011-2501" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-2690" id="CVE-2011-2690" title="CVE-2011-2690" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-2691" id="CVE-2011-2691" title="CVE-2011-2691" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-2692" id="CVE-2011-2692" title="CVE-2011-2692" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-3045" id="CVE-2011-3045" title="CVE-2011-3045" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-3048" id="CVE-2011-3048" title="CVE-2011-3048" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2012-3425" id="CVE-2012-3425" title="CVE-2012-3425" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2015-7981" id="CVE-2015-7981" title="CVE-2015-7981" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2015-8126" id="CVE-2015-8126" title="CVE-2015-8126" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2015-8472" id="CVE-2015-8472" title="CVE-2015-8472" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2015-8540" id="CVE-2015-8540" title="CVE-2015-8540" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2016-10087" id="CVE-2016-10087" title="CVE-2016-10087" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2017-12652" id="CVE-2017-12652" title="CVE-2017-12652" type="cve"></reference>
		</references>
		<description>CVE-2011-2501:The png_format_buffer function in pngerror.c in libpng 1.0.x before 1.0.55, 1.2.x before 1.2.45, 1.4.x before 1.4.8, and 1.5.x before 1.5.4 allows remote attackers to cause a denial of service (application crash) via a crafted PNG image that triggers an out-of-bounds read during the copying of error-message data.  NOTE: this vulnerability exists because of a CVE-2004-0421 regression. NOTE: this is called an off-by-one error by some sources.&#xA;CVE-2011-2690:Buffer overflow in libpng 1.0.x before 1.0.55, 1.2.x before 1.2.45, 1.4.x before 1.4.8, and 1.5.x before 1.5.4, when used by an application that calls the png_rgb_to_gray function but not the png_set_expand function, allows remote attackers to overwrite memory with an arbitrary amount of data, and possibly have unspecified other impact, via a crafted PNG image.&#xA;CVE-2011-2691:The png_err function in pngerror.c in libpng 1.0.x before 1.0.55, 1.2.x before 1.2.45, 1.4.x before 1.4.8, and 1.5.x before 1.5.4 makes a function call using a NULL pointer argument instead of an empty-string argument, which allows remote attackers to cause a denial of service (application crash) via a crafted PNG image.&#xA;CVE-2011-2692:The png_handle_sCAL function in pngrutil.c in libpng 1.0.x before 1.0.55, 1.2.x before 1.2.45, 1.4.x before 1.4.8, and 1.5.x before 1.5.4 does not properly handle invalid sCAL chunks, which allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via a crafted PNG image that triggers the reading of uninitialized memory.&#xA;CVE-2011-3045:Integer signedness error in the png_inflate function in pngrutil.c in libpng before 1.4.10beta01, as used in Google Chrome before 17.0.963.83 and other products, allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted PNG file, a different vulnerability than CVE-2011-3026.&#xA;CVE-2011-3048:The png_set_text_2 function in pngset.c in libpng 1.0.x before 1.0.59, 1.2.x before 1.2.49, 1.4.x before 1.4.11, and 1.5.x before 1.5.10 allows remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted text chunk in a PNG image file, which triggers a memory allocation failure that is not properly handled, leading to a heap-based buffer overflow.&#xA;CVE-2012-3425:The png_push_read_zTXt function in pngpread.c in libpng 1.0.x before 1.0.58, 1.2.x before 1.2.48, 1.4.x before 1.4.10, and 1.5.x before 1.5.10 allows remote attackers to cause a denial of service (out-of-bounds read) via a large avail_in field value in a PNG image.&#xA;CVE-2015-7981:The png_convert_to_rfc1123 function in png.c in libpng 1.0.x before 1.0.64, 1.2.x before 1.2.54, and 1.4.x before 1.4.17 allows remote attackers to obtain sensitive process memory information via crafted tIME chunk data in an image file, which triggers an out-of-bounds read.&#xA;CVE-2015-8126:Multiple buffer overflows in the (1) png_set_PLTE and (2) png_get_PLTE functions in libpng before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19 allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a small bit-depth value in an IHDR (aka image header) chunk in a PNG image.&#xA;CVE-2015-8472:Buffer overflow in the png_set_PLTE function in libpng before 1.0.65, 1.1.x and 1.2.x before 1.2.55, 1.3.x, 1.4.x before 1.4.18, 1.5.x before 1.5.25, and 1.6.x before 1.6.20 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a small bit-depth value in an IHDR (aka image header) chunk in a PNG image.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-8126.&#xA;CVE-2015-8540:Integer underflow in the png_check_keyword function in pngwutil.c in libpng 0.90 through 0.99, 1.0.x before 1.0.66, 1.1.x and 1.2.x before 1.2.56, 1.3.x and 1.4.x before 1.4.19, and 1.5.x before 1.5.26 allows remote attackers to have unspecified impact via a space character as a keyword in a PNG image, which triggers an out-of-bounds read.&#xA;CVE-2016-10087:The png_set_text_2 function in libpng 0.71 before 1.0.67, 1.2.x before 1.2.57, 1.4.x before 1.4.20, 1.5.x before 1.5.28, and 1.6.x before 1.6.27 allows context-dependent attackers to cause a NULL pointer dereference vectors involving loading a text chunk into a png structure, removing the text, and then adding another text chunk to the structure.&#xA;CVE-2017-12652:libpng before 1.6.32 does not properly check the length of chunks against the user limit.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="syslinux" release="16.u3.fos23" version="6.04">
					<filename>syslinux-6.04-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-6.04-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-perl" release="16.u3.fos23" version="6.04">
					<filename>syslinux-perl-6.04-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-perl-6.04-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-devel" release="16.u3.fos23" version="6.04">
					<filename>syslinux-devel-6.04-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-devel-6.04-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-extlinux" release="16.u3.fos23" version="6.04">
					<filename>syslinux-extlinux-6.04-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-extlinux-6.04-16.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-tftpboot" release="16.u3.fos23" version="6.04">
					<filename>syslinux-tftpboot-6.04-16.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-tftpboot-6.04-16.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-extlinux-nonlinux" release="16.u3.fos23" version="6.04">
					<filename>syslinux-extlinux-nonlinux-6.04-16.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-extlinux-nonlinux-6.04-16.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-nonlinux" release="16.u3.fos23" version="6.04">
					<filename>syslinux-nonlinux-6.04-16.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-nonlinux-6.04-16.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-efi64" release="16.u3.fos23" version="6.04">
					<filename>syslinux-efi64-6.04-16.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/syslinux-efi64-6.04-16.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2070</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-25762" id="CVE-2022-25762" title="CVE-2022-25762" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-43980" id="CVE-2021-43980" title="CVE-2021-43980" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-46589" id="CVE-2023-46589" title="CVE-2023-46589" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23672" id="CVE-2024-23672" title="CVE-2024-23672" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24549" id="CVE-2024-24549" title="CVE-2024-24549" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-34750" id="CVE-2024-34750" title="CVE-2024-34750" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52318" id="CVE-2024-52318" title="CVE-2024-52318" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52317" id="CVE-2024-52317" title="CVE-2024-52317" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52316" id="CVE-2024-52316" title="CVE-2024-52316" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50379" id="CVE-2024-50379" title="CVE-2024-50379" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-54677" id="CVE-2024-54677" title="CVE-2024-54677" type="cve"></reference>
		</references>
		<description>CVE-2022-25762:If a web application sends a WebSocket message concurrently with the WebSocket connection closing when running on Apache Tomcat 8.5.0 to 8.5.75 or Apache Tomcat 9.0.0.M1 to 9.0.20, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors.&#xA;CVE-2021-43980:The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug in Apache Tomcat 10.1.0 to 10.1.0-M12, 10.0.0-M1 to 10.0.18, 9.0.0-M1 to 9.0.60 and 8.5.0 to 8.5.77 that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.&#xA;CVE-2023-44487:The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.&#xA;CVE-2023-46589:Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82 and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single &#xA;request as multiple requests leading to the possibility of request &#xA;smuggling when behind a reverse proxy.&#xA;Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue.&#xA;CVE-2024-23672:Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.&#xA;Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.&#xA;CVE-2024-24549:Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.&#xA;Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.&#xA;CVE-2024-34750:Improper Handling of Exceptional Conditions, Uncontrolled Resource Consumption vulnerability in Apache Tomcat. When processing an HTTP/2 stream, Tomcat did not handle some cases of excessive HTTP headers correctly. This led to a miscounting of active HTTP/2 streams which in turn led to the use of an incorrect infinite timeout which allowed connections to remain open which should have been closed.&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.0-M1 through 9.0.89.&#xA;Users are recommended to upgrade to version 11.0.0-M21, 10.1.25 or 9.0.90, which fixes the issue.&#xA;CVE-2024-52318:Incorrect object recycling and reuse vulnerability in Apache Tomcat.&#xA;This issue affects Apache Tomcat: 11.0.0, 10.1.31, 9.0.96.&#xA;Users are recommended to upgrade to version 11.0.1, 10.1.32 or 9.0.97, which fixes the issue.&#xA;CVE-2024-52317:Incorrect object re-cycling and re-use vulnerability in Apache Tomcat. Incorrect recycling of the request and response used by HTTP/2 requests &#xA;could lead to request and/or response mix-up between users.&#xA;This issue affects Apache Tomcat: from 11.0.0-M23 through 11.0.0-M26, from 10.1.27 through 10.1.30, from 9.0.92 through 9.0.95.&#xA;Users are recommended to upgrade to version 11.0.0, 10.1.31 or 9.0.96, which fixes the issue.&#xA;CVE-2024-52316:Unchecked Error Condition vulnerability in Apache Tomcat. If Tomcat is configured to use a custom Jakarta Authentication (formerly JASPIC) ServerAuthContext component which may throw an exception during the authentication process without explicitly setting an HTTP status to indicate failure, the authentication may not fail, allowing the user to bypass the authentication process. There are no known Jakarta Authentication components that behave in this way.&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M26, from 10.1.0-M1 through 10.1.30, from 9.0.0-M1 through 9.0.95.&#xA;Users are recommended to upgrade to version 11.0.0, 10.1.31 or 9.0.96, which fix the issue.&#xA;CVE-2024-50379:Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability during JSP compilation in Apache Tomcat permits an RCE on case insensitive file systems when the default servlet is enabled for write (non-default configuration).&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97.&#xA;Users are recommended to upgrade to version 11.0.2, 10.1.34 or 9.0.98, which fixes the issue.&#xA;CVE-2024-54677:Uncontrolled Resource Consumption vulnerability in the examples web application provided with Apache Tomcat leads to denial of service.&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.9.97.&#xA;Users are recommended to upgrade to version 11.0.2, 10.1.34 or 9.0.98, which fixes the issue.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="1" name="tomcat" release="4.u15.fos23" version="9.0.96">
					<filename>tomcat-9.0.96-4.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/tomcat-9.0.96-4.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="4.u15.fos23" version="9.0.96">
					<filename>tomcat-jsvc-9.0.96-4.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/tomcat-jsvc-9.0.96-4.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="4.u15.fos23" version="9.0.96">
					<filename>tomcat-help-9.0.96-4.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/tomcat-help-9.0.96-4.u15.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2071</id>
		<title>An update for undertow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-3690" id="CVE-2021-3690" title="CVE-2021-3690" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-1973" id="CVE-2023-1973" title="CVE-2023-1973" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5379" id="CVE-2023-5379" title="CVE-2023-5379" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4109" id="CVE-2024-4109" title="CVE-2024-4109" type="cve"></reference>
		</references>
		<description>CVE-2021-3690:A flaw was found in Undertow. A buffer leak on the incoming WebSocket PONG message may lead to memory exhaustion. This flaw allows an attacker to cause a denial of service. The highest threat from this vulnerability is availability.&#xA;CVE-2023-1973:A flaw was found in Undertow package. Using the FormAuthenticationMechanism, a malicious user could trigger a Denial of Service by sending crafted requests, leading the server to an OutofMemory error, exhausting the server&#39;s memory.&#xA;CVE-2023-5379:A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).&#xA;CVE-2024-4109:A flaw was found in Undertow. An HTTP request header value from a previous stream may be incorrectly reused for a request associated with a subsequent stream on the same HTTP/2 connection. This issue can potentially lead to information leakage between requests.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="1" name="undertow" release="8.u3.fos23" version="1.4.0">
					<filename>undertow-1.4.0-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/undertow-1.4.0-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="undertow-javadoc" release="8.u3.fos23" version="1.4.0">
					<filename>undertow-javadoc-1.4.0-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/undertow-javadoc-1.4.0-8.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2072</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41957" id="CVE-2024-41957" title="CVE-2024-41957" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41965" id="CVE-2024-41965" title="CVE-2024-41965" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43374" id="CVE-2024-43374" title="CVE-2024-43374" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43802" id="CVE-2024-43802" title="CVE-2024-43802" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47814" id="CVE-2024-47814" title="CVE-2024-47814" type="cve"></reference>
		</references>
		<description>CVE-2024-41957:Vim is an open source command line text editor. Vim &lt; v9.1.0647 has double free in src/alloc.c:616. When closing a window, the corresponding tagstack data will be cleared and freed. However a bit later, the quickfix list belonging to that window will also be cleared and if that quickfix list points to the same tagstack data, Vim will try to free it again, resulting in a double-free/use-after-free access exception. Impact is low since the user must intentionally execute vim with several non-default flags,&#xA;but it may cause a crash of Vim. The issue has been fixed as of Vim patch v9.1.0647&#xA;CVE-2024-41965:Vim is an open source command line text editor. double-free in dialog_changed() in Vim &lt; v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648.&#xA;CVE-2024-43374:The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.&#xA;CVE-2024-43802:Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters.  So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It&#39;s not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.&#xA;CVE-2024-47814:Vim is an open source, command line text editor. A use-after-free was found in Vim &lt; 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="2" name="vim-common" release="30.u17.fos23" version="9.0">
					<filename>vim-common-9.0-30.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vim-common-9.0-30.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="30.u17.fos23" version="9.0">
					<filename>vim-minimal-9.0-30.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vim-minimal-9.0-30.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="30.u17.fos23" version="9.0">
					<filename>vim-enhanced-9.0-30.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vim-enhanced-9.0-30.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="30.u17.fos23" version="9.0">
					<filename>vim-filesystem-9.0-30.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vim-filesystem-9.0-30.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="30.u17.fos23" version="9.0">
					<filename>vim-X11-9.0-30.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vim-X11-9.0-30.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="30.u17.fos23" version="9.0">
					<filename>vim-common-9.0-30.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/vim-common-9.0-30.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="30.u17.fos23" version="9.0">
					<filename>vim-minimal-9.0-30.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/vim-minimal-9.0-30.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="30.u17.fos23" version="9.0">
					<filename>vim-enhanced-9.0-30.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/vim-enhanced-9.0-30.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="30.u17.fos23" version="9.0">
					<filename>vim-X11-9.0-30.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/vim-X11-9.0-30.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2073</id>
		<title>An update for vorbis-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-43361" id="CVE-2023-43361" title="CVE-2023-43361" type="cve"></reference>
		</references>
		<description>CVE-2023-43361:Buffer Overflow vulnerability in Vorbis-tools v.1.4.2 allows a local attacker to execute arbitrary code and cause a denial of service during the conversion of wav files to ogg files.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="1" name="vorbis-tools" release="4.u1.fos23" version="1.4.2">
					<filename>vorbis-tools-1.4.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vorbis-tools-1.4.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="vorbis-tools-help" release="4.u1.fos23" version="1.4.2">
					<filename>vorbis-tools-help-1.4.2-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/vorbis-tools-help-1.4.2-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="vorbis-tools" release="4.u1.fos23" version="1.4.2">
					<filename>vorbis-tools-1.4.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/vorbis-tools-1.4.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2074</id>
		<title>An update for wavpack is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-2476" id="CVE-2022-2476" title="CVE-2022-2476" type="cve"></reference>
		</references>
		<description>CVE-2022-2476:A null pointer dereference bug was found in wavpack-5.4.0 The results from the ASAN log: AddressSanitizer:DEADLYSIGNAL ===================================================================84257==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0) ==84257==The signal is caused by a WRITE memory access. ==84257==Hint: address points to the zero page. #0 0x561b47a970c5 in main cli/wvunpack.c:834 #1 0x7efc4f5c0082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #2 0x561b47a945ed in _start (/usr/local/bin/wvunpack+0xa5ed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:834 in main ==84257==ABORTING</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="wavpack" release="3.u1.fos23" version="5.3.0">
					<filename>wavpack-5.3.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/wavpack-5.3.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="wavpack-devel" release="3.u1.fos23" version="5.3.0">
					<filename>wavpack-devel-5.3.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/wavpack-devel-5.3.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="wavpack-help" release="3.u1.fos23" version="5.3.0">
					<filename>wavpack-help-5.3.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/wavpack-help-5.3.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="wavpack" release="3.u1.fos23" version="5.3.0">
					<filename>wavpack-5.3.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/wavpack-5.3.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="wavpack-devel" release="3.u1.fos23" version="5.3.0">
					<filename>wavpack-devel-5.3.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/wavpack-devel-5.3.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2075</id>
		<title>An update for webkit2gtk3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4558" id="CVE-2024-4558" title="CVE-2024-4558" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40779" id="CVE-2024-40779" title="CVE-2024-40779" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40780" id="CVE-2024-40780" title="CVE-2024-40780" type="cve"></reference>
		</references>
		<description>CVE-2024-4558:Use after free in ANGLE in Google Chrome prior to 124.0.6367.155 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)&#xA;CVE-2024-40779:An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash.&#xA;CVE-2024-40780:An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="webkit2gtk3" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-2.36.3-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/webkit2gtk3-2.36.3-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-devel" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-devel-2.36.3-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/webkit2gtk3-devel-2.36.3-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-jsc" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-2.36.3-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/webkit2gtk3-jsc-2.36.3-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="webkit2gtk3-jsc-devel" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-devel-2.36.3-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/webkit2gtk3-jsc-devel-2.36.3-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-2.36.3-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/webkit2gtk3-2.36.3-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-devel" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-devel-2.36.3-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/webkit2gtk3-devel-2.36.3-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="webkit2gtk3-help" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-help-2.36.3-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/webkit2gtk3-help-2.36.3-7.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-jsc" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-2.36.3-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/webkit2gtk3-jsc-2.36.3-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="webkit2gtk3-jsc-devel" release="7.u3.fos23" version="2.36.3">
					<filename>webkit2gtk3-jsc-devel-2.36.3-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/webkit2gtk3-jsc-devel-2.36.3-7.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2076</id>
		<title>An update for wget is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10524" id="CVE-2024-10524" title="CVE-2024-10524" type="cve"></reference>
		</references>
		<description>CVE-2024-10524:Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="wget" release="5.u3.fos23" version="1.21.2">
					<filename>wget-1.21.2-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/wget-1.21.2-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="wget-help" release="5.u3.fos23" version="1.21.2">
					<filename>wget-help-1.21.2-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/wget-help-1.21.2-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="wget" release="5.u3.fos23" version="1.21.2">
					<filename>wget-1.21.2-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/wget-1.21.2-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="wget-help" release="5.u3.fos23" version="1.21.2">
					<filename>wget-help-1.21.2-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/wget-help-1.21.2-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2077</id>
		<title>An update for xnio is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5685" id="CVE-2023-5685" title="CVE-2023-5685" type="cve"></reference>
		</references>
		<description>CVE-2023-5685:A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS).</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="xnio" release="11.u1.fos23" version="3.4.0">
					<filename>xnio-3.4.0-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xnio-3.4.0-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xnio-help" release="11.u1.fos23" version="3.4.0">
					<filename>xnio-help-3.4.0-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xnio-help-3.4.0-11.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2078</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9632" id="CVE-2024-9632" title="CVE-2024-9632" type="cve"></reference>
		</references>
		<description>CVE-2023-5574:A use-after-free flaw was found in xorg-x11-server-Xvfb. This issue occurs in Xvfb with a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode). If the pointer is warped from a screen 1 to a screen 0, a use-after-free issue may be triggered during shutdown or reset of the Xvfb server, allowing for possible escalation of privileges or denial of service.&#xA;CVE-2024-9632:A flaw was found in the X.org server. Due to improperly tracked allocation size in _XkbSetCompatMap, a local attacker may be able to trigger a buffer overflow condition via a specially crafted payload, leading to denial of service or local privilege escalation in distributions where the X.org server is run with root privileges.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-common-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-Xnest-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-Xdmx-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-Xvfb-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-Xephyr-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-34.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-devel-1.20.11-34.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-34.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-help-1.20.11-34.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-34.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xorg-x11-server-source-1.20.11-34.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-common-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-Xnest-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-Xdmx-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-Xvfb-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-Xephyr-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="34.u19.fos23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-34.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/xorg-x11-server-devel-1.20.11-34.u19.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2079</id>
		<title>An update for xstream is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47072" id="CVE-2024-47072" title="CVE-2024-47072" type="cve"></reference>
		</references>
		<description>CVE-2024-47072:XStream is a simple library to serialize objects to XML and back again. This vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream when XStream is configured to use the BinaryStreamDriver. XStream 1.4.21 has been patched to detect the manipulation in the binary input stream causing the the stack overflow and raises an InputManipulationException instead. Users are advised to upgrade. Users unable to upgrade may catch the StackOverflowError in the client code calling XStream if XStream is configured to use the BinaryStreamDriver.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="noarch" epoch="0" name="xstream" release="2.u4.fos23" version="1.4.20">
					<filename>xstream-1.4.20-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xstream-1.4.20-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-javadoc" release="2.u4.fos23" version="1.4.20">
					<filename>xstream-javadoc-1.4.20-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xstream-javadoc-1.4.20-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-hibernate" release="2.u4.fos23" version="1.4.20">
					<filename>xstream-hibernate-1.4.20-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xstream-hibernate-1.4.20-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-benchmark" release="2.u4.fos23" version="1.4.20">
					<filename>xstream-benchmark-1.4.20-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xstream-benchmark-1.4.20-2.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xstream-parent" release="2.u4.fos23" version="1.4.20">
					<filename>xstream-parent-1.4.20-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/xstream-parent-1.4.20-2.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2080</id>
		<title>An update for zziplib is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-18770" id="CVE-2020-18770" title="CVE-2020-18770" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39134" id="CVE-2024-39134" title="CVE-2024-39134" type="cve"></reference>
		</references>
		<description>CVE-2020-18770:An issue was discovered in function zzip_disk_entry_to_file_header in mmapped.c in zziplib 0.13.69, which will lead to a denial-of-service.&#xA;CVE-2024-39134:A Stack Buffer Overflow vulnerability in zziplibv 0.13.77 allows attackers to cause a denial of service via the __zzip_fetch_disk_trailer() function at /zzip/zip.c.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="zziplib" release="7.u2.fos23" version="0.13.71">
					<filename>zziplib-0.13.71-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/zziplib-0.13.71-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="zziplib-devel" release="7.u2.fos23" version="0.13.71">
					<filename>zziplib-devel-0.13.71-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/zziplib-devel-0.13.71-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="zziplib-help" release="7.u2.fos23" version="0.13.71">
					<filename>zziplib-help-0.13.71-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/zziplib-help-0.13.71-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zziplib" release="7.u2.fos23" version="0.13.71">
					<filename>zziplib-0.13.71-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/zziplib-0.13.71-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zziplib-devel" release="7.u2.fos23" version="0.13.71">
					<filename>zziplib-devel-0.13.71-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/zziplib-devel-0.13.71-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2081</id>
		<title>An update for rsync is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-01-15"></issued>
		<references>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12085" id="CVE-2024-12085" title="CVE-2024-12085" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12086" id="CVE-2024-12086" title="CVE-2024-12086" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12087" id="CVE-2024-12087" title="CVE-2024-12087" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12088" id="CVE-2024-12088" title="CVE-2024-12088" type="cve"></reference>
			<reference href="https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12747" id="CVE-2024-12747" title="CVE-2024-12747" type="cve"></reference>
		</references>
		<description>CVE-2024-12085:A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.&#xA;CVE-2024-12086:A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client&#39;s machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.&#xA;CVE-2024-12087:A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client&#39;s intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.&#xA;CVE-2024-12088:A flaw was found in rsync. When using the `--safe-links` option, rsync fails to properly verify if a symbolic link destination contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.&#xA;CVE-2024-12747:A flaw was found in rsync. This vulnerability arises from a race condition during rsync&#39;s handling of symbolic links. Rsync&#39;s default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.</description>
		<pkglist>
			<collection>
				<name>23.1.4</name>
				<package arch="x86_64" epoch="0" name="rsync" release="4.u3.fos23" version="3.2.5">
					<filename>rsync-3.2.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rsync-3.2.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rsync-help" release="4.u3.fos23" version="3.2.5">
					<filename>rsync-help-3.2.5-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4/rsync-help-3.2.5-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rsync" release="4.u3.fos23" version="3.2.5">
					<filename>rsync-3.2.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4/rsync-3.2.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2082</id>
		<title>An update for curl is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0167&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0167" id="CVE-2025-0167" title="CVE-2025-0167" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0725&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0725" id="CVE-2025-0725" title="CVE-2025-0725" type="cve"></reference>
		</references>
		<description>CVE-2025-0167:When asked to use a `.netrc` file for credentials **and** to follow HTTP&#xA;redirects, curl could leak the password used for the first host to the&#xA;followed-to host under certain circumstances.&#xA;&#xA;This flaw only manifests itself if the netrc file has a `default` entry that&#xA;omits both login and password. A rare circumstance.&#xA;CVE-2025-0725:When libcurl is asked to perform automatic gzip decompression of&#xA;content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,&#xA;**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would&#xA;make libcurl perform a buffer overflow.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="curl" release="37.u22" version="7.79.1">
					<filename>curl-7.79.1-37.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/curl-7.79.1-37.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="37.u22" version="7.79.1">
					<filename>libcurl-7.79.1-37.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libcurl-7.79.1-37.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="37.u22" version="7.79.1">
					<filename>libcurl-devel-7.79.1-37.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libcurl-devel-7.79.1-37.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="37.u22" version="7.79.1">
					<filename>curl-help-7.79.1-37.u22.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/curl-help-7.79.1-37.u22.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="curl" release="37.u22" version="7.79.1">
					<filename>curl-7.79.1-37.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/curl-7.79.1-37.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="37.u22" version="7.79.1">
					<filename>libcurl-devel-7.79.1-37.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libcurl-devel-7.79.1-37.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="37.u22" version="7.79.1">
					<filename>libcurl-7.79.1-37.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libcurl-7.79.1-37.u22.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2083</id>
		<title>An update for redis6 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46981&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46981" id="CVE-2024-46981" title="CVE-2024-46981" type="cve"></reference>
		</references>
		<description>CVE-2024-46981:Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to manipulate the garbage collector and potentially lead to remote code execution. The problem is fixed in 7.4.2, 7.2.7, and 6.2.17. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u9" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/redis6-doc-6.2.7-3.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u9" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/redis6-devel-6.2.7-3.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u9" version="6.2.7">
					<filename>redis6-6.2.7-3.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/redis6-6.2.7-3.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u9" version="6.2.7">
					<filename>redis6-6.2.7-3.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/redis6-6.2.7-3.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u9" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/redis6-devel-6.2.7-3.u9.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2084</id>
		<title>An update for binutils is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57630&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57630" id="CVE-2024-57630" title="CVE-2024-57630" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0840&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0840" id="CVE-2025-0840" title="CVE-2025-0840" type="cve"></reference>
		</references>
		<description>CVE-2024-57630:An issue in the exps_card component of MonetDB Server v11.49.1 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.&#xA;CVE-2025-0840:A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="binutils-help" release="26.u14" version="2.37">
					<filename>binutils-help-2.37-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/binutils-help-2.37-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils" release="26.u14" version="2.37">
					<filename>binutils-2.37-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/binutils-2.37-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="26.u14" version="2.37">
					<filename>binutils-devel-2.37-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/binutils-devel-2.37-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="26.u14" version="2.37">
					<filename>binutils-2.37-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/binutils-2.37-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="26.u14" version="2.37">
					<filename>binutils-help-2.37-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/binutils-help-2.37-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="26.u14" version="2.37">
					<filename>binutils-devel-2.37-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/binutils-devel-2.37-26.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2085</id>
		<title>An update for ffmpeg is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36613&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36613" id="CVE-2024-36613" title="CVE-2024-36613" type="cve"></reference>
		</references>
		<description>CVE-2024-36613:FFmpeg n6.1.1 has a vulnerability in the DXA demuxer of the libavformat library allowing for an integer overflow, potentially resulting in a denial-of-service (DoS) condition or other undefined behavior.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="libavdevice" release="22.u6" version="4.2.4">
					<filename>libavdevice-4.2.4-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libavdevice-4.2.4-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="22.u6" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ffmpeg-devel-4.2.4-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="22.u6" version="4.2.4">
					<filename>ffmpeg-4.2.4-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ffmpeg-4.2.4-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="22.u6" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-22.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ffmpeg-libs-4.2.4-22.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="22.u6" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/ffmpeg-libs-4.2.4-22.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="22.u6" version="4.2.4">
					<filename>libavdevice-4.2.4-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libavdevice-4.2.4-22.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="22.u6" version="4.2.4">
					<filename>ffmpeg-4.2.4-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/ffmpeg-4.2.4-22.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="22.u6" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-22.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/ffmpeg-devel-4.2.4-22.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2086</id>
		<title>An update for erlang is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26618&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26618" id="CVE-2025-26618" title="CVE-2025-26618" type="cve"></reference>
		</references>
		<description>CVE-2025-26618:Erlang is a programming language and runtime system for building massively scalable soft real-time systems with requirements on high availability. OTP is a set of Erlang libraries, which consists of the Erlang runtime system, a number of ready-to-use components mainly written in Erlang. Packet size is not verified properly for SFTP packets. As a result when multiple SSH packets (conforming to max SSH packet size) are received by ssh, they might be combined into an SFTP packet which will exceed the max allowed packet size and potentially cause large amount of memory to be allocated. Note that situation described above can only happen for successfully authenticated users after completing the SSH handshake. This issue has been patched in OTP versions 27.2.4, 26.2.5.9, and 25.3.2.18. There are no known workarounds for this vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="erlang-debugger" release="5.u3" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-debugger-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eldap" release="5.u3" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-eldap-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-public_key" release="5.u3" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-public_key-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-odbc" release="5.u3" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-odbc-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssl" release="5.u3" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-ssl-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-diameter" release="5.u3" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-diameter-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-sasl" release="5.u3" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-sasl-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-xmerl" release="5.u3" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-xmerl-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-compiler" release="5.u3" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-compiler-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_docgen" release="5.u3" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-erl_docgen-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-observer" release="5.u3" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-observer-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-reltool" release="5.u3" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-reltool-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-os_mon" release="5.u3" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-os_mon-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-syntax_tools" release="5.u3" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-syntax_tools-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-asn1" release="5.u3" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-asn1-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-dialyzer" release="5.u3" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-dialyzer-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-edoc" release="5.u3" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-edoc-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ftp" release="5.u3" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-ftp-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-common_test" release="5.u3" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-common_test-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-jinterface" release="5.u3" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-jinterface-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-hipe" release="5.u3" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-hipe-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-megaco" release="5.u3" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-megaco-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-wx" release="5.u3" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-wx-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssh" release="5.u3" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-ssh-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-crypto" release="5.u3" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-crypto-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-snmp" release="5.u3" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-snmp-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-parsetools" release="5.u3" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-parsetools-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang" release="5.u3" version="23.3.4.9">
					<filename>erlang-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_interface" release="5.u3" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-erl_interface-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-mnesia" release="5.u3" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-mnesia-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-runtime_tools" release="5.u3" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-runtime_tools-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-examples" release="5.u3" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-examples-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eunit" release="5.u3" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-eunit-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-kernel" release="5.u3" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-kernel-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erts" release="5.u3" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-erts-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-inets" release="5.u3" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-inets-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-et" release="5.u3" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-et-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-stdlib" release="5.u3" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-stdlib-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tftp" release="5.u3" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-tftp-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tools" release="5.u3" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/erlang-tools-23.3.4.9-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-compiler" release="5.u3" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-compiler-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-jinterface" release="5.u3" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-jinterface-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-sasl" release="5.u3" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-sasl-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-hipe" release="5.u3" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-hipe-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-syntax_tools" release="5.u3" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-syntax_tools-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-xmerl" release="5.u3" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-xmerl-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-diameter" release="5.u3" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-diameter-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-mnesia" release="5.u3" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-mnesia-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-dialyzer" release="5.u3" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-dialyzer-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-inets" release="5.u3" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-inets-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eunit" release="5.u3" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-eunit-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-public_key" release="5.u3" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-public_key-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssl" release="5.u3" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-ssl-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssh" release="5.u3" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-ssh-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-runtime_tools" release="5.u3" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-runtime_tools-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-examples" release="5.u3" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-examples-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_interface" release="5.u3" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-erl_interface-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-et" release="5.u3" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-et-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tftp" release="5.u3" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-tftp-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-reltool" release="5.u3" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-reltool-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-snmp" release="5.u3" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-snmp-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ftp" release="5.u3" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-ftp-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-crypto" release="5.u3" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-crypto-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erts" release="5.u3" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-erts-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-observer" release="5.u3" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-observer-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-parsetools" release="5.u3" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-parsetools-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-wx" release="5.u3" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-wx-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_docgen" release="5.u3" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-erl_docgen-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-os_mon" release="5.u3" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-os_mon-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-kernel" release="5.u3" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-kernel-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-odbc" release="5.u3" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-odbc-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-stdlib" release="5.u3" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-stdlib-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tools" release="5.u3" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-tools-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang" release="5.u3" version="23.3.4.9">
					<filename>erlang-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-megaco" release="5.u3" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-megaco-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-asn1" release="5.u3" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-asn1-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-debugger" release="5.u3" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-debugger-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eldap" release="5.u3" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-eldap-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-common_test" release="5.u3" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-common_test-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-edoc" release="5.u3" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/erlang-edoc-23.3.4.9-5.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2087</id>
		<title>An update for libxml2 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56171" id="CVE-2024-56171" title="CVE-2024-56171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24928&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-24928" id="CVE-2025-24928" title="CVE-2025-24928" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27113&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27113" id="CVE-2025-27113" title="CVE-2025-27113" type="cve"></reference>
		</references>
		<description>CVE-2024-56171:libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.&#xA;CVE-2025-24928:libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047.&#xA;CVE-2025-27113:libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a NULL pointer dereference in xmlPatMatch in pattern.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="15.u10" version="2.9.14">
					<filename>libxml2-devel-2.9.14-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libxml2-devel-2.9.14-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="15.u10" version="2.9.14">
					<filename>libxml2-2.9.14-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libxml2-2.9.14-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="15.u10" version="2.9.14">
					<filename>python3-libxml2-2.9.14-15.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-libxml2-2.9.14-15.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="15.u10" version="2.9.14">
					<filename>libxml2-devel-2.9.14-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libxml2-devel-2.9.14-15.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="15.u10" version="2.9.14">
					<filename>libxml2-2.9.14-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libxml2-2.9.14-15.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="15.u10" version="2.9.14">
					<filename>python3-libxml2-2.9.14-15.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/python3-libxml2-2.9.14-15.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="15.u10" version="2.9.14">
					<filename>libxml2-help-2.9.14-15.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libxml2-help-2.9.14-15.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2088</id>
		<title>An update for python3 is now available for 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11168" id="CVE-2024-11168" title="CVE-2024-11168" type="cve"></reference>
		</references>
		<description>CVE-2024-11168:The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren&#39;t IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="37.u19" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-37.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/python3-unversioned-command-3.9.9-37.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="37.u19" version="3.9.9">
					<filename>python3-debug-3.9.9-37.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/python3-debug-3.9.9-37.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="37.u19" version="3.9.9">
					<filename>python3-3.9.9-37.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/python3-3.9.9-37.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="37.u19" version="3.9.9">
					<filename>python3-devel-3.9.9-37.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/python3-devel-3.9.9-37.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3" release="37.u19" version="3.9.9">
					<filename>python3-3.9.9-37.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-3.9.9-37.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="37.u19" version="3.9.9">
					<filename>python3-devel-3.9.9-37.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-devel-3.9.9-37.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="37.u19" version="3.9.9">
					<filename>python3-debug-3.9.9-37.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-debug-3.9.9-37.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="37.u19" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-37.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-unversioned-command-3.9.9-37.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="37.u19" version="3.9.9">
					<filename>python3-help-3.9.9-37.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-help-3.9.9-37.u19.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2089</id>
		<title>An update for qt5-qtconnectivity is now available for 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23050" id="CVE-2025-23050" title="CVE-2025-23050" type="cve"></reference>
		</references>
		<description>CVE-2025-23050:QLowEnergyController on Linux has a BlueZ DBus and a Bluetooth Kernel API backend. When using the Bluetooth Kernel API backend of QLowEnergyController, QtBluetooth creates a Bluetooth L2CAP socket to establish a connection with an external Bluetooth Low Energy device. After that, the external device can send malformed Bluetooth ATT commands to trigger read past the end of the buffer and division by zero errors. The problem is relevant for both central and peripheral roles.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="qt5-qtconnectivity-devel" release="2.u2" version="5.15.2">
					<filename>qt5-qtconnectivity-devel-5.15.2-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/qt5-qtconnectivity-devel-5.15.2-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtconnectivity" release="2.u2" version="5.15.2">
					<filename>qt5-qtconnectivity-5.15.2-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/qt5-qtconnectivity-5.15.2-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtconnectivity-help" release="2.u2" version="5.15.2">
					<filename>qt5-qtconnectivity-help-5.15.2-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/qt5-qtconnectivity-help-5.15.2-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtconnectivity" release="2.u2" version="5.15.2">
					<filename>qt5-qtconnectivity-5.15.2-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/qt5-qtconnectivity-5.15.2-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtconnectivity-devel" release="2.u2" version="5.15.2">
					<filename>qt5-qtconnectivity-devel-5.15.2-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/qt5-qtconnectivity-devel-5.15.2-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtconnectivity-help" release="2.u2" version="5.15.2">
					<filename>qt5-qtconnectivity-help-5.15.2-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/qt5-qtconnectivity-help-5.15.2-2.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2090</id>
		<title>An update for openjpeg2 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3575&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-3575" id="CVE-2021-3575" title="CVE-2021-3575" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56826&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56826" id="CVE-2024-56826" title="CVE-2024-56826" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56827&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56827" id="CVE-2024-56827" title="CVE-2024-56827" type="cve"></reference>
		</references>
		<description>CVE-2021-3575:A heap-based buffer overflow was found in openjpeg in color.c:379:42 in sycc420_to_rgb when decompressing a crafted .j2k file. An attacker could use this to execute arbitrary code with the permissions of the application compiled against openjpeg.&#xA;CVE-2024-56826:A flaw was found in the OpenJPEG project. A heap buffer overflow condition may be triggered when certain options are specified while using the opj_decompress utility.  This can lead to an application crash or other undefined behavior.&#xA;CVE-2024-56827:A flaw was found in the OpenJPEG project. A heap buffer overflow condition may be triggered when certain options are specified while using the opj_decompress utility.  This can lead to an application crash or other undefined behavior.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="openjpeg2-devel" release="6.u3" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/openjpeg2-devel-2.5.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2" release="6.u3" version="2.5.0">
					<filename>openjpeg2-2.5.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/openjpeg2-2.5.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2-tools" release="6.u3" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/openjpeg2-tools-2.5.0-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openjpeg2-help" release="6.u3" version="2.5.0">
					<filename>openjpeg2-help-2.5.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/openjpeg2-help-2.5.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-devel" release="6.u3" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/openjpeg2-devel-2.5.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-tools" release="6.u3" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/openjpeg2-tools-2.5.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2" release="6.u3" version="2.5.0">
					<filename>openjpeg2-2.5.0-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/openjpeg2-2.5.0-6.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2091</id>
		<title>An update for ruby is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27219&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27219" id="CVE-2025-27219" title="CVE-2025-27219" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27220&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27220" id="CVE-2025-27220" title="CVE-2025-27220" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27221&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27221" id="CVE-2025-27221" title="CVE-2025-27221" type="cve"></reference>
		</references>
		<description>CVE-2025-27219:In the CGI gem before 0.4.2 for Ruby, the CGI::Cookie.parse method in the CGI library contains a potential Denial of Service (DoS) vulnerability. The method does not impose any limit on the length of the raw cookie value it processes. This oversight can lead to excessive resource consumption when parsing extremely large cookies.&#xA;CVE-2025-27220:In the CGI gem before 0.4.2 for Ruby, a Regular Expression Denial of Service (ReDoS) vulnerability exists in the Util#escapeElement method.&#xA;CVE-2025-27221:In the URI gem before 1.0.3 for Ruby, the URI handling methods (URI.join, URI#merge, URI#+) have an inadvertent leakage of authentication credentials because userinfo is retained even after changing the host.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="142.u16" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/rubygem-bigdecimal-3.0.0-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="142.u16" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/rubygem-openssl-2.2.1-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="142.u16" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/rubygem-io-console-0.5.7-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="142.u16" version="3.0.3">
					<filename>ruby-3.0.3-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/ruby-3.0.3-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="142.u16" version="3.0.3">
					<filename>ruby-devel-3.0.3-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/ruby-devel-3.0.3-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="142.u16" version="2.5.1">
					<filename>rubygem-json-2.5.1-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/rubygem-json-2.5.1-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="142.u16" version="3.3.2">
					<filename>rubygem-psych-3.3.2-142.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/rubygem-psych-3.3.2-142.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="142.u16" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-did_you_mean-1.5.0-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="142.u16" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-typeprof-0.15.2-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="142.u16" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rdoc-6.3.3-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="142.u16" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-test-unit-3.3.7-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="142.u16" version="3.2.32">
					<filename>rubygems-3.2.32-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygems-3.2.32-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="142.u16" version="13.0.3">
					<filename>rubygem-rake-13.0.3-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rake-13.0.3-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="142.u16" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rexml-3.2.5-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="142.u16" version="3.2.32">
					<filename>rubygems-devel-3.2.32-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygems-devel-3.2.32-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="142.u16" version="3.0.3">
					<filename>ruby-irb-3.0.3-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ruby-irb-3.0.3-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="142.u16" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rbs-1.4.0-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="142.u16" version="0.2.9">
					<filename>rubygem-rss-0.2.9-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rss-0.2.9-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="142.u16" version="3.0.3">
					<filename>ruby-help-3.0.3-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ruby-help-3.0.3-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="142.u16" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-142.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-minitest-5.14.2-142.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby" release="142.u16" version="3.0.3">
					<filename>ruby-3.0.3-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ruby-3.0.3-142.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="142.u16" version="3.3.2">
					<filename>rubygem-psych-3.3.2-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-psych-3.3.2-142.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="142.u16" version="2.5.1">
					<filename>rubygem-json-2.5.1-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-json-2.5.1-142.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="142.u16" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-openssl-2.2.1-142.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="142.u16" version="3.0.3">
					<filename>ruby-devel-3.0.3-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ruby-devel-3.0.3-142.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="142.u16" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-bigdecimal-3.0.0-142.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="142.u16" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-142.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-io-console-0.5.7-142.u16.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2092</id>
		<title>An update for three-eight-nine-ds-base is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8445&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8445" id="CVE-2024-8445" title="CVE-2024-8445" type="cve"></reference>
		</references>
		<description>CVE-2024-8445:The fix for CVE-2024-2199 in 389-ds-base was insufficient to cover all scenarios. In certain product versions, an authenticated user may cause a server crash while modifying `userPassword` using malformed input.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="389-ds-base-help" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/389-ds-base-help-1.4.3.36-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-legacy-tools" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/389-ds-base-legacy-tools-1.4.3.36-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/389-ds-base-1.4.3.36-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-snmp" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/389-ds-base-snmp-1.4.3.36-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-devel" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/389-ds-base-devel-1.4.3.36-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/389-ds-base-1.4.3.36-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-devel" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/389-ds-base-devel-1.4.3.36-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-legacy-tools" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/389-ds-base-legacy-tools-1.4.3.36-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-snmp" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/389-ds-base-snmp-1.4.3.36-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-help" release="9.u6" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/389-ds-base-help-1.4.3.36-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-lib389" release="9.u6" version="1.4.3.36">
					<filename>python3-lib389-1.4.3.36-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-lib389-1.4.3.36-9.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-389-ds" release="9.u6" version="1.4.3.36">
					<filename>cockpit-389-ds-1.4.3.36-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/cockpit-389-ds-1.4.3.36-9.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2093</id>
		<title>An update for redis5 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46981&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46981" id="CVE-2024-46981" title="CVE-2024-46981" type="cve"></reference>
		</references>
		<description>CVE-2024-46981:Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to manipulate the garbage collector and potentially lead to remote code execution. The problem is fixed in 7.4.2, 7.2.7, and 6.2.17. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u10" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/redis5-doc-5.0.7-6.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u10" version="5.0.7">
					<filename>redis5-5.0.7-6.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/redis5-5.0.7-6.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u10" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/redis5-devel-5.0.7-6.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u10" version="5.0.7">
					<filename>redis5-5.0.7-6.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/redis5-5.0.7-6.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u10" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/redis5-devel-5.0.7-6.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2094</id>
		<title>An update for nodejs is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23085" id="CVE-2025-23085" title="CVE-2025-23085" type="cve"></reference>
		</references>
		<description>CVE-2025-23085:A memory leak could occur when a remote peer abruptly closes the socket without sending a GOAWAY notification. Additionally, if an invalid header was detected by nghttp2, causing the connection to be terminated by the peer, the same leak was triggered. This flaw could lead to increased memory consumption and potential denial of service under certain conditions.&#xA;&#xA;This vulnerability affects HTTP/2 Server users on Node.js v18.x, v20.x, v22.x and v23.x.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="11.u7" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nodejs-full-i18n-12.22.11-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="11.u7" version="12.22.11">
					<filename>nodejs-libs-12.22.11-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nodejs-libs-12.22.11-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.11.u7" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/npm-6.14.16-1.12.22.11.11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs" release="11.u7" version="12.22.11">
					<filename>nodejs-12.22.11-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nodejs-12.22.11-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="11.u7" version="12.22.11">
					<filename>nodejs-devel-12.22.11-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nodejs-devel-12.22.11-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.11.u7" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/v8-devel-7.8.279.23-1.12.22.11.11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.11.u7" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/npm-6.14.16-1.12.22.11.11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.11.u7" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/v8-devel-7.8.279.23-1.12.22.11.11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="11.u7" version="12.22.11">
					<filename>nodejs-12.22.11-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nodejs-12.22.11-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="11.u7" version="12.22.11">
					<filename>nodejs-devel-12.22.11-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nodejs-devel-12.22.11-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="11.u7" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nodejs-full-i18n-12.22.11-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="11.u7" version="12.22.11">
					<filename>nodejs-libs-12.22.11-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nodejs-libs-12.22.11-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="11.u7" version="12.22.11">
					<filename>nodejs-docs-12.22.11-11.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nodejs-docs-12.22.11-11.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2095</id>
		<title>An update for syslinux is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24370&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-24370" id="CVE-2020-24370" title="CVE-2020-24370" type="cve"></reference>
		</references>
		<description>CVE-2020-24370:ldebug.c in Lua 5.4.0 allows a negation overflow and segmentation fault in getlocal and setlocal, as demonstrated by getlocal(3,2^31).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="syslinux-efi64" release="17.u4" version="6.04">
					<filename>syslinux-efi64-6.04-17.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-efi64-6.04-17.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-perl" release="17.u4" version="6.04">
					<filename>syslinux-perl-6.04-17.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-perl-6.04-17.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux" release="17.u4" version="6.04">
					<filename>syslinux-6.04-17.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-6.04-17.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-devel" release="17.u4" version="6.04">
					<filename>syslinux-devel-6.04-17.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-devel-6.04-17.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="syslinux-extlinux" release="17.u4" version="6.04">
					<filename>syslinux-extlinux-6.04-17.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-extlinux-6.04-17.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-extlinux-nonlinux" release="17.u4" version="6.04">
					<filename>syslinux-extlinux-nonlinux-6.04-17.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-extlinux-nonlinux-6.04-17.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-nonlinux" release="17.u4" version="6.04">
					<filename>syslinux-nonlinux-6.04-17.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-nonlinux-6.04-17.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="syslinux-tftpboot" release="17.u4" version="6.04">
					<filename>syslinux-tftpboot-6.04-17.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/syslinux-tftpboot-6.04-17.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2096</id>
		<title>An update for edk2 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-13176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-13176" id="CVE-2024-13176" title="CVE-2024-13176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
		</references>
		<description>CVE-2024-13176:Issue summary: A timing side-channel which could potentially allow recovering&#xA;the private key exists in the ECDSA signature computation.&#xA;&#xA;Impact summary: A timing side-channel in ECDSA signature computations&#xA;could allow recovering the private key by an attacker. However, measuring&#xA;the timing would require either local access to the signing application or&#xA;a very fast network connection with low latency.&#xA;&#xA;There is a timing signal of around 300 nanoseconds when the top word of&#xA;the inverted ECDSA nonce value is zero. This can happen with significant&#xA;probability only for some of the supported elliptic curves. In particular&#xA;the NIST P-521 curve is affected. To be able to measure this leak, the attacker&#xA;process must either be located in the same physical computer or must&#xA;have a very fast network connection with low latency. For that reason&#xA;the severity of this vulnerability is Low.&#xA;&#xA;The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.&#xA;CVE-2024-4741:Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause&#xA;memory to be accessed that was previously freed in some situations&#xA;&#xA;Impact summary: A use after free can have a range of potential consequences such&#xA;as the corruption of valid data, crashes or execution of arbitrary code.&#xA;However, only applications that directly call the SSL_free_buffers function are&#xA;affected by this issue. Applications that do not call this function are not&#xA;vulnerable. Our investigations indicate that this function is rarely used by&#xA;applications.&#xA;&#xA;The SSL_free_buffers function is used to free the internal OpenSSL buffer used&#xA;when processing an incoming record from the network. The call is only expected&#xA;to succeed if the buffer is not currently in use. However, two scenarios have&#xA;been identified where the buffer is freed even when still in use.&#xA;&#xA;The first scenario occurs where a record header has been received from the&#xA;network and processed by OpenSSL, but the full record body has not yet arrived.&#xA;In this case calling SSL_free_buffers will succeed even though a record has only&#xA;been partially processed and the buffer is still in use.&#xA;&#xA;The second scenario occurs where a full record containing application data has&#xA;been received and processed by OpenSSL but the application has only read part of&#xA;this data. Again a call to SSL_free_buffers will succeed even though the buffer&#xA;is still in use.&#xA;&#xA;While these scenarios could occur accidentally during normal operation a&#xA;malicious attacker could attempt to engineer a stituation where this occurs.&#xA;We are not aware of this issue being actively exploited.&#xA;&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="23.u12" version="202011">
					<filename>python3-edk2-devel-202011-23.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/python3-edk2-devel-202011-23.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="23.u12" version="202011">
					<filename>edk2-ovmf-202011-23.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/edk2-ovmf-202011-23.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="23.u12" version="202011">
					<filename>edk2-aarch64-202011-23.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/edk2-aarch64-202011-23.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="23.u12" version="202011">
					<filename>edk2-help-202011-23.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/edk2-help-202011-23.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="23.u12" version="202011">
					<filename>edk2-devel-202011-23.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/edk2-devel-202011-23.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="23.u12" version="202011">
					<filename>edk2-devel-202011-23.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/edk2-devel-202011-23.u12.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2097</id>
		<title>An update for redis is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46981&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46981" id="CVE-2024-46981" title="CVE-2024-46981" type="cve"></reference>
		</references>
		<description>CVE-2024-46981:Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to manipulate the garbage collector and potentially lead to remote code execution. The problem is fixed in 7.4.2, 7.2.7, and 6.2.17. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2098</id>
		<title>An update for uboot-tools is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57254&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57254" id="CVE-2024-57254" title="CVE-2024-57254" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57255&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57255" id="CVE-2024-57255" title="CVE-2024-57255" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57256&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57256" id="CVE-2024-57256" title="CVE-2024-57256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57257&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57257" id="CVE-2024-57257" title="CVE-2024-57257" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57258&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57258" id="CVE-2024-57258" title="CVE-2024-57258" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57259&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57259" id="CVE-2024-57259" title="CVE-2024-57259" type="cve"></reference>
		</references>
		<description>CVE-2024-57254:An integer overflow in sqfs_inode_size in Das U-Boot before 2025.01-rc1 occurs in the symlink size calculation via a crafted squashfs filesystem.&#xA;CVE-2024-57255:An integer overflow in sqfs_resolve_symlink in Das U-Boot before 2025.01-rc1 occurs via a crafted squashfs filesystem with an inode size of 0xffffffff, resulting in a malloc of zero and resultant memory overwrite.&#xA;CVE-2024-57256:An integer overflow in ext4fs_read_symlink in Das U-Boot before 2025.01-rc1 occurs for zalloc (adding one to an le32 variable) via a crafted ext4 filesystem with an inode size of 0xffffffff, resulting in a malloc of zero and resultant memory overwrite.&#xA;CVE-2024-57257:A stack consumption issue in sqfs_size in Das U-Boot before 2025.01-rc1 occurs via a crafted squashfs filesystem with deep symlink nesting.&#xA;CVE-2024-57258:Integer overflows in memory allocation in Das U-Boot before 2025.01-rc1 occur for a crafted squashfs filesystem via sbrk, via request2size, or because ptrdiff_t is mishandled on x86_64.&#xA;CVE-2024-57259:sqfs_search_dir in Das U-Boot before 2025.01-rc1 exhibits an off-by-one error and resultant heap memory corruption for squashfs directory listing because the path separator is not considered in a size calculation.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="uboot-tools" release="9.u2" version="2021.10">
					<filename>uboot-tools-2021.10-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/uboot-tools-2021.10-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uboot-images-armv8" release="9.u2" version="2021.10">
					<filename>uboot-images-armv8-2021.10-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/uboot-images-armv8-2021.10-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uboot-tools-help" release="9.u2" version="2021.10">
					<filename>uboot-tools-help-2021.10-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/uboot-tools-help-2021.10-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-images-elf" release="9.u2" version="2021.10">
					<filename>uboot-images-elf-2021.10-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/uboot-images-elf-2021.10-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-tools" release="9.u2" version="2021.10">
					<filename>uboot-tools-2021.10-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/uboot-tools-2021.10-9.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2099</id>
		<title>An update for tomcat is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56337&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56337" id="CVE-2024-56337" title="CVE-2024-56337" type="cve"></reference>
		</references>
		<description>CVE-2024-56337:Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97.&#xA;&#xA;The mitigation for CVE-2024-50379 was incomplete.&#xA;&#xA;Users running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation &#xA;parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat:&#xA;- running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true)&#xA;- running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false)&#xA;- running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed)&#xA;&#xA;Tomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include checks that sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write enabled on a case insensitive file system. Tomcat will also set sun.io.useCanonCaches to false by default where it can.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="1" name="tomcat" release="1.u15" version="9.0.100">
					<filename>tomcat-9.0.100-1.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/tomcat-9.0.100-1.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="1.u15" version="9.0.100">
					<filename>tomcat-help-9.0.100-1.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/tomcat-help-9.0.100-1.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="1.u15" version="9.0.100">
					<filename>tomcat-jsvc-9.0.100-1.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/tomcat-jsvc-9.0.100-1.u15.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2100</id>
		<title>An update for rubygem-rack is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27610&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27610" id="CVE-2025-27610" title="CVE-2025-27610" type="cve"></reference>
		</references>
		<description>CVE-2025-27610:Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.13, 3.0.14, and 3.1.12, `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. Versions 2.2.13, 3.0.14, and 3.1.12 contain a patch for the issue. Other mitigations include removing usage of `Rack::Static`, or ensuring that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="1" name="rubygem-rack-help" release="6.u2" version="2.2.3.1">
					<filename>rubygem-rack-help-2.2.3.1-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rack-help-2.2.3.1-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-rack" release="6.u2" version="2.2.3.1">
					<filename>rubygem-rack-2.2.3.1-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/rubygem-rack-2.2.3.1-6.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2101</id>
		<title>An update for mysql is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21490&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21490" id="CVE-2025-21490" title="CVE-2025-21490" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21491&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21491" id="CVE-2025-21491" title="CVE-2025-21491" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21495&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21495" id="CVE-2025-21495" title="CVE-2025-21495" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21497&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21497" id="CVE-2025-21497" title="CVE-2025-21497" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21500&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21500" id="CVE-2025-21500" title="CVE-2025-21500" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21501&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21501" id="CVE-2025-21501" title="CVE-2025-21501" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21503&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21503" id="CVE-2025-21503" title="CVE-2025-21503" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21505&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21505" id="CVE-2025-21505" title="CVE-2025-21505" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21518&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21518" id="CVE-2025-21518" title="CVE-2025-21518" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21519&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21519" id="CVE-2025-21519" title="CVE-2025-21519" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21520&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21520" id="CVE-2025-21520" title="CVE-2025-21520" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21522&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21522" id="CVE-2025-21522" title="CVE-2025-21522" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21523&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21523" id="CVE-2025-21523" title="CVE-2025-21523" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21529&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21529" id="CVE-2025-21529" title="CVE-2025-21529" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21531&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21531" id="CVE-2025-21531" title="CVE-2025-21531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21540&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21540" id="CVE-2025-21540" title="CVE-2025-21540" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21543&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21543" id="CVE-2025-21543" title="CVE-2025-21543" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21546&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21546" id="CVE-2025-21546" title="CVE-2025-21546" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21555&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21555" id="CVE-2025-21555" title="CVE-2025-21555" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21559&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21559" id="CVE-2025-21559" title="CVE-2025-21559" type="cve"></reference>
		</references>
		<description>CVE-2025-21490:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21491:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21495:Vulnerability in the MySQL Enterprise Firewall product of Oracle MySQL (component: Firewall).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Enterprise Firewall.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Enterprise Firewall. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21497:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-21500:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21501:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21503:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21505:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21518:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21519:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21520:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Options).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 1.8 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N).&#xA;CVE-2025-21522:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21523:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21529:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21531:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21540:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2025-21543:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Packaging).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21546:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 3.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2025-21555:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-21559:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u4" version="8.0.41">
					<filename>mysql-devel-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-devel-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u4" version="8.0.41">
					<filename>mysql-errmsg-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-errmsg-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u4" version="8.0.41">
					<filename>mysql-help-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-help-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u4" version="8.0.41">
					<filename>mysql-test-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-test-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u4" version="8.0.41">
					<filename>mysql-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u4" version="8.0.41">
					<filename>mysql-server-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-server-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u4" version="8.0.41">
					<filename>mysql-common-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-common-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u4" version="8.0.41">
					<filename>mysql-config-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-config-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u4" version="8.0.41">
					<filename>mysql-libs-8.0.41-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/mysql-libs-8.0.41-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u4" version="8.0.41">
					<filename>mysql-test-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-test-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u4" version="8.0.41">
					<filename>mysql-config-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-config-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u4" version="8.0.41">
					<filename>mysql-errmsg-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-errmsg-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u4" version="8.0.41">
					<filename>mysql-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u4" version="8.0.41">
					<filename>mysql-common-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-common-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u4" version="8.0.41">
					<filename>mysql-devel-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-devel-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u4" version="8.0.41">
					<filename>mysql-libs-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-libs-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u4" version="8.0.41">
					<filename>mysql-help-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-help-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u4" version="8.0.41">
					<filename>mysql-server-8.0.41-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/mysql-server-8.0.41-1.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2102</id>
		<title>An update for apache-mina is now available for 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52046&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52046" id="CVE-2024-52046" title="CVE-2024-52046" type="cve"></reference>
		</references>
		<description>CVE-2024-52046:The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process&#xA;incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows&#xA;attackers to exploit the deserialization process by sending specially crafted malicious serialized data,&#xA;potentially leading to remote code execution (RCE) attacks.&#xA;&#xA;&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#xA;&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;&#xA;&#xA;&#xA;&#x9;&#x9;&#x9;&#xA;&#xA;&#xA;&#x9;&#x9;&#xA;&#xA;&#xA;&#x9;&#xA;This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;It&#39;s also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library.&#xA;&#xA;&#xA;&#xA;&#xA;Upgrading will  not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods:&#xA;&#xA;&#xA;&#xA;&#xA;    /**&#xA;&#xA;     * Accept class names where the supplied ClassNameMatcher matches for&#xA;&#xA;     * deserialization, unless they are otherwise rejected.&#xA;&#xA;     *&#xA;&#xA;     * @param classNameMatcher the matcher to use&#xA;&#xA;     */&#xA;&#xA;    public void accept(ClassNameMatcher classNameMatcher)&#xA;&#xA;&#xA;&#xA;&#xA;    /**&#xA;&#xA;     * Accept class names that match the supplied pattern for&#xA;&#xA;     * deserialization, unless they are otherwise rejected.&#xA;&#xA;     *&#xA;&#xA;     * @param pattern standard Java regexp&#xA;&#xA;     */&#xA;&#xA;    public void accept(Pattern pattern) &#xA;&#xA;&#xA;&#xA;&#xA;&#xA;    /**&#xA;&#xA;     * Accept the wildcard specified classes for deserialization,&#xA;&#xA;     * unless they are otherwise rejected.&#xA;&#xA;     *&#xA;&#xA;     * @param patterns Wildcard file name patterns as defined by&#xA;&#xA;     *                  {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch}&#xA;&#xA;     */&#xA;&#xA;    public void accept(String... patterns)&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;By default, the decoder will reject *all* classes that will be present in the incoming data.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="0" name="apache-mina-mina-filter-compression" release="1" version="2.0.27">
					<filename>apache-mina-mina-filter-compression-2.0.27-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/apache-mina-mina-filter-compression-2.0.27-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-mina-http" release="1" version="2.0.27">
					<filename>apache-mina-mina-http-2.0.27-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/apache-mina-mina-http-2.0.27-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-mina-statemachine" release="1" version="2.0.27">
					<filename>apache-mina-mina-statemachine-2.0.27-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/apache-mina-mina-statemachine-2.0.27-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina" release="1" version="2.0.27">
					<filename>apache-mina-2.0.27-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/apache-mina-2.0.27-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-javadoc" release="1" version="2.0.27">
					<filename>apache-mina-javadoc-2.0.27-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/apache-mina-javadoc-2.0.27-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-mina-core" release="1" version="2.0.27">
					<filename>apache-mina-mina-core-2.0.27-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/apache-mina-mina-core-2.0.27-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2103</id>
		<title>An update for vim is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22134&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22134" id="CVE-2025-22134" title="CVE-2025-22134" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-24014" id="CVE-2025-24014" title="CVE-2025-24014" type="cve"></reference>
		</references>
		<description>CVE-2025-22134:When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won&#39;t try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003&#xA;CVE-2025-24014:Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn&#39;t show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn&#39;t been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="31.u18" version="9.0">
					<filename>vim-enhanced-9.0-31.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/vim-enhanced-9.0-31.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="31.u18" version="9.0">
					<filename>vim-common-9.0-31.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/vim-common-9.0-31.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="31.u18" version="9.0">
					<filename>vim-minimal-9.0-31.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/vim-minimal-9.0-31.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="31.u18" version="9.0">
					<filename>vim-X11-9.0-31.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/vim-X11-9.0-31.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-common" release="31.u18" version="9.0">
					<filename>vim-common-9.0-31.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/vim-common-9.0-31.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="31.u18" version="9.0">
					<filename>vim-enhanced-9.0-31.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/vim-enhanced-9.0-31.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="31.u18" version="9.0">
					<filename>vim-minimal-9.0-31.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/vim-minimal-9.0-31.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="31.u18" version="9.0">
					<filename>vim-X11-9.0-31.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/vim-X11-9.0-31.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="31.u18" version="9.0">
					<filename>vim-filesystem-9.0-31.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/vim-filesystem-9.0-31.u18.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2104</id>
		<title>An update for node_exporter is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21698&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-21698" id="CVE-2022-21698" title="CVE-2022-21698" type="cve"></reference>
		</references>
		<description>CVE-2022-21698:client_golang is the instrumentation library for Go applications in Prometheus, and the promhttp package in client_golang provides tooling around HTTP servers and clients. In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods. In order to be affected, an instrumented software must use any of `promhttp.InstrumentHandler*` middleware except `RequestsInFlight`; not filter any specific methods (e.g GET) before middleware; pass metric with `method` label name to our middleware; and not have any firewall/LB/proxy that filters away requests with unknown `method`. client_golang version 1.11.1 contains a patch for this issue. Several workarounds are available, including removing the `method` label name from counter/gauge used in the InstrumentHandler; turning off affected promhttp handlers; adding custom middleware before promhttp handler that will sanitize the request method given by Go http.Request; and using a reverse proxy or web application firewall, configured to only allow a limited set of methods.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="golang-github-prometheus-node_exporter" release="3.u1" version="1.0.1">
					<filename>golang-github-prometheus-node_exporter-1.0.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/golang-github-prometheus-node_exporter-1.0.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="golang-github-prometheus-node_exporter" release="3.u1" version="1.0.1">
					<filename>golang-github-prometheus-node_exporter-1.0.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/golang-github-prometheus-node_exporter-1.0.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-github-prometheus-node_exporter-devel" release="3.u1" version="1.0.1">
					<filename>golang-github-prometheus-node_exporter-devel-1.0.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/golang-github-prometheus-node_exporter-devel-1.0.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2105</id>
		<title>An update for grub2 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45781&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45781" id="CVE-2024-45781" title="CVE-2024-45781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45782" id="CVE-2024-45782" title="CVE-2024-45782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56737" id="CVE-2024-56737" title="CVE-2024-56737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45780&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45780" id="CVE-2024-45780" title="CVE-2024-45780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45783&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45783" id="CVE-2024-45783" title="CVE-2024-45783" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49504&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49504" id="CVE-2024-49504" title="CVE-2024-49504" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0624&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0624" id="CVE-2025-0624" title="CVE-2025-0624" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45774&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45774" id="CVE-2024-45774" title="CVE-2024-45774" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45775&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45775" id="CVE-2024-45775" title="CVE-2024-45775" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0622&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0622" id="CVE-2025-0622" title="CVE-2025-0622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45776&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45776" id="CVE-2024-45776" title="CVE-2024-45776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45777&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45777" id="CVE-2024-45777" title="CVE-2024-45777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0690&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0690" id="CVE-2025-0690" title="CVE-2025-0690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1118&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1118" id="CVE-2025-1118" title="CVE-2025-1118" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45778" id="CVE-2024-45778" title="CVE-2024-45778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45779&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45779" id="CVE-2024-45779" title="CVE-2024-45779" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0677&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0677" id="CVE-2025-0677" title="CVE-2025-0677" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0684&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0684" id="CVE-2025-0684" title="CVE-2025-0684" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0685&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0685" id="CVE-2025-0685" title="CVE-2025-0685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0686&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0686" id="CVE-2025-0686" title="CVE-2025-0686" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0689&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0689" id="CVE-2025-0689" title="CVE-2025-0689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0678" id="CVE-2025-0678" title="CVE-2025-0678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1125" id="CVE-2025-1125" title="CVE-2025-1125" type="cve"></reference>
		</references>
		<description>CVE-2024-45781:A flaw was found in grub2. When reading a symbolic link&#39;s name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.&#xA;CVE-2024-45782:A flaw was found in the HFS filesystem. When reading an HFS volume&#39;s name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name&#39;s length. This issue may read to a heap-based out-of-bounds writer, impacting grub&#39;s sensitive data integrity and eventually leading to a secure boot protection bypass.&#xA;CVE-2024-56737:GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.&#xA;CVE-2024-45780:A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It&#39;s possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.&#xA;CVE-2024-45783:A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn&#39;t properly set an ERRNO value. This issue may lead to a NULL pointer access.&#xA;CVE-2024-49504:grub2 allowed attackers with access to the grub shell to access files on the encrypted disks.&#xA;CVE-2025-0624:A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections.&#xA;CVE-2024-45774:A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.&#xA;CVE-2024-45775:A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub&#39;s argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.&#xA;CVE-2025-0622:A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections.&#xA;CVE-2024-45776:When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.&#xA;CVE-2024-45777:A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2&#39;s sensitive heap data, eventually leading to the circumvention of secure boot protections.&#xA;CVE-2025-0690:The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it&#39;s possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub&#39;s internal critical data and secure boot bypass is not discarded as consequence.&#xA;CVE-2025-1118:A flaw was found in grub2. Grub&#39;s dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory.&#xA;CVE-2024-45778:A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.&#xA;CVE-2024-45779:An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.&#xA;CVE-2025-0677:A flaw was found in grub2. When performing a symlink lookup, the grub&#39;s UFS module checks the inode&#39;s data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms.&#xA;CVE-2025-0684:A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub&#39;s reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub&#39;s internal critical data and can result in arbitrary code execution, by-passing secure boot protections.&#xA;CVE-2025-0685:A flaw was found in grub2. When reading data from a jfs filesystem, grub&#39;s jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub&#39;s internal critical data and may result in arbitrary code execution, by-passing secure boot protections.&#xA;CVE-2025-0686:A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub&#39;s romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub&#39;s internal critical data and can result in arbitrary code execution by-passing secure boot protections.&#xA;CVE-2025-0689:When reading data from disk, the grub&#39;s UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections.&#xA;CVE-2025-0678:A flaw was found in grub2. When reading data from a squash4 filesystem, grub&#39;s squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub&#39;s internal critical data and may result in arbitrary code execution, by-passing secure boot protections.&#xA;CVE-2025-1125:When reading data from a hfs filesystem, grub&#39;s hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub&#39;s internal critical data and may result in arbitrary code execution by-passing secure boot protections.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="1" name="grub2-help" release="51.u17" version="2.06">
					<filename>grub2-help-2.06-51.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-help-2.06-51.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-ia32-modules" release="51.u17" version="2.06">
					<filename>grub2-efi-ia32-modules-2.06-51.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-ia32-modules-2.06-51.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-aa64-modules" release="51.u17" version="2.06">
					<filename>grub2-efi-aa64-modules-2.06-51.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-aa64-modules-2.06-51.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-common" release="51.u17" version="2.06">
					<filename>grub2-common-2.06-51.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-common-2.06-51.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-pc-modules" release="51.u17" version="2.06">
					<filename>grub2-pc-modules-2.06-51.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-pc-modules-2.06-51.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-x64-modules" release="51.u17" version="2.06">
					<filename>grub2-efi-x64-modules-2.06-51.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-x64-modules-2.06-51.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-pc" release="51.u17" version="2.06">
					<filename>grub2-pc-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-pc-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools" release="51.u17" version="2.06">
					<filename>grub2-tools-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-tools-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-efi" release="51.u17" version="2.06">
					<filename>grub2-tools-efi-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-tools-efi-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-minimal" release="51.u17" version="2.06">
					<filename>grub2-tools-minimal-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-tools-minimal-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64-cdboot" release="51.u17" version="2.06">
					<filename>grub2-efi-x64-cdboot-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-x64-cdboot-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32" release="51.u17" version="2.06">
					<filename>grub2-efi-ia32-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-ia32-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32-cdboot" release="51.u17" version="2.06">
					<filename>grub2-efi-ia32-cdboot-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-ia32-cdboot-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64" release="51.u17" version="2.06">
					<filename>grub2-efi-x64-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-efi-x64-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-extra" release="51.u17" version="2.06">
					<filename>grub2-tools-extra-2.06-51.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/grub2-tools-extra-2.06-51.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-efi-aa64" release="51.u17" version="2.06">
					<filename>grub2-efi-aa64-2.06-51.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/grub2-efi-aa64-2.06-51.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-efi-aa64-cdboot" release="51.u17" version="2.06">
					<filename>grub2-efi-aa64-cdboot-2.06-51.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/grub2-efi-aa64-cdboot-2.06-51.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools" release="51.u17" version="2.06">
					<filename>grub2-tools-2.06-51.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/grub2-tools-2.06-51.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-minimal" release="51.u17" version="2.06">
					<filename>grub2-tools-minimal-2.06-51.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/grub2-tools-minimal-2.06-51.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-extra" release="51.u17" version="2.06">
					<filename>grub2-tools-extra-2.06-51.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/grub2-tools-extra-2.06-51.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2106</id>
		<title>An update for libcap is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1390&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1390" id="CVE-2025-1390" title="CVE-2025-1390" type="cve"></reference>
		</references>
		<description>CVE-2025-1390:The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="libcap-devel" release="8.u4" version="2.61">
					<filename>libcap-devel-2.61-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libcap-devel-2.61-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcap" release="8.u4" version="2.61">
					<filename>libcap-2.61-8.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libcap-2.61-8.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcap" release="8.u4" version="2.61">
					<filename>libcap-2.61-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libcap-2.61-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcap-devel" release="8.u4" version="2.61">
					<filename>libcap-devel-2.61-8.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libcap-devel-2.61-8.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libcap-help" release="8.u4" version="2.61">
					<filename>libcap-help-2.61-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libcap-help-2.61-8.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2107</id>
		<title>An update for gnutls is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12243&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12243" id="CVE-2024-12243" title="CVE-2024-12243" type="cve"></reference>
		</references>
		<description>CVE-2024-12243:A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="0" name="gnutls-help" release="16.u8" version="3.7.2">
					<filename>gnutls-help-3.7.2-16.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/gnutls-help-3.7.2-16.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls" release="16.u8" version="3.7.2">
					<filename>gnutls-3.7.2-16.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/gnutls-3.7.2-16.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="16.u8" version="3.7.2">
					<filename>gnutls-devel-3.7.2-16.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/gnutls-devel-3.7.2-16.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="16.u8" version="3.7.2">
					<filename>gnutls-utils-3.7.2-16.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/gnutls-utils-3.7.2-16.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="16.u8" version="3.7.2">
					<filename>gnutls-3.7.2-16.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/gnutls-3.7.2-16.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="16.u8" version="3.7.2">
					<filename>gnutls-devel-3.7.2-16.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/gnutls-devel-3.7.2-16.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="16.u8" version="3.7.2">
					<filename>gnutls-utils-3.7.2-16.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/gnutls-utils-3.7.2-16.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2108</id>
		<title>An update for jss is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4132&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-4132" id="CVE-2022-4132" title="CVE-2022-4132" type="cve"></reference>
		</references>
		<description>CVE-2022-4132:A flaw was found in JSS. A memory leak in JSS requires non-standard configuration but is a low-effort DoS vector if configured that way (repeatedly hitting the login page).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="jss" release="3.u1" version="5.1.0">
					<filename>jss-5.1.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/jss-5.1.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jss-help" release="3.u1" version="5.1.0">
					<filename>jss-help-5.1.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/jss-help-5.1.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jss" release="3.u1" version="5.1.0">
					<filename>jss-5.1.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/jss-5.1.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jss-help" release="3.u1" version="5.1.0">
					<filename>jss-help-5.1.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/jss-help-5.1.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2109</id>
		<title>An update for emacs is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1244&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1244" id="CVE-2025-1244" title="CVE-2025-1244" type="cve"></reference>
		</references>
		<description>CVE-2025-1244:A command injection flaw was found in the text editor Emacs. It could allow a remote, unauthenticated attacker to execute arbitrary shell commands on a vulnerable system. Exploitation is possible by tricking users into visiting a specially crafted website or an HTTP URL with a redirect.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="1" name="emacs" release="15.u7" version="27.2">
					<filename>emacs-27.2-15.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-27.2-15.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-common" release="15.u7" version="27.2">
					<filename>emacs-common-27.2-15.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-common-27.2-15.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-nox" release="15.u7" version="27.2">
					<filename>emacs-nox-27.2-15.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-nox-27.2-15.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-devel" release="15.u7" version="27.2">
					<filename>emacs-devel-27.2-15.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-devel-27.2-15.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="emacs-lucid" release="15.u7" version="27.2">
					<filename>emacs-lucid-27.2-15.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-lucid-27.2-15.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-nox" release="15.u7" version="27.2">
					<filename>emacs-nox-27.2-15.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/emacs-nox-27.2-15.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs" release="15.u7" version="27.2">
					<filename>emacs-27.2-15.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/emacs-27.2-15.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-common" release="15.u7" version="27.2">
					<filename>emacs-common-27.2-15.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/emacs-common-27.2-15.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-lucid" release="15.u7" version="27.2">
					<filename>emacs-lucid-27.2-15.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/emacs-lucid-27.2-15.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="emacs-devel" release="15.u7" version="27.2">
					<filename>emacs-devel-27.2-15.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/emacs-devel-27.2-15.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-filesystem" release="15.u7" version="27.2">
					<filename>emacs-filesystem-27.2-15.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-filesystem-27.2-15.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-help" release="15.u7" version="27.2">
					<filename>emacs-help-27.2-15.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-help-27.2-15.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="emacs-terminal" release="15.u7" version="27.2">
					<filename>emacs-terminal-27.2-15.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/emacs-terminal-27.2-15.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2110</id>
		<title>An update for libxkbfile is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26595&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26595" id="CVE-2025-26595" title="CVE-2025-26595" type="cve"></reference>
		</references>
		<description>CVE-2025-26595:A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="libxkbfile" release="6.u1" version="1.1.0">
					<filename>libxkbfile-1.1.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libxkbfile-1.1.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxkbfile-devel" release="6.u1" version="1.1.0">
					<filename>libxkbfile-devel-1.1.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libxkbfile-devel-1.1.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxkbfile" release="6.u1" version="1.1.0">
					<filename>libxkbfile-1.1.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libxkbfile-1.1.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxkbfile-devel" release="6.u1" version="1.1.0">
					<filename>libxkbfile-devel-1.1.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libxkbfile-devel-1.1.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2111</id>
		<title>An update for nfs-utils is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-1999-0554&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-1999-0554" id="CVE-1999-0554" title="CVE-1999-0554" type="cve"></reference>
		</references>
		<description>CVE-1999-0554:NFS exports system-critical data to the world, e.g. / or a password file.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="2" name="nfs-utils" release="15.u5" version="2.5.4">
					<filename>nfs-utils-2.5.4-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nfs-utils-2.5.4-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="nfs-utils-devel" release="15.u5" version="2.5.4">
					<filename>nfs-utils-devel-2.5.4-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nfs-utils-devel-2.5.4-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="nfs-utils-help" release="15.u5" version="2.5.4">
					<filename>nfs-utils-help-2.5.4-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nfs-utils-help-2.5.4-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="nfs-utils-min" release="15.u5" version="2.5.4">
					<filename>nfs-utils-min-2.5.4-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nfs-utils-min-2.5.4-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libnfsidmap" release="15.u5" version="2.5.4">
					<filename>libnfsidmap-2.5.4-15.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/libnfsidmap-2.5.4-15.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libnfsidmap" release="15.u5" version="2.5.4">
					<filename>libnfsidmap-2.5.4-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/libnfsidmap-2.5.4-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="nfs-utils-min" release="15.u5" version="2.5.4">
					<filename>nfs-utils-min-2.5.4-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nfs-utils-min-2.5.4-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="nfs-utils" release="15.u5" version="2.5.4">
					<filename>nfs-utils-2.5.4-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nfs-utils-2.5.4-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="nfs-utils-devel" release="15.u5" version="2.5.4">
					<filename>nfs-utils-devel-2.5.4-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nfs-utils-devel-2.5.4-15.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="nfs-utils-help" release="15.u5" version="2.5.4">
					<filename>nfs-utils-help-2.5.4-15.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nfs-utils-help-2.5.4-15.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2112</id>
		<title>An update for ctags is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4515&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-4515" id="CVE-2022-4515" title="CVE-2022-4515" type="cve"></reference>
		</references>
		<description>CVE-2022-4515:A flaw was found in Exuberant Ctags in the way it handles the &#34;-o&#34; option. This option specifies the tag filename. A crafted tag filename specified in the command line or in the configuration file results in arbitrary command execution because the externalSortTags() in sort.c calls the system(3) function in an unsafe way.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="ctags" release="30.u2" version="5.8">
					<filename>ctags-5.8-30.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ctags-5.8-30.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctags" release="30.u2" version="5.8">
					<filename>ctags-5.8-30.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/ctags-5.8-30.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ctags-help" release="30.u2" version="5.8">
					<filename>ctags-help-5.8-30.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/ctags-help-5.8-30.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2113</id>
		<title>An update for perl-FCGI is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2012-6687&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2012-6687" id="CVE-2012-6687" title="CVE-2012-6687" type="cve"></reference>
		</references>
		<description>CVE-2012-6687:FastCGI (aka fcgi and libfcgi) 2.4.0 allows remote attackers to cause a denial of service (segmentation fault and crash) via a large number of connections.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="1" name="perl-FCGI-help" release="13.u1" version="0.78">
					<filename>perl-FCGI-help-0.78-13.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/perl-FCGI-help-0.78-13.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="perl-FCGI" release="13.u1" version="0.78">
					<filename>perl-FCGI-0.78-13.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/perl-FCGI-0.78-13.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-FCGI-help" release="13.u1" version="0.78">
					<filename>perl-FCGI-help-0.78-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/perl-FCGI-help-0.78-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-FCGI" release="13.u1" version="0.78">
					<filename>perl-FCGI-0.78-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/perl-FCGI-0.78-13.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2114</id>
		<title>An update for undertow is now available for 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-12196&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2017-12196" id="CVE-2017-12196" title="CVE-2017-12196" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10184&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-10184" id="CVE-2019-10184" title="CVE-2019-10184" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-10212" id="CVE-2019-10212" title="CVE-2019-10212" type="cve"></reference>
		</references>
		<description>CVE-2017-12196:undertow before versions 1.4.18.SP1, 2.0.2.Final, 1.4.24.Final was found vulnerable when using Digest authentication, the server does not ensure that the value of URI in the Authorization header matches the URI in HTTP request line. This allows the attacker to cause a MITM attack and access the desired content on the server.&#xA;CVE-2019-10184:undertow before version 2.0.23.Final is vulnerable to an information leak issue. Web apps may have their directory structures predicted through requests without trailing slashes via the api.&#xA;CVE-2019-10212:A flaw was found in, all under 2.0.20, in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user&#39;s credentials from the log files.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="noarch" epoch="1" name="undertow" release="9.u4" version="1.4.0">
					<filename>undertow-1.4.0-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/undertow-1.4.0-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="undertow-javadoc" release="9.u4" version="1.4.0">
					<filename>undertow-javadoc-1.4.0-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/undertow-javadoc-1.4.0-9.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2115</id>
		<title>An update for etcd is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-3064" id="CVE-2022-3064" title="CVE-2022-3064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32082&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32082" id="CVE-2023-32082" title="CVE-2023-32082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24675&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-24675" id="CVE-2022-24675" title="CVE-2022-24675" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28327&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-28327" id="CVE-2022-28327" title="CVE-2022-28327" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24921&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-24921" id="CVE-2022-24921" title="CVE-2022-24921" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-44717&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-44717" id="CVE-2021-44717" title="CVE-2021-44717" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33195&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-33195" id="CVE-2021-33195" title="CVE-2021-33195" type="cve"></reference>
		</references>
		<description>CVE-2022-3064:Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory.&#xA;CVE-2022-41723:A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.&#xA;CVE-2023-32082:etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.26 and 3.5.9, the LeaseTimeToLive API allows access to key names (not value) associated to a lease when `Keys` parameter is true, even a user doesn&#39;t have read permission to the keys. The impact is limited to a cluster which enables auth (RBAC). Versions 3.4.26 and 3.5.9 fix this issue. There are no known workarounds.&#xA;CVE-2023-39325:A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.&#xA;CVE-2022-24675:encoding/pem in Go before 1.17.9 and 1.18.x before 1.18.1 has a Decode stack overflow via a large amount of PEM data.&#xA;CVE-2022-28327:The generic P-256 feature in crypto/elliptic in Go before 1.17.9 and 1.18.x before 1.18.1 allows a panic via long scalar input.&#xA;CVE-2022-24921:regexp.Compile in Go before 1.16.15 and 1.17.x before 1.17.8 allows stack exhaustion via a deeply nested expression.&#xA;CVE-2021-44717:Go before 1.16.12 and 1.17.x before 1.17.5 on UNIX allows write operations to an unintended file or unintended network connection as a consequence of erroneous closing of file descriptor 0 after file-descriptor exhaustion.&#xA;CVE-2021-33195:Go before 1.15.13 and 1.16.x before 1.16.5 has functions for DNS lookups that do not validate replies from DNS servers, and thus a return value may contain an unsafe injection (e.g., XSS) that does not conform to the RFC1035 format.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="x86_64" epoch="0" name="etcd" release="12.u3" version="3.4.14">
					<filename>etcd-3.4.14-12.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/etcd-3.4.14-12.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="etcd" release="12.u3" version="3.4.14">
					<filename>etcd-3.4.14-12.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/etcd-3.4.14-12.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2116</id>
		<title>An update for nginx is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23419" id="CVE-2025-23419" title="CVE-2025-23419" type="cve"></reference>
		</references>
		<description>CVE-2025-23419:When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when  TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key  are used and/or the  SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache  are used in the default server and the default server is performing client certificate authentication.  &#xA;&#xA;Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="1" name="nginx" release="8.u5" version="1.21.5">
					<filename>nginx-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="8.u5" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-mod-http-perl-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="8.u5" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-mod-devel-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="8.u5" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-mod-http-image-filter-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="8.u5" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-mod-http-xslt-filter-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="8.u5" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-mod-mail-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="8.u5" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/nginx-mod-stream-1.21.5-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="8.u5" version="1.21.5">
					<filename>nginx-help-1.21.5-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-help-1.21.5-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="8.u5" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-all-modules-1.21.5-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="8.u5" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-filesystem-1.21.5-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="8.u5" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-mod-http-perl-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="8.u5" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-mod-stream-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="8.u5" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-mod-http-image-filter-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="8.u5" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-mod-http-xslt-filter-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="8.u5" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-mod-mail-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="8.u5" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-mod-devel-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx" release="8.u5" version="1.21.5">
					<filename>nginx-1.21.5-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/nginx-1.21.5-8.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2117</id>
		<title>An update for raptor2 is now available for 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-03-27"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57823" id="CVE-2024-57823" title="CVE-2024-57823" type="cve"></reference>
		</references>
		<description>CVE-2024-57823:In Raptor RDF Syntax Library through 2.0.16, there is an integer underflow when normalizing a URI with the turtle parser in raptor_uri_normalize_path().&#xA;</description>
		<pkglist>
			<collection>
				<name>23.1.4.3</name>
				<package arch="aarch64" epoch="0" name="raptor2-help" release="18.u1" version="2.0.15">
					<filename>raptor2-help-2.0.15-18.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/raptor2-help-2.0.15-18.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="raptor2" release="18.u1" version="2.0.15">
					<filename>raptor2-2.0.15-18.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/raptor2-2.0.15-18.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="raptor2-devel" release="18.u1" version="2.0.15">
					<filename>raptor2-devel-2.0.15-18.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.1.4.3/raptor2-devel-2.0.15-18.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="raptor2" release="18.u1" version="2.0.15">
					<filename>raptor2-2.0.15-18.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/raptor2-2.0.15-18.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="raptor2-devel" release="18.u1" version="2.0.15">
					<filename>raptor2-devel-2.0.15-18.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/raptor2-devel-2.0.15-18.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="raptor2-help" release="18.u1" version="2.0.15">
					<filename>raptor2-help-2.0.15-18.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.1.4.3/raptor2-help-2.0.15-18.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2118</id>
		<title>An update for postgresql is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1094&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1094" id="CVE-2025-1094" title="CVE-2025-1094" type="cve"></reference>
		</references>
		<description>CVE-2025-1094:Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns.  Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal.  Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when client_encoding is BIG5 and server_encoding is one of EUC_TW or MULE_INTERNAL.  Versions before PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 are affected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="2.u4" version="13.20">
					<filename>postgresql-private-libs-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-private-libs-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="2.u4" version="13.20">
					<filename>postgresql-static-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-static-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="2.u4" version="13.20">
					<filename>postgresql-docs-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-docs-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="2.u4" version="13.20">
					<filename>postgresql-private-devel-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-private-devel-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="2.u4" version="13.20">
					<filename>postgresql-plpython3-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-plpython3-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="2.u4" version="13.20">
					<filename>postgresql-test-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-test-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="2.u4" version="13.20">
					<filename>postgresql-contrib-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-contrib-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="2.u4" version="13.20">
					<filename>postgresql-llvmjit-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-llvmjit-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="2.u4" version="13.20">
					<filename>postgresql-server-devel-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-server-devel-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="2.u4" version="13.20">
					<filename>postgresql-pltcl-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-pltcl-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="2.u4" version="13.20">
					<filename>postgresql-plperl-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-plperl-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="2.u4" version="13.20">
					<filename>postgresql-server-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-server-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql" release="2.u4" version="13.20">
					<filename>postgresql-13.20-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-13.20-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="2.u4" version="13.20">
					<filename>postgresql-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="2.u4" version="13.20">
					<filename>postgresql-llvmjit-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-llvmjit-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="2.u4" version="13.20">
					<filename>postgresql-plperl-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-plperl-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="2.u4" version="13.20">
					<filename>postgresql-private-devel-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-private-devel-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="2.u4" version="13.20">
					<filename>postgresql-pltcl-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-pltcl-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="2.u4" version="13.20">
					<filename>postgresql-plpython3-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-plpython3-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="2.u4" version="13.20">
					<filename>postgresql-docs-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-docs-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="2.u4" version="13.20">
					<filename>postgresql-private-libs-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-private-libs-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="2.u4" version="13.20">
					<filename>postgresql-server-devel-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-server-devel-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="2.u4" version="13.20">
					<filename>postgresql-static-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-static-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="2.u4" version="13.20">
					<filename>postgresql-test-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-test-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="2.u4" version="13.20">
					<filename>postgresql-server-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-server-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="2.u4" version="13.20">
					<filename>postgresql-contrib-13.20-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/postgresql-contrib-13.20-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="2.u4" version="13.20">
					<filename>postgresql-test-rpm-macros-13.20-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/postgresql-test-rpm-macros-13.20-2.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2119</id>
		<title>An update for iperf3 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53580&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53580" id="CVE-2024-53580" title="CVE-2024-53580" type="cve"></reference>
		</references>
		<description>CVE-2024-53580:iperf v3.17.1 was discovered to contain a segmentation violation via the iperf_exchange_parameters() function.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="aarch64" epoch="0" name="iperf3" release="1.u4" version="3.18">
					<filename>iperf3-3.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/iperf3-3.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3-devel" release="1.u4" version="3.18">
					<filename>iperf3-devel-3.18-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/iperf3-devel-3.18-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3" release="1.u4" version="3.18">
					<filename>iperf3-3.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/iperf3-3.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3-devel" release="1.u4" version="3.18">
					<filename>iperf3-devel-3.18-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/iperf3-devel-3.18-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="iperf3-help" release="1.u4" version="3.18">
					<filename>iperf3-help-3.18-1.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/iperf3-help-3.18-1.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2120</id>
		<title>An update for corosync is now available for 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30472&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30472" id="CVE-2025-30472" title="CVE-2025-30472" type="cve"></reference>
		</references>
		<description>CVE-2025-30472:Corosync through 3.1.9, if encryption is disabled or the attacker knows the encryption key, has a stack-based buffer overflow in orf_token_endian_convert in exec/totemsrp.c via a large UDP packet.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="corosynclib" release="2.u1" version="3.1.5">
					<filename>corosynclib-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/corosynclib-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosync" release="2.u1" version="3.1.5">
					<filename>corosync-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/corosync-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosynclib-devel" release="2.u1" version="3.1.5">
					<filename>corosynclib-devel-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/corosynclib-devel-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosync-vqsim" release="2.u1" version="3.1.5">
					<filename>corosync-vqsim-3.1.5-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/corosync-vqsim-3.1.5-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosync" release="2.u1" version="3.1.5">
					<filename>corosync-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/corosync-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosynclib" release="2.u1" version="3.1.5">
					<filename>corosynclib-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/corosynclib-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosynclib-devel" release="2.u1" version="3.1.5">
					<filename>corosynclib-devel-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/corosynclib-devel-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosync-vqsim" release="2.u1" version="3.1.5">
					<filename>corosync-vqsim-3.1.5-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/corosync-vqsim-3.1.5-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2121</id>
		<title>An update for abseil-cpp is now available for 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0838&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0838" id="CVE-2025-0838" title="CVE-2025-0838" type="cve"></reference>
		</references>
		<description>CVE-2025-0838:There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container&#39;s backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="abseil-cpp" release="6.u1" version="20220623.1">
					<filename>abseil-cpp-20220623.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/abseil-cpp-20220623.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="abseil-cpp-devel" release="6.u1" version="20220623.1">
					<filename>abseil-cpp-devel-20220623.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/abseil-cpp-devel-20220623.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="abseil-cpp" release="6.u1" version="20220623.1">
					<filename>abseil-cpp-20220623.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/abseil-cpp-20220623.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="abseil-cpp-devel" release="6.u1" version="20220623.1">
					<filename>abseil-cpp-devel-20220623.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/abseil-cpp-devel-20220623.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2122</id>
		<title>An update for bind is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11187" id="CVE-2024-11187" title="CVE-2024-11187" type="cve"></reference>
		</references>
		<description>CVE-2024-11187:It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-pkcs11-libs-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="24.u10" version="9.16.23">
					<filename>bind-utils-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-utils-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-pkcs11-devel-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="24.u10" version="9.16.23">
					<filename>bind-devel-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-devel-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="24.u10" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-dnssec-utils-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-pkcs11-utils-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="24.u10" version="9.16.23">
					<filename>bind-libs-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-libs-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-pkcs11-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="24.u10" version="9.16.23">
					<filename>bind-chroot-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-chroot-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="24.u10" version="9.16.23">
					<filename>bind-9.16.23-24.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bind-9.16.23-24.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="24.u10" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-24.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-dnssec-doc-9.16.23-24.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="24.u10" version="9.16.23">
					<filename>bind-license-9.16.23-24.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-license-9.16.23-24.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="24.u10" version="9.16.23">
					<filename>python3-bind-9.16.23-24.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-bind-9.16.23-24.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="24.u10" version="9.16.23">
					<filename>bind-libs-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-libs-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="24.u10" version="9.16.23">
					<filename>bind-chroot-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-chroot-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="24.u10" version="9.16.23">
					<filename>bind-devel-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-devel-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="24.u10" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-dnssec-utils-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-pkcs11-libs-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="24.u10" version="9.16.23">
					<filename>bind-utils-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-utils-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind" release="24.u10" version="9.16.23">
					<filename>bind-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-pkcs11-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-pkcs11-devel-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="24.u10" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-24.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bind-pkcs11-utils-9.16.23-24.u10.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2123</id>
		<title>An update for mariadb is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21096" id="CVE-2024-21096" title="CVE-2024-21096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-22084" id="CVE-2023-22084" title="CVE-2023-22084" type="cve"></reference>
		</references>
		<description>CVE-2024-21096:Vulnerability in the MySQL Server product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.36 and prior and  8.3.0 and prior. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).&#xA;CVE-2023-22084:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 5.7.43 and prior, 8.0.34 and prior and  8.1.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="aarch64" epoch="4" name="mariadb-gssapi-server" release="1" version="10.5.25">
					<filename>mariadb-gssapi-server-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-gssapi-server-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-rocksdb-engine" release="1" version="10.5.25">
					<filename>mariadb-rocksdb-engine-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-rocksdb-engine-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server" release="1" version="10.5.25">
					<filename>mariadb-server-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-server-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-backup" release="1" version="10.5.25">
					<filename>mariadb-backup-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-backup-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-embedded-devel" release="1" version="10.5.25">
					<filename>mariadb-embedded-devel-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-embedded-devel-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server-galera" release="1" version="10.5.25">
					<filename>mariadb-server-galera-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-server-galera-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-oqgraph-engine" release="1" version="10.5.25">
					<filename>mariadb-oqgraph-engine-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-oqgraph-engine-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server-utils" release="1" version="10.5.25">
					<filename>mariadb-server-utils-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-server-utils-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb" release="1" version="10.5.25">
					<filename>mariadb-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-devel" release="1" version="10.5.25">
					<filename>mariadb-devel-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-devel-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-errmsg" release="1" version="10.5.25">
					<filename>mariadb-errmsg-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-errmsg-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-embedded" release="1" version="10.5.25">
					<filename>mariadb-embedded-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-embedded-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-common" release="1" version="10.5.25">
					<filename>mariadb-common-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-common-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-test" release="1" version="10.5.25">
					<filename>mariadb-test-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-test-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-config" release="1" version="10.5.25">
					<filename>mariadb-config-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-config-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-pam" release="1" version="10.5.25">
					<filename>mariadb-pam-10.5.25-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/mariadb-pam-10.5.25-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-embedded" release="1" version="10.5.25">
					<filename>mariadb-embedded-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-embedded-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-oqgraph-engine" release="1" version="10.5.25">
					<filename>mariadb-oqgraph-engine-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-oqgraph-engine-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-pam" release="1" version="10.5.25">
					<filename>mariadb-pam-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-pam-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-test" release="1" version="10.5.25">
					<filename>mariadb-test-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-test-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-gssapi-server" release="1" version="10.5.25">
					<filename>mariadb-gssapi-server-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-gssapi-server-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-errmsg" release="1" version="10.5.25">
					<filename>mariadb-errmsg-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-errmsg-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server" release="1" version="10.5.25">
					<filename>mariadb-server-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-server-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-common" release="1" version="10.5.25">
					<filename>mariadb-common-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-common-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb" release="1" version="10.5.25">
					<filename>mariadb-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-backup" release="1" version="10.5.25">
					<filename>mariadb-backup-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-backup-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-config" release="1" version="10.5.25">
					<filename>mariadb-config-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-config-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-embedded-devel" release="1" version="10.5.25">
					<filename>mariadb-embedded-devel-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-embedded-devel-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server-galera" release="1" version="10.5.25">
					<filename>mariadb-server-galera-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-server-galera-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-devel" release="1" version="10.5.25">
					<filename>mariadb-devel-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-devel-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server-utils" release="1" version="10.5.25">
					<filename>mariadb-server-utils-10.5.25-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/mariadb-server-utils-10.5.25-1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2124</id>
		<title>An update for tuned is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52336&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52336" id="CVE-2024-52336" title="CVE-2024-52336" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52337&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52337" id="CVE-2024-52337" title="CVE-2024-52337" type="cve"></reference>
		</references>
		<description>CVE-2024-52336:A script injection vulnerability was identified in the Tuned package. The `instance_create()` D-Bus function can be called by locally logged-in users without authentication. This flaw allows a local non-privileged user to execute a D-Bus call with `script_pre` or `script_post` options that permit arbitrary scripts with their absolute paths to be passed. These user or attacker-controlled executable scripts or programs could then be executed by Tuned with root privileges that could allow attackers to local privilege escalation.&#xA;CVE-2024-52337:A log spoofing flaw was found in the Tuned package due to improper sanitization of some API arguments. This flaw allows an attacker to pass a controlled sequence of characters; newlines can be inserted into the log. Instead of the &#39;evil&#39; the attacker could mimic a valid TuneD log line and trick the administrator. The quotes &#39;&#39; are usually used in TuneD logs citing raw user input, so there will always be the &#39; character ending the spoofed input, and the administrator can easily overlook this. This logged string is later used in logging and in the output of utilities, for example, `tuned-adm get_instances` or other third-party programs that use Tuned&#39;s D-Bus interface for such operations.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="noarch" epoch="0" name="tuned-help" release="1.u2" version="2.24.1">
					<filename>tuned-help-2.24.1-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/tuned-help-2.24.1-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tuned-profiles-devel" release="1.u2" version="2.24.1">
					<filename>tuned-profiles-devel-2.24.1-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/tuned-profiles-devel-2.24.1-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tuned" release="1.u2" version="2.24.1">
					<filename>tuned-2.24.1-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/tuned-2.24.1-1.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2125</id>
		<title>An update for elfutils is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1352&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1352" id="CVE-2025-1352" title="CVE-2025-1352" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1372&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1372" id="CVE-2025-1372" title="CVE-2025-1372" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1376&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1376" id="CVE-2025-1376" title="CVE-2025-1376" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1377&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1377" id="CVE-2025-1377" title="CVE-2025-1377" type="cve"></reference>
		</references>
		<description>CVE-2025-1352:A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-1372:A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-1376:A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-1377:A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="elfutils" release="20.u1" version="0.185">
					<filename>elfutils-0.185-20.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/elfutils-0.185-20.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="elfutils-devel" release="20.u1" version="0.185">
					<filename>elfutils-devel-0.185-20.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/elfutils-devel-0.185-20.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="elfutils-extra" release="20.u1" version="0.185">
					<filename>elfutils-extra-0.185-20.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/elfutils-extra-0.185-20.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="elfutils-help" release="20.u1" version="0.185">
					<filename>elfutils-help-0.185-20.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/elfutils-help-0.185-20.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="elfutils-help" release="20.u1" version="0.185">
					<filename>elfutils-help-0.185-20.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/elfutils-help-0.185-20.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="elfutils" release="20.u1" version="0.185">
					<filename>elfutils-0.185-20.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/elfutils-0.185-20.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="elfutils-devel" release="20.u1" version="0.185">
					<filename>elfutils-devel-0.185-20.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/elfutils-devel-0.185-20.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="elfutils-extra" release="20.u1" version="0.185">
					<filename>elfutils-extra-0.185-20.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/elfutils-extra-0.185-20.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2126</id>
		<title>An update for openssh is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26465&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26465" id="CVE-2025-26465" title="CVE-2025-26465" type="cve"></reference>
		</references>
		<description>CVE-2025-26465:A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client&#39;s memory resource first, turning the attack complexity high.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="noarch" epoch="0" name="openssh-help" release="34.u26" version="8.8p1">
					<filename>openssh-help-8.8p1-34.u26.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/openssh-help-8.8p1-34.u26.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="34.u26" version="8.8p1">
					<filename>openssh-server-8.8p1-34.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/openssh-server-8.8p1-34.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="34.u26" version="8.8p1">
					<filename>openssh-askpass-8.8p1-34.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/openssh-askpass-8.8p1-34.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="34.u26" version="8.8p1">
					<filename>openssh-clients-8.8p1-34.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/openssh-clients-8.8p1-34.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh" release="34.u26" version="8.8p1">
					<filename>openssh-8.8p1-34.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/openssh-8.8p1-34.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="34.u26" version="8.8p1">
					<filename>openssh-keycat-8.8p1-34.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/openssh-keycat-8.8p1-34.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.34.u26" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.34.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/pam_ssh_agent_auth-0.10.4-4.34.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="34.u26" version="8.8p1">
					<filename>openssh-keycat-8.8p1-34.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/openssh-keycat-8.8p1-34.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.34.u26" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.34.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/pam_ssh_agent_auth-0.10.4-4.34.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="34.u26" version="8.8p1">
					<filename>openssh-8.8p1-34.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/openssh-8.8p1-34.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="34.u26" version="8.8p1">
					<filename>openssh-askpass-8.8p1-34.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/openssh-askpass-8.8p1-34.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="34.u26" version="8.8p1">
					<filename>openssh-server-8.8p1-34.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/openssh-server-8.8p1-34.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="34.u26" version="8.8p1">
					<filename>openssh-clients-8.8p1-34.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/openssh-clients-8.8p1-34.u26.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2127</id>
		<title>An update for rubygem-rack is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-25184&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-25184" id="CVE-2025-25184" title="CVE-2025-25184" type="cve"></reference>
		</references>
		<description>CVE-2025-25184:Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.11, 3.0.12, and 3.1.10, Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs. When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env[&#39;REMOTE_USER&#39;] and later be used by Rack::CommonLogger for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile. Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files. Versions 2.2.11, 3.0.12, and 3.1.10 contain a fix.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="noarch" epoch="1" name="rubygem-rack" release="8.u4" version="2.2.3.1">
					<filename>rubygem-rack-2.2.3.1-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/rubygem-rack-2.2.3.1-8.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-rack-help" release="8.u4" version="2.2.3.1">
					<filename>rubygem-rack-help-2.2.3.1-8.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/rubygem-rack-help-2.2.3.1-8.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2128</id>
		<title>An update for ghostscript is now available for 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27830&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27830" id="CVE-2025-27830" title="CVE-2025-27830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27832&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27832" id="CVE-2025-27832" title="CVE-2025-27832" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27834&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27834" id="CVE-2025-27834" title="CVE-2025-27834" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27835&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27835" id="CVE-2025-27835" title="CVE-2025-27835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27836&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27836" id="CVE-2025-27836" title="CVE-2025-27836" type="cve"></reference>
		</references>
		<description>CVE-2025-27830:An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs during serialization of DollarBlend in a font, for base/write_t1.c and psi/zfapi.c.&#xA;CVE-2025-27832:An issue was discovered in Artifex Ghostscript before 10.05.0. The NPDL device has a Compression buffer overflow for contrib/japanese/gdevnpdl.c.&#xA;CVE-2025-27834:An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs via an oversized Type 4 function in a PDF document to pdf/pdf_func.c.&#xA;CVE-2025-27835:An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs when converting glyphs to Unicode in psi/zbfont.c.&#xA;CVE-2025-27836:An issue was discovered in Artifex Ghostscript before 10.05.0. The BJ10V device has a Print buffer overflow in contrib/japanese/gdev10v.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="18.u15" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-18.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/ghostscript-devel-9.55.0-18.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript" release="18.u15" version="9.55.0">
					<filename>ghostscript-9.55.0-18.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/ghostscript-9.55.0-18.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="18.u15" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-18.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/ghostscript-tools-dvipdf-9.55.0-18.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="18.u15" version="9.55.0">
					<filename>ghostscript-help-9.55.0-18.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/ghostscript-help-9.55.0-18.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="18.u15" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-18.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/ghostscript-tools-dvipdf-9.55.0-18.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="18.u15" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-18.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/ghostscript-devel-9.55.0-18.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="18.u15" version="9.55.0">
					<filename>ghostscript-9.55.0-18.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/ghostscript-9.55.0-18.u15.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2129</id>
		<title>An update for vim is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1215&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1215" id="CVE-2025-1215" title="CVE-2025-1215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26603&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26603" id="CVE-2025-26603" title="CVE-2025-26603" type="cve"></reference>
		</references>
		<description>CVE-2025-1215:A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.&#xA;CVE-2025-26603:Vim is a greatly improved version of the good old UNIX editor Vi. Vim allows to redirect screen messages using the `:redir` ex command to register, variables and files. It also allows to show the contents of registers using the `:registers` or `:display` ex command. When redirecting the output of `:display` to a register, Vim will free the register content before storing the new content in the register. Now when redirecting the `:display` command to a register that is being displayed, Vim will free the content while shortly afterwards trying to access it, which leads to a use-after-free. Vim pre 9.1.1115 checks in the ex_display() function, that it does not try to redirect to a register while displaying this register at the same time. However this check is not complete, and so Vim does not check the `+` and `*` registers (which typically donate the X11/clipboard registers, and when a clipboard connection is not possible will fall back to use register 0 instead. In Patch 9.1.1115 Vim will therefore skip outputting to register zero when trying to redirect to the clipboard registers `*` or `+`. Users are advised to upgrade. There are no known workarounds for this vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="32.u19" version="9.0">
					<filename>vim-filesystem-9.0-32.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/vim-filesystem-9.0-32.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="32.u19" version="9.0">
					<filename>vim-X11-9.0-32.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/vim-X11-9.0-32.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-common" release="32.u19" version="9.0">
					<filename>vim-common-9.0-32.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/vim-common-9.0-32.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="32.u19" version="9.0">
					<filename>vim-enhanced-9.0-32.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/vim-enhanced-9.0-32.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="32.u19" version="9.0">
					<filename>vim-minimal-9.0-32.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/vim-minimal-9.0-32.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="32.u19" version="9.0">
					<filename>vim-minimal-9.0-32.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/vim-minimal-9.0-32.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="32.u19" version="9.0">
					<filename>vim-enhanced-9.0-32.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/vim-enhanced-9.0-32.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="32.u19" version="9.0">
					<filename>vim-X11-9.0-32.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/vim-X11-9.0-32.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="32.u19" version="9.0">
					<filename>vim-common-9.0-32.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/vim-common-9.0-32.u19.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2130</id>
		<title>An update for python3 is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0938&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0938" id="CVE-2025-0938" title="CVE-2025-0938" type="cve"></reference>
		</references>
		<description>CVE-2025-0938:The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn&#39;t valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="aarch64" epoch="0" name="python3-debug" release="41.u20" version="3.9.9">
					<filename>python3-debug-3.9.9-41.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/python3-debug-3.9.9-41.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="41.u20" version="3.9.9">
					<filename>python3-3.9.9-41.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/python3-3.9.9-41.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="41.u20" version="3.9.9">
					<filename>python3-devel-3.9.9-41.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/python3-devel-3.9.9-41.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="41.u20" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-41.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/python3-unversioned-command-3.9.9-41.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="41.u20" version="3.9.9">
					<filename>python3-help-3.9.9-41.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-help-3.9.9-41.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="41.u20" version="3.9.9">
					<filename>python3-debug-3.9.9-41.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-debug-3.9.9-41.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="41.u20" version="3.9.9">
					<filename>python3-devel-3.9.9-41.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-devel-3.9.9-41.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3" release="41.u20" version="3.9.9">
					<filename>python3-3.9.9-41.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-3.9.9-41.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="41.u20" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-41.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-unversioned-command-3.9.9-41.u20.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2131</id>
		<title>An update for libtasn1 is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12133&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12133" id="CVE-2024-12133" title="CVE-2024-12133" type="cve"></reference>
		</references>
		<description>CVE-2024-12133:A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="libtasn1-devel" release="2" version="4.19.0">
					<filename>libtasn1-devel-4.19.0-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/libtasn1-devel-4.19.0-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtasn1" release="2" version="4.19.0">
					<filename>libtasn1-4.19.0-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/libtasn1-4.19.0-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtasn1-help" release="2" version="4.19.0">
					<filename>libtasn1-help-4.19.0-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/libtasn1-help-4.19.0-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtasn1" release="2" version="4.19.0">
					<filename>libtasn1-4.19.0-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/libtasn1-4.19.0-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtasn1-devel" release="2" version="4.19.0">
					<filename>libtasn1-devel-4.19.0-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/libtasn1-devel-4.19.0-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2132</id>
		<title>An update for kernel is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49856" id="CVE-2024-49856" title="CVE-2024-49856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47730&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47730" id="CVE-2024-47730" title="CVE-2024-47730" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50001&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50001" id="CVE-2024-50001" title="CVE-2024-50001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49002&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49002" id="CVE-2022-49002" title="CVE-2022-49002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49907&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49907" id="CVE-2024-49907" title="CVE-2024-49907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50188&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50188" id="CVE-2024-50188" title="CVE-2024-50188" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50287&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50287" id="CVE-2024-50287" title="CVE-2024-50287" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50264&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50264" id="CVE-2024-50264" title="CVE-2024-50264" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50233&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50233" id="CVE-2024-50233" title="CVE-2024-50233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50089&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50089" id="CVE-2024-50089" title="CVE-2024-50089" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53147&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53147" id="CVE-2024-53147" title="CVE-2024-53147" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53155&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53155" id="CVE-2024-53155" title="CVE-2024-53155" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53161" id="CVE-2024-53161" title="CVE-2024-53161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53158" id="CVE-2024-53158" title="CVE-2024-53158" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56548&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56548" id="CVE-2024-56548" title="CVE-2024-56548" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49034" id="CVE-2022-49034" title="CVE-2022-49034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53224&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53224" id="CVE-2024-53224" title="CVE-2024-53224" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56538&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56538" id="CVE-2024-56538" title="CVE-2024-56538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53239&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53239" id="CVE-2024-53239" title="CVE-2024-53239" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53165&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53165" id="CVE-2024-53165" title="CVE-2024-53165" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53201&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53201" id="CVE-2024-53201" title="CVE-2024-53201" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53194&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53194" id="CVE-2024-53194" title="CVE-2024-53194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53227&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53227" id="CVE-2024-53227" title="CVE-2024-53227" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53197&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53197" id="CVE-2024-53197" title="CVE-2024-53197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53221&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53221" id="CVE-2024-53221" title="CVE-2024-53221" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53187" id="CVE-2024-53187" title="CVE-2024-53187" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53185&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53185" id="CVE-2024-53185" title="CVE-2024-53185" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53219&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53219" id="CVE-2024-53219" title="CVE-2024-53219" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53171" id="CVE-2024-53171" title="CVE-2024-53171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56672&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56672" id="CVE-2024-56672" title="CVE-2024-56672" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56562&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56562" id="CVE-2024-56562" title="CVE-2024-56562" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56567&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56567" id="CVE-2024-56567" title="CVE-2024-56567" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56569&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56569" id="CVE-2024-56569" title="CVE-2024-56569" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56570&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56570" id="CVE-2024-56570" title="CVE-2024-56570" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56630&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56630" id="CVE-2024-56630" title="CVE-2024-56630" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56631&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56631" id="CVE-2024-56631" title="CVE-2024-56631" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56604&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56604" id="CVE-2024-56604" title="CVE-2024-56604" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56605&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56605" id="CVE-2024-56605" title="CVE-2024-56605" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56619&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56619" id="CVE-2024-56619" title="CVE-2024-56619" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56634&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56634" id="CVE-2024-56634" title="CVE-2024-56634" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56594&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56594" id="CVE-2024-56594" title="CVE-2024-56594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56608&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56608" id="CVE-2024-56608" title="CVE-2024-56608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56581&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56581" id="CVE-2024-56581" title="CVE-2024-56581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56596&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56596" id="CVE-2024-56596" title="CVE-2024-56596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56583&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56583" id="CVE-2024-56583" title="CVE-2024-56583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56598&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56598" id="CVE-2024-56598" title="CVE-2024-56598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56584&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56584" id="CVE-2024-56584" title="CVE-2024-56584" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56627&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56627" id="CVE-2024-56627" title="CVE-2024-56627" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56586&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56586" id="CVE-2024-56586" title="CVE-2024-56586" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56615" id="CVE-2024-56615" title="CVE-2024-56615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56629&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56629" id="CVE-2024-56629" title="CVE-2024-56629" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56691" id="CVE-2024-56691" title="CVE-2024-56691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56700&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56700" id="CVE-2024-56700" title="CVE-2024-56700" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56692" id="CVE-2024-56692" title="CVE-2024-56692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56681&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56681" id="CVE-2024-56681" title="CVE-2024-56681" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56709&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56709" id="CVE-2024-56709" title="CVE-2024-56709" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56748&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56748" id="CVE-2024-56748" title="CVE-2024-56748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56739&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56739" id="CVE-2024-56739" title="CVE-2024-56739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56722&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56722" id="CVE-2024-56722" title="CVE-2024-56722" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56747&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56747" id="CVE-2024-56747" title="CVE-2024-56747" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56756&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56756" id="CVE-2024-56756" title="CVE-2024-56756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49035" id="CVE-2022-49035" title="CVE-2022-49035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56763&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56763" id="CVE-2024-56763" title="CVE-2024-56763" type="cve"></reference>
		</references>
		<description>CVE-2024-49856:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/sgx: Fix deadlock in SGX NUMA node search&#xA;&#xA;When the current node doesn&#39;t have an EPC section configured by firmware&#xA;and all other EPC sections are used up, CPU can get stuck inside the&#xA;while loop that looks for an available EPC page from remote nodes&#xA;indefinitely, leading to a soft lockup. Note how nid_of_current will&#xA;never be equal to nid in that while loop because nid_of_current is not&#xA;set in sgx_numa_mask.&#xA;&#xA;Also worth mentioning is that it&#39;s perfectly fine for the firmware not&#xA;to setup an EPC section on a node. While setting up an EPC section on&#xA;each node can enhance performance, it is not a requirement for&#xA;functionality.&#xA;&#xA;Rework the loop to start and end on *a* node that has SGX memory. This&#xA;avoids the deadlock looking for the current SGX-lacking node to show up&#xA;in the loop when it never will.&#xA;CVE-2024-47730:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: hisilicon/qm - inject error before stopping queue&#xA;&#xA;The master ooo cannot be completely closed when the&#xA;accelerator core reports memory error. Therefore, the driver&#xA;needs to inject the qm error to close the master ooo. Currently,&#xA;the qm error is injected after stopping queue, memory may be&#xA;released immediately after stopping queue, causing the device to&#xA;access the released memory. Therefore, error is injected to close master&#xA;ooo before stopping queue to ensure that the device does not access&#xA;the released memory.&#xA;CVE-2024-50001:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mlx5: Fix error path in multi-packet WQE transmit&#xA;&#xA;Remove the erroneous unmap in case no DMA mapping was established&#xA;&#xA;The multi-packet WQE transmit code attempts to obtain a DMA mapping for&#xA;the skb. This could fail, e.g. under memory pressure, when the IOMMU&#xA;driver just can&#39;t allocate more memory for page tables. While the code&#xA;tries to handle this in the path below the err_unmap label it erroneously&#xA;unmaps one entry from the sq&#39;s FIFO list of active mappings. Since the&#xA;current map attempt failed this unmap is removing some random DMA mapping&#xA;that might still be required. If the PCI function now presents that IOVA,&#xA;the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI&#xA;function in error state.&#xA;&#xA;The erroneous behavior was seen in a stress-test environment that created&#xA;memory pressure.&#xA;CVE-2022-49002:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()&#xA;&#xA;for_each_pci_dev() is implemented by pci_get_device(). The comment of&#xA;pci_get_device() says that it will increase the reference count for the&#xA;returned pci_dev and also decrease the reference count for the input&#xA;pci_dev @from if it is not NULL.&#xA;&#xA;If we break for_each_pci_dev() loop with pdev not NULL, we need to call&#xA;pci_dev_put() to decrease the reference count. Add the missing&#xA;pci_dev_put() for the error path to avoid reference count leak.&#xA;CVE-2024-49907:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Check null pointers before using dc-&gt;clk_mgr&#xA;&#xA;[WHY &amp; HOW]&#xA;dc-&gt;clk_mgr is null checked previously in the same function, indicating&#xA;it might be null.&#xA;&#xA;Passing &#34;dc&#34; to &#34;dc-&gt;hwss.apply_idle_power_optimizations&#34;, which&#xA;dereferences null &#34;dc-&gt;clk_mgr&#34;. (The function pointer resolves to&#xA;&#34;dcn35_apply_idle_power_optimizations&#34;.)&#xA;&#xA;This fixes 1 FORWARD_NULL issue reported by Coverity.&#xA;CVE-2024-50188:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: phy: dp83869: fix memory corruption when enabling fiber&#xA;&#xA;When configuring the fiber port, the DP83869 PHY driver incorrectly&#xA;calls linkmode_set_bit() with a bit mask (1 &lt;&lt; 10) rather than a bit&#xA;number (10). This corrupts some other memory location -- in case of&#xA;arm64 the priv pointer in the same structure.&#xA;&#xA;Since the advertising flags are updated from supported at the end of the&#xA;function the incorrect line isn&#39;t needed at all and can be removed.&#xA;CVE-2024-50287:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: v4l2-tpg: prevent the risk of a division by zero&#xA;&#xA;As reported by Coverity, the logic at tpg_precalculate_line()&#xA;blindly rescales the buffer even when scaled_witdh is equal to&#xA;zero. If this ever happens, this will cause a division by zero.&#xA;&#xA;Instead, add a WARN_ON_ONCE() to trigger such cases and return&#xA;without doing any precalculation.&#xA;CVE-2024-50264:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans&#xA;&#xA;During loopback communication, a dangling pointer can be created in&#xA;vsk-&gt;trans, potentially leading to a Use-After-Free condition.  This&#xA;issue is resolved by initializing vsk-&gt;trans to NULL.&#xA;CVE-2024-50233:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()&#xA;&#xA;In the ad9832_write_frequency() function, clk_get_rate() might return 0.&#xA;This can lead to a division by zero when calling ad9832_calc_freqreg().&#xA;The check if (fout &gt; (clk_get_rate(st-&gt;mclk) / 2)) does not protect&#xA;against the case when fout is 0. The ad9832_write_frequency() function&#xA;is called from ad9832_write(), and fout is derived from a text buffer,&#xA;which can contain any value.&#xA;CVE-2024-50089:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-53147:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;exfat: fix out-of-bounds access of directory entries&#xA;&#xA;In the case of the directory size is greater than or equal to&#xA;the cluster size, if start_clu becomes an EOF cluster(an invalid&#xA;cluster) due to file system corruption, then the directory entry&#xA;where ei-&gt;hint_femp.eidx hint is outside the directory, resulting&#xA;in an out-of-bounds access, which may cause further file system&#xA;corruption.&#xA;&#xA;This commit adds a check for start_clu, if it is an invalid cluster,&#xA;the file or directory will be treated as empty.&#xA;CVE-2024-53155:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: fix uninitialized value in ocfs2_file_read_iter()&#xA;&#xA;Syzbot has reported the following KMSAN splat:&#xA;&#xA;BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80&#xA; ocfs2_file_read_iter+0x9a4/0xf80&#xA; __io_read+0x8d4/0x20f0&#xA; io_read+0x3e/0xf0&#xA; io_issue_sqe+0x42b/0x22c0&#xA; io_wq_submit_work+0xaf9/0xdc0&#xA; io_worker_handle_work+0xd13/0x2110&#xA; io_wq_worker+0x447/0x1410&#xA; ret_from_fork+0x6f/0x90&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;Uninit was created at:&#xA; __alloc_pages_noprof+0x9a7/0xe00&#xA; alloc_pages_mpol_noprof+0x299/0x990&#xA; alloc_pages_noprof+0x1bf/0x1e0&#xA; allocate_slab+0x33a/0x1250&#xA; ___slab_alloc+0x12ef/0x35e0&#xA; kmem_cache_alloc_bulk_noprof+0x486/0x1330&#xA; __io_alloc_req_refill+0x84/0x560&#xA; io_submit_sqes+0x172f/0x2f30&#xA; __se_sys_io_uring_enter+0x406/0x41c0&#xA; __x64_sys_io_uring_enter+0x11f/0x1a0&#xA; x64_sys_call+0x2b54/0x3ba0&#xA; do_syscall_64+0xcd/0x1e0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Since an instance of &#39;struct kiocb&#39; may be passed from the block layer&#xA;with &#39;private&#39; field uninitialized, introduce &#39;ocfs2_iocb_init_rw_locked()&#39;&#xA;and use it from where &#39;ocfs2_dio_end_io()&#39; might take care, i.e. in&#xA;&#39;ocfs2_file_read_iter()&#39; and &#39;ocfs2_file_write_iter()&#39;.&#xA;CVE-2024-53161:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;EDAC/bluefield: Fix potential integer overflow&#xA;&#xA;The 64-bit argument for the &#34;get DIMM info&#34; SMC call consists of mem_ctrl_idx&#xA;left-shifted 16 bits and OR-ed with DIMM index.  With mem_ctrl_idx defined as&#xA;32-bits wide the left-shift operation truncates the upper 16 bits of&#xA;information during the calculation of the SMC argument.&#xA;&#xA;The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any&#xA;potential integer overflow, i.e. loss of data from upper 16 bits.&#xA;CVE-2024-53158:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()&#xA;&#xA;This loop is supposed to break if the frequency returned from&#xA;clk_round_rate() is the same as on the previous iteration.  However,&#xA;that check doesn&#39;t make sense on the first iteration through the loop.&#xA;It leads to reading before the start of these-&gt;clk_perf_tbl[] array.&#xA;CVE-2024-56548:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hfsplus: don&#39;t query the device logical block size multiple times&#xA;&#xA;Devices block sizes may change. One of these cases is a loop device by&#xA;using ioctl LOOP_SET_BLOCK_SIZE.&#xA;&#xA;While this may cause other issues like IO being rejected, in the case of&#xA;hfsplus, it will allocate a block by using that size and potentially write&#xA;out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the&#xA;latter function reads a different io_size.&#xA;&#xA;Using a new min_io_size initally set to sb_min_blocksize works for the&#xA;purposes of the original fix, since it will be set to the max between&#xA;HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the&#xA;max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not&#xA;initialized.&#xA;&#xA;Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024&#xA;and 4096.&#xA;&#xA;The produced KASAN report before the fix looks like this:&#xA;&#xA;[  419.944641] ==================================================================&#xA;[  419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a&#xA;[  419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678&#xA;[  419.947612]&#xA;[  419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84&#xA;[  419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014&#xA;[  419.950035] Call Trace:&#xA;[  419.950384]  &lt;TASK&gt;&#xA;[  419.950676]  dump_stack_lvl+0x57/0x78&#xA;[  419.951212]  ? hfsplus_read_wrapper+0x659/0xa0a&#xA;[  419.951830]  print_report+0x14c/0x49e&#xA;[  419.952361]  ? __virt_addr_valid+0x267/0x278&#xA;[  419.952979]  ? kmem_cache_debug_flags+0xc/0x1d&#xA;[  419.953561]  ? hfsplus_read_wrapper+0x659/0xa0a&#xA;[  419.954231]  kasan_report+0x89/0xb0&#xA;[  419.954748]  ? hfsplus_read_wrapper+0x659/0xa0a&#xA;[  419.955367]  hfsplus_read_wrapper+0x659/0xa0a&#xA;[  419.955948]  ? __pfx_hfsplus_read_wrapper+0x10/0x10&#xA;[  419.956618]  ? do_raw_spin_unlock+0x59/0x1a9&#xA;[  419.957214]  ? _raw_spin_unlock+0x1a/0x2e&#xA;[  419.957772]  hfsplus_fill_super+0x348/0x1590&#xA;[  419.958355]  ? hlock_class+0x4c/0x109&#xA;[  419.958867]  ? __pfx_hfsplus_fill_super+0x10/0x10&#xA;[  419.959499]  ? __pfx_string+0x10/0x10&#xA;[  419.960006]  ? lock_acquire+0x3e2/0x454&#xA;[  419.960532]  ? bdev_name.constprop.0+0xce/0x243&#xA;[  419.961129]  ? __pfx_bdev_name.constprop.0+0x10/0x10&#xA;[  419.961799]  ? pointer+0x3f0/0x62f&#xA;[  419.962277]  ? __pfx_pointer+0x10/0x10&#xA;[  419.962761]  ? vsnprintf+0x6c4/0xfba&#xA;[  419.963178]  ? __pfx_vsnprintf+0x10/0x10&#xA;[  419.963621]  ? setup_bdev_super+0x376/0x3b3&#xA;[  419.964029]  ? snprintf+0x9d/0xd2&#xA;[  419.964344]  ? __pfx_snprintf+0x10/0x10&#xA;[  419.964675]  ? lock_acquired+0x45c/0x5e9&#xA;[  419.965016]  ? set_blocksize+0x139/0x1c1&#xA;[  419.965381]  ? sb_set_blocksize+0x6d/0xae&#xA;[  419.965742]  ? __pfx_hfsplus_fill_super+0x10/0x10&#xA;[  419.966179]  mount_bdev+0x12f/0x1bf&#xA;[  419.966512]  ? __pfx_mount_bdev+0x10/0x10&#xA;[  419.966886]  ? vfs_parse_fs_string+0xce/0x111&#xA;[  419.967293]  ? __pfx_vfs_parse_fs_string+0x10/0x10&#xA;[  419.967702]  ? __pfx_hfsplus_mount+0x10/0x10&#xA;[  419.968073]  legacy_get_tree+0x104/0x178&#xA;[  419.968414]  vfs_get_tree+0x86/0x296&#xA;[  419.968751]  path_mount+0xba3/0xd0b&#xA;[  419.969157]  ? __pfx_path_mount+0x10/0x10&#xA;[  419.969594]  ? kmem_cache_free+0x1e2/0x260&#xA;[  419.970311]  do_mount+0x99/0xe0&#xA;[  419.970630]  ? __pfx_do_mount+0x10/0x10&#xA;[  419.971008]  __do_sys_mount+0x199/0x1c9&#xA;[  419.971397]  do_syscall_64+0xd0/0x135&#xA;[  419.971761]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[  419.972233] RIP: 0033:0x7c3cb812972e&#xA;[  419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48&#xA;[  419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5&#xA;[  419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e&#xA;[  419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:&#xA;---truncated---&#xA;CVE-2022-49034:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK&#xA;&#xA;When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected,&#xA;cpu_max_bits_warn() generates a runtime warning similar as below when&#xA;showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)&#xA;instead of NR_CPUS to iterate CPUs.&#xA;&#xA;[    3.052463] ------------[ cut here ]------------&#xA;[    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0&#xA;[    3.070072] Modules linked in: efivarfs autofs4&#xA;[    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052&#xA;[    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000&#xA;[    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430&#xA;[    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff&#xA;[    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890&#xA;[    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa&#xA;[    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000&#xA;[    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000&#xA;[    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000&#xA;[    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286&#xA;[    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c&#xA;[    3.195868]         ...&#xA;[    3.199917] Call Trace:&#xA;[    3.203941] [&lt;90000000002086d8&gt;] show_stack+0x38/0x14c&#xA;[    3.210666] [&lt;9000000000cf846c&gt;] dump_stack_lvl+0x60/0x88&#xA;[    3.217625] [&lt;900000000023d268&gt;] __warn+0xd0/0x100&#xA;[    3.223958] [&lt;9000000000cf3c90&gt;] warn_slowpath_fmt+0x7c/0xcc&#xA;[    3.231150] [&lt;9000000000210220&gt;] show_cpuinfo+0x5e8/0x5f0&#xA;[    3.238080] [&lt;90000000004f578c&gt;] seq_read_iter+0x354/0x4b4&#xA;[    3.245098] [&lt;90000000004c2e90&gt;] new_sync_read+0x17c/0x1c4&#xA;[    3.252114] [&lt;90000000004c5174&gt;] vfs_read+0x138/0x1d0&#xA;[    3.258694] [&lt;90000000004c55f8&gt;] ksys_read+0x70/0x100&#xA;[    3.265265] [&lt;9000000000cfde9c&gt;] do_syscall+0x7c/0x94&#xA;[    3.271820] [&lt;9000000000202fe4&gt;] handle_syscall+0xc4/0x160&#xA;[    3.281824] ---[ end trace 8b484262b4b8c24c ]---&#xA;CVE-2024-53224:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/mlx5: Move events notifier registration to be after device registration&#xA;&#xA;Move pkey change work initialization and cleanup from device resources&#xA;stage to notifier stage, since this is the stage which handles this work&#xA;events.&#xA;&#xA;Fix a race between the device deregistration and pkey change work by moving&#xA;MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to&#xA;ensure that the notifier is deregistered before the device during cleanup.&#xA;Which ensures there are no works that are being executed after the&#xA;device has already unregistered which can cause the panic below.&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1&#xA;Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023&#xA;Workqueue: events pkey_change_handler [mlx5_ib]&#xA;RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]&#xA;Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 &lt;4c&gt; 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40&#xA;RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36&#xA;RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128&#xA;RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001&#xA;R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000&#xA;R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905&#xA;FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA;mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]&#xA;process_one_work+0x1e8/0x3c0&#xA;worker_thread+0x50/0x3b0&#xA;? rescuer_thread+0x380/0x380&#xA;kthread+0x149/0x170&#xA;? set_kthread_struct+0x50/0x50&#xA;ret_from_fork+0x22/0x30&#xA;Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]&#xA;CR2: 0000000000000000&#xA;---[ end trace f6f8be4eae12f7bc ]---&#xA;CVE-2024-56538:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm: zynqmp_kms: Unplug DRM device before removal&#xA;&#xA;Prevent userspace accesses to the DRM device from causing&#xA;use-after-frees by unplugging the device before we remove it. This&#xA;causes any further userspace accesses to result in an error without&#xA;further calls into this driver&#39;s internals.&#xA;CVE-2024-53239:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: 6fire: Release resources at card release&#xA;&#xA;The current 6fire code tries to release the resources right after the&#xA;call of usb6fire_chip_abort().  But at this moment, the card object&#xA;might be still in use (as we&#39;re calling snd_card_free_when_closed()).&#xA;&#xA;For avoid potential UAFs, move the release of resources to the card&#39;s&#xA;private_free instead of the manual call of usb6fire_chip_destroy() at&#xA;the USB disconnect callback.&#xA;CVE-2024-53165:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sh: intc: Fix use-after-free bug in register_intc_controller()&#xA;&#xA;In the error handling for this function, d is freed without ever&#xA;removing it from intc_list which would lead to a use after free.&#xA;To fix this, let&#39;s only add it to the list after everything has&#xA;succeeded.&#xA;CVE-2024-53201:In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.&#xA;CVE-2024-53194:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI: Fix use-after-free of slot-&gt;bus on hot remove&#xA;&#xA;Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.&#xA;&#xA;Since commit 0fc70886569c (&#34;thunderbolt: Reset USB4 v2 host router&#34;) and&#xA;commit 59a54c5f3dbd (&#34;thunderbolt: Reset topology created by the boot&#xA;firmware&#34;), USB4 v2 and v1 Host Routers are reset on probe of the&#xA;thunderbolt driver.&#xA;&#xA;The reset clears the Presence Detect State and Data Link Layer Link Active&#xA;bits at the USB4 Host Router&#39;s Root Port and thus causes hot removal of the&#xA;dock.&#xA;&#xA;The crash occurs when pciehp is unbound from one of the dock&#39;s Downstream&#xA;Ports:  pciehp creates a pci_slot on bind and destroys it on unbind.  The&#xA;pci_slot contains a pointer to the pci_bus below the Downstream Port, but&#xA;a reference on that pci_bus is never acquired.  The pci_bus is destroyed&#xA;before the pci_slot, so a use-after-free ensues when pci_slot_release()&#xA;accesses slot-&gt;bus.&#xA;&#xA;In principle this should not happen because pci_stop_bus_device() unbinds&#xA;pciehp (and therefore destroys the pci_slot) before the pci_bus is&#xA;destroyed by pci_remove_bus_device().&#xA;&#xA;However the stacktrace provided by Dennis shows that pciehp is unbound from&#xA;pci_remove_bus_device() instead of pci_stop_bus_device().  To understand&#xA;the significance of this, one needs to know that the PCI core uses a two&#xA;step process to remove a portion of the hierarchy:  It first unbinds all&#xA;drivers in the sub-hierarchy in pci_stop_bus_device() and then actually&#xA;removes the devices in pci_remove_bus_device().  There is no precaution to&#xA;prevent driver binding in-between pci_stop_bus_device() and&#xA;pci_remove_bus_device().&#xA;&#xA;In Dennis&#39; case, it seems removal of the hierarchy by pciehp races with&#xA;driver binding by pci_bus_add_devices().  pciehp is bound to the&#xA;Downstream Port after pci_stop_bus_device() has run, so it is unbound by&#xA;pci_remove_bus_device() instead of pci_stop_bus_device().  Because the&#xA;pci_bus has already been destroyed at that point, accesses to it result in&#xA;a use-after-free.&#xA;&#xA;One might conclude that driver binding needs to be prevented after&#xA;pci_stop_bus_device() has run.  However it seems risky that pci_slot points&#xA;to pci_bus without holding a reference.  Solely relying on correct ordering&#xA;of driver unbind versus pci_bus destruction is certainly not defensive&#xA;programming.&#xA;&#xA;If pci_slot has a need to access data in pci_bus, it ought to acquire a&#xA;reference.  Amend pci_create_slot() accordingly.  Dennis reports that the&#xA;crash is not reproducible with this change.&#xA;&#xA;Abridged stacktrace:&#xA;&#xA;  pcieport 0000:00:07.0: PME: Signaling with IRQ 156&#xA;  pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+&#xA;  pci_bus 0000:20: dev 00, created physical slot 12&#xA;  pcieport 0000:00:07.0: pciehp: Slot(12): Card not present&#xA;  ...&#xA;  pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0&#xA;  Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI&#xA;  CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1&#xA;  RIP: 0010:dev_driver_string+0x12/0x40&#xA;  pci_destroy_slot&#xA;  pciehp_remove&#xA;  pcie_port_remove_service&#xA;  device_release_driver_internal&#xA;  bus_remove_device&#xA;  device_del&#xA;  device_unregister&#xA;  remove_iter&#xA;  device_for_each_child&#xA;  pcie_portdrv_remove&#xA;  pci_device_remove&#xA;  device_release_driver_internal&#xA;  bus_remove_device&#xA;  device_del&#xA;  pci_remove_bus_device (recursive invocation)&#xA;  pci_remove_bus_device&#xA;  pciehp_unconfigure_device&#xA;  pciehp_disable_slot&#xA;  pciehp_handle_presence_or_link_change&#xA;  pciehp_ist&#xA;CVE-2024-53227:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: bfa: Fix use-after-free in bfad_im_module_exit()&#xA;&#xA;BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20&#xA;Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303&#xA;&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x95/0xe0&#xA; print_report+0xcb/0x620&#xA; kasan_report+0xbd/0xf0&#xA; __lock_acquire+0x2aca/0x3a20&#xA; lock_acquire+0x19b/0x520&#xA; _raw_spin_lock+0x2b/0x40&#xA; attribute_container_unregister+0x30/0x160&#xA; fc_release_transport+0x19/0x90 [scsi_transport_fc]&#xA; bfad_im_module_exit+0x23/0x60 [bfa]&#xA; bfad_init+0xdb/0xff0 [bfa]&#xA; do_one_initcall+0xdc/0x550&#xA; do_init_module+0x22d/0x6b0&#xA; load_module+0x4e96/0x5ff0&#xA; init_module_from_file+0xcd/0x130&#xA; idempotent_init_module+0x330/0x620&#xA; __x64_sys_finit_module+0xb3/0x110&#xA; do_syscall_64+0xc1/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 25303:&#xA; kasan_save_stack+0x24/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0x7f/0x90&#xA; fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]&#xA; bfad_im_module_init+0x17/0x80 [bfa]&#xA; bfad_init+0x23/0xff0 [bfa]&#xA; do_one_initcall+0xdc/0x550&#xA; do_init_module+0x22d/0x6b0&#xA; load_module+0x4e96/0x5ff0&#xA; init_module_from_file+0xcd/0x130&#xA; idempotent_init_module+0x330/0x620&#xA; __x64_sys_finit_module+0xb3/0x110&#xA; do_syscall_64+0xc1/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Freed by task 25303:&#xA; kasan_save_stack+0x24/0x50&#xA; kasan_save_track+0x14/0x30&#xA; kasan_save_free_info+0x3b/0x60&#xA; __kasan_slab_free+0x38/0x50&#xA; kfree+0x212/0x480&#xA; bfad_im_module_init+0x7e/0x80 [bfa]&#xA; bfad_init+0x23/0xff0 [bfa]&#xA; do_one_initcall+0xdc/0x550&#xA; do_init_module+0x22d/0x6b0&#xA; load_module+0x4e96/0x5ff0&#xA; init_module_from_file+0xcd/0x130&#xA; idempotent_init_module+0x330/0x620&#xA; __x64_sys_finit_module+0xb3/0x110&#xA; do_syscall_64+0xc1/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Above issue happens as follows:&#xA;&#xA;bfad_init&#xA;  error = bfad_im_module_init()&#xA;    fc_release_transport(bfad_im_scsi_transport_template);&#xA;  if (error)&#xA;    goto ext;&#xA;&#xA;ext:&#xA;  bfad_im_module_exit();&#xA;    fc_release_transport(bfad_im_scsi_transport_template);&#xA;    --&gt; Trigger double release&#xA;&#xA;Don&#39;t call bfad_im_module_exit() if bfad_im_module_init() failed.&#xA;CVE-2024-53197:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices&#xA;&#xA;A bogus device can provide a bNumConfigurations value that exceeds the&#xA;initial value used in usb_get_configuration for allocating dev-&gt;config.&#xA;&#xA;This can lead to out-of-bounds accesses later, e.g. in&#xA;usb_destroy_configuration.&#xA;CVE-2024-53221:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix null-ptr-deref in f2fs_submit_page_bio()&#xA;&#xA;There&#39;s issue as follows when concurrently installing the f2fs.ko&#xA;module and mounting the f2fs file system:&#xA;KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]&#xA;RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; f2fs_submit_page_bio+0x126/0x8b0 [f2fs]&#xA; __get_meta_page+0x1d4/0x920 [f2fs]&#xA; get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs]&#xA; validate_checkpoint+0xac/0x290 [f2fs]&#xA; f2fs_get_valid_checkpoint+0x207/0x950 [f2fs]&#xA; f2fs_fill_super+0x1007/0x39b0 [f2fs]&#xA; mount_bdev+0x183/0x250&#xA; legacy_get_tree+0xf4/0x1e0&#xA; vfs_get_tree+0x88/0x340&#xA; do_new_mount+0x283/0x5e0&#xA; path_mount+0x2b2/0x15b0&#xA; __x64_sys_mount+0x1fe/0x270&#xA; do_syscall_64+0x5f/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Above issue happens as the biset of the f2fs file system is not&#xA;initialized before register &#34;f2fs_fs_type&#34;.&#xA;To address above issue just register &#34;f2fs_fs_type&#34; at the last in&#xA;init_f2fs_fs(). Ensure that all f2fs file system resources are&#xA;initialized.&#xA;CVE-2024-53187:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;io_uring: check for overflows in io_pin_pages&#xA;&#xA;WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144&#xA;CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183&#xA; io_rings_map io_uring/io_uring.c:2611 [inline]&#xA; io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470&#xA; io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692&#xA; io_uring_setup io_uring/io_uring.c:3781 [inline]&#xA; ...&#xA; &lt;/TASK&gt;&#xA;&#xA;io_pin_pages()&#39;s uaddr parameter came directly from the user and can be&#xA;garbage. Don&#39;t just add size to it as it can overflow.&#xA;CVE-2024-53185:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: fix NULL ptr deref in crypto_aead_setkey()&#xA;&#xA;Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so&#xA;when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,&#xA;the client uses AES-128-CCM as the default cipher.  See MS-SMB2&#xA;3.3.5.4.&#xA;&#xA;Commit b0abcd65ec54 (&#34;smb: client: fix UAF in async decryption&#34;) added&#xA;a @server-&gt;cipher_type check to conditionally call&#xA;smb3_crypto_aead_allocate(), but that check would always be false as&#xA;@server-&gt;cipher_type is unset for SMB3.02.&#xA;&#xA;Fix the following KASAN splat by setting @server-&gt;cipher_type for&#xA;SMB3.02 as well.&#xA;&#xA;mount.cifs //srv/share /mnt -o vers=3.02,seal,...&#xA;&#xA;BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130&#xA;Read of size 8 at addr 0000000000000020 by task mount.cifs/1095&#xA;CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41&#xA;04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x5d/0x80&#xA; ? crypto_aead_setkey+0x2c/0x130&#xA; kasan_report+0xda/0x110&#xA; ? crypto_aead_setkey+0x2c/0x130&#xA; crypto_aead_setkey+0x2c/0x130&#xA; crypt_message+0x258/0xec0 [cifs]&#xA; ? __asan_memset+0x23/0x50&#xA; ? __pfx_crypt_message+0x10/0x10 [cifs]&#xA; ? mark_lock+0xb0/0x6a0&#xA; ? hlock_class+0x32/0xb0&#xA; ? mark_lock+0xb0/0x6a0&#xA; smb3_init_transform_rq+0x352/0x3f0 [cifs]&#xA; ? lock_acquire.part.0+0xf4/0x2a0&#xA; smb_send_rqst+0x144/0x230 [cifs]&#xA; ? __pfx_smb_send_rqst+0x10/0x10 [cifs]&#xA; ? hlock_class+0x32/0xb0&#xA; ? smb2_setup_request+0x225/0x3a0 [cifs]&#xA; ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]&#xA; compound_send_recv+0x59b/0x1140 [cifs]&#xA; ? __pfx_compound_send_recv+0x10/0x10 [cifs]&#xA; ? __create_object+0x5e/0x90&#xA; ? hlock_class+0x32/0xb0&#xA; ? do_raw_spin_unlock+0x9a/0xf0&#xA; cifs_send_recv+0x23/0x30 [cifs]&#xA; SMB2_tcon+0x3ec/0xb30 [cifs]&#xA; ? __pfx_SMB2_tcon+0x10/0x10 [cifs]&#xA; ? lock_acquire.part.0+0xf4/0x2a0&#xA; ? __pfx_lock_release+0x10/0x10&#xA; ? do_raw_spin_trylock+0xc6/0x120&#xA; ? lock_acquire+0x3f/0x90&#xA; ? _get_xid+0x16/0xd0 [cifs]&#xA; ? __pfx_SMB2_tcon+0x10/0x10 [cifs]&#xA; ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]&#xA; cifs_get_smb_ses+0xcdd/0x10a0 [cifs]&#xA; ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]&#xA; ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]&#xA; cifs_mount_get_session+0x8a/0x210 [cifs]&#xA; dfs_mount_share+0x1b0/0x11d0 [cifs]&#xA; ? __pfx___lock_acquire+0x10/0x10&#xA; ? __pfx_dfs_mount_share+0x10/0x10 [cifs]&#xA; ? lock_acquire.part.0+0xf4/0x2a0&#xA; ? find_held_lock+0x8a/0xa0&#xA; ? hlock_class+0x32/0xb0&#xA; ? lock_release+0x203/0x5d0&#xA; cifs_mount+0xb3/0x3d0 [cifs]&#xA; ? do_raw_spin_trylock+0xc6/0x120&#xA; ? __pfx_cifs_mount+0x10/0x10 [cifs]&#xA; ? lock_acquire+0x3f/0x90&#xA; ? find_nls+0x16/0xa0&#xA; ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]&#xA; cifs_smb3_do_mount+0x1e2/0xc80 [cifs]&#xA; ? __pfx_vfs_parse_fs_string+0x10/0x10&#xA; ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]&#xA; smb3_get_tree+0x1bf/0x330 [cifs]&#xA; vfs_get_tree+0x4a/0x160&#xA; path_mount+0x3c1/0xfb0&#xA; ? kasan_quarantine_put+0xc7/0x1d0&#xA; ? __pfx_path_mount+0x10/0x10&#xA; ? kmem_cache_free+0x118/0x3e0&#xA; ? user_path_at+0x74/0xa0&#xA; __x64_sys_mount+0x1a6/0x1e0&#xA; ? __pfx___x64_sys_mount+0x10/0x10&#xA; ? mark_held_locks+0x1a/0x90&#xA; do_syscall_64+0xbb/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-53219:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;virtiofs: use pages instead of pointer for kernel direct IO&#xA;&#xA;When trying to insert a 10MB kernel module kept in a virtio-fs with cache&#xA;disabled, the following warning was reported:&#xA;&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ......&#xA;  Modules linked in:&#xA;  CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......&#xA;  RIP: 0010:__alloc_pages+0x2bf/0x380&#xA;  ......&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? __warn+0x8e/0x150&#xA;   ? __alloc_pages+0x2bf/0x380&#xA;   __kmalloc_large_node+0x86/0x160&#xA;   __kmalloc+0x33c/0x480&#xA;   virtio_fs_enqueue_req+0x240/0x6d0&#xA;   virtio_fs_wake_pending_and_unlock+0x7f/0x190&#xA;   queue_request_and_unlock+0x55/0x60&#xA;   fuse_simple_request+0x152/0x2b0&#xA;   fuse_direct_io+0x5d2/0x8c0&#xA;   fuse_file_read_iter+0x121/0x160&#xA;   __kernel_read+0x151/0x2d0&#xA;   kernel_read+0x45/0x50&#xA;   kernel_read_file+0x1a9/0x2a0&#xA;   init_module_from_file+0x6a/0xe0&#xA;   idempotent_init_module+0x175/0x230&#xA;   __x64_sys_finit_module+0x5d/0xb0&#xA;   x64_sys_call+0x1c3/0x9e0&#xA;   do_syscall_64+0x3d/0xc0&#xA;   entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;   ......&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;&#xA;The warning is triggered as follows:&#xA;&#xA;1) syscall finit_module() handles the module insertion and it invokes&#xA;kernel_read_file() to read the content of the module first.&#xA;&#xA;2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and&#xA;passes it to kernel_read(). kernel_read() constructs a kvec iter by&#xA;using iov_iter_kvec() and passes it to fuse_file_read_iter().&#xA;&#xA;3) virtio-fs disables the cache, so fuse_file_read_iter() invokes&#xA;fuse_direct_io(). As for now, the maximal read size for kvec iter is&#xA;only limited by fc-&gt;max_read. For virtio-fs, max_read is UINT_MAX, so&#xA;fuse_direct_io() doesn&#39;t split the 10MB buffer. It saves the address and&#xA;the size of the 10MB-sized buffer in out_args[0] of a fuse request and&#xA;passes the fuse request to virtio_fs_wake_pending_and_unlock().&#xA;&#xA;4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to&#xA;queue the request. Because virtiofs need DMA-able address, so&#xA;virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for&#xA;all fuse args, copies these args into the bounce buffer and passed the&#xA;physical address of the bounce buffer to virtiofsd. The total length of&#xA;these fuse args for the passed fuse request is about 10MB, so&#xA;copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and&#xA;it triggers the warning in __alloc_pages():&#xA;&#xA;&#x9;if (WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp))&#xA;&#x9;&#x9;return NULL;&#xA;&#xA;5) virtio_fs_enqueue_req() will retry the memory allocation in a&#xA;kworker, but it won&#39;t help, because kmalloc() will always return NULL&#xA;due to the abnormal size and finit_module() will hang forever.&#xA;&#xA;A feasible solution is to limit the value of max_read for virtio-fs, so&#xA;the length passed to kmalloc() will be limited. However it will affect&#xA;the maximal read size for normal read. And for virtio-fs write initiated&#xA;from kernel, it has the similar problem but now there is no way to limit&#xA;fc-&gt;max_write in kernel.&#xA;&#xA;So instead of limiting both the values of max_read and max_write in&#xA;kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as&#xA;true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use&#xA;pages instead of pointer to pass the KVEC_IO data.&#xA;&#xA;After switching to pages for KVEC_IO data, these pages will be used for&#xA;DMA through virtio-fs. If these pages are backed by vmalloc(),&#xA;{flush|invalidate}_kernel_vmap_range() are necessary to flush or&#xA;invalidate the cache before the DMA operation. So add two new fields in&#xA;fuse_args_pages to record the base address of vmalloc area and the&#xA;condition indicating whether invalidation is needed. Perform the flush&#xA;in fuse_get_user_pages() for write operations and the invalidation in&#xA;fuse_release_user_pages() for read operations.&#xA;&#xA;It may seem necessary to introduce another fie&#xA;---truncated---&#xA;CVE-2024-53171:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit&#xA;&#xA;After an insertion in TNC, the tree might split and cause a node to&#xA;change its `znode-&gt;parent`. A further deletion of other nodes in the&#xA;tree (which also could free the nodes), the aforementioned node&#39;s&#xA;`znode-&gt;cparent` could still point to a freed node. This&#xA;`znode-&gt;cparent` may not be updated when getting nodes to commit in&#xA;`ubifs_tnc_start_commit()`. This could then trigger a use-after-free&#xA;when accessing the `znode-&gt;cparent` in `write_index()` in&#xA;`ubifs_tnc_end_commit()`.&#xA;&#xA;This can be triggered by running&#xA;&#xA;  rm -f /etc/test-file.bin&#xA;  dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync&#xA;&#xA;in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then&#xA;reports:&#xA;&#xA;  BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950&#xA;  Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153&#xA;&#xA;  Call trace:&#xA;   dump_backtrace+0x0/0x340&#xA;   show_stack+0x18/0x24&#xA;   dump_stack_lvl+0x9c/0xbc&#xA;   print_address_description.constprop.0+0x74/0x2b0&#xA;   kasan_report+0x1d8/0x1f0&#xA;   kasan_check_range+0xf8/0x1a0&#xA;   memcpy+0x84/0xf4&#xA;   ubifs_tnc_end_commit+0xa5c/0x1950&#xA;   do_commit+0x4e0/0x1340&#xA;   ubifs_bg_thread+0x234/0x2e0&#xA;   kthread+0x36c/0x410&#xA;   ret_from_fork+0x10/0x20&#xA;&#xA;  Allocated by task 401:&#xA;   kasan_save_stack+0x38/0x70&#xA;   __kasan_kmalloc+0x8c/0xd0&#xA;   __kmalloc+0x34c/0x5bc&#xA;   tnc_insert+0x140/0x16a4&#xA;   ubifs_tnc_add+0x370/0x52c&#xA;   ubifs_jnl_write_data+0x5d8/0x870&#xA;   do_writepage+0x36c/0x510&#xA;   ubifs_writepage+0x190/0x4dc&#xA;   __writepage+0x58/0x154&#xA;   write_cache_pages+0x394/0x830&#xA;   do_writepages+0x1f0/0x5b0&#xA;   filemap_fdatawrite_wbc+0x170/0x25c&#xA;   file_write_and_wait_range+0x140/0x190&#xA;   ubifs_fsync+0xe8/0x290&#xA;   vfs_fsync_range+0xc0/0x1e4&#xA;   do_fsync+0x40/0x90&#xA;   __arm64_sys_fsync+0x34/0x50&#xA;   invoke_syscall.constprop.0+0xa8/0x260&#xA;   do_el0_svc+0xc8/0x1f0&#xA;   el0_svc+0x34/0x70&#xA;   el0t_64_sync_handler+0x108/0x114&#xA;   el0t_64_sync+0x1a4/0x1a8&#xA;&#xA;  Freed by task 403:&#xA;   kasan_save_stack+0x38/0x70&#xA;   kasan_set_track+0x28/0x40&#xA;   kasan_set_free_info+0x28/0x4c&#xA;   __kasan_slab_free+0xd4/0x13c&#xA;   kfree+0xc4/0x3a0&#xA;   tnc_delete+0x3f4/0xe40&#xA;   ubifs_tnc_remove_range+0x368/0x73c&#xA;   ubifs_tnc_remove_ino+0x29c/0x2e0&#xA;   ubifs_jnl_delete_inode+0x150/0x260&#xA;   ubifs_evict_inode+0x1d4/0x2e4&#xA;   evict+0x1c8/0x450&#xA;   iput+0x2a0/0x3c4&#xA;   do_unlinkat+0x2cc/0x490&#xA;   __arm64_sys_unlinkat+0x90/0x100&#xA;   invoke_syscall.constprop.0+0xa8/0x260&#xA;   do_el0_svc+0xc8/0x1f0&#xA;   el0_svc+0x34/0x70&#xA;   el0t_64_sync_handler+0x108/0x114&#xA;   el0t_64_sync+0x1a4/0x1a8&#xA;&#xA;The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free&#xA;when a node becomes root in TNC but still has a `cparent` to an already&#xA;freed node. More specifically, consider the following TNC:&#xA;&#xA;         zroot&#xA;         /&#xA;        /&#xA;      zp1&#xA;      /&#xA;     /&#xA;    zn&#xA;&#xA;Inserting a new node `zn_new` with a key smaller then `zn` will trigger&#xA;a split in `tnc_insert()` if `zp1` is full:&#xA;&#xA;         zroot&#xA;         /   \&#xA;        /     \&#xA;      zp1     zp2&#xA;      /         \&#xA;     /           \&#xA;  zn_new          zn&#xA;&#xA;`zn-&gt;parent` has now been moved to `zp2`, *but* `zn-&gt;cparent` still&#xA;points to `zp1`.&#xA;&#xA;Now, consider a removal of all the nodes _except_ `zn`. Just when&#xA;`tnc_delete()` is about to delete `zroot` and `zp2`:&#xA;&#xA;         zroot&#xA;             \&#xA;              \&#xA;              zp2&#xA;                \&#xA;                 \&#xA;                 zn&#xA;&#xA;`zroot` and `zp2` get freed and the tree collapses:&#xA;&#xA;           zn&#xA;&#xA;`zn` now becomes the new `zroot`.&#xA;&#xA;`get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and&#xA;`write_index()` will check its `znode-&gt;cparent` that wrongly points to&#xA;the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called&#xA;with `znode-&gt;cparent-&gt;zbranch[znode-&gt;iip].hash` that triggers the&#xA;use-after-free!&#xA;&#xA;Fix this by explicitly setting `znode-&gt;cparent` to `NULL` in&#xA;`get_znodes_to_commit()` for the root node. The search for the dirty&#xA;nodes&#xA;---truncated---&#xA;CVE-2024-56672:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;blk-cgroup: Fix UAF in blkcg_unpin_online()&#xA;&#xA;blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To&#xA;walk up, it uses blkcg_parent(blkcg) but it was calling that after&#xA;blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the&#xA;following UAF:&#xA;&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270&#xA;  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117&#xA;&#xA;  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022&#xA;  Workqueue: cgwb_release cgwb_release_workfn&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x27/0x80&#xA;   print_report+0x151/0x710&#xA;   kasan_report+0xc0/0x100&#xA;   blkcg_unpin_online+0x15a/0x270&#xA;   cgwb_release_workfn+0x194/0x480&#xA;   process_scheduled_works+0x71b/0xe20&#xA;   worker_thread+0x82a/0xbd0&#xA;   kthread+0x242/0x2c0&#xA;   ret_from_fork+0x33/0x70&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;   &lt;/TASK&gt;&#xA;  ...&#xA;  Freed by task 1944:&#xA;   kasan_save_track+0x2b/0x70&#xA;   kasan_save_free_info+0x3c/0x50&#xA;   __kasan_slab_free+0x33/0x50&#xA;   kfree+0x10c/0x330&#xA;   css_free_rwork_fn+0xe6/0xb30&#xA;   process_scheduled_works+0x71b/0xe20&#xA;   worker_thread+0x82a/0xbd0&#xA;   kthread+0x242/0x2c0&#xA;   ret_from_fork+0x33/0x70&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;&#xA;Note that the UAF is not easy to trigger as the free path is indirected&#xA;behind a couple RCU grace periods and a work item execution. I could only&#xA;trigger it with artifical msleep() injected in blkcg_unpin_online().&#xA;&#xA;Fix it by reading the parent pointer before destroying the blkcg&#39;s blkg&#39;s.&#xA;CVE-2024-56562:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()&#xA;&#xA;if (dev-&gt;boardinfo &amp;&amp; dev-&gt;boardinfo-&gt;init_dyn_addr)&#xA;                                      ^^^ here check &#34;init_dyn_addr&#34;&#xA;&#x9;i3c_bus_set_addr_slot_status(&amp;master-&gt;bus, dev-&gt;info.dyn_addr, ...)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;             ^^^^&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;free &#34;dyn_addr&#34;&#xA;Fix copy/paste error &#34;dyn_addr&#34; by replacing it with &#34;init_dyn_addr&#34;.&#xA;CVE-2024-56567:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ad7780: fix division by zero in ad7780_write_raw()&#xA;&#xA;In the ad7780_write_raw() , val2 can be zero, which might lead to a&#xA;division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()&#xA;is based on iio_info&#39;s write_raw. While val is explicitly declared that&#xA;can be zero (in read mode), val2 is not specified to be non-zero.&#xA;CVE-2024-56569:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ftrace: Fix regression with module command in stack_trace_filter&#xA;&#xA;When executing the following command:&#xA;&#xA;    # echo &#34;write*:mod:ext3&#34; &gt; /sys/kernel/tracing/stack_trace_filter&#xA;&#xA;The current mod command causes a null pointer dereference. While commit&#xA;0f17976568b3f (&#34;ftrace: Fix regression with module command in stack_trace_filter&#34;)&#xA;has addressed part of the issue, it left a corner case unhandled, which still&#xA;results in a kernel crash.&#xA;CVE-2024-56570:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ovl: Filter invalid inodes with missing lookup function&#xA;&#xA;Add a check to the ovl_dentry_weird() function to prevent the&#xA;processing of directory inodes that lack the lookup function.&#xA;This is important because such inodes can cause errors in overlayfs&#xA;when passed to the lowerstack.&#xA;CVE-2024-56630:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: free inode when ocfs2_get_init_inode() fails&#xA;&#xA;syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826&#xA;(&#34;ocfs2: Handle error from dquot_initialize()&#34;) forgot to call iput() when&#xA;new_inode() succeeded and dquot_initialize() failed.&#xA;CVE-2024-56631:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: sg: Fix slab-use-after-free read in sg_release()&#xA;&#xA;Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:&#xA;&#xA;BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30&#xA;kernel/locking/lockdep.c:5838&#xA;__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912&#xA;sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407&#xA;&#xA;In sg_release(), the function kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) is&#xA;called before releasing the open_rel_lock mutex. The kref_put() call may&#xA;decrement the reference count of sfp to zero, triggering its cleanup&#xA;through sg_remove_sfp(). This cleanup includes scheduling deferred work&#xA;via sg_remove_sfp_usercontext(), which ultimately frees sfp.&#xA;&#xA;After kref_put(), sg_release() continues to unlock open_rel_lock and may&#xA;reference sfp or sdp. If sfp has already been freed, this results in a&#xA;slab-use-after-free error.&#xA;&#xA;Move the kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) call after unlocking the&#xA;open_rel_lock mutex. This ensures:&#xA;&#xA; - No references to sfp or sdp occur after the reference count is&#xA;   decremented.&#xA;&#xA; - Cleanup functions such as sg_remove_sfp() and&#xA;   sg_remove_sfp_usercontext() can safely execute without impacting the&#xA;   mutex handling in sg_release().&#xA;&#xA;The fix has been tested and validated by syzbot. This patch closes the&#xA;bug reported at the following syzkaller link and ensures proper&#xA;sequencing of resource cleanup and mutex operations, eliminating the&#xA;risk of use-after-free errors in sg_release().&#xA;CVE-2024-56604:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()&#xA;&#xA;bt_sock_alloc() attaches allocated sk object to the provided sock object.&#xA;If rfcomm_dlc_alloc() fails, we release the sk object, but leave the&#xA;dangling pointer in the sock object, which may cause use-after-free.&#xA;&#xA;Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().&#xA;CVE-2024-56605:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()&#xA;&#xA;bt_sock_alloc() allocates the sk object and attaches it to the provided&#xA;sock object. On error l2cap_sock_alloc() frees the sk object, but the&#xA;dangling pointer is still attached to the sock object, which may create&#xA;use-after-free in other code.&#xA;CVE-2024-56619:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()&#xA;&#xA;Syzbot reported that when searching for records in a directory where the&#xA;inode&#39;s i_size is corrupted and has a large value, memory access outside&#xA;the folio/page range may occur, or a use-after-free bug may be detected if&#xA;KASAN is enabled.&#xA;&#xA;This is because nilfs_last_byte(), which is called by nilfs_find_entry()&#xA;and others to calculate the number of valid bytes of directory data in a&#xA;page from i_size and the page index, loses the upper 32 bits of the 64-bit&#xA;size information due to an inappropriate type of local variable to which&#xA;the i_size value is assigned.&#xA;&#xA;This caused a large byte offset value due to underflow in the end address&#xA;calculation in the calling nilfs_find_entry(), resulting in memory access&#xA;that exceeds the folio/page size.&#xA;&#xA;Fix this issue by changing the type of the local variable causing the bit&#xA;loss from &#34;unsigned int&#34; to &#34;u64&#34;.  The return value of nilfs_last_byte()&#xA;is also of type &#34;unsigned int&#34;, but it is truncated so as not to exceed&#xA;PAGE_SIZE and no bit loss occurs, so no change is required.&#xA;CVE-2024-56634:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;gpio: grgpio: Add NULL check in grgpio_probe&#xA;&#xA;devm_kasprintf() can return a NULL pointer on failure,but this&#xA;returned value in grgpio_probe is not checked.&#xA;Add NULL check in grgpio_probe, to handle kernel NULL&#xA;pointer dereference error.&#xA;CVE-2024-56594:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amdgpu: set the right AMDGPU sg segment limitation&#xA;&#xA;The driver needs to set the correct max_segment_size;&#xA;otherwise debug_dma_map_sg() will complain about the&#xA;over-mapping of the AMDGPU sg length as following:&#xA;&#xA;WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370&#xA;[  364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd&#xA;[  364.049532]  ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii&#xA;[  364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G           OE      6.10.0-custom #492&#xA;[  364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021&#xA;[  364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370&#xA;[  364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff &lt;0f&gt; 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05&#xA;[  364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286&#xA;[  364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027&#xA;[  364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680&#xA;[  364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930&#xA;[  364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000&#xA;[  364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800&#xA;[  364.049599] FS:  00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000&#xA;[  364.049601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0&#xA;[  364.049605] Call Trace:&#xA;[  364.049607]  &lt;TASK&gt;&#xA;[  364.049609]  ? show_regs+0x6d/0x80&#xA;[  364.049614]  ? __warn+0x8c/0x140&#xA;[  364.049618]  ? debug_dma_map_sg+0x2dc/0x370&#xA;[  364.049621]  ? report_bug+0x193/0x1a0&#xA;[  364.049627]  ? handle_bug+0x46/0x80&#xA;[  364.049631]  ? exc_invalid_op+0x1d/0x80&#xA;[  364.049635]  ? asm_exc_invalid_op+0x1f/0x30&#xA;[  364.049642]  ? debug_dma_map_sg+0x2dc/0x370&#xA;[  364.049647]  __dma_map_sg_attrs+0x90/0xe0&#xA;[  364.049651]  dma_map_sgtable+0x25/0x40&#xA;[  364.049654]  amdgpu_bo_move+0x59a/0x850 [amdgpu]&#xA;[  364.049935]  ? srso_return_thunk+0x5/0x5f&#xA;[  364.049939]  ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]&#xA;[  364.050095]  ttm_bo_handle_move_mem+0xc3/0x180 [ttm]&#xA;[  364.050103]  ttm_bo_validate+0xc1/0x160 [ttm]&#xA;[  364.050108]  ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]&#xA;[  364.050263]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]&#xA;[  364.050473]  kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]&#xA;[  364.050680]  kfd_ioctl+0x3c2/0x530 [amdgpu]&#xA;[  364.050866]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]&#xA;[  364.05105&#xA;---truncated---&#xA;CVE-2024-56608:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Fix out-of-bounds access in &#39;dcn21_link_encoder_create&#39;&#xA;&#xA;An issue was identified in the dcn21_link_encoder_create function where&#xA;an out-of-bounds access could occur when the hpd_source index was used&#xA;to reference the link_enc_hpd_regs array. This array has a fixed size&#xA;and the index was not being checked against the array&#39;s bounds before&#xA;accessing it.&#xA;&#xA;This fix adds a conditional check to ensure that the hpd_source index is&#xA;within the valid range of the link_enc_hpd_regs array. If the index is&#xA;out of bounds, the function now returns NULL to prevent undefined&#xA;behavior.&#xA;&#xA;References:&#xA;&#xA;[   65.920507] ------------[ cut here ]------------&#xA;[   65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29&#xA;[   65.920519] index 7 is out of range for type &#39;dcn10_link_enc_hpd_registers [5]&#39;&#xA;[   65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G           OE      6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13&#xA;[   65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020&#xA;[   65.920527] Call Trace:&#xA;[   65.920529]  &lt;TASK&gt;&#xA;[   65.920532]  dump_stack_lvl+0x48/0x70&#xA;[   65.920541]  dump_stack+0x10/0x20&#xA;[   65.920543]  __ubsan_handle_out_of_bounds+0xa2/0xe0&#xA;[   65.920549]  dcn21_link_encoder_create+0xd9/0x140 [amdgpu]&#xA;[   65.921009]  link_create+0x6d3/0xed0 [amdgpu]&#xA;[   65.921355]  create_links+0x18a/0x4e0 [amdgpu]&#xA;[   65.921679]  dc_create+0x360/0x720 [amdgpu]&#xA;[   65.921999]  ? dmi_matches+0xa0/0x220&#xA;[   65.922004]  amdgpu_dm_init+0x2b6/0x2c90 [amdgpu]&#xA;[   65.922342]  ? console_unlock+0x77/0x120&#xA;[   65.922348]  ? dev_printk_emit+0x86/0xb0&#xA;[   65.922354]  dm_hw_init+0x15/0x40 [amdgpu]&#xA;[   65.922686]  amdgpu_device_init+0x26a8/0x33a0 [amdgpu]&#xA;[   65.922921]  amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu]&#xA;[   65.923087]  amdgpu_pci_probe+0x1b7/0x630 [amdgpu]&#xA;[   65.923087]  local_pci_probe+0x4b/0xb0&#xA;[   65.923087]  pci_device_probe+0xc8/0x280&#xA;[   65.923087]  really_probe+0x187/0x300&#xA;[   65.923087]  __driver_probe_device+0x85/0x130&#xA;[   65.923087]  driver_probe_device+0x24/0x110&#xA;[   65.923087]  __driver_attach+0xac/0x1d0&#xA;[   65.923087]  ? __pfx___driver_attach+0x10/0x10&#xA;[   65.923087]  bus_for_each_dev+0x7d/0xd0&#xA;[   65.923087]  driver_attach+0x1e/0x30&#xA;[   65.923087]  bus_add_driver+0xf2/0x200&#xA;[   65.923087]  driver_register+0x64/0x130&#xA;[   65.923087]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]&#xA;[   65.923087]  __pci_register_driver+0x61/0x70&#xA;[   65.923087]  amdgpu_init+0x7d/0xff0 [amdgpu]&#xA;[   65.923087]  do_one_initcall+0x49/0x310&#xA;[   65.923087]  ? kmalloc_trace+0x136/0x360&#xA;[   65.923087]  do_init_module+0x6a/0x270&#xA;[   65.923087]  load_module+0x1fce/0x23a0&#xA;[   65.923087]  init_module_from_file+0x9c/0xe0&#xA;[   65.923087]  ? init_module_from_file+0x9c/0xe0&#xA;[   65.923087]  idempotent_init_module+0x179/0x230&#xA;[   65.923087]  __x64_sys_finit_module+0x5d/0xa0&#xA;[   65.923087]  do_syscall_64+0x76/0x120&#xA;[   65.923087]  entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA;[   65.923087] RIP: 0033:0x7f2d80f1e88d&#xA;[   65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48&#xA;[   65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139&#xA;[   65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d&#xA;[   65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f&#xA;[   65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002&#xA;[   65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480&#xA;[   65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0&#xA;[   65.923087]  &lt;/TASK&gt;&#xA;[   65.923927] ---[ end trace ]---&#xA;CVE-2024-56581:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: ref-verify: fix use-after-free after invalid ref action&#xA;&#xA;At btrfs_ref_tree_mod() after we successfully inserted the new ref entry&#xA;(local variable &#39;ref&#39;) into the respective block entry&#39;s rbtree (local&#xA;variable &#39;be&#39;), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,&#xA;we error out and free the ref entry without removing it from the block&#xA;entry&#39;s rbtree. Then in the error path of btrfs_ref_tree_mod() we call&#xA;btrfs_free_ref_cache(), which iterates over all block entries and then&#xA;calls free_block_entry() for each one, and there we will trigger a&#xA;use-after-free when we are called against the block entry to which we&#xA;added the freed ref entry to its rbtree, since the rbtree still points&#xA;to the block entry, as we didn&#39;t remove it from the rbtree before freeing&#xA;it in the error path at btrfs_ref_tree_mod(). Fix this by removing the&#xA;new ref entry from the rbtree before freeing it.&#xA;&#xA;Syzbot report this with the following stack traces:&#xA;&#xA;   BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615&#xA;      __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523&#xA;      update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512&#xA;      btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594&#xA;      btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754&#xA;      btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116&#xA;      btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314&#xA;      btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline]&#xA;      btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23&#xA;      btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482&#xA;      btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293&#xA;      vfs_unlink+0x365/0x650 fs/namei.c:4469&#xA;      do_unlinkat+0x4ae/0x830 fs/namei.c:4533&#xA;      __do_sys_unlinkat fs/namei.c:4576 [inline]&#xA;      __se_sys_unlinkat fs/namei.c:4569 [inline]&#xA;      __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569&#xA;      do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;      do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA;      entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;   BTRFS error (device loop0 state EA):   Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1&#xA;      __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521&#xA;      update_ref_for_cow+0x96a/0x11f0&#xA;      btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594&#xA;      btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754&#xA;      btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116&#xA;      btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411&#xA;      __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030&#xA;      btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]&#xA;      __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137&#xA;      __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171&#xA;      btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313&#xA;      prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586&#xA;      relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611&#xA;      btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081&#xA;      btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377&#xA;      __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161&#xA;      btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538&#xA;   BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615&#xA;      __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523&#xA;      update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512&#xA;      btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594&#xA;      btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754&#xA;      btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116&#xA;      btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411&#xA;      __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030&#xA;      btrfs_update_delayed_i&#xA;---truncated---&#xA;CVE-2024-56596:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: fix array-index-out-of-bounds in jfs_readdir&#xA;&#xA;The stbl might contain some invalid values. Added a check to&#xA;return error code in that case.&#xA;CVE-2024-56583:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sched/deadline: Fix warning in migrate_enable for boosted tasks&#xA;&#xA;When running the following command:&#xA;&#xA;while true; do&#xA;    stress-ng --cyclic 30 --timeout 30s --minimize --quiet&#xA;done&#xA;&#xA;a warning is eventually triggered:&#xA;&#xA;WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794&#xA;setup_new_dl_entity+0x13e/0x180&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_trace_log_lvl+0x1c4/0x2df&#xA; ? enqueue_dl_entity+0x631/0x6e0&#xA; ? setup_new_dl_entity+0x13e/0x180&#xA; ? __warn+0x7e/0xd0&#xA; ? report_bug+0x11a/0x1a0&#xA; ? handle_bug+0x3c/0x70&#xA; ? exc_invalid_op+0x14/0x70&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; enqueue_dl_entity+0x631/0x6e0&#xA; enqueue_task_dl+0x7d/0x120&#xA; __do_set_cpus_allowed+0xe3/0x280&#xA; __set_cpus_allowed_ptr_locked+0x140/0x1d0&#xA; __set_cpus_allowed_ptr+0x54/0xa0&#xA; migrate_enable+0x7e/0x150&#xA; rt_spin_unlock+0x1c/0x90&#xA; group_send_sig_info+0xf7/0x1a0&#xA; ? kill_pid_info+0x1f/0x1d0&#xA; kill_pid_info+0x78/0x1d0&#xA; kill_proc_info+0x5b/0x110&#xA; __x64_sys_kill+0x93/0xc0&#xA; do_syscall_64+0x5c/0xf0&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0x76&#xA; RIP: 0033:0x7f0dab31f92b&#xA;&#xA;This warning occurs because set_cpus_allowed dequeues and enqueues tasks&#xA;with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning&#xA;is triggered. A boosted task already had its parameters set by&#xA;rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,&#xA;hence the WARN_ON call.&#xA;&#xA;Check if we are requeueing a boosted task and avoid calling&#xA;setup_new_dl_entity if that&#39;s the case.&#xA;CVE-2024-56598:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: array-index-out-of-bounds fix in dtReadFirst&#xA;&#xA;The value of stbl can be sometimes out of bounds due&#xA;to a bad filesystem. Added a check with appopriate return&#xA;of error code in that case.&#xA;CVE-2024-56584:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;io_uring/tctx: work around xa_store() allocation error issue&#xA;&#xA;syzbot triggered the following WARN_ON:&#xA;&#xA;WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51&#xA;&#xA;which is the&#xA;&#xA;WARN_ON_ONCE(!xa_empty(&amp;tctx-&gt;xa));&#xA;&#xA;sanity check in __io_uring_free() when a io_uring_task is going through&#xA;its final put. The syzbot test case includes injecting memory allocation&#xA;failures, and it very much looks like xa_store() can fail one of its&#xA;memory allocations and end up with -&gt;head being non-NULL even though no&#xA;entries exist in the xarray.&#xA;&#xA;Until this issue gets sorted out, work around it by attempting to&#xA;iterate entries in our xarray, and WARN_ON_ONCE() if one is found.&#xA;CVE-2024-56627:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read&#xA;&#xA;An offset from client could be a negative value, It could lead&#xA;to an out-of-bounds read from the stream_buf.&#xA;Note that this issue is coming when setting&#xA;&#39;vfs objects = streams_xattr parameter&#39; in ksmbd.conf.&#xA;CVE-2024-56586:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.&#xA;&#xA;creating a large files during checkpoint disable until it runs out of&#xA;space and then delete it, then remount to enable checkpoint again, and&#xA;then unmount the filesystem triggers the f2fs_bug_on as below:&#xA;&#xA;------------[ cut here ]------------&#xA;kernel BUG at fs/f2fs/inode.c:896!&#xA;CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;RIP: 0010:f2fs_evict_inode+0x58c/0x610&#xA;Call Trace:&#xA; __die_body+0x15/0x60&#xA; die+0x33/0x50&#xA; do_trap+0x10a/0x120&#xA; f2fs_evict_inode+0x58c/0x610&#xA; do_error_trap+0x60/0x80&#xA; f2fs_evict_inode+0x58c/0x610&#xA; exc_invalid_op+0x53/0x60&#xA; f2fs_evict_inode+0x58c/0x610&#xA; asm_exc_invalid_op+0x16/0x20&#xA; f2fs_evict_inode+0x58c/0x610&#xA; evict+0x101/0x260&#xA; dispose_list+0x30/0x50&#xA; evict_inodes+0x140/0x190&#xA; generic_shutdown_super+0x2f/0x150&#xA; kill_block_super+0x11/0x40&#xA; kill_f2fs_super+0x7d/0x140&#xA; deactivate_locked_super+0x2a/0x70&#xA; cleanup_mnt+0xb3/0x140&#xA; task_work_run+0x61/0x90&#xA;&#xA;The root cause is: creating large files during disable checkpoint&#xA;period results in not enough free segments, so when writing back root&#xA;inode will failed in f2fs_enable_checkpoint. When umount the file&#xA;system after enabling checkpoint, the root inode is dirty in&#xA;f2fs_evict_inode function, which triggers BUG_ON. The steps to&#xA;reproduce are as follows:&#xA;&#xA;dd if=/dev/zero of=f2fs.img bs=1M count=55&#xA;mount f2fs.img f2fs_dir -o checkpoint=disable:10%&#xA;dd if=/dev/zero of=big bs=1M count=50&#xA;sync&#xA;rm big&#xA;mount -o remount,checkpoint=enable f2fs_dir&#xA;umount f2fs_dir&#xA;&#xA;Let&#39;s redirty inode when there is not free segments during checkpoint&#xA;is disable.&#xA;CVE-2024-56615:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: fix OOB devmap writes when deleting elements&#xA;&#xA;Jordy reported issue against XSKMAP which also applies to DEVMAP - the&#xA;index used for accessing map entry, due to being a signed integer,&#xA;causes the OOB writes. Fix is simple as changing the type from int to&#xA;u32, however, when compared to XSKMAP case, one more thing needs to be&#xA;addressed.&#xA;&#xA;When map is released from system via dev_map_free(), we iterate through&#xA;all of the entries and an iterator variable is also an int, which&#xA;implies OOB accesses. Again, change it to be u32.&#xA;&#xA;Example splat below:&#xA;&#xA;[  160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000&#xA;[  160.731662] #PF: supervisor read access in kernel mode&#xA;[  160.736876] #PF: error_code(0x0000) - not-present page&#xA;[  160.742095] PGD 0 P4D 0&#xA;[  160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP&#xA;[  160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487&#xA;[  160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019&#xA;[  160.767642] Workqueue: events_unbound bpf_map_free_deferred&#xA;[  160.773308] RIP: 0010:dev_map_free+0x77/0x170&#xA;[  160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 &lt;48&gt; 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff&#xA;[  160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202&#xA;[  160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024&#xA;[  160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000&#xA;[  160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001&#xA;[  160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122&#xA;[  160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000&#xA;[  160.838310] FS:  0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000&#xA;[  160.846528] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0&#xA;[  160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  160.874092] PKRU: 55555554&#xA;[  160.876847] Call Trace:&#xA;[  160.879338]  &lt;TASK&gt;&#xA;[  160.881477]  ? __die+0x20/0x60&#xA;[  160.884586]  ? page_fault_oops+0x15a/0x450&#xA;[  160.888746]  ? search_extable+0x22/0x30&#xA;[  160.892647]  ? search_bpf_extables+0x5f/0x80&#xA;[  160.896988]  ? exc_page_fault+0xa9/0x140&#xA;[  160.900973]  ? asm_exc_page_fault+0x22/0x30&#xA;[  160.905232]  ? dev_map_free+0x77/0x170&#xA;[  160.909043]  ? dev_map_free+0x58/0x170&#xA;[  160.912857]  bpf_map_free_deferred+0x51/0x90&#xA;[  160.917196]  process_one_work+0x142/0x370&#xA;[  160.921272]  worker_thread+0x29e/0x3b0&#xA;[  160.925082]  ? rescuer_thread+0x4b0/0x4b0&#xA;[  160.929157]  kthread+0xd4/0x110&#xA;[  160.932355]  ? kthread_park+0x80/0x80&#xA;[  160.936079]  ret_from_fork+0x2d/0x50&#xA;[  160.943396]  ? kthread_park+0x80/0x80&#xA;[  160.950803]  ret_from_fork_asm+0x11/0x20&#xA;[  160.958482]  &lt;/TASK&gt;&#xA;CVE-2024-56629:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: wacom: fix when get product name maybe null pointer&#xA;&#xA;Due to incorrect dev-&gt;product reporting by certain devices, null&#xA;pointer dereferences occur when dev-&gt;product is empty, leading to&#xA;potential system crashes.&#xA;&#xA;This issue was found on EXCELSIOR DL37-D05 device with&#xA;Loongson-LS3A6000-7A2000-DL37 motherboard.&#xA;&#xA;Kernel logs:&#xA;[   56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci&#xA;[   56.671638] usb 4-3: string descriptor 0 read error: -22&#xA;[   56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07&#xA;[   56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3&#xA;[   56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0&#xA;[   56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80&#xA;[   56.697732] Oops[#1]:&#xA;[   56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G           OE      6.6.0-loong64-desktop #25.00.2000.015&#xA;[   56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024&#xA;[   56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0&#xA;[   56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000&#xA;[   56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000&#xA;[   56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005&#xA;[   56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000&#xA;[   56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028&#xA;[   56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000&#xA;[   56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000&#xA;[   56.697753]    ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]&#xA;[   56.697802]   ERA: 90000000066e35c8 strstr+0x28/0x120&#xA;[   56.697806]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)&#xA;[   56.697816]  PRMD: 0000000c (PPLV0 +PIE +PWE)&#xA;[   56.697821]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)&#xA;[   56.697827]  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)&#xA;[   56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)&#xA;[   56.697835]  BADV: 0000000000000000&#xA;[   56.697836]  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)&#xA;[   56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit&#xA;[   56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)&#xA;[   56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000&#xA;[   56.697896]         0000000000000000 00000011fffffffd 0000000000000000 0000000000000000&#xA;[   56.697901]         0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0&#xA;[   56.697906]         90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c&#xA;[   56.697911]         90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440&#xA;[   56.697916]         ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0&#xA;[   56.697921]         0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c&#xA;[   56.697926]         ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000&#xA;[   56.697931]         90000001000bb8d0 &#xA;---truncated---&#xA;CVE-2024-56691:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device&#xA;&#xA;While design wise the idea of converting the driver to use&#xA;the hierarchy of the IRQ chips is correct, the implementation&#xA;has (inherited) flaws. This was unveiled when platform_get_irq()&#xA;had started WARN() on IRQ 0 that is supposed to be a Linux&#xA;IRQ number (also known as vIRQ).&#xA;&#xA;Rework the driver to respect IRQ domain when creating each MFD&#xA;device separately, as the domain is not the same for all of them.&#xA;CVE-2024-56700:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: wl128x: Fix atomicity violation in fmc_send_cmd()&#xA;&#xA;Atomicity violation occurs when the fmc_send_cmd() function is executed&#xA;simultaneously with the modification of the fmdev-&gt;resp_skb value.&#xA;Consider a scenario where, after passing the validity check within the&#xA;function, a non-null fmdev-&gt;resp_skb variable is assigned a null value.&#xA;This results in an invalid fmdev-&gt;resp_skb variable passing the validity&#xA;check. As seen in the later part of the function, skb = fmdev-&gt;resp_skb;&#xA;when the invalid fmdev-&gt;resp_skb passes the check, a null pointer&#xA;dereference error may occur at line 478, evt_hdr = (void *)skb-&gt;data;&#xA;&#xA;To address this issue, it is recommended to include the validity check of&#xA;fmdev-&gt;resp_skb within the locked section of the function. This&#xA;modification ensures that the value of fmdev-&gt;resp_skb does not change&#xA;during the validation process, thereby maintaining its validity.&#xA;&#xA;This possible bug is found by an experimental static analysis tool&#xA;developed by our team. This tool analyzes the locking APIs&#xA;to extract function pairs that can be concurrently executed, and then&#xA;analyzes the instructions in the paired functions to identify possible&#xA;concurrency bugs including data races and atomicity violations.&#xA;CVE-2024-56692:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix to do sanity check on node blkaddr in truncate_node()&#xA;&#xA;syzbot reports a f2fs bug as below:&#xA;&#xA;------------[ cut here ]------------&#xA;kernel BUG at fs/f2fs/segment.c:2534!&#xA;RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534&#xA;Call Trace:&#xA; truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909&#xA; f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288&#xA; f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856&#xA; evict+0x4e8/0x9b0 fs/inode.c:723&#xA; f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986&#xA; f2fs_create+0x357/0x530 fs/f2fs/namei.c:394&#xA; lookup_open fs/namei.c:3595 [inline]&#xA; open_last_lookups fs/namei.c:3694 [inline]&#xA; path_openat+0x1c03/0x3590 fs/namei.c:3930&#xA; do_filp_open+0x235/0x490 fs/namei.c:3960&#xA; do_sys_openat2+0x13e/0x1d0 fs/open.c:1415&#xA; do_sys_open fs/open.c:1430 [inline]&#xA; __do_sys_openat fs/open.c:1446 [inline]&#xA; __se_sys_openat fs/open.c:1441 [inline]&#xA; __x64_sys_openat+0x247/0x2a0 fs/open.c:1441&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534&#xA;&#xA;The root cause is: on a fuzzed image, blkaddr in nat entry may be&#xA;corrupted, then it will cause system panic when using it in&#xA;f2fs_invalidate_blocks(), to avoid this, let&#39;s add sanity check on&#xA;nat blkaddr in truncate_node().&#xA;CVE-2024-56681:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: bcm - add error check in the ahash_hmac_init function&#xA;&#xA;The ahash_init functions may return fails. The ahash_hmac_init should&#xA;not return ok when ahash_init returns error. For an example, ahash_init&#xA;will return -ENOMEM when allocation memory is error.&#xA;CVE-2024-56709:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;io_uring: check if iowq is killed before queuing&#xA;&#xA;task work can be executed after the task has gone through io_uring&#xA;termination, whether it&#39;s the final task_work run or the fallback path.&#xA;In this case, task work will find -&gt;io_wq being already killed and&#xA;null&#39;ed, which is a problem if it then tries to forward the request to&#xA;io_queue_iowq(). Make io_queue_iowq() fail requests in this case.&#xA;&#xA;Note that it also checks PF_KTHREAD, because the user can first close&#xA;a DEFER_TASKRUN ring and shortly after kill the task, in which case&#xA;-&gt;iowq check would race.&#xA;CVE-2024-56748:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()&#xA;&#xA;Hook &#34;qed_ops-&gt;common-&gt;sb_init = qed_sb_init&#34; does not release the DMA&#xA;memory sb_virt when it fails. Add dma_free_coherent() to free it. This&#xA;is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().&#xA;CVE-2024-56739:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rtc: check if __rtc_read_time was successful in rtc_timer_do_work()&#xA;&#xA;If the __rtc_read_time call fails,, the struct rtc_time tm; may contain&#xA;uninitialized data, or an illegal date/time read from the RTC hardware.&#xA;&#xA;When calling rtc_tm_to_ktime later, the result may be a very large value&#xA;(possibly KTIME_MAX). If there are periodic timers in rtc-&gt;timerqueue,&#xA;they will continually expire, may causing kernel softlockup.&#xA;CVE-2024-56722:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/hns: Fix cpu stuck caused by printings during reset&#xA;&#xA;During reset, cmd to destroy resources such as qp, cq, and mr may fail,&#xA;and error logs will be printed. When a large number of resources are&#xA;destroyed, there will be lots of printings, and it may lead to a cpu&#xA;stuck.&#xA;&#xA;Delete some unnecessary printings and replace other printing functions&#xA;in these paths with the ratelimited version.&#xA;CVE-2024-56747:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()&#xA;&#xA;Hook &#34;qedi_ops-&gt;common-&gt;sb_init = qed_sb_init&#34; does not release the DMA&#xA;memory sb_virt when it fails. Add dma_free_coherent() to free it. This&#xA;is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().&#xA;CVE-2024-56756:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-pci: fix freeing of the HMB descriptor table&#xA;&#xA;The HMB descriptor table is sized to the maximum number of descriptors&#xA;that could be used for a given device, but __nvme_alloc_host_mem could&#xA;break out of the loop earlier on memory allocation failure and end up&#xA;using less descriptors than planned for, which leads to an incorrect&#xA;size passed to dma_free_coherent.&#xA;&#xA;In practice this was not showing up because the number of descriptors&#xA;tends to be low and the dma coherent allocator always allocates and&#xA;frees at least a page.&#xA;CVE-2022-49035:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE&#xA;&#xA;I expect that the hardware will have limited this to 16, but just in&#xA;case it hasn&#39;t, check for this corner case.&#xA;CVE-2024-56763:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Prevent bad count for tracing_cpumask_write&#xA;&#xA;If a large count is provided, it will trigger a warning in bitmap_parse_user.&#xA;Also check zero for it.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/kernel-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/kernel-devel-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.108.0.188.u166" version="5.10.0">
					<filename>python3-perf-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/python3-perf-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/kernel-headers-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.108.0.188.u166" version="5.10.0">
					<filename>bpftool-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/bpftool-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/kernel-tools-devel-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.108.0.188.u166" version="5.10.0">
					<filename>perf-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/perf-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/kernel-tools-5.10.0-136.108.0.188.u166.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.108.0.188.u166" version="5.10.0">
					<filename>bpftool-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/bpftool-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/kernel-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/kernel-tools-devel-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.108.0.188.u166" version="5.10.0">
					<filename>perf-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/perf-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/kernel-tools-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/kernel-headers-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.108.0.188.u166" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/kernel-devel-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.108.0.188.u166" version="5.10.0">
					<filename>python3-perf-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/python3-perf-5.10.0-136.108.0.188.u166.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2133</id>
		<title>An update for dhcp is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1975&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1975" id="CVE-2024-1975" title="CVE-2024-1975" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1737" id="CVE-2024-1737" title="CVE-2024-1737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3341&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-3341" id="CVE-2023-3341" title="CVE-2023-3341" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11187" id="CVE-2024-11187" title="CVE-2024-11187" type="cve"></reference>
		</references>
		<description>CVE-2024-1975:If a server hosts a zone containing a &#34;KEY&#34; Resource Record, or a resolver DNSSEC-validates a &#34;KEY&#34; Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.&#xA;This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.&#xA;CVE-2024-1737:Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.&#xA;CVE-2023-3341:The configuration functionality in the Intelligent Platform Management Interface (IPMI) baseboard management controller (BMC) implementation on Supermicro X11 and M11 based devices, with firmware versions through 3.17.02, allows remote authenticated users to execute arbitrary commands.&#xA;CVE-2024-11187:It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="noarch" epoch="12" name="dhcp-help" release="9.u6" version="4.4.3">
					<filename>dhcp-help-4.4.3-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/dhcp-help-4.4.3-9.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="dhcp-devel" release="9.u6" version="4.4.3">
					<filename>dhcp-devel-4.4.3-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/dhcp-devel-4.4.3-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="dhcp" release="9.u6" version="4.4.3">
					<filename>dhcp-4.4.3-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/dhcp-4.4.3-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="dhcp-devel" release="9.u6" version="4.4.3">
					<filename>dhcp-devel-4.4.3-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/dhcp-devel-4.4.3-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="dhcp" release="9.u6" version="4.4.3">
					<filename>dhcp-4.4.3-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/dhcp-4.4.3-9.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2134</id>
		<title>An update for glibc is now available for 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0395&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0395" id="CVE-2025-0395" title="CVE-2025-0395" type="cve"></reference>
		</references>
		<description>CVE-2025-0395:When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="151.u25" version="2.34">
					<filename>glibc-compat-2.17-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-compat-2.17-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="151.u25" version="2.34">
					<filename>glibc-locale-source-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-locale-source-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="151.u25" version="2.34">
					<filename>nscd-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/nscd-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="151.u25" version="2.34">
					<filename>glibc-common-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-common-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="151.u25" version="2.34">
					<filename>glibc-nss-devel-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-nss-devel-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="151.u25" version="2.34">
					<filename>glibc-devel-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-devel-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="151.u25" version="2.34">
					<filename>nss_modules-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/nss_modules-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="151.u25" version="2.34">
					<filename>glibc-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="151.u25" version="2.34">
					<filename>glibc-all-langpacks-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-all-langpacks-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="151.u25" version="2.34">
					<filename>glibc-locale-archive-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-locale-archive-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="151.u25" version="2.34">
					<filename>libnsl-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/libnsl-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="151.u25" version="2.34">
					<filename>glibc-debugutils-2.34-151.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/glibc-debugutils-2.34-151.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="151.u25" version="2.34">
					<filename>glibc-help-2.34-151.u25.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-help-2.34-151.u25.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="151.u25" version="2.34">
					<filename>glibc-all-langpacks-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-all-langpacks-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="151.u25" version="2.34">
					<filename>glibc-compat-2.17-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-compat-2.17-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="151.u25" version="2.34">
					<filename>glibc-locale-archive-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-locale-archive-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="151.u25" version="2.34">
					<filename>glibc-debugutils-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-debugutils-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="151.u25" version="2.34">
					<filename>libnsl-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/libnsl-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="151.u25" version="2.34">
					<filename>glibc-common-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-common-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="151.u25" version="2.34">
					<filename>glibc-devel-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-devel-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="151.u25" version="2.34">
					<filename>nss_modules-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/nss_modules-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc" release="151.u25" version="2.34">
					<filename>glibc-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="151.u25" version="2.34">
					<filename>nscd-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/nscd-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="151.u25" version="2.34">
					<filename>glibc-nss-devel-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-nss-devel-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="151.u25" version="2.34">
					<filename>glibc-locale-source-2.34-151.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/glibc-locale-source-2.34-151.u25.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2135</id>
		<title>An update for krb5 is now available for 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-04-11"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24528&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-24528" id="CVE-2025-24528" title="CVE-2025-24528" type="cve"></reference>
		</references>
		<description>CVE-2025-24528:In MIT krb5 release 1.7 and later with incremental propagation&#xA;enabled, an authenticated attacker can cause kadmind to write beyond&#xA;the end of the mapped region for the iprop log file, likely causing a&#xA;process crash.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1</name>
				<package arch="x86_64" epoch="0" name="krb5-client" release="24.u11" version="1.19.2">
					<filename>krb5-client-1.19.2-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/krb5-client-1.19.2-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-devel" release="24.u11" version="1.19.2">
					<filename>krb5-devel-1.19.2-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/krb5-devel-1.19.2-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-libs" release="24.u11" version="1.19.2">
					<filename>krb5-libs-1.19.2-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/krb5-libs-1.19.2-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-server" release="24.u11" version="1.19.2">
					<filename>krb5-server-1.19.2-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/krb5-server-1.19.2-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5" release="24.u11" version="1.19.2">
					<filename>krb5-1.19.2-24.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/krb5-1.19.2-24.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5" release="24.u11" version="1.19.2">
					<filename>krb5-1.19.2-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/krb5-1.19.2-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-devel" release="24.u11" version="1.19.2">
					<filename>krb5-devel-1.19.2-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/krb5-devel-1.19.2-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-libs" release="24.u11" version="1.19.2">
					<filename>krb5-libs-1.19.2-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/krb5-libs-1.19.2-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-server" release="24.u11" version="1.19.2">
					<filename>krb5-server-1.19.2-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/krb5-server-1.19.2-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-client" release="24.u11" version="1.19.2">
					<filename>krb5-client-1.19.2-24.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1/krb5-client-1.19.2-24.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="krb5-help" release="24.u11" version="1.19.2">
					<filename>krb5-help-1.19.2-24.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1/krb5-help-1.19.2-24.u11.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2136</id>
		<title>An update for coreutils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5278&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5278" id="CVE-2025-5278" title="CVE-2025-5278" type="cve"></reference>
		</references>
		<description>CVE-2025-5278:A flaw was found in GNU Coreutils. The sort utility&#39;s begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="coreutils-help" release="20.u7" version="9.0">
					<filename>coreutils-help-9.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/coreutils-help-9.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="coreutils" release="20.u7" version="9.0">
					<filename>coreutils-9.0-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/coreutils-9.0-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="coreutils" release="20.u7" version="9.0">
					<filename>coreutils-9.0-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/coreutils-9.0-20.u7.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2137</id>
		<title>An update for bind-dyndb-ldap is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1737" id="CVE-2024-1737" title="CVE-2024-1737" type="cve"></reference>
		</references>
		<description>CVE-2024-1737:Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="bind-dyndb-ldap" release="3.u1" version="11.10">
					<filename>bind-dyndb-ldap-11.10-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-dyndb-ldap-11.10-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bind-dyndb-ldap" release="3.u1" version="11.10">
					<filename>bind-dyndb-ldap-11.10-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-dyndb-ldap-11.10-3.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2138</id>
		<title>An update for python-jwcrypto is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28102&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-28102" id="CVE-2024-28102" title="CVE-2024-28102" type="cve"></reference>
		</references>
		<description>CVE-2024-28102:JWCrypto implements JWK, JWS, and JWE specifications using python-cryptography. Prior to version 1.5.6, an attacker can cause a denial of service attack by passing in a malicious JWE Token with a high compression ratio. When the server processes this token, it will consume a lot of memory and processing time. Version 1.5.6 fixes this vulnerability by limiting the maximum token length.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="python3-jwcrypto" release="3.u2" version="1.4.2">
					<filename>python3-jwcrypto-1.4.2-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-jwcrypto-1.4.2-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2139</id>
		<title>An update for python-setuptools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47273&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47273" id="CVE-2025-47273" title="CVE-2025-47273" type="cve"></reference>
		</references>
		<description>CVE-2025-47273:setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="python-setuptools" release="6.u3" version="59.4.0">
					<filename>python-setuptools-59.4.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python-setuptools-59.4.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-setuptools-help" release="6.u3" version="59.4.0">
					<filename>python-setuptools-help-59.4.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python-setuptools-help-59.4.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-setuptools" release="6.u3" version="59.4.0">
					<filename>python3-setuptools-59.4.0-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-setuptools-59.4.0-6.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2140</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40909&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40909" id="CVE-2025-40909" title="CVE-2025-40909" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56406&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56406" id="CVE-2024-56406" title="CVE-2024-56406" type="cve"></reference>
		</references>
		<description>CVE-2025-40909:Perl threads have a working directory race condition where file operations may target unintended paths.&#xA;&#xA;If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. &#xA;&#xA;This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.&#xA;&#xA;The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6&#xA;CVE-2024-56406:A heap buffer overflow vulnerability was discovered in Perl. &#xA;&#xA;Release branches 5.34, 5.36, 5.38 and 5.40 are affected, including development versions from 5.33.1 through 5.41.10.&#xA;&#xA;When there are non-ASCII bytes in the left-hand-side of the `tr` operator, `S_do_trans_invmap` can overflow the destination pointer `d`.&#xA;&#xA;   $ perl -e &#39;$_ = &#34;\x{FF}&#34; x 1000000; tr/\xFF/\x{100}/;&#39; &#xA;   Segmentation fault (core dumped)&#xA;&#xA;It is believed that this vulnerability can enable Denial of Service and possibly Code Execution attacks on platforms that lack sufficient defenses.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="4" name="perl-devel" release="14.u8" version="5.34.0">
					<filename>perl-devel-5.34.0-14.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-devel-5.34.0-14.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl-libs" release="14.u8" version="5.34.0">
					<filename>perl-libs-5.34.0-14.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-libs-5.34.0-14.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="perl" release="14.u8" version="5.34.0">
					<filename>perl-5.34.0-14.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-5.34.0-14.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="4" name="perl-help" release="14.u8" version="5.34.0">
					<filename>perl-help-5.34.0-14.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-help-5.34.0-14.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-devel" release="14.u8" version="5.34.0">
					<filename>perl-devel-5.34.0-14.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-devel-5.34.0-14.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl-libs" release="14.u8" version="5.34.0">
					<filename>perl-libs-5.34.0-14.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-libs-5.34.0-14.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="perl" release="14.u8" version="5.34.0">
					<filename>perl-5.34.0-14.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-5.34.0-14.u8.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2141</id>
		<title>An update for yelp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3155&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3155" id="CVE-2025-3155" title="CVE-2025-3155" type="cve"></reference>
		</references>
		<description>CVE-2025-3155:A flaw was found in Yelp. The Gnome user help application allows the help document to execute arbitrary scripts. This vulnerability allows malicious users to input help documents, which may exfiltrate user files to an external environment.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="2" name="yelp" release="2.u1" version="3.38.3">
					<filename>yelp-3.38.3-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/yelp-3.38.3-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="yelp-devel" release="2.u1" version="3.38.3">
					<filename>yelp-devel-3.38.3-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/yelp-devel-3.38.3-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="yelp" release="2.u1" version="3.38.3">
					<filename>yelp-3.38.3-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/yelp-3.38.3-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="yelp-devel" release="2.u1" version="3.38.3">
					<filename>yelp-devel-3.38.3-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/yelp-devel-3.38.3-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="yelp-help" release="2.u1" version="3.38.3">
					<filename>yelp-help-3.38.3-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/yelp-help-3.38.3-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2142</id>
		<title>An update for jose is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50967&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-50967" id="CVE-2023-50967" title="CVE-2023-50967" type="cve"></reference>
		</references>
		<description>CVE-2023-50967:latchset jose through version 11 allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="jose-help" release="3.u2" version="11">
					<filename>jose-help-11-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/jose-help-11-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jose" release="3.u2" version="11">
					<filename>jose-11-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/jose-11-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jose-devel" release="3.u2" version="11">
					<filename>jose-devel-11-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/jose-devel-11-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jose" release="3.u2" version="11">
					<filename>jose-11-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/jose-11-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jose-help" release="3.u2" version="11">
					<filename>jose-help-11-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/jose-help-11-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jose-devel" release="3.u2" version="11">
					<filename>jose-devel-11-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/jose-devel-11-3.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2143</id>
		<title>An update for fcgi is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23016&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23016" id="CVE-2025-23016" title="CVE-2025-23016" type="cve"></reference>
		</references>
		<description>CVE-2025-23016:FastCGI fcgi2 (aka fcgi) 2.x through 2.4.4 has an integer overflow (and resultant heap-based buffer overflow) via crafted nameLen or valueLen values in data to the IPC socket. This occurs in ReadParams in fcgiapp.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="fcgi" release="2.u1" version="2.4.2">
					<filename>fcgi-2.4.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/fcgi-2.4.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fcgi-devel" release="2.u1" version="2.4.2">
					<filename>fcgi-devel-2.4.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/fcgi-devel-2.4.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fcgi" release="2.u1" version="2.4.2">
					<filename>fcgi-2.4.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/fcgi-2.4.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fcgi-devel" release="2.u1" version="2.4.2">
					<filename>fcgi-devel-2.4.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/fcgi-devel-2.4.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2144</id>
		<title>An update for mongo-c-driver is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6381&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6381" id="CVE-2024-6381" title="CVE-2024-6381" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6383&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6383" id="CVE-2024-6383" title="CVE-2024-6383" type="cve"></reference>
		</references>
		<description>CVE-2024-6381:The bson_strfreev function in the MongoDB C driver library may be susceptible to an integer overflow where the function will try to free memory at a negative offset. This may result in memory corruption. This issue affected libbson versions prior to 1.26.2&#xA;CVE-2024-6383:The bson_string_append function in MongoDB C Driver may be vulnerable to a buffer overflow where the function might attempt to allocate too small of buffer and may lead to memory corruption of neighbouring heap memory. This issue affects libbson versions prior to 1.27.1&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="mongo-c-driver" release="1.u1" version="1.27.4">
					<filename>mongo-c-driver-1.27.4-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mongo-c-driver-1.27.4-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mongo-c-driver-help" release="1.u1" version="1.27.4">
					<filename>mongo-c-driver-help-1.27.4-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mongo-c-driver-help-1.27.4-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libbson" release="1.u1" version="1.27.4">
					<filename>libbson-1.27.4-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libbson-1.27.4-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libbson-devel" release="1.u1" version="1.27.4">
					<filename>libbson-devel-1.27.4-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libbson-devel-1.27.4-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mongo-c-driver-devel" release="1.u1" version="1.27.4">
					<filename>mongo-c-driver-devel-1.27.4-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mongo-c-driver-devel-1.27.4-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libbson-devel" release="1.u1" version="1.27.4">
					<filename>libbson-devel-1.27.4-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libbson-devel-1.27.4-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libbson" release="1.u1" version="1.27.4">
					<filename>libbson-1.27.4-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libbson-1.27.4-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mongo-c-driver-help" release="1.u1" version="1.27.4">
					<filename>mongo-c-driver-help-1.27.4-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mongo-c-driver-help-1.27.4-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mongo-c-driver-devel" release="1.u1" version="1.27.4">
					<filename>mongo-c-driver-devel-1.27.4-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mongo-c-driver-devel-1.27.4-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mongo-c-driver" release="1.u1" version="1.27.4">
					<filename>mongo-c-driver-1.27.4-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mongo-c-driver-1.27.4-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2145</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43857" id="CVE-2025-43857" title="CVE-2025-43857" type="cve"></reference>
		</references>
		<description>CVE-2025-43857:Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &#34;literal&#34; byte count, which is automatically read by the client&#39;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="143.u17" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-openssl-2.2.1-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="143.u17" version="2.5.1">
					<filename>rubygem-json-2.5.1-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-json-2.5.1-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby" release="143.u17" version="3.0.3">
					<filename>ruby-3.0.3-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ruby-3.0.3-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="143.u17" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-bigdecimal-3.0.0-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="143.u17" version="3.3.2">
					<filename>rubygem-psych-3.3.2-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-psych-3.3.2-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="143.u17" version="3.0.3">
					<filename>ruby-devel-3.0.3-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ruby-devel-3.0.3-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="143.u17" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-143.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-io-console-0.5.7-143.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="143.u17" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-test-unit-3.3.7-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="143.u17" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-rdoc-6.3.3-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="143.u17" version="3.0.3">
					<filename>ruby-help-3.0.3-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ruby-help-3.0.3-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="143.u17" version="0.2.9">
					<filename>rubygem-rss-0.2.9-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-rss-0.2.9-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="143.u17" version="3.0.3">
					<filename>ruby-irb-3.0.3-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ruby-irb-3.0.3-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="143.u17" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-rbs-1.4.0-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="143.u17" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-typeprof-0.15.2-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="143.u17" version="13.0.3">
					<filename>rubygem-rake-13.0.3-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-rake-13.0.3-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="143.u17" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-rexml-3.2.5-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="143.u17" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-did_you_mean-1.5.0-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="143.u17" version="3.2.32">
					<filename>rubygems-devel-3.2.32-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygems-devel-3.2.32-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="143.u17" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygem-minitest-5.14.2-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="143.u17" version="3.2.32">
					<filename>rubygems-3.2.32-143.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/rubygems-3.2.32-143.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="143.u17" version="2.5.1">
					<filename>rubygem-json-2.5.1-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/rubygem-json-2.5.1-143.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="143.u17" version="3.0.3">
					<filename>ruby-3.0.3-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ruby-3.0.3-143.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="143.u17" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/rubygem-bigdecimal-3.0.0-143.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="143.u17" version="3.0.3">
					<filename>ruby-devel-3.0.3-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ruby-devel-3.0.3-143.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="143.u17" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/rubygem-openssl-2.2.1-143.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="143.u17" version="3.3.2">
					<filename>rubygem-psych-3.3.2-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/rubygem-psych-3.3.2-143.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="143.u17" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-143.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/rubygem-io-console-0.5.7-143.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2146</id>
		<title>An update for ppp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58250&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58250" id="CVE-2024-58250" title="CVE-2024-58250" type="cve"></reference>
		</references>
		<description>CVE-2024-58250:The passprompt plugin in pppd in ppp before 2.5.2 mishandles privileges.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="ppp-help" release="8.u6" version="2.4.9">
					<filename>ppp-help-2.4.9-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ppp-help-2.4.9-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ppp" release="8.u6" version="2.4.9">
					<filename>ppp-2.4.9-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ppp-2.4.9-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ppp-devel" release="8.u6" version="2.4.9">
					<filename>ppp-devel-2.4.9-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ppp-devel-2.4.9-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ppp" release="8.u6" version="2.4.9">
					<filename>ppp-2.4.9-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ppp-2.4.9-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ppp-devel" release="8.u6" version="2.4.9">
					<filename>ppp-devel-2.4.9-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ppp-devel-2.4.9-8.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2147</id>
		<title>An update for augeas is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2588&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2588" id="CVE-2025-2588" title="CVE-2025-2588" type="cve"></reference>
		</references>
		<description>CVE-2025-2588:A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="augeas" release="6.u2" version="1.13.0">
					<filename>augeas-1.13.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/augeas-1.13.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="augeas-devel" release="6.u2" version="1.13.0">
					<filename>augeas-devel-1.13.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/augeas-devel-1.13.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="augeas" release="6.u2" version="1.13.0">
					<filename>augeas-1.13.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/augeas-1.13.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="augeas-devel" release="6.u2" version="1.13.0">
					<filename>augeas-devel-1.13.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/augeas-devel-1.13.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="augeas-help" release="6.u2" version="1.13.0">
					<filename>augeas-help-1.13.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/augeas-help-1.13.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2148</id>
		<title>An update for perl-YAML-LibYAML is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40908&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40908" id="CVE-2025-40908" title="CVE-2025-40908" type="cve"></reference>
		</references>
		<description>CVE-2025-40908:YAML-LibYAML prior to 0.903.0 for Perl uses 2-args open, allowing existing files to be modified&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="1" name="perl-YAML-LibYAML" release="2.u1" version="0.83">
					<filename>perl-YAML-LibYAML-0.83-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-YAML-LibYAML-0.83-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="perl-YAML-LibYAML-help" release="2.u1" version="0.83">
					<filename>perl-YAML-LibYAML-help-0.83-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-YAML-LibYAML-help-0.83-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-YAML-LibYAML" release="2.u1" version="0.83">
					<filename>perl-YAML-LibYAML-0.83-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-YAML-LibYAML-0.83-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-YAML-LibYAML-help" release="2.u1" version="0.83">
					<filename>perl-YAML-LibYAML-help-0.83-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-YAML-LibYAML-help-0.83-2.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2149</id>
		<title>An update for gnupg2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30258&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30258" id="CVE-2025-30258" title="CVE-2025-30258" type="cve"></reference>
		</references>
		<description>CVE-2025-30258:In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a &#34;verification DoS.&#34;&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="gnupg2-help" release="7.u4" version="2.2.32">
					<filename>gnupg2-help-2.2.32-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gnupg2-help-2.2.32-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnupg2" release="7.u4" version="2.2.32">
					<filename>gnupg2-2.2.32-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/gnupg2-2.2.32-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnupg2" release="7.u4" version="2.2.32">
					<filename>gnupg2-2.2.32-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gnupg2-2.2.32-7.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2150</id>
		<title>An update for hdf5 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13871&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-13871" id="CVE-2018-13871" title="CVE-2018-13871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13875&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-13875" id="CVE-2018-13875" title="CVE-2018-13875" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-14034" id="CVE-2018-14034" title="CVE-2018-14034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32622&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32622" id="CVE-2024-32622" title="CVE-2024-32622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32620&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32620" id="CVE-2024-32620" title="CVE-2024-32620" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33875&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-33875" id="CVE-2024-33875" title="CVE-2024-33875" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29157" id="CVE-2024-29157" title="CVE-2024-29157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32618&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32618" id="CVE-2024-32618" title="CVE-2024-32618" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32623&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32623" id="CVE-2024-32623" title="CVE-2024-32623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32616&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32616" id="CVE-2024-32616" title="CVE-2024-32616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32619&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32619" id="CVE-2024-32619" title="CVE-2024-32619" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32621&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32621" id="CVE-2024-32621" title="CVE-2024-32621" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33877&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-33877" id="CVE-2024-33877" title="CVE-2024-33877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32617&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32617" id="CVE-2024-32617" title="CVE-2024-32617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32615" id="CVE-2024-32615" title="CVE-2024-32615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32612&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32612" id="CVE-2024-32612" title="CVE-2024-32612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32614&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32614" id="CVE-2024-32614" title="CVE-2024-32614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32624&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32624" id="CVE-2024-32624" title="CVE-2024-32624" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32613&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32613" id="CVE-2024-32613" title="CVE-2024-32613" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33873&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-33873" id="CVE-2024-33873" title="CVE-2024-33873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33874&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-33874" id="CVE-2024-33874" title="CVE-2024-33874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33876&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-33876" id="CVE-2024-33876" title="CVE-2024-33876" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29158" id="CVE-2024-29158" title="CVE-2024-29158" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29165&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29165" id="CVE-2024-29165" title="CVE-2024-29165" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29159&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29159" id="CVE-2024-29159" title="CVE-2024-29159" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29163&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29163" id="CVE-2024-29163" title="CVE-2024-29163" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29160" id="CVE-2024-29160" title="CVE-2024-29160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29164&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29164" id="CVE-2024-29164" title="CVE-2024-29164" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29162&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29162" id="CVE-2024-29162" title="CVE-2024-29162" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29161" id="CVE-2024-29161" title="CVE-2024-29161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29166&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29166" id="CVE-2024-29166" title="CVE-2024-29166" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32610&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32610" id="CVE-2024-32610" title="CVE-2024-32610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32611" id="CVE-2024-32611" title="CVE-2024-32611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32606&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32606" id="CVE-2024-32606" title="CVE-2024-32606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32607&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32607" id="CVE-2024-32607" title="CVE-2024-32607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32609&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32609" id="CVE-2024-32609" title="CVE-2024-32609" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32605&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32605" id="CVE-2024-32605" title="CVE-2024-32605" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32608&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-32608" id="CVE-2024-32608" title="CVE-2024-32608" type="cve"></reference>
		</references>
		<description>CVE-2018-13871:An issue was discovered in the HDF HDF5 1.8.20 library. There is a heap-based buffer overflow in the function H5FL_blk_malloc in H5FL.c.&#xA;CVE-2018-13875:An issue was discovered in the HDF HDF5 1.8.20 library. There is an out-of-bounds read in the function H5VM_memcpyvv in H5VM.c.&#xA;CVE-2018-14034:An issue was discovered in the HDF HDF5 1.8.20 library. There is an out of bounds read in the function H5O_pline_reset in H5Opline.c.&#xA;CVE-2024-32622:HDF5 Library through 1.14.3 contains a out-of-bounds read operation in H5FL_arr_malloc in H5FL.c (called from H5S_set_extent_simple in H5S.c).&#xA;CVE-2024-32620:HDF5 Library through 1.14.3 contains a heap-based buffer over-read in H5F_addr_decode_len in H5Fint.c, resulting in the corruption of the instruction pointer.&#xA;CVE-2024-33875:HDF5 Library through 1.14.3 has a heap-based buffer overflow in H5O__layout_encode in H5Olayout.c, resulting in the corruption of the instruction pointer.&#xA;CVE-2024-29157:HDF5 through 1.14.3 contains a heap buffer overflow in H5HG_read, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-32618:HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5T__get_native_type in H5Tnative.c, resulting in the corruption of the instruction pointer.&#xA;CVE-2024-32623:HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5VM_array_fill in H5VM.c (called from H5S_select_elements in H5Spoint.c).&#xA;CVE-2024-32616:HDF5 Library through 1.14.3 contains a heap-based buffer over-read in H5O__dtype_encode_helper in H5Odtype.c.&#xA;CVE-2024-32619:HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5T_copy_reopen in H5T.c, resulting in the corruption of the instruction pointer.&#xA;CVE-2024-32621:HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5HG_read in H5HG.c (called from H5VL__native_blob_get in H5VLnative_blob.c), resulting in the corruption of the instruction pointer.&#xA;CVE-2024-33877:HDF5 Library through 1.14.3 has a heap-based buffer overflow in H5T__conv_struct_opt in H5Tconv.c.&#xA;CVE-2024-32617:HDF5 Library through 1.14.3 contains a heap-based buffer over-read caused by the unsafe use of strdup in H5MM_xstrdup in H5MM.c (called from H5G__ent_to_link in H5Glink.c).&#xA;CVE-2024-32615:HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5Z__nbit_decompress_one_byte in H5Znbit.c, caused by the earlier use of an initialized pointer.&#xA;CVE-2024-32612:HDF5 Library through 1.14.3 contains a heap-based buffer over-read in H5HL__fl_deserialize in H5HLcache.c, resulting in the corruption of the instruction pointer, a different vulnerability than CVE-2024-32613.&#xA;CVE-2024-32614:HDF5 Library through 1.14.3 has a SEGV in H5VM_memcpyvv in H5VM.c.&#xA;CVE-2024-32624:HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5T__ref_mem_setnull in H5Tref.c (called from H5T__conv_ref in H5Tconv.c), resulting in the corruption of the instruction pointer.&#xA;CVE-2024-32613:HDF5 Library through 1.14.3 contains a heap-based buffer over-read in the function H5HL__fl_deserialize in H5HLcache.c, a different vulnerability than CVE-2024-32612.&#xA;CVE-2024-33873:HDF5 Library through 1.14.3 has a heap-based buffer overflow in H5D__scatter_mem in H5Dscatgath.c.&#xA;CVE-2024-33874:HDF5 Library through 1.14.3 has a heap buffer overflow in H5O__mtime_new_encode in H5Omtime.c.&#xA;CVE-2024-33876:HDF5 Library through 1.14.3 has a heap buffer overflow in H5S__point_deserialize in H5Spoint.c.&#xA;CVE-2024-29158:HDF5 through 1.14.3 contains a stack buffer overflow in H5FL_arr_malloc, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29165:HDF5 through 1.14.3 contains a buffer overflow in H5Z__filter_fletcher32, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29159:HDF5 through 1.14.3 contains a buffer overflow in H5Z__filter_scaleoffset, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29163:HDF5 through 1.14.3 contains a heap buffer overflow in H5T__bit_find, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29160:HDF5 through 1.14.3 contains a heap buffer overflow in H5HG__cache_heap_deserialize, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29164:HDF5 through 1.14.3 contains a stack buffer overflow in H5R__decode_heap, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29162:HDF5 through 1.13.3 and/or 1.14.2 contains a stack buffer overflow in H5HG_read, resulting in denial of service or potential code execution.&#xA;CVE-2024-29161:HDF5 through 1.14.3 contains a heap buffer overflow in H5A__attr_release_table, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-29166:HDF5 through 1.14.3 contains a buffer overflow in H5O__linfo_decode, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;CVE-2024-32610:HDF5 Library through 1.14.3 has a SEGV in H5T_close_real in H5T.c, resulting in a corrupted instruction pointer.&#xA;CVE-2024-32611:HDF5 Library through 1.14.3 may use an uninitialized value in H5A__attr_release_table in H5Aint.c.&#xA;CVE-2024-32606:HDF5 Library through 1.14.3 may attempt to dereference uninitialized values in h5tools_str_sprint in tools/lib/h5tools_str.c (called from h5tools_dump_simple_data in tools/lib/h5tools_dump.c).&#xA;CVE-2024-32607:HDF5 Library through 1.14.3 has a SEGV in H5A__close in H5Aint.c, resulting in the corruption of the instruction pointer.&#xA;CVE-2024-32609:HDF5 Library through 1.14.3 allows stack consumption in the function H5E_printf_stack in H5Eint.c.&#xA;CVE-2024-32605:HDF5 Library through 1.14.3 has a heap-based buffer over-read in H5VM_memcpyvv in H5VM.c (called from H5D__compact_readvv in H5Dcompact.c).&#xA;CVE-2024-32608:HDF5 library through 1.14.3 has memory corruption in H5A__close resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="hdf5-mpich" release="1.u4" version="1.14.5">
					<filename>hdf5-mpich-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-mpich-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-static" release="1.u4" version="1.14.5">
					<filename>hdf5-openmpi-static-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-openmpi-static-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-devel" release="1.u4" version="1.14.5">
					<filename>hdf5-devel-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-devel-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-devel" release="1.u4" version="1.14.5">
					<filename>hdf5-openmpi-devel-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-openmpi-devel-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi" release="1.u4" version="1.14.5">
					<filename>hdf5-openmpi-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-openmpi-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-devel" release="1.u4" version="1.14.5">
					<filename>hdf5-mpich-devel-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-mpich-devel-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-static" release="1.u4" version="1.14.5">
					<filename>hdf5-mpich-static-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-mpich-static-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5" release="1.u4" version="1.14.5">
					<filename>hdf5-1.14.5-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/hdf5-1.14.5-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5" release="1.u4" version="1.14.5">
					<filename>hdf5-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-devel" release="1.u4" version="1.14.5">
					<filename>hdf5-mpich-devel-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-mpich-devel-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-static" release="1.u4" version="1.14.5">
					<filename>hdf5-openmpi-static-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-openmpi-static-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi" release="1.u4" version="1.14.5">
					<filename>hdf5-openmpi-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-openmpi-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-devel" release="1.u4" version="1.14.5">
					<filename>hdf5-devel-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-devel-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-static" release="1.u4" version="1.14.5">
					<filename>hdf5-mpich-static-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-mpich-static-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich" release="1.u4" version="1.14.5">
					<filename>hdf5-mpich-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-mpich-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-devel" release="1.u4" version="1.14.5">
					<filename>hdf5-openmpi-devel-1.14.5-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/hdf5-openmpi-devel-1.14.5-1.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2151</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0480&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-0480" id="CVE-2022-0480" title="CVE-2022-0480" type="cve"></reference>
		</references>
		<description>CVE-2022-0480:A flaw was found in the filelock_init in fs/locks.c function in the Linux kernel. This issue can lead to host memory exhaustion due to memcg not limiting the number of Portable Operating System Interface (POSIX) file locks.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/kernel-devel-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.108.0.188.u168" version="5.10.0">
					<filename>bpftool-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bpftool-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/kernel-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.108.0.188.u168" version="5.10.0">
					<filename>python3-perf-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-perf-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/kernel-tools-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/kernel-headers-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/kernel-tools-devel-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.108.0.188.u168" version="5.10.0">
					<filename>perf-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perf-5.10.0-136.108.0.188.u168.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.108.0.188.u168" version="5.10.0">
					<filename>bpftool-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bpftool-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.108.0.188.u168" version="5.10.0">
					<filename>python3-perf-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/python3-perf-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/kernel-headers-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.108.0.188.u168" version="5.10.0">
					<filename>perf-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perf-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/kernel-tools-devel-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/kernel-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/kernel-devel-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.108.0.188.u168" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/kernel-tools-5.10.0-136.108.0.188.u168.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2152</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32728" id="CVE-2025-32728" title="CVE-2025-32728" type="cve"></reference>
		</references>
		<description>CVE-2025-32728:In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="openssh-help" release="35.u27" version="8.8p1">
					<filename>openssh-help-8.8p1-35.u27.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/openssh-help-8.8p1-35.u27.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.35.u27" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.35.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/pam_ssh_agent_auth-0.10.4-4.35.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="35.u27" version="8.8p1">
					<filename>openssh-clients-8.8p1-35.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/openssh-clients-8.8p1-35.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="35.u27" version="8.8p1">
					<filename>openssh-keycat-8.8p1-35.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/openssh-keycat-8.8p1-35.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="35.u27" version="8.8p1">
					<filename>openssh-server-8.8p1-35.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/openssh-server-8.8p1-35.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="35.u27" version="8.8p1">
					<filename>openssh-8.8p1-35.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/openssh-8.8p1-35.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="35.u27" version="8.8p1">
					<filename>openssh-askpass-8.8p1-35.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/openssh-askpass-8.8p1-35.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh" release="35.u27" version="8.8p1">
					<filename>openssh-8.8p1-35.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/openssh-8.8p1-35.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="35.u27" version="8.8p1">
					<filename>openssh-askpass-8.8p1-35.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/openssh-askpass-8.8p1-35.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="35.u27" version="8.8p1">
					<filename>openssh-clients-8.8p1-35.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/openssh-clients-8.8p1-35.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="35.u27" version="8.8p1">
					<filename>openssh-keycat-8.8p1-35.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/openssh-keycat-8.8p1-35.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.35.u27" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.35.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/pam_ssh_agent_auth-0.10.4-4.35.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="35.u27" version="8.8p1">
					<filename>openssh-server-8.8p1-35.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/openssh-server-8.8p1-35.u27.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2153</id>
		<title>An update for perl-FCGI is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40907&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40907" id="CVE-2025-40907" title="CVE-2025-40907" type="cve"></reference>
		</references>
		<description>CVE-2025-40907:FCGI versions 0.44 through 0.82, for Perl, include a vulnerable version of the FastCGI fcgi2 (aka fcgi) library.&#xA;&#xA;The included FastCGI library is affected by  CVE-2025-23016, causing an integer overflow (and resultant heap-based buffer overflow) via crafted nameLen or valueLen values in data to the IPC socket. This occurs in ReadParams in fcgiapp.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="1" name="perl-FCGI" release="14.u2" version="0.78">
					<filename>perl-FCGI-0.78-14.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-FCGI-0.78-14.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="perl-FCGI-help" release="14.u2" version="0.78">
					<filename>perl-FCGI-help-0.78-14.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/perl-FCGI-help-0.78-14.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-FCGI" release="14.u2" version="0.78">
					<filename>perl-FCGI-0.78-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-FCGI-0.78-14.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-FCGI-help" release="14.u2" version="0.78">
					<filename>perl-FCGI-help-0.78-14.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/perl-FCGI-help-0.78-14.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2154</id>
		<title>An update for cifs-utils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2312&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2312" id="CVE-2025-2312" title="CVE-2025-2312" type="cve"></reference>
		</references>
		<description>CVE-2025-2312:A flaw was found in cifs-utils. When trying to obtain Kerberos credentials, the cifs.upcall program from the cifs-utils package makes an upcall to the wrong namespace in containerized environments. This issue may lead to disclosing sensitive data from the host&#39;s Kerberos credentials cache.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="cifs-utils-devel" release="4.u2" version="6.14">
					<filename>cifs-utils-devel-6.14-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/cifs-utils-devel-6.14-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cifs-utils-help" release="4.u2" version="6.14">
					<filename>cifs-utils-help-6.14-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/cifs-utils-help-6.14-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cifs-utils" release="4.u2" version="6.14">
					<filename>cifs-utils-6.14-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/cifs-utils-6.14-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cifs-utils-devel" release="4.u2" version="6.14">
					<filename>cifs-utils-devel-6.14-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/cifs-utils-devel-6.14-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cifs-utils" release="4.u2" version="6.14">
					<filename>cifs-utils-6.14-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/cifs-utils-6.14-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cifs-utils-help" release="4.u2" version="6.14">
					<filename>cifs-utils-help-6.14-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/cifs-utils-help-6.14-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2155</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4802&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4802" id="CVE-2025-4802" title="CVE-2025-4802" type="cve"></reference>
		</references>
		<description>CVE-2025-4802:Untrusted LD_LIBRARY_PATH environment variable vulnerability in the GNU C Library version 2.27 to 2.38 allows attacker controlled loading of dynamically shared library in statically compiled setuid binaries that call dlopen (including internal dlopen calls after setlocale or calls to NSS functions such as getaddrinfo).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="151.u26" version="2.34">
					<filename>glibc-compat-2.17-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-compat-2.17-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="151.u26" version="2.34">
					<filename>nscd-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/nscd-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="151.u26" version="2.34">
					<filename>glibc-locale-archive-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-locale-archive-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="151.u26" version="2.34">
					<filename>glibc-locale-source-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-locale-source-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="151.u26" version="2.34">
					<filename>glibc-devel-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-devel-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="151.u26" version="2.34">
					<filename>nss_modules-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/nss_modules-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="151.u26" version="2.34">
					<filename>glibc-common-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-common-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="151.u26" version="2.34">
					<filename>glibc-nss-devel-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-nss-devel-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="151.u26" version="2.34">
					<filename>glibc-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="151.u26" version="2.34">
					<filename>glibc-debugutils-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-debugutils-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="151.u26" version="2.34">
					<filename>libnsl-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libnsl-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="151.u26" version="2.34">
					<filename>glibc-all-langpacks-2.34-151.u26.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glibc-all-langpacks-2.34-151.u26.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="151.u26" version="2.34">
					<filename>glibc-nss-devel-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-nss-devel-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="151.u26" version="2.34">
					<filename>libnsl-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libnsl-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="151.u26" version="2.34">
					<filename>glibc-locale-source-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-locale-source-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="151.u26" version="2.34">
					<filename>nscd-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/nscd-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="151.u26" version="2.34">
					<filename>glibc-locale-archive-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-locale-archive-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="151.u26" version="2.34">
					<filename>glibc-all-langpacks-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-all-langpacks-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="151.u26" version="2.34">
					<filename>glibc-common-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-common-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="151.u26" version="2.34">
					<filename>nss_modules-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/nss_modules-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc" release="151.u26" version="2.34">
					<filename>glibc-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="151.u26" version="2.34">
					<filename>glibc-compat-2.17-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-compat-2.17-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="151.u26" version="2.34">
					<filename>glibc-debugutils-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-debugutils-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="151.u26" version="2.34">
					<filename>glibc-devel-2.34-151.u26.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-devel-2.34-151.u26.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="151.u26" version="2.34">
					<filename>glibc-help-2.34-151.u26.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glibc-help-2.34-151.u26.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2156</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28956&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-28956" id="CVE-2024-28956" title="CVE-2024-28956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24495&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-24495" id="CVE-2025-24495" title="CVE-2025-24495" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20012&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-20012" id="CVE-2025-20012" title="CVE-2025-20012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45332&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45332" id="CVE-2024-45332" title="CVE-2024-45332" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20623&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-20623" id="CVE-2025-20623" title="CVE-2025-20623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43420" id="CVE-2024-43420" title="CVE-2024-43420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20054&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-20054" id="CVE-2025-20054" title="CVE-2025-20054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20103&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-20103" id="CVE-2025-20103" title="CVE-2025-20103" type="cve"></reference>
		</references>
		<description>CVE-2024-28956:Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2025-24495:Incorrect initialization of resource in the branch prediction unit for some Intel(R) Core™ Ultra Processors may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2025-20012:Incorrect behavior order for some Intel(R) Core™ Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.&#xA;CVE-2024-45332:Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution in the indirect branch predictors for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2025-20623:Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel(R) Core™ processors (10th Generation) may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2024-43420:Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel Atom(R) processors may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2025-20054:Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.&#xA;CVE-2025-20103:Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="1.u3" version="20250512">
					<filename>microcode_ctl-20250512-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/microcode_ctl-20250512-1.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2157</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3198&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3198" id="CVE-2025-3198" title="CVE-2025-3198" type="cve"></reference>
		</references>
		<description>CVE-2025-3198:A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="binutils" release="26.u15" version="2.37">
					<filename>binutils-2.37-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/binutils-2.37-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="26.u15" version="2.37">
					<filename>binutils-devel-2.37-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/binutils-devel-2.37-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="26.u15" version="2.37">
					<filename>binutils-help-2.37-26.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/binutils-help-2.37-26.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="26.u15" version="2.37">
					<filename>binutils-2.37-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/binutils-2.37-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="26.u15" version="2.37">
					<filename>binutils-devel-2.37-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/binutils-devel-2.37-26.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="26.u15" version="2.37">
					<filename>binutils-help-2.37-26.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/binutils-help-2.37-26.u15.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2158</id>
		<title>An update for gstreamer1-plugins-good is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47219&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47219" id="CVE-2025-47219" title="CVE-2025-47219" type="cve"></reference>
		</references>
		<description>CVE-2025-47219:An Out-of-bounds read in the MOV/MP4 demuxer that can cause crashes or potentially information leaks for certain input files.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good" release="10.u5" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/gstreamer1-plugins-good-1.16.2-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good-gtk" release="10.u5" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/gstreamer1-plugins-good-gtk-1.16.2-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-good-help" release="10.u5" version="1.16.2">
					<filename>gstreamer1-plugins-good-help-1.16.2-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gstreamer1-plugins-good-help-1.16.2-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good" release="10.u5" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gstreamer1-plugins-good-1.16.2-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good-gtk" release="10.u5" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gstreamer1-plugins-good-gtk-1.16.2-10.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2159</id>
		<title>An update for gstreamer1-plugins-base is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47806&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47806" id="CVE-2025-47806" title="CVE-2025-47806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47807&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47807" id="CVE-2025-47807" title="CVE-2025-47807" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47808&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47808" id="CVE-2025-47808" title="CVE-2025-47808" type="cve"></reference>
		</references>
		<description>CVE-2025-47806:A stack buffer overflow in the SubRip subtitle parser that can cause crashes for certain input files.&#xA;CVE-2025-47807:A NULL-pointer dereference in the SubRip subtitle parser that can cause crashes for certain input files.&#xA;CVE-2025-47808:A NULL-pointer dereference in the TMPlayer subtitle parser that can cause crashes for certain input files.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base-devel" release="9.u5" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-9.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/gstreamer1-plugins-base-devel-1.18.4-9.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base" release="9.u5" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-9.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/gstreamer1-plugins-base-1.18.4-9.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-base-help" release="9.u5" version="1.18.4">
					<filename>gstreamer1-plugins-base-help-1.18.4-9.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gstreamer1-plugins-base-help-1.18.4-9.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base" release="9.u5" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-9.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gstreamer1-plugins-base-1.18.4-9.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base-devel" release="9.u5" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-9.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/gstreamer1-plugins-base-devel-1.18.4-9.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2160</id>
		<title>An update for uboot-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33103&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-33103" id="CVE-2022-33103" title="CVE-2022-33103" type="cve"></reference>
		</references>
		<description>CVE-2022-33103:Das U-Boot from v2020.10 to v2022.07-rc3 was discovered to contain an out-of-bounds write via the function sqfs_readdir().&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="uboot-tools-help" release="10.u3" version="2021.10">
					<filename>uboot-tools-help-2021.10-10.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/uboot-tools-help-2021.10-10.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uboot-images-armv8" release="10.u3" version="2021.10">
					<filename>uboot-images-armv8-2021.10-10.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/uboot-images-armv8-2021.10-10.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uboot-tools" release="10.u3" version="2021.10">
					<filename>uboot-tools-2021.10-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/uboot-tools-2021.10-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-tools" release="10.u3" version="2021.10">
					<filename>uboot-tools-2021.10-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/uboot-tools-2021.10-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-images-elf" release="10.u3" version="2021.10">
					<filename>uboot-images-elf-2021.10-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/uboot-images-elf-2021.10-10.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2161</id>
		<title>An update for freetype is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27363&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27363" id="CVE-2025-27363" title="CVE-2025-27363" type="cve"></reference>
		</references>
		<description>CVE-2025-27363:An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="freetype" release="5.u4" version="2.12.1">
					<filename>freetype-2.12.1-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/freetype-2.12.1-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freetype-demos" release="5.u4" version="2.12.1">
					<filename>freetype-demos-2.12.1-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/freetype-demos-2.12.1-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freetype-devel" release="5.u4" version="2.12.1">
					<filename>freetype-devel-2.12.1-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/freetype-devel-2.12.1-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype-demos" release="5.u4" version="2.12.1">
					<filename>freetype-demos-2.12.1-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/freetype-demos-2.12.1-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype" release="5.u4" version="2.12.1">
					<filename>freetype-2.12.1-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/freetype-2.12.1-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype-devel" release="5.u4" version="2.12.1">
					<filename>freetype-devel-2.12.1-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/freetype-devel-2.12.1-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="freetype-help" release="5.u4" version="2.12.1">
					<filename>freetype-help-2.12.1-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/freetype-help-2.12.1-5.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2162</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21605&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21605" id="CVE-2025-21605" title="CVE-2025-21605" type="cve"></reference>
		</references>
		<description>CVE-2025-21605:Redis is an open source, in-memory database that persists on disk. In versions starting at 2.6 and prior to 7.4.3, An unauthenticated client can cause unlimited growth of output buffers, until the server runs out of memory or is killed. By default, the Redis configuration does not limit the output buffer of normal clients (see client-output-buffer-limit). Therefore, the output buffer can grow unlimitedly over time. As a result, the service is exhausted and the memory is unavailable. When password authentication is enabled on the Redis server, but no password is provided, the client can still cause the output buffer to grow from &#34;NOAUTH&#34; responses until the system will run out of memory. This issue has been patched in version 7.4.3. An additional workaround to mitigate this problem without patching the redis-server executable is to block access to prevent unauthenticated users from connecting to Redis. This can be done in different ways. Either using network access control tools like firewalls, iptables, security groups, etc, or enabling TLS and requiring users to authenticate using client side certificates.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u10" version="6.2.7">
					<filename>redis6-6.2.7-3.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/redis6-6.2.7-3.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u10" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/redis6-devel-6.2.7-3.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u10" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/redis6-doc-6.2.7-3.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u10" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/redis6-devel-6.2.7-3.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u10" version="6.2.7">
					<filename>redis6-6.2.7-3.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/redis6-6.2.7-3.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2163</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32414&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32414" id="CVE-2025-32414" title="CVE-2025-32414" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32415&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32415" id="CVE-2025-32415" title="CVE-2025-32415" type="cve"></reference>
		</references>
		<description>CVE-2025-32414:In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.&#xA;CVE-2025-32415:In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="17.u12" version="2.9.14">
					<filename>libxml2-devel-2.9.14-17.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libxml2-devel-2.9.14-17.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="17.u12" version="2.9.14">
					<filename>python3-libxml2-2.9.14-17.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-libxml2-2.9.14-17.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="17.u12" version="2.9.14">
					<filename>libxml2-2.9.14-17.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libxml2-2.9.14-17.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="17.u12" version="2.9.14">
					<filename>libxml2-2.9.14-17.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libxml2-2.9.14-17.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="17.u12" version="2.9.14">
					<filename>libxml2-devel-2.9.14-17.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libxml2-devel-2.9.14-17.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="17.u12" version="2.9.14">
					<filename>python3-libxml2-2.9.14-17.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/python3-libxml2-2.9.14-17.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="17.u12" version="2.9.14">
					<filename>libxml2-help-2.9.14-17.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libxml2-help-2.9.14-17.u12.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2164</id>
		<title>An update for python-dns is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29483&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29483" id="CVE-2023-29483" title="CVE-2023-29483" type="cve"></reference>
		</references>
		<description>CVE-2023-29483:eventlet before 0.35.2, as used in dnspython before 2.6.0, allows remote attackers to interfere with DNS name resolution by quickly sending an invalid packet from the expected IP address and source port, aka a &#34;TuDoor&#34; attack. In other words, dnspython does not have the preferred behavior in which the DNS name resolution algorithm would proceed, within the full time window, in order to wait for a valid packet. NOTE: dnspython 2.6.0 is unusable for a different reason that was addressed in 2.6.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="python-dns-help" release="3.u1" version="2.2.1">
					<filename>python-dns-help-2.2.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python-dns-help-2.2.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-dns" release="3.u1" version="2.2.1">
					<filename>python3-dns-2.2.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-dns-2.2.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2165</id>
		<title>An update for libsoup is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32906&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32906" id="CVE-2025-32906" title="CVE-2025-32906" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32909&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32909" id="CVE-2025-32909" title="CVE-2025-32909" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32910&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32910" id="CVE-2025-32910" title="CVE-2025-32910" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32911&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32911" id="CVE-2025-32911" title="CVE-2025-32911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32912" id="CVE-2025-32912" title="CVE-2025-32912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32913&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32913" id="CVE-2025-32913" title="CVE-2025-32913" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2784&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2784" id="CVE-2025-2784" title="CVE-2025-2784" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32050" id="CVE-2025-32050" title="CVE-2025-32050" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32052&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32052" id="CVE-2025-32052" title="CVE-2025-32052" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32053&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32053" id="CVE-2025-32053" title="CVE-2025-32053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4476&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4476" id="CVE-2025-4476" title="CVE-2025-4476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4948&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4948" id="CVE-2025-4948" title="CVE-2025-4948" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4969&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4969" id="CVE-2025-4969" title="CVE-2025-4969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46420" id="CVE-2025-46420" title="CVE-2025-46420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46421&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46421" id="CVE-2025-46421" title="CVE-2025-46421" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32907&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32907" id="CVE-2025-32907" title="CVE-2025-32907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32914&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32914" id="CVE-2025-32914" title="CVE-2025-32914" type="cve"></reference>
		</references>
		<description>CVE-2025-32906:A flaw was found in libsoup, where the soup_headers_parse_request() function may be vulnerable to an out-of-bound read. This flaw allows a malicious user to use a specially crafted HTTP request to crash the HTTP server.&#xA;CVE-2025-32909:A flaw was found in libsoup. SoupContentSniffer may be vulnerable to a NULL pointer dereference in the sniff_mp4 function. The HTTP server may cause the libsoup client to crash.&#xA;CVE-2025-32910:A flaw was found in libsoup, where soup_auth_digest_authenticate() is vulnerable to a NULL pointer dereference. This issue may cause the libsoup client to crash.&#xA;CVE-2025-32911:A use-after-free type vulnerability was found in libsoup, in the soup_message_headers_get_content_disposition() function. This flaw allows a malicious HTTP client to cause memory corruption in the libsoup server.&#xA;CVE-2025-32912:A flaw was found in libsoup, where SoupAuthDigest is vulnerable to a NULL pointer dereference. The HTTP server may cause the libsoup client to crash.&#xA;CVE-2025-32913:A flaw was found in libsoup, where the soup_message_headers_get_content_disposition() function is vulnerable to a NULL pointer dereference. This flaw allows a malicious HTTP peer to crash a libsoup client or server that uses this function.&#xA;CVE-2025-2784:A flaw was found in libsoup. The package is vulnerable to a heap buffer over-read when sniffing content via the skip_insight_whitespace() function. Libsoup clients may read one byte out-of-bounds in response to a crafted HTTP response by an HTTP server.&#xA;CVE-2025-32050:A flaw was found in libsoup. The libsoup append_param_quoted() function may contain an overflow bug resulting in a buffer under-read.&#xA;CVE-2025-32052:A flaw was found in libsoup. A vulnerability in the sniff_unknown() function may lead to heap buffer over-read.&#xA;CVE-2025-32053:A flaw was found in libsoup. A vulnerability in sniff_feed_or_html() and skip_insignificant_space() functions may lead to a heap buffer over-read.&#xA;CVE-2025-4476:A denial-of-service vulnerability has been identified in the libsoup HTTP client library. This flaw can be triggered when a libsoup client receives a 401 (Unauthorized) HTTP response containing a specifically crafted domain parameter within the WWW-Authenticate header. Processing this malformed header can lead to a crash of the client application using libsoup. An attacker could exploit this by setting up a malicious HTTP server. If a user&#39;s application using the vulnerable libsoup library connects to this malicious server, it could result in a denial-of-service. Successful exploitation requires tricking a user&#39;s client application into connecting to the attacker&#39;s malicious server.&#xA;CVE-2025-4948:A flaw was found in the soup_multipart_new_from_message() function of the libsoup HTTP library, which is commonly used by GNOME and other applications to handle web communications. The issue occurs when the library processes specially crafted multipart messages. Due to improper validation, an internal calculation can go wrong, leading to an integer underflow. This can cause the program to access invalid memory and crash. As a result, any application or server using libsoup could be forced to exit unexpectedly, creating a denial-of-service (DoS) risk.&#xA;CVE-2025-4969:A vulnerability was found in the libsoup package. This flaw stems from its failure to correctly verify the termination of multipart HTTP messages. This can allow a remote attacker to send a specially crafted multipart HTTP body, causing the libsoup-consuming server to read beyond its allocated memory boundaries (out-of-bounds read).&#xA;CVE-2025-46420:A flaw was found in libsoup. It is vulnerable to memory leaks in the soup_header_parse_quality_list() function when parsing a quality list that contains elements with all zeroes.&#xA;CVE-2025-46421:A flaw was found in libsoup. When libsoup clients encounter an HTTP redirect, they mistakenly send the HTTP Authorization header to the new host that the redirection points to. This allows the new host to impersonate the user to the original host that issued the redirect.&#xA;CVE-2025-32907:A flaw was found in libsoup. The implementation of HTTP range requests is vulnerable to a resource consumption attack. This flaw allows a malicious client to request the same range many times in a single HTTP request, causing the server to use large amounts of memory. This does not allow for a full denial of service.&#xA;CVE-2025-32914:A flaw was found in libsoup, where the soup_multipart_new_from_message() function is vulnerable to an out-of-bounds read. This flaw allows a malicious HTTP client to induce the libsoup server to read out of bounds.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="libsoup" release="10.u6" version="2.74.2">
					<filename>libsoup-2.74.2-10.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libsoup-2.74.2-10.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsoup-devel" release="10.u6" version="2.74.2">
					<filename>libsoup-devel-2.74.2-10.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libsoup-devel-2.74.2-10.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsoup" release="10.u6" version="2.74.2">
					<filename>libsoup-2.74.2-10.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libsoup-2.74.2-10.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsoup-devel" release="10.u6" version="2.74.2">
					<filename>libsoup-devel-2.74.2-10.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libsoup-devel-2.74.2-10.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libsoup-help" release="10.u6" version="2.74.2">
					<filename>libsoup-help-2.74.2-10.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libsoup-help-2.74.2-10.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2166</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8176" id="CVE-2024-8176" title="CVE-2024-8176" type="cve"></reference>
		</references>
		<description>CVE-2024-8176:A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="expat-devel" release="16.u4" version="2.4.1">
					<filename>expat-devel-2.4.1-16.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/expat-devel-2.4.1-16.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat" release="16.u4" version="2.4.1">
					<filename>expat-2.4.1-16.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/expat-2.4.1-16.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat-devel" release="16.u4" version="2.4.1">
					<filename>expat-devel-2.4.1-16.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/expat-devel-2.4.1-16.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat" release="16.u4" version="2.4.1">
					<filename>expat-2.4.1-16.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/expat-2.4.1-16.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="expat-help" release="16.u4" version="2.4.1">
					<filename>expat-help-2.4.1-16.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/expat-help-2.4.1-16.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2167</id>
		<title>An update for containerd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40635&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40635" id="CVE-2024-40635" title="CVE-2024-40635" type="cve"></reference>
		</references>
		<description>CVE-2024-40635:containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="containerd-stress" release="11.u10" version="1.6.22">
					<filename>containerd-stress-1.6.22-11.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/containerd-stress-1.6.22-11.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="containerd" release="11.u10" version="1.6.22">
					<filename>containerd-1.6.22-11.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/containerd-1.6.22-11.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd" release="11.u10" version="1.6.22">
					<filename>containerd-1.6.22-11.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/containerd-1.6.22-11.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd-stress" release="11.u10" version="1.6.22">
					<filename>containerd-stress-1.6.22-11.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/containerd-stress-1.6.22-11.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2168</id>
		<title>An update for varnish is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47905&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47905" id="CVE-2025-47905" title="CVE-2025-47905" type="cve"></reference>
		</references>
		<description>CVE-2025-47905:Varnish Cache before 7.6.3 and 7.7 before 7.7.1, and Varnish Enterprise before 6.0.13r14, allow client-side desync via HTTP/1 requests, because the product incorrectly permits CRLF to be skipped to delimit chunk boundaries.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="varnish" release="3.u2" version="7.4.3">
					<filename>varnish-7.4.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/varnish-7.4.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="varnish-devel" release="3.u2" version="7.4.3">
					<filename>varnish-devel-7.4.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/varnish-devel-7.4.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish-devel" release="3.u2" version="7.4.3">
					<filename>varnish-devel-7.4.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/varnish-devel-7.4.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish" release="3.u2" version="7.4.3">
					<filename>varnish-7.4.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/varnish-7.4.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="varnish-help" release="3.u2" version="7.4.3">
					<filename>varnish-help-7.4.3-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/varnish-help-7.4.3-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2169</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32464&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32464" id="CVE-2025-32464" title="CVE-2025-32464" type="cve"></reference>
		</references>
		<description>CVE-2025-32464:HAProxy 2.2 through 3.1.6, in certain uncommon configurations, has a sample_conv_regsub heap-based buffer overflow because of mishandling of the replacement of multiple short patterns with a longer one.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="16.u14" version="2.6.6">
					<filename>haproxy-2.6.6-16.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/haproxy-2.6.6-16.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="16.u14" version="2.6.6">
					<filename>haproxy-2.6.6-16.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/haproxy-2.6.6-16.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="16.u14" version="2.6.6">
					<filename>haproxy-help-2.6.6-16.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/haproxy-help-2.6.6-16.u14.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2170</id>
		<title>An update for apache-commons-vfs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27553&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27553" id="CVE-2025-27553" title="CVE-2025-27553" type="cve"></reference>
		</references>
		<description>CVE-2025-27553:Relative Path Traversal vulnerability in Apache Commons VFS before 2.10.0.&#xA;&#xA;The FileObject API in Commons VFS has a &#39;resolveFile&#39; method that&#xA;takes a &#39;scope&#39; parameter. Specifying &#39;NameScope.DESCENDENT&#39; promises that &#34;an exception is thrown if the resolved file is not a descendent of&#xA;the base file&#34;. However, when the path contains encoded &#34;..&#34;&#xA;characters (for example, &#34;%2E%2E/bar.txt&#34;), it might return file objects that are not&#xA;a descendent of the base file, without throwing an exception.&#xA;This issue affects Apache Commons VFS: before 2.10.0.&#xA;&#xA;Users are recommended to upgrade to version 2.10.0, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="apache-commons-vfs" release="15.u1" version="2.1">
					<filename>apache-commons-vfs-2.1-15.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/apache-commons-vfs-2.1-15.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-vfs-devel" release="15.u1" version="2.1">
					<filename>apache-commons-vfs-devel-2.1-15.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/apache-commons-vfs-devel-2.1-15.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-vfs-help" release="15.u1" version="2.1">
					<filename>apache-commons-vfs-help-2.1-15.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/apache-commons-vfs-help-2.1-15.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2171</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21575&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21575" id="CVE-2025-21575" title="CVE-2025-21575" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21577&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21577" id="CVE-2025-21577" title="CVE-2025-21577" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21574&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21574" id="CVE-2025-21574" title="CVE-2025-21574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30722&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30722" id="CVE-2025-30722" title="CVE-2025-30722" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30704&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30704" id="CVE-2025-30704" title="CVE-2025-30704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30703&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30703" id="CVE-2025-30703" title="CVE-2025-30703" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30715&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30715" id="CVE-2025-30715" title="CVE-2025-30715" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21580&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21580" id="CVE-2025-21580" title="CVE-2025-21580" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30695&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30695" id="CVE-2025-30695" title="CVE-2025-30695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30699" id="CVE-2025-30699" title="CVE-2025-30699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30693&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30693" id="CVE-2025-30693" title="CVE-2025-30693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30721&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30721" id="CVE-2025-30721" title="CVE-2025-30721" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30688&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30688" id="CVE-2025-30688" title="CVE-2025-30688" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30682&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30682" id="CVE-2025-30682" title="CVE-2025-30682" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30684&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30684" id="CVE-2025-30684" title="CVE-2025-30684" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30689&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30689" id="CVE-2025-30689" title="CVE-2025-30689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30681&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30681" id="CVE-2025-30681" title="CVE-2025-30681" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30705&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30705" id="CVE-2025-30705" title="CVE-2025-30705" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30685&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30685" id="CVE-2025-30685" title="CVE-2025-30685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30687&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30687" id="CVE-2025-30687" title="CVE-2025-30687" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21584&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21584" id="CVE-2025-21584" title="CVE-2025-21584" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30683&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30683" id="CVE-2025-30683" title="CVE-2025-30683" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21581&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21581" id="CVE-2025-21581" title="CVE-2025-21581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21585&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21585" id="CVE-2025-21585" title="CVE-2025-21585" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21579&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21579" id="CVE-2025-21579" title="CVE-2025-21579" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30696&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30696" id="CVE-2025-30696" title="CVE-2025-30696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30710&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30710" id="CVE-2025-30710" title="CVE-2025-30710" type="cve"></reference>
		</references>
		<description>CVE-2025-21575:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21577:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21574:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30722:Vulnerability in the MySQL Client product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Client.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all MySQL Client accessible data as well as  unauthorized update, insert or delete access to some of MySQL Client accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N).&#xA;CVE-2025-30704:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30703:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).&#xA;CVE-2025-30715:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21580:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30695:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-30699:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30693:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-30721:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: UDF).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.0 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30688:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30682:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30684:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30689:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30681:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2025-30705:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: PS).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30685:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30687:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21584:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30683:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21581:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21585:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-21579:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Options).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30696:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: PS).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30710:Vulnerability in the MySQL Cluster product of Oracle MySQL (component: Cluster: NDBCluster Plugin).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Cluster.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Cluster. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u4" version="8.0.42">
					<filename>mysql-config-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-config-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u4" version="8.0.42">
					<filename>mysql-errmsg-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-errmsg-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u4" version="8.0.42">
					<filename>mysql-libs-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-libs-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u4" version="8.0.42">
					<filename>mysql-test-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-test-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u4" version="8.0.42">
					<filename>mysql-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u4" version="8.0.42">
					<filename>mysql-devel-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-devel-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u4" version="8.0.42">
					<filename>mysql-help-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-help-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u4" version="8.0.42">
					<filename>mysql-server-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-server-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u4" version="8.0.42">
					<filename>mysql-common-8.0.42-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/mysql-common-8.0.42-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u4" version="8.0.42">
					<filename>mysql-errmsg-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-errmsg-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u4" version="8.0.42">
					<filename>mysql-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u4" version="8.0.42">
					<filename>mysql-devel-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-devel-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u4" version="8.0.42">
					<filename>mysql-test-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-test-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u4" version="8.0.42">
					<filename>mysql-help-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-help-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u4" version="8.0.42">
					<filename>mysql-libs-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-libs-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u4" version="8.0.42">
					<filename>mysql-server-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-server-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u4" version="8.0.42">
					<filename>mysql-config-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-config-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u4" version="8.0.42">
					<filename>mysql-common-8.0.42-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/mysql-common-8.0.42-1.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2172</id>
		<title>An update for kafka is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27818&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27818" id="CVE-2025-27818" title="CVE-2025-27818" type="cve"></reference>
		</references>
		<description>CVE-2025-27818:A possible security vulnerability has been identified in Apache Kafka.&#xA;This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config&#xA;and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0).&#xA;When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config`&#xA;property for any of the connector&#39;s Kafka clients to &#34;com.sun.security.auth.module.LdapLoginModule&#34;, which can be done via the&#xA;`producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties.&#xA;This will allow the server to connect to the attacker&#39;s LDAP server&#xA;and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.&#xA;Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.&#xA;&#xA;Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box&#xA;configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector&#xA;client override policy that permits them.&#xA;&#xA;Since Apache Kafka 3.9.1/4.0.0, we have added a system property (&#34;-Dorg.apache.kafka.disallowed.login.modules&#34;) to disable the problematic login modules usage&#xA;in SASL JAAS configuration. Also by default &#34;com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule&#34; are disabled in Apache Kafka Connect 3.9.1/4.0.0. &#xA;&#xA;We advise the Kafka users to validate connector configurations and only allow trusted LDAP configurations. Also examine connector dependencies for &#xA;vulnerable versions and either upgrade their connectors, upgrading that specific dependency, or removing the connectors as options for remediation. Finally,&#xA;in addition to leveraging the &#34;org.apache.kafka.disallowed.login.modules&#34; system property, Kafka Connect users can also implement their own connector&#xA;client config override policy, which can be used to control which Kafka client properties can be overridden directly in a connector config and which cannot.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="kafka" release="1.u4" version="2.8.2">
					<filename>kafka-2.8.2-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/kafka-2.8.2-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kafka" release="1.u4" version="2.8.2">
					<filename>kafka-2.8.2-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/kafka-2.8.2-1.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2173</id>
		<title>An update for cjson is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26819&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-26819" id="CVE-2023-26819" title="CVE-2023-26819" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53154&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53154" id="CVE-2023-53154" title="CVE-2023-53154" type="cve"></reference>
		</references>
		<description>CVE-2023-26819:cJSON 1.7.15 might allow a denial of service via a crafted JSON document such as {&#34;a&#34;: true, &#34;b&#34;: [ null,9999999999999999999999999999999999999999999999912345678901234567]}.&#xA;CVE-2023-53154:parse_string in cJSON before 1.7.18 has a heap-based buffer over-read via {&#34;1&#34;:1, with no trailing newline if cJSON_ParseWithLength is called.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="cjson-devel" release="5.u4" version="1.7.15">
					<filename>cjson-devel-1.7.15-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/cjson-devel-1.7.15-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cjson" release="5.u4" version="1.7.15">
					<filename>cjson-1.7.15-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/cjson-1.7.15-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson" release="5.u4" version="1.7.15">
					<filename>cjson-1.7.15-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/cjson-1.7.15-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson-devel" release="5.u4" version="1.7.15">
					<filename>cjson-devel-1.7.15-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/cjson-devel-1.7.15-5.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2174</id>
		<title>An update for netty3 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-20444&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-20444" id="CVE-2019-20444" title="CVE-2019-20444" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-20445&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-20445" id="CVE-2019-20445" title="CVE-2019-20445" type="cve"></reference>
		</references>
		<description>CVE-2019-20444:HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an &#34;invalid fold.&#34;&#xA;CVE-2019-20445:HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="netty3" release="8.u2" version="3.10.6">
					<filename>netty3-3.10.6-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/netty3-3.10.6-8.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2175</id>
		<title>An update for eclipse-jgit is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4759&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4759" id="CVE-2023-4759" title="CVE-2023-4759" type="cve"></reference>
		</references>
		<description>CVE-2023-4759:Arbitrary File Overwrite in Eclipse JGit &lt;= 6.6.0&#xA;&#xA;In Eclipse JGit, all versions &lt;= 6.6.0.202305301015-r, a symbolic link present in a specially crafted git repository can be used to write a file to locations outside the working tree when this repository is cloned with JGit to a case-insensitive filesystem, or when a checkout from a clone of such a repository is performed on a case-insensitive filesystem.&#xA;&#xA;This can happen on checkout (DirCacheCheckout), merge (ResolveMerger via its WorkingTreeUpdater), pull (PullCommand using merge), and when applying a patch (PatchApplier). This can be exploited for remote code execution (RCE), for instance if the file written outside the working tree is a git filter that gets executed on a subsequent git command.&#xA;&#xA;The issue occurs only on case-insensitive filesystems, like the default filesystems on Windows and macOS. The user performing the clone or checkout must have the rights to create symbolic links for the problem to occur, and symbolic links must be enabled in the git configuration.&#xA;&#xA;Setting git configuration option core.symlinks = false before checking out avoids the problem.&#xA;&#xA;The issue was fixed in Eclipse JGit version 6.6.1.202309021850-r and 6.7.0.202309050840-r, available via  Maven Central https://repo1.maven.org/maven2/org/eclipse/jgit/  and  repo.eclipse.org https://repo.eclipse.org/content/repositories/jgit-releases/ . A backport is available in 5.13.3 starting from  5.13.3.202401111512-r.&#xA;&#xA;&#xA;The JGit maintainers would like to thank RyotaK for finding and reporting this issue.&#xA;&#xA;&#xA;&#xA;&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="eclipse-jgit" release="2.u1" version="5.11.0">
					<filename>eclipse-jgit-5.11.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/eclipse-jgit-5.11.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2176</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46394&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46394" id="CVE-2025-46394" title="CVE-2025-46394" type="cve"></reference>
		</references>
		<description>CVE-2025-46394:In tar in BusyBox through 1.37.0, a TAR archive can have filenames hidden from a listing through the use of terminal escape sequences.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="1" name="busybox-help" release="22.u3" version="1.34.1">
					<filename>busybox-help-1.34.1-22.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/busybox-help-1.34.1-22.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-petitboot" release="22.u3" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-22.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/busybox-petitboot-1.34.1-22.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox" release="22.u3" version="1.34.1">
					<filename>busybox-1.34.1-22.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/busybox-1.34.1-22.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-help" release="22.u3" version="1.34.1">
					<filename>busybox-help-1.34.1-22.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/busybox-help-1.34.1-22.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-petitboot" release="22.u3" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-22.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/busybox-petitboot-1.34.1-22.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox" release="22.u3" version="1.34.1">
					<filename>busybox-1.34.1-22.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/busybox-1.34.1-22.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2177</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26594&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26594" id="CVE-2025-26594" title="CVE-2025-26594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26599&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26599" id="CVE-2025-26599" title="CVE-2025-26599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26601" id="CVE-2025-26601" title="CVE-2025-26601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26595&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26595" id="CVE-2025-26595" title="CVE-2025-26595" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26596&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26596" id="CVE-2025-26596" title="CVE-2025-26596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26597&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26597" id="CVE-2025-26597" title="CVE-2025-26597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26598&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26598" id="CVE-2025-26598" title="CVE-2025-26598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26600&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26600" id="CVE-2025-26600" title="CVE-2025-26600" type="cve"></reference>
		</references>
		<description>CVE-2025-26594:A use-after-free flaw was found in X.Org and Xwayland. The root cursor is referenced in the X server as a global variable. If a client frees the root cursor, the internal reference points to freed memory and causes a use-after-free.&#xA;CVE-2025-26599:An access to an uninitialized pointer flaw was found in X.Org and Xwayland. The function compCheckRedirect() may fail if it cannot allocate the backing pixmap. In that case, compRedirectWindow() will return a BadAlloc error without validating the window tree marked just before, which leaves the validated data partly initialized and the use of an uninitialized pointer later.&#xA;CVE-2025-26601:A use-after-free flaw was found in X.Org and Xwayland. When changing an alarm, the values of the change mask are evaluated one after the other, changing the trigger values as requested, and eventually, SyncInitTrigger() is called. If one of the changes triggers an error, the function will return early, not adding the new sync object, possibly causing a use-after-free when the alarm eventually triggers.&#xA;CVE-2025-26595:A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.&#xA;CVE-2025-26596:A heap overflow flaw was found in X.Org and Xwayland. The computation of the length in XkbSizeKeySyms() differs from what is written in XkbWriteKeySyms(), which may lead to a heap-based buffer overflow.&#xA;CVE-2025-26597:A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.&#xA;CVE-2025-26598:An out-of-bounds write flaw was found in X.Org and Xwayland. The function GetBarrierDevice() searches for the pointer device based on its device ID and returns the matching value, or supposedly NULL, if no match was found. However, the code will return the last element of the list if no matching device ID is found, which can lead to out-of-bounds memory access.&#xA;CVE-2025-26600:A use-after-free flaw was found in X.Org and Xwayland. When a device is removed while still frozen, the events queued for that device remain while the device is freed. Replaying the events will cause a use-after-free.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-Xdmx-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-Xnest-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-devel-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-Xephyr-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-Xvfb-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-36.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-common-1.20.11-36.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-Xdmx-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-common-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-devel-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-Xephyr-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-Xnest-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-36.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/xorg-x11-server-Xvfb-1.20.11-36.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-36.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-help-1.20.11-36.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="36.u21" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-36.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/xorg-x11-server-source-1.20.11-36.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2178</id>
		<title>An update for nasm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38665&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-38665" id="CVE-2023-38665" title="CVE-2023-38665" type="cve"></reference>
		</references>
		<description>CVE-2023-38665:Null pointer dereference in ieee_write_file in nasm 2.16rc0 allows attackers to cause a denial of service (crash).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="nasm" release="7.u4" version="2.15.05">
					<filename>nasm-2.15.05-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/nasm-2.15.05-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nasm-help" release="7.u4" version="2.15.05">
					<filename>nasm-help-2.15.05-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/nasm-help-2.15.05-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nasm" release="7.u4" version="2.15.05">
					<filename>nasm-2.15.05-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/nasm-2.15.05-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2179</id>
		<title>An update for python-tornado is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47287&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47287" id="CVE-2025-47287" title="CVE-2025-47287" type="cve"></reference>
		</references>
		<description>CVE-2025-47287:Tornado is a Python web framework and asynchronous networking library. When Tornado&#39;s ``multipart/form-data`` parser encounters certain errors, it logs a warning but continues trying to parse the remainder of the data. This allows remote attackers to generate an extremely high volume of logs, constituting a DoS attack. This DoS is compounded by the fact that the logging subsystem is synchronous. All versions of Tornado prior to 6.5.0 are affected. The vulnerable parser is enabled by default. Upgrade to Tornado version 6.50 to receive a patch. As a workaround, risk can be mitigated by blocking `Content-Type: multipart/form-data` in a proxy.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="python-tornado-help" release="4.u3" version="6.1">
					<filename>python-tornado-help-6.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python-tornado-help-6.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-tornado" release="4.u3" version="6.1">
					<filename>python3-tornado-6.1-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-tornado-6.1-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python-tornado-help" release="4.u3" version="6.1">
					<filename>python-tornado-help-6.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/python-tornado-help-6.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-tornado" release="4.u3" version="6.1">
					<filename>python3-tornado-6.1-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/python3-tornado-6.1-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2180</id>
		<title>An update for python-requests is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47081&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47081" id="CVE-2024-47081" title="CVE-2024-47081" type="cve"></reference>
		</references>
		<description>CVE-2024-47081:Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one&#39;s Requests Session.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="python-requests-help" release="9.u7" version="2.26.0">
					<filename>python-requests-help-2.26.0-9.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python-requests-help-2.26.0-9.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-requests" release="9.u7" version="2.26.0">
					<filename>python3-requests-2.26.0-9.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-requests-2.26.0-9.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2181</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1737" id="CVE-2024-1737" title="CVE-2024-1737" type="cve"></reference>
		</references>
		<description>CVE-2024-1737:Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="25.u11" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-dnssec-utils-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-pkcs11-utils-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="25.u11" version="9.16.23">
					<filename>bind-devel-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-devel-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-pkcs11-devel-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind" release="25.u11" version="9.16.23">
					<filename>bind-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-pkcs11-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="25.u11" version="9.16.23">
					<filename>bind-libs-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-libs-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="25.u11" version="9.16.23">
					<filename>bind-utils-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-utils-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-pkcs11-libs-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="25.u11" version="9.16.23">
					<filename>bind-chroot-9.16.23-25.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-chroot-9.16.23-25.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="25.u11" version="9.16.23">
					<filename>python3-bind-9.16.23-25.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-bind-9.16.23-25.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="25.u11" version="9.16.23">
					<filename>bind-license-9.16.23-25.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-license-9.16.23-25.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="25.u11" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-25.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bind-dnssec-doc-9.16.23-25.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="25.u11" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-dnssec-utils-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="25.u11" version="9.16.23">
					<filename>bind-chroot-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-chroot-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-pkcs11-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="25.u11" version="9.16.23">
					<filename>bind-devel-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-devel-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-pkcs11-devel-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-pkcs11-libs-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="25.u11" version="9.16.23">
					<filename>bind-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="25.u11" version="9.16.23">
					<filename>bind-libs-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-libs-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="25.u11" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-pkcs11-utils-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="25.u11" version="9.16.23">
					<filename>bind-utils-9.16.23-25.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bind-utils-9.16.23-25.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2182</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30348&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30348" id="CVE-2025-30348" title="CVE-2025-30348" type="cve"></reference>
		</references>
		<description>CVE-2025-30348:encodeText in QDom in Qt before 6.8.0 has a complex algorithm involving XML string copy and inline replacement of parts of a string (with relocation of later data).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-devel-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-examples-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-odbc-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-gui-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-private-devel-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-static-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-mysql-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-17.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/qt5-qtbase-postgresql-5.15.2-17.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-17.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-common-5.15.2-17.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-mysql-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-odbc-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-devel-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-gui-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-examples-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-static-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-postgresql-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="17.u11" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-17.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/qt5-qtbase-private-devel-5.15.2-17.u11.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2183</id>
		<title>An update for taglib is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47466&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-47466" id="CVE-2023-47466" title="CVE-2023-47466" type="cve"></reference>
		</references>
		<description>CVE-2023-47466:TagLib before 2.0 allows a segmentation violation and application crash during tag writing via a crafted WAV file in which an id3 chunk is the only valid chunk.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="taglib-devel" release="13.u1" version="1.11.1">
					<filename>taglib-devel-1.11.1-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/taglib-devel-1.11.1-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="taglib" release="13.u1" version="1.11.1">
					<filename>taglib-1.11.1-13.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/taglib-1.11.1-13.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="taglib-devel" release="13.u1" version="1.11.1">
					<filename>taglib-devel-1.11.1-13.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/taglib-devel-1.11.1-13.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="taglib" release="13.u1" version="1.11.1">
					<filename>taglib-1.11.1-13.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/taglib-1.11.1-13.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="taglib-help" release="13.u1" version="1.11.1">
					<filename>taglib-help-1.11.1-13.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/taglib-help-1.11.1-13.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2184</id>
		<title>An update for libvpx is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5283&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5283" id="CVE-2025-5283" title="CVE-2025-5283" type="cve"></reference>
		</references>
		<description>CVE-2025-5283:Use after free in libvpx in Google Chrome prior to 137.0.7151.55 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="libvpx" release="13.u5" version="1.7.0">
					<filename>libvpx-1.7.0-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libvpx-1.7.0-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvpx-devel" release="13.u5" version="1.7.0">
					<filename>libvpx-devel-1.7.0-13.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libvpx-devel-1.7.0-13.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx" release="13.u5" version="1.7.0">
					<filename>libvpx-1.7.0-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libvpx-1.7.0-13.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx-devel" release="13.u5" version="1.7.0">
					<filename>libvpx-devel-1.7.0-13.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libvpx-devel-1.7.0-13.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2185</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3360&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3360" id="CVE-2025-3360" title="CVE-2025-3360" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4373&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4373" id="CVE-2025-4373" title="CVE-2025-4373" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4056&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4056" id="CVE-2025-4056" title="CVE-2025-4056" type="cve"></reference>
		</references>
		<description>CVE-2025-3360:A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.&#xA;CVE-2025-4373:A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.&#xA;CVE-2025-4056:A flaw was found in GLib. A denial of service on Windows platforms may occur if an application attempts to spawn a program using long command lines.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="glib2-static" release="21.u16" version="2.72.2">
					<filename>glib2-static-2.72.2-21.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glib2-static-2.72.2-21.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="21.u16" version="2.72.2">
					<filename>glib2-devel-2.72.2-21.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glib2-devel-2.72.2-21.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2" release="21.u16" version="2.72.2">
					<filename>glib2-2.72.2-21.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glib2-2.72.2-21.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="21.u16" version="2.72.2">
					<filename>glib2-tests-2.72.2-21.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/glib2-tests-2.72.2-21.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="21.u16" version="2.72.2">
					<filename>glib2-devel-2.72.2-21.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glib2-devel-2.72.2-21.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="21.u16" version="2.72.2">
					<filename>glib2-tests-2.72.2-21.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glib2-tests-2.72.2-21.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2" release="21.u16" version="2.72.2">
					<filename>glib2-2.72.2-21.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glib2-2.72.2-21.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-static" release="21.u16" version="2.72.2">
					<filename>glib2-static-2.72.2-21.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glib2-static-2.72.2-21.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="21.u16" version="2.72.2">
					<filename>glib2-help-2.72.2-21.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/glib2-help-2.72.2-21.u16.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2186</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31650&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31650" id="CVE-2025-31650" title="CVE-2025-31650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31651&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31651" id="CVE-2025-31651" title="CVE-2025-31651" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48988&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48988" id="CVE-2025-48988" title="CVE-2025-48988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49125" id="CVE-2025-49125" title="CVE-2025-49125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46701&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46701" id="CVE-2025-46701" title="CVE-2025-46701" type="cve"></reference>
		</references>
		<description>CVE-2025-31650:Improper Input Validation vulnerability in Apache Tomcat. Incorrect error handling for some invalid HTTP priority headers resulted in incomplete clean-up of the failed request which created a memory leak. A large number of such requests could trigger an OutOfMemoryException resulting in a denial of service.&#xA;&#xA;This issue affects Apache Tomcat: from 9.0.76 through 9.0.102, from 10.1.10 through 10.1.39, from 11.0.0-M2 through 11.0.5.&#xA;&#xA;Users are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6 which fix the issue.&#xA;CVE-2025-31651:Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat. For a subset of unlikely rewrite rule configurations, it was possible &#xA;for a specially crafted request to bypass some rewrite rules. If those &#xA;rewrite rules effectively enforced security constraints, those &#xA;constraints could be bypassed.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.5, from 10.1.0-M1 through 10.1.39, from 9.0.0.M1 through 9.0.102.&#xA;&#xA;Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.&#xA;CVE-2025-48988:Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105.&#xA;&#xA;Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.&#xA;CVE-2025-49125:Authentication Bypass Using an Alternate Path or Channel vulnerability in Apache Tomcat.  When using PreResources or PostResources mounted other than at the root of the web application, it was possible to access those resources via an unexpected path. That path was likely not to be protected by the same security constraints as the expected path, allowing those security constraints to be bypassed.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105.&#xA;&#xA;Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.&#xA;CVE-2025-46701:Improper Handling of Case Sensitivity vulnerability in Apache Tomcat&#39;s GCI servlet allows security constraint bypass of security constraints that apply to the pathInfo component of a URI mapped to the CGI servlet.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.6, from 10.1.0-M1 through 10.1.40, from 9.0.0.M1 through 9.0.104.&#xA;&#xA;Users are recommended to upgrade to version 11.0.7, 10.1.41 or 9.0.105, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="1" name="tomcat-help" release="4.u18" version="9.0.100">
					<filename>tomcat-help-9.0.100-4.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/tomcat-help-9.0.100-4.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="4.u18" version="9.0.100">
					<filename>tomcat-jsvc-9.0.100-4.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/tomcat-jsvc-9.0.100-4.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat" release="4.u18" version="9.0.100">
					<filename>tomcat-9.0.100-4.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/tomcat-9.0.100-4.u18.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2187</id>
		<title>An update for motif is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44617&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-44617" id="CVE-2022-44617" title="CVE-2022-44617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46285&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-46285" id="CVE-2022-46285" title="CVE-2022-46285" type="cve"></reference>
		</references>
		<description>CVE-2022-44617:A flaw was found in libXpm. When processing a file with width of 0 and a very large height, some parser functions will be called repeatedly and can lead to an infinite loop, resulting in a Denial of Service in the application linked to the library.&#xA;CVE-2022-46285:A flaw was found in libXpm. This issue occurs when parsing a file with a comment not closed; the end-of-file condition will not be detected, leading to an infinite loop and resulting in a Denial of Service in the application linked to the library.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="motif-devel" release="4.u2" version="2.3.8">
					<filename>motif-devel-2.3.8-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/motif-devel-2.3.8-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="motif-help" release="4.u2" version="2.3.8">
					<filename>motif-help-2.3.8-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/motif-help-2.3.8-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="motif" release="4.u2" version="2.3.8">
					<filename>motif-2.3.8-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/motif-2.3.8-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="motif-help" release="4.u2" version="2.3.8">
					<filename>motif-help-2.3.8-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/motif-help-2.3.8-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="motif" release="4.u2" version="2.3.8">
					<filename>motif-2.3.8-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/motif-2.3.8-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="motif-devel" release="4.u2" version="2.3.8">
					<filename>motif-devel-2.3.8-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/motif-devel-2.3.8-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2188</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4207&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4207" id="CVE-2025-4207" title="CVE-2025-4207" type="cve"></reference>
		</references>
		<description>CVE-2025-4207:Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination.  This affects the database server and also libpq.  Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="2.u4" version="13.21">
					<filename>postgresql-pltcl-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-pltcl-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="2.u4" version="13.21">
					<filename>postgresql-plperl-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-plperl-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="2.u4" version="13.21">
					<filename>postgresql-server-devel-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-server-devel-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="2.u4" version="13.21">
					<filename>postgresql-test-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-test-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="2.u4" version="13.21">
					<filename>postgresql-contrib-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-contrib-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="2.u4" version="13.21">
					<filename>postgresql-private-devel-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-private-devel-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="2.u4" version="13.21">
					<filename>postgresql-llvmjit-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-llvmjit-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="2.u4" version="13.21">
					<filename>postgresql-docs-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-docs-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="2.u4" version="13.21">
					<filename>postgresql-static-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-static-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="2.u4" version="13.21">
					<filename>postgresql-plpython3-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-plpython3-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="2.u4" version="13.21">
					<filename>postgresql-server-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-server-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="2.u4" version="13.21">
					<filename>postgresql-private-libs-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-private-libs-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="2.u4" version="13.21">
					<filename>postgresql-13.21-2.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/postgresql-13.21-2.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql" release="2.u4" version="13.21">
					<filename>postgresql-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="2.u4" version="13.21">
					<filename>postgresql-contrib-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-contrib-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="2.u4" version="13.21">
					<filename>postgresql-private-devel-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-private-devel-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="2.u4" version="13.21">
					<filename>postgresql-llvmjit-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-llvmjit-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="2.u4" version="13.21">
					<filename>postgresql-private-libs-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-private-libs-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="2.u4" version="13.21">
					<filename>postgresql-test-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-test-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="2.u4" version="13.21">
					<filename>postgresql-server-devel-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-server-devel-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="2.u4" version="13.21">
					<filename>postgresql-server-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-server-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="2.u4" version="13.21">
					<filename>postgresql-static-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-static-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="2.u4" version="13.21">
					<filename>postgresql-docs-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-docs-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="2.u4" version="13.21">
					<filename>postgresql-plpython3-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-plpython3-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="2.u4" version="13.21">
					<filename>postgresql-pltcl-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-pltcl-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="2.u4" version="13.21">
					<filename>postgresql-plperl-13.21-2.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-plperl-13.21-2.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="2.u4" version="13.21">
					<filename>postgresql-test-rpm-macros-13.21-2.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/postgresql-test-rpm-macros-13.21-2.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2189</id>
		<title>An update for libarchive is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5914&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5914" id="CVE-2025-5914" title="CVE-2025-5914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5916&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5916" id="CVE-2025-5916" title="CVE-2025-5916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5917&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5917" id="CVE-2025-5917" title="CVE-2025-5917" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5918&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5918" id="CVE-2025-5918" title="CVE-2025-5918" type="cve"></reference>
		</references>
		<description>CVE-2025-5914:A vulnerability has been identified in the libarchive library, specifically within the archive_read_format_rar_seek_data() function. This flaw involves an integer overflow that can ultimately lead to a double-free condition. Exploiting a double-free vulnerability can result in memory corruption, enabling an attacker to execute arbitrary code or cause a denial-of-service condition.&#xA;CVE-2025-5916:A vulnerability has been identified in the libarchive library. This flaw involves an integer overflow that can be triggered when processing a Web Archive (WARC) file that claims to have more than INT64_MAX - 4 content bytes. An attacker could craft a malicious WARC archive to induce this overflow, potentially leading to unpredictable program behavior, memory corruption, or a denial-of-service condition within applications that process such archives using libarchive.&#xA;CVE-2025-5917:A vulnerability has been identified in the libarchive library. This flaw involves an &#39;off-by-one&#39; miscalculation when handling prefixes and suffixes for file names. This can lead to a 1-byte write overflow. While seemingly small, such an overflow can corrupt adjacent memory, leading to unpredictable program behavior, crashes, or in specific circumstances, could be leveraged as a building block for more sophisticated exploitation.&#xA;CVE-2025-5918:A vulnerability has been identified in the libarchive library. This flaw can be triggered when file streams are piped into bsdtar, potentially allowing for reading past the end of the file. This out-of-bounds read can lead to unintended consequences, including unpredictable program behavior, memory corruption, or a denial-of-service condition.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="bsdcat" release="9.u7" version="3.5.2">
					<filename>bsdcat-3.5.2-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bsdcat-3.5.2-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive" release="9.u7" version="3.5.2">
					<filename>libarchive-3.5.2-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libarchive-3.5.2-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive-devel" release="9.u7" version="3.5.2">
					<filename>libarchive-devel-3.5.2-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libarchive-devel-3.5.2-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcpio" release="9.u7" version="3.5.2">
					<filename>bsdcpio-3.5.2-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bsdcpio-3.5.2-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdtar" release="9.u7" version="3.5.2">
					<filename>bsdtar-3.5.2-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/bsdtar-3.5.2-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcat" release="9.u7" version="3.5.2">
					<filename>bsdcat-3.5.2-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bsdcat-3.5.2-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcpio" release="9.u7" version="3.5.2">
					<filename>bsdcpio-3.5.2-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bsdcpio-3.5.2-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdtar" release="9.u7" version="3.5.2">
					<filename>bsdtar-3.5.2-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/bsdtar-3.5.2-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive" release="9.u7" version="3.5.2">
					<filename>libarchive-3.5.2-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libarchive-3.5.2-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive-devel" release="9.u7" version="3.5.2">
					<filename>libarchive-devel-3.5.2-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libarchive-devel-3.5.2-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libarchive-help" release="9.u7" version="3.5.2">
					<filename>libarchive-help-3.5.2-9.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libarchive-help-3.5.2-9.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2190</id>
		<title>An update for libpq is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4207&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4207" id="CVE-2025-4207" title="CVE-2025-4207" type="cve"></reference>
		</references>
		<description>CVE-2025-4207:Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination.  This affects the database server and also libpq.  Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="libpq-devel" release="1.u2" version="13.21">
					<filename>libpq-devel-13.21-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libpq-devel-13.21-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libpq" release="1.u2" version="13.21">
					<filename>libpq-13.21-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libpq-13.21-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libpq-devel" release="1.u2" version="13.21">
					<filename>libpq-devel-13.21-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libpq-devel-13.21-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libpq" release="1.u2" version="13.21">
					<filename>libpq-13.21-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libpq-13.21-1.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2191</id>
		<title>An update for open-vm-tools is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22247&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22247" id="CVE-2025-22247" title="CVE-2025-22247" type="cve"></reference>
		</references>
		<description>CVE-2025-22247:VMware Tools contains an insecure file handling vulnerability. A malicious actor with non-administrative privileges on a guest VM may tamper the local files to trigger insecure file operations within that VM.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="open-vm-tools" release="4.u3" version="12.0.5">
					<filename>open-vm-tools-12.0.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/open-vm-tools-12.0.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-sdmp" release="4.u3" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/open-vm-tools-sdmp-12.0.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-desktop" release="4.u3" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/open-vm-tools-desktop-12.0.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-sdmp" release="4.u3" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/open-vm-tools-sdmp-12.0.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-desktop" release="4.u3" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/open-vm-tools-desktop-12.0.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools" release="4.u3" version="12.0.5">
					<filename>open-vm-tools-12.0.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/open-vm-tools-12.0.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2192</id>
		<title>An update for apache-commons-fileupload is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48976&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48976" id="CVE-2025-48976" title="CVE-2025-48976" type="cve"></reference>
		</references>
		<description>CVE-2025-48976:Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload.&#xA;&#xA;This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4.&#xA;&#xA;Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="apache-commons-fileupload" release="2.u2" version="1.4">
					<filename>apache-commons-fileupload-1.4-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/apache-commons-fileupload-1.4-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-fileupload-help" release="2.u2" version="1.4">
					<filename>apache-commons-fileupload-help-1.4-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/apache-commons-fileupload-help-1.4-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2193</id>
		<title>An update for libtpms is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49133&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49133" id="CVE-2025-49133" title="CVE-2025-49133" type="cve"></reference>
		</references>
		<description>CVE-2025-49133:Libtpms is a library that targets the integration of TPM functionality into hypervisors, primarily into Qemu. Libtpms, which is derived from the TPM 2.0 reference implementation code published by the Trusted Computing Group, is prone to a potential out of bounds (OOB) read vulnerability. The vulnerability occurs in the ‘CryptHmacSign’ function with an inconsistent pairing of the signKey and signScheme parameters, where the signKey is ALG_KEYEDHASH key and inScheme is an ECC or RSA scheme. The reported vulnerability is in the ‘CryptHmacSign’ function, which is defined in the &#34;Part 4: Supporting Routines – Code&#34; document, section &#34;7.151 - /tpm/src/crypt/CryptUtil.c &#34;. This vulnerability can be triggered from user-mode applications by sending malicious commands to a TPM 2.0/vTPM (swtpm) whose firmware is based on an affected TCG reference implementation. The effect on libtpms is that it will cause an abort due to the detection of the out-of-bounds access, thus for example making a vTPM (swtpm) unavailable to a VM. This vulnerability is fixed in 0.7.12, 0.8.10, 0.9.7, and 0.10.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="libtpms" release="10.u3" version="0.7.3">
					<filename>libtpms-0.7.3-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libtpms-0.7.3-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtpms-devel" release="10.u3" version="0.7.3">
					<filename>libtpms-devel-0.7.3-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libtpms-devel-0.7.3-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtpms" release="10.u3" version="0.7.3">
					<filename>libtpms-0.7.3-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libtpms-0.7.3-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtpms-devel" release="10.u3" version="0.7.3">
					<filename>libtpms-devel-0.7.3-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libtpms-devel-0.7.3-10.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2194</id>
		<title>An update for nodejs-brace-expansion is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5889&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5889" id="CVE-2025-5889" title="CVE-2025-5889" type="cve"></reference>
		</references>
		<description>CVE-2025-5889:A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="nodejs-brace-expansion" release="2.u1" version="1.1.11">
					<filename>nodejs-brace-expansion-1.1.11-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/nodejs-brace-expansion-1.1.11-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2195</id>
		<title>An update for LibRaw is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43961&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43961" id="CVE-2025-43961" title="CVE-2025-43961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43962&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43962" id="CVE-2025-43962" title="CVE-2025-43962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43964" id="CVE-2025-43964" title="CVE-2025-43964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43963&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43963" id="CVE-2025-43963" title="CVE-2025-43963" type="cve"></reference>
		</references>
		<description>CVE-2025-43961:In LibRaw before 0.21.4, metadata/tiff.cpp has an out-of-bounds read in the Fujifilm 0xf00c tag parser.&#xA;CVE-2025-43962:In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp has out-of-bounds reads for tag 0x412 processing, related to large w0 or w1 values or the frac and mult calculations.&#xA;CVE-2025-43964:In LibRaw before 0.21.4, tag 0x412 processing in phase_one_correct in decoders/load_mfbacks.cpp does not enforce minimum w0 and w1 values.&#xA;CVE-2025-43963:In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp allows out-of-buffer access because split_col and split_row values are not checked in 0x041f tag processing.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="0" name="LibRaw-devel" release="9.u6" version="0.20.2">
					<filename>LibRaw-devel-0.20.2-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/LibRaw-devel-0.20.2-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="LibRaw" release="9.u6" version="0.20.2">
					<filename>LibRaw-0.20.2-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/LibRaw-0.20.2-9.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="LibRaw-devel" release="9.u6" version="0.20.2">
					<filename>LibRaw-devel-0.20.2-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/LibRaw-devel-0.20.2-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="LibRaw" release="9.u6" version="0.20.2">
					<filename>LibRaw-0.20.2-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/LibRaw-0.20.2-9.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2196</id>
		<title>An update for udisks2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6019&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6019" id="CVE-2025-6019" title="CVE-2025-6019" type="cve"></reference>
		</references>
		<description>CVE-2025-6019:A Local Privilege Escalation (LPE) vulnerability was found in libblockdev. Generally, the &#34;allow_active&#34; setting in Polkit permits a physically present user to take certain actions based on the session type. Due to the way libblockdev interacts with the udisks daemon, an &#34;allow_active&#34; user on a system may be able escalate to full root privileges on the target host. Normally, udisks mounts user-provided filesystem images with security flags like nosuid and nodev to prevent privilege escalation.  However, a local attacker can create a specially crafted XFS image containing a SUID-root shell, then trick udisks into resizing it. This mounts their malicious filesystem with root privileges, allowing them to execute their SUID-root shell and gain complete control of the system.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="0" name="udisks2-lvm2" release="6.u5" version="2.9.4">
					<filename>udisks2-lvm2-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/udisks2-lvm2-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-vdo" release="6.u5" version="2.9.4">
					<filename>udisks2-vdo-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/udisks2-vdo-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-zram" release="6.u5" version="2.9.4">
					<filename>udisks2-zram-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/udisks2-zram-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libudisks2" release="6.u5" version="2.9.4">
					<filename>libudisks2-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libudisks2-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libudisks2-devel" release="6.u5" version="2.9.4">
					<filename>libudisks2-devel-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/libudisks2-devel-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2" release="6.u5" version="2.9.4">
					<filename>udisks2-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/udisks2-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-lsm" release="6.u5" version="2.9.4">
					<filename>udisks2-lsm-2.9.4-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/udisks2-lsm-2.9.4-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-lvm2" release="6.u5" version="2.9.4">
					<filename>udisks2-lvm2-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/udisks2-lvm2-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-vdo" release="6.u5" version="2.9.4">
					<filename>udisks2-vdo-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/udisks2-vdo-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2" release="6.u5" version="2.9.4">
					<filename>udisks2-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/udisks2-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-lsm" release="6.u5" version="2.9.4">
					<filename>udisks2-lsm-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/udisks2-lsm-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-zram" release="6.u5" version="2.9.4">
					<filename>udisks2-zram-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/udisks2-zram-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libudisks2" release="6.u5" version="2.9.4">
					<filename>libudisks2-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libudisks2-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libudisks2-devel" release="6.u5" version="2.9.4">
					<filename>libudisks2-devel-2.9.4-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/libudisks2-devel-2.9.4-6.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2197</id>
		<title>An update for python-jinja2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27516" id="CVE-2025-27516" title="CVE-2025-27516" type="cve"></reference>
		</references>
		<description>CVE-2025-27516:Jinja is an extensible templating engine. Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja&#39;s sandbox does catch calls to str.format and ensures they don&#39;t escape the sandbox. However, it&#39;s possible to use the |attr filter to get a reference to a string&#39;s plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment&#39;s attribute lookup. This vulnerability is fixed in 3.1.6.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="python-jinja2-help" release="7.u5" version="3.0.3">
					<filename>python-jinja2-help-3.0.3-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python-jinja2-help-3.0.3-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-jinja2" release="7.u5" version="3.0.3">
					<filename>python3-jinja2-3.0.3-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/python3-jinja2-3.0.3-7.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2198</id>
		<title>An update for transfig is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31162&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31162" id="CVE-2025-31162" title="CVE-2025-31162" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31163&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31163" id="CVE-2025-31163" title="CVE-2025-31163" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31164&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31164" id="CVE-2025-31164" title="CVE-2025-31164" type="cve"></reference>
		</references>
		<description>CVE-2025-31162:Floating point exception in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via get_slope function.&#xA;CVE-2025-31163:Segmentation fault in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via put_patternarc function.&#xA;CVE-2025-31164:heap-buffer overflow in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via  create_line_with_spline.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="1" name="transfig" release="3.u1" version="3.2.8b">
					<filename>transfig-3.2.8b-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/transfig-3.2.8b-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="transfig-help" release="3.u1" version="3.2.8b">
					<filename>transfig-help-3.2.8b-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/transfig-help-3.2.8b-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="transfig" release="3.u1" version="3.2.8b">
					<filename>transfig-3.2.8b-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/transfig-3.2.8b-3.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2199</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-29768&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-29768" id="CVE-2025-29768" title="CVE-2025-29768" type="cve"></reference>
		</references>
		<description>CVE-2025-29768:Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press &#39;x&#39; on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="34.u21" version="9.0">
					<filename>vim-minimal-9.0-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/vim-minimal-9.0-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-common" release="34.u21" version="9.0">
					<filename>vim-common-9.0-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/vim-common-9.0-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="34.u21" version="9.0">
					<filename>vim-X11-9.0-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/vim-X11-9.0-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="34.u21" version="9.0">
					<filename>vim-enhanced-9.0-34.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/vim-enhanced-9.0-34.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="34.u21" version="9.0">
					<filename>vim-common-9.0-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/vim-common-9.0-34.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="34.u21" version="9.0">
					<filename>vim-enhanced-9.0-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/vim-enhanced-9.0-34.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="34.u21" version="9.0">
					<filename>vim-X11-9.0-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/vim-X11-9.0-34.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="34.u21" version="9.0">
					<filename>vim-minimal-9.0-34.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/vim-minimal-9.0-34.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="34.u21" version="9.0">
					<filename>vim-filesystem-9.0-34.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/vim-filesystem-9.0-34.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2200</id>
		<title>An update for yelp-xsl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3155&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3155" id="CVE-2025-3155" title="CVE-2025-3155" type="cve"></reference>
		</references>
		<description>CVE-2025-3155:A flaw was found in Yelp. The Gnome user help application allows the help document to execute arbitrary scripts. This vulnerability allows malicious users to input help documents, which may exfiltrate user files to an external environment.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="noarch" epoch="0" name="yelp-xsl" release="2.u1" version="3.38.3">
					<filename>yelp-xsl-3.38.3-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/yelp-xsl-3.38.3-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="yelp-xsl-devel" release="2.u1" version="3.38.3">
					<filename>yelp-xsl-devel-3.38.3-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/yelp-xsl-devel-3.38.3-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="yelp-xsl-help" release="2.u1" version="3.38.3">
					<filename>yelp-xsl-help-3.38.3-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/yelp-xsl-help-3.38.3-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2201</id>
		<title>An update for screen is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46802&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46802" id="CVE-2025-46802" title="CVE-2025-46802" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46804&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46804" id="CVE-2025-46804" title="CVE-2025-46804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46805&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46805" id="CVE-2025-46805" title="CVE-2025-46805" type="cve"></reference>
		</references>
		<description>CVE-2025-46802:For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.&#xA;CVE-2025-46804:A minor information leak when running Screen with setuid-root privileges allows unprivileged users to deduce information about a path that would otherwise not be available.&#xA;&#xA;&#xA;Affected are older Screen versions, as well as version 5.0.0.&#xA;CVE-2025-46805:Screen version 5.0.0 and older version 4 releases have  a TOCTOU race potentially allowing to send SIGHUP, SIGCONT to privileged processes when installed setuid-root.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="1" name="screen" release="3.u2" version="4.9.0">
					<filename>screen-4.9.0-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/screen-4.9.0-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="screen-help" release="3.u2" version="4.9.0">
					<filename>screen-help-4.9.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/screen-help-4.9.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="screen" release="3.u2" version="4.9.0">
					<filename>screen-4.9.0-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/screen-4.9.0-3.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2202</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-06-26"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43965&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43965" id="CVE-2025-43965" title="CVE-2025-43965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46393&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46393" id="CVE-2025-46393" title="CVE-2025-46393" type="cve"></reference>
		</references>
		<description>CVE-2025-43965:In MIFF image processing in ImageMagick before 7.1.1-44, image depth is mishandled after SetQuantumFormat is used.&#xA;CVE-2025-46393:In multispectral MIFF image processing in ImageMagick before 7.1.1-44, packet_size is mishandled (related to the rendering of all channels in an arbitrary order).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.1</name>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ImageMagick-7.1.1.8-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ImageMagick-c++-devel-7.1.1.8-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ImageMagick-perl-7.1.1.8-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ImageMagick-devel-7.1.1.8-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ImageMagick-help-7.1.1.8-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-6.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.1/ImageMagick-c++-7.1.1.8-6.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ImageMagick-devel-7.1.1.8-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ImageMagick-7.1.1.8-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ImageMagick-c++-7.1.1.8-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ImageMagick-c++-devel-7.1.1.8-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ImageMagick-perl-7.1.1.8-6.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="6.u8" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-6.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.1/ImageMagick-help-7.1.1.8-6.u8.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2203</id>
		<title>An update for protobuf is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4565&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4565" id="CVE-2025-4565" title="CVE-2025-4565" type="cve"></reference>
		</references>
		<description>CVE-2025-4565:Any project that uses Protobuf Pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of recursive groups, recursive messages or a series of SGROUP tags can be corrupted by exceeding the Python recursion limit. This can result in a Denial of service by crashing the application with a RecursionError. We recommend upgrading to version =&gt;6.31.1 or beyond commit 17838beda2943d08b8a9d4df5b68f5f04f26d901&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="protobuf-bom" release="9.u2" version="3.14.0">
					<filename>protobuf-bom-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-bom-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="protobuf-javalite" release="9.u2" version="3.14.0">
					<filename>protobuf-javalite-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-javalite-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="protobuf-java" release="9.u2" version="3.14.0">
					<filename>protobuf-java-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-java-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="protobuf-java-util" release="9.u2" version="3.14.0">
					<filename>protobuf-java-util-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-java-util-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="protobuf-javadoc" release="9.u2" version="3.14.0">
					<filename>protobuf-javadoc-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-javadoc-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="protobuf-parent" release="9.u2" version="3.14.0">
					<filename>protobuf-parent-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-parent-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-protobuf" release="9.u2" version="3.14.0">
					<filename>python3-protobuf-3.14.0-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-protobuf-3.14.0-9.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf-compiler" release="9.u2" version="3.14.0">
					<filename>protobuf-compiler-3.14.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-compiler-3.14.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf-devel" release="9.u2" version="3.14.0">
					<filename>protobuf-devel-3.14.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-devel-3.14.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf-lite-devel" release="9.u2" version="3.14.0">
					<filename>protobuf-lite-devel-3.14.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-lite-devel-3.14.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf" release="9.u2" version="3.14.0">
					<filename>protobuf-3.14.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-3.14.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="protobuf-lite" release="9.u2" version="3.14.0">
					<filename>protobuf-lite-3.14.0-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/protobuf-lite-3.14.0-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf" release="9.u2" version="3.14.0">
					<filename>protobuf-3.14.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/protobuf-3.14.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf-devel" release="9.u2" version="3.14.0">
					<filename>protobuf-devel-3.14.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/protobuf-devel-3.14.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf-lite" release="9.u2" version="3.14.0">
					<filename>protobuf-lite-3.14.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/protobuf-lite-3.14.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf-lite-devel" release="9.u2" version="3.14.0">
					<filename>protobuf-lite-devel-3.14.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/protobuf-lite-devel-3.14.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="protobuf-compiler" release="9.u2" version="3.14.0">
					<filename>protobuf-compiler-3.14.0-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/protobuf-compiler-3.14.0-9.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2204</id>
		<title>An update for p7zip is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52168" id="CVE-2023-52168" title="CVE-2023-52168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52169&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52169" id="CVE-2023-52169" title="CVE-2023-52169" type="cve"></reference>
		</references>
		<description>CVE-2023-52168:The NtfsHandler.cpp NTFS handler in 7-Zip before 24.01 (for 7zz) contains a heap-based buffer overflow that allows an attacker to overwrite two bytes at multiple offsets beyond the allocated buffer size: buffer+512*i-2, for i=9, i=10, i=11, etc.&#xA;CVE-2023-52169:The NtfsHandler.cpp NTFS handler in 7-Zip before 24.01 (for 7zz) contains an out-of-bounds read that allows an attacker to read beyond the intended buffer. The bytes read beyond the intended buffer are presented as a part of a filename listed in the file system image. This has security relevance in some known web-service use cases where untrusted users can upload files and have them extracted by a server-side 7-Zip process.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="p7zip" release="6.u3" version="16.02">
					<filename>p7zip-16.02-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/p7zip-16.02-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="p7zip" release="6.u3" version="16.02">
					<filename>p7zip-16.02-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/p7zip-16.02-6.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2205</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9143&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9143" id="CVE-2024-9143" title="CVE-2024-9143" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38797&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38797" id="CVE-2024-38797" title="CVE-2024-38797" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45236&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-45236" id="CVE-2023-45236" title="CVE-2023-45236" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-45237" id="CVE-2023-45237" title="CVE-2023-45237" type="cve"></reference>
		</references>
		<description>CVE-2024-9143:Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted&#xA;explicit values for the field polynomial can lead to out-of-bounds memory reads&#xA;or writes.&#xA;&#xA;Impact summary: Out of bound memory writes can lead to an application crash or&#xA;even a possibility of a remote code execution, however, in all the protocols&#xA;involving Elliptic Curve Cryptography that we&#39;re aware of, either only &#34;named&#xA;curves&#34; are supported, or, if explicit curve parameters are supported, they&#xA;specify an X9.62 encoding of binary (GF(2^m)) curves that can&#39;t represent&#xA;problematic input values. Thus the likelihood of existence of a vulnerable&#xA;application is low.&#xA;&#xA;In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,&#xA;so problematic inputs cannot occur in the context of processing X.509&#xA;certificates.  Any problematic use-cases would have to be using an &#34;exotic&#34;&#xA;curve encoding.&#xA;&#xA;The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),&#xA;and various supporting BN_GF2m_*() functions.&#xA;&#xA;Applications working with &#34;exotic&#34; explicit binary (GF(2^m)) curve parameters,&#xA;that make it possible to represent invalid field polynomials with a zero&#xA;constant term, via the above or similar APIs, may terminate abruptly as a&#xA;result of reading or writing outside of array bounds.  Remote code execution&#xA;cannot easily be ruled out.&#xA;&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;CVE-2024-38797:EDK2 contains a vulnerability in the HashPeImageByType(). A user may cause a read out of bounds when a corrupted data pointer and length are sent via an adjecent network. A successful exploit of this vulnerability may lead to a loss of Integrity and/or Availability.&#xA;CVE-2023-5678:Issue summary: Generating excessively long X9.42 DH keys or checking&#xA;excessively long X9.42 DH keys or parameters may be very slow.&#xA;&#xA;Impact summary: Applications that use the functions DH_generate_key() to&#xA;generate an X9.42 DH key may experience long delays.  Likewise, applications&#xA;that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()&#xA;to check an X9.42 DH key or X9.42 DH parameters may experience long delays.&#xA;Where the key or parameters that are being checked have been obtained from&#xA;an untrusted source this may lead to a Denial of Service.&#xA;&#xA;While DH_check() performs all the necessary checks (as of CVE-2023-3817),&#xA;DH_check_pub_key() doesn&#39;t make any of these checks, and is therefore&#xA;vulnerable for excessively large P and Q parameters.&#xA;&#xA;Likewise, while DH_generate_key() performs a check for an excessively large&#xA;P, it doesn&#39;t check for an excessively large Q.&#xA;&#xA;An application that calls DH_generate_key() or DH_check_pub_key() and&#xA;supplies a key or parameters obtained from an untrusted source could be&#xA;vulnerable to a Denial of Service attack.&#xA;&#xA;DH_generate_key() and DH_check_pub_key() are also called by a number of&#xA;other OpenSSL functions.  An application calling any of those other&#xA;functions may similarly be affected.  The other functions affected by this&#xA;are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().&#xA;&#xA;Also vulnerable are the OpenSSL pkey command line application when using the&#xA;&#34;-pubcheck&#34; option, as well as the OpenSSL genpkey command line application.&#xA;&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2023-45236:EDK2&#39;s Network Package is susceptible to a predictable TCP Initial Sequence Number. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality.&#xA;CVE-2023-45237:EDK2&#39;s Network Package is susceptible to a predictable TCP Initial Sequence Number. This&#xA; vulnerability can be exploited by an attacker to gain unauthorized &#xA;access and potentially lead to a loss of Confidentiality.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="27.u16" version="202011">
					<filename>edk2-ovmf-202011-27.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/edk2-ovmf-202011-27.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="27.u16" version="202011">
					<filename>edk2-aarch64-202011-27.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/edk2-aarch64-202011-27.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="27.u16" version="202011">
					<filename>edk2-help-202011-27.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/edk2-help-202011-27.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="27.u16" version="202011">
					<filename>python3-edk2-devel-202011-27.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-edk2-devel-202011-27.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="27.u16" version="202011">
					<filename>edk2-devel-202011-27.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/edk2-devel-202011-27.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="27.u16" version="202011">
					<filename>edk2-devel-202011-27.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/edk2-devel-202011-27.u16.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2206</id>
		<title>An update for nbdkit is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47711&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47711" id="CVE-2025-47711" title="CVE-2025-47711" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47712&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47712" id="CVE-2025-47712" title="CVE-2025-47712" type="cve"></reference>
		</references>
		<description>CVE-2025-47711:There&#39;s a flaw in the nbdkit server when handling responses from its plugins regarding the status of data blocks. If a client makes a specific request for a very large data range, and a plugin responds with an even larger single block, the nbdkit server can encounter a critical internal error, leading to a denial-of-service.&#xA;CVE-2025-47712:A flaw exists in the nbdkit &#34;blocksize&#34; filter that can be triggered by a specific type of client request. When a client requests block status information for a very large data range, exceeding a certain limit, it causes an internal error in the nbdkit, leading to a denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="nbdkit-bash-completion" release="2.u1" version="1.29.11">
					<filename>nbdkit-bash-completion-1.29.11-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-bash-completion-1.29.11-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nbdkit-help" release="2.u1" version="1.29.11">
					<filename>nbdkit-help-1.29.11-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-help-1.29.11-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-vddk-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-vddk-plugin-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-vddk-plugin-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-basic-plugins" release="2.u1" version="1.29.11">
					<filename>nbdkit-basic-plugins-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-basic-plugins-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-plugins" release="2.u1" version="1.29.11">
					<filename>nbdkit-plugins-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-plugins-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-python3-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-python3-plugin-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-python3-plugin-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-libvirt-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-libvirt-plugin-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-libvirt-plugin-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-perl-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-perl-plugin-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-perl-plugin-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-server" release="2.u1" version="1.29.11">
					<filename>nbdkit-server-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-server-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-devel" release="2.u1" version="1.29.11">
					<filename>nbdkit-devel-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-devel-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-ocaml-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-ocaml-plugin-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-ocaml-plugin-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-guestfs-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-guestfs-plugin-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-guestfs-plugin-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-ocaml-plugin-devel" release="2.u1" version="1.29.11">
					<filename>nbdkit-ocaml-plugin-devel-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-ocaml-plugin-devel-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit" release="2.u1" version="1.29.11">
					<filename>nbdkit-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nbdkit-basic-filters" release="2.u1" version="1.29.11">
					<filename>nbdkit-basic-filters-1.29.11-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/nbdkit-basic-filters-1.29.11-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-python3-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-python3-plugin-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-python3-plugin-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-guestfs-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-guestfs-plugin-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-guestfs-plugin-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-basic-filters" release="2.u1" version="1.29.11">
					<filename>nbdkit-basic-filters-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-basic-filters-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit" release="2.u1" version="1.29.11">
					<filename>nbdkit-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-ocaml-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-ocaml-plugin-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-ocaml-plugin-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-server" release="2.u1" version="1.29.11">
					<filename>nbdkit-server-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-server-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-basic-plugins" release="2.u1" version="1.29.11">
					<filename>nbdkit-basic-plugins-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-basic-plugins-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-ocaml-plugin-devel" release="2.u1" version="1.29.11">
					<filename>nbdkit-ocaml-plugin-devel-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-ocaml-plugin-devel-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-libvirt-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-libvirt-plugin-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-libvirt-plugin-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-plugins" release="2.u1" version="1.29.11">
					<filename>nbdkit-plugins-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-plugins-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-devel" release="2.u1" version="1.29.11">
					<filename>nbdkit-devel-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-devel-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nbdkit-perl-plugin" release="2.u1" version="1.29.11">
					<filename>nbdkit-perl-plugin-1.29.11-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/nbdkit-perl-plugin-1.29.11-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2207</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
		</references>
		<description>CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded&#xA;memory growth when processing TLSv1.3 sessions&#xA;&#xA;Impact summary: An attacker may exploit certain server configurations to trigger&#xA;unbounded memory growth that would lead to a Denial of Service&#xA;&#xA;This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is&#xA;being used (but not if early_data support is also configured and the default&#xA;anti-replay protection is in use). In this case, under certain conditions, the&#xA;session cache can get into an incorrect state and it will fail to flush properly&#xA;as it fills. The session cache will continue to grow in an unbounded manner. A&#xA;malicious client could deliberately create the scenario for this failure to&#xA;force a Denial of Service. It may also happen by accident in normal operation.&#xA;&#xA;This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS&#xA;clients.&#xA;&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL&#xA;1.0.2 is also not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u9" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/openresty-openssl111-asan-1.1.1h-2.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u9" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/openresty-openssl111-asan-1.1.1h-2.u9.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2208</id>
		<title>An update for krb5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3576&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3576" id="CVE-2025-3576" title="CVE-2025-3576" type="cve"></reference>
		</references>
		<description>CVE-2025-3576:A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="krb5" release="24.u12" version="1.19.2">
					<filename>krb5-1.19.2-24.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/krb5-1.19.2-24.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-devel" release="24.u12" version="1.19.2">
					<filename>krb5-devel-1.19.2-24.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/krb5-devel-1.19.2-24.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-libs" release="24.u12" version="1.19.2">
					<filename>krb5-libs-1.19.2-24.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/krb5-libs-1.19.2-24.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-server" release="24.u12" version="1.19.2">
					<filename>krb5-server-1.19.2-24.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/krb5-server-1.19.2-24.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-client" release="24.u12" version="1.19.2">
					<filename>krb5-client-1.19.2-24.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/krb5-client-1.19.2-24.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-devel" release="24.u12" version="1.19.2">
					<filename>krb5-devel-1.19.2-24.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/krb5-devel-1.19.2-24.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-client" release="24.u12" version="1.19.2">
					<filename>krb5-client-1.19.2-24.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/krb5-client-1.19.2-24.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-libs" release="24.u12" version="1.19.2">
					<filename>krb5-libs-1.19.2-24.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/krb5-libs-1.19.2-24.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5" release="24.u12" version="1.19.2">
					<filename>krb5-1.19.2-24.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/krb5-1.19.2-24.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-server" release="24.u12" version="1.19.2">
					<filename>krb5-server-1.19.2-24.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/krb5-server-1.19.2-24.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="krb5-help" release="24.u12" version="1.19.2">
					<filename>krb5-help-1.19.2-24.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/krb5-help-1.19.2-24.u12.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2209</id>
		<title>An update for apache-commons-beanutils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48734&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48734" id="CVE-2025-48734" title="CVE-2025-48734" type="cve"></reference>
		</references>
		<description>CVE-2025-48734:Improper Access Control vulnerability in Apache Commons.&#xA;&#xA;&#xA;&#xA;A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty().&#xA;Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user&#39;s guide and the unit tests.&#xA;&#xA;This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils&#xA;&#xA; 1.x are recommended to upgrade to version 1.11.0, which fixes the issue.&#xA;&#xA;&#xA;Users of the artifact org.apache.commons:commons-beanutils2&#xA;&#xA; 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="apache-commons-beanutils-javadoc" release="4.u1" version="1.9.4">
					<filename>apache-commons-beanutils-javadoc-1.9.4-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/apache-commons-beanutils-javadoc-1.9.4-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-beanutils" release="4.u1" version="1.9.4">
					<filename>apache-commons-beanutils-1.9.4-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/apache-commons-beanutils-1.9.4-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2210</id>
		<title>An update for mod_security is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47947&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47947" id="CVE-2025-47947" title="CVE-2025-47947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39956&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-39956" id="CVE-2022-39956" title="CVE-2022-39956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48866&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48866" id="CVE-2025-48866" title="CVE-2025-48866" type="cve"></reference>
		</references>
		<description>CVE-2025-47947:ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Versions up to and including 2.9.8 are vulnerable to denial of service in one special case (in stable released versions): when the payload&#39;s content type is `application/json`, and there is at least one rule which does a `sanitiseMatchedBytes` action. A patch is available at pull request 3389 and expected to be part of version 2.9.9. No known workarounds are available.&#xA;CVE-2022-39956:The OWASP ModSecurity Core Rule Set (CRS) is affected by a partial rule set bypass for HTTP multipart requests by submitting a payload that uses a character encoding scheme via the Content-Type or the deprecated Content-Transfer-Encoding multipart MIME header fields that will not be decoded and inspected by the web application firewall engine and the rule set. The multipart payload will therefore bypass detection. A vulnerable backend that supports these encoding schemes can potentially be exploited. The legacy CRS versions 3.0.x and 3.1.x are affected, as well as the currently supported versions 3.2.1 and 3.3.2. Integrators and users are advised upgrade to 3.2.2 and 3.3.3 respectively. The mitigation against these vulnerabilities depends on the installation of the latest ModSecurity version (v2.9.6 / v3.0.8).&#xA;CVE-2025-48866:ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Versions prior to 2.9.10 contain a denial of service vulnerability similar to GHSA-859r-vvv8-rm8r/CVE-2025-47947. The `sanitiseArg` (and `sanitizeArg` - this is the same action but an alias) is vulnerable to adding an excessive number of arguments, thereby leading to denial of service. Version 2.9.10 fixes the issue. As a workaround, avoid using rules that contain the  `sanitiseArg` (or `sanitizeArg`) action.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="x86_64" epoch="0" name="mod_security" release="2.u1" version="2.9.9">
					<filename>mod_security-2.9.9-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/mod_security-2.9.9-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_security" release="2.u1" version="2.9.9">
					<filename>mod_security-2.9.9-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/mod_security-2.9.9-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2211</id>
		<title>An update for intel-sgx-ssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
		</references>
		<description>CVE-2023-3446:Issue summary: Checking excessively long DH keys or parameters may be very slow.&#xA;&#xA;Impact summary: Applications that use the functions DH_check(), DH_check_ex()&#xA;or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long&#xA;delays. Where the key or parameters that are being checked have been obtained&#xA;from an untrusted source this may lead to a Denial of Service.&#xA;&#xA;The function DH_check() performs various checks on DH parameters. One of those&#xA;checks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to use&#xA;a very large modulus is slow and OpenSSL will not normally use a modulus which&#xA;is over 10,000 bits in length.&#xA;&#xA;However the DH_check() function checks numerous aspects of the key or parameters&#xA;that have been supplied. Some of those checks use the supplied modulus value&#xA;even if it has already been found to be too large.&#xA;&#xA;An application that calls DH_check() and supplies a key or parameters obtained&#xA;from an untrusted source could be vulernable to a Denial of Service attack.&#xA;&#xA;The function DH_check() is itself called by a number of other OpenSSL functions.&#xA;An application calling any of those other functions may similarly be affected.&#xA;The other functions affected by this are DH_check_ex() and&#xA;EVP_PKEY_param_check().&#xA;&#xA;Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications&#xA;when using the &#39;-check&#39; option.&#xA;&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2023-5678:Issue summary: Generating excessively long X9.42 DH keys or checking&#xA;excessively long X9.42 DH keys or parameters may be very slow.&#xA;&#xA;Impact summary: Applications that use the functions DH_generate_key() to&#xA;generate an X9.42 DH key may experience long delays.  Likewise, applications&#xA;that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()&#xA;to check an X9.42 DH key or X9.42 DH parameters may experience long delays.&#xA;Where the key or parameters that are being checked have been obtained from&#xA;an untrusted source this may lead to a Denial of Service.&#xA;&#xA;While DH_check() performs all the necessary checks (as of CVE-2023-3817),&#xA;DH_check_pub_key() doesn&#39;t make any of these checks, and is therefore&#xA;vulnerable for excessively large P and Q parameters.&#xA;&#xA;Likewise, while DH_generate_key() performs a check for an excessively large&#xA;P, it doesn&#39;t check for an excessively large Q.&#xA;&#xA;An application that calls DH_generate_key() or DH_check_pub_key() and&#xA;supplies a key or parameters obtained from an untrusted source could be&#xA;vulnerable to a Denial of Service attack.&#xA;&#xA;DH_generate_key() and DH_check_pub_key() are also called by a number of&#xA;other OpenSSL functions.  An application calling any of those other&#xA;functions may similarly be affected.  The other functions affected by this&#xA;are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().&#xA;&#xA;Also vulnerable are the OpenSSL pkey command line application when using the&#xA;&#34;-pubcheck&#34; option, as well as the OpenSSL genpkey command line application.&#xA;&#xA;The OpenSSL SSL/TLS implementation is not affected by this issue.&#xA;&#xA;The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.&#xA;CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL&#xA;to crash leading to a potential Denial of Service attack&#xA;&#xA;Impact summary: Applications loading files in the PKCS12 format from untrusted&#xA;sources might terminate abruptly.&#xA;&#xA;A file in PKCS12 format can contain certificates and keys and may come from an&#xA;untrusted source. The PKCS12 specification allows certain fields to be NULL, but&#xA;OpenSSL does not correctly check for this case. This can lead to a NULL pointer&#xA;dereference that results in OpenSSL crashing. If an application processes PKCS12&#xA;files from an untrusted source using the OpenSSL APIs then that application will&#xA;be vulnerable to this issue.&#xA;&#xA;OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),&#xA;PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()&#xA;and PKCS12_newpass().&#xA;&#xA;We have also fixed a similar issue in SMIME_write_PKCS7(). However since this&#xA;function is related to writing data we do not consider it security significant.&#xA;&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded&#xA;memory growth when processing TLSv1.3 sessions&#xA;&#xA;Impact summary: An attacker may exploit certain server configurations to trigger&#xA;unbounded memory growth that would lead to a Denial of Service&#xA;&#xA;This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is&#xA;being used (but not if early_data support is also configured and the default&#xA;anti-replay protection is in use). In this case, under certain conditions, the&#xA;session cache can get into an incorrect state and it will fail to flush properly&#xA;as it fills. The session cache will continue to grow in an unbounded manner. A&#xA;malicious client could deliberately create the scenario for this failure to&#xA;force a Denial of Service. It may also happen by accident in normal operation.&#xA;&#xA;This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS&#xA;clients.&#xA;&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL&#xA;1.0.2 is also not affected by this issue.&#xA;CVE-2024-4741:Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause&#xA;memory to be accessed that was previously freed in some situations&#xA;&#xA;Impact summary: A use after free can have a range of potential consequences such&#xA;as the corruption of valid data, crashes or execution of arbitrary code.&#xA;However, only applications that directly call the SSL_free_buffers function are&#xA;affected by this issue. Applications that do not call this function are not&#xA;vulnerable. Our investigations indicate that this function is rarely used by&#xA;applications.&#xA;&#xA;The SSL_free_buffers function is used to free the internal OpenSSL buffer used&#xA;when processing an incoming record from the network. The call is only expected&#xA;to succeed if the buffer is not currently in use. However, two scenarios have&#xA;been identified where the buffer is freed even when still in use.&#xA;&#xA;The first scenario occurs where a record header has been received from the&#xA;network and processed by OpenSSL, but the full record body has not yet arrived.&#xA;In this case calling SSL_free_buffers will succeed even though a record has only&#xA;been partially processed and the buffer is still in use.&#xA;&#xA;The second scenario occurs where a full record containing application data has&#xA;been received and processed by OpenSSL but the application has only read part of&#xA;this data. Again a call to SSL_free_buffers will succeed even though the buffer&#xA;is still in use.&#xA;&#xA;While these scenarios could occur accidentally during normal operation a&#xA;malicious attacker could attempt to engineer a stituation where this occurs.&#xA;We are not aware of this issue being actively exploited.&#xA;&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="x86_64" epoch="0" name="intel-sgx-ssl" release="3.u3" version="2.15.1">
					<filename>intel-sgx-ssl-2.15.1-3.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/intel-sgx-ssl-2.15.1-3.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="intel-sgx-ssl-devel" release="3.u3" version="2.15.1">
					<filename>intel-sgx-ssl-devel-2.15.1-3.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/intel-sgx-ssl-devel-2.15.1-3.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2212</id>
		<title>An update for linux-sgx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
		</references>
		<description>CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL&#xA;to crash leading to a potential Denial of Service attack&#xA;&#xA;Impact summary: Applications loading files in the PKCS12 format from untrusted&#xA;sources might terminate abruptly.&#xA;&#xA;A file in PKCS12 format can contain certificates and keys and may come from an&#xA;untrusted source. The PKCS12 specification allows certain fields to be NULL, but&#xA;OpenSSL does not correctly check for this case. This can lead to a NULL pointer&#xA;dereference that results in OpenSSL crashing. If an application processes PKCS12&#xA;files from an untrusted source using the OpenSSL APIs then that application will&#xA;be vulnerable to this issue.&#xA;&#xA;OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),&#xA;PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()&#xA;and PKCS12_newpass().&#xA;&#xA;We have also fixed a similar issue in SMIME_write_PKCS7(). However since this&#xA;function is related to writing data we do not consider it security significant.&#xA;&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded&#xA;memory growth when processing TLSv1.3 sessions&#xA;&#xA;Impact summary: An attacker may exploit certain server configurations to trigger&#xA;unbounded memory growth that would lead to a Denial of Service&#xA;&#xA;This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is&#xA;being used (but not if early_data support is also configured and the default&#xA;anti-replay protection is in use). In this case, under certain conditions, the&#xA;session cache can get into an incorrect state and it will fail to flush properly&#xA;as it fills. The session cache will continue to grow in an unbounded manner. A&#xA;malicious client could deliberately create the scenario for this failure to&#xA;force a Denial of Service. It may also happen by accident in normal operation.&#xA;&#xA;This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS&#xA;clients.&#xA;&#xA;The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL&#xA;1.0.2 is also not affected by this issue.&#xA;CVE-2024-4741:Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause&#xA;memory to be accessed that was previously freed in some situations&#xA;&#xA;Impact summary: A use after free can have a range of potential consequences such&#xA;as the corruption of valid data, crashes or execution of arbitrary code.&#xA;However, only applications that directly call the SSL_free_buffers function are&#xA;affected by this issue. Applications that do not call this function are not&#xA;vulnerable. Our investigations indicate that this function is rarely used by&#xA;applications.&#xA;&#xA;The SSL_free_buffers function is used to free the internal OpenSSL buffer used&#xA;when processing an incoming record from the network. The call is only expected&#xA;to succeed if the buffer is not currently in use. However, two scenarios have&#xA;been identified where the buffer is freed even when still in use.&#xA;&#xA;The first scenario occurs where a record header has been received from the&#xA;network and processed by OpenSSL, but the full record body has not yet arrived.&#xA;In this case calling SSL_free_buffers will succeed even though a record has only&#xA;been partially processed and the buffer is still in use.&#xA;&#xA;The second scenario occurs where a full record containing application data has&#xA;been received and processed by OpenSSL but the application has only read part of&#xA;this data. Again a call to SSL_free_buffers will succeed even though the buffer&#xA;is still in use.&#xA;&#xA;While these scenarios could occur accidentally during normal operation a&#xA;malicious attacker could attempt to engineer a stituation where this occurs.&#xA;We are not aware of this issue being actively exploited.&#xA;&#xA;The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-ecdsa-plugin" release="12.u5" version="2.15.1">
					<filename>libsgx-aesm-ecdsa-plugin-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-aesm-ecdsa-plugin-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl" release="12.u5" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-dcap-default-qpl-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-dcap-default-qpl-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common" release="12.u5" version="2.15.1">
					<filename>libsgx-enclave-common-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-enclave-common-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-dcap-pccs" release="12.u5" version="2.15.1">
					<filename>sgx-dcap-pccs-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sgx-dcap-pccs-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgxsdk" release="12.u5" version="2.15.1">
					<filename>sgxsdk-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sgxsdk-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-pce" release="12.u5" version="2.15.1">
					<filename>libsgx-ae-pce-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ae-pce-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qe3" release="12.u5" version="2.15.1">
					<filename>libsgx-ae-qe3-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ae-qe3-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-epid-plugin" release="12.u5" version="2.15.1">
					<filename>libsgx-aesm-epid-plugin-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-aesm-epid-plugin-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql" release="12.u5" version="2.15.1">
					<filename>libsgx-dcap-ql-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-dcap-ql-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify" release="12.u5" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-dcap-quote-verify-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi" release="12.u5" version="2.15.1">
					<filename>libsgx-ra-uefi-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ra-uefi-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-pck-id-retrieval-tool" release="12.u5" version="2.15.1">
					<filename>sgx-pck-id-retrieval-tool-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sgx-pck-id-retrieval-tool-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-qe3-logic" release="12.u5" version="2.15.1">
					<filename>libsgx-qe3-logic-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-qe3-logic-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qve" release="12.u5" version="2.15.1">
					<filename>libsgx-ae-qve-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ae-qve-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-pce-plugin" release="12.u5" version="2.15.1">
					<filename>libsgx-aesm-pce-plugin-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-aesm-pce-plugin-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-enclave-common-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-enclave-common-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid" release="12.u5" version="2.15.1">
					<filename>libsgx-epid-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-epid-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-launch-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-launch-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network" release="12.u5" version="2.15.1">
					<filename>libsgx-ra-network-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ra-network-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-uae-service" release="12.u5" version="2.15.1">
					<filename>libsgx-uae-service-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-uae-service-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-quote-ex-plugin" release="12.u5" version="2.15.1">
					<filename>libsgx-aesm-quote-ex-plugin-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-aesm-quote-ex-plugin-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-quote-ex-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-quote-ex-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-epid" release="12.u5" version="2.15.1">
					<filename>libsgx-ae-epid-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ae-epid-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-launch-plugin" release="12.u5" version="2.15.1">
					<filename>libsgx-aesm-launch-plugin-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-aesm-launch-plugin-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-dcap-ql-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-dcap-ql-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-headers" release="12.u5" version="2.15.1">
					<filename>libsgx-headers-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-headers-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch" release="12.u5" version="2.15.1">
					<filename>libsgx-launch-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-launch-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-ra-uefi-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ra-uefi-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-urts" release="12.u5" version="2.15.1">
					<filename>libsgx-urts-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-urts-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-le" release="12.u5" version="2.15.1">
					<filename>libsgx-ae-le-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ae-le-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-dcap-quote-verify-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-epid-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-epid-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-pce-logic" release="12.u5" version="2.15.1">
					<filename>libsgx-pce-logic-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-pce-logic-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex" release="12.u5" version="2.15.1">
					<filename>libsgx-quote-ex-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-quote-ex-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network-devel" release="12.u5" version="2.15.1">
					<filename>libsgx-ra-network-devel-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libsgx-ra-network-devel-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-aesm-service" release="12.u5" version="2.15.1">
					<filename>sgx-aesm-service-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sgx-aesm-service-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-ra-service" release="12.u5" version="2.15.1">
					<filename>sgx-ra-service-2.15.1-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sgx-ra-service-2.15.1-12.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2213</id>
		<title>An update for libblockdev is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6019&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6019" id="CVE-2025-6019" title="CVE-2025-6019" type="cve"></reference>
		</references>
		<description>CVE-2025-6019:A Local Privilege Escalation (LPE) vulnerability was found in libblockdev. Generally, the &#34;allow_active&#34; setting in Polkit permits a physically present user to take certain actions based on the session type. Due to the way libblockdev interacts with the udisks daemon, an &#34;allow_active&#34; user on a system may be able escalate to full root privileges on the target host. Normally, udisks mounts user-provided filesystem images with security flags like nosuid and nodev to prevent privilege escalation.  However, a local attacker can create a specially crafted XFS image containing a SUID-root shell, then trick udisks into resizing it. This mounts their malicious filesystem with root privileges, allowing them to execute their SUID-root shell and gain complete control of the system.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="python3-blockdev" release="5.u3" version="2.26">
					<filename>python3-blockdev-2.26-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-blockdev-2.26-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libblockdev-tools" release="5.u3" version="2.26">
					<filename>libblockdev-tools-2.26-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libblockdev-tools-2.26-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libblockdev-devel" release="5.u3" version="2.26">
					<filename>libblockdev-devel-2.26-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libblockdev-devel-2.26-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libblockdev" release="5.u3" version="2.26">
					<filename>libblockdev-2.26-5.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libblockdev-2.26-5.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libblockdev-devel" release="5.u3" version="2.26">
					<filename>libblockdev-devel-2.26-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libblockdev-devel-2.26-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libblockdev-tools" release="5.u3" version="2.26">
					<filename>libblockdev-tools-2.26-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libblockdev-tools-2.26-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-blockdev" release="5.u3" version="2.26">
					<filename>python3-blockdev-2.26-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-blockdev-2.26-5.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libblockdev" release="5.u3" version="2.26">
					<filename>libblockdev-2.26-5.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libblockdev-2.26-5.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2214</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6021&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6021" id="CVE-2025-6021" title="CVE-2025-6021" type="cve"></reference>
		</references>
		<description>CVE-2025-6021:A flaw was found in libxml2&#39;s xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="libxml2-help" release="18.u13" version="2.9.14">
					<filename>libxml2-help-2.9.14-18.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libxml2-help-2.9.14-18.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="18.u13" version="2.9.14">
					<filename>python3-libxml2-2.9.14-18.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-libxml2-2.9.14-18.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="18.u13" version="2.9.14">
					<filename>libxml2-2.9.14-18.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libxml2-2.9.14-18.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="18.u13" version="2.9.14">
					<filename>libxml2-devel-2.9.14-18.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libxml2-devel-2.9.14-18.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="18.u13" version="2.9.14">
					<filename>libxml2-2.9.14-18.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libxml2-2.9.14-18.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="18.u13" version="2.9.14">
					<filename>python3-libxml2-2.9.14-18.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-libxml2-2.9.14-18.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="18.u13" version="2.9.14">
					<filename>libxml2-devel-2.9.14-18.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libxml2-devel-2.9.14-18.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2215</id>
		<title>An update for perl-File-Find-Rule is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-10007&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2011-10007" id="CVE-2011-10007" title="CVE-2011-10007" type="cve"></reference>
		</references>
		<description>CVE-2011-10007:File::Find::Rule through 0.34 for Perl is vulnerable to Arbitrary Code Execution when `grep()` encounters a crafted filename.&#xA;&#xA;A file handle is opened with the 2 argument form of `open()` allowing an attacker controlled filename to provide the MODE parameter to `open()`, turning the filename into a command to be executed.&#xA;&#xA;Example:&#xA;&#xA;$ mkdir /tmp/poc; echo &gt; &#34;/tmp/poc/|id&#34;&#xA;$ perl -MFile::Find::Rule \&#xA;    -E &#39;File::Find::Rule-&gt;grep(&#34;foo&#34;)-&gt;in(&#34;/tmp/poc&#34;)&#39;&#xA;uid=1000(user) gid=1000(user) groups=1000(user),100(users)&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="perl-File-Find-Rule-help" release="3.u1" version="0.34">
					<filename>perl-File-Find-Rule-help-0.34-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/perl-File-Find-Rule-help-0.34-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-File-Find-Rule" release="3.u1" version="0.34">
					<filename>perl-File-Find-Rule-0.34-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/perl-File-Find-Rule-0.34-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2216</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22019&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22019" id="CVE-2020-22019" title="CVE-2020-22019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22021&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22021" id="CVE-2020-22021" title="CVE-2020-22021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22026&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22026" id="CVE-2020-22026" title="CVE-2020-22026" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22038&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22038" id="CVE-2020-22038" title="CVE-2020-22038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22039&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22039" id="CVE-2020-22039" title="CVE-2020-22039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22043&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22043" id="CVE-2020-22043" title="CVE-2020-22043" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22044&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22044" id="CVE-2020-22044" title="CVE-2020-22044" type="cve"></reference>
		</references>
		<description>CVE-2020-22019:Buffer Overflow vulnerability in FFmpeg 4.2 at convolution_y_10bit in libavfilter/vf_vmafmotion.c, which could let a remote malicious user cause a Denial of Service.&#xA;CVE-2020-22021:Buffer Overflow vulnerability in FFmpeg 4.2 at filter_edges function in libavfilter/vf_yadif.c, which could let a remote malicious user cause a Denial of Service.&#xA;CVE-2020-22026:Buffer Overflow vulnerability exists in FFmpeg 4.2 in the config_input function at libavfilter/af_tremolo.c, which could let a remote malicious user cause a Denial of Service.&#xA;CVE-2020-22038:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the ff_v4l2_m2m_create_context function in v4l2_m2m.c.&#xA;CVE-2020-22039:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the inavi_add_ientry function.&#xA;CVE-2020-22043:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak at the fifo_alloc_common function in libavutil/fifo.c.&#xA;CVE-2020-22044:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the url_open_dyn_buf_internal function in libavformat/aviobuf.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="23.u7" version="4.2.4">
					<filename>ffmpeg-4.2.4-23.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ffmpeg-4.2.4-23.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="23.u7" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-23.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ffmpeg-devel-4.2.4-23.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="23.u7" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-23.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ffmpeg-libs-4.2.4-23.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="23.u7" version="4.2.4">
					<filename>libavdevice-4.2.4-23.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libavdevice-4.2.4-23.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="23.u7" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-23.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ffmpeg-devel-4.2.4-23.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="23.u7" version="4.2.4">
					<filename>libavdevice-4.2.4-23.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libavdevice-4.2.4-23.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="23.u7" version="4.2.4">
					<filename>ffmpeg-4.2.4-23.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ffmpeg-4.2.4-23.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="23.u7" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-23.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ffmpeg-libs-4.2.4-23.u7.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2217</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48367&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48367" id="CVE-2025-48367" title="CVE-2025-48367" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32023&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32023" id="CVE-2025-32023" title="CVE-2025-32023" type="cve"></reference>
		</references>
		<description>CVE-2025-48367:Redis is an open source, in-memory database that persists on disk. An unauthenticated connection can cause repeated IP protocol errors, leading to client starvation and, ultimately, a denial of service. This vulnerability is fixed in 8.0.3, 7.4.5, 7.2.10, and 6.2.19.&#xA;CVE-2025-32023:Redis is an open source, in-memory database that persists on disk. From 2.8 to before 8.0.3, 7.4.5, 7.2.10, and 6.2.19, an authenticated user may use a specially crafted string to trigger a stack/heap out of bounds write on hyperloglog operations, potentially leading to remote code execution. The bug likely affects all Redis versions with hyperloglog operations implemented. This vulnerability is fixed in 8.0.3, 7.4.5, 7.2.10, and 6.2.19. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing hyperloglog operations. This can be done using ACL to restrict HLL commands.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u12" version="6.2.7">
					<filename>redis6-6.2.7-3.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/redis6-6.2.7-3.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u12" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/redis6-devel-6.2.7-3.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u12" version="6.2.7">
					<filename>redis6-6.2.7-3.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/redis6-6.2.7-3.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u12" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/redis6-devel-6.2.7-3.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u12" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/redis6-doc-6.2.7-3.u12.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2218</id>
		<title>An update for sassc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43357&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-43357" id="CVE-2022-43357" title="CVE-2022-43357" type="cve"></reference>
		</references>
		<description>CVE-2022-43357:Stack overflow vulnerability in ast_selectors.cpp in function Sass::CompoundSelector::has_real_parent_ref in libsass:3.6.5-8-g210218, which can be exploited by attackers to causea denial of service (DoS). Also affects the command line driver for libsass, sassc 3.6.2.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="x86_64" epoch="0" name="sassc" release="5.u1" version="3.5.0">
					<filename>sassc-3.5.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sassc-3.5.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sassc" release="5.u1" version="3.5.0">
					<filename>sassc-3.5.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/sassc-3.5.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2219</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5318&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5318" id="CVE-2025-5318" title="CVE-2025-5318" type="cve"></reference>
		</references>
		<description>CVE-2025-5318:A flaw was found in the libssh library. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="libssh-help" release="10.u5" version="0.9.6">
					<filename>libssh-help-0.9.6-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libssh-help-0.9.6-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="10.u5" version="0.9.6">
					<filename>libssh-devel-0.9.6-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libssh-devel-0.9.6-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh" release="10.u5" version="0.9.6">
					<filename>libssh-0.9.6-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libssh-0.9.6-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="10.u5" version="0.9.6">
					<filename>libssh-0.9.6-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libssh-0.9.6-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="10.u5" version="0.9.6">
					<filename>libssh-devel-0.9.6-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libssh-devel-0.9.6-10.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2220</id>
		<title>An update for gdk-pixbuf2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6199&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6199" id="CVE-2025-6199" title="CVE-2025-6199" type="cve"></reference>
		</references>
		<description>CVE-2025-6199:A flaw was found in the GIF parser of GdkPixbuf’s LZW decoder. When an invalid symbol is encountered during decompression, the decoder sets the reported output size to the full buffer length rather than the actual number of written bytes. This logic error results in uninitialized sections of the buffer being included in the output, potentially leaking arbitrary memory contents in the processed image.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-modules" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/gdk-pixbuf2-modules-2.42.6-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/gdk-pixbuf2-2.42.6-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-devel" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/gdk-pixbuf2-devel-2.42.6-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-tests" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/gdk-pixbuf2-tests-2.42.6-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-tests" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/gdk-pixbuf2-tests-2.42.6-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/gdk-pixbuf2-2.42.6-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-devel" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/gdk-pixbuf2-devel-2.42.6-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-modules" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/gdk-pixbuf2-modules-2.42.6-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdk-pixbuf2-help" release="8.u3" version="2.42.6">
					<filename>gdk-pixbuf2-help-2.42.6-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/gdk-pixbuf2-help-2.42.6-8.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2221</id>
		<title>An update for jq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23337&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23337" id="CVE-2024-23337" title="CVE-2024-23337" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48060&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48060" id="CVE-2025-48060" title="CVE-2025-48060" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49014" id="CVE-2025-49014" title="CVE-2025-49014" type="cve"></reference>
		</references>
		<description>CVE-2024-23337:jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue.&#xA;CVE-2025-48060:jq is a command-line JSON processor. In versions up to and including 1.7.1, a heap-buffer-overflow is present in function `jv_string_vfmt` in the jq_fuzz_execute harness from oss-fuzz. This crash happens on file jv.c, line 1456 `void* p = malloc(sz);`. As of time of publication, no patched versions are available.&#xA;CVE-2025-49014:jq is a command-line JSON processor. In version 1.8.0 a heap use after free vulnerability exists within the function f_strflocaltime of /src/builtin.c. This issue has been patched in commit 499c91b, no known fix version exists at time of publication.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="jq-devel" release="2.u2" version="1.8.0">
					<filename>jq-devel-1.8.0-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/jq-devel-1.8.0-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jq" release="2.u2" version="1.8.0">
					<filename>jq-1.8.0-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/jq-1.8.0-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jq" release="2.u2" version="1.8.0">
					<filename>jq-1.8.0-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/jq-1.8.0-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jq-devel" release="2.u2" version="1.8.0">
					<filename>jq-devel-1.8.0-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/jq-devel-1.8.0-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jq-help" release="2.u2" version="1.8.0">
					<filename>jq-help-1.8.0-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/jq-help-1.8.0-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2222</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48367&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48367" id="CVE-2025-48367" title="CVE-2025-48367" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32023&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32023" id="CVE-2025-32023" title="CVE-2025-32023" type="cve"></reference>
		</references>
		<description>CVE-2025-48367:Redis is an open source, in-memory database that persists on disk. An unauthenticated connection can cause repeated IP protocol errors, leading to client starvation and, ultimately, a denial of service. This vulnerability is fixed in 8.0.3, 7.4.5, 7.2.10, and 6.2.19.&#xA;CVE-2025-32023:Redis is an open source, in-memory database that persists on disk. From 2.8 to before 8.0.3, 7.4.5, 7.2.10, and 6.2.19, an authenticated user may use a specially crafted string to trigger a stack/heap out of bounds write on hyperloglog operations, potentially leading to remote code execution. The bug likely affects all Redis versions with hyperloglog operations implemented. This vulnerability is fixed in 8.0.3, 7.4.5, 7.2.10, and 6.2.19. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing hyperloglog operations. This can be done using ACL to restrict HLL commands.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u12" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/redis5-doc-5.0.7-6.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u12" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/redis5-devel-5.0.7-6.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u12" version="5.0.7">
					<filename>redis5-5.0.7-6.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/redis5-5.0.7-6.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u12" version="5.0.7">
					<filename>redis5-5.0.7-6.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/redis5-5.0.7-6.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u12" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/redis5-devel-5.0.7-6.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2223</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-11358&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-11358" id="CVE-2019-11358" title="CVE-2019-11358" type="cve"></reference>
		</references>
		<description>CVE-2019-11358:jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="x86_64" epoch="2" name="libcephfs2" release="21.u12" version="16.2.7">
					<filename>libcephfs2-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libcephfs2-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw2" release="21.u12" version="16.2.7">
					<filename>librgw2-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/librgw2-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-argparse" release="21.u12" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-ceph-argparse-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados-devel" release="21.u12" version="16.2.7">
					<filename>librados-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/librados-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-selinux" release="21.u12" version="16.2.7">
					<filename>ceph-selinux-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-selinux-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-test" release="21.u12" version="16.2.7">
					<filename>ceph-test-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-test-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados2" release="21.u12" version="16.2.7">
					<filename>librados2-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/librados2-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw-devel" release="21.u12" version="16.2.7">
					<filename>librgw-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/librgw-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rbd" release="21.u12" version="16.2.7">
					<filename>python3-rbd-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-rbd-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-fuse" release="21.u12" version="16.2.7">
					<filename>ceph-fuse-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-fuse-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mds" release="21.u12" version="16.2.7">
					<filename>ceph-mds-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mds-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mgr" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-nbd" release="21.u12" version="16.2.7">
					<filename>rbd-nbd-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/rbd-nbd-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-common" release="21.u12" version="16.2.7">
					<filename>ceph-common-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-common-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-cephfs" release="21.u12" version="16.2.7">
					<filename>python3-cephfs-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-cephfs-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mon" release="21.u12" version="16.2.7">
					<filename>ceph-mon-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mon-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rados" release="21.u12" version="16.2.7">
					<filename>python3-rados-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-rados-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-osd" release="21.u12" version="16.2.7">
					<filename>ceph-osd-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-osd-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-resource-agents" release="21.u12" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-resource-agents-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradospp-devel" release="21.u12" version="16.2.7">
					<filename>libradospp-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libradospp-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-immutable-object-cache" release="21.u12" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-immutable-object-cache-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs-devel" release="21.u12" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libcephfs-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph" release="21.u12" version="16.2.7">
					<filename>ceph-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-radosgw" release="21.u12" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-radosgw-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite" release="21.u12" version="16.2.7">
					<filename>libcephsqlite-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libcephsqlite-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd-devel" release="21.u12" version="16.2.7">
					<filename>librbd-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/librbd-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-base" release="21.u12" version="16.2.7">
					<filename>ceph-base-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-base-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper1" release="21.u12" version="16.2.7">
					<filename>libradosstriper1-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libradosstriper1-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-fuse" release="21.u12" version="16.2.7">
					<filename>rbd-fuse-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/rbd-fuse-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd1" release="21.u12" version="16.2.7">
					<filename>librbd1-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/librbd1-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rgw" release="21.u12" version="16.2.7">
					<filename>python3-rgw-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-rgw-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper-devel" release="21.u12" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libradosstriper-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rados-objclass-devel" release="21.u12" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/rados-objclass-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="cephfs-mirror" release="21.u12" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/cephfs-mirror-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite-devel" release="21.u12" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/libcephsqlite-devel-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-common" release="21.u12" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/python3-ceph-common-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-mirror" release="21.u12" version="16.2.7">
					<filename>rbd-mirror-16.2.7-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/rbd-mirror-16.2.7-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mon" release="21.u12" version="16.2.7">
					<filename>ceph-mon-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-mon-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-radosgw" release="21.u12" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-radosgw-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradospp-devel" release="21.u12" version="16.2.7">
					<filename>libradospp-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libradospp-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-common" release="21.u12" version="16.2.7">
					<filename>ceph-common-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-common-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper-devel" release="21.u12" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libradosstriper-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rados" release="21.u12" version="16.2.7">
					<filename>python3-rados-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-rados-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rbd" release="21.u12" version="16.2.7">
					<filename>python3-rbd-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-rbd-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-immutable-object-cache" release="21.u12" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-immutable-object-cache-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw-devel" release="21.u12" version="16.2.7">
					<filename>librgw-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/librgw-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-cephfs" release="21.u12" version="16.2.7">
					<filename>python3-cephfs-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-cephfs-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rados-objclass-devel" release="21.u12" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/rados-objclass-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rgw" release="21.u12" version="16.2.7">
					<filename>python3-rgw-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-rgw-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-mirror" release="21.u12" version="16.2.7">
					<filename>rbd-mirror-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/rbd-mirror-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd1" release="21.u12" version="16.2.7">
					<filename>librbd1-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/librbd1-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw2" release="21.u12" version="16.2.7">
					<filename>librgw2-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/librgw2-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-nbd" release="21.u12" version="16.2.7">
					<filename>rbd-nbd-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/rbd-nbd-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados-devel" release="21.u12" version="16.2.7">
					<filename>librados-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/librados-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mgr" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-mgr-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-test" release="21.u12" version="16.2.7">
					<filename>ceph-test-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-test-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite-devel" release="21.u12" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libcephsqlite-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-base" release="21.u12" version="16.2.7">
					<filename>ceph-base-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-base-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="cephfs-mirror" release="21.u12" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/cephfs-mirror-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-osd" release="21.u12" version="16.2.7">
					<filename>ceph-osd-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-osd-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs2" release="21.u12" version="16.2.7">
					<filename>libcephfs2-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libcephfs2-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd-devel" release="21.u12" version="16.2.7">
					<filename>librbd-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/librbd-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-fuse" release="21.u12" version="16.2.7">
					<filename>ceph-fuse-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-fuse-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite" release="21.u12" version="16.2.7">
					<filename>libcephsqlite-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libcephsqlite-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados2" release="21.u12" version="16.2.7">
					<filename>librados2-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/librados2-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph" release="21.u12" version="16.2.7">
					<filename>ceph-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs-devel" release="21.u12" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libcephfs-devel-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-resource-agents" release="21.u12" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-resource-agents-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper1" release="21.u12" version="16.2.7">
					<filename>libradosstriper1-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/libradosstriper1-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mds" release="21.u12" version="16.2.7">
					<filename>ceph-mds-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-mds-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-selinux" release="21.u12" version="16.2.7">
					<filename>ceph-selinux-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/ceph-selinux-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-argparse" release="21.u12" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-ceph-argparse-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-common" release="21.u12" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/python3-ceph-common-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-fuse" release="21.u12" version="16.2.7">
					<filename>rbd-fuse-16.2.7-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/rbd-fuse-16.2.7-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-dashboard" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-dashboard-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-dashboard-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-modules-core" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-modules-core-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-modules-core-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-rook" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-rook-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-rook-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-prometheus-alerts" release="21.u12" version="16.2.7">
					<filename>ceph-prometheus-alerts-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-prometheus-alerts-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-cephadm" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-cephadm-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-cephadm-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-k8sevents" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-k8sevents-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-k8sevents-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephadm" release="21.u12" version="16.2.7">
					<filename>cephadm-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/cephadm-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-grafana-dashboards" release="21.u12" version="16.2.7">
					<filename>ceph-grafana-dashboards-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-grafana-dashboards-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-diskprediction-local" release="21.u12" version="16.2.7">
					<filename>ceph-mgr-diskprediction-local-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/ceph-mgr-diskprediction-local-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephfs-top" release="21.u12" version="16.2.7">
					<filename>cephfs-top-16.2.7-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/cephfs-top-16.2.7-21.u12.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2224</id>
		<title>An update for sudo is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-07-16"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32462&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32462" id="CVE-2025-32462" title="CVE-2025-32462" type="cve"></reference>
		</references>
		<description>CVE-2025-32462:Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.2</name>
				<package arch="aarch64" epoch="0" name="sudo-devel" release="19.u10" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-19.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/sudo-devel-1.9.8p2-19.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo" release="19.u10" version="1.9.8p2">
					<filename>sudo-1.9.8p2-19.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.2/sudo-1.9.8p2-19.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sudo-devel" release="19.u10" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-19.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sudo-devel-1.9.8p2-19.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sudo" release="19.u10" version="1.9.8p2">
					<filename>sudo-1.9.8p2-19.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sudo-1.9.8p2-19.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sudo-help" release="19.u10" version="1.9.8p2">
					<filename>sudo-help-1.9.8p2-19.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.2/sudo-help-1.9.8p2-19.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2225</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6170&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6170" id="CVE-2025-6170" title="CVE-2025-6170" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49794&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49794" id="CVE-2025-49794" title="CVE-2025-49794" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49796&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49796" id="CVE-2025-49796" title="CVE-2025-49796" type="cve"></reference>
		</references>
		<description>CVE-2025-6170:A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.&#xA;CVE-2025-49794:A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the &lt;sch:name path=&#34;...&#34;/&gt; schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program&#39;s crash using libxml or other possible undefined behaviors.&#xA;CVE-2025-49796:A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="20.u15" version="2.9.14">
					<filename>python3-libxml2-2.9.14-20.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/python3-libxml2-2.9.14-20.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="20.u15" version="2.9.14">
					<filename>libxml2-2.9.14-20.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libxml2-2.9.14-20.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="20.u15" version="2.9.14">
					<filename>libxml2-devel-2.9.14-20.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libxml2-devel-2.9.14-20.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="20.u15" version="2.9.14">
					<filename>libxml2-2.9.14-20.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libxml2-2.9.14-20.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="20.u15" version="2.9.14">
					<filename>libxml2-devel-2.9.14-20.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libxml2-devel-2.9.14-20.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="20.u15" version="2.9.14">
					<filename>python3-libxml2-2.9.14-20.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/python3-libxml2-2.9.14-20.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="20.u15" version="2.9.14">
					<filename>libxml2-help-2.9.14-20.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libxml2-help-2.9.14-20.u15.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2226</id>
		<title>An update for transfig is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46397&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46397" id="CVE-2025-46397" title="CVE-2025-46397" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46398&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46398" id="CVE-2025-46398" title="CVE-2025-46398" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46399&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46399" id="CVE-2025-46399" title="CVE-2025-46399" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46400&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46400" id="CVE-2025-46400" title="CVE-2025-46400" type="cve"></reference>
		</references>
		<description>CVE-2025-46397:In xfig diagramming tool, a stack-overflow while running fig2dev allows memory corruption via local input manipulation at the bezier_spline function.&#xA;CVE-2025-46398:In xfig diagramming tool, a stack-overflow while running fig2dev allows memory corruption via local input manipulation via read_objects function.&#xA;CVE-2025-46399:A flaw was found in fig2dev. This vulnerability allows availability via local input manipulation via genge_itp_spline function.&#xA;CVE-2025-46400:In xfig diagramming tool, a segmentation fault while running fig2dev allows an attacker to availability via local input manipulation via read_arcobject function.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="1" name="transfig" release="4.u2" version="3.2.8b">
					<filename>transfig-3.2.8b-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/transfig-3.2.8b-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="transfig-help" release="4.u2" version="3.2.8b">
					<filename>transfig-help-3.2.8b-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/transfig-help-3.2.8b-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="transfig" release="4.u2" version="3.2.8b">
					<filename>transfig-3.2.8b-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/transfig-3.2.8b-4.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2227</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56738&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56738" id="CVE-2024-56738" title="CVE-2024-56738" type="cve"></reference>
		</references>
		<description>CVE-2024-56738:GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="1" name="grub2-tools-extra" release="52.u18" version="2.06">
					<filename>grub2-tools-extra-2.06-52.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/grub2-tools-extra-2.06-52.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-efi-aa64" release="52.u18" version="2.06">
					<filename>grub2-efi-aa64-2.06-52.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/grub2-efi-aa64-2.06-52.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools" release="52.u18" version="2.06">
					<filename>grub2-tools-2.06-52.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/grub2-tools-2.06-52.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-efi-aa64-cdboot" release="52.u18" version="2.06">
					<filename>grub2-efi-aa64-cdboot-2.06-52.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/grub2-efi-aa64-cdboot-2.06-52.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-minimal" release="52.u18" version="2.06">
					<filename>grub2-tools-minimal-2.06-52.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/grub2-tools-minimal-2.06-52.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-common" release="52.u18" version="2.06">
					<filename>grub2-common-2.06-52.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-common-2.06-52.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-ia32-modules" release="52.u18" version="2.06">
					<filename>grub2-efi-ia32-modules-2.06-52.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-ia32-modules-2.06-52.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-help" release="52.u18" version="2.06">
					<filename>grub2-help-2.06-52.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-help-2.06-52.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-x64-modules" release="52.u18" version="2.06">
					<filename>grub2-efi-x64-modules-2.06-52.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-x64-modules-2.06-52.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-pc-modules" release="52.u18" version="2.06">
					<filename>grub2-pc-modules-2.06-52.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-pc-modules-2.06-52.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-aa64-modules" release="52.u18" version="2.06">
					<filename>grub2-efi-aa64-modules-2.06-52.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-aa64-modules-2.06-52.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-minimal" release="52.u18" version="2.06">
					<filename>grub2-tools-minimal-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-tools-minimal-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-extra" release="52.u18" version="2.06">
					<filename>grub2-tools-extra-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-tools-extra-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools" release="52.u18" version="2.06">
					<filename>grub2-tools-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-tools-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-efi" release="52.u18" version="2.06">
					<filename>grub2-tools-efi-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-tools-efi-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32-cdboot" release="52.u18" version="2.06">
					<filename>grub2-efi-ia32-cdboot-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-ia32-cdboot-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64" release="52.u18" version="2.06">
					<filename>grub2-efi-x64-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-x64-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64-cdboot" release="52.u18" version="2.06">
					<filename>grub2-efi-x64-cdboot-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-x64-cdboot-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-pc" release="52.u18" version="2.06">
					<filename>grub2-pc-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-pc-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32" release="52.u18" version="2.06">
					<filename>grub2-efi-ia32-2.06-52.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/grub2-efi-ia32-2.06-52.u18.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2228</id>
		<title>An update for apache-commons-lang3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48924&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48924" id="CVE-2025-48924" title="CVE-2025-48924" type="cve"></reference>
		</references>
		<description>CVE-2025-48924:Uncontrolled Recursion vulnerability in Apache Commons Lang.&#xA;&#xA;This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.&#xA;&#xA;The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a &#xA;StackOverflowError could cause an application to stop.&#xA;&#xA;Users are recommended to upgrade to version 3.18.0, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="apache-commons-lang3" release="1" version="3.18.0">
					<filename>apache-commons-lang3-3.18.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/apache-commons-lang3-3.18.0-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-lang3-help" release="1" version="3.18.0">
					<filename>apache-commons-lang3-help-3.18.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/apache-commons-lang3-help-3.18.0-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2229</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42516" id="CVE-2024-42516" title="CVE-2024-42516" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43204" id="CVE-2024-43204" title="CVE-2024-43204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47252&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47252" id="CVE-2024-47252" title="CVE-2024-47252" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23048&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23048" id="CVE-2025-23048" title="CVE-2025-23048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49812&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49812" id="CVE-2025-49812" title="CVE-2025-49812" type="cve"></reference>
		</references>
		<description>CVE-2024-42516:HTTP response splitting in the core of Apache HTTP Server allows an attacker who can manipulate the Content-Type response headers of applications hosted or proxied by the server can split the HTTP response.&#xA;&#xA;This vulnerability was described as CVE-2023-38709 but the patch included in Apache HTTP Server 2.4.59 did not address the issue.&#xA;&#xA;Users are recommended to upgrade to version 2.4.64, which fixes this issue.&#xA;CVE-2024-43204:SSRF in Apache HTTP Server with mod_proxy loaded allows an attacker to send outbound proxy requests to a URL controlled by the attacker.  Requires an unlikely configuration where mod_headers is configured to modify the Content-Type request or response header with a value provided in the HTTP request.&#xA;&#xA;Users are recommended to upgrade to version 2.4.64 which fixes this issue.&#xA;CVE-2024-47252:Insufficient escaping of user-supplied data in mod_ssl in Apache HTTP Server 2.4.63 and earlier allows an untrusted SSL/TLS client to insert escape characters into log files in some configurations.&#xA;&#xA;In a logging configuration where CustomLog is used with &#34;%{varname}x&#34; or &#34;%{varname}c&#34; to log variables provided by mod_ssl such as SSL_TLS_SNI, no escaping is performed by either mod_log_config or mod_ssl and unsanitized data provided by the client may appear in log files.&#xA;CVE-2025-23048:In some mod_ssl configurations on Apache HTTP Server 2.4.35 through to 2.4.63, an access control bypass by trusted clients is possible using TLS 1.3 session resumption.&#xA;&#xA;Configurations are affected when mod_ssl is configured for multiple virtual hosts, with each restricted to a different set of trusted client certificates (for example with a different SSLCACertificateFile/Path setting). In such a case, a client trusted to access one virtual host may be able to access another virtual host, if SSLStrictSNIVHostCheck is not enabled in either virtual host.&#xA;CVE-2025-49812:In some mod_ssl configurations on Apache HTTP Server versions through to 2.4.63, an HTTP desynchronisation attack allows a man-in-the-middle attacker to hijack an HTTP session via a TLS upgrade.&#xA;&#xA;Only configurations using &#34;SSLEngine optional&#34; to enable TLS upgrades are affected. Users are recommended to upgrade to version 2.4.64, which removes support for TLS upgrade.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="25.u16" version="2.4.51">
					<filename>httpd-devel-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/httpd-devel-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="25.u16" version="2.4.51">
					<filename>httpd-tools-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/httpd-tools-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="25.u16" version="2.4.51">
					<filename>mod_ldap-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mod_ldap-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="25.u16" version="2.4.51">
					<filename>mod_md-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mod_md-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="25.u16" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mod_proxy_html-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="25.u16" version="2.4.51">
					<filename>httpd-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/httpd-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="25.u16" version="2.4.51">
					<filename>mod_session-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mod_session-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="25.u16" version="2.4.51">
					<filename>mod_ssl-2.4.51-25.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mod_ssl-2.4.51-25.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="25.u16" version="2.4.51">
					<filename>httpd-devel-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/httpd-devel-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd" release="25.u16" version="2.4.51">
					<filename>httpd-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/httpd-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="25.u16" version="2.4.51">
					<filename>httpd-tools-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/httpd-tools-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="25.u16" version="2.4.51">
					<filename>mod_ldap-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_ldap-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="25.u16" version="2.4.51">
					<filename>mod_md-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_md-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="25.u16" version="2.4.51">
					<filename>mod_session-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_session-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="25.u16" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_proxy_html-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="25.u16" version="2.4.51">
					<filename>mod_ssl-2.4.51-25.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_ssl-2.4.51-25.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="25.u16" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-25.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/httpd-filesystem-2.4.51-25.u16.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="25.u16" version="2.4.51">
					<filename>httpd-help-2.4.51-25.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/httpd-help-2.4.51-25.u16.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2230</id>
		<title>An update for xmlunit is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31573&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-31573" id="CVE-2024-31573" title="CVE-2024-31573" type="cve"></reference>
		</references>
		<description>CVE-2024-31573:XMLUnit for Java has Insecure Defaults when Processing XSLT Stylesheets&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="xmlunit-core" release="2.u1" version="2.7.0">
					<filename>xmlunit-core-2.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xmlunit-core-2.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xmlunit-placeholders" release="2.u1" version="2.7.0">
					<filename>xmlunit-placeholders-2.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xmlunit-placeholders-2.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xmlunit-assertj" release="2.u1" version="2.7.0">
					<filename>xmlunit-assertj-2.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xmlunit-assertj-2.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xmlunit-legacy" release="2.u1" version="2.7.0">
					<filename>xmlunit-legacy-2.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xmlunit-legacy-2.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xmlunit-matchers" release="2.u1" version="2.7.0">
					<filename>xmlunit-matchers-2.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xmlunit-matchers-2.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xmlunit" release="2.u1" version="2.7.0">
					<filename>xmlunit-2.7.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xmlunit-2.7.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2231</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50181" id="CVE-2025-50181" title="CVE-2025-50181" type="cve"></reference>
		</references>
		<description>CVE-2025-50181:urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="python3-urllib3" release="8.u7" version="1.26.12">
					<filename>python3-urllib3-1.26.12-8.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/python3-urllib3-1.26.12-8.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2232</id>
		<title>An update for gdk-pixbuf2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7345&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7345" id="CVE-2025-7345" title="CVE-2025-7345" type="cve"></reference>
		</references>
		<description>CVE-2025-7345:A flaw exists in gdk‑pixbuf within the gdk_pixbuf__jpeg_image_load_increment function (io-jpeg.c) and in glib’s g_base64_encode_step (glib/gbase64.c). When processing maliciously crafted JPEG images, a heap buffer overflow can occur during Base64 encoding, allowing out-of-bounds reads from heap memory, potentially causing application crashes or arbitrary code execution.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gdk-pixbuf2-2.42.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-devel" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gdk-pixbuf2-devel-2.42.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-modules" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gdk-pixbuf2-modules-2.42.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-tests" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gdk-pixbuf2-tests-2.42.6-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-tests" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gdk-pixbuf2-tests-2.42.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-modules" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gdk-pixbuf2-modules-2.42.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gdk-pixbuf2-2.42.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-devel" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gdk-pixbuf2-devel-2.42.6-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gdk-pixbuf2-help" release="9.u4" version="2.42.6">
					<filename>gdk-pixbuf2-help-2.42.6-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gdk-pixbuf2-help-2.42.6-9.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2233</id>
		<title>An update for resource-agents is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47081&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47081" id="CVE-2024-47081" title="CVE-2024-47081" type="cve"></reference>
		</references>
		<description>CVE-2024-47081:Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one&#39;s Requests Session.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="resource-agents-help" release="5.u1" version="4.2.0">
					<filename>resource-agents-help-4.2.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/resource-agents-help-4.2.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ldirectord" release="5.u1" version="4.2.0">
					<filename>ldirectord-4.2.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ldirectord-4.2.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="resource-agents" release="5.u1" version="4.2.0">
					<filename>resource-agents-4.2.0-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/resource-agents-4.2.0-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ldirectord" release="5.u1" version="4.2.0">
					<filename>ldirectord-4.2.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ldirectord-4.2.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="resource-agents-help" release="5.u1" version="4.2.0">
					<filename>resource-agents-help-4.2.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/resource-agents-help-4.2.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="resource-agents" release="5.u1" version="4.2.0">
					<filename>resource-agents-4.2.0-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/resource-agents-4.2.0-5.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2234</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48976&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48976" id="CVE-2025-48976" title="CVE-2025-48976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52434&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52434" id="CVE-2025-52434" title="CVE-2025-52434" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53506&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53506" id="CVE-2025-53506" title="CVE-2025-53506" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52520&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52520" id="CVE-2025-52520" title="CVE-2025-52520" type="cve"></reference>
		</references>
		<description>CVE-2025-48976:Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload.&#xA;&#xA;This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4.&#xA;&#xA;Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue.&#xA;CVE-2025-52434:Concurrent Execution using Shared Resource with Improper Synchronization (&#39;Race Condition&#39;) vulnerability in Apache Tomcat when using the APR/Native connector. This was particularly noticeable with client initiated closes of HTTP/2 connections.&#xA;&#xA;This issue affects Apache Tomcat: from 9.0.0.M1 through 9.0.106.&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.0 through 8.5.100. Other, older, EOL versions &#xA;may also be affected.&#xA;&#xA;&#xA;Users are recommended to upgrade to version 9.0.107, which fixes the issue.&#xA;CVE-2025-53506:Uncontrolled Resource Consumption vulnerability in Apache Tomcat if an HTTP/2 client did not acknowledge the initial settings frame that reduces the maximum permitted concurrent streams.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106.&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.0 through 8.5.100.&#xA;&#xA;&#xA;Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.&#xA;CVE-2025-52520:For some unlikely configurations of multipart upload, an Integer Overflow vulnerability in Apache Tomcat could lead to a DoS via bypassing of size limits.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106.&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.0 through 8.5.100. Other, older, EOL versions &#xA;may also be affected.&#xA;&#xA;&#xA;Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="1" name="tomcat" release="6.u19" version="9.0.100">
					<filename>tomcat-9.0.100-6.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/tomcat-9.0.100-6.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="6.u19" version="9.0.100">
					<filename>tomcat-help-9.0.100-6.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/tomcat-help-9.0.100-6.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="6.u19" version="9.0.100">
					<filename>tomcat-jsvc-9.0.100-6.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/tomcat-jsvc-9.0.100-6.u19.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2235</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32988&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32988" id="CVE-2025-32988" title="CVE-2025-32988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32990&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32990" id="CVE-2025-32990" title="CVE-2025-32990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6395&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6395" id="CVE-2025-6395" title="CVE-2025-6395" type="cve"></reference>
		</references>
		<description>CVE-2025-32988:A flaw was found in GnuTLS. A double-free vulnerability exists in GnuTLS due to incorrect ownership handling in the export logic of Subject Alternative Name (SAN) entries containing an otherName. If the type-id OID is invalid or malformed, GnuTLS will call asn1_delete_structure() on an ASN.1 node it does not own, leading to a double-free condition when the parent function or caller later attempts to free the same structure.&#xA;&#xA;This vulnerability can be triggered using only public GnuTLS APIs and may result in denial of service or memory corruption, depending on allocator behavior.&#xA;CVE-2025-32990:A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system.&#xA;CVE-2025-6395:A NULL pointer dereference flaw was found in the GnuTLS software in _gnutls_figure_common_ciphersuite().&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="gnutls" release="17.u9" version="3.7.2">
					<filename>gnutls-3.7.2-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gnutls-3.7.2-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="17.u9" version="3.7.2">
					<filename>gnutls-devel-3.7.2-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gnutls-devel-3.7.2-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="17.u9" version="3.7.2">
					<filename>gnutls-utils-3.7.2-17.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gnutls-utils-3.7.2-17.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="17.u9" version="3.7.2">
					<filename>gnutls-devel-3.7.2-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gnutls-devel-3.7.2-17.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="17.u9" version="3.7.2">
					<filename>gnutls-3.7.2-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gnutls-3.7.2-17.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="17.u9" version="3.7.2">
					<filename>gnutls-utils-3.7.2-17.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/gnutls-utils-3.7.2-17.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnutls-help" release="17.u9" version="3.7.2">
					<filename>gnutls-help-3.7.2-17.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/gnutls-help-3.7.2-17.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2236</id>
		<title>An update for icu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5222&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5222" id="CVE-2025-5222" title="CVE-2025-5222" type="cve"></reference>
		</references>
		<description>CVE-2025-5222:A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the &#39;subtag&#39; struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="icu" release="8.u5" version="72.1">
					<filename>icu-72.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/icu-72.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libicu-devel" release="8.u5" version="72.1">
					<filename>libicu-devel-72.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libicu-devel-72.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libicu" release="8.u5" version="72.1">
					<filename>libicu-72.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libicu-72.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libicu-devel" release="8.u5" version="72.1">
					<filename>libicu-devel-72.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libicu-devel-72.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="icu" release="8.u5" version="72.1">
					<filename>icu-72.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/icu-72.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libicu" release="8.u5" version="72.1">
					<filename>libicu-72.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libicu-72.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="icu-help" release="8.u5" version="72.1">
					<filename>icu-help-72.1-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/icu-help-72.1-8.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2237</id>
		<title>An update for iperf3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54349&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54349" id="CVE-2025-54349" title="CVE-2025-54349" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54350&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54350" id="CVE-2025-54350" title="CVE-2025-54350" type="cve"></reference>
		</references>
		<description>CVE-2025-54349:In iperf before 3.19.1, iperf_auth.c has an off-by-one error and resultant heap-based buffer overflow.&#xA;CVE-2025-54350:In iperf before 3.19.1, iperf_auth.c has a Base64Decode assertion failure and application exit upon a malformed authentication attempt.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="iperf3-help" release="2.u5" version="3.18">
					<filename>iperf3-help-3.18-2.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/iperf3-help-3.18-2.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3" release="2.u5" version="3.18">
					<filename>iperf3-3.18-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/iperf3-3.18-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iperf3-devel" release="2.u5" version="3.18">
					<filename>iperf3-devel-3.18-2.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/iperf3-devel-3.18-2.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3-devel" release="2.u5" version="3.18">
					<filename>iperf3-devel-3.18-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/iperf3-devel-3.18-2.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iperf3" release="2.u5" version="3.18">
					<filename>iperf3-3.18-2.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/iperf3-3.18-2.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2238</id>
		<title>An update for avahi is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52616&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52616" id="CVE-2024-52616" title="CVE-2024-52616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52615" id="CVE-2024-52615" title="CVE-2024-52615" type="cve"></reference>
		</references>
		<description>CVE-2024-52616:A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.&#xA;CVE-2024-52615:A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="avahi" release="20.u6" version="0.8">
					<filename>avahi-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl" release="20.u6" version="0.8">
					<filename>avahi-compat-howl-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-compat-howl-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-devel" release="20.u6" version="0.8">
					<filename>avahi-devel-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-devel-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-autoipd" release="20.u6" version="0.8">
					<filename>avahi-autoipd-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-autoipd-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib" release="20.u6" version="0.8">
					<filename>avahi-glib-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-glib-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-libs" release="20.u6" version="0.8">
					<filename>avahi-libs-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-libs-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-devel" release="20.u6" version="0.8">
					<filename>avahi-ui-devel-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-ui-devel-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-gtk3" release="20.u6" version="0.8">
					<filename>avahi-ui-gtk3-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-ui-gtk3-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl-devel" release="20.u6" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-compat-howl-devel-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd-devel" release="20.u6" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-compat-libdns_sd-devel-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject-devel" release="20.u6" version="0.8">
					<filename>avahi-gobject-devel-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-gobject-devel-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui" release="20.u6" version="0.8">
					<filename>avahi-ui-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-ui-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-dnsconfd" release="20.u6" version="0.8">
					<filename>avahi-dnsconfd-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-dnsconfd-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib-devel" release="20.u6" version="0.8">
					<filename>avahi-glib-devel-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-glib-devel-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject" release="20.u6" version="0.8">
					<filename>avahi-gobject-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-gobject-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd" release="20.u6" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-compat-libdns_sd-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-tools" release="20.u6" version="0.8">
					<filename>avahi-tools-0.8-20.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-tools-0.8-20.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-dnsconfd" release="20.u6" version="0.8">
					<filename>avahi-dnsconfd-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-dnsconfd-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-devel" release="20.u6" version="0.8">
					<filename>avahi-ui-devel-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-ui-devel-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-gtk3" release="20.u6" version="0.8">
					<filename>avahi-ui-gtk3-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-ui-gtk3-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-autoipd" release="20.u6" version="0.8">
					<filename>avahi-autoipd-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-autoipd-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd" release="20.u6" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-compat-libdns_sd-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-libs" release="20.u6" version="0.8">
					<filename>avahi-libs-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-libs-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib" release="20.u6" version="0.8">
					<filename>avahi-glib-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-glib-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib-devel" release="20.u6" version="0.8">
					<filename>avahi-glib-devel-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-glib-devel-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-devel" release="20.u6" version="0.8">
					<filename>avahi-devel-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-devel-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-tools" release="20.u6" version="0.8">
					<filename>avahi-tools-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-tools-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd-devel" release="20.u6" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-compat-libdns_sd-devel-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject" release="20.u6" version="0.8">
					<filename>avahi-gobject-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-gobject-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl-devel" release="20.u6" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-compat-howl-devel-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject-devel" release="20.u6" version="0.8">
					<filename>avahi-gobject-devel-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-gobject-devel-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi" release="20.u6" version="0.8">
					<filename>avahi-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl" release="20.u6" version="0.8">
					<filename>avahi-compat-howl-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-compat-howl-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui" release="20.u6" version="0.8">
					<filename>avahi-ui-0.8-20.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/avahi-ui-0.8-20.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="avahi-help" release="20.u6" version="0.8">
					<filename>avahi-help-0.8-20.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/avahi-help-0.8-20.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2239</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50068&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50068" id="CVE-2025-50068" title="CVE-2025-50068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50077&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50077" id="CVE-2025-50077" title="CVE-2025-50077" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50078&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50078" id="CVE-2025-50078" title="CVE-2025-50078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50079&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50079" id="CVE-2025-50079" title="CVE-2025-50079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50080&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50080" id="CVE-2025-50080" title="CVE-2025-50080" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50081&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50081" id="CVE-2025-50081" title="CVE-2025-50081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50082&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50082" id="CVE-2025-50082" title="CVE-2025-50082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50083" id="CVE-2025-50083" title="CVE-2025-50083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50084" id="CVE-2025-50084" title="CVE-2025-50084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50085" id="CVE-2025-50085" title="CVE-2025-50085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50086&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50086" id="CVE-2025-50086" title="CVE-2025-50086" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50087&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50087" id="CVE-2025-50087" title="CVE-2025-50087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50091&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50091" id="CVE-2025-50091" title="CVE-2025-50091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50092&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50092" id="CVE-2025-50092" title="CVE-2025-50092" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50093&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50093" id="CVE-2025-50093" title="CVE-2025-50093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50094&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50094" id="CVE-2025-50094" title="CVE-2025-50094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50096" id="CVE-2025-50096" title="CVE-2025-50096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50097&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50097" id="CVE-2025-50097" title="CVE-2025-50097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50098&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50098" id="CVE-2025-50098" title="CVE-2025-50098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50099&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50099" id="CVE-2025-50099" title="CVE-2025-50099" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50100&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50100" id="CVE-2025-50100" title="CVE-2025-50100" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50101&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50101" id="CVE-2025-50101" title="CVE-2025-50101" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50102&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50102" id="CVE-2025-50102" title="CVE-2025-50102" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50104&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50104" id="CVE-2025-50104" title="CVE-2025-50104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53023&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53023" id="CVE-2025-53023" title="CVE-2025-53023" type="cve"></reference>
		</references>
		<description>CVE-2025-50068:Vulnerability in the MySQL Cluster product of Oracle MySQL (component: Cluster: General).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Cluster executes to compromise MySQL Cluster.  Successful attacks of this vulnerability can result in takeover of MySQL Cluster. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).&#xA;CVE-2025-50077:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50078:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50079:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50080:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50081:Vulnerability in the MySQL Client product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Client.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Client accessible data as well as  unauthorized read access to a subset of MySQL Client accessible data. CVSS 3.1 Base Score 3.1 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N).&#xA;CVE-2025-50082:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50083:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50084:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50085:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-50086:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50087:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all MySQL Server accessible data. CVSS 3.1 Base Score 4.9 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N).&#xA;CVE-2025-50091:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50092:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50093:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50094:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.42, 8.4.5 and  9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50096:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50097:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50098:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2025-50099:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50100:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.2 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2025-50101:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50102:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-50104:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).&#xA;CVE-2025-53023:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.42. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u4" version="8.0.43">
					<filename>mysql-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u4" version="8.0.43">
					<filename>mysql-errmsg-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-errmsg-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u4" version="8.0.43">
					<filename>mysql-libs-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-libs-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u4" version="8.0.43">
					<filename>mysql-server-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-server-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u4" version="8.0.43">
					<filename>mysql-test-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-test-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u4" version="8.0.43">
					<filename>mysql-help-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-help-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u4" version="8.0.43">
					<filename>mysql-common-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-common-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u4" version="8.0.43">
					<filename>mysql-config-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-config-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u4" version="8.0.43">
					<filename>mysql-devel-8.0.43-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mysql-devel-8.0.43-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u4" version="8.0.43">
					<filename>mysql-libs-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-libs-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u4" version="8.0.43">
					<filename>mysql-devel-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-devel-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u4" version="8.0.43">
					<filename>mysql-server-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-server-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u4" version="8.0.43">
					<filename>mysql-common-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-common-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u4" version="8.0.43">
					<filename>mysql-config-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-config-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u4" version="8.0.43">
					<filename>mysql-help-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-help-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u4" version="8.0.43">
					<filename>mysql-test-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-test-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u4" version="8.0.43">
					<filename>mysql-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u4" version="8.0.43">
					<filename>mysql-errmsg-8.0.43-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mysql-errmsg-8.0.43-1.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2240</id>
		<title>An update for netty3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29025&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29025" id="CVE-2024-29025" title="CVE-2024-29025" type="cve"></reference>
		</references>
		<description>CVE-2024-29025:Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. The `HttpPostRequestDecoder` can be tricked to accumulate data. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits. This vulnerability is fixed in 4.1.108.Final.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="netty3" release="9.u3" version="3.10.6">
					<filename>netty3-3.10.6-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/netty3-3.10.6-9.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2241</id>
		<title>An update for iputils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47268&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47268" id="CVE-2025-47268" title="CVE-2025-47268" type="cve"></reference>
		</references>
		<description>CVE-2025-47268:ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="iputils" release="7.u5" version="20221126">
					<filename>iputils-20221126-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/iputils-20221126-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iputils" release="7.u5" version="20221126">
					<filename>iputils-20221126-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/iputils-20221126-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="iputils-help" release="7.u5" version="20221126">
					<filename>iputils-help-20221126-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/iputils-help-20221126-7.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2242</id>
		<title>An update for varnish is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8671&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8671" id="CVE-2025-8671" title="CVE-2025-8671" type="cve"></reference>
		</references>
		<description>CVE-2025-8671:A mismatch caused by client-triggered server-sent stream resets between HTTP/2 specifications and the internal architectures of some HTTP/2 implementations may result in excessive server resource consumption leading to denial-of-service (DoS).  By opening streams and then rapidly triggering the server to reset them—using malformed frames or flow control errors—an attacker can exploit incorrect stream accounting. Streams reset by the server are considered closed at the protocol level, even though backend processing continues. This allows a client to cause the server to handle an unbounded number of concurrent streams on a single connection. This CVE will be updated as affected product details are released.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="varnish-help" release="4.u3" version="7.4.3">
					<filename>varnish-help-7.4.3-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/varnish-help-7.4.3-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish-devel" release="4.u3" version="7.4.3">
					<filename>varnish-devel-7.4.3-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/varnish-devel-7.4.3-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="varnish" release="4.u3" version="7.4.3">
					<filename>varnish-7.4.3-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/varnish-7.4.3-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="varnish" release="4.u3" version="7.4.3">
					<filename>varnish-7.4.3-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/varnish-7.4.3-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="varnish-devel" release="4.u3" version="7.4.3">
					<filename>varnish-devel-7.4.3-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/varnish-devel-7.4.3-4.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2243</id>
		<title>An update for openjpeg2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50952&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50952" id="CVE-2025-50952" title="CVE-2025-50952" type="cve"></reference>
		</references>
		<description>CVE-2025-50952:openjpeg v 2.5.0 was discovered to contain a NULL pointer dereference via the component /openjp2/dwt.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="openjpeg2" release="7.u4" version="2.5.0">
					<filename>openjpeg2-2.5.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/openjpeg2-2.5.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-tools" release="7.u4" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/openjpeg2-tools-2.5.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-devel" release="7.u4" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/openjpeg2-devel-2.5.0-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2-devel" release="7.u4" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/openjpeg2-devel-2.5.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2-tools" release="7.u4" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/openjpeg2-tools-2.5.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2" release="7.u4" version="2.5.0">
					<filename>openjpeg2-2.5.0-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/openjpeg2-2.5.0-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openjpeg2-help" release="7.u4" version="2.5.0">
					<filename>openjpeg2-help-2.5.0-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/openjpeg2-help-2.5.0-7.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2244</id>
		<title>An update for pam is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6020" id="CVE-2025-6020" title="CVE-2025-6020" type="cve"></reference>
		</references>
		<description>CVE-2025-6020:A flaw was found in linux-pam. The module pam_namespace may use access user-controlled paths without proper protection, allowing local users to elevate their privileges to root via multiple symlink attacks and race conditions.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="pam" release="13.u10" version="1.5.2">
					<filename>pam-1.5.2-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/pam-1.5.2-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam-devel" release="13.u10" version="1.5.2">
					<filename>pam-devel-1.5.2-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/pam-devel-1.5.2-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam" release="13.u10" version="1.5.2">
					<filename>pam-1.5.2-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/pam-1.5.2-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam-devel" release="13.u10" version="1.5.2">
					<filename>pam-devel-1.5.2-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/pam-devel-1.5.2-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pam-help" release="13.u10" version="1.5.2">
					<filename>pam-help-1.5.2-13.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/pam-help-1.5.2-13.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2245</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1220&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1220" id="CVE-2025-1220" title="CVE-2025-1220" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1735&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1735" id="CVE-2025-1735" title="CVE-2025-1735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6491&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6491" id="CVE-2025-6491" title="CVE-2025-6491" type="cve"></reference>
		</references>
		<description>CVE-2025-1220:In PHP versions:8.1.* before 8.1.33, 8.2.* before 8.2.29, 8.3.* before 8.3.23, 8.4.* before 8.4.10 some functions like fsockopen() lack validation that the hostname supplied does not contain null characters. This may lead to other functions like parse_url() treat the hostname in different way, thus opening way to security problems if the user code implements access checks before access using such functions.&#xA;CVE-2025-1735:In PHP versions:8.1.* before 8.1.33, 8.2.* before 8.2.29, 8.3.* before 8.3.23, 8.4.* pgsql and pdo_pgsql escaping functions do not check if the underlying quoting functions returned errors. This could cause crashes if Postgres server rejects the string as invalid.&#xA;CVE-2025-6491:In PHP versions:8.1.* before 8.1.33, 8.2.* before 8.2.29, 8.3.* before 8.3.23, 8.4.* before 8.4.10 when parsing XML data in SOAP extensions, overly large (&gt;2Gb) XML namespace prefix may lead to null pointer dereference. This may lead to crashes and affect the availability of the target server.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="php-snmp" release="10.u8" version="8.0.30">
					<filename>php-snmp-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-snmp-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="10.u8" version="8.0.30">
					<filename>php-gd-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-gd-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="10.u8" version="8.0.30">
					<filename>php-odbc-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-odbc-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php" release="10.u8" version="8.0.30">
					<filename>php-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="10.u8" version="8.0.30">
					<filename>php-embedded-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-embedded-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="10.u8" version="8.0.30">
					<filename>php-ldap-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-ldap-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="10.u8" version="8.0.30">
					<filename>php-mbstring-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-mbstring-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="10.u8" version="8.0.30">
					<filename>php-pdo-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-pdo-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="10.u8" version="8.0.30">
					<filename>php-cli-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-cli-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="10.u8" version="8.0.30">
					<filename>php-devel-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-devel-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="10.u8" version="8.0.30">
					<filename>php-enchant-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-enchant-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="10.u8" version="8.0.30">
					<filename>php-intl-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-intl-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="10.u8" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-mysqlnd-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="10.u8" version="8.0.30">
					<filename>php-dba-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-dba-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="10.u8" version="8.0.30">
					<filename>php-dbg-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-dbg-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="10.u8" version="8.0.30">
					<filename>php-common-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-common-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="10.u8" version="8.0.30">
					<filename>php-opcache-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-opcache-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="10.u8" version="8.0.30">
					<filename>php-pgsql-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-pgsql-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="10.u8" version="8.0.30">
					<filename>php-xml-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-xml-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="10.u8" version="8.0.30">
					<filename>php-gmp-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-gmp-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="10.u8" version="8.0.30">
					<filename>php-soap-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-soap-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="10.u8" version="8.0.30">
					<filename>php-bcmath-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-bcmath-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="10.u8" version="8.0.30">
					<filename>php-process-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-process-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="10.u8" version="8.0.30">
					<filename>php-sodium-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-sodium-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="10.u8" version="8.0.30">
					<filename>php-fpm-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-fpm-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="10.u8" version="8.0.30">
					<filename>php-tidy-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-tidy-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="10.u8" version="8.0.30">
					<filename>php-ffi-8.0.30-10.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-ffi-8.0.30-10.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="10.u8" version="8.0.30">
					<filename>php-opcache-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-opcache-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="10.u8" version="8.0.30">
					<filename>php-odbc-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-odbc-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="10.u8" version="8.0.30">
					<filename>php-xml-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-xml-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="10.u8" version="8.0.30">
					<filename>php-sodium-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-sodium-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="10.u8" version="8.0.30">
					<filename>php-fpm-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-fpm-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="10.u8" version="8.0.30">
					<filename>php-intl-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-intl-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="10.u8" version="8.0.30">
					<filename>php-snmp-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-snmp-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="10.u8" version="8.0.30">
					<filename>php-soap-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-soap-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="10.u8" version="8.0.30">
					<filename>php-pdo-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-pdo-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="10.u8" version="8.0.30">
					<filename>php-bcmath-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-bcmath-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="10.u8" version="8.0.30">
					<filename>php-ffi-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-ffi-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="10.u8" version="8.0.30">
					<filename>php-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="10.u8" version="8.0.30">
					<filename>php-gd-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-gd-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="10.u8" version="8.0.30">
					<filename>php-dba-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-dba-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="10.u8" version="8.0.30">
					<filename>php-tidy-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-tidy-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="10.u8" version="8.0.30">
					<filename>php-embedded-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-embedded-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="10.u8" version="8.0.30">
					<filename>php-mbstring-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-mbstring-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="10.u8" version="8.0.30">
					<filename>php-cli-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-cli-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="10.u8" version="8.0.30">
					<filename>php-enchant-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-enchant-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="10.u8" version="8.0.30">
					<filename>php-devel-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-devel-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="10.u8" version="8.0.30">
					<filename>php-dbg-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-dbg-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="10.u8" version="8.0.30">
					<filename>php-pgsql-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-pgsql-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="10.u8" version="8.0.30">
					<filename>php-process-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-process-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="10.u8" version="8.0.30">
					<filename>php-common-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-common-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="10.u8" version="8.0.30">
					<filename>php-gmp-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-gmp-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="10.u8" version="8.0.30">
					<filename>php-ldap-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-ldap-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="10.u8" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-10.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/php-mysqlnd-8.0.30-10.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="php-help" release="10.u8" version="8.0.30">
					<filename>php-help-8.0.30-10.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/php-help-8.0.30-10.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2246</id>
		<title>An update for ncurses is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6141&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6141" id="CVE-2025-6141" title="CVE-2025-6141" type="cve"></reference>
		</references>
		<description>CVE-2025-6141:A vulnerability has been found in GNU ncurses up to 6.5-20250322 and classified as problematic. This vulnerability affects the function postprocess_termcap of the file tinfo/parse_entry.c. The manipulation leads to stack-based buffer overflow. The attack needs to be approached locally. Upgrading to version 6.5-20250329 is able to address this issue. It is recommended to upgrade the affected component.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="ncurses-static" release="16.u6" version="6.3">
					<filename>ncurses-static-6.3-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-static-6.3-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-devel" release="16.u6" version="6.3">
					<filename>ncurses-devel-6.3-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-devel-6.3-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-compat-libs" release="16.u6" version="6.3">
					<filename>ncurses-compat-libs-6.3-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-compat-libs-6.3-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-help" release="16.u6" version="6.3">
					<filename>ncurses-help-6.3-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-help-6.3-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-libs" release="16.u6" version="6.3">
					<filename>ncurses-libs-6.3-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-libs-6.3-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses" release="16.u6" version="6.3">
					<filename>ncurses-6.3-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-6.3-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-compat-libs" release="16.u6" version="6.3">
					<filename>ncurses-compat-libs-6.3-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ncurses-compat-libs-6.3-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-static" release="16.u6" version="6.3">
					<filename>ncurses-static-6.3-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ncurses-static-6.3-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-help" release="16.u6" version="6.3">
					<filename>ncurses-help-6.3-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ncurses-help-6.3-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses" release="16.u6" version="6.3">
					<filename>ncurses-6.3-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ncurses-6.3-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-devel" release="16.u6" version="6.3">
					<filename>ncurses-devel-6.3-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ncurses-devel-6.3-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-libs" release="16.u6" version="6.3">
					<filename>ncurses-libs-6.3-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ncurses-libs-6.3-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ncurses-base" release="16.u6" version="6.3">
					<filename>ncurses-base-6.3-16.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ncurses-base-6.3-16.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2247</id>
		<title>An update for mod_http2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49630&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49630" id="CVE-2025-49630" title="CVE-2025-49630" type="cve"></reference>
		</references>
		<description>CVE-2025-49630:In certain proxy configurations, a denial of service attack against Apache HTTP Server versions 2.4.26 through to 2.4.63 can be triggered by untrusted clients causing an assertion in mod_proxy_http2.&#xA;&#xA;Configurations affected are a reverse proxy is configured for an HTTP/2 backend, with ProxyPreserveHost set to &#34;on&#34;.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="mod_http2" release="4.u2" version="1.15.25">
					<filename>mod_http2-1.15.25-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_http2-1.15.25-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_http2" release="4.u2" version="1.15.25">
					<filename>mod_http2-1.15.25-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/mod_http2-1.15.25-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="mod_http2-help" release="4.u2" version="1.15.25">
					<filename>mod_http2-help-1.15.25-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/mod_http2-help-1.15.25-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2248</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8177" id="CVE-2025-8177" title="CVE-2025-8177" type="cve"></reference>
		</references>
		<description>CVE-2025-8177:A vulnerability was found in LibTIFF up to 4.7.0. It has been rated as critical. This issue affects the function setrow of the file tools/thumbnail.c. The manipulation leads to buffer overflow. An attack has to be approached locally. The patch is named e8c9d6c616b19438695fd829e58ae4fde5bfbc22. It is recommended to apply a patch to fix this issue. This vulnerability only affects products that are no longer supported by the maintainer.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="39.u15" version="4.3.0">
					<filename>libtiff-static-4.3.0-39.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libtiff-static-4.3.0-39.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="39.u15" version="4.3.0">
					<filename>libtiff-devel-4.3.0-39.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libtiff-devel-4.3.0-39.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="39.u15" version="4.3.0">
					<filename>libtiff-4.3.0-39.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libtiff-4.3.0-39.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="39.u15" version="4.3.0">
					<filename>libtiff-tools-4.3.0-39.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libtiff-tools-4.3.0-39.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="39.u15" version="4.3.0">
					<filename>libtiff-help-4.3.0-39.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libtiff-help-4.3.0-39.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="39.u15" version="4.3.0">
					<filename>libtiff-static-4.3.0-39.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libtiff-static-4.3.0-39.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="39.u15" version="4.3.0">
					<filename>libtiff-devel-4.3.0-39.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libtiff-devel-4.3.0-39.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="39.u15" version="4.3.0">
					<filename>libtiff-tools-4.3.0-39.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libtiff-tools-4.3.0-39.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff" release="39.u15" version="4.3.0">
					<filename>libtiff-4.3.0-39.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libtiff-4.3.0-39.u15.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2249</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7039&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7039" id="CVE-2025-7039" title="CVE-2025-7039" type="cve"></reference>
		</references>
		<description>CVE-2025-7039:An Improper Access Control vulnerability has been found in EmbedAI 2.1 and below. This vulnerability allows an authenticated attacker to show subscription&#39;s information of others users by changing the &#34;SUSCBRIPTION_ID&#34; param of the endpoint &#34;/demos/embedai/subscriptions/show/&lt;SUSCBRIPTION_ID&gt;&#34;.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="glib2-static" release="22.u17" version="2.72.2">
					<filename>glib2-static-2.72.2-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/glib2-static-2.72.2-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="22.u17" version="2.72.2">
					<filename>glib2-tests-2.72.2-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/glib2-tests-2.72.2-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2" release="22.u17" version="2.72.2">
					<filename>glib2-2.72.2-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/glib2-2.72.2-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="22.u17" version="2.72.2">
					<filename>glib2-devel-2.72.2-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/glib2-devel-2.72.2-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2" release="22.u17" version="2.72.2">
					<filename>glib2-2.72.2-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/glib2-2.72.2-22.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="22.u17" version="2.72.2">
					<filename>glib2-devel-2.72.2-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/glib2-devel-2.72.2-22.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="22.u17" version="2.72.2">
					<filename>glib2-tests-2.72.2-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/glib2-tests-2.72.2-22.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-static" release="22.u17" version="2.72.2">
					<filename>glib2-static-2.72.2-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/glib2-static-2.72.2-22.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="22.u17" version="2.72.2">
					<filename>glib2-help-2.72.2-22.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/glib2-help-2.72.2-22.u17.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2250</id>
		<title>An update for jakarta-mail is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7962&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7962" id="CVE-2025-7962" title="CVE-2025-7962" type="cve"></reference>
		</references>
		<description>CVE-2025-7962:In Jakarta Mail 2.0.2 it is possible to preform a SMTP Injection by utilizing the \r and \n UTF-8 characters to separate different messages.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="jakarta-mail" release="4.u1" version="1.6.7">
					<filename>jakarta-mail-1.6.7-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/jakarta-mail-1.6.7-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2251</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21688&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-21688" id="CVE-2020-21688" title="CVE-2020-21688" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-21697" id="CVE-2020-21697" title="CVE-2020-21697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22020" id="CVE-2020-22020" title="CVE-2020-22020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22037&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22037" id="CVE-2020-22037" title="CVE-2020-22037" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22042&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22042" id="CVE-2020-22042" title="CVE-2020-22042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22051&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22051" id="CVE-2020-22051" title="CVE-2020-22051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38090&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-38090" id="CVE-2021-38090" title="CVE-2021-38090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22919&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22919" id="CVE-2025-22919" title="CVE-2025-22919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22921&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22921" id="CVE-2025-22921" title="CVE-2025-22921" type="cve"></reference>
		</references>
		<description>CVE-2020-21688:A heap-use-after-free in the av_freep function in libavutil/mem.c of FFmpeg 4.2 allows attackers to execute arbitrary code.&#xA;CVE-2020-21697:A heap-use-after-free in the mpeg_mux_write_packet function in libavformat/mpegenc.c of FFmpeg 4.2 allows to cause a denial of service (DOS) via a crafted avi file.&#xA;CVE-2020-22020:Buffer Overflow vulnerability in FFmpeg 4.2 in the build_diff_map function in libavfilter/vf_fieldmatch.c, which could let a remote malicious user cause a Denial of Service.&#xA;CVE-2020-22037:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in avcodec_alloc_context3 at options.c.&#xA;CVE-2020-22042:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak is affected by: memory leak in the link_filter_inouts function in libavfilter/graphparser.c.&#xA;CVE-2020-22051:A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the filter_frame function in vf_tile.c.&#xA;CVE-2021-38090:Integer Overflow vulnerability in function filter16_roberts in libavfilter/vf_convolution.c in Ffmpeg 4.2.1, allows attackers to cause a Denial of Service or other unspecified impacts.&#xA;CVE-2025-22919:A reachable assertion in FFmpeg git-master commit N-113007-g8d24a28d06 allows attackers to cause a Denial of Service (DoS) via opening a crafted AAC file.&#xA;CVE-2025-22921:FFmpeg git-master,N-113007-g8d24a28d06 was discovered to contain a segmentation violation via the component /libavcodec/jpeg2000dec.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="24.u8" version="4.2.4">
					<filename>ffmpeg-4.2.4-24.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ffmpeg-4.2.4-24.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="24.u8" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-24.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ffmpeg-libs-4.2.4-24.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="24.u8" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-24.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ffmpeg-devel-4.2.4-24.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="24.u8" version="4.2.4">
					<filename>libavdevice-4.2.4-24.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/libavdevice-4.2.4-24.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="24.u8" version="4.2.4">
					<filename>ffmpeg-4.2.4-24.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ffmpeg-4.2.4-24.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="24.u8" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-24.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ffmpeg-devel-4.2.4-24.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="24.u8" version="4.2.4">
					<filename>libavdevice-4.2.4-24.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/libavdevice-4.2.4-24.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="24.u8" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-24.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ffmpeg-libs-4.2.4-24.u8.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2252</id>
		<title>An update for jython is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6069&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6069" id="CVE-2025-6069" title="CVE-2025-6069" type="cve"></reference>
		</references>
		<description>CVE-2025-6069:The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="jython-javadoc" release="3.u1" version="2.7.1">
					<filename>jython-javadoc-2.7.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/jython-javadoc-2.7.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jython" release="3.u1" version="2.7.1">
					<filename>jython-2.7.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/jython-2.7.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jython-demo" release="3.u1" version="2.7.1">
					<filename>jython-demo-2.7.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/jython-demo-2.7.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2253</id>
		<title>An update for python-werkzeug is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34069&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-34069" id="CVE-2024-34069" title="CVE-2024-34069" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46136&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-46136" id="CVE-2023-46136" title="CVE-2023-46136" type="cve"></reference>
		</references>
		<description>CVE-2024-34069:Werkzeug is a comprehensive WSGI web application library. The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer&#39;s machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer&#39;s application that will trigger the debugger. This vulnerability is fixed in 3.0.3.&#xA;CVE-2023-46136:Werkzeug is a comprehensive WSGI web application library. If an upload of a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. This vulnerability has been patched in version 3.0.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="python-werkzeug-help" release="6.u5" version="2.0.3">
					<filename>python-werkzeug-help-2.0.3-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/python-werkzeug-help-2.0.3-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-werkzeug" release="6.u5" version="2.0.3">
					<filename>python3-werkzeug-2.0.3-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/python3-werkzeug-2.0.3-6.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2254</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49178&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49178" id="CVE-2025-49178" title="CVE-2025-49178" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49175&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49175" id="CVE-2025-49175" title="CVE-2025-49175" type="cve"></reference>
		</references>
		<description>CVE-2025-49178:A flaw was found in the X server&#39;s request handling. Non-zero &#39;bytes to ignore&#39; in a client&#39;s request can cause the server to skip processing another client&#39;s request, potentially leading to a denial of service.&#xA;CVE-2025-49175:A flaw was found in the X Rendering extension&#39;s handling of animated cursors. If a client provides no cursors, the server assumes at least one is present, leading to an out-of-bounds read and potential crash.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-38.u23.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-source-1.20.11-38.u23.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-38.u23.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-help-1.20.11-38.u23.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-Xvfb-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-Xdmx-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-Xnest-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-devel-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-Xephyr-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-38.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/xorg-x11-server-common-1.20.11-38.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-Xdmx-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-Xnest-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-common-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-devel-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-Xephyr-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-Xvfb-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="38.u23" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-38.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/xorg-x11-server-1.20.11-38.u23.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2255</id>
		<title>An update for rubygem-webrick is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6442&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6442" id="CVE-2025-6442" title="CVE-2025-6442" type="cve"></reference>
		</references>
		<description>CVE-2025-6442:Ruby WEBrick read_header HTTP Request Smuggling Vulnerability. This vulnerability allows remote attackers to smuggle arbitrary HTTP requests on affected installations of Ruby WEBrick. This issue is exploitable when the product is deployed behind an HTTP proxy that fulfills specific conditions.&#xA;&#xA;The specific flaw exists within the read_headers method. The issue results from the inconsistent parsing of terminators of HTTP headers. An attacker can leverage this vulnerability to smuggle arbitrary HTTP requests. Was ZDI-CAN-21876.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="noarch" epoch="0" name="rubygem-webrick" release="3.u2" version="1.7.0">
					<filename>rubygem-webrick-1.7.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/rubygem-webrick-1.7.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-webrick-help" release="3.u2" version="1.7.0">
					<filename>rubygem-webrick-help-1.7.0-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/rubygem-webrick-help-1.7.0-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2256</id>
		<title>An update for djvulibre is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53367&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53367" id="CVE-2025-53367" title="CVE-2025-53367" type="cve"></reference>
		</references>
		<description>CVE-2025-53367:DjVuLibre is a GPL implementation of DjVu, a web-centric format for distributing documents and images. Prior to version 3.5.29, the MMRDecoder::scanruns method is affected by an OOB-write vulnerability, because it does not check that the xr pointer stays within the bounds of the allocated buffer. This can lead to writes beyond the allocated memory, resulting in a heap corruption condition. An out-of-bounds read with pr is also possible for the same reason. This issue has been patched in version 3.5.29.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="djvulibre-help" release="20.u2" version="3.5.27">
					<filename>djvulibre-help-3.5.27-20.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/djvulibre-help-3.5.27-20.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="djvulibre" release="20.u2" version="3.5.27">
					<filename>djvulibre-3.5.27-20.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/djvulibre-3.5.27-20.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="djvulibre-devel" release="20.u2" version="3.5.27">
					<filename>djvulibre-devel-3.5.27-20.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/djvulibre-devel-3.5.27-20.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="djvulibre" release="20.u2" version="3.5.27">
					<filename>djvulibre-3.5.27-20.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/djvulibre-3.5.27-20.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="djvulibre-devel" release="20.u2" version="3.5.27">
					<filename>djvulibre-devel-3.5.27-20.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/djvulibre-devel-3.5.27-20.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="djvulibre-help" release="20.u2" version="3.5.27">
					<filename>djvulibre-help-3.5.27-20.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/djvulibre-help-3.5.27-20.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2257</id>
		<title>An update for qt5-qtsvg is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32573&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32573" id="CVE-2023-32573" title="CVE-2023-32573" type="cve"></reference>
		</references>
		<description>CVE-2023-32573:In Qt before 5.15.14, 6.0.x through 6.2.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1, QtSvg QSvgFont m_unitsPerEm initialization is mishandled.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="0" name="qt5-qtsvg" release="1.u1" version="5.15.2">
					<filename>qt5-qtsvg-5.15.2-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/qt5-qtsvg-5.15.2-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtsvg-devel" release="1.u1" version="5.15.2">
					<filename>qt5-qtsvg-devel-5.15.2-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/qt5-qtsvg-devel-5.15.2-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtsvg" release="1.u1" version="5.15.2">
					<filename>qt5-qtsvg-5.15.2-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/qt5-qtsvg-5.15.2-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtsvg-devel" release="1.u1" version="5.15.2">
					<filename>qt5-qtsvg-devel-5.15.2-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/qt5-qtsvg-devel-5.15.2-1.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2258</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42364&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-42364" id="CVE-2023-42364" title="CVE-2023-42364" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42365&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-42365" id="CVE-2023-42365" title="CVE-2023-42365" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39810&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-39810" id="CVE-2023-39810" title="CVE-2023-39810" type="cve"></reference>
		</references>
		<description>CVE-2023-42364:A use-after-free vulnerability in BusyBox v.1.36.1 allows attackers to cause a denial of service via a crafted awk pattern in the awk.c evaluate function.&#xA;CVE-2023-42365:A use-after-free vulnerability was discovered in BusyBox v.1.36.1 via a crafted awk pattern in the awk.c copyvar function.&#xA;CVE-2023-39810:An issue in the CPIO command of Busybox v1.33.2 allows attackers to execute a directory traversal.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="aarch64" epoch="1" name="busybox-help" release="24.u4" version="1.34.1">
					<filename>busybox-help-1.34.1-24.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/busybox-help-1.34.1-24.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox" release="24.u4" version="1.34.1">
					<filename>busybox-1.34.1-24.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/busybox-1.34.1-24.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-petitboot" release="24.u4" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-24.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/busybox-petitboot-1.34.1-24.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox" release="24.u4" version="1.34.1">
					<filename>busybox-1.34.1-24.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/busybox-1.34.1-24.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-help" release="24.u4" version="1.34.1">
					<filename>busybox-help-1.34.1-24.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/busybox-help-1.34.1-24.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-petitboot" release="24.u4" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-24.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/busybox-petitboot-1.34.1-24.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2259</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55004" id="CVE-2025-55004" title="CVE-2025-55004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55005" id="CVE-2025-55005" title="CVE-2025-55005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55154&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55154" id="CVE-2025-55154" title="CVE-2025-55154" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55160" id="CVE-2025-55160" title="CVE-2025-55160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53014" id="CVE-2025-53014" title="CVE-2025-53014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53015" id="CVE-2025-53015" title="CVE-2025-53015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53019&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53019" id="CVE-2025-53019" title="CVE-2025-53019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53101&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53101" id="CVE-2025-53101" title="CVE-2025-53101" type="cve"></reference>
		</references>
		<description>CVE-2025-55004:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-1, ImageMagick is vulnerable to heap-buffer overflow read around the handling of images with separate alpha channels when performing image magnification in ReadOneMNGIMage. This can likely be used to leak subsequent memory contents into the output image. This issue has been patched in version 7.1.2-1.&#xA;CVE-2025-55005:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-1, when preparing to transform from Log to sRGB colorspaces, the logmap construction fails to handle cases where the reference-black or reference-white value is larger than 1024. This leads to corrupting memory beyond the end of the allocated logmap buffer. This issue has been patched in version 7.1.2-1.&#xA;CVE-2025-55154:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-27 and 7.1.2-1, the magnified size calculations in ReadOneMNGIMage (in coders/png.c) are unsafe and can overflow, leading to memory corruption. This issue has been patched in versions 6.9.13-27 and 7.1.2-1.&#xA;CVE-2025-55160:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-27 and 7.1.2-1, there is undefined behavior (function-type-mismatch) in splay tree cloning callback. This results in a deterministic abort under UBSan (DoS in sanitizer builds), with no crash in a non-sanitized build. This issue has been patched in versions 6.9.13-27 and 7.1.2-1.&#xA;CVE-2025-53014:ImageMagick is free and open-source software used for editing and manipulating digital images. Versions prior to 7.1.2-0 and 6.9.13-26 have a heap buffer overflow in the `InterpretImageFilename` function. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (`%%`). Versions 7.1.2-0 and 6.9.13-26 fix the issue.&#xA;CVE-2025-53015:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions prior to 7.1.2-0, infinite lines occur when writing during a specific XMP file conversion command. Version 7.1.2-0 fixes the issue.&#xA;CVE-2025-53019:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions prior to 7.1.2-0 and 6.9.13-26, in ImageMagick&#39;s `magick stream` command, specifying multiple consecutive `%d` format specifiers in a filename template causes a memory leak. Versions 7.1.2-0 and 6.9.13-26 fix the issue.&#xA;CVE-2025-53101:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions prior to 7.1.2-0 and 6.9.13-26, in ImageMagick&#39;s `magick mogrify` command, specifying multiple consecutive `%d` format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through `vsnprintf()`. Versions 7.1.2-0 and 6.9.13-26 fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-8.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ImageMagick-devel-7.1.1.8-8.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-8.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ImageMagick-perl-7.1.1.8-8.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-8.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ImageMagick-c++-devel-7.1.1.8-8.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-8.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ImageMagick-7.1.1.8-8.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-help" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-8.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ImageMagick-help-7.1.1.8-8.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-8.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/ImageMagick-c++-7.1.1.8-8.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-7.1.1.8-8.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ImageMagick-7.1.1.8-8.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-c++-7.1.1.8-8.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ImageMagick-c++-7.1.1.8-8.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-c++-devel-7.1.1.8-8.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ImageMagick-c++-devel-7.1.1.8-8.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-devel-7.1.1.8-8.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ImageMagick-devel-7.1.1.8-8.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-perl-7.1.1.8-8.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ImageMagick-perl-7.1.1.8-8.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-help" release="8.u10" version="7.1.1.8">
					<filename>ImageMagick-help-7.1.1.8-8.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/ImageMagick-help-7.1.1.8-8.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2260</id>
		<title>An update for freetype is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-08-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-31782" id="CVE-2022-31782" title="CVE-2022-31782" type="cve"></reference>
		</references>
		<description>CVE-2022-31782:ftbench.c in FreeType Demo Programs through 2.12.1 has a heap-based buffer overflow.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.1.3</name>
				<package arch="x86_64" epoch="0" name="freetype-demos" release="6.u5" version="2.12.1">
					<filename>freetype-demos-2.12.1-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/freetype-demos-2.12.1-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freetype-devel" release="6.u5" version="2.12.1">
					<filename>freetype-devel-2.12.1-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/freetype-devel-2.12.1-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="freetype" release="6.u5" version="2.12.1">
					<filename>freetype-2.12.1-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/freetype-2.12.1-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="freetype-help" release="6.u5" version="2.12.1">
					<filename>freetype-help-2.12.1-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.1.3/freetype-help-2.12.1-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype" release="6.u5" version="2.12.1">
					<filename>freetype-2.12.1-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/freetype-2.12.1-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype-devel" release="6.u5" version="2.12.1">
					<filename>freetype-devel-2.12.1-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/freetype-devel-2.12.1-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="freetype-demos" release="6.u5" version="2.12.1">
					<filename>freetype-demos-2.12.1-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.1.3/freetype-demos-2.12.1-6.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2261</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8713&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8713" id="CVE-2025-8713" title="CVE-2025-8713" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8714&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8714" id="CVE-2025-8714" title="CVE-2025-8714" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8715&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8715" id="CVE-2025-8715" title="CVE-2025-8715" type="cve"></reference>
		</references>
		<description>CVE-2025-8713:PostgreSQL optimizer statistics allow a user to read sampled data within a view that the user cannot access.  Separately, statistics allow a user to read sampled data that a row security policy intended to hide.  PostgreSQL maintains statistics for tables by sampling data available in columns; this data is consulted during the query planning process.  Prior to this release, a user could craft a leaky operator that bypassed view access control lists (ACLs) and bypassed row security policies in partitioning or table inheritance hierarchies.  Reachable statistics data notably included histograms and most-common-values lists.  CVE-2017-7484 and CVE-2019-10130 intended to close this class of vulnerability, but this gap remained.  Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.&#xA;CVE-2025-8714:Untrusted data inclusion in pg_dump in PostgreSQL allows a malicious superuser of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands.  pg_dumpall is also affected.  pg_restore is affected when used to generate a plain-format dump.  This is similar to MySQL CVE-2024-21096.  Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.&#xA;CVE-2025-8715:Improper neutralization of newlines in pg_dump in PostgreSQL allows a user of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands inside a purpose-crafted object name.  The same attacks can achieve SQL injection as a superuser of the restore target server.  pg_dumpall, pg_restore, and pg_upgrade are also affected.  Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.  Versions before 11.20 are unaffected.  CVE-2012-0868 had fixed this class of problem, but version 11.20 reintroduced it.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u4" version="13.22">
					<filename>postgresql-llvmjit-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-llvmjit-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u4" version="13.22">
					<filename>postgresql-plpython3-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-plpython3-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u4" version="13.22">
					<filename>postgresql-private-libs-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-private-libs-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u4" version="13.22">
					<filename>postgresql-test-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-test-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u4" version="13.22">
					<filename>postgresql-server-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-server-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u4" version="13.22">
					<filename>postgresql-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u4" version="13.22">
					<filename>postgresql-static-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-static-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u4" version="13.22">
					<filename>postgresql-docs-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-docs-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u4" version="13.22">
					<filename>postgresql-plperl-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-plperl-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u4" version="13.22">
					<filename>postgresql-pltcl-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-pltcl-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u4" version="13.22">
					<filename>postgresql-private-devel-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-private-devel-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u4" version="13.22">
					<filename>postgresql-contrib-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-contrib-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u4" version="13.22">
					<filename>postgresql-server-devel-13.22-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-server-devel-13.22-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u4" version="13.22">
					<filename>postgresql-contrib-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-contrib-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u4" version="13.22">
					<filename>postgresql-plperl-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-plperl-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u4" version="13.22">
					<filename>postgresql-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u4" version="13.22">
					<filename>postgresql-server-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-server-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u4" version="13.22">
					<filename>postgresql-server-devel-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-server-devel-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u4" version="13.22">
					<filename>postgresql-private-libs-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-private-libs-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u4" version="13.22">
					<filename>postgresql-docs-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-docs-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u4" version="13.22">
					<filename>postgresql-llvmjit-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-llvmjit-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u4" version="13.22">
					<filename>postgresql-pltcl-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-pltcl-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u4" version="13.22">
					<filename>postgresql-static-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-static-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u4" version="13.22">
					<filename>postgresql-test-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-test-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u4" version="13.22">
					<filename>postgresql-plpython3-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-plpython3-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u4" version="13.22">
					<filename>postgresql-private-devel-13.22-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/postgresql-private-devel-13.22-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u4" version="13.22">
					<filename>postgresql-test-rpm-macros-13.22-1.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/postgresql-test-rpm-macros-13.22-1.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2262</id>
		<title>An update for systemd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4598&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4598" id="CVE-2025-4598" title="CVE-2025-4598" type="cve"></reference>
		</references>
		<description>CVE-2025-4598:A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original&#39;s privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process.&#xA;&#xA;A SUID binary or process has a special type of permission, which allows the process to run with the file owner&#39;s permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original&#39;s SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="aarch64" epoch="0" name="systemd-libs" release="76.u20" version="249">
					<filename>systemd-libs-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-libs-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-nspawn" release="76.u20" version="249">
					<filename>systemd-nspawn-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-nspawn-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-container" release="76.u20" version="249">
					<filename>systemd-container-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-container-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-networkd" release="76.u20" version="249">
					<filename>systemd-networkd-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-networkd-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-pam" release="76.u20" version="249">
					<filename>systemd-pam-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-pam-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-timesyncd" release="76.u20" version="249">
					<filename>systemd-timesyncd-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-timesyncd-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-udev" release="76.u20" version="249">
					<filename>systemd-udev-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-udev-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-resolved" release="76.u20" version="249">
					<filename>systemd-resolved-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-resolved-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-devel" release="76.u20" version="249">
					<filename>systemd-devel-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-devel-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="76.u20" version="249">
					<filename>systemd-249-76.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/systemd-249-76.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-container" release="76.u20" version="249">
					<filename>systemd-container-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-container-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-resolved" release="76.u20" version="249">
					<filename>systemd-resolved-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-resolved-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd" release="76.u20" version="249">
					<filename>systemd-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-devel" release="76.u20" version="249">
					<filename>systemd-devel-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-devel-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-networkd" release="76.u20" version="249">
					<filename>systemd-networkd-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-networkd-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-pam" release="76.u20" version="249">
					<filename>systemd-pam-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-pam-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-nspawn" release="76.u20" version="249">
					<filename>systemd-nspawn-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-nspawn-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-udev" release="76.u20" version="249">
					<filename>systemd-udev-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-udev-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-libs" release="76.u20" version="249">
					<filename>systemd-libs-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-libs-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-timesyncd" release="76.u20" version="249">
					<filename>systemd-timesyncd-249-76.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-timesyncd-249-76.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="systemd-help" release="76.u20" version="249">
					<filename>systemd-help-249-76.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/systemd-help-249-76.u20.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2263</id>
		<title>An update for dav1d is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1580&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1580" id="CVE-2024-1580" title="CVE-2024-1580" type="cve"></reference>
		</references>
		<description>CVE-2024-1580:An integer overflow in dav1d AV1 decoder that can occur when decoding videos with large frame size. This can lead to memory corruption within the AV1 decoder. We recommend upgrading past version 1.4.0 of dav1d.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="libdav1d" release="4.u1" version="0.5.2">
					<filename>libdav1d-0.5.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libdav1d-0.5.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="dav1d" release="4.u1" version="0.5.2">
					<filename>dav1d-0.5.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/dav1d-0.5.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libdav1d-devel" release="4.u1" version="0.5.2">
					<filename>libdav1d-devel-0.5.2-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libdav1d-devel-0.5.2-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dav1d" release="4.u1" version="0.5.2">
					<filename>dav1d-0.5.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/dav1d-0.5.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libdav1d" release="4.u1" version="0.5.2">
					<filename>libdav1d-0.5.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libdav1d-0.5.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libdav1d-devel" release="4.u1" version="0.5.2">
					<filename>libdav1d-devel-0.5.2-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libdav1d-devel-0.5.2-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2264</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49535&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49535" id="CVE-2022-49535" title="CVE-2022-49535" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58095&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58095" id="CVE-2024-58095" title="CVE-2024-58095" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50098&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50098" id="CVE-2022-50098" title="CVE-2022-50098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38015" id="CVE-2025-38015" title="CVE-2025-38015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38035" id="CVE-2025-38035" title="CVE-2025-38035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38245&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38245" id="CVE-2025-38245" title="CVE-2025-38245" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38324&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38324" id="CVE-2025-38324" title="CVE-2025-38324" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38391&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38391" id="CVE-2025-38391" title="CVE-2025-38391" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38424&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38424" id="CVE-2025-38424" title="CVE-2025-38424" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38466&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38466" id="CVE-2025-38466" title="CVE-2025-38466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49961&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49961" id="CVE-2022-49961" title="CVE-2022-49961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38079&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38079" id="CVE-2025-38079" title="CVE-2025-38079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38074&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38074" id="CVE-2025-38074" title="CVE-2025-38074" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38117&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38117" id="CVE-2025-38117" title="CVE-2025-38117" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38157" id="CVE-2025-38157" title="CVE-2025-38157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38298&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38298" id="CVE-2025-38298" title="CVE-2025-38298" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38337&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38337" id="CVE-2025-38337" title="CVE-2025-38337" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58002&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58002" id="CVE-2024-58002" title="CVE-2024-58002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21855&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21855" id="CVE-2025-21855" title="CVE-2025-21855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50224&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50224" id="CVE-2022-50224" title="CVE-2022-50224" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38108&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38108" id="CVE-2025-38108" title="CVE-2025-38108" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38229&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38229" id="CVE-2025-38229" title="CVE-2025-38229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38320&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38320" id="CVE-2025-38320" title="CVE-2025-38320" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37968&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37968" id="CVE-2025-37968" title="CVE-2025-37968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57931&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57931" id="CVE-2024-57931" title="CVE-2024-57931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38072&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38072" id="CVE-2025-38072" title="CVE-2025-38072" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38023&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38023" id="CVE-2025-38023" title="CVE-2025-38023" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38146&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38146" id="CVE-2025-38146" title="CVE-2025-38146" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38170&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38170" id="CVE-2025-38170" title="CVE-2025-38170" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38095&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38095" id="CVE-2025-38095" title="CVE-2025-38095" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26798" id="CVE-2024-26798" title="CVE-2024-26798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21927&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21927" id="CVE-2025-21927" title="CVE-2025-21927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22026&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22026" id="CVE-2025-22026" title="CVE-2025-22026" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50057&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50057" id="CVE-2022-50057" title="CVE-2022-50057" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50230&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50230" id="CVE-2022-50230" title="CVE-2022-50230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50167&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50167" id="CVE-2022-50167" title="CVE-2022-50167" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38078&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38078" id="CVE-2025-38078" title="CVE-2025-38078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38346&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38346" id="CVE-2025-38346" title="CVE-2025-38346" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37738&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37738" id="CVE-2025-37738" title="CVE-2025-37738" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37937&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37937" id="CVE-2025-37937" title="CVE-2025-37937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21704&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21704" id="CVE-2025-21704" title="CVE-2025-21704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58083" id="CVE-2024-58083" title="CVE-2024-58083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53039&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53039" id="CVE-2023-53039" title="CVE-2023-53039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21546&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-21546" id="CVE-2022-21546" title="CVE-2022-21546" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23156&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23156" id="CVE-2025-23156" title="CVE-2025-23156" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23148&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23148" id="CVE-2025-23148" title="CVE-2025-23148" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53082&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53082" id="CVE-2023-53082" title="CVE-2023-53082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37923&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37923" id="CVE-2025-37923" title="CVE-2025-37923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37995&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37995" id="CVE-2025-37995" title="CVE-2025-37995" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38212" id="CVE-2025-38212" title="CVE-2025-38212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49647&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49647" id="CVE-2022-49647" title="CVE-2022-49647" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37858" id="CVE-2025-37858" title="CVE-2025-37858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38031&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38031" id="CVE-2025-38031" title="CVE-2025-38031" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3238&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-3238" id="CVE-2022-3238" title="CVE-2022-3238" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57876&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57876" id="CVE-2024-57876" title="CVE-2024-57876" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58097&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58097" id="CVE-2024-58097" title="CVE-2024-58097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37925&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37925" id="CVE-2025-37925" title="CVE-2025-37925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37773&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37773" id="CVE-2025-37773" title="CVE-2025-37773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37782" id="CVE-2025-37782" title="CVE-2025-37782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37940&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37940" id="CVE-2025-37940" title="CVE-2025-37940" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21999&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21999" id="CVE-2025-21999" title="CVE-2025-21999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23144&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23144" id="CVE-2025-23144" title="CVE-2025-23144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53093&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53093" id="CVE-2023-53093" title="CVE-2023-53093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21760&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21760" id="CVE-2025-21760" title="CVE-2025-21760" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21763&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21763" id="CVE-2025-21763" title="CVE-2025-21763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21761&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21761" id="CVE-2025-21761" title="CVE-2025-21761" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21764&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21764" id="CVE-2025-21764" title="CVE-2025-21764" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21762&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21762" id="CVE-2025-21762" title="CVE-2025-21762" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58094&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58094" id="CVE-2024-58094" title="CVE-2024-58094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21780&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21780" id="CVE-2025-21780" title="CVE-2025-21780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21877&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21877" id="CVE-2025-21877" title="CVE-2025-21877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53010&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53010" id="CVE-2023-53010" title="CVE-2023-53010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21898&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21898" id="CVE-2025-21898" title="CVE-2025-21898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21935" id="CVE-2025-21935" title="CVE-2025-21935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21993&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21993" id="CVE-2025-21993" title="CVE-2025-21993" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37980&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37980" id="CVE-2025-37980" title="CVE-2025-37980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49246&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49246" id="CVE-2022-49246" title="CVE-2022-49246" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49328&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49328" id="CVE-2022-49328" title="CVE-2022-49328" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57980&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57980" id="CVE-2024-57980" title="CVE-2024-57980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21858" id="CVE-2025-21858" title="CVE-2025-21858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21928&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21928" id="CVE-2025-21928" title="CVE-2025-21928" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56664&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56664" id="CVE-2024-56664" title="CVE-2024-56664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56642&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56642" id="CVE-2024-56642" title="CVE-2024-56642" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57951&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57951" id="CVE-2024-57951" title="CVE-2024-57951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49513&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49513" id="CVE-2022-49513" title="CVE-2022-49513" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49443&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49443" id="CVE-2022-49443" title="CVE-2022-49443" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21726&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21726" id="CVE-2025-21726" title="CVE-2025-21726" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21718&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21718" id="CVE-2025-21718" title="CVE-2025-21718" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21715&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21715" id="CVE-2025-21715" title="CVE-2025-21715" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21727" id="CVE-2025-21727" title="CVE-2025-21727" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21781&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21781" id="CVE-2025-21781" title="CVE-2025-21781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21791&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21791" id="CVE-2025-21791" title="CVE-2025-21791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21816&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21816" id="CVE-2025-21816" title="CVE-2025-21816" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21823" id="CVE-2025-21823" title="CVE-2025-21823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21804&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21804" id="CVE-2025-21804" title="CVE-2025-21804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58055&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58055" id="CVE-2024-58055" title="CVE-2024-58055" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21881&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21881" id="CVE-2025-21881" title="CVE-2025-21881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53001&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53001" id="CVE-2023-53001" title="CVE-2023-53001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21943&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21943" id="CVE-2025-21943" title="CVE-2025-21943" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22035" id="CVE-2025-22035" title="CVE-2025-22035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47660&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-47660" id="CVE-2021-47660" title="CVE-2021-47660" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49553&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49553" id="CVE-2022-49553" title="CVE-2022-49553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21722&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21722" id="CVE-2025-21722" title="CVE-2025-21722" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21785&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21785" id="CVE-2025-21785" title="CVE-2025-21785" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21863&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21863" id="CVE-2025-21863" title="CVE-2025-21863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21887&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21887" id="CVE-2025-21887" title="CVE-2025-21887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49711&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49711" id="CVE-2022-49711" title="CVE-2022-49711" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49444&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49444" id="CVE-2022-49444" title="CVE-2022-49444" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-54680&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-54680" id="CVE-2024-54680" title="CVE-2024-54680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57947&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57947" id="CVE-2024-57947" title="CVE-2024-57947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49564&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49564" id="CVE-2022-49564" title="CVE-2022-49564" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49651&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49651" id="CVE-2022-49651" title="CVE-2022-49651" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49096" id="CVE-2022-49096" title="CVE-2022-49096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49266&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49266" id="CVE-2022-49266" title="CVE-2022-49266" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21719&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21719" id="CVE-2025-21719" title="CVE-2025-21719" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21782" id="CVE-2025-21782" title="CVE-2025-21782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58009&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58009" id="CVE-2024-58009" title="CVE-2024-58009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21756&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21756" id="CVE-2025-21756" title="CVE-2025-21756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21779&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21779" id="CVE-2025-21779" title="CVE-2025-21779" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58001&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58001" id="CVE-2024-58001" title="CVE-2024-58001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21735&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21735" id="CVE-2025-21735" title="CVE-2025-21735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21802&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21802" id="CVE-2025-21802" title="CVE-2025-21802" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56606&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56606" id="CVE-2024-56606" title="CVE-2024-56606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58058" id="CVE-2024-58058" title="CVE-2024-58058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50150&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50150" id="CVE-2024-50150" title="CVE-2024-50150" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56650&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56650" id="CVE-2024-56650" title="CVE-2024-56650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56754&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56754" id="CVE-2024-56754" title="CVE-2024-56754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57792&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57792" id="CVE-2024-57792" title="CVE-2024-57792" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57857" id="CVE-2024-57857" title="CVE-2024-57857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57795" id="CVE-2024-57795" title="CVE-2024-57795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57908&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57908" id="CVE-2024-57908" title="CVE-2024-57908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57912" id="CVE-2024-57912" title="CVE-2024-57912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21662&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21662" id="CVE-2025-21662" title="CVE-2025-21662" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46782" id="CVE-2024-46782" title="CVE-2024-46782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47697" id="CVE-2024-47697" title="CVE-2024-47697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50125" id="CVE-2024-50125" title="CVE-2024-50125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50268&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50268" id="CVE-2024-50268" title="CVE-2024-50268" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53057&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53057" id="CVE-2024-53057" title="CVE-2024-53057" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53096" id="CVE-2024-53096" title="CVE-2024-53096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53141&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53141" id="CVE-2024-53141" title="CVE-2024-53141" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53156&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53156" id="CVE-2024-53156" title="CVE-2024-53156" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53148&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53148" id="CVE-2024-53148" title="CVE-2024-53148" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56658&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56658" id="CVE-2024-56658" title="CVE-2024-56658" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56600&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56600" id="CVE-2024-56600" title="CVE-2024-56600" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56601" id="CVE-2024-56601" title="CVE-2024-56601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57900&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57900" id="CVE-2024-57900" title="CVE-2024-57900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21647&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21647" id="CVE-2025-21647" title="CVE-2025-21647" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21648&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21648" id="CVE-2025-21648" title="CVE-2025-21648" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21667&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21667" id="CVE-2025-21667" title="CVE-2025-21667" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53203&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53203" id="CVE-2024-53203" title="CVE-2024-53203" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49569&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49569" id="CVE-2024-49569" title="CVE-2024-49569" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57849&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57849" id="CVE-2024-57849" title="CVE-2024-57849" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57887&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57887" id="CVE-2024-57887" title="CVE-2024-57887" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57893&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57893" id="CVE-2024-57893" title="CVE-2024-57893" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47141&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47141" id="CVE-2024-47141" title="CVE-2024-47141" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57910&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57910" id="CVE-2024-57910" title="CVE-2024-57910" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49571&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49571" id="CVE-2024-49571" title="CVE-2024-49571" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53690&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53690" id="CVE-2024-53690" title="CVE-2024-53690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50051&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50051" id="CVE-2024-50051" title="CVE-2024-50051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21731&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21731" id="CVE-2025-21731" title="CVE-2025-21731" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26954&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26954" id="CVE-2024-26954" title="CVE-2024-26954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26952&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26952" id="CVE-2024-26952" title="CVE-2024-26952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52913&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52913" id="CVE-2023-52913" title="CVE-2023-52913" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50194&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50194" id="CVE-2024-50194" title="CVE-2024-50194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50280&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50280" id="CVE-2024-50280" title="CVE-2024-50280" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56539&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56539" id="CVE-2024-56539" title="CVE-2024-56539" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53183" id="CVE-2024-53183" title="CVE-2024-53183" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53222&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53222" id="CVE-2024-53222" title="CVE-2024-53222" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53198&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53198" id="CVE-2024-53198" title="CVE-2024-53198" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56571&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56571" id="CVE-2024-56571" title="CVE-2024-56571" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56610&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56610" id="CVE-2024-56610" title="CVE-2024-56610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56611" id="CVE-2024-56611" title="CVE-2024-56611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56704&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56704" id="CVE-2024-56704" title="CVE-2024-56704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56715&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56715" id="CVE-2024-56715" title="CVE-2024-56715" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56746&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56746" id="CVE-2024-56746" title="CVE-2024-56746" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57850&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57850" id="CVE-2024-57850" title="CVE-2024-57850" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57896&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57896" id="CVE-2024-57896" title="CVE-2024-57896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57892&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57892" id="CVE-2024-57892" title="CVE-2024-57892" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21815&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21815" id="CVE-2025-21815" title="CVE-2025-21815" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53050" id="CVE-2024-53050" title="CVE-2024-53050" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53131&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53131" id="CVE-2024-53131" title="CVE-2024-53131" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56648&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56648" id="CVE-2024-56648" title="CVE-2024-56648" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56626&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56626" id="CVE-2024-56626" title="CVE-2024-56626" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56728" id="CVE-2024-56728" title="CVE-2024-56728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56758&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56758" id="CVE-2024-56758" title="CVE-2024-56758" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56780&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56780" id="CVE-2024-56780" title="CVE-2024-56780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56777&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56777" id="CVE-2024-56777" title="CVE-2024-56777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53237" id="CVE-2024-53237" title="CVE-2024-53237" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53190&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53190" id="CVE-2024-53190" title="CVE-2024-53190" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56662&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56662" id="CVE-2024-56662" title="CVE-2024-56662" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56633&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56633" id="CVE-2024-56633" title="CVE-2024-56633" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56595&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56595" id="CVE-2024-56595" title="CVE-2024-56595" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56597&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56597" id="CVE-2024-56597" title="CVE-2024-56597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56701&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56701" id="CVE-2024-56701" title="CVE-2024-56701" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56759&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56759" id="CVE-2024-56759" title="CVE-2024-56759" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53146&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53146" id="CVE-2024-53146" title="CVE-2024-53146" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53218&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53218" id="CVE-2024-53218" title="CVE-2024-53218" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53217&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53217" id="CVE-2024-53217" title="CVE-2024-53217" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53173&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53173" id="CVE-2024-53173" title="CVE-2024-53173" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56572&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56572" id="CVE-2024-56572" title="CVE-2024-56572" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56623&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56623" id="CVE-2024-56623" title="CVE-2024-56623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56723" id="CVE-2024-56723" title="CVE-2024-56723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56741&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56741" id="CVE-2024-56741" title="CVE-2024-56741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56705&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56705" id="CVE-2024-56705" title="CVE-2024-56705" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57977&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57977" id="CVE-2024-57977" title="CVE-2024-57977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52480&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52480" id="CVE-2023-52480" title="CVE-2023-52480" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56549&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56549" id="CVE-2024-56549" title="CVE-2024-56549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56588&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56588" id="CVE-2024-56588" title="CVE-2024-56588" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52935" id="CVE-2023-52935" title="CVE-2023-52935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53168" id="CVE-2024-53168" title="CVE-2024-53168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56688&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56688" id="CVE-2024-56688" title="CVE-2024-56688" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53114&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53114" id="CVE-2024-53114" title="CVE-2024-53114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40927&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40927" id="CVE-2024-40927" title="CVE-2024-40927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49991&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49991" id="CVE-2024-49991" title="CVE-2024-49991" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50116&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50116" id="CVE-2024-50116" title="CVE-2024-50116" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50187" id="CVE-2024-50187" title="CVE-2024-50187" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50279&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50279" id="CVE-2024-50279" title="CVE-2024-50279" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50272&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50272" id="CVE-2024-50272" title="CVE-2024-50272" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56690&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56690" id="CVE-2024-56690" title="CVE-2024-56690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43817" id="CVE-2024-43817" title="CVE-2024-43817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50141&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50141" id="CVE-2024-50141" title="CVE-2024-50141" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53226&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53226" id="CVE-2024-53226" title="CVE-2024-53226" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53061&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53061" id="CVE-2023-53061" title="CVE-2023-53061" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52920&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52920" id="CVE-2023-52920" title="CVE-2023-52920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50153&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50153" id="CVE-2024-50153" title="CVE-2024-50153" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50203&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50203" id="CVE-2024-50203" title="CVE-2024-50203" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43853&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43853" id="CVE-2024-43853" title="CVE-2024-43853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49862&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49862" id="CVE-2024-49862" title="CVE-2024-49862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50040&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50040" id="CVE-2024-50040" title="CVE-2024-50040" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50064" id="CVE-2024-50064" title="CVE-2024-50064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49901&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49901" id="CVE-2022-49901" title="CVE-2022-49901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42315&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42315" id="CVE-2024-42315" title="CVE-2024-42315" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45009&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45009" id="CVE-2024-45009" title="CVE-2024-45009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49892&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49892" id="CVE-2024-49892" title="CVE-2024-49892" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50085" id="CVE-2024-50085" title="CVE-2024-50085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50199&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50199" id="CVE-2024-50199" title="CVE-2024-50199" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27397&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27397" id="CVE-2024-27397" title="CVE-2024-27397" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36927&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36927" id="CVE-2024-36927" title="CVE-2024-36927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56686&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56686" id="CVE-2024-56686" title="CVE-2024-56686" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36941&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36941" id="CVE-2024-36941" title="CVE-2024-36941" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21651&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21651" id="CVE-2025-21651" title="CVE-2025-21651" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21650&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21650" id="CVE-2025-21650" title="CVE-2025-21650" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48867&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48867" id="CVE-2022-48867" title="CVE-2022-48867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-44935" id="CVE-2024-44935" title="CVE-2024-44935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42287&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42287" id="CVE-2024-42287" title="CVE-2024-42287" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46833&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46833" id="CVE-2024-46833" title="CVE-2024-46833" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47670&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47670" id="CVE-2024-47670" title="CVE-2024-47670" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53073&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53073" id="CVE-2023-53073" title="CVE-2023-53073" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24857" id="CVE-2024-24857" title="CVE-2024-24857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24858" id="CVE-2024-24858" title="CVE-2024-24858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24859" id="CVE-2024-24859" title="CVE-2024-24859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35785&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35785" id="CVE-2024-35785" title="CVE-2024-35785" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42318&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42318" id="CVE-2024-42318" title="CVE-2024-42318" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42306&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42306" id="CVE-2024-42306" title="CVE-2024-42306" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42302&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42302" id="CVE-2024-42302" title="CVE-2024-42302" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43861&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43861" id="CVE-2024-43861" title="CVE-2024-43861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43872&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43872" id="CVE-2024-43872" title="CVE-2024-43872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41088&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41088" id="CVE-2024-41088" title="CVE-2024-41088" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42070&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42070" id="CVE-2024-42070" title="CVE-2024-42070" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42131&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42131" id="CVE-2024-42131" title="CVE-2024-42131" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42127&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42127" id="CVE-2024-42127" title="CVE-2024-42127" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42232&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42232" id="CVE-2024-42232" title="CVE-2024-42232" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42236&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42236" id="CVE-2024-42236" title="CVE-2024-42236" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42283&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42283" id="CVE-2024-42283" title="CVE-2024-42283" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42310&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42310" id="CVE-2024-42310" title="CVE-2024-42310" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42305&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42305" id="CVE-2024-42305" title="CVE-2024-42305" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43839&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43839" id="CVE-2024-43839" title="CVE-2024-43839" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43840&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43840" id="CVE-2024-43840" title="CVE-2024-43840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43830&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43830" id="CVE-2024-43830" title="CVE-2024-43830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26659&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26659" id="CVE-2024-26659" title="CVE-2024-26659" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26820&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26820" id="CVE-2024-26820" title="CVE-2024-26820" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42158" id="CVE-2024-42158" title="CVE-2024-42158" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26753&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26753" id="CVE-2024-26753" title="CVE-2024-26753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26793&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26793" id="CVE-2024-26793" title="CVE-2024-26793" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26790&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26790" id="CVE-2024-26790" title="CVE-2024-26790" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26781&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26781" id="CVE-2024-26781" title="CVE-2024-26781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35825&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35825" id="CVE-2024-35825" title="CVE-2024-35825" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38594&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38594" id="CVE-2024-38594" title="CVE-2024-38594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41049&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41049" id="CVE-2024-41049" title="CVE-2024-41049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41055&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41055" id="CVE-2024-41055" title="CVE-2024-41055" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41064" id="CVE-2024-41064" title="CVE-2024-41064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41066&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41066" id="CVE-2024-41066" title="CVE-2024-41066" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42082&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42082" id="CVE-2024-42082" title="CVE-2024-42082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42137&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42137" id="CVE-2024-42137" title="CVE-2024-42137" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26748&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26748" id="CVE-2024-26748" title="CVE-2024-26748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26749&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26749" id="CVE-2024-26749" title="CVE-2024-26749" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26747&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26747" id="CVE-2024-26747" title="CVE-2024-26747" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35884&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35884" id="CVE-2024-35884" title="CVE-2024-35884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39476&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39476" id="CVE-2024-39476" title="CVE-2024-39476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41006" id="CVE-2024-41006" title="CVE-2024-41006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41022&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41022" id="CVE-2024-41022" title="CVE-2024-41022" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49959&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49959" id="CVE-2024-49959" title="CVE-2024-49959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26664&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26664" id="CVE-2024-26664" title="CVE-2024-26664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27012&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27012" id="CVE-2024-27012" title="CVE-2024-27012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27065&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27065" id="CVE-2024-27065" title="CVE-2024-27065" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27412&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27412" id="CVE-2024-27412" title="CVE-2024-27412" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33621&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-33621" id="CVE-2024-33621" title="CVE-2024-33621" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40963&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40963" id="CVE-2024-40963" title="CVE-2024-40963" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48816&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48816" id="CVE-2022-48816" title="CVE-2022-48816" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27416&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27416" id="CVE-2024-27416" title="CVE-2024-27416" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39502&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39502" id="CVE-2024-39502" title="CVE-2024-39502" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40934&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-40934" id="CVE-2024-40934" title="CVE-2024-40934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35893&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35893" id="CVE-2024-35893" title="CVE-2024-35893" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38567&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38567" id="CVE-2024-38567" title="CVE-2024-38567" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27052&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27052" id="CVE-2024-27052" title="CVE-2024-27052" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27047&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27047" id="CVE-2024-27047" title="CVE-2024-27047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27405&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27405" id="CVE-2024-27405" title="CVE-2024-27405" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27417&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27417" id="CVE-2024-27417" title="CVE-2024-27417" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38553&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38553" id="CVE-2024-38553" title="CVE-2024-38553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38587&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38587" id="CVE-2024-38587" title="CVE-2024-38587" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39180&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-39180" id="CVE-2023-39180" title="CVE-2023-39180" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38381&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38381" id="CVE-2024-38381" title="CVE-2024-38381" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36020" id="CVE-2024-36020" title="CVE-2024-36020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36959&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36959" id="CVE-2024-36959" title="CVE-2024-36959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36484&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36484" id="CVE-2024-36484" title="CVE-2024-36484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26835&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26835" id="CVE-2024-26835" title="CVE-2024-26835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36903&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-36903" id="CVE-2024-36903" title="CVE-2024-36903" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27408&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27408" id="CVE-2024-27408" title="CVE-2024-27408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35852&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35852" id="CVE-2024-35852" title="CVE-2024-35852" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35962&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35962" id="CVE-2024-35962" title="CVE-2024-35962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38662&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38662" id="CVE-2024-38662" title="CVE-2024-38662" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41002&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-41002" id="CVE-2024-41002" title="CVE-2024-41002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27414&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27414" id="CVE-2024-27414" title="CVE-2024-27414" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35808&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35808" id="CVE-2024-35808" title="CVE-2024-35808" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35900&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35900" id="CVE-2024-35900" title="CVE-2024-35900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52831&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52831" id="CVE-2023-52831" title="CVE-2023-52831" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26886&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26886" id="CVE-2024-26886" title="CVE-2024-26886" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27428&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27428" id="CVE-2024-27428" title="CVE-2024-27428" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52682&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52682" id="CVE-2023-52682" title="CVE-2023-52682" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35897&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35897" id="CVE-2024-35897" title="CVE-2024-35897" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39507&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39507" id="CVE-2024-39507" title="CVE-2024-39507" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4244&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4244" id="CVE-2023-4244" title="CVE-2023-4244" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28746&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-28746" id="CVE-2023-28746" title="CVE-2023-28746" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26920&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26920" id="CVE-2024-26920" title="CVE-2024-26920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27013&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27013" id="CVE-2024-27013" title="CVE-2024-27013" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26957&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26957" id="CVE-2024-26957" title="CVE-2024-26957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27017&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27017" id="CVE-2024-27017" title="CVE-2024-27017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52653&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52653" id="CVE-2023-52653" title="CVE-2023-52653" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27388&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27388" id="CVE-2024-27388" title="CVE-2024-27388" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27045&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27045" id="CVE-2024-27045" title="CVE-2024-27045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27024&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27024" id="CVE-2024-27024" title="CVE-2024-27024" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52691" id="CVE-2023-52691" title="CVE-2023-52691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49135&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49135" id="CVE-2022-49135" title="CVE-2022-49135" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49371&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49371" id="CVE-2022-49371" title="CVE-2022-49371" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26845&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26845" id="CVE-2024-26845" title="CVE-2024-26845" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26846&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26846" id="CVE-2024-26846" title="CVE-2024-26846" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26880&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26880" id="CVE-2024-26880" title="CVE-2024-26880" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26859" id="CVE-2024-26859" title="CVE-2024-26859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26739&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26739" id="CVE-2024-26739" title="CVE-2024-26739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26804&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26804" id="CVE-2024-26804" title="CVE-2024-26804" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52631&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52631" id="CVE-2023-52631" title="CVE-2023-52631" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26687&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26687" id="CVE-2024-26687" title="CVE-2024-26687" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26779&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26779" id="CVE-2024-26779" title="CVE-2024-26779" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26766&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26766" id="CVE-2024-26766" title="CVE-2024-26766" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52514&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52514" id="CVE-2023-52514" title="CVE-2023-52514" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52489&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52489" id="CVE-2023-52489" title="CVE-2023-52489" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52619&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52619" id="CVE-2023-52619" title="CVE-2023-52619" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52586&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52586" id="CVE-2023-52586" title="CVE-2023-52586" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52577&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52577" id="CVE-2023-52577" title="CVE-2023-52577" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52525&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52525" id="CVE-2023-52525" title="CVE-2023-52525" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26581&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26581" id="CVE-2024-26581" title="CVE-2024-26581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26585&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26585" id="CVE-2024-26585" title="CVE-2024-26585" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26601" id="CVE-2024-26601" title="CVE-2024-26601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52482&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52482" id="CVE-2023-52482" title="CVE-2023-52482" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20569&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-20569" id="CVE-2023-20569" title="CVE-2023-20569" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0597&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-0597" id="CVE-2023-0597" title="CVE-2023-0597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-0615" id="CVE-2023-0615" title="CVE-2023-0615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2860&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-2860" id="CVE-2023-2860" title="CVE-2023-2860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0590&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-0590" id="CVE-2023-0590" title="CVE-2023-0590" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4129&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-4129" id="CVE-2022-4129" title="CVE-2022-4129" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45934&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45934" id="CVE-2022-45934" title="CVE-2022-45934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4139&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-4139" id="CVE-2022-4139" title="CVE-2022-4139" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-20566&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-20566" id="CVE-2022-20566" title="CVE-2022-20566" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3643&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-3643" id="CVE-2022-3643" title="CVE-2022-3643" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4378&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-4378" id="CVE-2022-4378" title="CVE-2022-4378" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3114&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-3114" id="CVE-2022-3114" title="CVE-2022-3114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42896&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-42896" id="CVE-2022-42896" title="CVE-2022-42896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42895&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-42895" id="CVE-2022-42895" title="CVE-2022-42895" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39842&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-39842" id="CVE-2022-39842" title="CVE-2022-39842" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49535&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49535" id="CVE-2022-49535" title="CVE-2022-49535" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58095&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58095" id="CVE-2024-58095" title="CVE-2024-58095" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50098&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50098" id="CVE-2022-50098" title="CVE-2022-50098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38015" id="CVE-2025-38015" title="CVE-2025-38015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38035" id="CVE-2025-38035" title="CVE-2025-38035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38245&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38245" id="CVE-2025-38245" title="CVE-2025-38245" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38324&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38324" id="CVE-2025-38324" title="CVE-2025-38324" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38391&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38391" id="CVE-2025-38391" title="CVE-2025-38391" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38424&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38424" id="CVE-2025-38424" title="CVE-2025-38424" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38466&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38466" id="CVE-2025-38466" title="CVE-2025-38466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56616&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56616" id="CVE-2024-56616" title="CVE-2024-56616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57798" id="CVE-2024-57798" title="CVE-2024-57798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21692" id="CVE-2025-21692" title="CVE-2025-21692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21700&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21700" id="CVE-2025-21700" title="CVE-2025-21700" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21702&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21702" id="CVE-2025-21702" title="CVE-2025-21702" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49183" id="CVE-2022-49183" title="CVE-2022-49183" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49420" id="CVE-2022-49420" title="CVE-2022-49420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21891&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21891" id="CVE-2025-21891" title="CVE-2025-21891" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38063&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38063" id="CVE-2025-38063" title="CVE-2025-38063" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38125" id="CVE-2025-38125" title="CVE-2025-38125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38181" id="CVE-2025-38181" title="CVE-2025-38181" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38222&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38222" id="CVE-2025-38222" title="CVE-2025-38222" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38263&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38263" id="CVE-2025-38263" title="CVE-2025-38263" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38332&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38332" id="CVE-2025-38332" title="CVE-2025-38332" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38387&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38387" id="CVE-2025-38387" title="CVE-2025-38387" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38362&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38362" id="CVE-2025-38362" title="CVE-2025-38362" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38371&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38371" id="CVE-2025-38371" title="CVE-2025-38371" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38386&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38386" id="CVE-2025-38386" title="CVE-2025-38386" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38439&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38439" id="CVE-2025-38439" title="CVE-2025-38439" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38459&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38459" id="CVE-2025-38459" title="CVE-2025-38459" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38474&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38474" id="CVE-2025-38474" title="CVE-2025-38474" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21920&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21920" id="CVE-2025-21920" title="CVE-2025-21920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21926&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21926" id="CVE-2025-21926" title="CVE-2025-21926" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22004" id="CVE-2025-22004" title="CVE-2025-22004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23142&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23142" id="CVE-2025-23142" title="CVE-2025-23142" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37823" id="CVE-2025-37823" title="CVE-2025-37823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58237" id="CVE-2024-58237" title="CVE-2024-58237" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38352&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38352" id="CVE-2025-38352" title="CVE-2025-38352" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49623&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49623" id="CVE-2022-49623" title="CVE-2022-49623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58093&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58093" id="CVE-2024-58093" title="CVE-2024-58093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37796&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37796" id="CVE-2025-37796" title="CVE-2025-37796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37798" id="CVE-2025-37798" title="CVE-2025-37798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37915&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37915" id="CVE-2025-37915" title="CVE-2025-37915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37913&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37913" id="CVE-2025-37913" title="CVE-2025-37913" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38180&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38180" id="CVE-2025-38180" title="CVE-2025-38180" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38323&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38323" id="CVE-2025-38323" title="CVE-2025-38323" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38495&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38495" id="CVE-2025-38495" title="CVE-2025-38495" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38529&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38529" id="CVE-2025-38529" title="CVE-2025-38529" type="cve"></reference>
		</references>
		<description>CVE-2022-49535:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI&#xA;&#xA;If lpfc_issue_els_flogi() fails and returns non-zero status, the node&#xA;reference count is decremented to trigger the release of the nodelist&#xA;structure. However, if there is a prior registration or dev-loss-evt work&#xA;pending, the node may be released prematurely.  When dev-loss-evt&#xA;completes, the released node is referenced causing a use-after-free null&#xA;pointer dereference.&#xA;&#xA;Similarly, when processing non-zero ELS PLOGI completion status in&#xA;lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport&#xA;registration before triggering node removal.  If dev-loss-evt work is&#xA;pending, the node may be released prematurely and a subsequent call to&#xA;lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.&#xA;&#xA;Add test for pending dev-loss before decrementing the node reference count&#xA;for FLOGI, PLOGI, PRLI, and ADISC handling.&#xA;CVE-2024-58095:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: add check read-only before txBeginAnon() call&#xA;&#xA;Added a read-only check before calling `txBeginAnon` in `extAlloc`&#xA;and `extRecord`. This prevents modification attempts on a read-only&#xA;mounted filesystem, avoiding potential errors or crashes.&#xA;&#xA;Call trace:&#xA; txBeginAnon+0xac/0x154&#xA; extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78&#xA; jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248&#xA; __block_write_begin_int+0x580/0x166c fs/buffer.c:2128&#xA; __block_write_begin fs/buffer.c:2177 [inline]&#xA; block_write_begin+0x98/0x11c fs/buffer.c:2236&#xA; jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299&#xA;CVE-2022-50098:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts&#xA;&#xA;Ensure SRB is returned during I/O timeout error escalation. If that is not&#xA;possible fail the escalation path.&#xA;&#xA;Following crash stack was seen:&#xA;&#xA;BUG: unable to handle kernel paging request at 0000002f56aa90f8&#xA;IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]&#xA;Call Trace:&#xA; ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]&#xA; ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]&#xA; ? dma_pool_alloc+0x1d6/0x210&#xA; ? mempool_alloc+0x54/0x130&#xA; ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]&#xA; ? qla_do_work+0x2d/0x40 [qla2xxx]&#xA; ? process_one_work+0x14c/0x390&#xA;CVE-2025-38015:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: idxd: fix memory leak in error handling path of idxd_alloc&#xA;&#xA;Memory allocated for idxd is not freed if an error occurs during&#xA;idxd_alloc(). To fix it, free the allocated memory in the reverse order&#xA;of allocation before exiting the function in case of an error.&#xA;CVE-2025-38035:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvmet-tcp: don&#39;t restore null sk_state_change&#xA;&#xA;queue-&gt;state_change is set as part of nvmet_tcp_set_queue_sock(), but if&#xA;the TCP connection isn&#39;t established when nvmet_tcp_set_queue_sock() is&#xA;called then queue-&gt;state_change isn&#39;t set and sock-&gt;sk-&gt;sk_state_change&#xA;isn&#39;t replaced.&#xA;&#xA;As such we don&#39;t need to restore sock-&gt;sk-&gt;sk_state_change if&#xA;queue-&gt;state_change is NULL.&#xA;&#xA;This avoids NULL pointer dereferences such as this:&#xA;&#xA;[  286.462026][    C0] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[  286.462814][    C0] #PF: supervisor instruction fetch in kernel mode&#xA;[  286.463796][    C0] #PF: error_code(0x0010) - not-present page&#xA;[  286.464392][    C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0&#xA;[  286.465086][    C0] Oops: Oops: 0010 [#1] SMP KASAN PTI&#xA;[  286.465559][    C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)&#xA;[  286.466393][    C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014&#xA;[  286.467147][    C0] RIP: 0010:0x0&#xA;[  286.467420][    C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.&#xA;[  286.467977][    C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246&#xA;[  286.468425][    C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43&#xA;[  286.469019][    C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100&#xA;[  286.469545][    C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c&#xA;[  286.470072][    C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3&#xA;[  286.470585][    C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268&#xA;[  286.471070][    C0] FS:  00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000&#xA;[  286.471644][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  286.472543][    C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0&#xA;[  286.473500][    C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  286.474467][    C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400&#xA;[  286.475453][    C0] Call Trace:&#xA;[  286.476102][    C0]  &lt;IRQ&gt;&#xA;[  286.476719][    C0]  tcp_fin+0x2bb/0x440&#xA;[  286.477429][    C0]  tcp_data_queue+0x190f/0x4e60&#xA;[  286.478174][    C0]  ? __build_skb_around+0x234/0x330&#xA;[  286.478940][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.479659][    C0]  ? __pfx_tcp_data_queue+0x10/0x10&#xA;[  286.480431][    C0]  ? tcp_try_undo_loss+0x640/0x6c0&#xA;[  286.481196][    C0]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90&#xA;[  286.482046][    C0]  ? kvm_clock_get_cycles+0x14/0x30&#xA;[  286.482769][    C0]  ? ktime_get+0x66/0x150&#xA;[  286.483433][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.484146][    C0]  tcp_rcv_established+0x6e4/0x2050&#xA;[  286.484857][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.485523][    C0]  ? ipv4_dst_check+0x160/0x2b0&#xA;[  286.486203][    C0]  ? __pfx_tcp_rcv_established+0x10/0x10&#xA;[  286.486917][    C0]  ? lock_release+0x217/0x2c0&#xA;[  286.487595][    C0]  tcp_v4_do_rcv+0x4d6/0x9b0&#xA;[  286.488279][    C0]  tcp_v4_rcv+0x2af8/0x3e30&#xA;[  286.488904][    C0]  ? raw_local_deliver+0x51b/0xad0&#xA;[  286.489551][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.490198][    C0]  ? __pfx_tcp_v4_rcv+0x10/0x10&#xA;[  286.490813][    C0]  ? __pfx_raw_local_deliver+0x10/0x10&#xA;[  286.491487][    C0]  ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]&#xA;[  286.492275][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.492900][    C0]  ip_protocol_deliver_rcu+0x8f/0x370&#xA;[  286.493579][    C0]  ip_local_deliver_finish+0x297/0x420&#xA;[  286.494268][    C0]  ip_local_deliver+0x168/0x430&#xA;[  286.494867][    C0]  ? __pfx_ip_local_deliver+0x10/0x10&#xA;[  286.495498][    C0]  ? __pfx_ip_local_deliver_finish+0x10/0x10&#xA;[  286.496204][    C0]  ? ip_rcv_finish_core+0x19a/0x1f20&#xA;[  286.496806][    C0]  ? lock_release+0x217/0x2c0&#xA;[  286.497414][    C0]  ip_rcv+0x455/0x6e0&#xA;[  286.497945][    C0]  ? __pfx_ip_rcv+0x10/0x10&#xA;[ &#xA;---truncated---&#xA;CVE-2025-38245:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().&#xA;&#xA;syzbot reported a warning below during atm_dev_register(). [0]&#xA;&#xA;Before creating a new device and procfs/sysfs for it, atm_dev_register()&#xA;looks up a duplicated device by __atm_dev_lookup().  These operations are&#xA;done under atm_dev_mutex.&#xA;&#xA;However, when removing a device in atm_dev_deregister(), it releases the&#xA;mutex just after removing the device from the list that __atm_dev_lookup()&#xA;iterates over.&#xA;&#xA;So, there will be a small race window where the device does not exist on&#xA;the device list but procfs/sysfs are still not removed, triggering the&#xA;splat.&#xA;&#xA;Let&#39;s hold the mutex until procfs/sysfs are removed in&#xA;atm_dev_deregister().&#xA;&#xA;[0]:&#xA;proc_dir_entry &#39;atm/atmtcp:0&#39; already registered&#xA;WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377&#xA;Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 &lt;0f&gt; 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48&#xA;RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248&#xA;RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001&#xA;RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140&#xA;R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444&#xA;FS:  00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; proc_create_data+0xbe/0x110 fs/proc/generic.c:585&#xA; atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361&#xA; atm_dev_register+0x46d/0x890 net/atm/resources.c:113&#xA; atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369&#xA; atmtcp_attach drivers/atm/atmtcp.c:403 [inline]&#xA; atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464&#xA; do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159&#xA; sock_do_ioctl+0x115/0x280 net/socket.c:1190&#xA; sock_ioctl+0x227/0x6b0 net/socket.c:1311&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:893 [inline]&#xA; __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f38b3b74459&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459&#xA;RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005&#xA;RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f&#xA;R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac&#xA;R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b&#xA; &lt;/TASK&gt;&#xA;CVE-2025-38324:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().&#xA;&#xA;As syzbot reported [0], mpls_route_input_rcu() can be called&#xA;from mpls_getroute(), where is under RTNL.&#xA;&#xA;net-&gt;mpls.platform_label is only updated under RTNL.&#xA;&#xA;Let&#39;s use rcu_dereference_rtnl() in mpls_route_input_rcu() to&#xA;silence the splat.&#xA;&#xA;[0]:&#xA;WARNING: suspicious RCU usage&#xA;6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted&#xA; ----------------------------&#xA;net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!&#xA;&#xA;other info that might help us debug this:&#xA;&#xA;rcu_scheduler_active = 2, debug_locks = 1&#xA;1 lock held by syz.2.4451/17730:&#xA; #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]&#xA; #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961&#xA;&#xA;stack backtrace:&#xA;CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120&#xA; lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865&#xA; mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84&#xA; mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381&#xA; rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964&#xA; netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]&#xA; netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339&#xA; netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg net/socket.c:727 [inline]&#xA; ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566&#xA; ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620&#xA; __sys_sendmmsg+0x200/0x420 net/socket.c:2709&#xA; __do_sys_sendmmsg net/socket.c:2736 [inline]&#xA; __se_sys_sendmmsg net/socket.c:2733 [inline]&#xA; __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f0a2818e969&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133&#xA;RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969&#xA;RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003&#xA;RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268&#xA; &lt;/TASK&gt;&#xA;CVE-2025-38391:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: altmodes/displayport: do not index invalid pin_assignments&#xA;&#xA;A poorly implemented DisplayPort Alt Mode port partner can indicate&#xA;that its pin assignment capabilities are greater than the maximum&#xA;value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show&#xA;will cause a BRK exception due to an out of bounds array access.&#xA;&#xA;Prevent for loop in pin_assignment_show from accessing&#xA;invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX&#xA;value in typec_dp.h and using i &lt; DP_PIN_ASSIGN_MAX as a loop&#xA;condition.&#xA;CVE-2025-38424:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf: Fix sample vs do_exit()&#xA;&#xA;Baisheng Gao reported an ARM64 crash, which Mark decoded as being a&#xA;synchronous external abort -- most likely due to trying to access&#xA;MMIO in bad ways.&#xA;&#xA;The crash further shows perf trying to do a user stack sample while in&#xA;exit_mmap()&#39;s tlb_finish_mmu() -- i.e. while tearing down the address&#xA;space it is trying to access.&#xA;&#xA;It turns out that we stop perf after we tear down the userspace mm; a&#xA;receipie for disaster, since perf likes to access userspace for&#xA;various reasons.&#xA;&#xA;Flip this order by moving up where we stop perf in do_exit().&#xA;&#xA;Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER&#xA;to abort when the current task does not have an mm (exit_mm() makes&#xA;sure to set current-&gt;mm = NULL; before commencing with the actual&#xA;teardown). Such that CPU wide events don&#39;t trip on this same problem.&#xA;CVE-2025-38466:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf: Revert to requiring CAP_SYS_ADMIN for uprobes&#xA;&#xA;Jann reports that uprobes can be used destructively when used in the&#xA;middle of an instruction. The kernel only verifies there is a valid&#xA;instruction at the requested offset, but due to variable instruction&#xA;length cannot determine if this is an instruction as seen by the&#xA;intended execution stream.&#xA;&#xA;Additionally, Mark Rutland notes that on architectures that mix data&#xA;in the text segment (like arm64), a similar things can be done if the&#xA;data word is &#39;mistaken&#39; for an instruction.&#xA;&#xA;As such, require CAP_SYS_ADMIN for uprobes.&#xA;CVE-2022-49961:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&#xA;&#xA;Precision markers need to be propagated whenever we have an ARG_CONST_*&#xA;style argument, as the verifier cannot consider imprecise scalars to be&#xA;equivalent for the purposes of states_equal check when such arguments&#xA;refine the return value (in this case, set mem_size for PTR_TO_MEM). The&#xA;resultant mem_size for the R0 is derived from the constant value, and if&#xA;the verifier incorrectly prunes states considering them equivalent where&#xA;such arguments exist (by seeing that both registers have reg-&gt;precise as&#xA;false in regsafe), we can end up with invalid programs passing the&#xA;verifier which can do access beyond what should have been the correct&#xA;mem_size in that explored state.&#xA;&#xA;To show a concrete example of the problem:&#xA;&#xA;0000000000000000 &lt;prog&gt;:&#xA;       0:       r2 = *(u32 *)(r1 + 80)&#xA;       1:       r1 = *(u32 *)(r1 + 76)&#xA;       2:       r3 = r1&#xA;       3:       r3 += 4&#xA;       4:       if r3 &gt; r2 goto +18 &lt;LBB5_5&gt;&#xA;       5:       w2 = 0&#xA;       6:       *(u32 *)(r1 + 0) = r2&#xA;       7:       r1 = *(u32 *)(r1 + 0)&#xA;       8:       r2 = 1&#xA;       9:       if w1 == 0 goto +1 &lt;LBB5_3&gt;&#xA;      10:       r2 = -1&#xA;&#xA;0000000000000058 &lt;LBB5_3&gt;:&#xA;      11:       r1 = 0 ll&#xA;      13:       r3 = 0&#xA;      14:       call bpf_ringbuf_reserve&#xA;      15:       if r0 == 0 goto +7 &lt;LBB5_5&gt;&#xA;      16:       r1 = r0&#xA;      17:       r1 += 16777215&#xA;      18:       w2 = 0&#xA;      19:       *(u8 *)(r1 + 0) = r2&#xA;      20:       r1 = r0&#xA;      21:       r2 = 0&#xA;      22:       call bpf_ringbuf_submit&#xA;&#xA;00000000000000b8 &lt;LBB5_5&gt;:&#xA;      23:       w0 = 0&#xA;      24:       exit&#xA;&#xA;For the first case, the single line execution&#39;s exploration will prune&#xA;the search at insn 14 for the branch insn 9&#39;s second leg as it will be&#xA;verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will&#xA;always be 0 so at runtime we don&#39;t get error for being greater than&#xA;UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just&#xA;sees reg-&gt;precise as false for both r2 registers in both states, hence&#xA;considers them equal for purposes of states_equal.&#xA;&#xA;If we propagated precise markers using the backtracking support, we&#xA;would use the precise marking to then ensure that old r2 (UINT_MAX) was&#xA;within the new r2 (1) and this would never be true, so the verification&#xA;would rightfully fail.&#xA;&#xA;The end result is that the out of bounds access at instruction 19 would&#xA;be permitted without this fix.&#xA;&#xA;Note that reg-&gt;precise is always set to true when user does not have&#xA;CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static&#xA;or global functions)), hence this is only a problem when precision marks&#xA;need to be explicitly propagated (i.e. privileged users with CAP_BPF).&#xA;&#xA;A simplified test case has been included in the next patch to prevent&#xA;future regressions.&#xA;CVE-2025-38079:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: algif_hash - fix double free in hash_accept&#xA;&#xA;If accept(2) is called on socket type algif_hash with&#xA;MSG_MORE flag set and crypto_ahash_import fails,&#xA;sk2 is freed. However, it is also freed in af_alg_release,&#xA;leading to slab-use-after-free error.&#xA;CVE-2025-38074:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex&#xA;&#xA;The vhost-scsi completion path may access vq-&gt;log_base when vq-&gt;log_used is&#xA;already set to false.&#xA;&#xA;    vhost-thread                       QEMU-thread&#xA;&#xA;vhost_scsi_complete_cmd_work()&#xA;-&gt; vhost_add_used()&#xA;   -&gt; vhost_add_used_n()&#xA;      if (unlikely(vq-&gt;log_used))&#xA;                                      QEMU disables vq-&gt;log_used&#xA;                                      via VHOST_SET_VRING_ADDR.&#xA;                                      mutex_lock(&amp;vq-&gt;mutex);&#xA;                                      vq-&gt;log_used = false now!&#xA;                                      mutex_unlock(&amp;vq-&gt;mutex);&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;      QEMU gfree(vq-&gt;log_base)&#xA;        log_used()&#xA;        -&gt; log_write(vq-&gt;log_base)&#xA;&#xA;Assuming the VMM is QEMU. The vq-&gt;log_base is from QEMU userpace and can be&#xA;reclaimed via gfree(). As a result, this causes invalid memory writes to&#xA;QEMU userspace.&#xA;&#xA;The control queue path has the same issue.&#xA;CVE-2025-38117:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: MGMT: Protect mgmt_pending list with its own lock&#xA;&#xA;This uses a mutex to protect from concurrent access of mgmt_pending&#xA;list which can cause crashes like:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91&#xA;Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318&#xA;&#xA;CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025&#xA;Call trace:&#xA; show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)&#xA; __dump_stack+0x30/0x40 lib/dump_stack.c:94&#xA; dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120&#xA; print_address_description+0xa8/0x254 mm/kasan/report.c:408&#xA; print_report+0x68/0x84 mm/kasan/report.c:521&#xA; kasan_report+0xb0/0x110 mm/kasan/report.c:634&#xA; __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379&#xA; hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91&#xA; mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223&#xA; pending_find net/bluetooth/mgmt.c:947 [inline]&#xA; remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445&#xA; hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712&#xA; hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg net/socket.c:727 [inline]&#xA; sock_write_iter+0x25c/0x378 net/socket.c:1131&#xA; new_sync_write fs/read_write.c:591 [inline]&#xA; vfs_write+0x62c/0x97c fs/read_write.c:684&#xA; ksys_write+0x120/0x210 fs/read_write.c:736&#xA; __do_sys_write fs/read_write.c:747 [inline]&#xA; __se_sys_write fs/read_write.c:744 [inline]&#xA; __arm64_sys_write+0x7c/0x90 fs/read_write.c:744&#xA; __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]&#xA; invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49&#xA; el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132&#xA; do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151&#xA; el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767&#xA; el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786&#xA; el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600&#xA;&#xA;Allocated by task 7037:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x40/0x78 mm/kasan/common.c:68&#xA; kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562&#xA; poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA; __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394&#xA; kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA; __do_kmalloc_node mm/slub.c:4327 [inline]&#xA; __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339&#xA; kmalloc_noprof include/linux/slab.h:909 [inline]&#xA; sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198&#xA; sk_alloc+0x44/0x3ac net/core/sock.c:2254&#xA; bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148&#xA; hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202&#xA; bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132&#xA; __sock_create+0x43c/0x91c net/socket.c:1541&#xA; sock_create net/socket.c:1599 [inline]&#xA; __sys_socket_create net/socket.c:1636 [inline]&#xA; __sys_socket+0xd4/0x1c0 net/socket.c:1683&#xA; __do_sys_socket net/socket.c:1697 [inline]&#xA; __se_sys_socket net/socket.c:1695 [inline]&#xA; __arm64_sys_socket+0x7c/0x94 net/socket.c:1695&#xA; __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]&#xA; invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49&#xA; el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132&#xA; do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151&#xA; el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767&#xA; el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786&#xA; el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600&#xA;&#xA;Freed by task 6607:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x40/0x78 mm/kasan/common.c:68&#xA; kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576&#xA; poison_slab_object mm/kasan/common.c:247 [inline]&#xA; __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264&#xA; kasan_slab_free include/linux/kasan.h:233 [inline&#xA;---truncated---&#xA;CVE-2025-38157:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: ath9k_htc: Abort software beacon handling if disabled&#xA;&#xA;A malicious USB device can send a WMI_SWBA_EVENTID event from an&#xA;ath9k_htc-managed device before beaconing has been enabled. This causes&#xA;a device-by-zero error in the driver, leading to either a crash or an&#xA;out of bounds read.&#xA;&#xA;Prevent this by aborting the handling in ath9k_htc_swba() if beacons are&#xA;not enabled.&#xA;CVE-2025-38298:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;EDAC/skx_common: Fix general protection fault&#xA;&#xA;After loading i10nm_edac (which automatically loads skx_edac_common), if&#xA;unload only i10nm_edac, then reload it and perform error injection testing,&#xA;a general protection fault may occur:&#xA;&#xA;  mce: [Hardware Error]: Machine check events logged&#xA;  Oops: general protection fault ...&#xA;  ...&#xA;  Workqueue: events mce_gen_pool_process&#xA;  RIP: 0010:string+0x53/0xe0&#xA;  ...&#xA;  Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? die_addr+0x37/0x90&#xA;  ? exc_general_protection+0x1e7/0x3f0&#xA;  ? asm_exc_general_protection+0x26/0x30&#xA;  ? string+0x53/0xe0&#xA;  vsnprintf+0x23e/0x4c0&#xA;  snprintf+0x4d/0x70&#xA;  skx_adxl_decode+0x16a/0x330 [skx_edac_common]&#xA;  skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common]&#xA;  skx_mce_check_error+0x17/0x20 [skx_edac_common]&#xA;  ...&#xA;&#xA;The issue arose was because the variable &#39;adxl_component_count&#39; (inside&#xA;skx_edac_common), which counts the ADXL components, was not reset. During&#xA;the reloading of i10nm_edac, the count was incremented by the actual number&#xA;of ADXL components again, resulting in a count that was double the real&#xA;number of ADXL components. This led to an out-of-bounds reference to the&#xA;ADXL component array, causing the general protection fault above.&#xA;&#xA;Fix this issue by resetting the &#39;adxl_component_count&#39; in adxl_put(),&#xA;which is called during the unloading of {skx,i10nm}_edac.&#xA;CVE-2025-38337:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()&#xA;&#xA;Since handle-&gt;h_transaction may be a NULL pointer, so we should change it&#xA;to call is_handle_aborted(handle) first before dereferencing it.&#xA;&#xA;And the following data-race was reported in my fuzzer:&#xA;&#xA;==================================================================&#xA;BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata&#xA;&#xA;write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:&#xA; jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556&#xA; __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358&#xA; ext4_do_update_inode fs/ext4/inode.c:5220 [inline]&#xA; ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869&#xA; __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074&#xA; ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103&#xA;....&#xA;&#xA;read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:&#xA; jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512&#xA; __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358&#xA; ext4_do_update_inode fs/ext4/inode.c:5220 [inline]&#xA; ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869&#xA; __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074&#xA; ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103&#xA;....&#xA;&#xA;value changed: 0x00000000 -&gt; 0x00000001&#xA;==================================================================&#xA;&#xA;This issue is caused by missing data-race annotation for jh-&gt;b_modified.&#xA;Therefore, the missing annotation needs to be added.&#xA;CVE-2024-58002:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: uvcvideo: Remove dangling pointers&#xA;&#xA;When an async control is written, we copy a pointer to the file handle&#xA;that started the operation. That pointer will be used when the device is&#xA;done. Which could be anytime in the future.&#xA;&#xA;If the user closes that file descriptor, its structure will be freed,&#xA;and there will be one dangling pointer per pending async control, that&#xA;the driver will try to use.&#xA;&#xA;Clean all the dangling pointers during release().&#xA;&#xA;To avoid adding a performance penalty in the most common case (no async&#xA;operation), a counter has been introduced with some logic to make sure&#xA;that it is properly handled.&#xA;CVE-2025-21855:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ibmvnic: Don&#39;t reference skb after sending to VIOS&#xA;&#xA;Previously, after successfully flushing the xmit buffer to VIOS,&#xA;the tx_bytes stat was incremented by the length of the skb.&#xA;&#xA;It is invalid to access the skb memory after sending the buffer to&#xA;the VIOS because, at any point after sending, the VIOS can trigger&#xA;an interrupt to free this memory. A race between reading skb-&gt;len&#xA;and freeing the skb is possible (especially during LPM) and will&#xA;result in use-after-free:&#xA; ==================================================================&#xA; BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]&#xA; Read of size 4 at addr c00000024eb48a70 by task hxecom/14495&#xA; &lt;...&gt;&#xA; Call Trace:&#xA; [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)&#xA; [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0&#xA; [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8&#xA; [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0&#xA; [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]&#xA; [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358&#xA; &lt;...&gt;&#xA; Freed by task 0:&#xA; kasan_save_stack+0x34/0x68&#xA; kasan_save_track+0x2c/0x50&#xA; kasan_save_free_info+0x64/0x108&#xA; __kasan_mempool_poison_object+0x148/0x2d4&#xA; napi_skb_cache_put+0x5c/0x194&#xA; net_tx_action+0x154/0x5b8&#xA; handle_softirqs+0x20c/0x60c&#xA; do_softirq_own_stack+0x6c/0x88&#xA; &lt;...&gt;&#xA; The buggy address belongs to the object at c00000024eb48a00 which&#xA;  belongs to the cache skbuff_head_cache of size 224&#xA;==================================================================&#xA;CVE-2022-50224:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT&#xA;&#xA;Treat the NX bit as valid when using NPT, as KVM will set the NX bit when&#xA;the NX huge page mitigation is enabled (mindblowing) and trigger the WARN&#xA;that fires on reserved SPTE bits being set.&#xA;&#xA;KVM has required NX support for SVM since commit b26a71a1a5b9 (&#34;KVM: SVM:&#xA;Refuse to load kvm_amd if NX support is not available&#34;) for exactly this&#xA;reason, but apparently it never occurred to anyone to actually test NPT&#xA;with the mitigation enabled.&#xA;&#xA;  ------------[ cut here ]------------&#xA;  spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000&#xA;  WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm]&#xA;  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022&#xA;  RIP: 0010:make_spte+0x327/0x340 [kvm]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm]&#xA;   kvm_tdp_mmu_map+0x343/0x3b0 [kvm]&#xA;   direct_page_fault+0x1ae/0x2a0 [kvm]&#xA;   kvm_tdp_page_fault+0x7d/0x90 [kvm]&#xA;   kvm_mmu_page_fault+0xfb/0x2e0 [kvm]&#xA;   npf_interception+0x55/0x90 [kvm_amd]&#xA;   svm_invoke_exit_handler+0x31/0xf0 [kvm_amd]&#xA;   svm_handle_exit+0xf6/0x1d0 [kvm_amd]&#xA;   vcpu_enter_guest+0xb6d/0xee0 [kvm]&#xA;   ? kvm_pmu_trigger_event+0x6d/0x230 [kvm]&#xA;   vcpu_run+0x65/0x2c0 [kvm]&#xA;   kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm]&#xA;   kvm_vcpu_ioctl+0x551/0x610 [kvm]&#xA;   __se_sys_ioctl+0x77/0xc0&#xA;   __x64_sys_ioctl+0x1d/0x20&#xA;   do_syscall_64+0x44/0xa0&#xA;   entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;CVE-2025-38108:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: red: fix a race in __red_change()&#xA;&#xA;Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer&#xA;fires at the wrong time.&#xA;&#xA;The race is as follows:&#xA;&#xA;CPU 0                                 CPU 1&#xA;[1]: lock root&#xA;[2]: qdisc_tree_flush_backlog()&#xA;[3]: unlock root&#xA; |&#xA; |                                    [5]: lock root&#xA; |                                    [6]: rehash&#xA; |                                    [7]: qdisc_tree_reduce_backlog()&#xA; |&#xA;[4]: qdisc_put()&#xA;&#xA;This can be abused to underflow a parent&#39;s qlen.&#xA;&#xA;Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()&#xA;should fix the race, because all packets will be purged from the qdisc&#xA;before releasing the lock.&#xA;CVE-2025-38229:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: cxusb: no longer judge rbuf when the write fails&#xA;&#xA;syzbot reported a uninit-value in cxusb_i2c_xfer. [1]&#xA;&#xA;Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()&#xA;succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()&#xA;will be executed to read rlen bytes of data from the dvb device into the&#xA;rbuf.&#xA;&#xA;In this case, although rlen is 1, the write operation failed which resulted&#xA;in the dvb read operation not being executed, and ultimately variable i was&#xA;not initialized.&#xA;&#xA;[1]&#xA;BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]&#xA;BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196&#xA; cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]&#xA; cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196&#xA; __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1&#xA; i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315&#xA; i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343&#xA; i2c_master_send include/linux/i2c.h:109 [inline]&#xA; i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183&#xA; do_loop_readv_writev fs/read_write.c:848 [inline]&#xA; vfs_writev+0x963/0x14e0 fs/read_write.c:1057&#xA; do_writev+0x247/0x5c0 fs/read_write.c:1101&#xA; __do_sys_writev fs/read_write.c:1169 [inline]&#xA; __se_sys_writev fs/read_write.c:1166 [inline]&#xA; __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166&#xA; x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2025-38320:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()&#xA;&#xA;KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().&#xA;&#xA;Call Trace:&#xA;[   97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8&#xA;[   97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550&#xA;[   97.285732]&#xA;[   97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11&#xA;[   97.287032] Hardware name: linux,dummy-virt (DT)&#xA;[   97.287815] Call trace:&#xA;[   97.288279]  dump_backtrace+0xa0/0x128&#xA;[   97.288946]  show_stack+0x20/0x38&#xA;[   97.289551]  dump_stack_lvl+0x78/0xc8&#xA;[   97.290203]  print_address_description.constprop.0+0x84/0x3c8&#xA;[   97.291159]  print_report+0xb0/0x280&#xA;[   97.291792]  kasan_report+0x84/0xd0&#xA;[   97.292421]  __asan_load8+0x9c/0xc0&#xA;[   97.293042]  regs_get_kernel_stack_nth+0xa8/0xc8&#xA;[   97.293835]  process_fetch_insn+0x770/0xa30&#xA;[   97.294562]  kprobe_trace_func+0x254/0x3b0&#xA;[   97.295271]  kprobe_dispatcher+0x98/0xe0&#xA;[   97.295955]  kprobe_breakpoint_handler+0x1b0/0x210&#xA;[   97.296774]  call_break_hook+0xc4/0x100&#xA;[   97.297451]  brk_handler+0x24/0x78&#xA;[   97.298073]  do_debug_exception+0xac/0x178&#xA;[   97.298785]  el1_dbg+0x70/0x90&#xA;[   97.299344]  el1h_64_sync_handler+0xcc/0xe8&#xA;[   97.300066]  el1h_64_sync+0x78/0x80&#xA;[   97.300699]  kernel_clone+0x0/0x500&#xA;[   97.301331]  __arm64_sys_clone+0x70/0x90&#xA;[   97.302084]  invoke_syscall+0x68/0x198&#xA;[   97.302746]  el0_svc_common.constprop.0+0x11c/0x150&#xA;[   97.303569]  do_el0_svc+0x38/0x50&#xA;[   97.304164]  el0_svc+0x44/0x1d8&#xA;[   97.304749]  el0t_64_sync_handler+0x100/0x130&#xA;[   97.305500]  el0t_64_sync+0x188/0x190&#xA;[   97.306151]&#xA;[   97.306475] The buggy address belongs to stack of task 1.sh/2550&#xA;[   97.307461]  and is located at offset 0 in frame:&#xA;[   97.308257]  __se_sys_clone+0x0/0x138&#xA;[   97.308910]&#xA;[   97.309241] This frame has 1 object:&#xA;[   97.309873]  [48, 184) &#39;args&#39;&#xA;[   97.309876]&#xA;[   97.310749] The buggy address belongs to the virtual mapping at&#xA;[   97.310749]  [ffff800089270000, ffff800089279000) created by:&#xA;[   97.310749]  dup_task_struct+0xc0/0x2e8&#xA;[   97.313347]&#xA;[   97.313674] The buggy address belongs to the physical page:&#xA;[   97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a&#xA;[   97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)&#xA;[   97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000&#xA;[   97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000&#xA;[   97.319445] page dumped because: kasan: bad access detected&#xA;[   97.320371]&#xA;[   97.320694] Memory state around the buggy address:&#xA;[   97.321511]  ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;[   97.322681]  ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;[   97.323846] &gt;ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00&#xA;[   97.325023]                          ^&#xA;[   97.325683]  ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3&#xA;[   97.326856]  ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;&#xA;This issue seems to be related to the behavior of some gcc compilers and&#xA;was also fixed on the s390 architecture before:&#xA;&#xA; commit d93a855c31b7 (&#34;s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()&#34;)&#xA;&#xA;As described in that commit, regs_get_kernel_stack_nth() has confirmed that&#xA;`addr` is on the stack, so reading the value at `*addr` should be allowed.&#xA;Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.&#xA;&#xA;[will: Use &#39;*addr&#39; as the argument to READ_ONCE_NOCHECK()]&#xA;CVE-2025-37968:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: light: opt3001: fix deadlock due to concurrent flag access&#xA;&#xA;The threaded IRQ function in this driver is reading the flag twice: once to&#xA;lock a mutex and once to unlock it. Even though the code setting the flag&#xA;is designed to prevent it, there are subtle cases where the flag could be&#xA;true at the mutex_lock stage and false at the mutex_unlock stage. This&#xA;results in the mutex not being unlocked, resulting in a deadlock.&#xA;&#xA;Fix it by making the opt3001_irq() code generally more robust, reading the&#xA;flag into a variable and using the variable value at both stages.&#xA;CVE-2024-57931:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;selinux: ignore unknown extended permissions&#xA;&#xA;When evaluating extended permissions, ignore unknown permissions instead&#xA;of calling BUG(). This commit ensures that future permissions can be&#xA;added without interfering with older kernels.&#xA;CVE-2025-38072:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libnvdimm/labels: Fix divide error in nd_label_data_init()&#xA;&#xA;If a faulty CXL memory device returns a broken zero LSA size in its&#xA;memory device information (Identify Memory Device (Opcode 4000h), CXL&#xA;spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm&#xA;driver:&#xA;&#xA; Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI&#xA; RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]&#xA;&#xA;Code and flow:&#xA;&#xA;1) CXL Command 4000h returns LSA size = 0&#xA;2) config_size is assigned to zero LSA size (CXL pmem driver):&#xA;&#xA;drivers/cxl/pmem.c:             .config_size = mds-&gt;lsa_size,&#xA;&#xA;3) max_xfer is set to zero (nvdimm driver):&#xA;&#xA;drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-&gt;nsarea.max_xfer, config_size);&#xA;&#xA;4) A subsequent DIV_ROUND_UP() causes a division by zero:&#xA;&#xA;drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */&#xA;drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,&#xA;drivers/nvdimm/label.c-                 config_size);&#xA;&#xA;Fix this by checking the config size parameter by extending an&#xA;existing check.&#xA;CVE-2025-38023:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfs: handle failure of nfs_get_lock_context in unlock path&#xA;&#xA;When memory is insufficient, the allocation of nfs_lock_context in&#xA;nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat&#xA;an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)&#xA;as valid and proceed to execute rpc_run_task(), this will trigger a NULL&#xA;pointer dereference in nfs4_locku_prepare. For example:&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 000000000000000c&#xA;PGD 0 P4D 0&#xA;Oops: Oops: 0000 [#1] SMP PTI&#xA;CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40&#xA;Workqueue: rpciod rpc_async_schedule&#xA;RIP: 0010:nfs4_locku_prepare+0x35/0xc2&#xA;Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3&#xA;RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246&#xA;RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40&#xA;RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38&#xA;R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030&#xA;R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30&#xA;FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __rpc_execute+0xbc/0x480&#xA; rpc_async_schedule+0x2f/0x40&#xA; process_one_work+0x232/0x5d0&#xA; worker_thread+0x1da/0x3d0&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0x10d/0x240&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x34/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;CR2: 000000000000000c&#xA;---[ end trace 0000000000000000 ]---&#xA;&#xA;Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and&#xA;return NULL to terminate subsequent rpc_run_task, preventing NULL pointer&#xA;dereference.&#xA;CVE-2025-38146:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: openvswitch: Fix the dead loop of MPLS parse&#xA;&#xA;The unexpected MPLS packet may not end with the bottom label stack.&#xA;When there are many stacks, The label count value has wrapped around.&#xA;A dead loop occurs, soft lockup/CPU stuck finally.&#xA;&#xA;stack backtrace:&#xA;UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26&#xA;index -1 is out of range for type &#39;__be32 [3]&#39;&#xA;CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G           OE   5.15.0-121-generic #131-Ubuntu&#xA;Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; show_stack+0x52/0x5c&#xA; dump_stack_lvl+0x4a/0x63&#xA; dump_stack+0x10/0x16&#xA; ubsan_epilogue+0x9/0x36&#xA; __ubsan_handle_out_of_bounds.cold+0x44/0x49&#xA; key_extract_l3l4+0x82a/0x840 [openvswitch]&#xA; ? kfree_skbmem+0x52/0xa0&#xA; key_extract+0x9c/0x2b0 [openvswitch]&#xA; ovs_flow_key_extract+0x124/0x350 [openvswitch]&#xA; ovs_vport_receive+0x61/0xd0 [openvswitch]&#xA; ? kernel_init_free_pages.part.0+0x4a/0x70&#xA; ? get_page_from_freelist+0x353/0x540&#xA; netdev_port_receive+0xc4/0x180 [openvswitch]&#xA; ? netdev_port_receive+0x180/0x180 [openvswitch]&#xA; netdev_frame_hook+0x1f/0x40 [openvswitch]&#xA; __netif_receive_skb_core.constprop.0+0x23a/0xf00&#xA; __netif_receive_skb_list_core+0xfa/0x240&#xA; netif_receive_skb_list_internal+0x18e/0x2a0&#xA; napi_complete_done+0x7a/0x1c0&#xA; bnxt_poll+0x155/0x1c0 [bnxt_en]&#xA; __napi_poll+0x30/0x180&#xA; net_rx_action+0x126/0x280&#xA; ? bnxt_msix+0x67/0x80 [bnxt_en]&#xA; handle_softirqs+0xda/0x2d0&#xA; irq_exit_rcu+0x96/0xc0&#xA; common_interrupt+0x8e/0xa0&#xA; &lt;/IRQ&gt;&#xA;CVE-2025-38170:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64/fpsimd: Discard stale CPU state when handling SME traps&#xA;&#xA;The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state&#xA;incorrectly, and a race with preemption can result in a task having&#xA;TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state&#xA;is stale (e.g. with SME traps enabled). This can result in warnings from&#xA;do_sme_acc() where SME traps are not expected while TIF_SME is set:&#xA;&#xA;|        /* With TIF_SME userspace shouldn&#39;t generate any traps */&#xA;|        if (test_and_set_thread_flag(TIF_SME))&#xA;|                WARN_ON(1);&#xA;&#xA;This is very similar to the SVE issue we fixed in commit:&#xA;&#xA;  751ecf6afd6568ad (&#34;arm64/sve: Discard stale CPU state when handling SVE traps&#34;)&#xA;&#xA;The race can occur when the SME trap handler is preempted before and&#xA;after manipulating the saved FPSIMD/SVE/SME state, starting and ending on&#xA;the same CPU, e.g.&#xA;&#xA;| void do_sme_acc(unsigned long esr, struct pt_regs *regs)&#xA;| {&#xA;|         // Trap on CPU 0 with TIF_SME clear, SME traps enabled&#xA;|         // task-&gt;fpsimd_cpu is 0.&#xA;|         // per_cpu_ptr(&amp;fpsimd_last_state, 0) is task.&#xA;|&#xA;|         ...&#xA;|&#xA;|         // Preempted; migrated from CPU 0 to CPU 1.&#xA;|         // TIF_FOREIGN_FPSTATE is set.&#xA;|&#xA;|         get_cpu_fpsimd_context();&#xA;|&#xA;|         /* With TIF_SME userspace shouldn&#39;t generate any traps */&#xA;|         if (test_and_set_thread_flag(TIF_SME))&#xA;|                 WARN_ON(1);&#xA;|&#xA;|         if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {&#xA;|                 unsigned long vq_minus_one =&#xA;|                         sve_vq_from_vl(task_get_sme_vl(current)) - 1;&#xA;|                 sme_set_vq(vq_minus_one);&#xA;|&#xA;|                 fpsimd_bind_task_to_cpu();&#xA;|         }&#xA;|&#xA;|         put_cpu_fpsimd_context();&#xA;|&#xA;|         // Preempted; migrated from CPU 1 to CPU 0.&#xA;|         // task-&gt;fpsimd_cpu is still 0&#xA;|         // If per_cpu_ptr(&amp;fpsimd_last_state, 0) is still task then:&#xA;|         // - Stale HW state is reused (with SME traps enabled)&#xA;|         // - TIF_FOREIGN_FPSTATE is cleared&#xA;|         // - A return to userspace skips HW state restore&#xA;| }&#xA;&#xA;Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set&#xA;by calling fpsimd_flush_task_state() to detach from the saved CPU&#xA;state. This ensures that a subsequent context switch will not reuse the&#xA;stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the&#xA;new state to be reloaded from memory prior to a return to userspace.&#xA;&#xA;Note: this was originallly posted as [1].&#xA;&#xA;[ Rutland: rewrite commit message ]&#xA;CVE-2025-38095:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dma-buf: insert memory barrier before updating num_fences&#xA;&#xA;smp_store_mb() inserts memory barrier after storing operation.&#xA;It is different with what the comment is originally aiming so Null&#xA;pointer dereference can be happened if memory update is reordered.&#xA;CVE-2024-26798:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbcon: always restore the old font data in fbcon_do_set_font()&#xA;&#xA;Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when&#xA;vc_resize() failed) started restoring old font data upon failure (of&#xA;vc_resize()). But it performs so only for user fonts. It means that the&#xA;&#34;system&#34;/internal fonts are not restored at all. So in result, the very&#xA;first call to fbcon_do_set_font() performs no restore at all upon&#xA;failing vc_resize().&#xA;&#xA;This can be reproduced by Syzkaller to crash the system on the next&#xA;invocation of font_get(). It&#39;s rather hard to hit the allocation failure&#xA;in vc_resize() on the first font_set(), but not impossible. Esp. if&#xA;fault injection is used to aid the execution/failure. It was&#xA;demonstrated by Sirius:&#xA;  BUG: unable to handle page fault for address: fffffffffffffff8&#xA;  #PF: supervisor read access in kernel mode&#xA;  #PF: error_code(0x0000) - not-present page&#xA;  PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0&#xA;  Oops: 0000 [#1] PREEMPT SMP KASAN&#xA;  CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;  RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   con_font_get drivers/tty/vt/vt.c:4558 [inline]&#xA;   con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673&#xA;   vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]&#xA;   vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752&#xA;   tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803&#xA;   vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  ...&#xA;&#xA;So restore the font data in any case, not only for user fonts. Note the&#xA;later &#39;if&#39; is now protected by &#39;old_userfont&#39; and not &#39;old_data&#39; as the&#xA;latter is always set now. (And it is supposed to be non-NULL. Otherwise&#xA;we would see the bug above again.)&#xA;CVE-2025-21927:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()&#xA;&#xA;nvme_tcp_recv_pdu() doesn&#39;t check the validity of the header length.&#xA;When header digests are enabled, a target might send a packet with an&#xA;invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()&#xA;to access memory outside the allocated area and cause memory corruptions&#xA;by overwriting it with the calculated digest.&#xA;&#xA;Fix this by rejecting packets with an unexpected header length.&#xA;CVE-2025-22026:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: don&#39;t ignore the return code of svc_proc_register()&#xA;&#xA;Currently, nfsd_proc_stat_init() ignores the return value of&#xA;svc_proc_register(). If the procfile creation fails, then the kernel&#xA;will WARN when it tries to remove the entry later.&#xA;&#xA;Fix nfsd_proc_stat_init() to return the same type of pointer as&#xA;svc_proc_register(), and fix up nfsd_net_init() to check that and fail&#xA;the nfsd_net construction if it occurs.&#xA;&#xA;svc_proc_register() can fail if the dentry can&#39;t be allocated, or if an&#xA;identical dentry already exists. The second case is pretty unlikely in&#xA;the nfsd_net construction codepath, so if this happens, return -ENOMEM.&#xA;CVE-2022-50057:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr&#xA;&#xA;If ntfs_fill_super() wasn&#39;t called then sbi-&gt;sb will be equal to NULL.&#xA;Code should check this ptr before dereferencing. Syzbot hit this issue&#xA;via passing wrong mount param as can be seen from log below&#xA;&#xA;Fail log:&#xA;ntfs3: Unknown parameter &#39;iochvrset&#39;&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN&#xA;KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]&#xA;CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463&#xA; ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363&#xA; put_fs_context+0x119/0x7a0 fs/fs_context.c:469&#xA; do_new_mount+0x2b4/0xad0 fs/namespace.c:3044&#xA; do_mount fs/namespace.c:3383 [inline]&#xA; __do_sys_mount fs/namespace.c:3591 [inline]&#xA;CVE-2022-50230:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64: set UXN on swapper page tables&#xA;&#xA;[ This issue was fixed upstream by accident in c3cee924bd85 (&#34;arm64:&#xA;  head: cover entire kernel image in initial ID map&#34;) as part of a&#xA;  large refactoring of the arm64 boot flow. This simple fix is therefore&#xA;  preferred for -stable backporting ]&#xA;&#xA;On a system that implements FEAT_EPAN, read/write access to the idmap&#xA;is denied because UXN is not set on the swapper PTEs. As a result,&#xA;idmap_kpti_install_ng_mappings panics the kernel when accessing&#xA;__idmap_kpti_flag. Fix it by setting UXN on these PTEs.&#xA;CVE-2022-50167:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: fix potential 32-bit overflow when accessing ARRAY map element&#xA;&#xA;If BPF array map is bigger than 4GB, element pointer calculation can&#xA;overflow because both index and elem_size are u32. Fix this everywhere&#xA;by forcing 64-bit multiplication. Extract this formula into separate&#xA;small helper and use it consistently in various places.&#xA;&#xA;Speculative-preventing formula utilizing index_mask trick is left as is,&#xA;but explicit u64 casts are added in both places.&#xA;CVE-2025-38078:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: pcm: Fix race of buffer access at PCM OSS layer&#xA;&#xA;The PCM OSS layer tries to clear the buffer with the silence data at&#xA;initialization (or reconfiguration) of a stream with the explicit call&#xA;of snd_pcm_format_set_silence() with runtime-&gt;dma_area.  But this may&#xA;lead to a UAF because the accessed runtime-&gt;dma_area might be freed&#xA;concurrently, as it&#39;s performed outside the PCM ops.&#xA;&#xA;For avoiding it, move the code into the PCM core and perform it inside&#xA;the buffer access lock, so that it won&#39;t be changed during the&#xA;operation.&#xA;CVE-2025-38346:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ftrace: Fix UAF when lookup kallsym after ftrace disabled&#xA;&#xA;The following issue happens with a buggy module:&#xA;&#xA;BUG: unable to handle page fault for address: ffffffffc05d0218&#xA;PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0&#xA;Oops: Oops: 0000 [#1] SMP KASAN PTI&#xA;Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;RIP: 0010:sized_strscpy+0x81/0x2f0&#xA;RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000&#xA;RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d&#xA;RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68&#xA;R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038&#xA;R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff&#xA;FS:  00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ftrace_mod_get_kallsym+0x1ac/0x590&#xA; update_iter_mod+0x239/0x5b0&#xA; s_next+0x5b/0xa0&#xA; seq_read_iter+0x8c9/0x1070&#xA; seq_read+0x249/0x3b0&#xA; proc_reg_read+0x1b0/0x280&#xA; vfs_read+0x17f/0x920&#xA; ksys_read+0xf3/0x1c0&#xA; do_syscall_64+0x5f/0x2e0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;The above issue may happen as follows:&#xA;(1) Add kprobe tracepoint;&#xA;(2) insmod test.ko;&#xA;(3)  Module triggers ftrace disabled;&#xA;(4) rmmod test.ko;&#xA;(5) cat /proc/kallsyms; --&gt; Will trigger UAF as test.ko already removed;&#xA;ftrace_mod_get_kallsym()&#xA;...&#xA;strscpy(module_name, mod_map-&gt;mod-&gt;name, MODULE_NAME_LEN);&#xA;...&#xA;&#xA;The problem is when a module triggers an issue with ftrace and&#xA;sets ftrace_disable. The ftrace_disable is set when an anomaly is&#xA;discovered and to prevent any more damage, ftrace stops all text&#xA;modification. The issue that happened was that the ftrace_disable stops&#xA;more than just the text modification.&#xA;&#xA;When a module is loaded, its init functions can also be traced. Because&#xA;kallsyms deletes the init functions after a module has loaded, ftrace&#xA;saves them when the module is loaded and function tracing is enabled. This&#xA;allows the output of the function trace to show the init function names&#xA;instead of just their raw memory addresses.&#xA;&#xA;When a module is removed, ftrace_release_mod() is called, and if&#xA;ftrace_disable is set, it just returns without doing anything more. The&#xA;problem here is that it leaves the mod_list still around and if kallsyms&#xA;is called, it will call into this code and access the module memory that&#xA;has already been freed as it will return:&#xA;&#xA;  strscpy(module_name, mod_map-&gt;mod-&gt;name, MODULE_NAME_LEN);&#xA;&#xA;Where the &#34;mod&#34; no longer exists and triggers a UAF bug.&#xA;CVE-2025-37738:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: ignore xattrs past end&#xA;&#xA;Once inside &#39;ext4_xattr_inode_dec_ref_all&#39; we should&#xA;ignore xattrs entries past the &#39;end&#39; entry.&#xA;&#xA;This fixes the following KASAN reported issue:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90&#xA;Read of size 4 at addr ffff888012c120c4 by task repro/2065&#xA;&#xA;CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x1fd/0x300&#xA; ? tcp_gro_dev_warn+0x260/0x260&#xA; ? _printk+0xc0/0x100&#xA; ? read_lock_is_recursive+0x10/0x10&#xA; ? irq_work_queue+0x72/0xf0&#xA; ? __virt_addr_valid+0x17b/0x4b0&#xA; print_address_description+0x78/0x390&#xA; print_report+0x107/0x1f0&#xA; ? __virt_addr_valid+0x17b/0x4b0&#xA; ? __virt_addr_valid+0x3ff/0x4b0&#xA; ? __phys_addr+0xb5/0x160&#xA; ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90&#xA; kasan_report+0xcc/0x100&#xA; ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90&#xA; ext4_xattr_inode_dec_ref_all+0xb8c/0xe90&#xA; ? ext4_xattr_delete_inode+0xd30/0xd30&#xA; ? __ext4_journal_ensure_credits+0x5f0/0x5f0&#xA; ? __ext4_journal_ensure_credits+0x2b/0x5f0&#xA; ? inode_update_timestamps+0x410/0x410&#xA; ext4_xattr_delete_inode+0xb64/0xd30&#xA; ? ext4_truncate+0xb70/0xdc0&#xA; ? ext4_expand_extra_isize_ea+0x1d20/0x1d20&#xA; ? __ext4_mark_inode_dirty+0x670/0x670&#xA; ? ext4_journal_check_start+0x16f/0x240&#xA; ? ext4_inode_is_fast_symlink+0x2f2/0x3a0&#xA; ext4_evict_inode+0xc8c/0xff0&#xA; ? ext4_inode_is_fast_symlink+0x3a0/0x3a0&#xA; ? do_raw_spin_unlock+0x53/0x8a0&#xA; ? ext4_inode_is_fast_symlink+0x3a0/0x3a0&#xA; evict+0x4ac/0x950&#xA; ? proc_nr_inodes+0x310/0x310&#xA; ? trace_ext4_drop_inode+0xa2/0x220&#xA; ? _raw_spin_unlock+0x1a/0x30&#xA; ? iput+0x4cb/0x7e0&#xA; do_unlinkat+0x495/0x7c0&#xA; ? try_break_deleg+0x120/0x120&#xA; ? 0xffffffff81000000&#xA; ? __check_object_size+0x15a/0x210&#xA; ? strncpy_from_user+0x13e/0x250&#xA; ? getname_flags+0x1dc/0x530&#xA; __x64_sys_unlinkat+0xc8/0xf0&#xA; do_syscall_64+0x65/0x110&#xA; entry_SYSCALL_64_after_hwframe+0x67/0x6f&#xA;RIP: 0033:0x434ffd&#xA;Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8&#xA;RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107&#xA;RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd&#xA;RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005&#xA;RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001&#xA;R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001&#xA; &lt;/TASK&gt;&#xA;&#xA;The buggy address belongs to the object at ffff888012c12000&#xA; which belongs to the cache filp of size 360&#xA;The buggy address is located 196 bytes inside of&#xA; freed 360-byte region [ffff888012c12000, ffff888012c12168)&#xA;&#xA;The buggy address belongs to the physical page:&#xA;page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12&#xA;head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0&#xA;flags: 0x40(head|node=0|zone=0)&#xA;page_type: f5(slab)&#xA;raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004&#xA;raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000&#xA;head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004&#xA;head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000&#xA;head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000&#xA;head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;&#xA;Memory state around the buggy address:&#xA; ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA; ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;&gt; ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;                                           ^&#xA; ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc&#xA; ffff888012c12180: fc fc fc fc fc fc fc fc fc&#xA;---truncated---&#xA;CVE-2025-37937:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()&#xA;&#xA;If dib8000_set_dds()&#39;s call to dib8000_read32() returns zero, the result&#xA;is a divide-by-zero.  Prevent that from happening.&#xA;&#xA;Fixes the following warning with an UBSAN kernel:&#xA;&#xA;  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()&#xA;CVE-2025-21704:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: cdc-acm: Check control transfer buffer size before access&#xA;&#xA;If the first fragment is shorter than struct usb_cdc_notification, we can&#39;t&#xA;calculate an expected_size. Log an error and discard the notification&#xA;instead of reading lengths from memory outside the received data, which can&#xA;lead to memory corruption when the expected_size decreases between&#xA;fragments, causing `expected_size - acm-&gt;nb_index` to wrap.&#xA;&#xA;This issue has been present since the beginning of git history; however,&#xA;it only leads to memory corruption since commit ea2583529cd1&#xA;(&#34;cdc-acm: reassemble fragmented notifications&#34;).&#xA;&#xA;A mitigating factor is that acm_ctrl_irq() can only execute after userspace&#xA;has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will&#xA;do that automatically depending on the USB device&#39;s vendor/product IDs and&#xA;its other interfaces.&#xA;CVE-2024-58083:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()&#xA;&#xA;Explicitly verify the target vCPU is fully online _prior_ to clamping the&#xA;index in kvm_get_vcpu().  If the index is &#34;bad&#34;, the nospec clamping will&#xA;generate &#39;0&#39;, i.e. KVM will return vCPU0 instead of NULL.&#xA;&#xA;In practice, the bug is unlikely to cause problems, as it will only come&#xA;into play if userspace or the guest is buggy or misbehaving, e.g. KVM may&#xA;send interrupts to vCPU0 instead of dropping them on the floor.&#xA;&#xA;However, returning vCPU0 when it shouldn&#39;t exist per online_vcpus is&#xA;problematic now that KVM uses an xarray for the vCPUs array, as KVM needs&#xA;to insert into the xarray before publishing the vCPU to userspace (see&#xA;commit c5b077549136 (&#34;KVM: Convert the kvm-&gt;vcpus array to a xarray&#34;)),&#xA;i.e. before vCPU creation is guaranteed to succeed.&#xA;&#xA;As a result, incorrectly providing access to vCPU0 will trigger a&#xA;use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()&#xA;bails out of vCPU creation due to an error and frees vCPU0.  Commit&#xA;afb2acb2e3a3 (&#34;KVM: Fix vcpu_array[0] races&#34;) papered over that issue, but&#xA;in doing so introduced an unsolvable teardown conundrum.  Preventing&#xA;accesses to vCPU0 before it&#39;s fully online will allow reverting commit&#xA;afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.&#xA;CVE-2023-53039:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: intel-ish-hid: ipc: Fix potential use-after-free in work function&#xA;&#xA;When a reset notify IPC message is received, the ISR schedules a work&#xA;function and passes the ISHTP device to it via a global pointer&#xA;ishtp_dev. If ish_probe() fails, the devm-managed device resources&#xA;including ishtp_dev are freed, but the work is not cancelled, causing a&#xA;use-after-free when the work function tries to access ishtp_dev. Use&#xA;devm_work_autocancel() instead, so that the work is automatically&#xA;cancelled if probe fails.&#xA;CVE-2022-21546:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: Fix WRITE_SAME No Data Buffer crash&#xA;&#xA;In newer version of the SBC specs, we have a NDOB bit that indicates there&#xA;is no data buffer that gets written out. If this bit is set using commands&#xA;like &#34;sg_write_same --ndob&#34; we will crash in target_core_iblock/file&#39;s&#xA;execute_write_same handlers when we go to access the se_cmd-&gt;t_data_sg&#xA;because its NULL.&#xA;&#xA;This patch adds a check for the NDOB bit in the common WRITE SAME code&#xA;because we don&#39;t support it. And, it adds a check for zero SG elements in&#xA;each handler in case the initiator tries to send a normal WRITE SAME with&#xA;no data buffer.&#xA;CVE-2025-23156:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: venus: hfi_parser: refactor hfi packet parsing logic&#xA;&#xA;words_count denotes the number of words in total payload, while data&#xA;points to payload of various property within it. When words_count&#xA;reaches last word, data can access memory beyond the total payload. This&#xA;can lead to OOB access. With this patch, the utility api for handling&#xA;individual properties now returns the size of data consumed. Accordingly&#xA;remaining bytes are calculated before parsing the payload, thereby&#xA;eliminates the OOB access possibilities.&#xA;CVE-2025-23148:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()&#xA;&#xA;soc_dev_attr-&gt;revision could be NULL, thus,&#xA;a pointer check is added to prevent potential NULL pointer dereference.&#xA;This is similar to the fix in commit 3027e7b15b02&#xA;(&#34;ice: Fix some null pointer dereference issues in ice_ptp.c&#34;).&#xA;&#xA;This issue is found by our static analysis tool.&#xA;CVE-2023-53082:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vp_vdpa: fix the crash in hot unplug with vp_vdpa&#xA;&#xA;While unplugging the vp_vdpa device, it triggers a kernel panic&#xA;The root cause is: vdpa_mgmtdev_unregister() will accesses modern&#xA;devices which will cause a use after free.&#xA;So need to change the sequence in vp_vdpa_remove&#xA;&#xA;[  195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014&#xA;[  195.004012] #PF: supervisor read access in kernel mode&#xA;[  195.004486] #PF: error_code(0x0000) - not-present page&#xA;[  195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0&#xA;[  195.005578] Oops: 0000 1 PREEMPT SMP PTI&#xA;[  195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1&#xA;[  195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown&#xA;[  195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn&#xA;[  195.008059] RIP: 0010:ioread8+0x31/0x80&#xA;[  195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc &lt;8a&gt; 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7&#xA;[  195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292&#xA;[  195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0&#xA;[  195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014&#xA;[  195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68&#xA;[  195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120&#xA;[  195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805&#xA;[  195.013826] FS:  0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000&#xA;[  195.014564] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0&#xA;[  195.015741] PKRU: 55555554&#xA;[  195.016001] Call Trace:&#xA;[  195.016233]  &lt;TASK&gt;&#xA;[  195.016434]  vp_modern_get_status+0x12/0x20&#xA;[  195.016823]  vp_vdpa_reset+0x1b/0x50 [vp_vdpa]&#xA;[  195.017238]  virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa]&#xA;[  195.017709]  remove_vq_common+0x1f/0x3a0 [virtio_net]&#xA;[  195.018178]  virtnet_remove+0x5d/0x70 [virtio_net]&#xA;[  195.018618]  virtio_dev_remove+0x3d/0x90&#xA;[  195.018986]  device_release_driver_internal+0x1aa/0x230&#xA;[  195.019466]  bus_remove_device+0xd8/0x150&#xA;[  195.019841]  device_del+0x18b/0x3f0&#xA;[  195.020167]  ? kernfs_find_ns+0x35/0xd0&#xA;[  195.020526]  device_unregister+0x13/0x60&#xA;[  195.020894]  unregister_virtio_device+0x11/0x20&#xA;[  195.021311]  device_release_driver_internal+0x1aa/0x230&#xA;[  195.021790]  bus_remove_device+0xd8/0x150&#xA;[  195.022162]  device_del+0x18b/0x3f0&#xA;[  195.022487]  device_unregister+0x13/0x60&#xA;[  195.022852]  ? vdpa_dev_remove+0x30/0x30 [vdpa]&#xA;[  195.023270]  vp_vdpa_dev_del+0x12/0x20 [vp_vdpa]&#xA;[  195.023694]  vdpa_match_remove+0x2b/0x40 [vdpa]&#xA;[  195.024115]  bus_for_each_dev+0x78/0xc0&#xA;[  195.024471]  vdpa_mgmtdev_unregister+0x65/0x80 [vdpa]&#xA;[  195.024937]  vp_vdpa_remove+0x23/0x40 [vp_vdpa]&#xA;[  195.025353]  pci_device_remove+0x36/0xa0&#xA;[  195.025719]  device_release_driver_internal+0x1aa/0x230&#xA;[  195.026201]  pci_stop_bus_device+0x6c/0x90&#xA;[  195.026580]  pci_stop_and_remove_bus_device+0xe/0x20&#xA;[  195.027039]  disable_slot+0x49/0x90&#xA;[  195.027366]  acpiphp_disable_and_eject_slot+0x15/0x90&#xA;[  195.027832]  hotplug_event+0xea/0x210&#xA;[  195.028171]  ? hotplug_event+0x210/0x210&#xA;[  195.028535]  acpiphp_hotplug_notify+0x22/0x80&#xA;[  195.028942]  ? hotplug_event+0x210/0x210&#xA;[  195.029303]  acpi_device_hotplug+0x8a/0x1d0&#xA;[  195.029690]  acpi_hotplug_work_fn+0x1a/0x30&#xA;[  195.030077]  process_one_work+0x1e8/0x3c0&#xA;[  195.030451]  worker_thread+0x50/0x3b0&#xA;[  195.030791]  ? rescuer_thread+0x3a0/0x3a0&#xA;[  195.031165]  kthread+0xd9/0x100&#xA;[  195.031459]  ? kthread_complete_and_exit+0x20/0x20&#xA;[  195.031899]  ret_from_fork+0x22/0x30&#xA;[  195.032233]  &lt;/TASK&gt;&#xA;CVE-2025-37923:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Fix oob write in trace_seq_to_buffer()&#xA;&#xA;syzbot reported this bug:&#xA;==================================================================&#xA;BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822&#xA;Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260&#xA;&#xA;CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:408 [inline]&#xA; print_report+0xc3/0x670 mm/kasan/report.c:521&#xA; kasan_report+0xe0/0x110 mm/kasan/report.c:634&#xA; check_region_inline mm/kasan/generic.c:183 [inline]&#xA; kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189&#xA; __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106&#xA; trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]&#xA; tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822&#xA; ....&#xA;==================================================================&#xA;&#xA;It has been reported that trace_seq_to_buffer() tries to copy more data&#xA;than PAGE_SIZE to buf. Therefore, to prevent this, we should use the&#xA;smaller of trace_seq_used(&amp;iter-&gt;seq) and PAGE_SIZE as an argument.&#xA;CVE-2025-37995:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;module: ensure that kobject_put() is safe for module type kobjects&#xA;&#xA;In &#39;lookup_or_create_module_kobject()&#39;, an internal kobject is created&#xA;using &#39;module_ktype&#39;. So call to &#39;kobject_put()&#39; on error handling&#xA;path causes an attempt to use an uninitialized completion pointer in&#xA;&#39;module_kobject_release()&#39;. In this scenario, we just want to release&#xA;kobject without an extra synchronization required for a regular module&#xA;unloading process, so adding an extra check whether &#39;complete()&#39; is&#xA;actually required makes &#39;kobject_put()&#39; safe.&#xA;CVE-2025-38212:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipc: fix to protect IPCS lookups using RCU&#xA;&#xA;syzbot reported that it discovered a use-after-free vulnerability, [0]&#xA;&#xA;[0]: https://lore.kernel.org/all/[email protected]/&#xA;&#xA;idr_for_each() is protected by rwsem, but this is not enough.  If it is&#xA;not protected by RCU read-critical region, when idr_for_each() calls&#xA;radix_tree_node_free() through call_rcu() to free the radix_tree_node&#xA;structure, the node will be freed immediately, and when reading the next&#xA;node in radix_tree_for_each_slot(), the already freed memory may be read.&#xA;&#xA;Therefore, we need to add code to make sure that idr_for_each() is&#xA;protected within the RCU read-critical region when we call it in&#xA;shm_destroy_orphaned().&#xA;CVE-2022-49647:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cgroup: Use separate src/dst nodes when preloading css_sets for migration&#xA;&#xA;Each cset (css_set) is pinned by its tasks. When we&#39;re moving tasks around&#xA;across csets for a migration, we need to hold the source and destination&#xA;csets to ensure that they don&#39;t go away while we&#39;re moving tasks about. This&#xA;is done by linking cset-&gt;mg_preload_node on either the&#xA;mgctx-&gt;preloaded_src_csets or mgctx-&gt;preloaded_dst_csets list. Using the&#xA;same cset-&gt;mg_preload_node for both the src and dst lists was deemed okay as&#xA;a cset can&#39;t be both the source and destination at the same time.&#xA;&#xA;Unfortunately, this overloading becomes problematic when multiple tasks are&#xA;involved in a migration and some of them are identity noop migrations while&#xA;others are actually moving across cgroups. For example, this can happen with&#xA;the following sequence on cgroup1:&#xA;&#xA; #1&gt; mkdir -p /sys/fs/cgroup/misc/a/b&#xA; #2&gt; echo $$ &gt; /sys/fs/cgroup/misc/a/cgroup.procs&#xA; #3&gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &amp;&#xA; #4&gt; PID=$!&#xA; #5&gt; echo $PID &gt; /sys/fs/cgroup/misc/a/b/tasks&#xA; #6&gt; echo $PID &gt; /sys/fs/cgroup/misc/a/cgroup.procs&#xA;&#xA;the process including the group leader back into a. In this final migration,&#xA;non-leader threads would be doing identity migration while the group leader&#xA;is doing an actual one.&#xA;&#xA;After #3, let&#39;s say the whole process was in cset A, and that after #4, the&#xA;leader moves to cset B. Then, during #6, the following happens:&#xA;&#xA; 1. cgroup_migrate_add_src() is called on B for the leader.&#xA;&#xA; 2. cgroup_migrate_add_src() is called on A for the other threads.&#xA;&#xA; 3. cgroup_migrate_prepare_dst() is called. It scans the src list.&#xA;&#xA; 4. It notices that B wants to migrate to A, so it tries to A to the dst&#xA;    list but realizes that its -&gt;mg_preload_node is already busy.&#xA;&#xA; 5. and then it notices A wants to migrate to A as it&#39;s an identity&#xA;    migration, it culls it by list_del_init()&#39;ing its -&gt;mg_preload_node and&#xA;    putting references accordingly.&#xA;&#xA; 6. The rest of migration takes place with B on the src list but nothing on&#xA;    the dst list.&#xA;&#xA;This means that A isn&#39;t held while migration is in progress. If all tasks&#xA;leave A before the migration finishes and the incoming task pins it, the&#xA;cset will be destroyed leading to use-after-free.&#xA;&#xA;This is caused by overloading cset-&gt;mg_preload_node for both src and dst&#xA;preload lists. We wanted to exclude the cset from the src list but ended up&#xA;inadvertently excluding it from the dst list too.&#xA;&#xA;This patch fixes the issue by separating out cset-&gt;mg_preload_node into&#xA;-&gt;mg_src_preload_node and -&gt;mg_dst_preload_node, so that the src and dst&#xA;preloadings don&#39;t interfere with each other.&#xA;CVE-2025-37858:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/jfs: Prevent integer overflow in AG size calculation&#xA;&#xA;The JFS filesystem calculates allocation group (AG) size using 1 &lt;&lt;&#xA;l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with &gt;2TB&#xA;aggregates on 32-bit systems), this 32-bit shift operation causes undefined&#xA;behavior and improper AG sizing.&#xA;&#xA;On 32-bit architectures:&#xA;- Left-shifting 1 by 32+ bits results in 0 due to integer overflow&#xA;- This creates invalid AG sizes (0 or garbage values) in&#xA;sbi-&gt;bmap-&gt;db_agsize&#xA;- Subsequent block allocations would reference invalid AG structures&#xA;- Could lead to:&#xA;  - Filesystem corruption during extend operations&#xA;  - Kernel crashes due to invalid memory accesses&#xA;  - Security vulnerabilities via malformed on-disk structures&#xA;&#xA;Fix by casting to s64 before shifting:&#xA;bmp-&gt;db_agsize = (s64)1 &lt;&lt; l2agsize;&#xA;&#xA;This ensures 64-bit arithmetic even on 32-bit architectures. The cast&#xA;matches the data type of db_agsize (s64) and follows similar patterns in&#xA;JFS block calculation code.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2025-38031:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;padata: do not leak refcount in reorder_work&#xA;&#xA;A recent patch that addressed a UAF introduced a reference count leak:&#xA;the parallel_data refcount is incremented unconditionally, regardless&#xA;of the return value of queue_work(). If the work item is already queued,&#xA;the incremented refcount is never decremented.&#xA;&#xA;Fix this by checking the return value of queue_work() and decrementing&#xA;the refcount when necessary.&#xA;&#xA;Resolves:&#xA;&#xA;Unreferenced object 0xffff9d9f421e3d80 (size 192):&#xA;  comm &#34;cryptomgr_probe&#34;, pid 157, jiffies 4294694003&#xA;  hex dump (first 32 bytes):&#xA;    80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff  ...A............&#xA;    d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00  ..............#.&#xA;  backtrace (crc 838fb36):&#xA;    __kmalloc_cache_noprof+0x284/0x320&#xA;    padata_alloc_pd+0x20/0x1e0&#xA;    padata_alloc_shell+0x3b/0xa0&#xA;    0xffffffffc040a54d&#xA;    cryptomgr_probe+0x43/0xc0&#xA;    kthread+0xf6/0x1f0&#xA;    ret_from_fork+0x2f/0x50&#xA;    ret_from_fork_asm+0x1a/0x30&#xA;CVE-2022-3238:A double-free flaw was found in the Linux kernel’s NTFS3 subsystem in how a user triggers remount and umount simultaneously. This flaw allows a local user to crash or potentially escalate their privileges on the system.&#xA;CVE-2024-57876:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/dp_mst: Fix resetting msg rx state after topology removal&#xA;&#xA;If the MST topology is removed during the reception of an MST down reply&#xA;or MST up request sideband message, the&#xA;drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset&#xA;from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with&#xA;the reading/parsing of the message from another thread via&#xA;drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is&#xA;possible since the reader/parser doesn&#39;t hold any lock while accessing&#xA;the reception state. This in turn can lead to a memory corruption in the&#xA;reader/parser as described by commit bd2fccac61b4 (&#34;drm/dp_mst: Fix MST&#xA;sideband message body length check&#34;).&#xA;&#xA;Fix the above by resetting the message reception state if needed before&#xA;reading/parsing a message. Another solution would be to hold the&#xA;drm_dp_mst_topology_mgr::lock for the whole duration of the message&#xA;reception/parsing in drm_dp_mst_handle_down_rep() and&#xA;drm_dp_mst_handle_up_req(), however this would require a bigger change.&#xA;Since the fix is also needed for stable, opting for the simpler solution&#xA;in this patch.&#xA;CVE-2024-58097:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: ath11k: fix RCU stall while reaping monitor destination ring&#xA;&#xA;While processing the monitor destination ring, MSDUs are reaped from the&#xA;link descriptor based on the corresponding buf_id.&#xA;&#xA;However, sometimes the driver cannot obtain a valid buffer corresponding&#xA;to the buf_id received from the hardware. This causes an infinite loop&#xA;in the destination processing, resulting in a kernel crash.&#xA;&#xA;kernel log:&#xA;ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309&#xA;ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed&#xA;ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309&#xA;ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed&#xA;&#xA;Fix this by skipping the problematic buf_id and reaping the next entry,&#xA;replacing the break with the next MSDU processing.&#xA;&#xA;Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30&#xA;Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1&#xA;CVE-2025-37925:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: reject on-disk inodes of an unsupported type&#xA;&#xA;Syzbot has reported the following BUG:&#xA;&#xA;kernel BUG at fs/inode.c:668!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014&#xA;RIP: 0010:clear_inode+0x168/0x190&#xA;Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7&#xA; 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f&#xA;RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093&#xA;RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980&#xA;RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000&#xA;RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38&#xA;R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000&#xA;R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80&#xA;FS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body+0x5f/0xb0&#xA; ? die+0x9e/0xc0&#xA; ? do_trap+0x15a/0x3a0&#xA; ? clear_inode+0x168/0x190&#xA; ? do_error_trap+0x1dc/0x2c0&#xA; ? clear_inode+0x168/0x190&#xA; ? __pfx_do_error_trap+0x10/0x10&#xA; ? report_bug+0x3cd/0x500&#xA; ? handle_invalid_op+0x34/0x40&#xA; ? clear_inode+0x168/0x190&#xA; ? exc_invalid_op+0x38/0x50&#xA; ? asm_exc_invalid_op+0x1a/0x20&#xA; ? clear_inode+0x57/0x190&#xA; ? clear_inode+0x167/0x190&#xA; ? clear_inode+0x168/0x190&#xA; ? clear_inode+0x167/0x190&#xA; jfs_evict_inode+0xb5/0x440&#xA; ? __pfx_jfs_evict_inode+0x10/0x10&#xA; evict+0x4ea/0x9b0&#xA; ? __pfx_evict+0x10/0x10&#xA; ? iput+0x713/0xa50&#xA; txUpdateMap+0x931/0xb10&#xA; ? __pfx_txUpdateMap+0x10/0x10&#xA; jfs_lazycommit+0x49a/0xb80&#xA; ? _raw_spin_unlock_irqrestore+0x8f/0x140&#xA; ? lockdep_hardirqs_on+0x99/0x150&#xA; ? __pfx_jfs_lazycommit+0x10/0x10&#xA; ? __pfx_default_wake_function+0x10/0x10&#xA; ? __kthread_parkme+0x169/0x1d0&#xA; ? __pfx_jfs_lazycommit+0x10/0x10&#xA; kthread+0x2f2/0x390&#xA; ? __pfx_jfs_lazycommit+0x10/0x10&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x4d/0x80&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;&#xA;This happens when &#39;clear_inode()&#39; makes an attempt to finalize an underlying&#xA;JFS inode of unknown type. According to JFS layout description from&#xA;https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to&#xA;15 are reserved for future extensions and should not be encountered on a valid&#xA;filesystem. So add an extra check for valid inode type in &#39;copy_from_dinode()&#39;.&#xA;CVE-2025-37773:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;virtiofs: add filesystem context source name check&#xA;&#xA;In certain scenarios, for example, during fuzz testing, the source&#xA;name may be NULL, which could lead to a kernel panic. Therefore, an&#xA;extra check for the source name should be added.&#xA;CVE-2025-37782:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2025-37940:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ftrace: Add cond_resched() to ftrace_graph_set_hash()&#xA;&#xA;When the kernel contains a large number of functions that can be traced,&#xA;the loop in ftrace_graph_set_hash() may take a lot of time to execute.&#xA;This may trigger the softlockup watchdog.&#xA;&#xA;Add cond_resched() within the loop to allow the kernel to remain&#xA;responsive even when processing a large number of functions.&#xA;&#xA;This matches the cond_resched() that is used in other locations of the&#xA;code that iterates over all functions that can be traced.&#xA;CVE-2025-21999:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;proc: fix UAF in proc_get_inode()&#xA;&#xA;Fix race between rmmod and /proc/XXX&#39;s inode instantiation.&#xA;&#xA;The bug is that pde-&gt;proc_ops don&#39;t belong to /proc, it belongs to a&#xA;module, therefore dereferencing it after /proc entry has been registered&#xA;is a bug unless use_pde/unuse_pde() pair has been used.&#xA;&#xA;use_pde/unuse_pde can be avoided (2 atomic ops!) because pde-&gt;proc_ops&#xA;never changes so information necessary for inode instantiation can be&#xA;saved _before_ proc_register() in PDE itself and used later, avoiding&#xA;pde-&gt;proc_ops-&gt;...  dereference.&#xA;&#xA;      rmmod                         lookup&#xA;sys_delete_module&#xA;                         proc_lookup_de&#xA;&#x9;&#x9;&#x9;   pde_get(de);&#xA;&#x9;&#x9;&#x9;   proc_get_inode(dir-&gt;i_sb, de);&#xA;  mod-&gt;exit()&#xA;    proc_remove&#xA;      remove_proc_subtree&#xA;       proc_entry_rundown(de);&#xA;  free_module(mod);&#xA;&#xA;                               if (S_ISREG(inode-&gt;i_mode))&#xA;&#x9;                         if (de-&gt;proc_ops-&gt;proc_read_iter)&#xA;                           --&gt; As module is already freed, will trigger UAF&#xA;&#xA;BUG: unable to handle page fault for address: fffffbfff80a702b&#xA;PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0&#xA;Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;RIP: 0010:proc_get_inode+0x302/0x6e0&#xA;RSP: 0018:ffff88811c837998 EFLAGS: 00010a06&#xA;RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007&#xA;RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158&#xA;RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20&#xA;R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0&#xA;R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001&#xA;FS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; proc_lookup_de+0x11f/0x2e0&#xA; __lookup_slow+0x188/0x350&#xA; walk_component+0x2ab/0x4f0&#xA; path_lookupat+0x120/0x660&#xA; filename_lookup+0x1ce/0x560&#xA; vfs_statx+0xac/0x150&#xA; __do_sys_newstat+0x96/0x110&#xA; do_syscall_64+0x5f/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;[[email protected]: don&#39;t do 2 atomic ops on the common path]&#xA;CVE-2025-23144:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()&#xA;&#xA;Lockdep detects the following issue on led-backlight removal:&#xA;  [  142.315935] ------------[ cut here ]------------&#xA;  [  142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80&#xA;  ...&#xA;  [  142.500725] Call trace:&#xA;  [  142.503176]  led_sysfs_enable+0x54/0x80 (P)&#xA;  [  142.507370]  led_bl_remove+0x80/0xa8 [led_bl]&#xA;  [  142.511742]  platform_remove+0x30/0x58&#xA;  [  142.515501]  device_remove+0x54/0x90&#xA;  ...&#xA;&#xA;Indeed, led_sysfs_enable() has to be called with the led_access&#xA;lock held.&#xA;&#xA;Hold the lock when calling led_sysfs_disable().&#xA;CVE-2023-53093:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Do not let histogram values have some modifiers&#xA;&#xA;Histogram values can not be strings, stacktraces, graphs, symbols,&#xA;syscalls, or grouped in buckets or log. Give an error if a value is set to&#xA;do so.&#xA;&#xA;Note, the histogram code was not prepared to handle these modifiers for&#xA;histograms and caused a bug.&#xA;&#xA;Mark Rutland reported:&#xA;&#xA; # echo &#39;p:copy_to_user __arch_copy_to_user n=$arg2&#39; &gt;&gt; /sys/kernel/tracing/kprobe_events&#xA; # echo &#39;hist:keys=n:vals=hitcount.buckets=8:sort=hitcount&#39; &gt; /sys/kernel/tracing/events/kprobes/copy_to_user/trigger&#xA; # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist&#xA;[  143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000&#xA;[  143.695190] Mem abort info:&#xA;[  143.695362]   ESR = 0x0000000096000004&#xA;[  143.695604]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[  143.695889]   SET = 0, FnV = 0&#xA;[  143.696077]   EA = 0, S1PTW = 0&#xA;[  143.696302]   FSC = 0x04: level 0 translation fault&#xA;[  143.702381] Data abort info:&#xA;[  143.702614]   ISV = 0, ISS = 0x00000004&#xA;[  143.702832]   CM = 0, WnR = 0&#xA;[  143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000&#xA;[  143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000&#xA;[  143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP&#xA;[  143.704714] Modules linked in:&#xA;[  143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3&#xA;[  143.706138] Hardware name: linux,dummy-virt (DT)&#xA;[  143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[  143.707120] pc : hist_field_name.part.0+0x14/0x140&#xA;[  143.707504] lr : hist_field_name.part.0+0x104/0x140&#xA;[  143.707774] sp : ffff800008333a30&#xA;[  143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0&#xA;[  143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800&#xA;[  143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001&#xA;[  143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000&#xA;[  143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;[  143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023&#xA;[  143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c&#xA;[  143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c&#xA;[  143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d&#xA;[  143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000&#xA;[  143.711746] Call trace:&#xA;[  143.712115]  hist_field_name.part.0+0x14/0x140&#xA;[  143.712642]  hist_field_name.part.0+0x104/0x140&#xA;[  143.712925]  hist_field_print+0x28/0x140&#xA;[  143.713125]  event_hist_trigger_print+0x174/0x4d0&#xA;[  143.713348]  hist_show+0xf8/0x980&#xA;[  143.713521]  seq_read_iter+0x1bc/0x4b0&#xA;[  143.713711]  seq_read+0x8c/0xc4&#xA;[  143.713876]  vfs_read+0xc8/0x2a4&#xA;[  143.714043]  ksys_read+0x70/0xfc&#xA;[  143.714218]  __arm64_sys_read+0x24/0x30&#xA;[  143.714400]  invoke_syscall+0x50/0x120&#xA;[  143.714587]  el0_svc_common.constprop.0+0x4c/0x100&#xA;[  143.714807]  do_el0_svc+0x44/0xd0&#xA;[  143.714970]  el0_svc+0x2c/0x84&#xA;[  143.715134]  el0t_64_sync_handler+0xbc/0x140&#xA;[  143.715334]  el0t_64_sync+0x190/0x194&#xA;[  143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000)&#xA;[  143.716510] ---[ end trace 0000000000000000 ]---&#xA;Segmentation fault&#xA;CVE-2025-21760:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ndisc: extend RCU protection in ndisc_send_skb()&#xA;&#xA;ndisc_send_skb() can be called without RTNL or RCU held.&#xA;&#xA;Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()&#xA;and avoid a potential UAF.&#xA;CVE-2025-21763:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;neighbour: use RCU protection in __neigh_notify()&#xA;&#xA;__neigh_notify() can be called without RTNL or RCU protection.&#xA;&#xA;Use RCU protection to avoid potential UAF.&#xA;CVE-2025-21761:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;openvswitch: use RCU protection in ovs_vport_cmd_fill_info()&#xA;&#xA;ovs_vport_cmd_fill_info() can be called without RTNL or RCU.&#xA;&#xA;Use RCU protection and dev_net_rcu() to avoid potential UAF.&#xA;CVE-2025-21764:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ndisc: use RCU protection in ndisc_alloc_skb()&#xA;&#xA;ndisc_alloc_skb() can be called without RTNL or RCU being held.&#xA;&#xA;Add RCU protection to avoid possible UAF.&#xA;CVE-2025-21762:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arp: use RCU protection in arp_xmit()&#xA;&#xA;arp_xmit() can be called without RTNL or RCU protection.&#xA;&#xA;Use RCU protection to avoid potential UAF.&#xA;CVE-2024-58094:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: add check read-only before truncation in jfs_truncate_nolock()&#xA;&#xA;Added a check for &#34;read-only&#34; mode in the `jfs_truncate_nolock`&#xA;function to avoid errors related to writing to a read-only&#xA;filesystem.&#xA;&#xA;Call stack:&#xA;&#xA;block_write_begin() {&#xA;  jfs_write_failed() {&#xA;    jfs_truncate() {&#xA;      jfs_truncate_nolock() {&#xA;        txEnd() {&#xA;          ...&#xA;          log = JFS_SBI(tblk-&gt;sb)-&gt;log;&#xA;          // (log == NULL)&#xA;&#xA;If the `isReadOnly(ip)` condition is triggered in&#xA;`jfs_truncate_nolock`, the function execution will stop, and no&#xA;further data modification will occur. Instead, the `xtTruncate`&#xA;function will be called with the &#34;COMMIT_WMAP&#34; flag, preventing&#xA;modifications in &#34;read-only&#34; mode.&#xA;CVE-2025-21780:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()&#xA;&#xA;It malicious user provides a small pptable through sysfs and then&#xA;a bigger pptable, it may cause buffer overflow attack in function&#xA;smu_sys_set_pp_table().&#xA;CVE-2025-21877:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usbnet: gl620a: fix endpoint checking in genelink_bind()&#xA;&#xA;Syzbot reports [1] a warning in usb_submit_urb() triggered by&#xA;inconsistencies between expected and actually present endpoints&#xA;in gl620a driver. Since genelink_bind() does not properly&#xA;verify whether specified eps are in fact provided by the device,&#xA;in this case, an artificially manufactured one, one may get a&#xA;mismatch.&#xA;&#xA;Fix the issue by resorting to a usbnet utility function&#xA;usbnet_get_endpoints(), usually reserved for this very problem.&#xA;Check for endpoints and return early before proceeding further if&#xA;any are missing.&#xA;&#xA;[1] Syzbot report:&#xA;usb 5-1: Manufacturer: syz&#xA;usb 5-1: SerialNumber: syz&#xA;usb 5-1: config 0 descriptor??&#xA;gl620a 5-1:0.23 usb0: register &#39;gl620a&#39; at usb-dummy_hcd.0-1, ...&#xA;------------[ cut here ]------------&#xA;usb 5-1: BOGUS urb xfer, pipe 3 != type 1&#xA;WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503&#xA;Modules linked in:&#xA;CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;Workqueue: mld mld_ifc_work&#xA;RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467&#xA; __netdev_start_xmit include/linux/netdevice.h:5002 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:5011 [inline]&#xA; xmit_one net/core/dev.c:3590 [inline]&#xA; dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606&#xA; sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343&#xA; __dev_xmit_skb net/core/dev.c:3827 [inline]&#xA; __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400&#xA; dev_queue_xmit include/linux/netdevice.h:3168 [inline]&#xA; neigh_resolve_output net/core/neighbour.c:1514 [inline]&#xA; neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494&#xA; neigh_output include/net/neighbour.h:539 [inline]&#xA; ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141&#xA; __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]&#xA; ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226&#xA; NF_HOOK_COND include/linux/netfilter.h:303 [inline]&#xA; ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247&#xA; dst_output include/net/dst.h:450 [inline]&#xA; NF_HOOK include/linux/netfilter.h:314 [inline]&#xA; NF_HOOK include/linux/netfilter.h:308 [inline]&#xA; mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819&#xA; mld_send_cr net/ipv6/mcast.c:2120 [inline]&#xA; mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651&#xA; process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229&#xA; process_scheduled_works kernel/workqueue.c:3310 [inline]&#xA; worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391&#xA; kthread+0x2c1/0x3a0 kernel/kthread.c:389&#xA; ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA; &lt;/TASK&gt;&#xA;CVE-2023-53010:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bnxt: Do not read past the end of test names&#xA;&#xA;Test names were being concatenated based on a offset beyond the end of&#xA;the first name, which tripped the buffer overflow detection logic:&#xA;&#xA; detected buffer overflow in strnlen&#xA; [...]&#xA; Call Trace:&#xA; bnxt_ethtool_init.cold+0x18/0x18&#xA;&#xA;Refactor struct hwrm_selftest_qlist_output to use an actual array,&#xA;and adjust the concatenation to use snprintf() rather than a series of&#xA;strncat() calls.&#xA;CVE-2025-21898:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ftrace: Avoid potential division by zero in function_stat_show()&#xA;&#xA;Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}&#xA;produce zero and skip stddev computation in that case.&#xA;&#xA;For now don&#39;t care about rec-&gt;counter * rec-&gt;counter overflow because&#xA;rec-&gt;time * rec-&gt;time overflow will likely happen earlier.&#xA;CVE-2025-21935:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rapidio: add check for rio_add_net() in rio_scan_alloc_net()&#xA;&#xA;The return value of rio_add_net() should be checked.  If it fails,&#xA;put_device() should be called to free the memory and give up the reference&#xA;initialized in rio_add_net().&#xA;CVE-2025-21993:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()&#xA;&#xA;When performing an iSCSI boot using IPv6, iscsistart still reads the&#xA;/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix&#xA;length is 64, this causes the shift exponent to become negative,&#xA;triggering a UBSAN warning. As the concept of a subnet mask does not&#xA;apply to IPv6, the value is set to ~0 to suppress the warning message.&#xA;CVE-2025-37980:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;block: fix resource leak in blk_register_queue() error path&#xA;&#xA;When registering a queue fails after blk_mq_sysfs_register() is&#xA;successful but the function later encounters an error, we need&#xA;to clean up the blk_mq_sysfs resources.&#xA;&#xA;Add the missing blk_mq_sysfs_unregister() call in the error path&#xA;to properly clean up these resources and prevent a memory leak.&#xA;CVE-2022-49246:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: atmel: Fix error handling in snd_proto_probe&#xA;&#xA;The device_node pointer is returned by of_parse_phandle()  with refcount&#xA;incremented. We should use of_node_put() on it when done.&#xA;&#xA;This function only calls of_node_put() in the regular path.&#xA;And it will cause refcount leak in error paths.&#xA;Fix this by calling of_node_put() in error handling too.&#xA;CVE-2022-49328:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mt76: fix use-after-free by removing a non-RCU wcid pointer&#xA;&#xA;Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule&#xA;by protecting mtxq-&gt;wcid with rcu_lock between mt76_txq_schedule and&#xA;sta_info_[alloc, free].&#xA;&#xA;[18853.876689] ==================================================================&#xA;[18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76]&#xA;[18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883&#xA;[18853.876786]&#xA;[18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215&#xA;&#xA;[18853.876840] Call trace:&#xA;[18853.876861]  dump_backtrace+0x0/0x3ec&#xA;[18853.876878]  show_stack+0x20/0x2c&#xA;[18853.876899]  dump_stack+0x11c/0x1ac&#xA;[18853.876918]  print_address_description+0x74/0x514&#xA;[18853.876934]  kasan_report+0x134/0x174&#xA;[18853.876948]  __asan_report_load8_noabort+0x44/0x50&#xA;[18853.876976]  mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]&#xA;[18853.877002]  mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]&#xA;[18853.877030]  mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047]&#xA;[18853.877054]  __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]&#xA;[18853.877071]  kthread+0x2f8/0x3b8&#xA;[18853.877087]  ret_from_fork+0x10/0x30&#xA;[18853.877098]&#xA;[18853.877112] Allocated by task 941:&#xA;[18853.877131]  kasan_save_stack+0x38/0x68&#xA;[18853.877147]  __kasan_kmalloc+0xd4/0xfc&#xA;[18853.877163]  kasan_kmalloc+0x10/0x1c&#xA;[18853.877177]  __kmalloc+0x264/0x3c4&#xA;[18853.877294]  sta_info_alloc+0x460/0xf88 [mac80211]&#xA;[18853.877410]  ieee80211_prep_connection+0x204/0x1ee0 [mac80211]&#xA;[18853.877523]  ieee80211_mgd_auth+0x6c4/0xa4c [mac80211]&#xA;[18853.877635]  ieee80211_auth+0x20/0x2c [mac80211]&#xA;[18853.877733]  rdev_auth+0x7c/0x438 [cfg80211]&#xA;[18853.877826]  cfg80211_mlme_auth+0x26c/0x390 [cfg80211]&#xA;[18853.877919]  nl80211_authenticate+0x6d4/0x904 [cfg80211]&#xA;[18853.877938]  genl_rcv_msg+0x748/0x93c&#xA;[18853.877954]  netlink_rcv_skb+0x160/0x2a8&#xA;[18853.877969]  genl_rcv+0x3c/0x54&#xA;[18853.877985]  netlink_unicast_kernel+0x104/0x1ec&#xA;[18853.877999]  netlink_unicast+0x178/0x268&#xA;[18853.878015]  netlink_sendmsg+0x3cc/0x5f0&#xA;[18853.878030]  sock_sendmsg+0xb4/0xd8&#xA;[18853.878043]  ____sys_sendmsg+0x2f8/0x53c&#xA;[18853.878058]  ___sys_sendmsg+0xe8/0x150&#xA;[18853.878071]  __sys_sendmsg+0xc4/0x1f4&#xA;[18853.878087]  __arm64_compat_sys_sendmsg+0x88/0x9c&#xA;[18853.878101]  el0_svc_common+0x1b4/0x390&#xA;[18853.878115]  do_el0_svc_compat+0x8c/0xdc&#xA;[18853.878131]  el0_svc_compat+0x10/0x1c&#xA;[18853.878146]  el0_sync_compat_handler+0xa8/0xcc&#xA;[18853.878161]  el0_sync_compat+0x188/0x1c0&#xA;[18853.878171]&#xA;[18853.878183] Freed by task 10927:&#xA;[18853.878200]  kasan_save_stack+0x38/0x68&#xA;[18853.878215]  kasan_set_track+0x28/0x3c&#xA;[18853.878228]  kasan_set_free_info+0x24/0x48&#xA;[18853.878244]  __kasan_slab_free+0x11c/0x154&#xA;[18853.878259]  kasan_slab_free+0x14/0x24&#xA;[18853.878273]  slab_free_freelist_hook+0xac/0x1b0&#xA;[18853.878287]  kfree+0x104/0x390&#xA;[18853.878402]  sta_info_free+0x198/0x210 [mac80211]&#xA;[18853.878515]  __sta_info_destroy_part2+0x230/0x2d4 [mac80211]&#xA;[18853.878628]  __sta_info_flush+0x300/0x37c [mac80211]&#xA;[18853.878740]  ieee80211_set_disassoc+0x2cc/0xa7c [mac80211]&#xA;[18853.878851]  ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211]&#xA;[18853.878962]  ieee80211_deauth+0x20/0x2c [mac80211]&#xA;[18853.879057]  rdev_deauth+0x7c/0x438 [cfg80211]&#xA;[18853.879150]  cfg80211_mlme_deauth+0x274/0x414 [cfg80211]&#xA;[18853.879243]  cfg80211_mlme_down+0xe4/0x118 [cfg80211]&#xA;[18853.879335]  cfg80211_disconnect+0x218/0x2d8 [cfg80211]&#xA;[18853.879427]  __cfg80211_leave+0x17c/0x240 [cfg80211]&#xA;[18853.879519]  cfg80211_leave+0x3c/0x58 [cfg80211]&#xA;[18853.879611]  wiphy_suspend+0xdc/0x200 [cfg80211]&#xA;[18853.879628]  dpm_run_callback+0x58/0x408&#xA;[18853.879642]  __device_suspend+0x4cc/0x864&#xA;[18853.879658]  async_suspend+0x34/0xf4&#xA;[18&#xA;---truncated---&#xA;CVE-2024-57980:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: uvcvideo: Fix double free in error path&#xA;&#xA;If the uvc_status_init() function fails to allocate the int_urb, it will&#xA;free the dev-&gt;status pointer but doesn&#39;t reset the pointer to NULL. This&#xA;results in the kfree() call in uvc_status_cleanup() trying to&#xA;double-free the memory. Fix it by resetting the dev-&gt;status pointer to&#xA;NULL after freeing it.&#xA;&#xA;Reviewed by: Ricardo Ribalda &lt;[email protected]&gt;&#xA;CVE-2025-21858:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;geneve: Fix use-after-free in geneve_find_dev().&#xA;&#xA;syzkaller reported a use-after-free in geneve_find_dev() [0]&#xA;without repro.&#xA;&#xA;geneve_configure() links struct geneve_dev.next to&#xA;net_generic(net, geneve_net_id)-&gt;geneve_list.&#xA;&#xA;The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,&#xA;IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.&#xA;&#xA;When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally&#xA;calls unregister_netdevice_queue() for each dev in the netns,&#xA;and later the dev is freed.&#xA;&#xA;However, its geneve_dev.next is still linked to the backend UDP&#xA;socket netns.&#xA;&#xA;Then, use-after-free will occur when another geneve dev is created&#xA;in the netns.&#xA;&#xA;Let&#39;s call geneve_dellink() instead in geneve_destroy_tunnels().&#xA;&#xA;[0]:&#xA;BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]&#xA;BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343&#xA;Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441&#xA;&#xA;CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d&#xA;Hardware name: linux,dummy-virt (DT)&#xA;Call trace:&#xA; show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C)&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:378 [inline]&#xA; print_report+0x16c/0x6f0 mm/kasan/report.c:489&#xA; kasan_report+0xc0/0x120 mm/kasan/report.c:602&#xA; __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379&#xA; geneve_find_dev drivers/net/geneve.c:1295 [inline]&#xA; geneve_configure+0x234/0x858 drivers/net/geneve.c:1343&#xA; geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634&#xA; rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795&#xA; __rtnl_newlink net/core/rtnetlink.c:3906 [inline]&#xA; rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021&#xA; rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911&#xA; netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543&#xA; rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]&#xA; netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348&#xA; netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892&#xA; sock_sendmsg_nosec net/socket.c:713 [inline]&#xA; __sock_sendmsg net/socket.c:728 [inline]&#xA; ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568&#xA; ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622&#xA; __sys_sendmsg net/socket.c:2654 [inline]&#xA; __do_sys_sendmsg net/socket.c:2659 [inline]&#xA; __se_sys_sendmsg net/socket.c:2657 [inline]&#xA; __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657&#xA; __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]&#xA; invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49&#xA; el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132&#xA; do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151&#xA; el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744&#xA; el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762&#xA; el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600&#xA;&#xA;Allocated by task 13247:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x30/0x68 mm/kasan/common.c:68&#xA; kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568&#xA; poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA; __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394&#xA; kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA; __do_kmalloc_node mm/slub.c:4298 [inline]&#xA; __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304&#xA; __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645&#xA; alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470&#xA; rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604&#xA; rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780&#xA; __rtnl_newlink net/core/rtnetlink.c:3906 [inline]&#xA; rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021&#xA; rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911&#xA; netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543&#xA; rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938&#xA; netlink_unicast_kernel net/netlink/af_n&#xA;---truncated---&#xA;CVE-2025-21928:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()&#xA;&#xA;The system can experience a random crash a few minutes after the driver is&#xA;removed. This issue occurs due to improper handling of memory freeing in&#xA;the ishtp_hid_remove() function.&#xA;&#xA;The function currently frees the `driver_data` directly within the loop&#xA;that destroys the HID devices, which can lead to accessing freed memory.&#xA;Specifically, `hid_destroy_device()` uses `driver_data` when it calls&#xA;`hid_ishtp_set_feature()` to power off the sensor, so freeing&#xA;`driver_data` beforehand can result in accessing invalid memory.&#xA;&#xA;This patch resolves the issue by storing the `driver_data` in a temporary&#xA;variable before calling `hid_destroy_device()`, and then freeing the&#xA;`driver_data` after the device is destroyed.&#xA;CVE-2024-56664:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, sockmap: Fix race between element replace and close()&#xA;&#xA;Element replace (with a socket different from the one stored) may race&#xA;with socket&#39;s close() link popping &amp; unlinking. __sock_map_delete()&#xA;unconditionally unrefs the (wrong) element:&#xA;&#xA;// set map[0] = s0&#xA;map_update_elem(map, 0, s0)&#xA;&#xA;// drop fd of s0&#xA;close(s0)&#xA;  sock_map_close()&#xA;    lock_sock(sk)               (s0!)&#xA;    sock_map_remove_links(sk)&#xA;      link = sk_psock_link_pop()&#xA;      sock_map_unlink(sk, link)&#xA;        sock_map_delete_from_link&#xA;                                        // replace map[0] with s1&#xA;                                        map_update_elem(map, 0, s1)&#xA;                                          sock_map_update_elem&#xA;                                (s1!)       lock_sock(sk)&#xA;                                            sock_map_update_common&#xA;                                              psock = sk_psock(sk)&#xA;                                              spin_lock(&amp;stab-&gt;lock)&#xA;                                              osk = stab-&gt;sks[idx]&#xA;                                              sock_map_add_link(..., &amp;stab-&gt;sks[idx])&#xA;                                              sock_map_unref(osk, &amp;stab-&gt;sks[idx])&#xA;                                                psock = sk_psock(osk)&#xA;                                                sk_psock_put(sk, psock)&#xA;                                                  if (refcount_dec_and_test(&amp;psock))&#xA;                                                    sk_psock_drop(sk, psock)&#xA;                                              spin_unlock(&amp;stab-&gt;lock)&#xA;                                            unlock_sock(sk)&#xA;          __sock_map_delete&#xA;            spin_lock(&amp;stab-&gt;lock)&#xA;            sk = *psk                        // s1 replaced s0; sk == s1&#xA;            if (!sk_test || sk_test == sk)   // sk_test (s0) != sk (s1); no branch&#xA;              sk = xchg(psk, NULL)&#xA;            if (sk)&#xA;              sock_map_unref(sk, psk)        // unref s1; sks[idx] will dangle&#xA;                psock = sk_psock(sk)&#xA;                sk_psock_put(sk, psock)&#xA;                  if (refcount_dec_and_test())&#xA;                    sk_psock_drop(sk, psock)&#xA;            spin_unlock(&amp;stab-&gt;lock)&#xA;    release_sock(sk)&#xA;&#xA;Then close(map) enqueues bpf_map_free_deferred, which finally calls&#xA;sock_map_free(). This results in some refcount_t warnings along with&#xA;a KASAN splat [1].&#xA;&#xA;Fix __sock_map_delete(), do not allow sock_map_unref() on elements that&#xA;may have been replaced.&#xA;&#xA;[1]:&#xA;BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330&#xA;Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063&#xA;&#xA;CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014&#xA;Workqueue: events_unbound bpf_map_free_deferred&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x68/0x90&#xA; print_report+0x174/0x4f6&#xA; kasan_report+0xb9/0x190&#xA; kasan_check_range+0x10f/0x1e0&#xA; sock_map_free+0x10e/0x330&#xA; bpf_map_free_deferred+0x173/0x320&#xA; process_one_work+0x846/0x1420&#xA; worker_thread+0x5b3/0xf80&#xA; kthread+0x29e/0x360&#xA; ret_from_fork+0x2d/0x70&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 1202:&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_save_track+0x10/0x30&#xA; __kasan_slab_alloc+0x85/0x90&#xA; kmem_cache_alloc_noprof+0x131/0x450&#xA; sk_prot_alloc+0x5b/0x220&#xA; sk_alloc+0x2c/0x870&#xA; unix_create1+0x88/0x8a0&#xA; unix_create+0xc5/0x180&#xA; __sock_create+0x241/0x650&#xA; __sys_socketpair+0x1ce/0x420&#xA; __x64_sys_socketpair+0x92/0x100&#xA; do_syscall_64+0x93/0x180&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Freed by task 46:&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_save_track+0x10/0x30&#xA; kasan_save_free_info+0x37/0x60&#xA; __kasan_slab_free+0x4b/0x70&#xA; kmem_cache_free+0x1a1/0x590&#xA; __sk_destruct+0x388/0x5a0&#xA; sk_psock_destroy+0x73e/0xa50&#xA; process_one_work+0x846/0x1420&#xA; worker_thread+0x5b3/0xf80&#xA; kthread+0x29e/0x360&#xA; ret_from_fork+0x2d/0x70&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;The bu&#xA;---truncated---&#xA;CVE-2024-56642:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tipc: Fix use-after-free of kernel socket in cleanup_bearer().&#xA;&#xA;syzkaller reported a use-after-free of UDP kernel socket&#xA;in cleanup_bearer() without repro. [0][1]&#xA;&#xA;When bearer_disable() calls tipc_udp_disable(), cleanup&#xA;of the UDP kernel socket is deferred by work calling&#xA;cleanup_bearer().&#xA;&#xA;tipc_exit_net() waits for such works to finish by checking&#xA;tipc_net(net)-&gt;wq_count.  However, the work decrements the&#xA;count too early before releasing the kernel socket,&#xA;unblocking cleanup_net() and resulting in use-after-free.&#xA;&#xA;Let&#39;s move the decrement after releasing the socket in&#xA;cleanup_bearer().&#xA;&#xA;[0]:&#xA;ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at&#xA;     sk_alloc+0x438/0x608&#xA;     inet_create+0x4c8/0xcb0&#xA;     __sock_create+0x350/0x6b8&#xA;     sock_create_kern+0x58/0x78&#xA;     udp_sock_create4+0x68/0x398&#xA;     udp_sock_create+0x88/0xc8&#xA;     tipc_udp_enable+0x5e8/0x848&#xA;     __tipc_nl_bearer_enable+0x84c/0xed8&#xA;     tipc_nl_bearer_enable+0x38/0x60&#xA;     genl_family_rcv_msg_doit+0x170/0x248&#xA;     genl_rcv_msg+0x400/0x5b0&#xA;     netlink_rcv_skb+0x1dc/0x398&#xA;     genl_rcv+0x44/0x68&#xA;     netlink_unicast+0x678/0x8b0&#xA;     netlink_sendmsg+0x5e4/0x898&#xA;     ____sys_sendmsg+0x500/0x830&#xA;&#xA;[1]:&#xA;BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]&#xA;BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979&#xA; udp_hashslot include/net/udp.h:85 [inline]&#xA; udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979&#xA; sk_common_release+0xaf/0x3f0 net/core/sock.c:3820&#xA; inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437&#xA; inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489&#xA; __sock_release net/socket.c:658 [inline]&#xA; sock_release+0xa0/0x210 net/socket.c:686&#xA; cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819&#xA; process_one_work kernel/workqueue.c:3229 [inline]&#xA; process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310&#xA; worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391&#xA; kthread+0x531/0x6b0 kernel/kthread.c:389&#xA; ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244&#xA;&#xA;Uninit was created at:&#xA; slab_free_hook mm/slub.c:2269 [inline]&#xA; slab_free mm/slub.c:4580 [inline]&#xA; kmem_cache_free+0x207/0xc40 mm/slub.c:4682&#xA; net_free net/core/net_namespace.c:454 [inline]&#xA; cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647&#xA; process_one_work kernel/workqueue.c:3229 [inline]&#xA; process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310&#xA; worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391&#xA; kthread+0x531/0x6b0 kernel/kthread.c:389&#xA; ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244&#xA;&#xA;CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;Workqueue: events cleanup_bearer&#xA;CVE-2024-57951:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hrtimers: Handle CPU state correctly on hotplug&#xA;&#xA;Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway&#xA;through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to&#xA;CPUHP_ONLINE:&#xA;&#xA;Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set&#xA;to 1 throughout. However, during a CPU unplug operation, the tick and the&#xA;clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online&#xA;state, for instance CFS incorrectly assumes that the hrtick is already&#xA;active, and the chance of the clockevent device to transition to oneshot&#xA;mode is also lost forever for the CPU, unless it goes back to a lower state&#xA;than CPUHP_HRTIMERS_PREPARE once.&#xA;&#xA;This round-trip reveals another issue; cpu_base.online is not set to 1&#xA;after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().&#xA;&#xA;Aside of that, the bulk of the per CPU state is not reset either, which&#xA;means there are dangling pointers in the worst case.&#xA;&#xA;Address this by adding a corresponding startup() callback, which resets the&#xA;stale per CPU state and sets the online flag.&#xA;&#xA;[ tglx: Make the new callback unconditionally available, remove the online&#xA;  &#x9;modification in the prepare() callback and clear the remaining&#xA;  &#x9;state in the starting callback instead of the prepare callback ]&#xA;CVE-2022-49513:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cpufreq: governor: Use kobject release() method to free dbs_data&#xA;&#xA;The struct dbs_data embeds a struct gov_attr_set and&#xA;the struct gov_attr_set embeds a kobject. Since every kobject must have&#xA;a release() method and we can&#39;t use kfree() to free it directly,&#xA;so introduce cpufreq_dbs_data_release() to release the dbs_data via&#xA;the kobject::release() method. This fixes the calltrace like below:&#xA;&#xA;  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34&#xA;  WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100&#xA;  Modules linked in:&#xA;  CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536&#xA;  Hardware name: Marvell OcteonTX CN96XX board (DT)&#xA;  pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;  pc : debug_print_object+0xb8/0x100&#xA;  lr : debug_print_object+0xb8/0x100&#xA;  sp : ffff80001dfcf9a0&#xA;  x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000&#xA;  x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210&#xA;  x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118&#xA;  x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000&#xA;  x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8&#xA;  x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14&#xA;  x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0&#xA;  x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001&#xA;  x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000&#xA;  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040&#xA;  Call trace:&#xA;   debug_print_object+0xb8/0x100&#xA;   __debug_check_no_obj_freed+0x1d0/0x25c&#xA;   debug_check_no_obj_freed+0x24/0xa0&#xA;   kfree+0x11c/0x440&#xA;   cpufreq_dbs_governor_exit+0xa8/0xac&#xA;   cpufreq_exit_governor+0x44/0x90&#xA;   cpufreq_set_policy+0x29c/0x570&#xA;   store_scaling_governor+0x110/0x154&#xA;   store+0xb0/0xe0&#xA;   sysfs_kf_write+0x58/0x84&#xA;   kernfs_fop_write_iter+0x12c/0x1c0&#xA;   new_sync_write+0xf0/0x18c&#xA;   vfs_write+0x1cc/0x220&#xA;   ksys_write+0x74/0x100&#xA;   __arm64_sys_write+0x28/0x3c&#xA;   invoke_syscall.constprop.0+0x58/0xf0&#xA;   do_el0_svc+0x70/0x170&#xA;   el0_svc+0x54/0x190&#xA;   el0t_64_sync_handler+0xa4/0x130&#xA;   el0t_64_sync+0x1a0/0x1a4&#xA;  irq event stamp: 189006&#xA;  hardirqs last  enabled at (189005): [&lt;ffff8000080849d0&gt;] finish_task_switch.isra.0+0xe0/0x2c0&#xA;  hardirqs last disabled at (189006): [&lt;ffff8000090667a4&gt;] el1_dbg+0x24/0xa0&#xA;  softirqs last  enabled at (188966): [&lt;ffff8000080106d0&gt;] __do_softirq+0x4b0/0x6a0&#xA;  softirqs last disabled at (188957): [&lt;ffff80000804a618&gt;] __irq_exit_rcu+0x108/0x1a4&#xA;&#xA;[ rjw: Because can be freed by the gov_attr_set_put() in&#xA;  cpufreq_dbs_governor_exit() now, it is also necessary to put the&#xA;  invocation of the governor -&gt;exit() callback into the new&#xA;  cpufreq_dbs_data_release() function. ]&#xA;CVE-2022-49443:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;list: fix a data-race around ep-&gt;rdllist&#xA;&#xA;ep_poll() first calls ep_events_available() with no lock held and checks&#xA;if ep-&gt;rdllist is empty by list_empty_careful(), which reads&#xA;rdllist-&gt;prev.  Thus all accesses to it need some protection to avoid&#xA;store/load-tearing.&#xA;&#xA;Note INIT_LIST_HEAD_RCU() already has the annotation for both prev&#xA;and next.&#xA;&#xA;Commit bf3b9f6372c4 (&#34;epoll: Add busy poll support to epoll with socket&#xA;fds.&#34;) added the first lockless ep_events_available(), and commit&#xA;c5a282e9635e (&#34;fs/epoll: reduce the scope of wq lock in epoll_wait()&#34;)&#xA;made some ep_events_available() calls lockless and added single call under&#xA;a lock, finally commit e59d3c64cba6 (&#34;epoll: eliminate unnecessary lock&#xA;for zero timeout&#34;) made the last ep_events_available() lockless.&#xA;&#xA;BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait&#xA;&#xA;write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:&#xA; INIT_LIST_HEAD include/linux/list.h:38 [inline]&#xA; list_splice_init include/linux/list.h:492 [inline]&#xA; ep_start_scan fs/eventpoll.c:622 [inline]&#xA; ep_send_events fs/eventpoll.c:1656 [inline]&#xA; ep_poll fs/eventpoll.c:1806 [inline]&#xA; do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234&#xA; do_epoll_pwait fs/eventpoll.c:2268 [inline]&#xA; __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]&#xA; __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275&#xA; __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;&#xA;read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:&#xA; list_empty_careful include/linux/list.h:329 [inline]&#xA; ep_events_available fs/eventpoll.c:381 [inline]&#xA; ep_poll fs/eventpoll.c:1797 [inline]&#xA; do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234&#xA; do_epoll_pwait fs/eventpoll.c:2268 [inline]&#xA; __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]&#xA; __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275&#xA; __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;&#xA;value changed: 0xffff88810480c7d0 -&gt; 0xffff888103c15098&#xA;&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G        W         5.17.0-rc7-syzkaller-dirty #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;CVE-2025-21726:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;padata: avoid UAF for reorder_work&#xA;&#xA;Although the previous patch can avoid ps and ps UAF for _do_serial, it&#xA;can not avoid potential UAF issue for reorder_work. This issue can&#xA;happen just as below:&#xA;&#xA;crypto_request&#x9;&#x9;&#x9;crypto_request&#x9;&#x9;crypto_del_alg&#xA;padata_do_serial&#xA;  ...&#xA;  padata_reorder&#xA;    // processes all remaining&#xA;    // requests then breaks&#xA;    while (1) {&#xA;      if (!padata)&#xA;        break;&#xA;      ...&#xA;    }&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;padata_do_serial&#xA;&#x9;&#x9;&#x9;&#x9;  // new request added&#xA;&#x9;&#x9;&#x9;&#x9;  list_add&#xA;    // sees the new request&#xA;    queue_work(reorder_work)&#xA;&#x9;&#x9;&#x9;&#x9;  padata_reorder&#xA;&#x9;&#x9;&#x9;&#x9;    queue_work_on(squeue-&gt;work)&#xA;...&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;&lt;kworker context&gt;&#xA;&#x9;&#x9;&#x9;&#x9;padata_serial_worker&#xA;&#x9;&#x9;&#x9;&#x9;// completes new request,&#xA;&#x9;&#x9;&#x9;&#x9;// no more outstanding&#xA;&#x9;&#x9;&#x9;&#x9;// requests&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;crypto_del_alg&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  // free pd&#xA;&#xA;&lt;kworker context&gt;&#xA;invoke_padata_reorder&#xA;  // UAF of pd&#xA;&#xA;To avoid UAF for &#39;reorder_work&#39;, get &#39;pd&#39; ref before put &#39;reorder_work&#39;&#xA;into the &#39;serial_wq&#39; and put &#39;pd&#39; ref until the &#39;serial_wq&#39; finish.&#xA;CVE-2025-21718:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: rose: fix timer races against user threads&#xA;&#xA;Rose timers only acquire the socket spinlock, without&#xA;checking if the socket is owned by one user thread.&#xA;&#xA;Add a check and rearm the timers if needed.&#xA;&#xA;BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174&#xA;Read of size 2 at addr ffff88802f09b82a by task swapper/0/0&#xA;&#xA;CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA;  __dump_stack lib/dump_stack.c:94 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA;  print_address_description mm/kasan/report.c:378 [inline]&#xA;  print_report+0x169/0x550 mm/kasan/report.c:489&#xA;  kasan_report+0x143/0x180 mm/kasan/report.c:602&#xA;  rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174&#xA;  call_timer_fn+0x187/0x650 kernel/time/timer.c:1793&#xA;  expire_timers kernel/time/timer.c:1844 [inline]&#xA;  __run_timers kernel/time/timer.c:2418 [inline]&#xA;  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430&#xA;  run_timer_base kernel/time/timer.c:2439 [inline]&#xA;  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449&#xA;  handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561&#xA;  __do_softirq kernel/softirq.c:595 [inline]&#xA;  invoke_softirq kernel/softirq.c:435 [inline]&#xA;  __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662&#xA;  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678&#xA;  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]&#xA;  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049&#xA; &lt;/IRQ&gt;&#xA;CVE-2025-21715:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: davicom: fix UAF in dm9000_drv_remove&#xA;&#xA;dm is netdev private data and it cannot be&#xA;used after free_netdev() call. Using dm after free_netdev()&#xA;can cause UAF bug. Fix it by moving free_netdev() at the end of the&#xA;function.&#xA;&#xA;This is similar to the issue fixed in commit&#xA;ad297cd2db89 (&#34;net: qcom/emac: fix UAF in emac_remove&#34;).&#xA;&#xA;This bug is detected by our static analysis tool.&#xA;CVE-2025-21727:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;padata: fix UAF in padata_reorder&#xA;&#xA;A bug was found when run ltp test:&#xA;&#xA;BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0&#xA;Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206&#xA;&#xA;CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+&#xA;Workqueue: pdecrypt_parallel padata_parallel_worker&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;dump_stack_lvl+0x32/0x50&#xA;print_address_description.constprop.0+0x6b/0x3d0&#xA;print_report+0xdd/0x2c0&#xA;kasan_report+0xa5/0xd0&#xA;padata_find_next+0x29/0x1a0&#xA;padata_reorder+0x131/0x220&#xA;padata_parallel_worker+0x3d/0xc0&#xA;process_one_work+0x2ec/0x5a0&#xA;&#xA;If &#39;mdelay(10)&#39; is added before calling &#39;padata_find_next&#39; in the&#xA;&#39;padata_reorder&#39; function, this issue could be reproduced easily with&#xA;ltp test (pcrypt_aead01).&#xA;&#xA;This can be explained as bellow:&#xA;&#xA;pcrypt_aead_encrypt&#xA;...&#xA;padata_do_parallel&#xA;refcount_inc(&amp;pd-&gt;refcnt); // add refcnt&#xA;...&#xA;padata_do_serial&#xA;padata_reorder // pd&#xA;while (1) {&#xA;padata_find_next(pd, true); // using pd&#xA;queue_work_on&#xA;...&#xA;padata_serial_worker&#x9;&#x9;&#x9;&#x9;crypto_del_alg&#xA;padata_put_pd_cnt // sub refcnt&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;padata_free_shell&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;padata_put_pd(ps-&gt;pd);&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// pd is freed&#xA;// loop again, but pd is freed&#xA;// call padata_find_next, UAF&#xA;}&#xA;&#xA;In the padata_reorder function, when it loops in &#39;while&#39;, if the alg is&#xA;deleted, the refcnt may be decreased to 0 before entering&#xA;&#39;padata_find_next&#39;, which leads to UAF.&#xA;&#xA;As mentioned in [1], do_serial is supposed to be called with BHs disabled&#xA;and always happen under RCU protection, to address this issue, add&#xA;synchronize_rcu() in &#39;padata_free_shell&#39; wait for all _do_serial calls&#xA;to finish.&#xA;&#xA;[1] https://lore.kernel.org/all/[email protected]/&#xA;[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/&#xA;CVE-2025-21781:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;batman-adv: fix panic during interface removal&#xA;&#xA;Reference counting is used to ensure that&#xA;batadv_hardif_neigh_node and batadv_hard_iface&#xA;are not freed before/during&#xA;batadv_v_elp_throughput_metric_update work is&#xA;finished.&#xA;&#xA;But there isn&#39;t a guarantee that the hard if will&#xA;remain associated with a soft interface up until&#xA;the work is finished.&#xA;&#xA;This fixes a crash triggered by reboot that looks&#xA;like this:&#xA;&#xA;Call trace:&#xA; batadv_v_mesh_free+0xd0/0x4dc [batman_adv]&#xA; batadv_v_elp_throughput_metric_update+0x1c/0xa4&#xA; process_one_work+0x178/0x398&#xA; worker_thread+0x2e8/0x4d0&#xA; kthread+0xd8/0xdc&#xA; ret_from_fork+0x10/0x20&#xA;&#xA;(the batadv_v_mesh_free call is misleading,&#xA;and does not actually happen)&#xA;&#xA;I was able to make the issue happen more reliably&#xA;by changing hardif_neigh-&gt;bat_v.metric_work work&#xA;to be delayed work. This allowed me to track down&#xA;and confirm the fix.&#xA;&#xA;[[email protected]: prevent entering batadv_v_elp_get_throughput without&#xA; soft_iface]&#xA;CVE-2025-21791:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vrf: use RCU protection in l3mdev_l3_out()&#xA;&#xA;l3mdev_l3_out() can be called without RCU being held:&#xA;&#xA;raw_sendmsg()&#xA; ip_push_pending_frames()&#xA;  ip_send_skb()&#xA;   ip_local_out()&#xA;    __ip_local_out()&#xA;     l3mdev_ip_out()&#xA;&#xA;Add rcu_read_lock() / rcu_read_unlock() pair to avoid&#xA;a potential UAF.&#xA;CVE-2025-21816:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING&#xA;&#xA;hrtimers are migrated away from the dying CPU to any online target at&#xA;the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers&#xA;handling tasks involved in the CPU hotplug forward progress.&#xA;&#xA;However wakeups can still be performed by the outgoing CPU after&#xA;CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being&#xA;armed. Depending on several considerations (crystal ball power management&#xA;based election, earliest timer already enqueued, timer migration enabled or&#xA;not), the target may eventually be the current CPU even if offline. If that&#xA;happens, the timer is eventually ignored.&#xA;&#xA;The most notable example is RCU which had to deal with each and every of&#xA;those wake-ups by deferring them to an online CPU, along with related&#xA;workarounds:&#xA;&#xA;_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)&#xA;_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)&#xA;_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)&#xA;&#xA;The problem isn&#39;t confined to RCU though as the stop machine kthread&#xA;(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end&#xA;of its work through cpu_stop_signal_done() and performs a wake up that&#xA;eventually arms the deadline server timer:&#xA;&#xA;   WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0&#xA;   CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted&#xA;   Stopper: multi_cpu_stop+0x0/0x120 &lt;- stop_machine_cpuslocked+0x66/0xc0&#xA;   RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0&#xA;   Call Trace:&#xA;   &lt;TASK&gt;&#xA;     start_dl_timer&#xA;     enqueue_dl_entity&#xA;     dl_server_start&#xA;     enqueue_task_fair&#xA;     enqueue_task&#xA;     ttwu_do_activate&#xA;     try_to_wake_up&#xA;     complete&#xA;     cpu_stopper_thread&#xA;&#xA;Instead of providing yet another bandaid to work around the situation, fix&#xA;it in the hrtimers infrastructure instead: always migrate away a timer to&#xA;an online target whenever it is enqueued from an offline CPU.&#xA;&#xA;This will also allow to revert all the above RCU disgraceful hacks.&#xA;CVE-2025-21823:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;batman-adv: Drop unmanaged ELP metric worker&#xA;&#xA;The ELP worker needs to calculate new metric values for all neighbors&#xA;&#34;reachable&#34; over an interface. Some of the used metric sources require&#xA;locks which might need to sleep. This sleep is incompatible with the RCU&#xA;list iterator used for the recorded neighbors. The initial approach to work&#xA;around of this problem was to queue another work item per neighbor and then&#xA;run this in a new context.&#xA;&#xA;Even when this solved the RCU vs might_sleep() conflict, it has a major&#xA;problems: Nothing was stopping the work item in case it is not needed&#xA;anymore - for example because one of the related interfaces was removed or&#xA;the batman-adv module was unloaded - resulting in potential invalid memory&#xA;accesses.&#xA;&#xA;Directly canceling the metric worker also has various problems:&#xA;&#xA;* cancel_work_sync for a to-be-deactivated interface is called with&#xA;  rtnl_lock held. But the code in the ELP metric worker also tries to use&#xA;  rtnl_lock() - which will never return in this case. This also means that&#xA;  cancel_work_sync would never return because it is waiting for the worker&#xA;  to finish.&#xA;* iterating over the neighbor list for the to-be-deactivated interface is&#xA;  currently done using the RCU specific methods. Which means that it is&#xA;  possible to miss items when iterating over it without the associated&#xA;  spinlock - a behaviour which is acceptable for a periodic metric check&#xA;  but not for a cleanup routine (which must &#34;stop&#34; all still running&#xA;  workers)&#xA;&#xA;The better approch is to get rid of the per interface neighbor metric&#xA;worker and handle everything in the interface worker. The original problems&#xA;are solved by:&#xA;&#xA;* creating a list of neighbors which require new metric information inside&#xA;  the RCU protected context, gathering the metric according to the new list&#xA;  outside the RCU protected context&#xA;* only use rcu_trylock inside metric gathering code to avoid a deadlock&#xA;  when the cancel_delayed_work_sync is called in the interface removal code&#xA;  (which is called with the rtnl_lock held)&#xA;CVE-2025-21804:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()&#xA;&#xA;The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()&#xA;macro to request a needed resource. A string variable that lives on the&#xA;stack is then used to store a dynamically computed resource name, which&#xA;is then passed on as one of the macro arguments. This can lead to&#xA;undefined behavior.&#xA;&#xA;Depending on the current contents of the memory, the manifestations of&#xA;errors may vary. One possible output may be as follows:&#xA;&#xA;  $ cat /proc/iomem&#xA;  30000000-37ffffff :&#xA;  38000000-3fffffff :&#xA;&#xA;Sometimes, garbage may appear after the colon.&#xA;&#xA;In very rare cases, if no NULL-terminator is found in memory, the system&#xA;might crash because the string iterator will overrun which can lead to&#xA;access of unmapped memory above the stack.&#xA;&#xA;Thus, fix this by replacing outbound_name with the name of the previously&#xA;requested resource. With the changes applied, the output will be as&#xA;follows:&#xA;&#xA;  $ cat /proc/iomem&#xA;  30000000-37ffffff : memory2&#xA;  38000000-3fffffff : memory3&#xA;&#xA;[kwilczynski: commit log]&#xA;CVE-2024-58055:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: gadget: f_tcm: Don&#39;t free command immediately&#xA;&#xA;Don&#39;t prematurely free the command. Wait for the status completion of&#xA;the sense status. It can be freed then. Otherwise we will double-free&#xA;the command.&#xA;CVE-2025-21881:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;uprobes: Reject the shared zeropage in uprobe_write_opcode()&#xA;&#xA;We triggered the following crash in syzkaller tests:&#xA;&#xA;  BUG: Bad page state in process syz.7.38  pfn:1eff3&#xA;  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3&#xA;  flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)&#xA;  raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000&#xA;  raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000&#xA;  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x32/0x50&#xA;   bad_page+0x69/0xf0&#xA;   free_unref_page_prepare+0x401/0x500&#xA;   free_unref_page+0x6d/0x1b0&#xA;   uprobe_write_opcode+0x460/0x8e0&#xA;   install_breakpoint.part.0+0x51/0x80&#xA;   register_for_each_vma+0x1d9/0x2b0&#xA;   __uprobe_register+0x245/0x300&#xA;   bpf_uprobe_multi_link_attach+0x29b/0x4f0&#xA;   link_create+0x1e2/0x280&#xA;   __sys_bpf+0x75f/0xac0&#xA;   __x64_sys_bpf+0x1a/0x30&#xA;   do_syscall_64+0x56/0x100&#xA;   entry_SYSCALL_64_after_hwframe+0x78/0xe2&#xA;&#xA;   BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1&#xA;&#xA;The following syzkaller test case can be used to reproduce:&#xA;&#xA;  r2 = creat(&amp;(0x7f0000000000)=&#39;./file0\x00&#39;, 0x8)&#xA;  write$nbd(r2, &amp;(0x7f0000000580)=ANY=[], 0x10)&#xA;  r4 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)=&#39;./file0\x00&#39;, 0x42, 0x0)&#xA;  mmap$IORING_OFF_SQ_RING(&amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)&#xA;  r5 = userfaultfd(0x80801)&#xA;  ioctl$UFFDIO_API(r5, 0xc018aa3f, &amp;(0x7f0000000040)={0xaa, 0x20})&#xA;  r6 = userfaultfd(0x80801)&#xA;  ioctl$UFFDIO_API(r6, 0xc018aa3f, &amp;(0x7f0000000140))&#xA;  ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &amp;(0x7f0000000100)={{&amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})&#xA;  ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &amp;(0x7f0000000000)={{&amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})&#xA;  r7 = bpf$PROG_LOAD(0x5, &amp;(0x7f0000000140)={0x2, 0x3, &amp;(0x7f0000000200)=ANY=[@ANYBLOB=&#34;1800000000120000000000000000000095&#34;], &amp;(0x7f0000000000)=&#39;GPL\x00&#39;, 0x7, 0x0, 0x0, 0x0, 0x0, &#39;\x00&#39;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)&#xA;  bpf$BPF_LINK_CREATE_XDP(0x1c, &amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&amp;(0x7f0000000080)=&#39;./file0\x00&#39;, &amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)&#xA;&#xA;The cause is that zero pfn is set to the PTE without increasing the RSS&#xA;count in mfill_atomic_pte_zeropage() and the refcount of zero folio does&#xA;not increase accordingly. Then, the operation on the same pfn is performed&#xA;in uprobe_write_opcode()-&gt;__replace_page() to unconditional decrease the&#xA;RSS count and old_folio&#39;s refcount.&#xA;&#xA;Therefore, two bugs are introduced:&#xA;&#xA; 1. The RSS count is incorrect, when process exit, the check_mm() report&#xA;    error &#34;Bad rss-count&#34;.&#xA;&#xA; 2. The reserved folio (zero folio) is freed when folio-&gt;refcount is zero,&#xA;    then free_pages_prepare-&gt;free_page_is_bad() report error&#xA;    &#34;Bad page state&#34;.&#xA;&#xA;There is more, the following warning could also theoretically be triggered:&#xA;&#xA;  __replace_page()&#xA;    -&gt; ...&#xA;      -&gt; folio_remove_rmap_pte()&#xA;        -&gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)&#xA;&#xA;Considering that uprobe hit on the zero folio is a very rare case, just&#xA;reject zero old folio immediately after get_user_page_vma_remote().&#xA;&#xA;[ mingo: Cleaned up the changelog ]&#xA;CVE-2023-53001:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2025-21943:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;gpio: aggregator: protect driver attr handlers against module unload&#xA;&#xA;Both new_device_store and delete_device_store touch module global&#xA;resources (e.g. gpio_aggregator_lock). To prevent race conditions with&#xA;module unload, a reference needs to be held.&#xA;&#xA;Add try_module_get() in these handlers.&#xA;&#xA;For new_device_store, this eliminates what appears to be the most dangerous&#xA;scenario: if an id is allocated from gpio_aggregator_idr but&#xA;platform_device_register has not yet been called or completed, a concurrent&#xA;module unload could fail to unregister/delete the device, leaving behind a&#xA;dangling platform device/GPIO forwarder. This can result in various issues.&#xA;The following simple reproducer demonstrates these problems:&#xA;&#xA;  #!/bin/bash&#xA;  while :; do&#xA;    # note: whether &#39;gpiochip0 0&#39; exists or not does not matter.&#xA;    echo &#39;gpiochip0 0&#39; &gt; /sys/bus/platform/drivers/gpio-aggregator/new_device&#xA;  done &amp;&#xA;  while :; do&#xA;    modprobe gpio-aggregator&#xA;    modprobe -r gpio-aggregator&#xA;  done &amp;&#xA;  wait&#xA;&#xA;  Starting with the following warning, several kinds of warnings will appear&#xA;  and the system may become unstable:&#xA;&#xA;  ------------[ cut here ]------------&#xA;  list_del corruption, ffff888103e2e980-&gt;next is LIST_POISON1 (dead000000000100)&#xA;  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120&#xA;  [...]&#xA;  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120&#xA;  [...]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? __list_del_entry_valid_or_report+0xa3/0x120&#xA;   ? __warn.cold+0x93/0xf2&#xA;   ? __list_del_entry_valid_or_report+0xa3/0x120&#xA;   ? report_bug+0xe6/0x170&#xA;   ? __irq_work_queue_local+0x39/0xe0&#xA;   ? handle_bug+0x58/0x90&#xA;   ? exc_invalid_op+0x13/0x60&#xA;   ? asm_exc_invalid_op+0x16/0x20&#xA;   ? __list_del_entry_valid_or_report+0xa3/0x120&#xA;   gpiod_remove_lookup_table+0x22/0x60&#xA;   new_device_store+0x315/0x350 [gpio_aggregator]&#xA;   kernfs_fop_write_iter+0x137/0x1f0&#xA;   vfs_write+0x262/0x430&#xA;   ksys_write+0x60/0xd0&#xA;   do_syscall_64+0x6c/0x180&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;   [...]&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;CVE-2025-22035:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Fix use-after-free in print_graph_function_flags during tracer switching&#xA;&#xA;Kairui reported a UAF issue in print_graph_function_flags() during&#xA;ftrace stress testing [1]. This issue can be reproduced if puting a&#xA;&#39;mdelay(10)&#39; after &#39;mutex_unlock(&amp;trace_types_lock)&#39; in s_start(),&#xA;and executing the following script:&#xA;&#xA;  $ echo function_graph &gt; current_tracer&#xA;  $ cat trace &gt; /dev/null &amp;&#xA;  $ sleep 5  # Ensure the &#39;cat&#39; reaches the &#39;mdelay(10)&#39; point&#xA;  $ echo timerlat &gt; current_tracer&#xA;&#xA;The root cause lies in the two calls to print_graph_function_flags&#xA;within print_trace_line during each s_show():&#xA;&#xA;  * One through &#39;iter-&gt;trace-&gt;print_line()&#39;;&#xA;  * Another through &#39;event-&gt;funcs-&gt;trace()&#39;, which is hidden in&#xA;    print_trace_fmt() before print_trace_line returns.&#xA;&#xA;Tracer switching only updates the former, while the latter continues&#xA;to use the print_line function of the old tracer, which in the script&#xA;above is print_graph_function_flags.&#xA;&#xA;Moreover, when switching from the &#39;function_graph&#39; tracer to the&#xA;&#39;timerlat&#39; tracer, s_start only calls graph_trace_close of the&#xA;&#39;function_graph&#39; tracer to free &#39;iter-&gt;private&#39;, but does not set&#xA;it to NULL. This provides an opportunity for &#39;event-&gt;funcs-&gt;trace()&#39;&#xA;to use an invalid &#39;iter-&gt;private&#39;.&#xA;&#xA;To fix this issue, set &#39;iter-&gt;private&#39; to NULL immediately after&#xA;freeing it in graph_trace_close(), ensuring that an invalid pointer&#xA;is not passed to other tracers. Additionally, clean up the unnecessary&#xA;&#39;iter-&gt;private = NULL&#39; during each &#39;cat trace&#39; when using wakeup and&#xA;irqsoff tracers.&#xA;&#xA; [1] https://lore.kernel.org/all/[email protected]/&#xA;CVE-2021-47660:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix some memory leaks in an error handling path of &#39;log_replay()&#39;&#xA;&#xA;All error handling paths lead to &#39;out&#39; where many resources are freed.&#xA;&#xA;Do it as well here instead of a direct return, otherwise &#39;log&#39;, &#39;ra&#39; and&#xA;&#39;log-&gt;one_page_buf&#39; (at least) will leak.&#xA;CVE-2022-49553:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: validate BOOT sectors_per_clusters&#xA;&#xA;When the NTFS BOOT sectors_per_clusters field is &gt; 0x80, it represents a&#xA;shift value.  Make sure that the shift value is not too large before using&#xA;it (NTFS max cluster size is 2MB).  Return -EVINVAL if it too large.&#xA;&#xA;This prevents negative shift values and shift values that are larger than&#xA;the field size.&#xA;&#xA;Prevents this UBSAN error:&#xA;&#xA; UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16&#xA; shift exponent -192 is negative&#xA;CVE-2025-21722:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nilfs2: do not force clear folio if buffer is referenced&#xA;&#xA;Patch series &#34;nilfs2: protect busy buffer heads from being force-cleared&#34;.&#xA;&#xA;This series fixes the buffer head state inconsistency issues reported by&#xA;syzbot that occurs when the filesystem is corrupted and falls back to&#xA;read-only, and the associated buffer head use-after-free issue.&#xA;&#xA;&#xA;This patch (of 2):&#xA;&#xA;Syzbot has reported that after nilfs2 detects filesystem corruption and&#xA;falls back to read-only, inconsistencies in the buffer state may occur.&#xA;&#xA;One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()&#xA;to set a data or metadata buffer as dirty, but it detects that the buffer&#xA;is not in the uptodate state:&#xA;&#xA; WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520&#xA;  fs/buffer.c:1177&#xA; ...&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598&#xA;  nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73&#xA;  nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344&#xA;  nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218&#xA;  vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257&#xA;  do_mkdirat+0x264/0x3a0 fs/namei.c:4280&#xA;  __do_sys_mkdirat fs/namei.c:4295 [inline]&#xA;  __se_sys_mkdirat fs/namei.c:4293 [inline]&#xA;  __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA;  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;The other is when nilfs_btree_propagate(), which propagates the dirty&#xA;state to the ancestor nodes of a b-tree that point to a dirty buffer,&#xA;detects that the origin buffer is not dirty, even though it should be:&#xA;&#xA; WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089&#xA;  nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089&#xA; ...&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345&#xA;  nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587&#xA;  nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006&#xA;  nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045&#xA;  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]&#xA;  nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]&#xA;  nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115&#xA;  nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479&#xA;  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]&#xA;  nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701&#xA;  kthread+0x2f0/0x390 kernel/kthread.c:389&#xA;  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;  &lt;/TASK&gt;&#xA;&#xA;Both of these issues are caused by the callbacks that handle the&#xA;page/folio write requests, forcibly clear various states, including the&#xA;working state of the buffers they hold, at unexpected times when they&#xA;detect read-only fallback.&#xA;&#xA;Fix these issues by checking if the buffer is referenced before clearing&#xA;the page/folio state, and skipping the clear if it is.&#xA;CVE-2025-21785:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array&#xA;&#xA;The loop that detects/populates cache information already has a bounds&#xA;check on the array size but does not account for cache levels with&#xA;separate data/instructions cache. Fix this by incrementing the index&#xA;for any populated leaf (instead of any populated level).&#xA;CVE-2025-21863:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;io_uring: prevent opcode speculation&#xA;&#xA;sqe-&gt;opcode is used for different tables, make sure we santitise it&#xA;against speculations.&#xA;CVE-2025-21887:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up&#xA;&#xA;The issue was caused by dput(upper) being called before&#xA;ovl_dentry_update_reval(), while upper-&gt;d_flags was still&#xA;accessed in ovl_dentry_remote().&#xA;&#xA;Move dput(upper) after its last use to prevent use-after-free.&#xA;&#xA;BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]&#xA;BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167&#xA;&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0xc3/0x620 mm/kasan/report.c:488&#xA; kasan_report+0xd9/0x110 mm/kasan/report.c:601&#xA; ovl_dentry_remote fs/overlayfs/util.c:162 [inline]&#xA; ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167&#xA; ovl_link_up fs/overlayfs/copy_up.c:610 [inline]&#xA; ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170&#xA; ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223&#xA; ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136&#xA; vfs_rename+0xf84/0x20a0 fs/namei.c:4893&#xA;...&#xA; &lt;/TASK&gt;&#xA;CVE-2022-49711:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()&#xA;&#xA;In fsl_mc_bus_remove(), mc-&gt;root_mc_bus_dev-&gt;mc_io is passed to&#xA;fsl_destroy_mc_io(). However, mc-&gt;root_mc_bus_dev is already freed in&#xA;fsl_mc_device_remove(). Then reference to mc-&gt;root_mc_bus_dev-&gt;mc_io&#xA;triggers KASAN use-after-free. To avoid the use-after-free, keep the&#xA;reference to mc-&gt;root_mc_bus_dev-&gt;mc_io in a local variable and pass to&#xA;fsl_destroy_mc_io().&#xA;&#xA;This patch needs rework to apply to kernels older than v5.15.&#xA;CVE-2022-49444:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;module: fix [e_shstrndx].sh_size=0 OOB access&#xA;&#xA;It is trivial to craft a module to trigger OOB access in this line:&#xA;&#xA;&#x9;if (info-&gt;secstrings[strhdr-&gt;sh_size - 1] != &#39;\0&#39;) {&#xA;&#xA;BUG: unable to handle page fault for address: ffffc90000aa0fff&#xA;PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0&#xA;Oops: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014&#xA;RIP: 0010:load_module+0x19b/0x2391&#xA;&#xA;[rebased patch onto modules-next]&#xA;CVE-2024-54680:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-57947:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_set_pipapo: fix initial map fill&#xA;&#xA;The initial buffer has to be inited to all-ones, but it must restrict&#xA;it to the size of the first field, not the total field size.&#xA;&#xA;After each round in the map search step, the result and the fill map&#xA;are swapped, so if we have a set where f-&gt;bsize of the first element&#xA;is smaller than m-&gt;bsize_max, those one-bits are leaked into future&#xA;rounds result map.&#xA;&#xA;This makes pipapo find an incorrect matching results for sets where&#xA;first field size is not the largest.&#xA;&#xA;Followup patch adds a test case to nft_concat_range.sh selftest script.&#xA;&#xA;Thanks to Stefano Brivio for pointing out that we need to zero out&#xA;the remainder explicitly, only correcting memset() argument isn&#39;t enough.&#xA;CVE-2022-49564:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: qat - add param check for DH&#xA;&#xA;Reject requests with a source buffer that is bigger than the size of the&#xA;key. This is to prevent a possible integer underflow that might happen&#xA;when copying the source scatterlist into a linear buffer.&#xA;CVE-2022-49651:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;srcu: Tighten cleanup_srcu_struct() GP checks&#xA;&#xA;Currently, cleanup_srcu_struct() checks for a grace period in progress,&#xA;but it does not check for a grace period that has not yet started but&#xA;which might start at any time.  Such a situation could result in a&#xA;use-after-free bug, so this commit adds a check for a grace period that&#xA;is needed but not yet started to cleanup_srcu_struct().&#xA;CVE-2022-49096:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sfc: add missing xdp queue reinitialization&#xA;&#xA;After rx/tx ring buffer size is changed, kernel panic occurs when&#xA;it acts XDP_TX or XDP_REDIRECT.&#xA;&#xA;When tx/rx ring buffer size is changed(ethtool -G), sfc driver&#xA;reallocates and reinitializes rx and tx queues and their buffer&#xA;(tx_queue-&gt;buffer).&#xA;But it misses reinitializing xdp queues(efx-&gt;xdp_tx_queues).&#xA;So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized&#xA;tx_queue-&gt;buffer.&#xA;&#xA;A new function efx_set_xdp_channels() is separated from efx_set_channels()&#xA;to handle only xdp queues.&#xA;&#xA;Splat looks like:&#xA;   BUG: kernel NULL pointer dereference, address: 000000000000002a&#xA;   #PF: supervisor write access in kernel mode&#xA;   #PF: error_code(0x0002) - not-present page&#xA;   PGD 0 P4D 0&#xA;   Oops: 0002 [#4] PREEMPT SMP NOPTI&#xA;   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]&#xA;   CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D           5.17.0+ #55 e8beeee8289528f11357029357cf&#xA;   Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80&#xA;   RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297&#xA;   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]&#xA;   RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870&#xA;   RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0&#xA;   RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000&#xA;   R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040&#xA;   R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0&#xA;   FS:  0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000&#xA;   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;   Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80&#xA;   CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0&#xA;   RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297&#xA;   PKRU: 55555554&#xA;   RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870&#xA;   RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700&#xA;   RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000&#xA;   R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040&#xA;   R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700&#xA;   FS:  0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000&#xA;   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;   CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0&#xA;   PKRU: 55555554&#xA;   Call Trace:&#xA;    &lt;IRQ&gt;&#xA;    efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]&#xA;    __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]&#xA;    efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]&#xA;    efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]&#xA;    ? enqueue_task_fair+0x95/0x550&#xA;    efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]&#xA;CVE-2022-49266:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;block: fix rq-qos breakage from skipping rq_qos_done_bio()&#xA;&#xA;a647a524a467 (&#34;block: don&#39;t call rq_qos_ops-&gt;done_bio if the bio isn&#39;t&#xA;tracked&#34;) made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set.&#xA;While this fixed a potential oops, it also broke blk-iocost by skipping the&#xA;done_bio callback for merged bios.&#xA;&#xA;Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(),&#xA;rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED&#xA;distinguishing the former from the latter. rq_qos_done_bio() is not called&#xA;for bios which wenth through rq_qos_merge(). This royally confuses&#xA;blk-iocost as the merged bios never finish and are considered perpetually&#xA;in-flight.&#xA;&#xA;One reliably reproducible failure mode is an intermediate cgroup geting&#xA;stuck active preventing its children from being activated due to the&#xA;leaf-only rule, leading to loss of control. The following is from&#xA;resctl-bench protection scenario which emulates isolating a web server like&#xA;workload from a memory bomb run on an iocost configuration which should&#xA;yield a reasonable level of protection.&#xA;&#xA;  # cat /sys/block/nvme2n1/device/model&#xA;  Samsung SSD 970 PRO 512GB&#xA;  # cat /sys/fs/cgroup/io.cost.model&#xA;  259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025&#xA;  # cat /sys/fs/cgroup/io.cost.qos&#xA;  259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00&#xA;  # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1&#xA;  ...&#xA;  Memory Hog Summary&#xA;  ==================&#xA;&#xA;  IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m&#xA;              W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m&#xA;&#xA;  Isolation and Request Latency Impact Distributions:&#xA;&#xA;                min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev&#xA;  isol%       15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82&#xA;  lat-imp%        0     0     0     0     0  4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6&#xA;&#xA;  Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96%&#xA;&#xA;The isolation result of 58.12% is close to what this device would show&#xA;without any IO control.&#xA;&#xA;Fix it by introducing a new flag BIO_QOS_MERGED to mark merged bios and&#xA;calling rq_qos_done_bio() on them too. For consistency and clarity, rename&#xA;BIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved into&#xA;rq_qos_done_bio() so that it&#39;s next to the code paths that set the flags.&#xA;&#xA;With the patch applied, the above same benchmark shows:&#xA;&#xA;  # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1&#xA;  ...&#xA;  Memory Hog Summary&#xA;  ==================&#xA;&#xA;  IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m&#xA;              W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m&#xA;&#xA;  Isolation and Request Latency Impact Distributions:&#xA;&#xA;                min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev&#xA;  isol%       84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42  2.81&#xA;  lat-imp%        0     0     0     0     0  2.81  5.73 11.11 13.92 17.53 22.61  4.10  4.68&#xA;&#xA;  Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0%&#xA;CVE-2025-21719:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipmr: do not call mr_mfc_uses_dev() for unres entries&#xA;&#xA;syzbot found that calling mr_mfc_uses_dev() for unres entries&#xA;would crash [1], because c-&gt;mfc_un.res.minvif / c-&gt;mfc_un.res.maxvif&#xA;alias to &#34;struct sk_buff_head unresolved&#34;, which contain two pointers.&#xA;&#xA;This code never worked, lets remove it.&#xA;&#xA;[1]&#xA;Unable to handle kernel paging request at virtual address ffff5fff2d536613&#xA;KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]&#xA;Modules linked in:&#xA;CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]&#xA; pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334&#xA; lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]&#xA; lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334&#xA;Call trace:&#xA;  mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)&#xA;  mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)&#xA;  mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382&#xA;  ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648&#xA;  rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327&#xA;  rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791&#xA;  netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317&#xA;  netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973&#xA;  sock_recvmsg_nosec net/socket.c:1033 [inline]&#xA;  sock_recvmsg net/socket.c:1055 [inline]&#xA;  sock_read_iter+0x2d8/0x40c net/socket.c:1125&#xA;  new_sync_read fs/read_write.c:484 [inline]&#xA;  vfs_read+0x740/0x970 fs/read_write.c:565&#xA;  ksys_read+0x15c/0x26c fs/read_write.c:708&#xA;CVE-2025-21782:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;orangefs: fix a oob in orangefs_debug_write&#xA;&#xA;I got a syzbot report: slab-out-of-bounds Read in&#xA;orangefs_debug_write... several people suggested fixes,&#xA;I tested Al Viro&#39;s suggestion and made this patch.&#xA;CVE-2024-58009:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc&#xA;&#xA;A NULL sock pointer is passed into l2cap_sock_alloc() when it is called&#xA;from l2cap_sock_new_connection_cb() and the error handling paths should&#xA;also be aware of it.&#xA;&#xA;Seemingly a more elegant solution would be to swap bt_sock_alloc() and&#xA;l2cap_chan_create() calls since they are not interdependent to that moment&#xA;but then l2cap_chan_create() adds the soon to be deallocated and still&#xA;dummy-initialized channel to the global list accessible by many L2CAP&#xA;paths. The channel would be removed from the list in short period of time&#xA;but be a bit more straight-forward here and just check for NULL instead of&#xA;changing the order of function calls.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE static&#xA;analysis tool.&#xA;CVE-2025-21756:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vsock: Keep the binding until socket destruction&#xA;&#xA;Preserve sockets bindings; this includes both resulting from an explicit&#xA;bind() and those implicitly bound through autobind during connect().&#xA;&#xA;Prevents socket unbinding during a transport reassignment, which fixes a&#xA;use-after-free:&#xA;&#xA;    1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)&#xA;    2. transport-&gt;release() calls vsock_remove_bound() without checking if&#xA;       sk was bound and moved to bound list (refcnt=1)&#xA;    3. vsock_bind() assumes sk is in unbound list and before&#xA;       __vsock_insert_bound(vsock_bound_sockets()) calls&#xA;       __vsock_remove_bound() which does:&#xA;           list_del_init(&amp;vsk-&gt;bound_table); // nop&#xA;           sock_put(&amp;vsk-&gt;sk);               // refcnt=0&#xA;&#xA;BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730&#xA;Read of size 4 at addr ffff88816b46a74c by task a.out/2057&#xA; dump_stack_lvl+0x68/0x90&#xA; print_report+0x174/0x4f6&#xA; kasan_report+0xb9/0x190&#xA; __vsock_bind+0x62e/0x730&#xA; vsock_bind+0x97/0xe0&#xA; __sys_bind+0x154/0x1f0&#xA; __x64_sys_bind+0x6e/0xb0&#xA; do_syscall_64+0x93/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Allocated by task 2057:&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_save_track+0x10/0x30&#xA; __kasan_slab_alloc+0x85/0x90&#xA; kmem_cache_alloc_noprof+0x131/0x450&#xA; sk_prot_alloc+0x5b/0x220&#xA; sk_alloc+0x2c/0x870&#xA; __vsock_create.constprop.0+0x2e/0xb60&#xA; vsock_create+0xe4/0x420&#xA; __sock_create+0x241/0x650&#xA; __sys_socket+0xf2/0x1a0&#xA; __x64_sys_socket+0x6e/0xb0&#xA; do_syscall_64+0x93/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Freed by task 2057:&#xA; kasan_save_stack+0x1e/0x40&#xA; kasan_save_track+0x10/0x30&#xA; kasan_save_free_info+0x37/0x60&#xA; __kasan_slab_free+0x4b/0x70&#xA; kmem_cache_free+0x1a1/0x590&#xA; __sk_destruct+0x388/0x5a0&#xA; __vsock_bind+0x5e1/0x730&#xA; vsock_bind+0x97/0xe0&#xA; __sys_bind+0x154/0x1f0&#xA; __x64_sys_bind+0x6e/0xb0&#xA; do_syscall_64+0x93/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150&#xA;RIP: 0010:refcount_warn_saturate+0xce/0x150&#xA; __vsock_bind+0x66d/0x730&#xA; vsock_bind+0x97/0xe0&#xA; __sys_bind+0x154/0x1f0&#xA; __x64_sys_bind+0x6e/0xb0&#xA; do_syscall_64+0x93/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;refcount_t: underflow; use-after-free.&#xA;WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150&#xA;RIP: 0010:refcount_warn_saturate+0xee/0x150&#xA; vsock_remove_bound+0x187/0x1e0&#xA; __vsock_release+0x383/0x4a0&#xA; vsock_release+0x90/0x120&#xA; __sock_release+0xa3/0x250&#xA; sock_close+0x14/0x20&#xA; __fput+0x359/0xa80&#xA; task_work_run+0x107/0x1d0&#xA; do_exit+0x847/0x2560&#xA; do_group_exit+0xb8/0x250&#xA; __x64_sys_exit_group+0x3a/0x50&#xA; x64_sys_call+0xfec/0x14f0&#xA; do_syscall_64+0x93/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2025-21779:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86: Reject Hyper-V&#39;s SEND_IPI hypercalls if local APIC isn&#39;t in-kernel&#xA;&#xA;Advertise support for Hyper-V&#39;s SEND_IPI and SEND_IPI_EX hypercalls if and&#xA;only if the local API is emulated/virtualized by KVM, and explicitly reject&#xA;said hypercalls if the local APIC is emulated in userspace, i.e. don&#39;t rely&#xA;on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.&#xA;&#xA;Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if&#xA;Hyper-V enlightenments are exposed to the guest without an in-kernel local&#xA;APIC:&#xA;&#xA;  dump_stack+0xbe/0xfd&#xA;  __kasan_report.cold+0x34/0x84&#xA;  kasan_report+0x3a/0x50&#xA;  __apic_accept_irq+0x3a/0x5c0&#xA;  kvm_hv_send_ipi.isra.0+0x34e/0x820&#xA;  kvm_hv_hypercall+0x8d9/0x9d0&#xA;  kvm_emulate_hypercall+0x506/0x7e0&#xA;  __vmx_handle_exit+0x283/0xb60&#xA;  vmx_handle_exit+0x1d/0xd0&#xA;  vcpu_enter_guest+0x16b0/0x24c0&#xA;  vcpu_run+0xc0/0x550&#xA;  kvm_arch_vcpu_ioctl_run+0x170/0x6d0&#xA;  kvm_vcpu_ioctl+0x413/0xb20&#xA;  __se_sys_ioctl+0x111/0x160&#xA;  do_syscal1_64+0x30/0x40&#xA;  entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;&#xA;Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode&#xA;can&#39;t be modified after vCPUs are created, i.e. if one vCPU has an&#xA;in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&#xA;CVE-2024-58001:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: handle a symlink read error correctly&#xA;&#xA;Patch series &#34;Convert ocfs2 to use folios&#34;.&#xA;&#xA;Mark did a conversion of ocfs2 to use folios and sent it to me as a&#xA;giant patch for review ;-)&#xA;&#xA;So I&#39;ve redone it as individual patches, and credited Mark for the patches&#xA;where his code is substantially the same.  It&#39;s not a bad way to do it;&#xA;his patch had some bugs and my patches had some bugs.  Hopefully all our&#xA;bugs were different from each other.  And hopefully Mark likes all the&#xA;changes I made to his code!&#xA;&#xA;&#xA;This patch (of 23):&#xA;&#xA;If we can&#39;t read the buffer, be sure to unlock the page before returning.&#xA;CVE-2025-21735:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFC: nci: Add bounds checking in nci_hci_create_pipe()&#xA;&#xA;The &#34;pipe&#34; variable is a u8 which comes from the network.  If it&#39;s more&#xA;than 127, then it results in memory corruption in the caller,&#xA;nci_hci_connect_gate().&#xA;CVE-2025-21802:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hns3: fix oops when unload drivers paralleling&#xA;&#xA;When unload hclge driver, it tries to disable sriov first for each&#xA;ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at&#xA;the time, because it removes all the ae_dev nodes, and it may cause&#xA;oops.&#xA;&#xA;But we can&#39;t simply use hnae3_common_lock for this. Because in the&#xA;process flow of pci_disable_sriov(), it will trigger the remove flow&#xA;of VF, which will also take hnae3_common_lock.&#xA;&#xA;To fixes it, introduce a new mutex to protect the unload process.&#xA;CVE-2024-56606:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;af_packet: avoid erroring out after sock_init_data() in packet_create()&#xA;&#xA;After sock_init_data() the allocated sk object is attached to the provided&#xA;sock object. On error, packet_create() frees the sk object leaving the&#xA;dangling pointer in the sock object on return. Some other code may try&#xA;to use this pointer and cause use-after-free.&#xA;CVE-2024-58058:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ubifs: skip dumping tnc tree when zroot is null&#xA;&#xA;Clearing slab cache will free all znode in memory and make&#xA;c-&gt;zroot.znode = NULL, then dumping tnc tree will access&#xA;c-&gt;zroot.znode which cause null pointer dereference.&#xA;CVE-2024-50150:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: altmode should keep reference to parent&#xA;&#xA;The altmode device release refers to its parent device, but without keeping&#xA;a reference to it.&#xA;&#xA;When registering the altmode, get a reference to the parent and put it in&#xA;the release function.&#xA;&#xA;Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues&#xA;like this:&#xA;&#xA;[   43.572860] kobject: &#39;port0.0&#39; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)&#xA;[   43.573532] kobject: &#39;port0.1&#39; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)&#xA;[   43.574407] kobject: &#39;port0&#39; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)&#xA;[   43.575059] kobject: &#39;port1.0&#39; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)&#xA;[   43.575908] kobject: &#39;port1.1&#39; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)&#xA;[   43.576908] kobject: &#39;typec&#39; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)&#xA;[   43.577769] kobject: &#39;port1&#39; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)&#xA;[   46.612867] ==================================================================&#xA;[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129&#xA;[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48&#xA;[   46.614538]&#xA;[   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535&#xA;[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014&#xA;[   46.616042] Workqueue: events kobject_delayed_cleanup&#xA;[   46.616446] Call Trace:&#xA;[   46.616648]  &lt;TASK&gt;&#xA;[   46.616820]  dump_stack_lvl+0x5b/0x7c&#xA;[   46.617112]  ? typec_altmode_release+0x38/0x129&#xA;[   46.617470]  print_report+0x14c/0x49e&#xA;[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69&#xA;[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab&#xA;[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d&#xA;[   46.618807]  ? typec_altmode_release+0x38/0x129&#xA;[   46.619161]  kasan_report+0x8d/0xb4&#xA;[   46.619447]  ? typec_altmode_release+0x38/0x129&#xA;[   46.619809]  ? process_scheduled_works+0x3cb/0x85f&#xA;[   46.620185]  typec_altmode_release+0x38/0x129&#xA;[   46.620537]  ? process_scheduled_works+0x3cb/0x85f&#xA;[   46.620907]  device_release+0xaf/0xf2&#xA;[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a&#xA;[   46.621584]  process_scheduled_works+0x4f6/0x85f&#xA;[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10&#xA;[   46.622353]  ? hlock_class+0x31/0x9a&#xA;[   46.622647]  ? lock_acquired+0x361/0x3c3&#xA;[   46.622956]  ? move_linked_works+0x46/0x7d&#xA;[   46.623277]  worker_thread+0x1ce/0x291&#xA;[   46.623582]  ? __kthread_parkme+0xc8/0xdf&#xA;[   46.623900]  ? __pfx_worker_thread+0x10/0x10&#xA;[   46.624236]  kthread+0x17e/0x190&#xA;[   46.624501]  ? kthread+0xfb/0x190&#xA;[   46.624756]  ? __pfx_kthread+0x10/0x10&#xA;[   46.625015]  ret_from_fork+0x20/0x40&#xA;[   46.625268]  ? __pfx_kthread+0x10/0x10&#xA;[   46.625532]  ret_from_fork_asm+0x1a/0x30&#xA;[   46.625805]  &lt;/TASK&gt;&#xA;[   46.625953]&#xA;[   46.626056] Allocated by task 678:&#xA;[   46.626287]  kasan_save_stack+0x24/0x44&#xA;[   46.626555]  kasan_save_track+0x14/0x2d&#xA;[   46.626811]  __kasan_kmalloc+0x3f/0x4d&#xA;[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0&#xA;[   46.627362]  typec_register_port+0x23/0x491&#xA;[   46.627698]  cros_typec_probe+0x634/0xbb6&#xA;[   46.628026]  platform_probe+0x47/0x8c&#xA;[   46.628311]  really_probe+0x20a/0x47d&#xA;[   46.628605]  device_driver_attach+0x39/0x72&#xA;[   46.628940]  bind_store+0x87/0xd7&#xA;[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218&#xA;[   46.629574]  vfs_write+0x1d6/0x29b&#xA;[   46.629856]  ksys_write+0xcd/0x13b&#xA;[   46.630128]  do_syscall_64+0xd4/0x139&#xA;[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[   46.630820]&#xA;[   46.630946] Freed by task 48:&#xA;[   46.631182]  kasan_save_stack+0x24/0x44&#xA;[   46.631493]  kasan_save_track+0x14/0x2d&#xA;[   46.631799]  kasan_save_free_info+0x3f/0x4d&#xA;[   46.632144]  __kasan_slab_free+0x37/0x45&#xA;[   46.632474]&#xA;---truncated---&#xA;CVE-2024-56650:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: x_tables: fix LED ID check in led_tg_check()&#xA;&#xA;Syzbot has reported the following BUG detected by KASAN:&#xA;&#xA;BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70&#xA;Read of size 1 at addr ffff8881022da0c8 by task repro/5879&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x241/0x360&#xA; ? __pfx_dump_stack_lvl+0x10/0x10&#xA; ? __pfx__printk+0x10/0x10&#xA; ? _printk+0xd5/0x120&#xA; ? __virt_addr_valid+0x183/0x530&#xA; ? __virt_addr_valid+0x183/0x530&#xA; print_report+0x169/0x550&#xA; ? __virt_addr_valid+0x183/0x530&#xA; ? __virt_addr_valid+0x183/0x530&#xA; ? __virt_addr_valid+0x45f/0x530&#xA; ? __phys_addr+0xba/0x170&#xA; ? strlen+0x58/0x70&#xA; kasan_report+0x143/0x180&#xA; ? strlen+0x58/0x70&#xA; strlen+0x58/0x70&#xA; kstrdup+0x20/0x80&#xA; led_tg_check+0x18b/0x3c0&#xA; xt_check_target+0x3bb/0xa40&#xA; ? __pfx_xt_check_target+0x10/0x10&#xA; ? stack_depot_save_flags+0x6e4/0x830&#xA; ? nft_target_init+0x174/0xc30&#xA; nft_target_init+0x82d/0xc30&#xA; ? __pfx_nft_target_init+0x10/0x10&#xA; ? nf_tables_newrule+0x1609/0x2980&#xA; ? nf_tables_newrule+0x1609/0x2980&#xA; ? rcu_is_watching+0x15/0xb0&#xA; ? nf_tables_newrule+0x1609/0x2980&#xA; ? nf_tables_newrule+0x1609/0x2980&#xA; ? __kmalloc_noprof+0x21a/0x400&#xA; nf_tables_newrule+0x1860/0x2980&#xA; ? __pfx_nf_tables_newrule+0x10/0x10&#xA; ? __nla_parse+0x40/0x60&#xA; nfnetlink_rcv+0x14e5/0x2ab0&#xA; ? __pfx_validate_chain+0x10/0x10&#xA; ? __pfx_nfnetlink_rcv+0x10/0x10&#xA; ? __lock_acquire+0x1384/0x2050&#xA; ? netlink_deliver_tap+0x2e/0x1b0&#xA; ? __pfx_lock_release+0x10/0x10&#xA; ? netlink_deliver_tap+0x2e/0x1b0&#xA; netlink_unicast+0x7f8/0x990&#xA; ? __pfx_netlink_unicast+0x10/0x10&#xA; ? __virt_addr_valid+0x183/0x530&#xA; ? __check_object_size+0x48e/0x900&#xA; netlink_sendmsg+0x8e4/0xcb0&#xA; ? __pfx_netlink_sendmsg+0x10/0x10&#xA; ? aa_sock_msg_perm+0x91/0x160&#xA; ? __pfx_netlink_sendmsg+0x10/0x10&#xA; __sock_sendmsg+0x223/0x270&#xA; ____sys_sendmsg+0x52a/0x7e0&#xA; ? __pfx_____sys_sendmsg+0x10/0x10&#xA; __sys_sendmsg+0x292/0x380&#xA; ? __pfx___sys_sendmsg+0x10/0x10&#xA; ? lockdep_hardirqs_on_prepare+0x43d/0x780&#xA; ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10&#xA; ? exc_page_fault+0x590/0x8c0&#xA; ? do_syscall_64+0xb6/0x230&#xA; do_syscall_64+0xf3/0x230&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;...&#xA; &lt;/TASK&gt;&#xA;&#xA;Since an invalid (without &#39;\0&#39; byte at all) byte sequence may be passed&#xA;from userspace, add an extra check to ensure that such a sequence is&#xA;rejected as possible ID and so never passed to &#39;kstrdup()&#39; and further.&#xA;CVE-2024-56754:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: caam - Fix the pointer passed to caam_qi_shutdown()&#xA;&#xA;The type of the last parameter given to devm_add_action_or_reset() is&#xA;&#34;struct caam_drv_private *&#34;, but in caam_qi_shutdown(), it is casted to&#xA;&#34;struct device *&#34;.&#xA;&#xA;Pass the correct parameter to devm_add_action_or_reset() so that the&#xA;resources are released as expected.&#xA;CVE-2024-57792:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;power: supply: gpio-charger: Fix set charge current limits&#xA;&#xA;Fix set charge current limits for devices which allow to set the lowest&#xA;charge current limit to be greater zero. If requested charge current limit&#xA;is below lowest limit, the index equals current_limit_map_size which leads&#xA;to accessing memory beyond allocated memory.&#xA;CVE-2024-57857:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/siw: Remove direct link to net_device&#xA;&#xA;Do not manage a per device direct link to net_device. Rely&#xA;on associated ib_devices net_device management, not doubling&#xA;the effort locally. A badly managed local link to net_device&#xA;was causing a &#39;KASAN: slab-use-after-free&#39; exception during&#xA;siw_query_port() call.&#xA;CVE-2024-57795:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/rxe: Remove the direct link to net_device&#xA;&#xA;The similar patch in siw is in the link:&#xA;https://git.kernel.org/rdma/rdma/c/16b87037b48889&#xA;&#xA;This problem also occurred in RXE. The following analyze this problem.&#xA;In the following Call Traces:&#xA;&#34;&#xA;BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782&#xA;Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295&#xA;&#xA;CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted&#xA;6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0&#xA;Hardware name: Google Compute Engine/Google Compute Engine,&#xA;BIOS Google 09/13/2024&#xA;Workqueue: infiniband ib_cache_event_task&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0x169/0x550 mm/kasan/report.c:488&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA; dev_get_flags+0x188/0x1d0 net/core/dev.c:8782&#xA; rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60&#xA; __ib_query_port drivers/infiniband/core/device.c:2111 [inline]&#xA; ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143&#xA; ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494&#xA; ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568&#xA; process_one_work kernel/workqueue.c:3229 [inline]&#xA; process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310&#xA; worker_thread+0x870/0xd30 kernel/workqueue.c:3391&#xA; kthread+0x2f2/0x390 kernel/kthread.c:389&#xA; ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA; &lt;/TASK&gt;&#xA;&#34;&#xA;&#xA;1). In the link [1],&#xA;&#xA;&#34;&#xA; infiniband syz2: set down&#xA;&#34;&#xA;&#xA;This means that on 839.350575, the event ib_cache_event_task was sent andi&#xA;queued in ib_wq.&#xA;&#xA;2). In the link [1],&#xA;&#xA;&#34;&#xA; team0 (unregistering): Port device team_slave_0 removed&#xA;&#34;&#xA;&#xA;It indicates that before 843.251853, the net device should be freed.&#xA;&#xA;3). In the link [1],&#xA;&#xA;&#34;&#xA; BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0&#xA;&#34;&#xA;&#xA;This means that on 850.559070, this slab-use-after-free problem occurred.&#xA;&#xA;In all, on 839.350575, the event ib_cache_event_task was sent and queued&#xA;in ib_wq,&#xA;&#xA;before 843.251853, the net device veth was freed.&#xA;&#xA;on 850.559070, this event was executed, and the mentioned freed net device&#xA;was called. Thus, the above call trace occurred.&#xA;&#xA;[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000&#xA;CVE-2024-57908:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: imu: kmx61: fix information leak in triggered buffer&#xA;&#xA;The &#39;buffer&#39; local array is used to push data to user space from a&#xA;triggered buffer, but it does not set values for inactive channels, as&#xA;it only uses iio_for_each_active_channel() to assign new values.&#xA;&#xA;Initialize the array to zero before using it to avoid pushing&#xA;uninitialized information to userspace.&#xA;CVE-2024-57912:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: pressure: zpa2326: fix information leak in triggered buffer&#xA;&#xA;The &#39;sample&#39; local struct is used to push data to user space from a&#xA;triggered buffer, but it has a hole between the temperature and the&#xA;timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).&#xA;This hole is never initialized.&#xA;&#xA;Initialize the struct to zero before using it to avoid pushing&#xA;uninitialized information to userspace.&#xA;CVE-2025-21662:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mlx5: Fix variable not being completed when function returns&#xA;&#xA;When cmd_alloc_index(), fails cmd_work_handler() needs&#xA;to complete ent-&gt;slotted before returning early.&#xA;Otherwise the task which issued the command may hang:&#xA;&#xA;   mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry&#xA;   INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.&#xA;         Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1&#xA;   &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA;   kworker/13:2    D    0 4055883      2 0x00000228&#xA;   Workqueue: events mlx5e_tx_dim_work [mlx5_core]&#xA;   Call trace:&#xA;      __switch_to+0xe8/0x150&#xA;      __schedule+0x2a8/0x9b8&#xA;      schedule+0x2c/0x88&#xA;      schedule_timeout+0x204/0x478&#xA;      wait_for_common+0x154/0x250&#xA;      wait_for_completion+0x28/0x38&#xA;      cmd_exec+0x7a0/0xa00 [mlx5_core]&#xA;      mlx5_cmd_exec+0x54/0x80 [mlx5_core]&#xA;      mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]&#xA;      mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]&#xA;      mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]&#xA;      process_one_work+0x1b0/0x448&#xA;      worker_thread+0x54/0x468&#xA;      kthread+0x134/0x138&#xA;      ret_from_fork+0x10/0x18&#xA;CVE-2024-46782:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ila: call nf_unregister_net_hooks() sooner&#xA;&#xA;syzbot found an use-after-free Read in ila_nf_input [1]&#xA;&#xA;Issue here is that ila_xlat_exit_net() frees the rhashtable,&#xA;then call nf_unregister_net_hooks().&#xA;&#xA;It should be done in the reverse way, with a synchronize_rcu().&#xA;&#xA;This is a good match for a pre_exit() method.&#xA;&#xA;[1]&#xA; BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]&#xA; BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]&#xA; BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]&#xA; BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672&#xA;Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16&#xA;&#xA;CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:93 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119&#xA;  print_address_description mm/kasan/report.c:377 [inline]&#xA;  print_report+0x169/0x550 mm/kasan/report.c:488&#xA;  kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA;  rht_key_hashfn include/linux/rhashtable.h:159 [inline]&#xA;  __rhashtable_lookup include/linux/rhashtable.h:604 [inline]&#xA;  rhashtable_lookup include/linux/rhashtable.h:646 [inline]&#xA;  rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672&#xA;  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]&#xA;  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]&#xA;  ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190&#xA;  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA;  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626&#xA;  nf_hook include/linux/netfilter.h:269 [inline]&#xA;  NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312&#xA;  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]&#xA;  __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775&#xA;  process_backlog+0x662/0x15b0 net/core/dev.c:6108&#xA;  __napi_poll+0xcb/0x490 net/core/dev.c:6772&#xA;  napi_poll net/core/dev.c:6841 [inline]&#xA;  net_rx_action+0x89b/0x1240 net/core/dev.c:6963&#xA;  handle_softirqs+0x2c4/0x970 kernel/softirq.c:554&#xA;  run_ksoftirqd+0xca/0x130 kernel/softirq.c:928&#xA;  smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164&#xA;  kthread+0x2f0/0x390 kernel/kthread.c:389&#xA;  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA; &lt;/TASK&gt;&#xA;&#xA;The buggy address belongs to the physical page:&#xA;page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620&#xA;flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)&#xA;page_type: 0xbfffffff(buddy)&#xA;raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000&#xA;raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;page_owner tracks the page as freed&#xA;page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187&#xA;  set_page_owner include/linux/page_owner.h:32 [inline]&#xA;  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493&#xA;  prep_new_page mm/page_alloc.c:1501 [inline]&#xA;  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439&#xA;  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695&#xA;  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]&#xA;  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]&#xA;  ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103&#xA;  __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130&#xA;  __do_kmalloc_node mm/slub.c:4146 [inline]&#xA;  __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164&#xA;  __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650&#xA;  bucket_table_alloc lib/rhashtable.c:186 [inline]&#xA;  rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071&#xA;  ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613&#xA;  ops_ini&#xA;---truncated---&#xA;CVE-2024-47697:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error&#xA;&#xA;Ensure index in rtl2830_pid_filter does not exceed 31 to prevent&#xA;out-of-bounds access.&#xA;&#xA;dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should&#xA;only operate on indices from 0 to 31. If index is 32, it will attempt to&#xA;access a non-existent 33rd bit, leading to out-of-bounds access.&#xA;Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this&#xA;issue.&#xA;CVE-2024-50125:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: SCO: Fix UAF on sco_sock_timeout&#xA;&#xA;conn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock&#xA;so this checks if the conn-&gt;sk is still valid by checking if it part of&#xA;sco_sk_list.&#xA;CVE-2024-50268:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()&#xA;&#xA;The &#34;*cmd&#34; variable can be controlled by the user via debugfs.  That means&#xA;&#34;new_cam&#34; can be as high as 255 while the size of the uc-&gt;updated[] array&#xA;is UCSI_MAX_ALTMODES (30).&#xA;&#xA;The call tree is:&#xA;ucsi_cmd() // val comes from simple_attr_write_xsigned()&#xA;-&gt; ucsi_send_command()&#xA;   -&gt; ucsi_send_command_common()&#xA;      -&gt; ucsi_run_command() // calls ucsi-&gt;ops-&gt;sync_control()&#xA;         -&gt; ucsi_ccg_sync_control()&#xA;CVE-2024-53057:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT&#xA;&#xA;In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed&#xA;to be either root or ingress. This assumption is bogus since it&#39;s valid&#xA;to create egress qdiscs with major handle ffff:&#xA;Budimir Markovic found that for qdiscs like DRR that maintain an active&#xA;class list, it will cause a UAF with a dangling class pointer.&#xA;&#xA;In 066a3b5b2346, the concern was to avoid iterating over the ingress&#xA;qdisc since its parent is itself. The proper fix is to stop when parent&#xA;TC_H_ROOT is reached because the only way to retrieve ingress is when a&#xA;hierarchy which does not contain a ffff: major handle call into&#xA;qdisc_lookup with TC_H_MAJ(TC_H_ROOT).&#xA;&#xA;In the scenario where major ffff: is an egress qdisc in any of the tree&#xA;levels, the updates will also propagate to TC_H_ROOT, which then the&#xA;iteration must stop.&#xA;&#xA;&#xA; net/sched/sch_api.c | 2 +-&#xA; 1 file changed, 1 insertion(+), 1 deletion(-)&#xA;CVE-2024-53096:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm: resolve faulty mmap_region() error path behaviour&#xA;&#xA;The mmap_region() function is somewhat terrifying, with spaghetti-like&#xA;control flow and numerous means by which issues can arise and incomplete&#xA;state, memory leaks and other unpleasantness can occur.&#xA;&#xA;A large amount of the complexity arises from trying to handle errors late&#xA;in the process of mapping a VMA, which forms the basis of recently&#xA;observed issues with resource leaks and observable inconsistent state.&#xA;&#xA;Taking advantage of previous patches in this series we move a number of&#xA;checks earlier in the code, simplifying things by moving the core of the&#xA;logic into a static internal function __mmap_region().&#xA;&#xA;Doing this allows us to perform a number of checks up front before we do&#xA;any real work, and allows us to unwind the writable unmap check&#xA;unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE&#xA;validation unconditionally also.&#xA;&#xA;We move a number of things here:&#xA;&#xA;1. We preallocate memory for the iterator before we call the file-backed&#xA;   memory hook, allowing us to exit early and avoid having to perform&#xA;   complicated and error-prone close/free logic. We carefully free&#xA;   iterator state on both success and error paths.&#xA;&#xA;2. The enclosing mmap_region() function handles the mapping_map_writable()&#xA;   logic early. Previously the logic had the mapping_map_writable() at the&#xA;   point of mapping a newly allocated file-backed VMA, and a matching&#xA;   mapping_unmap_writable() on success and error paths.&#xA;&#xA;   We now do this unconditionally if this is a file-backed, shared writable&#xA;   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however&#xA;   doing so does not invalidate the seal check we just performed, and we in&#xA;   any case always decrement the counter in the wrapper.&#xA;&#xA;   We perform a debug assert to ensure a driver does not attempt to do the&#xA;   opposite.&#xA;&#xA;3. We also move arch_validate_flags() up into the mmap_region()&#xA;   function. This is only relevant on arm64 and sparc64, and the check is&#xA;   only meaningful for SPARC with ADI enabled. We explicitly add a warning&#xA;   for this arch if a driver invalidates this check, though the code ought&#xA;   eventually to be fixed to eliminate the need for this.&#xA;&#xA;With all of these measures in place, we no longer need to explicitly close&#xA;the VMA on error paths, as we place all checks which might fail prior to a&#xA;call to any driver mmap hook.&#xA;&#xA;This eliminates an entire class of errors, makes the code easier to reason&#xA;about and more robust.&#xA;CVE-2024-53141:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: ipset: add missing range check in bitmap_ip_uadt&#xA;&#xA;When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,&#xA;the values of ip and ip_to are slightly swapped. Therefore, the range check&#xA;for ip should be done later, but this part is missing and it seems that the&#xA;vulnerability occurs.&#xA;&#xA;So we should add missing range checks and remove unnecessary range checks.&#xA;CVE-2024-53156:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()&#xA;&#xA;I found the following bug in my fuzzer:&#xA;&#xA;  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51&#xA;  index 255 is out of range for type &#39;htc_endpoint [22]&#39;&#xA;  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;  Workqueue: events request_firmware_work_func&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x180/0x1b0&#xA;   __ubsan_handle_out_of_bounds+0xd4/0x130&#xA;   htc_issue_send.constprop.0+0x20c/0x230&#xA;   ? _raw_spin_unlock_irqrestore+0x3c/0x70&#xA;   ath9k_wmi_cmd+0x41d/0x610&#xA;   ? mark_held_locks+0x9f/0xe0&#xA;   ...&#xA;&#xA;Since this bug has been confirmed to be caused by insufficient verification&#xA;of conn_rsp_epid, I think it would be appropriate to add a range check for&#xA;conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.&#xA;CVE-2024-53148:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;comedi: Flush partial mappings in error case&#xA;&#xA;If some remap_pfn_range() calls succeeded before one failed, we still have&#xA;buffer pages mapped into the userspace page tables when we drop the buffer&#xA;reference with comedi_buf_map_put(bm). The userspace mappings are only&#xA;cleaned up later in the mmap error path.&#xA;&#xA;Fix it by explicitly flushing all mappings in our VMA on the error path.&#xA;&#xA;See commit 79a61cc3fc04 (&#34;mm: avoid leaving partial pfn mappings around in&#xA;error case&#34;).&#xA;CVE-2024-56658:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: defer final &#39;struct net&#39; free in netns dismantle&#xA;&#xA;Ilya reported a slab-use-after-free in dst_destroy [1]&#xA;&#xA;Issue is in xfrm6_net_init() and xfrm4_net_init() :&#xA;&#xA;They copy xfrm[46]_dst_ops_template into net-&gt;xfrm.xfrm[46]_dst_ops.&#xA;&#xA;But net structure might be freed before all the dst callbacks are&#xA;called. So when dst_destroy() calls later :&#xA;&#xA;if (dst-&gt;ops-&gt;destroy)&#xA;    dst-&gt;ops-&gt;destroy(dst);&#xA;&#xA;dst-&gt;ops points to the old net-&gt;xfrm.xfrm[46]_dst_ops, which has been freed.&#xA;&#xA;See a relevant issue fixed in :&#xA;&#xA;ac888d58869b (&#34;net: do not delay dst_entries_add() in dst_release()&#34;)&#xA;&#xA;A fix is to queue the &#39;struct net&#39; to be freed after one&#xA;another cleanup_net() round (and existing rcu_barrier())&#xA;&#xA;[1]&#xA;&#xA;BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)&#xA;Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0&#xA;Dec 03 05:46:18 kernel:&#xA;CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67&#xA;Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA;dump_stack_lvl (lib/dump_stack.c:124)&#xA;print_address_description.constprop.0 (mm/kasan/report.c:378)&#xA;? dst_destroy (net/core/dst.c:112)&#xA;print_report (mm/kasan/report.c:489)&#xA;? dst_destroy (net/core/dst.c:112)&#xA;? kasan_addr_to_slab (mm/kasan/common.c:37)&#xA;kasan_report (mm/kasan/report.c:603)&#xA;? dst_destroy (net/core/dst.c:112)&#xA;? rcu_do_batch (kernel/rcu/tree.c:2567)&#xA;dst_destroy (net/core/dst.c:112)&#xA;rcu_do_batch (kernel/rcu/tree.c:2567)&#xA;? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)&#xA;? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)&#xA;rcu_core (kernel/rcu/tree.c:2825)&#xA;handle_softirqs (kernel/softirq.c:554)&#xA;__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)&#xA;irq_exit_rcu (kernel/softirq.c:651)&#xA;sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA;asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)&#xA;RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)&#xA;Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 &lt;fa&gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90&#xA;RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246&#xA;RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123&#xA;RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d&#xA;R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000&#xA;R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000&#xA;? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)&#xA;? cpuidle_idle_call (kernel/sched/idle.c:186)&#xA;default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)&#xA;cpuidle_idle_call (kernel/sched/idle.c:186)&#xA;? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)&#xA;? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)&#xA;? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)&#xA;? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)&#xA;do_idle (kernel/sched/idle.c:326)&#xA;cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))&#xA;start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)&#xA;? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)&#xA;? soft_restart_cpu (arch/x86/kernel/head_64.S:452)&#xA;common_startup_64 (arch/x86/kernel/head_64.S:414)&#xA; &lt;/TASK&gt;&#xA;Dec 03 05:46:18 kernel:&#xA;Allocated by task 12184:&#xA;kasan_save_stack (mm/kasan/common.c:48)&#xA;kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)&#xA;__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)&#xA;kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)&#xA;copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)&#xA;create_new_namespaces&#xA;---truncated---&#xA;CVE-2024-56600:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: inet6: do not leave a dangling sk pointer in inet6_create()&#xA;&#xA;sock_init_data() attaches the allocated sk pointer to the provided sock&#xA;object. If inet6_create() fails later, the sk object is released, but the&#xA;sock object retains the dangling sk pointer, which may cause use-after-free&#xA;later.&#xA;&#xA;Clear the sock sk pointer on error.&#xA;CVE-2024-56601:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: inet: do not leave a dangling sk pointer in inet_create()&#xA;&#xA;sock_init_data() attaches the allocated sk object to the provided sock&#xA;object. If inet_create() fails later, the sk object is freed, but the&#xA;sock object retains the dangling pointer, which may create use-after-free&#xA;later.&#xA;&#xA;Clear the sk pointer in the sock object on error.&#xA;CVE-2024-57900:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ila: serialize calls to nf_register_net_hooks()&#xA;&#xA;syzbot found a race in ila_add_mapping() [1]&#xA;&#xA;commit 031ae72825ce (&#34;ila: call nf_unregister_net_hooks() sooner&#34;)&#xA;attempted to fix a similar issue.&#xA;&#xA;Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.&#xA;&#xA;Add a mutex to make sure at most one thread is calling nf_register_net_hooks().&#xA;&#xA;[1]&#xA; BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]&#xA; BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604&#xA;Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501&#xA;&#xA;CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA;  __dump_stack lib/dump_stack.c:94 [inline]&#xA;  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA;  print_address_description mm/kasan/report.c:378 [inline]&#xA;  print_report+0xc3/0x620 mm/kasan/report.c:489&#xA;  kasan_report+0xd9/0x110 mm/kasan/report.c:602&#xA;  rht_key_hashfn include/linux/rhashtable.h:159 [inline]&#xA;  __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604&#xA;  rhashtable_lookup include/linux/rhashtable.h:646 [inline]&#xA;  rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]&#xA;  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]&#xA;  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]&#xA;  ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185&#xA;  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA;  nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626&#xA;  nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269&#xA;  NF_HOOK include/linux/netfilter.h:312 [inline]&#xA;  ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309&#xA;  __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672&#xA;  __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785&#xA;  process_backlog+0x443/0x15f0 net/core/dev.c:6117&#xA;  __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883&#xA;  napi_poll net/core/dev.c:6952 [inline]&#xA;  net_rx_action+0xa94/0x1010 net/core/dev.c:7074&#xA;  handle_softirqs+0x213/0x8f0 kernel/softirq.c:561&#xA;  __do_softirq kernel/softirq.c:595 [inline]&#xA;  invoke_softirq kernel/softirq.c:435 [inline]&#xA;  __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662&#xA;  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678&#xA;  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]&#xA;  sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049&#xA;CVE-2025-21647:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sched: sch_cake: add bounds checks to host bulk flow fairness counts&#xA;&#xA;Even though we fixed a logic error in the commit cited below, syzbot&#xA;still managed to trigger an underflow of the per-host bulk flow&#xA;counters, leading to an out of bounds memory access.&#xA;&#xA;To avoid any such logic errors causing out of bounds memory accesses,&#xA;this commit factors out all accesses to the per-host bulk flow counters&#xA;to a series of helpers that perform bounds-checking before any&#xA;increments and decrements. This also has the benefit of improving&#xA;readability by moving the conditional checks for the flow mode into&#xA;these helpers, instead of having them spread out throughout the&#xA;code (which was the cause of the original logic error).&#xA;&#xA;As part of this change, the flow quantum calculation is consolidated&#xA;into a helper function, which means that the dithering applied to the&#xA;ost load scaling is now applied both in the DRR rotation and when a&#xA;sparse flow&#39;s quantum is first initiated. The only user-visible effect&#xA;of this is that the maximum packet size that can be sent while a flow&#xA;stays sparse will now vary with +/- one byte in some cases. This should&#xA;not make a noticeable difference in practice, and thus it&#39;s not worth&#xA;complicating the code to preserve the old behaviour.&#xA;CVE-2025-21648:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: conntrack: clamp maximum hashtable size to INT_MAX&#xA;&#xA;Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it&#xA;is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when&#xA;resizing hashtable because __GFP_NOWARN is unset. See:&#xA;&#xA;  0708a0afe291 (&#34;mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls&#34;)&#xA;&#xA;Note: hashtable resize is only possible from init_netns.&#xA;CVE-2025-21667:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iomap: avoid avoid truncating 64-bit offset to 32 bits&#xA;&#xA;on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a&#xA;32-bit position due to folio_next_index() returning an unsigned long.&#xA;This could lead to an infinite loop when writing to an xfs filesystem.&#xA;CVE-2024-53203:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: fix potential array underflow in ucsi_ccg_sync_control()&#xA;&#xA;The &#34;command&#34; variable can be controlled by the user via debugfs.  The&#xA;worry is that if con_index is zero then &#34;&amp;uc-&gt;ucsi-&gt;connector[con_index&#xA;- 1]&#34; would be an array underflow.&#xA;CVE-2024-49569:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-rdma: unquiesce admin_q before destroy it&#xA;&#xA;Kernel will hang on destroy admin_q while we create ctrl failed, such&#xA;as following calltrace:&#xA;&#xA;PID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: &#34;nvme&#34;&#xA; #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15&#xA; #1 [ff61d23de260fc08] schedule at ffffffff8323c014&#xA; #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1&#xA; #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a&#xA; #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006&#xA; #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce&#xA; #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced&#xA; #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b&#xA; #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362&#xA; #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25&#xA;    RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202&#xA;    RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574&#xA;    RDX: 000000000000012b  RSI: 000055e8122a4d90  RDI: 0000000000000004&#xA;    RBP: 00007ffe2ef079c0   R8: 000000000000012b   R9: 000055e8122a4d90&#xA;    R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000004&#xA;    R13: 000055e8122923c0  R14: 000000000000012b  R15: 00007fda78a54500&#xA;    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b&#xA;&#xA;This due to we have quiesced admi_q before cancel requests, but forgot&#xA;to unquiesce before destroy it, as a result we fail to drain the&#xA;pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here&#xA;try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and&#xA;simplify the code.&#xA;CVE-2024-57849:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;s390/cpum_sf: Handle CPU hotplug remove during sampling&#xA;&#xA;CPU hotplug remove handling triggers the following function&#xA;call sequence:&#xA;&#xA;   CPUHP_AP_PERF_S390_SF_ONLINE  --&gt; s390_pmu_sf_offline_cpu()&#xA;   ...&#xA;   CPUHP_AP_PERF_ONLINE          --&gt; perf_event_exit_cpu()&#xA;&#xA;The s390 CPUMF sampling CPU hotplug handler invokes:&#xA;&#xA; s390_pmu_sf_offline_cpu()&#xA; +--&gt;  cpusf_pmu_setup()&#xA;       +--&gt; setup_pmc_cpu()&#xA;            +--&gt; deallocate_buffers()&#xA;&#xA;This function de-allocates all sampling data buffers (SDBs) allocated&#xA;for that CPU at event initialization. It also clears the&#xA;PMU_F_RESERVED bit. The CPU is gone and can not be sampled.&#xA;&#xA;With the event still being active on the removed CPU, the CPU event&#xA;hotplug support in kernel performance subsystem triggers the&#xA;following function calls on the removed CPU:&#xA;&#xA;  perf_event_exit_cpu()&#xA;  +--&gt; perf_event_exit_cpu_context()&#xA;       +--&gt; __perf_event_exit_context()&#xA;&#x9;    +--&gt; __perf_remove_from_context()&#xA;&#x9;         +--&gt; event_sched_out()&#xA;&#x9;              +--&gt; cpumsf_pmu_del()&#xA;&#x9;                   +--&gt; cpumsf_pmu_stop()&#xA;                                +--&gt; hw_perf_event_update()&#xA;&#xA;to stop and remove the event. During removal of the event, the&#xA;sampling device driver tries to read out the remaining samples from&#xA;the sample data buffers (SDBs). But they have already been freed&#xA;(and may have been re-assigned). This may lead to a use after free&#xA;situation in which case the samples are most likely invalid. In the&#xA;best case the memory has not been reassigned and still contains&#xA;valid data.&#xA;&#xA;Remedy this situation and check if the CPU is still in reserved&#xA;state (bit PMU_F_RESERVED set). In this case the SDBs have not been&#xA;released an contain valid data. This is always the case when&#xA;the event is removed (and no CPU hotplug off occured).&#xA;If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.&#xA;CVE-2024-57887:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm: adv7511: Fix use-after-free in adv7533_attach_dsi()&#xA;&#xA;The host_node pointer was assigned and freed in adv7533_parse_dt(), and&#xA;later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue&#xA;by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()&#xA;in error path of probe() and also in the remove().&#xA;CVE-2024-57893:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: seq: oss: Fix races at processing SysEx messages&#xA;&#xA;OSS sequencer handles the SysEx messages split in 6 bytes packets, and&#xA;ALSA sequencer OSS layer tries to combine those.  It stores the data&#xA;in the internal buffer and this access is racy as of now, which may&#xA;lead to the out-of-bounds access.&#xA;&#xA;As a temporary band-aid fix, introduce a mutex for serializing the&#xA;process of the SysEx message packets.&#xA;CVE-2024-47141:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pinmux: Use sequential access to access desc-&gt;pinmux data&#xA;&#xA;When two client of the same gpio call pinctrl_select_state() for the&#xA;same functionality, we are seeing NULL pointer issue while accessing&#xA;desc-&gt;mux_owner.&#xA;&#xA;Let&#39;s say two processes A, B executing in pin_request() for the same pin&#xA;and process A updates the desc-&gt;mux_usecount but not yet updated the&#xA;desc-&gt;mux_owner while process B see the desc-&gt;mux_usecount which got&#xA;updated by A path and further executes strcmp and while accessing&#xA;desc-&gt;mux_owner it crashes with NULL pointer.&#xA;&#xA;Serialize the access to mux related setting with a mutex lock.&#xA;&#xA;&#x9;cpu0 (process A)&#x9;&#x9;&#x9;cpu1(process B)&#xA;&#xA;pinctrl_select_state() {&#x9;&#x9;  pinctrl_select_state() {&#xA;  pin_request() {&#x9;&#x9;&#x9;&#x9;pin_request() {&#xA;  ...&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9; ....&#xA;    } else {&#xA;         desc-&gt;mux_usecount++;&#xA;    &#x9;&#x9;&#x9;&#x9;&#x9;&#x9;desc-&gt;mux_usecount &amp;&amp; strcmp(desc-&gt;mux_owner, owner)) {&#xA;&#xA;         if (desc-&gt;mux_usecount &gt; 1)&#xA;               return 0;&#xA;         desc-&gt;mux_owner = owner;&#xA;&#xA;  }&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;}&#xA;CVE-2024-57910:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: light: vcnl4035: fix information leak in triggered buffer&#xA;&#xA;The &#39;buffer&#39; local array is used to push data to userspace from a&#xA;triggered buffer, but it does not set an initial value for the single&#xA;data element, which is an u16 aligned to 8 bytes. That leaves at least&#xA;4 bytes uninitialized even after writing an integer value with&#xA;regmap_read().&#xA;&#xA;Initialize the array to zero before using it to avoid pushing&#xA;uninitialized information to userspace.&#xA;CVE-2024-49571:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg&#xA;&#xA;When receiving proposal msg in server, the field iparea_offset&#xA;and the field ipv6_prefixes_cnt in proposal msg are from the&#xA;remote client and can not be fully trusted. Especially the&#xA;field iparea_offset, once exceed the max value, there has the&#xA;chance to access wrong address, and crash may happen.&#xA;&#xA;This patch checks iparea_offset and ipv6_prefixes_cnt before using them.&#xA;CVE-2024-53690:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nilfs2: prevent use of deleted inode&#xA;&#xA;syzbot reported a WARNING in nilfs_rmdir. [1]&#xA;&#xA;Because the inode bitmap is corrupted, an inode with an inode number that&#xA;should exist as a &#34;.nilfs&#34; file was reassigned by nilfs_mkdir for &#34;file0&#34;,&#xA;causing an inode duplication during execution.  And this causes an&#xA;underflow of i_nlink in rmdir operations.&#xA;&#xA;The inode is used twice by the same task to unmount and remove directories&#xA;&#34;.nilfs&#34; and &#34;file0&#34;, it trigger warning in nilfs_rmdir.&#xA;&#xA;Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means&#xA;that this inode has been deleted, and iput is executed to reclaim it.&#xA;&#xA;[1]&#xA;WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342&#xA; vfs_rmdir+0x3a3/0x510 fs/namei.c:4394&#xA; do_rmdir+0x3b5/0x580 fs/namei.c:4453&#xA; __do_sys_rmdir fs/namei.c:4472 [inline]&#xA; __se_sys_rmdir fs/namei.c:4470 [inline]&#xA; __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-50051:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;spi: mpc52xx: Add cancel_work_sync before module remove&#xA;&#xA;If we remove the module which will call mpc52xx_spi_remove&#xA;it will free &#39;ms&#39; through spi_unregister_controller.&#xA;while the work ms-&gt;work will be used. The sequence of operations&#xA;that may lead to a UAF bug.&#xA;&#xA;Fix it by ensuring that the work is canceled before proceeding with&#xA;the cleanup in mpc52xx_spi_remove.&#xA;CVE-2025-21731:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nbd: don&#39;t allow reconnect after disconnect&#xA;&#xA;Following process can cause nbd_config UAF:&#xA;&#xA;1) grab nbd_config temporarily;&#xA;&#xA;2) nbd_genl_disconnect() flush all recv_work() and release the&#xA;initial reference:&#xA;&#xA;  nbd_genl_disconnect&#xA;   nbd_disconnect_and_put&#xA;    nbd_disconnect&#xA;     flush_workqueue(nbd-&gt;recv_workq)&#xA;    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))&#xA;     nbd_config_put&#xA;     -&gt; due to step 1), reference is still not zero&#xA;&#xA;3) nbd_genl_reconfigure() queue recv_work() again;&#xA;&#xA;  nbd_genl_reconfigure&#xA;   config = nbd_get_config_unlocked(nbd)&#xA;   if (!config)&#xA;   -&gt; succeed&#xA;   if (!test_bit(NBD_RT_BOUND, ...))&#xA;   -&gt; succeed&#xA;   nbd_reconnect_socket&#xA;    queue_work(nbd-&gt;recv_workq, &amp;args-&gt;work)&#xA;&#xA;4) step 1) release the reference;&#xA;&#xA;5) Finially, recv_work() will trigger UAF:&#xA;&#xA;  recv_work&#xA;   nbd_config_put(nbd)&#xA;   -&gt; nbd_config is freed&#xA;   atomic_dec(&amp;config-&gt;recv_threads)&#xA;   -&gt; UAF&#xA;&#xA;Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so&#xA;that nbd_genl_reconfigure() will fail.&#xA;CVE-2024-26954:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()&#xA;&#xA;If -&gt;NameOffset of smb2_create_req is smaller than Buffer offset of&#xA;smb2_create_req, slab-out-of-bounds read can happen from smb2_open.&#xA;This patch set the minimum value of the name offset to the buffer offset&#xA;to validate name length of smb2_create_req().&#xA;CVE-2024-26952:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix potencial out-of-bounds when buffer offset is invalid&#xA;&#xA;I found potencial out-of-bounds when buffer offset fields of a few requests&#xA;is invalid. This patch set the minimum value of buffer offset field to&#xA;-&gt;Buffer offset to validate buffer length.&#xA;CVE-2023-52913:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/i915: Fix potential context UAFs&#xA;&#xA;gem_context_register() makes the context visible to userspace, and which&#xA;point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.&#xA;So we need to ensure that nothing uses the ctx ptr after this.  And we&#xA;need to ensure that adding the ctx to the xarray is the *last* thing&#xA;that gem_context_register() does with the ctx pointer.&#xA;&#xA;[tursulin: Stable and fixes tags add/tidy.]&#xA;(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)&#xA;CVE-2024-50194:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64: probes: Fix uprobes for big-endian kernels&#xA;&#xA;The arm64 uprobes code is broken for big-endian kernels as it doesn&#39;t&#xA;convert the in-memory instruction encoding (which is always&#xA;little-endian) into the kernel&#39;s native endianness before analyzing and&#xA;simulating instructions. This may result in a few distinct problems:&#xA;&#xA;* The kernel may may erroneously reject probing an instruction which can&#xA;  safely be probed.&#xA;&#xA;* The kernel may erroneously erroneously permit stepping an&#xA;  instruction out-of-line when that instruction cannot be stepped&#xA;  out-of-line safely.&#xA;&#xA;* The kernel may erroneously simulate instruction incorrectly dur to&#xA;  interpretting the byte-swapped encoding.&#xA;&#xA;The endianness mismatch isn&#39;t caught by the compiler or sparse because:&#xA;&#xA;* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so&#xA;  the compiler and sparse have no idea these contain a little-endian&#xA;  32-bit value. The core uprobes code populates these with a memcpy()&#xA;  which similarly does not handle endianness.&#xA;&#xA;* While the uprobe_opcode_t type is an alias for __le32, both&#xA;  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]&#xA;  to the similarly-named probe_opcode_t, which is an alias for u32.&#xA;  Hence there is no endianness conversion warning.&#xA;&#xA;Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and&#xA;adding the appropriate __le32_to_cpu() conversions prior to consuming&#xA;the instruction encoding. The core uprobes copies these fields as opaque&#xA;ranges of bytes, and so is unaffected by this change.&#xA;&#xA;At the same time, remove MAX_UINSN_BYTES and consistently use&#xA;AARCH64_INSN_SIZE for clarity.&#xA;&#xA;Tested with the following:&#xA;&#xA;| #include &lt;stdio.h&gt;&#xA;| #include &lt;stdbool.h&gt;&#xA;|&#xA;| #define noinline __attribute__((noinline))&#xA;|&#xA;| static noinline void *adrp_self(void)&#xA;| {&#xA;|         void *addr;&#xA;|&#xA;|         asm volatile(&#xA;|         &#34;       adrp    %x0, adrp_self\n&#34;&#xA;|         &#34;       add     %x0, %x0, :lo12:adrp_self\n&#34;&#xA;|         : &#34;=r&#34; (addr));&#xA;| }&#xA;|&#xA;|&#xA;| int main(int argc, char *argv)&#xA;| {&#xA;|         void *ptr = adrp_self();&#xA;|         bool equal = (ptr == adrp_self);&#xA;|&#xA;|         printf(&#34;adrp_self   =&gt; %p\n&#34;&#xA;|                &#34;adrp_self() =&gt; %p\n&#34;&#xA;|                &#34;%s\n&#34;,&#xA;|                adrp_self, ptr, equal ? &#34;EQUAL&#34; : &#34;NOT EQUAL&#34;);&#xA;|&#xA;|         return 0;&#xA;| }&#xA;&#xA;.... where the adrp_self() function was compiled to:&#xA;&#xA;| 00000000004007e0 &lt;adrp_self&gt;:&#xA;|   4007e0:       90000000        adrp    x0, 400000 &lt;__ehdr_start&gt;&#xA;|   4007e4:       911f8000        add     x0, x0, #0x7e0&#xA;|   4007e8:       d65f03c0        ret&#xA;&#xA;Before this patch, the ADRP is not recognized, and is assumed to be&#xA;steppable, resulting in corruption of the result:&#xA;&#xA;| # ./adrp-self&#xA;| adrp_self   =&gt; 0x4007e0&#xA;| adrp_self() =&gt; 0x4007e0&#xA;| EQUAL&#xA;| # echo &#39;p /root/adrp-self:0x007e0&#39; &gt; /sys/kernel/tracing/uprobe_events&#xA;| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable&#xA;| # ./adrp-self&#xA;| adrp_self   =&gt; 0x4007e0&#xA;| adrp_self() =&gt; 0xffffffffff7e0&#xA;| NOT EQUAL&#xA;&#xA;After this patch, the ADRP is correctly recognized and simulated:&#xA;&#xA;| # ./adrp-self&#xA;| adrp_self   =&gt; 0x4007e0&#xA;| adrp_self() =&gt; 0x4007e0&#xA;| EQUAL&#xA;| #&#xA;| # echo &#39;p /root/adrp-self:0x007e0&#39; &gt; /sys/kernel/tracing/uprobe_events&#xA;| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable&#xA;| # ./adrp-self&#xA;| adrp_self   =&gt; 0x4007e0&#xA;| adrp_self() =&gt; 0x4007e0&#xA;| EQUAL&#xA;CVE-2024-50280:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm cache: fix flushing uninitialized delayed_work on cache_ctr error&#xA;&#xA;An unexpected WARN_ON from flush_work() may occur when cache creation&#xA;fails, caused by destroying the uninitialized delayed_work waker in the&#xA;error path of cache_create(). For example, the warning appears on the&#xA;superblock checksum error.&#xA;&#xA;Reproduce steps:&#xA;&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;&#xA;dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34;&#xA;dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct&#xA;dmsetup create cache --table &#34;0 524288 cache /dev/mapper/cmeta \&#xA;/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;&#xA;&#xA;Kernel logs:&#xA;&#xA;(snip)&#xA;WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890&#xA;&#xA;Fix by pulling out the cancel_delayed_work_sync() from the constructor&#39;s&#xA;error path. This patch doesn&#39;t affect the use-after-free fix for&#xA;concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (&#34;dm cache: Fix&#xA;UAF in destroy()&#34;)) as cache_dtr is not changed.&#xA;CVE-2024-56539:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()&#xA;&#xA;Replace one-element array with a flexible-array member in `struct&#xA;mwifiex_ie_types_wildcard_ssid_params` to fix the following warning&#xA;on a MT8173 Chromebook (mt8173-elm-hana):&#xA;&#xA;[  356.775250] ------------[ cut here ]------------&#xA;[  356.784543] memcpy: detected field-spanning write (size 6) of single field &#34;wildcard_ssid_tlv-&gt;ssid&#34; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)&#xA;[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]&#xA;&#xA;The &#34;(size 6)&#34; above is exactly the length of the SSID of the network&#xA;this device was connected to. The source of the warning looks like:&#xA;&#xA;    ssid_len = user_scan_in-&gt;ssid_list[i].ssid_len;&#xA;    [...]&#xA;    memcpy(wildcard_ssid_tlv-&gt;ssid,&#xA;           user_scan_in-&gt;ssid_list[i].ssid, ssid_len);&#xA;&#xA;There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this&#xA;struct, but it already didn&#39;t account for the size of the one-element&#xA;array, so it doesn&#39;t need to be changed.&#xA;CVE-2024-53183:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;um: net: Do not use drvdata in release&#xA;&#xA;The drvdata is not available in release. Let&#39;s just use container_of()&#xA;to get the uml_net instance. Otherwise, removing a network device will&#xA;result in a crash:&#xA;&#xA;RIP: 0033:net_device_release+0x10/0x6f&#xA;RSP: 00000000e20c7c40  EFLAGS: 00010206&#xA;RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0&#xA;RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028&#xA;RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70&#xA;R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000&#xA;R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6&#xA;Kernel panic - not syncing: Segfault with no mm&#xA;CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1&#xA;Workqueue: events mc_work_proc&#xA;Stack:&#xA; 627af028 62c7af00 e20c7c80 60276fcd&#xA; 62778000 603f5820 627af028 00000000&#xA; e20c7cb0 603a2bcd 627af000 62770010&#xA;Call Trace:&#xA; [&lt;60276fcd&gt;] device_release+0x70/0xba&#xA; [&lt;603a2bcd&gt;] kobject_put+0xba/0xe7&#xA; [&lt;60277265&gt;] put_device+0x19/0x1c&#xA; [&lt;60281266&gt;] platform_device_put+0x26/0x29&#xA; [&lt;60281e5f&gt;] platform_device_unregister+0x2c/0x2e&#xA; [&lt;6002ec9c&gt;] net_remove+0x63/0x69&#xA; [&lt;60031316&gt;] ? mconsole_reply+0x0/0x50&#xA; [&lt;600310c8&gt;] mconsole_remove+0x160/0x1cc&#xA; [&lt;60087d40&gt;] ? __remove_hrtimer+0x38/0x74&#xA; [&lt;60087ff8&gt;] ? hrtimer_try_to_cancel+0x8c/0x98&#xA; [&lt;6006b3cf&gt;] ? dl_server_stop+0x3f/0x48&#xA; [&lt;6006b390&gt;] ? dl_server_stop+0x0/0x48&#xA; [&lt;600672e8&gt;] ? dequeue_entities+0x327/0x390&#xA; [&lt;60038fa6&gt;] ? um_set_signals+0x0/0x43&#xA; [&lt;6003070c&gt;] mc_work_proc+0x77/0x91&#xA; [&lt;60057664&gt;] process_scheduled_works+0x1b3/0x2dd&#xA; [&lt;60055f32&gt;] ? assign_work+0x0/0x58&#xA; [&lt;60057f0a&gt;] worker_thread+0x1e9/0x293&#xA; [&lt;6005406f&gt;] ? set_pf_worker+0x0/0x64&#xA; [&lt;6005d65d&gt;] ? arch_local_irq_save+0x0/0x2d&#xA; [&lt;6005d748&gt;] ? kthread_exit+0x0/0x3a&#xA; [&lt;60057d21&gt;] ? worker_thread+0x0/0x293&#xA; [&lt;6005dbf1&gt;] kthread+0x126/0x12b&#xA; [&lt;600219c5&gt;] new_thread_handler+0x85/0xb6&#xA;CVE-2024-53222:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;zram: fix NULL pointer in comp_algorithm_show()&#xA;&#xA;LTP reported a NULL pointer dereference as followed:&#xA;&#xA; CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3&#xA; Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015&#xA; pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : __pi_strcmp+0x24/0x140&#xA; lr : zcomp_available_show+0x60/0x100 [zram]&#xA; sp : ffff800088b93b90&#xA; x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0&#xA; x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000&#xA; x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900&#xA; x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000&#xA; x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA; x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000&#xA; x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280&#xA; x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000&#xA; x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c&#xA; x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000&#xA; Call trace:&#xA;  __pi_strcmp+0x24/0x140&#xA;  comp_algorithm_show+0x40/0x70 [zram]&#xA;  dev_attr_show+0x28/0x80&#xA;  sysfs_kf_seq_show+0x90/0x140&#xA;  kernfs_seq_show+0x34/0x48&#xA;  seq_read_iter+0x1d4/0x4e8&#xA;  kernfs_fop_read_iter+0x40/0x58&#xA;  new_sync_read+0x9c/0x168&#xA;  vfs_read+0x1a8/0x1f8&#xA;  ksys_read+0x74/0x108&#xA;  __arm64_sys_read+0x24/0x38&#xA;  invoke_syscall+0x50/0x120&#xA;  el0_svc_common.constprop.0+0xc8/0xf0&#xA;  do_el0_svc+0x24/0x38&#xA;  el0_svc+0x38/0x138&#xA;  el0t_64_sync_handler+0xc0/0xc8&#xA;  el0t_64_sync+0x188/0x190&#xA;&#xA;The zram-&gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if&#xA;comp_algorithm_set() has not been called.  User can access the zram device&#xA;by sysfs after device_add_disk(), so there is a time window to trigger the&#xA;NULL pointer dereference.  Move it ahead device_add_disk() to make sure&#xA;when user can access the zram device, it is ready.  comp_algorithm_set()&#xA;is protected by zram-&gt;init_lock in other places and no such problem.&#xA;CVE-2024-53198:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xen: Fix the issue of resource not being properly released in xenbus_dev_probe()&#xA;&#xA;This patch fixes an issue in the function xenbus_dev_probe(). In the&#xA;xenbus_dev_probe() function, within the if (err) branch at line 313, the&#xA;program incorrectly returns err directly without releasing the resources&#xA;allocated by err = drv-&gt;probe(dev, id). As the return value is non-zero,&#xA;the upper layers assume the processing logic has failed. However, the probe&#xA;operation was performed earlier without a corresponding remove operation.&#xA;Since the probe actually allocates resources, failing to perform the remove&#xA;operation could lead to problems.&#xA;&#xA;To fix this issue, we followed the resource release logic of the&#xA;xenbus_dev_remove() function by adding a new block fail_remove before the&#xA;fail_put block. After entering the branch if (err) at line 313, the&#xA;function will use a goto statement to jump to the fail_remove block,&#xA;ensuring that the previously acquired resources are correctly released,&#xA;thus preventing the reference count leak.&#xA;&#xA;This bug was identified by an experimental static analysis tool developed&#xA;by our team. The tool specializes in analyzing reference count operations&#xA;and detecting potential issues where resources are not properly managed.&#xA;In this case, the tool flagged the missing release operation as a&#xA;potential problem, which led to the development of this patch.&#xA;CVE-2024-56571:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-56610:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;kcsan: Turn report_filterlist_lock into a raw_spinlock&#xA;&#xA;Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see&#xA;splats like:&#xA;&#xA;| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48&#xA;| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1&#xA;| preempt_count: 10002, expected: 0&#xA;| RCU nest depth: 0, expected: 0&#xA;| no locks held by swapper/1/0.&#xA;| irq event stamp: 156674&#xA;| hardirqs last  enabled at (156673): [&lt;ffffffff81130bd9&gt;] do_idle+0x1f9/0x240&#xA;| hardirqs last disabled at (156674): [&lt;ffffffff82254f84&gt;] sysvec_apic_timer_interrupt+0x14/0xc0&#xA;| softirqs last  enabled at (0): [&lt;ffffffff81099f47&gt;] copy_process+0xfc7/0x4b60&#xA;| softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0&#xA;| Preemption disabled at:&#xA;| [&lt;ffffffff814a3e2a&gt;] paint_ptr+0x2a/0x90&#xA;| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3&#xA;| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014&#xA;| Call Trace:&#xA;|  &lt;IRQ&gt;&#xA;|  dump_stack_lvl+0x7e/0xc0&#xA;|  dump_stack+0x1d/0x30&#xA;|  __might_resched+0x1a2/0x270&#xA;|  rt_spin_lock+0x68/0x170&#xA;|  kcsan_skip_report_debugfs+0x43/0xe0&#xA;|  print_report+0xb5/0x590&#xA;|  kcsan_report_known_origin+0x1b1/0x1d0&#xA;|  kcsan_setup_watchpoint+0x348/0x650&#xA;|  __tsan_unaligned_write1+0x16d/0x1d0&#xA;|  hrtimer_interrupt+0x3d6/0x430&#xA;|  __sysvec_apic_timer_interrupt+0xe8/0x3a0&#xA;|  sysvec_apic_timer_interrupt+0x97/0xc0&#xA;|  &lt;/IRQ&gt;&#xA;&#xA;On a detected data race, KCSAN&#39;s reporting logic checks if it should&#xA;filter the report. That list is protected by the report_filterlist_lock&#xA;*non-raw* spinlock which may sleep on RT kernels.&#xA;&#xA;Since KCSAN may report data races in any context, convert it to a&#xA;raw_spinlock.&#xA;&#xA;This requires being careful about when to allocate memory for the filter&#xA;list itself which can be done via KCSAN&#39;s debugfs interface. Concurrent&#xA;modification of the filter list via debugfs should be rare: the chosen&#xA;strategy is to optimistically pre-allocate memory before the critical&#xA;section and discard if unused.&#xA;CVE-2024-56611:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM&#xA;&#xA;We currently assume that there is at least one VMA in a MM, which isn&#39;t&#xA;true.&#xA;&#xA;So we might end up having find_vma() return NULL, to then de-reference&#xA;NULL.  So properly handle find_vma() returning NULL.&#xA;&#xA;This fixes the report:&#xA;&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024&#xA;RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]&#xA;RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194&#xA;Code: ...&#xA;RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000&#xA;RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044&#xA;RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1&#xA;R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003&#xA;R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8&#xA;FS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709&#xA; __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]&#xA; __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]&#xA; __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;[[email protected]: add unlikely()]&#xA;CVE-2024-56704:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;9p/xen: fix release of IRQ&#xA;&#xA;Kernel logs indicate an IRQ was double-freed.&#xA;&#xA;Pass correct device ID during IRQ release.&#xA;&#xA;[Dominique: remove confusing variable reset to 0]&#xA;CVE-2024-56715:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ionic: Fix netdev notifier unregister on failure&#xA;&#xA;If register_netdev() fails, then the driver leaks the netdev notifier.&#xA;Fix this by calling ionic_lif_unregister() on register_netdev()&#xA;failure. This will also call ionic_lif_unregister_phc() if it has&#xA;already been registered.&#xA;CVE-2024-56746:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()&#xA;&#xA;When information such as info-&gt;screen_base is not ready, calling&#xA;sh7760fb_free_mem() does not release memory correctly. Call&#xA;dma_free_coherent() instead.&#xA;CVE-2024-57850:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jffs2: Prevent rtime decompress memory corruption&#xA;&#xA;The rtime decompression routine does not fully check bounds during the&#xA;entirety of the decompression pass and can corrupt memory outside the&#xA;decompression buffer if the compressed data is corrupted. This adds the&#xA;required check to prevent this failure mode.&#xA;CVE-2024-57896:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount&#xA;&#xA;During the unmount path, at close_ctree(), we first stop the cleaner&#xA;kthread, using kthread_stop() which frees the associated task_struct, and&#xA;then stop and destroy all the work queues. However after we stopped the&#xA;cleaner we may still have a worker from the delalloc_workers queue running&#xA;inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),&#xA;which in turn tries to wake up the cleaner kthread - which was already&#xA;destroyed before, resulting in a use-after-free on the task_struct.&#xA;&#xA;Syzbot reported this with the following stack traces:&#xA;&#xA;  BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089&#xA;  Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52&#xA;&#xA;  CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0&#xA;  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;  Workqueue: btrfs-delalloc btrfs_work_helper&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   __dump_stack lib/dump_stack.c:94 [inline]&#xA;   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA;   print_address_description mm/kasan/report.c:378 [inline]&#xA;   print_report+0x169/0x550 mm/kasan/report.c:489&#xA;   kasan_report+0x143/0x180 mm/kasan/report.c:602&#xA;   __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089&#xA;   lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849&#xA;   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]&#xA;   _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162&#xA;   class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]&#xA;   try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205&#xA;   submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615&#xA;   run_ordered_work fs/btrfs/async-thread.c:288 [inline]&#xA;   btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324&#xA;   process_one_work kernel/workqueue.c:3229 [inline]&#xA;   process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310&#xA;   worker_thread+0x870/0xd30 kernel/workqueue.c:3391&#xA;   kthread+0x2f0/0x390 kernel/kthread.c:389&#xA;   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;   &lt;/TASK&gt;&#xA;&#xA;  Allocated by task 2:&#xA;   kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;   unpoison_slab_object mm/kasan/common.c:319 [inline]&#xA;   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345&#xA;   kasan_slab_alloc include/linux/kasan.h:250 [inline]&#xA;   slab_post_alloc_hook mm/slub.c:4104 [inline]&#xA;   slab_alloc_node mm/slub.c:4153 [inline]&#xA;   kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205&#xA;   alloc_task_struct_node kernel/fork.c:180 [inline]&#xA;   dup_task_struct+0x57/0x8c0 kernel/fork.c:1113&#xA;   copy_process+0x5d1/0x3d50 kernel/fork.c:2225&#xA;   kernel_clone+0x223/0x870 kernel/fork.c:2807&#xA;   kernel_thread+0x1bc/0x240 kernel/fork.c:2869&#xA;   create_kthread kernel/kthread.c:412 [inline]&#xA;   kthreadd+0x60d/0x810 kernel/kthread.c:767&#xA;   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;&#xA;  Freed by task 24:&#xA;   kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582&#xA;   poison_slab_object mm/kasan/common.c:247 [inline]&#xA;   __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264&#xA;   kasan_slab_free include/linux/kasan.h:233 [inline]&#xA;   slab_free_hook mm/slub.c:2338 [inline]&#xA;   slab_free mm/slub.c:4598 [inline]&#xA;   kmem_cache_free+0x195/0x410 mm/slub.c:4700&#xA;   put_task_struct include/linux/sched/task.h:144 [inline]&#xA;   delayed_put_task_struct+0x125/0x300 kernel/exit.c:227&#xA;   rcu_do_batch kernel/rcu/tree.c:2567 [inline]&#xA;   rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823&#xA;   handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554&#xA;   run_ksoftirqd+0xca/0x130 kernel/softirq.c:943&#xA;  &#xA;---truncated---&#xA;CVE-2024-57892:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv&#xA;&#xA;When mounting ocfs2 and then remounting it as read-only, a&#xA;slab-use-after-free occurs after the user uses a syscall to&#xA;quota_getnextquota.  Specifically, sb_dqinfo(sb, type)-&gt;dqi_priv is the&#xA;dangling pointer.&#xA;&#xA;During the remounting process, the pointer dqi_priv is freed but is never&#xA;set as null leaving it to be accessed.  Additionally, the read-only option&#xA;for remounting sets the DQUOT_SUSPENDED flag instead of setting the&#xA;DQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting the&#xA;next quota, the function ocfs2_get_next_id is called and only checks the&#xA;quota usage flags and not the quota suspended flags.&#xA;&#xA;To fix this, I set dqi_priv to null when it is freed after remounting with&#xA;read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.&#xA;&#xA;[[email protected]: coding-style cleanups]&#xA;CVE-2025-21815:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/compaction: fix UBSAN shift-out-of-bounds warning&#xA;&#xA;syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL &lt;&lt; order)&#xA;in isolate_freepages_block().  The bogus compound_order can be any value&#xA;because it is union with flags.  Add back the MAX_PAGE_ORDER check to fix&#xA;the warning.&#xA;CVE-2024-53050:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/i915/hdcp: Add encoder check in hdcp2_get_capability&#xA;&#xA;Add encoder check in intel_hdcp2_get_capability to avoid&#xA;null pointer error.&#xA;CVE-2024-53131:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint&#xA;&#xA;Patch series &#34;nilfs2: fix null-ptr-deref bugs on block tracepoints&#34;.&#xA;&#xA;This series fixes null pointer dereference bugs that occur when using&#xA;nilfs2 and two block-related tracepoints.&#xA;&#xA;&#xA;This patch (of 2):&#xA;&#xA;It has been reported that when using &#34;block:block_touch_buffer&#34;&#xA;tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a&#xA;NULL pointer dereference, or a general protection fault when KASAN is&#xA;enabled.&#xA;&#xA;This happens because since the tracepoint was added in touch_buffer(), it&#xA;references the dev_t member bh-&gt;b_bdev-&gt;bd_dev regardless of whether the&#xA;buffer head has a pointer to a block_device structure.  In the current&#xA;implementation, the block_device structure is set after the function&#xA;returns to the caller.&#xA;&#xA;Here, touch_buffer() is used to mark the folio/page that owns the buffer&#xA;head as accessed, but the common search helper for folio/page used by the&#xA;caller function was optimized to mark the folio/page as accessed when it&#xA;was reimplemented a long time ago, eliminating the need to call&#xA;touch_buffer() here in the first place.&#xA;&#xA;So this solves the issue by eliminating the touch_buffer() call itself.&#xA;CVE-2024-56648:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hsr: avoid potential out-of-bound access in fill_frame_info()&#xA;&#xA;syzbot is able to feed a packet with 14 bytes, pretending&#xA;it is a vlan one.&#xA;&#xA;Since fill_frame_info() is relying on skb-&gt;mac_len already,&#xA;extend the check to cover this case.&#xA;&#xA;BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]&#xA; BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724&#xA;  fill_frame_info net/hsr/hsr_forward.c:709 [inline]&#xA;  hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724&#xA;  hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235&#xA;  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:5011 [inline]&#xA;  xmit_one net/core/dev.c:3590 [inline]&#xA;  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606&#xA;  __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434&#xA;  dev_queue_xmit include/linux/netdevice.h:3168 [inline]&#xA;  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276&#xA;  packet_snd net/packet/af_packet.c:3146 [inline]&#xA;  packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178&#xA;  sock_sendmsg_nosec net/socket.c:711 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:726&#xA;  __sys_sendto+0x594/0x750 net/socket.c:2197&#xA;  __do_sys_sendto net/socket.c:2204 [inline]&#xA;  __se_sys_sendto net/socket.c:2200 [inline]&#xA;  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200&#xA;  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Uninit was created at:&#xA;  slab_post_alloc_hook mm/slub.c:4091 [inline]&#xA;  slab_alloc_node mm/slub.c:4134 [inline]&#xA;  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186&#xA;  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587&#xA;  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678&#xA;  alloc_skb include/linux/skbuff.h:1323 [inline]&#xA;  alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612&#xA;  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881&#xA;  packet_alloc_skb net/packet/af_packet.c:2995 [inline]&#xA;  packet_snd net/packet/af_packet.c:3089 [inline]&#xA;  packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178&#xA;  sock_sendmsg_nosec net/socket.c:711 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:726&#xA;  __sys_sendto+0x594/0x750 net/socket.c:2197&#xA;  __do_sys_sendto net/socket.c:2204 [inline]&#xA;  __se_sys_sendto net/socket.c:2200 [inline]&#xA;  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200&#xA;  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-56626:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write&#xA;&#xA;An offset from client could be a negative value, It could allows&#xA;to write data outside the bounds of the allocated buffer.&#xA;Note that this issue is coming when setting&#xA;&#39;vfs objects = streams_xattr parameter&#39; in ksmbd.conf.&#xA;CVE-2024-56728:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c&#xA;&#xA;Add error pointer check after calling otx2_mbox_get_rsp().&#xA;CVE-2024-56758:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: check folio mapping after unlock in relocate_one_folio()&#xA;&#xA;When we call btrfs_read_folio() to bring a folio uptodate, we unlock the&#xA;folio. The result of that is that a different thread can modify the&#xA;mapping (like remove it with invalidate) before we call folio_lock().&#xA;This results in an invalid page and we need to try again.&#xA;&#xA;In particular, if we are relocating concurrently with aborting a&#xA;transaction, this can result in a crash like the following:&#xA;&#xA;  BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;  PGD 0 P4D 0&#xA;  Oops: 0000 [#1] SMP&#xA;  CPU: 76 PID: 1411631 Comm: kworker/u322:5&#xA;  Workqueue: events_unbound btrfs_reclaim_bgs_work&#xA;  RIP: 0010:set_page_extent_mapped+0x20/0xb0&#xA;  RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246&#xA;  RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000&#xA;  RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880&#xA;  RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0&#xA;  R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000&#xA;  R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff&#xA;  FS:  0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0&#xA;  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;  PKRU: 55555554&#xA;  Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? __die+0x78/0xc0&#xA;  ? page_fault_oops+0x2a8/0x3a0&#xA;  ? __switch_to+0x133/0x530&#xA;  ? wq_worker_running+0xa/0x40&#xA;  ? exc_page_fault+0x63/0x130&#xA;  ? asm_exc_page_fault+0x22/0x30&#xA;  ? set_page_extent_mapped+0x20/0xb0&#xA;  relocate_file_extent_cluster+0x1a7/0x940&#xA;  relocate_data_extent+0xaf/0x120&#xA;  relocate_block_group+0x20f/0x480&#xA;  btrfs_relocate_block_group+0x152/0x320&#xA;  btrfs_relocate_chunk+0x3d/0x120&#xA;  btrfs_reclaim_bgs_work+0x2ae/0x4e0&#xA;  process_scheduled_works+0x184/0x370&#xA;  worker_thread+0xc6/0x3e0&#xA;  ? blk_add_timer+0xb0/0xb0&#xA;  kthread+0xae/0xe0&#xA;  ? flush_tlb_kernel_range+0x90/0x90&#xA;  ret_from_fork+0x2f/0x40&#xA;  ? flush_tlb_kernel_range+0x90/0x90&#xA;  ret_from_fork_asm+0x11/0x20&#xA;  &lt;/TASK&gt;&#xA;&#xA;This occurs because cleanup_one_transaction() calls&#xA;destroy_delalloc_inodes() which calls invalidate_inode_pages2() which&#xA;takes the folio_lock before setting mapping to NULL. We fail to check&#xA;this, and subsequently call set_extent_mapping(), which assumes that&#xA;mapping != NULL (in fact it asserts that in debug mode)&#xA;&#xA;Note that the &#34;fixes&#34; patch here is not the one that introduced the&#xA;race (the very first iteration of this code from 2009) but a more recent&#xA;change that made this particular crash happen in practice.&#xA;CVE-2024-56780:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;quota: flush quota_release_work upon quota writeback&#xA;&#xA;One of the paths quota writeback is called from is:&#xA;&#xA;freeze_super()&#xA;  sync_filesystem()&#xA;    ext4_sync_fs()&#xA;      dquot_writeback_dquots()&#xA;&#xA;Since we currently don&#39;t always flush the quota_release_work queue in&#xA;this path, we can end up with the following race:&#xA;&#xA; 1. dquot are added to releasing_dquots list during regular operations.&#xA; 2. FS Freeze starts, however, this does not flush the quota_release_work queue.&#xA; 3. Freeze completes.&#xA; 4. Kernel eventually tries to flush the workqueue while FS is frozen which&#xA;    hits a WARN_ON since transaction gets started during frozen state:&#xA;&#xA;  ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)&#xA;  __ext4_journal_start_sb+0x64/0x1c0 [ext4]&#xA;  ext4_release_dquot+0x90/0x1d0 [ext4]&#xA;  quota_release_workfn+0x43c/0x4d0&#xA;&#xA;Which is the following line:&#xA;&#xA;  WARN_ON(sb-&gt;s_writers.frozen == SB_FREEZE_COMPLETE);&#xA;&#xA;Which ultimately results in generic/390 failing due to dmesg&#xA;noise. This was detected on powerpc machine 15 cores.&#xA;&#xA;To avoid this, make sure to flush the workqueue during&#xA;dquot_writeback_dquots() so we dont have any pending workitems after&#xA;freeze.&#xA;CVE-2024-56777:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check&#xA;&#xA;The return value of drm_atomic_get_crtc_state() needs to be&#xA;checked. To avoid use of error pointer &#39;crtc_state&#39; in case&#xA;of the failure.&#xA;CVE-2024-53237:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: fix use-after-free in device_for_each_child()&#xA;&#xA;Syzbot has reported the following KASAN splat:&#xA;&#xA;BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0&#xA;Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980&#xA;&#xA;CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x100/0x190&#xA; ? device_for_each_child+0x18f/0x1a0&#xA; print_report+0x13a/0x4cb&#xA; ? __virt_addr_valid+0x5e/0x590&#xA; ? __phys_addr+0xc6/0x150&#xA; ? device_for_each_child+0x18f/0x1a0&#xA; kasan_report+0xda/0x110&#xA; ? device_for_each_child+0x18f/0x1a0&#xA; ? __pfx_dev_memalloc_noio+0x10/0x10&#xA; device_for_each_child+0x18f/0x1a0&#xA; ? __pfx_device_for_each_child+0x10/0x10&#xA; pm_runtime_set_memalloc_noio+0xf2/0x180&#xA; netdev_unregister_kobject+0x1ed/0x270&#xA; unregister_netdevice_many_notify+0x123c/0x1d80&#xA; ? __mutex_trylock_common+0xde/0x250&#xA; ? __pfx_unregister_netdevice_many_notify+0x10/0x10&#xA; ? trace_contention_end+0xe6/0x140&#xA; ? __mutex_lock+0x4e7/0x8f0&#xA; ? __pfx_lock_acquire.part.0+0x10/0x10&#xA; ? rcu_is_watching+0x12/0xc0&#xA; ? unregister_netdev+0x12/0x30&#xA; unregister_netdevice_queue+0x30d/0x3f0&#xA; ? __pfx_unregister_netdevice_queue+0x10/0x10&#xA; ? __pfx_down_write+0x10/0x10&#xA; unregister_netdev+0x1c/0x30&#xA; bnep_session+0x1fb3/0x2ab0&#xA; ? __pfx_bnep_session+0x10/0x10&#xA; ? __pfx_lock_release+0x10/0x10&#xA; ? __pfx_woken_wake_function+0x10/0x10&#xA; ? __kthread_parkme+0x132/0x200&#xA; ? __pfx_bnep_session+0x10/0x10&#xA; ? kthread+0x13a/0x370&#xA; ? __pfx_bnep_session+0x10/0x10&#xA; kthread+0x2b7/0x370&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x48/0x80&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 4974:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0xaa/0xb0&#xA; __kmalloc_noprof+0x1d1/0x440&#xA; hci_alloc_dev_priv+0x1d/0x2820&#xA; __vhci_create_device+0xef/0x7d0&#xA; vhci_write+0x2c7/0x480&#xA; vfs_write+0x6a0/0xfc0&#xA; ksys_write+0x12f/0x260&#xA; do_syscall_64+0xc7/0x250&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Freed by task 4979:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_save_track+0x14/0x30&#xA; kasan_save_free_info+0x3b/0x60&#xA; __kasan_slab_free+0x4f/0x70&#xA; kfree+0x141/0x490&#xA; hci_release_dev+0x4d9/0x600&#xA; bt_host_release+0x6a/0xb0&#xA; device_release+0xa4/0x240&#xA; kobject_put+0x1ec/0x5a0&#xA; put_device+0x1f/0x30&#xA; vhci_release+0x81/0xf0&#xA; __fput+0x3f6/0xb30&#xA; task_work_run+0x151/0x250&#xA; do_exit+0xa79/0x2c30&#xA; do_group_exit+0xd5/0x2a0&#xA; get_signal+0x1fcd/0x2210&#xA; arch_do_signal_or_restart+0x93/0x780&#xA; syscall_exit_to_user_mode+0x140/0x290&#xA; do_syscall_64+0xd4/0x250&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;In &#39;hci_conn_del_sysfs()&#39;, &#39;device_unregister()&#39; may be called when&#xA;an underlying (kobject) reference counter is greater than 1. This&#xA;means that reparenting (happened when the device is actually freed)&#xA;is delayed and, during that delay, parent controller device (hciX)&#xA;may be deleted. Since the latter may create a dangling pointer to&#xA;freed parent, avoid that scenario by reparenting to NULL explicitly.&#xA;CVE-2024-53190:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures&#xA;&#xA;Syzkaller reported a hung task with uevent_show() on stack trace. That&#xA;specific issue was addressed by another commit [0], but even with that&#xA;fix applied (for example, running v6.12-rc5) we face another type of hung&#xA;task that comes from the same reproducer [1]. By investigating that, we&#xA;could narrow it to the following path:&#xA;&#xA;(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and&#xA;dummy_hcd infrastructure.&#xA;&#xA;(b) During the probe of rtl8192cu, the driver ends-up performing an efuse&#xA;read procedure (which is related to EEPROM load IIUC), and here lies the&#xA;issue: the function read_efuse() calls read_efuse_byte() many times, as&#xA;loop iterations depending on the efuse size (in our example, 512 in total).&#xA;&#xA;This procedure for reading efuse bytes relies in a loop that performs an&#xA;I/O read up to *10k* times in case of failures. We measured the time of&#xA;the loop inside read_efuse_byte() alone, and in this reproducer (which&#xA;involves the dummy_hcd emulation layer), it takes 15 seconds each. As a&#xA;consequence, we have the driver stuck in its probe routine for big time,&#xA;exposing a stack trace like below if we attempt to reboot the system, for&#xA;example:&#xA;&#xA;task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000&#xA;Workqueue: usb_hub_wq hub_event&#xA;Call Trace:&#xA; __schedule+0xe22/0xeb6&#xA; schedule_timeout+0xe7/0x132&#xA; __wait_for_common+0xb5/0x12e&#xA; usb_start_wait_urb+0xc5/0x1ef&#xA; ? usb_alloc_urb+0x95/0xa4&#xA; usb_control_msg+0xff/0x184&#xA; _usbctrl_vendorreq_sync+0xa0/0x161&#xA; _usb_read_sync+0xb3/0xc5&#xA; read_efuse_byte+0x13c/0x146&#xA; read_efuse+0x351/0x5f0&#xA; efuse_read_all_map+0x42/0x52&#xA; rtl_efuse_shadow_map_update+0x60/0xef&#xA; rtl_get_hwinfo+0x5d/0x1c2&#xA; rtl92cu_read_eeprom_info+0x10a/0x8d5&#xA; ? rtl92c_read_chip_version+0x14f/0x17e&#xA; rtl_usb_probe+0x323/0x851&#xA; usb_probe_interface+0x278/0x34b&#xA; really_probe+0x202/0x4a4&#xA; __driver_probe_device+0x166/0x1b2&#xA; driver_probe_device+0x2f/0xd8&#xA; [...]&#xA;&#xA;We propose hereby to drastically reduce the attempts of doing the I/O&#xA;reads in case of failures, restricted to USB devices (given that&#xA;they&#39;re inherently slower than PCIe ones). By retrying up to 10 times&#xA;(instead of 10000), we got reponsiveness in the reproducer, while seems&#xA;reasonable to believe that there&#39;s no sane USB device implementation in&#xA;the field requiring this amount of retries at every I/O read in order&#xA;to properly work. Based on that assumption, it&#39;d be good to have it&#xA;backported to stable but maybe not since driver implementation (the 10k&#xA;number comes from day 0), perhaps up to 6.x series makes sense.&#xA;&#xA;[0] Commit 15fffc6a5624 (&#34;driver core: Fix uevent_show() vs driver detach race&#34;)&#xA;&#xA;[1] A note about that: this syzkaller report presents multiple reproducers&#xA;that differs by the type of emulated USB device. For this specific case,&#xA;check the entry from 2024/08/08 06:23 in the list of crashes; the C repro&#xA;is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.&#xA;CVE-2024-56662:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl&#xA;&#xA;Fix an issue detected by syzbot with KASAN:&#xA;&#xA;BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/&#xA;core.c:416 [inline]&#xA;BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0&#xA;drivers/acpi/nfit/core.c:459&#xA;&#xA;The issue occurs in cmd_to_func when the call_pkg-&gt;nd_reserved2&#xA;array is accessed without verifying that call_pkg points to a buffer&#xA;that is appropriately sized as a struct nd_cmd_pkg. This can lead&#xA;to out-of-bounds access and undefined behavior if the buffer does not&#xA;have sufficient space.&#xA;&#xA;To address this, a check was added in acpi_nfit_ctl() to ensure that&#xA;buf is not NULL and that buf_len is less than sizeof(*call_pkg)&#xA;before accessing it. This ensures safe access to the members of&#xA;call_pkg, including the nd_reserved2 array.&#xA;CVE-2024-56633:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg&#xA;&#xA;The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging&#xA;tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes.&#xA;&#xA;Potential problems with this strategy are as follows:&#xA;&#xA;- If the actual sent bytes are smaller than tosend, we need to charge some&#xA;  bytes back, as in line 487, which is okay but seems not clean.&#xA;&#xA;- When tosend is set to apply_bytes, as in line 417, and (ret &lt; 0), we may&#xA;  miss uncharging (msg-&gt;sg.size - apply_bytes) bytes.&#xA;&#xA;[...]&#xA;415 tosend = msg-&gt;sg.size;&#xA;416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes &lt; tosend)&#xA;417   tosend = psock-&gt;apply_bytes;&#xA;[...]&#xA;443 sk_msg_return(sk, msg, tosend);&#xA;444 release_sock(sk);&#xA;446 origsize = msg-&gt;sg.size;&#xA;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,&#xA;448                             msg, tosend, flags);&#xA;449 sent = origsize - msg-&gt;sg.size;&#xA;[...]&#xA;454 lock_sock(sk);&#xA;455 if (unlikely(ret &lt; 0)) {&#xA;456   int free = sk_msg_free_nocharge(sk, msg);&#xA;458   if (!cork)&#xA;459     *copied -= free;&#xA;460 }&#xA;[...]&#xA;487 if (eval == __SK_REDIRECT)&#xA;488   sk_mem_charge(sk, tosend - sent);&#xA;[...]&#xA;&#xA;When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,&#xA;the following warning will be reported:&#xA;&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0&#xA;Modules linked in:&#xA;CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014&#xA;Workqueue: events sk_psock_destroy&#xA;RIP: 0010:inet_sock_destruct+0x190/0x1a0&#xA;RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206&#xA;RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800&#xA;RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900&#xA;RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0&#xA;R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400&#xA;R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100&#xA;FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;? __warn+0x89/0x130&#xA;? inet_sock_destruct+0x190/0x1a0&#xA;? report_bug+0xfc/0x1e0&#xA;? handle_bug+0x5c/0xa0&#xA;? exc_invalid_op+0x17/0x70&#xA;? asm_exc_invalid_op+0x1a/0x20&#xA;? inet_sock_destruct+0x190/0x1a0&#xA;__sk_destruct+0x25/0x220&#xA;sk_psock_destroy+0x2b2/0x310&#xA;process_scheduled_works+0xa3/0x3e0&#xA;worker_thread+0x117/0x240&#xA;? __pfx_worker_thread+0x10/0x10&#xA;kthread+0xcf/0x100&#xA;? __pfx_kthread+0x10/0x10&#xA;ret_from_fork+0x31/0x40&#xA;? __pfx_kthread+0x10/0x10&#xA;ret_from_fork_asm+0x1a/0x30&#xA;&lt;/TASK&gt;&#xA;---[ end trace 0000000000000000 ]---&#xA;&#xA;In __SK_REDIRECT, a more concise way is delaying the uncharging after sent&#xA;bytes are finalized, and uncharge this value. When (ret &lt; 0), we shall&#xA;invoke sk_msg_free.&#xA;&#xA;Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,&#xA;we may miss uncharging (msg-&gt;sg.size - apply_bytes) bytes. The same&#xA;warning will be reported in selftest.&#xA;&#xA;[...]&#xA;468 case __SK_DROP:&#xA;469 default:&#xA;470 sk_msg_free_partial(sk, msg, tosend);&#xA;471 sk_msg_apply_bytes(psock, tosend);&#xA;472 *copied -= (tosend + delta);&#xA;473 return -EACCES;&#xA;[...]&#xA;&#xA;So instead of sk_msg_free_partial we can do sk_msg_free here.&#xA;CVE-2024-56595:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree&#xA;&#xA;When the value of lp is 0 at the beginning of the for loop, it will&#xA;become negative in the next assignment and we should bail out.&#xA;CVE-2024-56597:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: fix shift-out-of-bounds in dbSplit&#xA;&#xA;When dmt_budmin is less than zero, it causes errors&#xA;in the later stages. Added a check to return an error beforehand&#xA;in dbAllocCtl itself.&#xA;CVE-2024-56701:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore&#xA;&#xA;The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because&#xA;the code calls kmalloc() while holding it, which can sleep:&#xA;&#xA;  # echo 1 &gt; /proc/powerpc/vcpudispatch_stats&#xA;  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337&#xA;  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh&#xA;  preempt_count: 1, expected: 0&#xA;  3 locks held by sh/199:&#xA;   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438&#xA;   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4&#xA;   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4&#xA;  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152&#xA;  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries&#xA;  Call Trace:&#xA;    dump_stack_lvl+0x130/0x148 (unreliable)&#xA;    __might_resched+0x174/0x410&#xA;    kmem_cache_alloc_noprof+0x340/0x3d0&#xA;    alloc_dtl_buffers+0x124/0x1ac&#xA;    vcpudispatch_stats_write+0x2a8/0x5f4&#xA;    proc_reg_write+0xf4/0x150&#xA;    vfs_write+0xfc/0x438&#xA;    ksys_write+0x88/0x148&#xA;    system_call_exception+0x1c4/0x5a0&#xA;    system_call_common+0xf4/0x258&#xA;CVE-2024-56759:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: fix use-after-free when COWing tree bock and tracing is enabled&#xA;&#xA;When a COWing a tree block, at btrfs_cow_block(), and we have the&#xA;tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled&#xA;(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent&#xA;buffer while inside the tracepoint code. This is because in some paths&#xA;that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding&#xA;the last reference on the extent buffer @buf so btrfs_force_cow_block()&#xA;drops the last reference on the @buf extent buffer when it calls&#xA;free_extent_buffer_stale(buf), which schedules the release of the extent&#xA;buffer with RCU. This means that if we are on a kernel with preemption,&#xA;the current task may be preempted before calling trace_btrfs_cow_block()&#xA;and the extent buffer already released by the time trace_btrfs_cow_block()&#xA;is called, resulting in a use-after-free.&#xA;&#xA;Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to&#xA;btrfs_force_cow_block() before the COWed extent buffer is freed.&#xA;This also has a side effect of invoking the tracepoint in the tree defrag&#xA;code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is&#xA;called there, but this is fine and it was actually missing there.&#xA;CVE-2024-53146:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Prevent a potential integer overflow&#xA;&#xA;If the tag length is &gt;= U32_MAX - 3 then the &#34;length + 4&#34; addition&#xA;can result in an integer overflow. Address this by splitting the&#xA;decoding into several steps so that decode_cb_compound4res() does&#xA;not have to perform arithmetic on the unsafe length value.&#xA;CVE-2024-53218:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix race in concurrent f2fs_stop_gc_thread&#xA;&#xA;In my test case, concurrent calls to f2fs shutdown report the following&#xA;stack trace:&#xA;&#xA; Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI&#xA; CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? show_regs+0x8b/0xa0&#xA;  ? __die_body+0x26/0xa0&#xA;  ? die_addr+0x54/0x90&#xA;  ? exc_general_protection+0x24b/0x5c0&#xA;  ? asm_exc_general_protection+0x26/0x30&#xA;  ? kthread_stop+0x46/0x390&#xA;  f2fs_stop_gc_thread+0x6c/0x110&#xA;  f2fs_do_shutdown+0x309/0x3a0&#xA;  f2fs_ioc_shutdown+0x150/0x1c0&#xA;  __f2fs_ioctl+0xffd/0x2ac0&#xA;  f2fs_ioctl+0x76/0xe0&#xA;  vfs_ioctl+0x23/0x60&#xA;  __x64_sys_ioctl+0xce/0xf0&#xA;  x64_sys_call+0x2b1b/0x4540&#xA;  do_syscall_64+0xa7/0x240&#xA;  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;The root cause is a race condition in f2fs_stop_gc_thread() called from&#xA;different f2fs shutdown paths:&#xA;&#xA;  [CPU0]                       [CPU1]&#xA;  ----------------------       -----------------------&#xA;  f2fs_stop_gc_thread          f2fs_stop_gc_thread&#xA;                                 gc_th = sbi-&gt;gc_thread&#xA;    gc_th = sbi-&gt;gc_thread&#xA;    kfree(gc_th)&#xA;    sbi-&gt;gc_thread = NULL&#xA;                                 &lt; gc_th != NULL &gt;&#xA;                                 kthread_stop(gc_th-&gt;f2fs_gc_task) //UAF&#xA;&#xA;The commit c7f114d864ac (&#34;f2fs: fix to avoid use-after-free in&#xA;f2fs_stop_gc_thread()&#34;) attempted to fix this issue by using a read&#xA;semaphore to prevent races between shutdown and remount threads, but&#xA;it fails to prevent all race conditions.&#xA;&#xA;Fix it by converting to write lock of s_umount in f2fs_do_shutdown().&#xA;CVE-2024-53217:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Prevent NULL dereference in nfsd4_process_cb_update()&#xA;&#xA;@ses is initialized to NULL. If __nfsd4_find_backchannel() finds no&#xA;available backchannel session, setup_callback_client() will try to&#xA;dereference @ses and segfault.&#xA;CVE-2024-53173:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSv4.0: Fix a use-after-free problem in the asynchronous open()&#xA;&#xA;Yang Erkun reports that when two threads are opening files at the same&#xA;time, and are forced to abort before a reply is seen, then the call to&#xA;nfs_release_seqid() in nfs4_opendata_free() can result in a&#xA;use-after-free of the pointer to the defunct rpc task of the other&#xA;thread.&#xA;The fix is to ensure that if the RPC call is aborted before the call to&#xA;nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()&#xA;in nfs4_open_release() before the rpc_task is freed.&#xA;CVE-2024-56572:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()&#xA;&#xA;The buffer in the loop should be released under the exception path,&#xA;otherwise there may be a memory leak here.&#xA;&#xA;To mitigate this, free the buffer when allegro_alloc_buffer fails.&#xA;CVE-2024-56623:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Fix use after free on unload&#xA;&#xA;System crash is observed with stack trace warning of use after&#xA;free. There are 2 signals to tell dpc_thread to terminate (UNLOADING&#xA;flag and kthread_stop).&#xA;&#xA;On setting the UNLOADING flag when dpc_thread happens to run at the time&#xA;and sees the flag, this causes dpc_thread to exit and clean up&#xA;itself. When kthread_stop is called for final cleanup, this causes use&#xA;after free.&#xA;&#xA;Remove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop&#xA;as the main signal to exit dpc_thread.&#xA;&#xA;[596663.812935] kernel BUG at mm/slub.c:294!&#xA;[596663.812950] invalid opcode: 0000 [#1] SMP PTI&#xA;[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1&#xA;[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012&#xA;[596663.812974] RIP: 0010:__slab_free+0x17d/0x360&#xA;&#xA;...&#xA;[596663.813008] Call Trace:&#xA;[596663.813022]  ? __dentry_kill+0x121/0x170&#xA;[596663.813030]  ? _cond_resched+0x15/0x30&#xA;[596663.813034]  ? _cond_resched+0x15/0x30&#xA;[596663.813039]  ? wait_for_completion+0x35/0x190&#xA;[596663.813048]  ? try_to_wake_up+0x63/0x540&#xA;[596663.813055]  free_task+0x5a/0x60&#xA;[596663.813061]  kthread_stop+0xf3/0x100&#xA;[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx]&#xA;CVE-2024-56723:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices&#xA;&#xA;While design wise the idea of converting the driver to use&#xA;the hierarchy of the IRQ chips is correct, the implementation&#xA;has (inherited) flaws. This was unveiled when platform_get_irq()&#xA;had started WARN() on IRQ 0 that is supposed to be a Linux&#xA;IRQ number (also known as vIRQ).&#xA;&#xA;Rework the driver to respect IRQ domain when creating each MFD&#xA;device separately, as the domain is not the same for all of them.&#xA;CVE-2024-56741:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-56705:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: atomisp: Add check for rgby_data memory allocation failure&#xA;&#xA;In ia_css_3a_statistics_allocate(), there is no check on the allocation&#xA;result of the rgby_data memory. If rgby_data is not successfully&#xA;allocated, it may trigger the assert(host_stats-&gt;rgby_data) assertion in&#xA;ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.&#xA;CVE-2024-57977:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;memcg: fix soft lockup in the OOM process&#xA;&#xA;A soft lockup issue was found in the product with about 56,000 tasks were&#xA;in the OOM cgroup, it was traversing them when the soft lockup was&#xA;triggered.&#xA;&#xA;watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]&#xA;CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G&#xA;Hardware name: Huawei Cloud OpenStack Nova, BIOS&#xA;RIP: 0010:console_unlock+0x343/0x540&#xA;RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13&#xA;RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff&#xA;RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247&#xA;RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040&#xA;R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0&#xA;R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; vprintk_emit+0x193/0x280&#xA; printk+0x52/0x6e&#xA; dump_task+0x114/0x130&#xA; mem_cgroup_scan_tasks+0x76/0x100&#xA; dump_header+0x1fe/0x210&#xA; oom_kill_process+0xd1/0x100&#xA; out_of_memory+0x125/0x570&#xA; mem_cgroup_out_of_memory+0xb5/0xd0&#xA; try_charge+0x720/0x770&#xA; mem_cgroup_try_charge+0x86/0x180&#xA; mem_cgroup_try_charge_delay+0x1c/0x40&#xA; do_anonymous_page+0xb5/0x390&#xA; handle_mm_fault+0xc4/0x1f0&#xA;&#xA;This is because thousands of processes are in the OOM cgroup, it takes a&#xA;long time to traverse all of them.  As a result, this lead to soft lockup&#xA;in the OOM process.&#xA;&#xA;To fix this issue, call &#39;cond_resched&#39; in the &#39;mem_cgroup_scan_tasks&#39;&#xA;function per 1000 iterations.  For global OOM, call&#xA;&#39;touch_softlockup_watchdog&#39; per 1000 iterations to avoid this issue.&#xA;CVE-2023-52480:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix race condition between session lookup and expire&#xA;&#xA; Thread A                        +  Thread B&#xA; ksmbd_session_lookup            |  smb2_sess_setup&#xA;   sess = xa_load                |&#xA;                                 |&#xA;                                 |    xa_erase(&amp;conn-&gt;sessions, sess-&gt;id);&#xA;                                 |&#xA;                                 |    ksmbd_session_destroy(sess) --&gt; kfree(sess)&#xA;                                 |&#xA;   // UAF!                       |&#xA;   sess-&gt;last_active = jiffies   |&#xA;                                 +&#xA;&#xA;This patch add rwsem to fix race condition between ksmbd_session_lookup&#xA;and ksmbd_expire_session.&#xA;CVE-2024-56549:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cachefiles: Fix NULL pointer dereference in object-&gt;file&#xA;&#xA;At present, the object-&gt;file has the NULL pointer dereference problem in&#xA;ondemand-mode. The root cause is that the allocated fd and object-&gt;file&#xA;lifetime are inconsistent, and the user-space invocation to anon_fd uses&#xA;object-&gt;file. Following is the process that triggers the issue:&#xA;&#xA;&#x9;  [write fd]&#x9;&#x9;&#x9;&#x9;[umount]&#xA;cachefiles_ondemand_fd_write_iter&#xA;&#x9;&#x9;&#x9;&#x9;       fscache_cookie_state_machine&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; cachefiles_withdraw_cookie&#xA;  if (!file) return -ENOBUFS&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;   cachefiles_clean_up_object&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;     cachefiles_unmark_inode_in_use&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;     fput(object-&gt;file)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;     object-&gt;file = NULL&#xA;  // file NULL pointer dereference!&#xA;  __cachefiles_write(..., file, ...)&#xA;&#xA;Fix this issue by add an additional reference count to the object-&gt;file&#xA;before write/llseek, and decrement after it finished.&#xA;CVE-2024-56588:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: hisi_sas: Create all dump files during debugfs initialization&#xA;&#xA;For the current debugfs of hisi_sas, after user triggers dump, the&#xA;driver allocate memory space to save the register information and create&#xA;debugfs files to display the saved information. In this process, the&#xA;debugfs files created after each dump.&#xA;&#xA;Therefore, when the dump is triggered while the driver is unbind, the&#xA;following hang occurs:&#xA;&#xA;[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0&#xA;[67840.862947] Mem abort info:&#xA;[67840.865855]   ESR = 0x0000000096000004&#xA;[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[67840.875125]   SET = 0, FnV = 0&#xA;[67840.878291]   EA = 0, S1PTW = 0&#xA;[67840.881545]   FSC = 0x04: level 0 translation fault&#xA;[67840.886528] Data abort info:&#xA;[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000&#xA;[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000&#xA;[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000&#xA;[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP&#xA;[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[67841.003628] pc : down_write+0x30/0x98&#xA;[67841.007546] lr : start_creating.part.0+0x60/0x198&#xA;[67841.012495] sp : ffff8000b979ba20&#xA;[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40&#xA;[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8&#xA;[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18&#xA;[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020&#xA;[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff&#xA;[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18&#xA;[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18&#xA;[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9&#xA;[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001&#xA;[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0&#xA;[67841.089759] Call trace:&#xA;[67841.092456]  down_write+0x30/0x98&#xA;[67841.096017]  start_creating.part.0+0x60/0x198&#xA;[67841.100613]  debugfs_create_dir+0x48/0x1f8&#xA;[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]&#xA;[67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]&#xA;[67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]&#xA;[67841.125115]  full_proxy_write+0x68/0xc8&#xA;[67841.129175]  vfs_write+0xd8/0x3f0&#xA;[67841.132708]  ksys_write+0x70/0x108&#xA;[67841.136317]  __arm64_sys_write+0x24/0x38&#xA;[67841.140440]  invoke_syscall+0x50/0x128&#xA;[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0&#xA;[67841.149273]  do_el0_svc+0x24/0x38&#xA;[67841.152773]  el0_svc+0x38/0xd8&#xA;[67841.156009]  el0t_64_sync_handler+0xc0/0xc8&#xA;[67841.160361]  el0t_64_sync+0x1a4/0x1a8&#xA;[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)&#xA;[67841.170443] ---[ end trace 0000000000000000 ]---&#xA;&#xA;To fix this issue, create all directories and files during debugfs&#xA;initialization. In this way, the driver only needs to allocate memory&#xA;space to save information each time the user triggers dumping.&#xA;CVE-2023-52935:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/khugepaged: fix -&gt;anon_vma race&#xA;&#xA;If an -&gt;anon_vma is attached to the VMA, collapse_and_free_pmd() requires&#xA;it to be locked.&#xA;&#xA;Page table traversal is allowed under any one of the mmap lock, the&#xA;anon_vma lock (if the VMA is associated with an anon_vma), and the&#xA;mapping lock (if the VMA is associated with a mapping); and so to be&#xA;able to remove page tables, we must hold all three of them. &#xA;retract_page_tables() bails out if an -&gt;anon_vma is attached, but does&#xA;this check before holding the mmap lock (as the comment above the check&#xA;explains).&#xA;&#xA;If we racily merged an existing -&gt;anon_vma (shared with a child&#xA;process) from a neighboring VMA, subsequent rmap traversals on pages&#xA;belonging to the child will be able to see the page tables that we are&#xA;concurrently removing while assuming that nothing else can access them.&#xA;&#xA;Repeat the -&gt;anon_vma check once we hold the mmap lock to ensure that&#xA;there really is no concurrent page table access.&#xA;&#xA;Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),&#xA;in the line &#34;lockdep_assert_held_write(&amp;vma-&gt;anon_vma-&gt;root-&gt;rwsem)&#34;. &#xA;It can also lead to use-after-free access.&#xA;CVE-2024-53168:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket&#xA;&#xA;BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0&#xA;Read of size 1 at addr ffff888111f322cd by task swapper/0/0&#xA;&#xA;CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl+0x68/0xa0&#xA; print_address_description.constprop.0+0x2c/0x3d0&#xA; print_report+0xb4/0x270&#xA; kasan_report+0xbd/0xf0&#xA; tcp_write_timer_handler+0x156/0x3e0&#xA; tcp_write_timer+0x66/0x170&#xA; call_timer_fn+0xfb/0x1d0&#xA; __run_timers+0x3f8/0x480&#xA; run_timer_softirq+0x9b/0x100&#xA; handle_softirqs+0x153/0x390&#xA; __irq_exit_rcu+0x103/0x120&#xA; irq_exit_rcu+0xe/0x20&#xA; sysvec_apic_timer_interrupt+0x76/0x90&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; asm_sysvec_apic_timer_interrupt+0x1a/0x20&#xA;RIP: 0010:default_idle+0xf/0x20&#xA;Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90&#xA; 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 &lt;fa&gt; c3 cc cc cc&#xA; cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90&#xA;RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242&#xA;RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f&#xA;RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d&#xA;R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000&#xA;R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0&#xA; default_idle_call+0x6b/0xa0&#xA; cpuidle_idle_call+0x1af/0x1f0&#xA; do_idle+0xbc/0x130&#xA; cpu_startup_entry+0x33/0x40&#xA; rest_init+0x11f/0x210&#xA; start_kernel+0x39a/0x420&#xA; x86_64_start_reservations+0x18/0x30&#xA; x86_64_start_kernel+0x97/0xa0&#xA; common_startup_64+0x13e/0x141&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 595:&#xA; kasan_save_stack+0x24/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_slab_alloc+0x87/0x90&#xA; kmem_cache_alloc_noprof+0x12b/0x3f0&#xA; copy_net_ns+0x94/0x380&#xA; create_new_namespaces+0x24c/0x500&#xA; unshare_nsproxy_namespaces+0x75/0xf0&#xA; ksys_unshare+0x24e/0x4f0&#xA; __x64_sys_unshare+0x1f/0x30&#xA; do_syscall_64+0x70/0x180&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Freed by task 100:&#xA; kasan_save_stack+0x24/0x50&#xA; kasan_save_track+0x14/0x30&#xA; kasan_save_free_info+0x3b/0x60&#xA; __kasan_slab_free+0x54/0x70&#xA; kmem_cache_free+0x156/0x5d0&#xA; cleanup_net+0x5d3/0x670&#xA; process_one_work+0x776/0xa90&#xA; worker_thread+0x2e2/0x560&#xA; kthread+0x1a8/0x1f0&#xA; ret_from_fork+0x34/0x60&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;Reproduction script:&#xA;&#xA;mkdir -p /mnt/nfsshare&#xA;mkdir -p /mnt/nfs/netns_1&#xA;mkfs.ext4 /dev/sdb&#xA;mount /dev/sdb /mnt/nfsshare&#xA;systemctl restart nfs-server&#xA;chmod 777 /mnt/nfsshare&#xA;exportfs -i -o rw,no_root_squash *:/mnt/nfsshare&#xA;&#xA;ip netns add netns_1&#xA;ip link add name veth_1_peer type veth peer veth_1&#xA;ifconfig veth_1_peer 11.11.0.254 up&#xA;ip link set veth_1 netns netns_1&#xA;ip netns exec netns_1 ifconfig veth_1 11.11.0.1&#xA;&#xA;ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \&#xA;&#x9;--tcp-flags FIN FIN  -j DROP&#xA;&#xA;(note: In my environment, a DESTROY_CLIENTID operation is always sent&#xA; immediately, breaking the nfs tcp connection.)&#xA;ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \&#xA;&#x9;11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1&#xA;&#xA;ip netns del netns_1&#xA;&#xA;The reason here is that the tcp socket in netns_1 (nfs side) has been&#xA;shutdown and closed (done in xs_destroy), but the FIN message (with ack)&#xA;is discarded, and the nfsd side keeps sending retransmission messages.&#xA;As a result, when the tcp sock in netns_1 processes the received message,&#xA;it sends the message (FIN message) in the sending queue, and the tcp timer&#xA;is re-established. When the network namespace is deleted, the net structure&#xA;accessed by tcp&#39;s timer handler function causes problems.&#xA;&#xA;To fix this problem, let&#39;s hold netns refcnt for the tcp kernel socket as&#xA;done in other modules. This is an ugly hack which can easily be backported&#xA;to earlier kernels. A proper fix which cleans up the interfaces will&#xA;follow, but may not be so easy to backport.&#xA;CVE-2024-56688:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport&#xA;&#xA;Since transport-&gt;sock has been set to NULL during reset transport,&#xA;XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the&#xA;xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()&#xA;to dereference the transport-&gt;sock that has been set to NULL.&#xA;CVE-2024-53114:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client&#xA;&#xA;A number of Zen4 client SoCs advertise the ability to use virtualized&#xA;VMLOAD/VMSAVE, but using these instructions is reported to be a cause&#xA;of a random host reboot.&#xA;&#xA;These instructions aren&#39;t intended to be advertised on Zen4 client&#xA;so clear the capability.&#xA;CVE-2024-40927:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xhci: Handle TD clearing for multiple streams case&#xA;&#xA;When multiple streams are in use, multiple TDs might be in flight when&#xA;an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for&#xA;each, to ensure everything is reset properly and the caches cleared.&#xA;Change the logic so that any N&gt;1 TDs found active for different streams&#xA;are deferred until after the first one is processed, calling&#xA;xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to&#xA;queue another command until we are done with all of them. Also change&#xA;the error/&#34;should never happen&#34; paths to ensure we at least clear any&#xA;affected TDs, even if we can&#39;t issue a command to clear the hardware&#xA;cache, and complain loudly with an xhci_warn() if this ever happens.&#xA;&#xA;This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct&#xA;assumptions about number of rings per endpoint.&#34;) early on in the XHCI&#xA;driver&#39;s life, when stream support was first added.&#xA;It was then identified but not fixed nor made into a warning in commit&#xA;674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;),&#xA;which added a FIXME comment for the problem case (without materially&#xA;changing the behavior as far as I can tell, though the new logic made&#xA;the problem more obvious).&#xA;&#xA;Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some&#xA;cached cancelled URBs.&#34;), it was acknowledged again.&#xA;&#xA;[Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached&#xA;cancelled URBs.&#34;) was a targeted regression fix to the previously mentioned&#xA;patch. Users reported issues with usb stuck after unmounting/disconnecting&#xA;UAS devices. This rolled back the TD clearing of multiple streams to its&#xA;original state.]&#xA;&#xA;Apparently the commit author was aware of the problem (yet still chose&#xA;to submit it): It was still mentioned as a FIXME, an xhci_dbg() was&#xA;added to log the problem condition, and the remaining issue was mentioned&#xA;in the commit description. The choice of making the log type xhci_dbg()&#xA;for what is, at this point, a completely unhandled and known broken&#xA;condition is puzzling and unfortunate, as it guarantees that no actual&#xA;users would see the log in production, thereby making it nigh&#xA;undebuggable (indeed, even if you turn on DEBUG, the message doesn&#39;t&#xA;really hint at there being a problem at all).&#xA;&#xA;It took me *months* of random xHC crashes to finally find a reliable&#xA;repro and be able to do a deep dive debug session, which could all have&#xA;been avoided had this unhandled, broken condition been actually reported&#xA;with a warning, as it should have been as a bug intentionally left in&#xA;unfixed (never mind that it shouldn&#39;t have been left in at all).&#xA;&#xA;&gt; Another fix to solve clearing the caches of all stream rings with&#xA;&gt; cancelled TDs is needed, but not as urgent.&#xA;&#xA;3 years after that statement and 14 years after the original bug was&#xA;introduced, I think it&#39;s finally time to fix it. And maybe next time&#xA;let&#39;s not leave bugs unfixed (that are actually worse than the original&#xA;bug), and let&#39;s actually get people to review kernel commits please.&#xA;&#xA;Fixes xHC crashes and IOMMU faults with UAS devices when handling&#xA;errors/faults. Easiest repro is to use `hdparm` to mark an early sector&#xA;(e.g. 1024) on a disk as bad, then `cat /dev/sdX &gt; /dev/null` in a loop.&#xA;At least in the case of JMicron controllers, the read errors end up&#xA;having to cancel two TDs (for two queued requests to different streams)&#xA;and the one that didn&#39;t get cleared properly ends up faulting the xHC&#xA;entirely when it tries to access DMA pages that have since been unmapped,&#xA;referred to by the stale TDs. This normally happens quickly (after two&#xA;or three loops). After this fix, I left the `cat` in a loop running&#xA;overnight and experienced no xHC failures, with all read errors&#xA;recovered properly. Repro&#39;d and tested on an Apple M1 Mac Mini&#xA;(dwc3 host).&#xA;&#xA;On systems without an IOMMU, this bug would instead silently corrupt&#xA;freed memory, making this a&#xA;---truncated---&#xA;CVE-2024-49991:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer&#xA;&#xA;Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,&#xA;otherwise amdgpu_bo_unref clear the local variable, the original pointer&#xA;not set to NULL, this could cause use-after-free bug.&#xA;CVE-2024-50116:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nilfs2: fix kernel bug due to missing clearing of buffer delay flag&#xA;&#xA;Syzbot reported that after nilfs2 reads a corrupted file system image&#xA;and degrades to read-only, the BUG_ON check for the buffer delay flag&#xA;in submit_bh_wbc() may fail, causing a kernel bug.&#xA;&#xA;This is because the buffer delay flag is not cleared when clearing the&#xA;buffer state flags to discard a page/folio or a buffer head. So, fix&#xA;this.&#xA;&#xA;This became necessary when the use of nilfs2&#39;s own page clear routine&#xA;was expanded.  This state inconsistency does not occur if the buffer&#xA;is written normally by log writing.&#xA;CVE-2024-50187:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/vc4: Stop the active perfmon before being destroyed&#xA;&#xA;Upon closing the file descriptor, the active performance monitor is not&#xA;stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,&#xA;the active performance monitor&#39;s pointer (`vc4-&gt;active_perfmon`) is still&#xA;retained.&#xA;&#xA;If we open a new file descriptor and submit a few jobs with performance&#xA;monitors, the driver will attempt to stop the active performance monitor&#xA;using the stale pointer in `vc4-&gt;active_perfmon`. However, this pointer&#xA;is no longer valid because the previous process has already terminated,&#xA;and all performance monitors associated with it have been destroyed and&#xA;freed.&#xA;&#xA;To fix this, when the active performance monitor belongs to a given&#xA;process, explicitly stop it before destroying and freeing it.&#xA;CVE-2024-50279:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm cache: fix out-of-bounds access to the dirty bitset when resizing&#xA;&#xA;dm-cache checks the dirty bits of the cache blocks to be dropped when&#xA;shrinking the fast device, but an index bug in bitset iteration causes&#xA;out-of-bounds access.&#xA;&#xA;Reproduce steps:&#xA;&#xA;1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)&#xA;&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34;&#xA;dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34;&#xA;dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct&#xA;dmsetup create cache --table &#34;0 524288 cache /dev/mapper/cmeta \&#xA;/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;&#xA;&#xA;2. shrink the fast device to 512 cache blocks, triggering out-of-bounds&#xA;   access to the dirty bitset (offset 0x80)&#xA;&#xA;dmsetup suspend cache&#xA;dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;&#xA;dmsetup resume cdata&#xA;dmsetup resume cache&#xA;&#xA;KASAN reports:&#xA;&#xA;  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0&#xA;  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131&#xA;&#xA;  (...snip...)&#xA;  The buggy address belongs to the virtual mapping at&#xA;   [ffffc900000f3000, ffffc900000f5000) created by:&#xA;   cache_ctr+0x176a/0x35f0&#xA;&#xA;  (...snip...)&#xA;  Memory state around the buggy address:&#xA;   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;  &gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;                     ^&#xA;   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8&#xA;&#xA;Fix by making the index post-incremented.&#xA;CVE-2024-50272:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;filemap: Fix bounds checking in filemap_read()&#xA;&#xA;If the caller supplies an iocb-&gt;ki_pos value that is close to the&#xA;filesystem upper limit, and an iterator with a count that causes us to&#xA;overflow that limit, then filemap_read() enters an infinite loop.&#xA;&#xA;This behaviour was discovered when testing xfstests generic/525 with the&#xA;&#34;localio&#34; optimisation for loopback NFS mounts.&#xA;CVE-2024-56690:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY&#xA;&#xA;Since commit 8f4f68e788c3 (&#34;crypto: pcrypt - Fix hungtask for&#xA;PADATA_RESET&#34;), the pcrypt encryption and decryption operations return&#xA;-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is&#xA;generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns&#xA;-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.&#xA;Fix this issue by calling crypto layer directly without parallelization&#xA;in that case.&#xA;CVE-2024-43817:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: missing check virtio&#xA;&#xA;Two missing check in virtio_net_hdr_to_skb() allowed syzbot&#xA;to crash kernels again&#xA;&#xA;1. After the skb_segment function the buffer may become non-linear&#xA;(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere&#xA;the __skb_linearize function will not be executed, then the buffer will&#xA;remain non-linear. Then the condition (offset &gt;= skb_headlen(skb))&#xA;becomes true, which causes WARN_ON_ONCE in skb_checksum_help.&#xA;&#xA;2. The struct sk_buff and struct virtio_net_hdr members must be&#xA;mathematically related.&#xA;(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.&#xA;(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.&#xA;(remainder) may be 0 if division is without remainder.&#xA;&#xA;offset+2 (4191) &gt; skb_headlen() (1116)&#xA;WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303&#xA;Modules linked in:&#xA;CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0&#xA;Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023&#xA;RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303&#xA;Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 &lt;0f&gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef&#xA;RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286&#xA;RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209&#xA;RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001&#xA;RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c&#xA;R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d&#xA;FS:  0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777&#xA; ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584&#xA; ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]&#xA; __ip_finish_output net/ipv4/ip_output.c:308 [inline]&#xA; __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295&#xA; ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323&#xA; NF_HOOK_COND include/linux/netfilter.h:303 [inline]&#xA; ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433&#xA; dst_output include/net/dst.h:451 [inline]&#xA; ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129&#xA; iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82&#xA; ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]&#xA; sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076&#xA; __netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA; xmit_one net/core/dev.c:3545 [inline]&#xA; dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561&#xA; __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346&#xA; dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA; packet_xmit+0x257/0x380 net/packet/af_packet.c:276&#xA; packet_snd net/packet/af_packet.c:3087 [inline]&#xA; packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0xd5/0x180 net/socket.c:745&#xA; __sys_sendto+0x255/0x340 net/socket.c:2190&#xA; __do_sys_sendto net/socket.c:2202 [inline]&#xA; __se_sys_sendto net/socket.c:2198 [inline]&#xA; __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198&#xA; do_syscall_x64 arch/x86/entry/common.c:51 [inline]&#xA; do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller&#xA;CVE-2024-50141:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context&#xA;&#xA;PRMT needs to find the correct type of block to translate the PA-VA&#xA;mapping for EFI runtime services.&#xA;&#xA;The issue arises because the PRMT is finding a block of type&#xA;EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services&#xA;as described in Section 2.2.2 (Runtime Services) of the UEFI&#xA;Specification [1]. Since the PRM handler is a type of runtime service,&#xA;this causes an exception when the PRM handler is called.&#xA;&#xA;    [Firmware Bug]: Unable to handle paging request in EFI runtime service&#xA;    WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341&#xA;        __efi_queue_work+0x11c/0x170&#xA;    Call trace:&#xA;&#xA;Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM&#xA;context.&#xA;&#xA;If no suitable block is found, a warning message will be printed, but&#xA;the procedure continues to manage the next PRM handler.&#xA;&#xA;However, if the PRM handler is actually called without proper allocation,&#xA;it would result in a failure during error handling.&#xA;&#xA;By using the correct memory types for runtime services, ensure that the&#xA;PRM handler and the context are properly mapped in the virtual address&#xA;space during runtime, preventing the paging request error.&#xA;&#xA;The issue is really that only memory that has been remapped for runtime&#xA;by the firmware can be used by the PRM handler, and so the region needs&#xA;to have the EFI_MEMORY_RUNTIME attribute.&#xA;&#xA;[ rjw: Subject and changelog edits ]&#xA;CVE-2024-53226:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()&#xA;&#xA;ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.&#xA;The driver needs to check whether it is a NULL pointer before&#xA;dereferencing it.&#xA;CVE-2023-53061:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix possible refcount leak in smb2_open()&#xA;&#xA;Reference count of acls will leak when memory allocation fails. Fix this&#xA;by adding the missing posix_acl_release().&#xA;CVE-2023-52920:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: support non-r10 register spill/fill to/from stack in precision tracking&#xA;&#xA;Use instruction (jump) history to record instructions that performed&#xA;register spill/fill to/from stack, regardless if this was done through&#xA;read-only r10 register, or any other register after copying r10 into it&#xA;*and* potentially adjusting offset.&#xA;&#xA;To make this work reliably, we push extra per-instruction flags into&#xA;instruction history, encoding stack slot index (spi) and stack frame&#xA;number in extra 10 bit flags we take away from prev_idx in instruction&#xA;history. We don&#39;t touch idx field for maximum performance, as it&#39;s&#xA;checked most frequently during backtracking.&#xA;&#xA;This change removes basically the last remaining practical limitation of&#xA;precision backtracking logic in BPF verifier. It fixes known&#xA;deficiencies, but also opens up new opportunities to reduce number of&#xA;verified states, explored in the subsequent patches.&#xA;&#xA;There are only three differences in selftests&#39; BPF object files&#xA;according to veristat, all in the positive direction (less states).&#xA;&#xA;File                                    Program        Insns (A)  Insns (B)  Insns  (DIFF)  States (A)  States (B)  States (DIFF)&#xA;--------------------------------------  -------------  ---------  ---------  -------------  ----------  ----------  -------------&#xA;test_cls_redirect_dynptr.bpf.linked3.o  cls_redirect        2987       2864  -123 (-4.12%)         240         231    -9 (-3.75%)&#xA;xdp_synproxy_kern.bpf.linked3.o         syncookie_tc       82848      82661  -187 (-0.23%)        5107        5073   -34 (-0.67%)&#xA;xdp_synproxy_kern.bpf.linked3.o         syncookie_xdp      85116      84964  -152 (-0.18%)        5162        5130   -32 (-0.62%)&#xA;&#xA;Note, I avoided renaming jmp_history to more generic insn_hist to&#xA;minimize number of lines changed and potential merge conflicts between&#xA;bpf and bpf-next trees.&#xA;&#xA;Notice also cur_hist_entry pointer reset to NULL at the beginning of&#xA;instruction verification loop. This pointer avoids the problem of&#xA;relying on last jump history entry&#39;s insn_idx to determine whether we&#xA;already have entry for current instruction or not. It can happen that we&#xA;added jump history entry because current instruction is_jmp_point(), but&#xA;also we need to add instruction flags for stack access. In this case, we&#xA;don&#39;t want to entries, so we need to reuse last added entry, if it is&#xA;present.&#xA;&#xA;Relying on insn_idx comparison has the same ambiguity problem as the one&#xA;that was fixed recently in [0], so we avoid that.&#xA;&#xA;  [0] https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/&#xA;CVE-2024-50153:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: core: Fix null-ptr-deref in target_alloc_device()&#xA;&#xA;There is a null-ptr-deref issue reported by KASAN:&#xA;&#xA;BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]&#xA;...&#xA; kasan_report+0xb9/0xf0&#xA; target_alloc_device+0xbc4/0xbe0 [target_core_mod]&#xA; core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]&#xA; target_core_init_configfs+0x205/0x420 [target_core_mod]&#xA; do_one_initcall+0xdd/0x4e0&#xA;...&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;In target_alloc_device(), if allocing memory for dev queues fails, then&#xA;dev will be freed by dev-&gt;transport-&gt;free_device(), but dev-&gt;transport&#xA;is not initialized at that time, which will lead to a null pointer&#xA;reference problem.&#xA;&#xA;Fixing this bug by freeing dev with hba-&gt;backend-&gt;ops-&gt;free_device().&#xA;CVE-2024-50203:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, arm64: Fix address emission with tag-based KASAN enabled&#xA;&#xA;When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image&#xA;struct on the stack is passed during the size calculation pass and&#xA;an address on the heap is passed during code generation. This may&#xA;cause a heap buffer overflow if the heap address is tagged because&#xA;emit_a64_mov_i64() will emit longer code than it did during the size&#xA;calculation pass. The same problem could occur without tag-based&#xA;KASAN if one of the 16-bit words of the stack address happened to&#xA;be all-ones during the size calculation pass. Fix the problem by&#xA;assuming the worst case (4 instructions) when calculating the size&#xA;of the bpf_tramp_image address emission.&#xA;CVE-2024-43853:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cgroup/cpuset: Prevent UAF in proc_cpuset_show()&#xA;&#xA;An UAF can happen when /proc/cpuset is read as reported in [1].&#xA;&#xA;This can be reproduced by the following methods:&#xA;1.add an mdelay(1000) before acquiring the cgroup_lock In the&#xA; cgroup_path_ns function.&#xA;2.$cat /proc/&lt;pid&gt;/cpuset   repeatly.&#xA;3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/&#xA;$umount /sys/fs/cgroup/cpuset/   repeatly.&#xA;&#xA;The race that cause this bug can be shown as below:&#xA;&#xA;(umount)&#x9;&#x9;|&#x9;(cat /proc/&lt;pid&gt;/cpuset)&#xA;css_release&#x9;&#x9;|&#x9;proc_cpuset_show&#xA;css_release_work_fn&#x9;|&#x9;css = task_get_css(tsk, cpuset_cgrp_id);&#xA;css_free_rwork_fn&#x9;|&#x9;cgroup_path_ns(css-&gt;cgroup, ...);&#xA;cgroup_destroy_root&#x9;|&#x9;mutex_lock(&amp;cgroup_mutex);&#xA;rebind_subsystems&#x9;|&#xA;cgroup_free_root &#x9;|&#xA;&#x9;&#x9;&#x9;|&#x9;// cgrp was freed, UAF&#xA;&#x9;&#x9;&#x9;|&#x9;cgroup_path_ns_locked(cgrp,..);&#xA;&#xA;When the cpuset is initialized, the root node top_cpuset.css.cgrp&#xA;will point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will&#xA;allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated&#xA;&amp;cgroup_root.cgrp. When the umount operation is executed,&#xA;top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.&#xA;&#xA;The problem is that when rebinding to cgrp_dfl_root, there are cases&#xA;where the cgroup_root allocated by setting up the root for cgroup v1&#xA;is cached. This could lead to a Use-After-Free (UAF) if it is&#xA;subsequently freed. The descendant cgroups of cgroup v1 can only be&#xA;freed after the css is released. However, the css of the root will never&#xA;be released, yet the cgroup_root should be freed when it is unmounted.&#xA;This means that obtaining a reference to the css of the root does&#xA;not guarantee that css.cgrp-&gt;root will not be freed.&#xA;&#xA;Fix this problem by using rcu_read_lock in proc_cpuset_show().&#xA;As cgroup_root is kfree_rcu after commit d23b5c577715&#xA;(&#34;cgroup: Make operations on the cgroup root_list RCU safe&#34;),&#xA;css-&gt;cgroup won&#39;t be freed during the critical section.&#xA;To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to&#xA;replace task_get_css with task_css.&#xA;&#xA;[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd&#xA;CVE-2024-49862:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powercap: intel_rapl: Fix off by one in get_rpi()&#xA;&#xA;The rp-&gt;priv-&gt;rpi array is either rpi_msr or rpi_tpmi which have&#xA;NR_RAPL_PRIMITIVES number of elements.  Thus the &gt; needs to be &gt;=&#xA;to prevent an off by one access.&#xA;CVE-2024-50040:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;igb: Do not bring the device up after non-fatal error&#xA;&#xA;Commit 004d25060c78 (&#34;igb: Fix igb_down hung on surprise removal&#34;)&#xA;changed igb_io_error_detected() to ignore non-fatal pcie errors in order&#xA;to avoid hung task that can happen when igb_down() is called multiple&#xA;times. This caused an issue when processing transient non-fatal errors.&#xA;igb_io_resume(), which is called after igb_io_error_detected(), assumes&#xA;that device is brought down by igb_io_error_detected() if the interface&#xA;is up. This resulted in panic with stacktrace below.&#xA;&#xA;[ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down&#xA;[  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0&#xA;[  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)&#xA;[  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000&#xA;[  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000&#xA;[  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message&#xA;[  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported.&#xA;[  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message&#xA;[  T292] pcieport 0000:00:1c.5: AER: broadcast resume message&#xA;[  T292] ------------[ cut here ]------------&#xA;[  T292] kernel BUG at net/core/dev.c:6539!&#xA;[  T292] invalid opcode: 0000 [#1] PREEMPT SMP&#xA;[  T292] RIP: 0010:napi_enable+0x37/0x40&#xA;[  T292] Call Trace:&#xA;[  T292]  &lt;TASK&gt;&#xA;[  T292]  ? die+0x33/0x90&#xA;[  T292]  ? do_trap+0xdc/0x110&#xA;[  T292]  ? napi_enable+0x37/0x40&#xA;[  T292]  ? do_error_trap+0x70/0xb0&#xA;[  T292]  ? napi_enable+0x37/0x40&#xA;[  T292]  ? napi_enable+0x37/0x40&#xA;[  T292]  ? exc_invalid_op+0x4e/0x70&#xA;[  T292]  ? napi_enable+0x37/0x40&#xA;[  T292]  ? asm_exc_invalid_op+0x16/0x20&#xA;[  T292]  ? napi_enable+0x37/0x40&#xA;[  T292]  igb_up+0x41/0x150&#xA;[  T292]  igb_io_resume+0x25/0x70&#xA;[  T292]  report_resume+0x54/0x70&#xA;[  T292]  ? report_frozen_detected+0x20/0x20&#xA;[  T292]  pci_walk_bus+0x6c/0x90&#xA;[  T292]  ? aer_print_port_info+0xa0/0xa0&#xA;[  T292]  pcie_do_recovery+0x22f/0x380&#xA;[  T292]  aer_process_err_devices+0x110/0x160&#xA;[  T292]  aer_isr+0x1c1/0x1e0&#xA;[  T292]  ? disable_irq_nosync+0x10/0x10&#xA;[  T292]  irq_thread_fn+0x1a/0x60&#xA;[  T292]  irq_thread+0xe3/0x1a0&#xA;[  T292]  ? irq_set_affinity_notifier+0x120/0x120&#xA;[  T292]  ? irq_affinity_notify+0x100/0x100&#xA;[  T292]  kthread+0xe2/0x110&#xA;[  T292]  ? kthread_complete_and_exit+0x20/0x20&#xA;[  T292]  ret_from_fork+0x2d/0x50&#xA;[  T292]  ? kthread_complete_and_exit+0x20/0x20&#xA;[  T292]  ret_from_fork_asm+0x11/0x20&#xA;[  T292]  &lt;/TASK&gt;&#xA;&#xA;To fix this issue igb_io_resume() checks if the interface is running and&#xA;the device is not down this means igb_io_error_detected() did not bring&#xA;the device down and there is no need to bring it up.&#xA;CVE-2024-50064:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;zram: free secondary algorithms names&#xA;&#xA;We need to kfree() secondary algorithms names when reset zram device that&#xA;had multi-streams, otherwise we leak memory.&#xA;&#xA;[[email protected]: kfree(NULL) is legal]&#xA;CVE-2022-49901:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;blk-mq: Fix kmemleak in blk_mq_init_allocated_queue&#xA;&#xA;There is a kmemleak caused by modprobe null_blk.ko&#xA;&#xA;unreferenced object 0xffff8881acb1f000 (size 1024):&#xA;  comm &#34;modprobe&#34;, pid 836, jiffies 4294971190 (age 27.068s)&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........&#xA;    ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff  .........S......&#xA;  backtrace:&#xA;    [&lt;000000004a10c249&gt;] kmalloc_node_trace+0x22/0x60&#xA;    [&lt;00000000648f7950&gt;] blk_mq_alloc_and_init_hctx+0x289/0x350&#xA;    [&lt;00000000af06de0e&gt;] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0&#xA;    [&lt;00000000e00c1872&gt;] blk_mq_init_allocated_queue+0x48c/0x1440&#xA;    [&lt;00000000d16b4e68&gt;] __blk_mq_alloc_disk+0xc8/0x1c0&#xA;    [&lt;00000000d10c98c3&gt;] 0xffffffffc450d69d&#xA;    [&lt;00000000b9299f48&gt;] 0xffffffffc4538392&#xA;    [&lt;0000000061c39ed6&gt;] do_one_initcall+0xd0/0x4f0&#xA;    [&lt;00000000b389383b&gt;] do_init_module+0x1a4/0x680&#xA;    [&lt;0000000087cf3542&gt;] load_module+0x6249/0x7110&#xA;    [&lt;00000000beba61b8&gt;] __do_sys_finit_module+0x140/0x200&#xA;    [&lt;00000000fdcfff51&gt;] do_syscall_64+0x35/0x80&#xA;    [&lt;000000003c0f1f71&gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA;&#xA;That is because q-&gt;ma_ops is set to NULL before blk_release_queue is&#xA;called.&#xA;&#xA;blk_mq_init_queue_data&#xA;  blk_mq_init_allocated_queue&#xA;    blk_mq_realloc_hw_ctxs&#xA;      for (i = 0; i &lt; set-&gt;nr_hw_queues; i++) {&#xA;        old_hctx = xa_load(&amp;q-&gt;hctx_table, i);&#xA;        if (!blk_mq_alloc_and_init_hctx(.., i, ..))&#x9;&#x9;[1]&#xA;          if (!old_hctx)&#xA;&#x9;    break;&#xA;&#xA;      xa_for_each_start(&amp;q-&gt;hctx_table, j, hctx, j)&#xA;        blk_mq_exit_hctx(q, set, hctx, j); &#x9;&#x9;&#x9;[2]&#xA;&#xA;    if (!q-&gt;nr_hw_queues)&#x9;&#x9;&#x9;&#x9;&#x9;[3]&#xA;      goto err_hctxs;&#xA;&#xA;  err_exit:&#xA;      q-&gt;mq_ops = NULL;&#x9;&#x9;&#x9;  &#x9;&#x9;&#x9;[4]&#xA;&#xA;  blk_put_queue&#xA;    blk_release_queue&#xA;      if (queue_is_mq(q))&#x9;&#x9;&#x9;&#x9;&#x9;[5]&#xA;        blk_mq_release(q);&#xA;&#xA;[1]: blk_mq_alloc_and_init_hctx failed at i != 0.&#xA;[2]: The hctxs allocated by [1] are moved to q-&gt;unused_hctx_list and&#xA;will be cleaned up in blk_mq_release.&#xA;[3]: q-&gt;nr_hw_queues is 0.&#xA;[4]: Set q-&gt;mq_ops to NULL.&#xA;[5]: queue_is_mq returns false due to [4]. And blk_mq_release&#xA;will not be called. The hctxs in q-&gt;unused_hctx_list are leaked.&#xA;&#xA;To fix it, call blk_release_queue in exception path.&#xA;CVE-2024-42315:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;exfat: fix potential deadlock on __exfat_get_dentry_set&#xA;&#xA;When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array&#xA;is allocated in __exfat_get_entry_set. The problem is that the bh-array is&#xA;allocated with GFP_KERNEL. It does not make sense. In the following cases,&#xA;a deadlock for sbi-&gt;s_lock between the two processes may occur.&#xA;&#xA;       CPU0                CPU1&#xA;       ----                ----&#xA;  kswapd&#xA;   balance_pgdat&#xA;    lock(fs_reclaim)&#xA;                      exfat_iterate&#xA;                       lock(&amp;sbi-&gt;s_lock)&#xA;                       exfat_readdir&#xA;                        exfat_get_uniname_from_ext_entry&#xA;                         exfat_get_dentry_set&#xA;                          __exfat_get_dentry_set&#xA;                           kmalloc_array&#xA;                            ...&#xA;                            lock(fs_reclaim)&#xA;    ...&#xA;    evict&#xA;     exfat_evict_inode&#xA;      lock(&amp;sbi-&gt;s_lock)&#xA;&#xA;To fix this, let&#39;s allocate bh-array with GFP_NOFS.&#xA;CVE-2024-45009:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mptcp: pm: only decrement add_addr_accepted for MPJ req&#xA;&#xA;Adding the following warning ...&#xA;&#xA;  WARN_ON_ONCE(msk-&gt;pm.add_addr_accepted == 0)&#xA;&#xA;... before decrementing the add_addr_accepted counter helped to find a&#xA;bug when running the &#34;remove single subflow&#34; subtest from the&#xA;mptcp_join.sh selftest.&#xA;&#xA;Removing a &#39;subflow&#39; endpoint will first trigger a RM_ADDR, then the&#xA;subflow closure. Before this patch, and upon the reception of the&#xA;RM_ADDR, the other peer will then try to decrement this&#xA;add_addr_accepted. That&#39;s not correct because the attached subflows have&#xA;not been created upon the reception of an ADD_ADDR.&#xA;&#xA;A way to solve that is to decrement the counter only if the attached&#xA;subflow was an MP_JOIN to a remote id that was not 0, and initiated by&#xA;the host receiving the RM_ADDR.&#xA;CVE-2024-49892:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Initialize get_bytes_per_element&#39;s default to 1&#xA;&#xA;Variables, used as denominators and maybe not assigned to other values,&#xA;should not be 0. bytes_per_element_y &amp; bytes_per_element_c are&#xA;initialized by get_bytes_per_element() which should never return 0.&#xA;&#xA;This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.&#xA;CVE-2024-50085:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow&#xA;&#xA;Syzkaller reported this splat:&#xA;&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881&#xA;  Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662&#xA;&#xA;  CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0&#xA;  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   __dump_stack lib/dump_stack.c:94 [inline]&#xA;   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA;   print_address_description mm/kasan/report.c:377 [inline]&#xA;   print_report+0xc3/0x620 mm/kasan/report.c:488&#xA;   kasan_report+0xd9/0x110 mm/kasan/report.c:601&#xA;   mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881&#xA;   mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline]&#xA;   mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572&#xA;   mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603&#xA;   genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115&#xA;   genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]&#xA;   genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210&#xA;   netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551&#xA;   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219&#xA;   netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]&#xA;   netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357&#xA;   netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901&#xA;   sock_sendmsg_nosec net/socket.c:729 [inline]&#xA;   __sock_sendmsg net/socket.c:744 [inline]&#xA;   ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607&#xA;   ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661&#xA;   __sys_sendmsg+0x117/0x1f0 net/socket.c:2690&#xA;   do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]&#xA;   __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386&#xA;   do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411&#xA;   entry_SYSENTER_compat_after_hwframe+0x84/0x8e&#xA;  RIP: 0023:0xf7fe4579&#xA;  Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 &lt;5d&gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00&#xA;  RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172&#xA;  RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140&#xA;  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;  RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;  R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000&#xA;  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;   &lt;/TASK&gt;&#xA;&#xA;  Allocated by task 5387:&#xA;   kasan_save_stack+0x33/0x60 mm/kasan/common.c:47&#xA;   kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA;   poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA;   __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394&#xA;   kmalloc_noprof include/linux/slab.h:878 [inline]&#xA;   kzalloc_noprof include/linux/slab.h:1014 [inline]&#xA;   subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803&#xA;   subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956&#xA;   __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline]&#xA;   tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167&#xA;   mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764&#xA;   __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592&#xA;   mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642&#xA;   mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline]&#xA;   mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943&#xA;   mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777&#xA;   process_one_work+0x958/0x1b30 kernel/workqueue.c:3229&#xA;   process_scheduled_works kernel/workqueue.c:3310 [inline]&#xA;   worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391&#xA;   kthread+0x2c1/0x3a0 kernel/kthread.c:389&#xA;   ret_from_fork+0x45/0x80 arch/x86/ke&#xA;---truncated---&#xA;CVE-2024-50199:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/swapfile: skip HugeTLB pages for unuse_vma&#xA;&#xA;I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The&#xA;problem can be reproduced by the following steps:&#xA;&#xA; 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.&#xA; 2. Swapout the above anonymous memory.&#xA; 3. run swapoff and we will get a bad pud error in kernel message:&#xA;&#xA;  mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)&#xA;&#xA;We can tell that pud_clear_bad is called by pud_none_or_clear_bad in&#xA;unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never&#xA;be freed because we lost it from page table.  We can skip HugeTLB pages&#xA;for unuse_vma to fix it.&#xA;CVE-2024-27397:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: use timestamp to check for set element timeout&#xA;&#xA;Add a timestamp field at the beginning of the transaction, store it&#xA;in the nftables per-netns area.&#xA;&#xA;Update set backend .insert, .deactivate and sync gc path to use the&#xA;timestamp, this avoids that an element expires while control plane&#xA;transaction is still unfinished.&#xA;&#xA;.lookup and .update, which are used from packet path, still use the&#xA;current time to check if the element has expired. And .get path and dump&#xA;also since this runs lockless under rcu read size lock. Then, there is&#xA;async gc which also needs to check the current time since it runs&#xA;asynchronously from a workqueue.&#xA;CVE-2024-36927:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv4: Fix uninit-value access in __ip_make_skb()&#xA;&#xA;KMSAN reported uninit-value access in __ip_make_skb() [1].  __ip_make_skb()&#xA;tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a&#xA;race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL&#xA;while __ip_make_skb() is running, the function will access icmphdr in the&#xA;skb even if it is not included. This causes the issue reported by KMSAN.&#xA;&#xA;Check FLOWI_FLAG_KNOWN_NH on fl4-&gt;flowi4_flags instead of testing HDRINCL&#xA;on the socket.&#xA;&#xA;Also, fl4-&gt;fl4_icmp_type and fl4-&gt;fl4_icmp_code are not initialized. These&#xA;are union in struct flowi4 and are implicitly initialized by&#xA;flowi4_init_output(), but we should not rely on specific union layout.&#xA;&#xA;Initialize these explicitly in raw_sendmsg().&#xA;&#xA;[1]&#xA;BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481&#xA; __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481&#xA; ip_finish_skb include/net/ip.h:243 [inline]&#xA; ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508&#xA; raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654&#xA; inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0x274/0x3c0 net/socket.c:745&#xA; __sys_sendto+0x62c/0x7b0 net/socket.c:2191&#xA; __do_sys_sendto net/socket.c:2203 [inline]&#xA; __se_sys_sendto net/socket.c:2199 [inline]&#xA; __x64_sys_sendto+0x130/0x200 net/socket.c:2199&#xA; do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;&#xA;Uninit was created at:&#xA; slab_post_alloc_hook mm/slub.c:3804 [inline]&#xA; slab_alloc_node mm/slub.c:3845 [inline]&#xA; kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888&#xA; kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577&#xA; __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668&#xA; alloc_skb include/linux/skbuff.h:1318 [inline]&#xA; __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128&#xA; ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365&#xA; raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648&#xA; inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg+0x274/0x3c0 net/socket.c:745&#xA; __sys_sendto+0x62c/0x7b0 net/socket.c:2191&#xA; __do_sys_sendto net/socket.c:2203 [inline]&#xA; __se_sys_sendto net/socket.c:2199 [inline]&#xA; __x64_sys_sendto+0x130/0x200 net/socket.c:2199&#xA; do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;&#xA;CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014&#xA;CVE-2024-56686:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2024-36941:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: nl80211: don&#39;t free NULL coalescing rule&#xA;&#xA;If the parsing fails, we can dereference a NULL pointer here.&#xA;CVE-2025-21651:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hns3: don&#39;t auto enable misc vector&#xA;&#xA;Currently, there is a time window between misc irq enabled&#xA;and service task inited. If an interrupte is reported at&#xA;this time, it will cause warning like below:&#xA;&#xA;[   16.324639] Call trace:&#xA;[   16.324641]  __queue_delayed_work+0xb8/0xe0&#xA;[   16.324643]  mod_delayed_work_on+0x78/0xd0&#xA;[   16.324655]  hclge_errhand_task_schedule+0x58/0x90 [hclge]&#xA;[   16.324662]  hclge_misc_irq_handle+0x168/0x240 [hclge]&#xA;[   16.324666]  __handle_irq_event_percpu+0x64/0x1e0&#xA;[   16.324667]  handle_irq_event+0x80/0x170&#xA;[   16.324670]  handle_fasteoi_edge_irq+0x110/0x2bc&#xA;[   16.324671]  __handle_domain_irq+0x84/0xfc&#xA;[   16.324673]  gic_handle_irq+0x88/0x2c0&#xA;[   16.324674]  el1_irq+0xb8/0x140&#xA;[   16.324677]  arch_cpu_idle+0x18/0x40&#xA;[   16.324679]  default_idle_call+0x5c/0x1bc&#xA;[   16.324682]  cpuidle_idle_call+0x18c/0x1c4&#xA;[   16.324684]  do_idle+0x174/0x17c&#xA;[   16.324685]  cpu_startup_entry+0x30/0x6c&#xA;[   16.324687]  secondary_start_kernel+0x1a4/0x280&#xA;[   16.324688] ---[ end trace 6aa0bff672a964aa ]---&#xA;&#xA;So don&#39;t auto enable misc vector when request irq..&#xA;CVE-2025-21650:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue&#xA;&#xA;The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs&#xA;1024-1279 are in different BAR space addresses. However,&#xA;hclge_fetch_pf_reg does not distinguish the tqp space information when&#xA;reading the tqp space information. When the number of TQPs is greater&#xA;than 1024, access bar space overwriting occurs.&#xA;The problem of different segments has been considered during the&#xA;initialization of tqp.io_base. Therefore, tqp.io_base is directly used&#xA;when the queue is read in hclge_fetch_pf_reg.&#xA;&#xA;The error message:&#xA;&#xA;Unable to handle kernel paging request at virtual address ffff800037200000&#xA;pc : hclge_fetch_pf_reg+0x138/0x250 [hclge]&#xA;lr : hclge_get_regs+0x84/0x1d0 [hclge]&#xA;Call trace:&#xA; hclge_fetch_pf_reg+0x138/0x250 [hclge]&#xA; hclge_get_regs+0x84/0x1d0 [hclge]&#xA; hns3_get_regs+0x2c/0x50 [hns3]&#xA; ethtool_get_regs+0xf4/0x270&#xA; dev_ethtool+0x674/0x8a0&#xA; dev_ioctl+0x270/0x36c&#xA; sock_do_ioctl+0x110/0x2a0&#xA; sock_ioctl+0x2ac/0x530&#xA; __arm64_sys_ioctl+0xa8/0x100&#xA; invoke_syscall+0x4c/0x124&#xA; el0_svc_common.constprop.0+0x140/0x15c&#xA; do_el0_svc+0x30/0xd0&#xA; el0_svc+0x1c/0x2c&#xA; el0_sync_handler+0xb0/0xb4&#xA; el0_sync+0x168/0x180&#xA;CVE-2022-48867:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: idxd: Prevent use after free on completion memory&#xA;&#xA;On driver unload any pending descriptors are flushed at the&#xA;time the interrupt is freed:&#xA;idxd_dmaengine_drv_remove() -&gt;&#xA;&#x9;drv_disable_wq() -&gt;&#xA;&#x9;&#x9;idxd_wq_free_irq() -&gt;&#xA;&#x9;&#x9;&#x9;idxd_flush_pending_descs().&#xA;&#xA;If there are any descriptors present that need to be flushed this&#xA;flow triggers a &#34;not present&#34; page fault as below:&#xA;&#xA; BUG: unable to handle page fault for address: ff391c97c70c9040&#xA; #PF: supervisor read access in kernel mode&#xA; #PF: error_code(0x0000) - not-present page&#xA;&#xA;The address that triggers the fault is the address of the&#xA;descriptor that was freed moments earlier via:&#xA;drv_disable_wq()-&gt;idxd_wq_free_resources()&#xA;&#xA;Fix the use after free by freeing the descriptors after any possible&#xA;usage. This is done after idxd_wq_reset() to ensure that the memory&#xA;remains accessible during possible completion writes by the device.&#xA;CVE-2024-44935:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: Fix null-ptr-deref in reuseport_add_sock().&#xA;&#xA;syzbot reported a null-ptr-deref while accessing sk2-&gt;sk_reuseport_cb in&#xA;reuseport_add_sock(). [0]&#xA;&#xA;The repro first creates a listener with SO_REUSEPORT.  Then, it creates&#xA;another listener on the same port and concurrently closes the first&#xA;listener.&#xA;&#xA;The second listen() calls reuseport_add_sock() with the first listener as&#xA;sk2, where sk2-&gt;sk_reuseport_cb is not expected to be cleared concurrently,&#xA;but the close() does clear it by reuseport_detach_sock().&#xA;&#xA;The problem is SCTP does not properly synchronise reuseport_alloc(),&#xA;reuseport_add_sock(), and reuseport_detach_sock().&#xA;&#xA;The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must&#xA;provide synchronisation for sockets that are classified into the same&#xA;reuseport group.&#xA;&#xA;Otherwise, such sockets form multiple identical reuseport groups, and&#xA;all groups except one would be silently dead.&#xA;&#xA;  1. Two sockets call listen() concurrently&#xA;  2. No socket in the same group found in sctp_ep_hashtable[]&#xA;  3. Two sockets call reuseport_alloc() and form two reuseport groups&#xA;  4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives&#xA;      incoming packets&#xA;&#xA;Also, the reported null-ptr-deref could occur.&#xA;&#xA;TCP/UDP guarantees that would not happen by holding the hash bucket lock.&#xA;&#xA;Let&#39;s apply the locking strategy to __sctp_hash_endpoint() and&#xA;__sctp_unhash_endpoint().&#xA;&#xA;[0]:&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]&#xA;CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024&#xA;RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350&#xA;Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 &lt;42&gt; 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14&#xA;RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202&#xA;RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000&#xA;RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012&#xA;RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385&#xA;R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0&#xA;R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;FS:  00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __sctp_hash_endpoint net/sctp/input.c:762 [inline]&#xA; sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790&#xA; sctp_listen_start net/sctp/socket.c:8570 [inline]&#xA; sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625&#xA; __sys_listen_socket net/socket.c:1883 [inline]&#xA; __sys_listen+0x1b7/0x230 net/socket.c:1894&#xA; __do_sys_listen net/socket.c:1902 [inline]&#xA; __se_sys_listen net/socket.c:1900 [inline]&#xA; __x64_sys_listen+0x5a/0x70 net/socket.c:1900&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f24e46039b9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032&#xA;RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9&#xA;RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004&#xA;RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0&#xA;R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c&#xA;R13:&#xA;---truncated---&#xA;CVE-2024-42287:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Complete command early within lock&#xA;&#xA;A crash was observed while performing NPIV and FW reset,&#xA;&#xA; BUG: kernel NULL pointer dereference, address: 000000000000001c&#xA; #PF: supervisor read access in kernel mode&#xA; #PF: error_code(0x0000) - not-present page&#xA; PGD 0 P4D 0&#xA; Oops: 0000 1 PREEMPT_RT SMP NOPTI&#xA; RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0&#xA; RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246&#xA; RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002&#xA; RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0&#xA; RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034&#xA; R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000&#xA; R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000&#xA; FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000&#xA; CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; PKRU: 55555554&#xA; Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body+0x1a/0x60&#xA; ? page_fault_oops+0x16f/0x4a0&#xA; ? do_user_addr_fault+0x174/0x7f0&#xA; ? exc_page_fault+0x69/0x1a0&#xA; ? asm_exc_page_fault+0x22/0x30&#xA; ? dma_direct_unmap_sg+0x51/0x1e0&#xA; ? preempt_count_sub+0x96/0xe0&#xA; qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]&#xA; qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]&#xA; __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]&#xA;&#xA;The command completion was done early while aborting the commands in driver&#xA;unload path but outside lock to avoid the WARN_ON condition of performing&#xA;dma_free_attr within the lock. However this caused race condition while&#xA;command completion via multiple paths causing system crash.&#xA;&#xA;Hence complete the command early in unload path but within the lock to&#xA;avoid race condition.&#xA;CVE-2024-46833:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hns3: void array out of bound when loop tnl_num&#xA;&#xA;When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes&#xA;from hardware and the length of array is a fixed value. To void array out&#xA;of bound, make sure the loop time is not greater than the length of array&#xA;CVE-2024-47670:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: add bounds checking to ocfs2_xattr_find_entry()&#xA;&#xA;Add a paranoia check to make sure it doesn&#39;t stray beyond valid memory&#xA;region containing ocfs2 xattr entries when scanning for a match.  It will&#xA;prevent out-of-bound access in case of crafted images.&#xA;CVE-2023-53073:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf/x86/amd/core: Always clear status for idx&#xA;&#xA;The variable &#39;status&#39; (which contains the unhandled overflow bits) is&#xA;not being properly masked in some cases, displaying the following&#xA;warning:&#xA;&#xA;  WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270&#xA;&#xA;This seems to be happening because the loop is being continued before&#xA;the status bit being unset, in case x86_perf_event_set_period()&#xA;returns 0. This is also causing an inconsistency because the &#34;handled&#34;&#xA;counter is incremented, but the status bit is not cleaned.&#xA;&#xA;Move the bit cleaning together above, together when the &#34;handled&#34;&#xA;counter is incremented.&#xA;CVE-2024-24857:A race condition was found in the Linux kernel&#39;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.&#xA;CVE-2024-24858:A race condition was found in the Linux kernel&#39;s net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.&#xA;CVE-2024-24859:A race condition was found in the Linux kernel&#39;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;CVE-2024-35785:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tee: optee: Fix kernel panic caused by incorrect error handling&#xA;&#xA;The error path while failing to register devices on the TEE bus has a&#xA;bug leading to kernel panic as follows:&#xA;&#xA;[   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c&#xA;[   15.406913] Mem abort info:&#xA;[   15.409722]   ESR = 0x0000000096000005&#xA;[   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[   15.418814]   SET = 0, FnV = 0&#xA;[   15.421878]   EA = 0, S1PTW = 0&#xA;[   15.425031]   FSC = 0x05: level 1 translation fault&#xA;[   15.429922] Data abort info:&#xA;[   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000&#xA;[   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;[   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;[   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000&#xA;[   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000&#xA;[   15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP&#xA;&#xA;Commit 7269cba53d90 (&#34;tee: optee: Fix supplicant based device enumeration&#34;)&#xA;lead to the introduction of this bug. So fix it appropriately.&#xA;CVE-2024-42318:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;landlock: Don&#39;t lose track of restrictions on cred_transfer&#xA;&#xA;When a process&#39; cred struct is replaced, this _almost_ always invokes&#xA;the cred_prepare LSM hook; but in one special case (when&#xA;KEYCTL_SESSION_TO_PARENT updates the parent&#39;s credentials), the&#xA;cred_transfer LSM hook is used instead.  Landlock only implements the&#xA;cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes&#xA;all information on Landlock restrictions to be lost.&#xA;&#xA;This basically means that a process with the ability to use the fork()&#xA;and keyctl() syscalls can get rid of all Landlock restrictions on&#xA;itself.&#xA;&#xA;Fix it by adding a cred_transfer hook that does the same thing as the&#xA;existing cred_prepare hook. (Implemented by having hook_cred_prepare()&#xA;call hook_cred_transfer() so that the two functions are less likely to&#xA;accidentally diverge in the future.)&#xA;CVE-2024-42306:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;udf: Avoid using corrupted block bitmap buffer&#xA;&#xA;When the filesystem block bitmap is corrupted, we detect the corruption&#xA;while loading the bitmap and fail the allocation with error. However the&#xA;next allocation from the same bitmap will notice the bitmap buffer is&#xA;already loaded and tries to allocate from the bitmap with mixed results&#xA;(depending on the exact nature of the bitmap corruption). Fix the&#xA;problem by using BH_verified bit to indicate whether the bitmap is valid&#xA;or not.&#xA;CVE-2024-42302:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal&#xA;&#xA;Keith reports a use-after-free when a DPC event occurs concurrently to&#xA;hot-removal of the same portion of the hierarchy:&#xA;&#xA;The dpc_handler() awaits readiness of the secondary bus below the&#xA;Downstream Port where the DPC event occurred.  To do so, it polls the&#xA;config space of the first child device on the secondary bus.  If that&#xA;child device is concurrently removed, accesses to its struct pci_dev&#xA;cause the kernel to oops.&#xA;&#xA;That&#39;s because pci_bridge_wait_for_secondary_bus() neglects to hold a&#xA;reference on the child device.  Before v6.3, the function was only&#xA;called on resume from system sleep or on runtime resume.  Holding a&#xA;reference wasn&#39;t necessary back then because the pciehp IRQ thread&#xA;could never run concurrently.  (On resume from system sleep, IRQs are&#xA;not enabled until after the resume_noirq phase.  And runtime resume is&#xA;always awaited before a PCI device is removed.)&#xA;&#xA;However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also&#xA;called on a DPC event.  Commit 53b54ad074de (&#34;PCI/DPC: Await readiness&#xA;of secondary bus after reset&#34;), which introduced that, failed to&#xA;appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a&#xA;reference on the child device because dpc_handler() and pciehp may&#xA;indeed run concurrently.  The commit was backported to v5.10+ stable&#xA;kernels, so that&#39;s the oldest one affected.&#xA;&#xA;Add the missing reference acquisition.&#xA;&#xA;Abridged stack trace:&#xA;&#xA;  BUG: unable to handle page fault for address: 00000000091400c0&#xA;  CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0&#xA;  RIP: pci_bus_read_config_dword+0x17/0x50&#xA;  pci_dev_wait()&#xA;  pci_bridge_wait_for_secondary_bus()&#xA;  dpc_reset_link()&#xA;  pcie_do_recovery()&#xA;  dpc_handler()&#xA;CVE-2024-43861:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: qmi_wwan: fix memory leak for not ip packets&#xA;&#xA;Free the unused skb when not ip packets arrive.&#xA;CVE-2024-43872:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/hns: Fix soft lockup under heavy CEQE load&#xA;&#xA;CEQEs are handled in interrupt handler currently. This may cause the&#xA;CPU core staying in interrupt context too long and lead to soft lockup&#xA;under heavy load.&#xA;&#xA;Handle CEQEs in BH workqueue and set an upper limit for the number of&#xA;CEQE handled by a single call of work handler.&#xA;CVE-2024-41088:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: mcp251xfd: fix infinite loop when xmit fails&#xA;&#xA;When the mcp251xfd_start_xmit() function fails, the driver stops&#xA;processing messages, and the interrupt routine does not return,&#xA;running indefinitely even after killing the running application.&#xA;&#xA;Error messages:&#xA;[  441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16&#xA;[  441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).&#xA;... and repeat forever.&#xA;&#xA;The issue can be triggered when multiple devices share the same SPI&#xA;interface. And there is concurrent access to the bus.&#xA;&#xA;The problem occurs because tx_ring-&gt;head increments even if&#xA;mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX&#xA;package while still expecting a response in&#xA;mcp251xfd_handle_tefif_one().&#xA;&#xA;Resolve the issue by starting a workqueue to write the tx obj&#xA;synchronously if err = -EBUSY. In case of another error, decrement&#xA;tx_ring-&gt;head, remove skb from the echo stack, and drop the message.&#xA;&#xA;[mkl: use more imperative wording in patch description]&#xA;CVE-2024-42070:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers&#xA;&#xA;register store validation for NFT_DATA_VALUE is conditional, however,&#xA;the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This&#xA;only requires a new helper function to infer the register type from the&#xA;set datatype so this conditional check can be removed. Otherwise,&#xA;pointer to chain object can be leaked through the registers.&#xA;CVE-2024-42131:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm: avoid overflows in dirty throttling logic&#xA;&#xA;The dirty throttling logic is interspersed with assumptions that dirty&#xA;limits in PAGE_SIZE units fit into 32-bit (so that various multiplications&#xA;fit into 64-bits).  If limits end up being larger, we will hit overflows,&#xA;possible divisions by 0 etc.  Fix these problems by never allowing so&#xA;large dirty limits as they have dubious practical value anyway.  For&#xA;dirty_bytes / dirty_background_bytes interfaces we can just refuse to set&#xA;so large limits.  For dirty_ratio / dirty_background_ratio it isn&#39;t so&#xA;simple as the dirty limit is computed from the amount of available memory&#xA;which can change due to memory hotplug etc.  So when converting dirty&#xA;limits from ratios to numbers of pages, we just don&#39;t allow the result to&#xA;exceed UINT_MAX.&#xA;&#xA;This is root-only triggerable problem which occurs when the operator&#xA;sets dirty limits to &gt;16 TB.&#xA;CVE-2024-42127:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/lima: fix shared irq handling on driver remove&#xA;&#xA;lima uses a shared interrupt, so the interrupt handlers must be prepared&#xA;to be called at any time. At driver removal time, the clocks are&#xA;disabled early and the interrupts stay registered until the very end of&#xA;the remove process due to the devm usage.&#xA;This is potentially a bug as the interrupts access device registers&#xA;which assumes clocks are enabled. A crash can be triggered by removing&#xA;the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.&#xA;This patch frees the interrupts at each lima device finishing callback&#xA;so that the handlers are already unregistered by the time we fully&#xA;disable clocks.&#xA;CVE-2024-42232:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: fix race between delayed_work() and ceph_monc_stop()&#xA;&#xA;The way the delayed work is handled in ceph_monc_stop() is prone to&#xA;races with mon_fault() and possibly also finish_hunting().  Both of&#xA;these can requeue the delayed work which wouldn&#39;t be canceled by any of&#xA;the following code in case that happens after cancel_delayed_work_sync()&#xA;runs -- __close_session() doesn&#39;t mess with the delayed work in order&#xA;to avoid interfering with the hunting interval logic.  This part was&#xA;missed in commit b5d91704f53e (&#34;libceph: behave in mon_fault() if&#xA;cur_mon &lt; 0&#34;) and use-after-free can still ensue on monc and objects&#xA;that hang off of it, with monc-&gt;auth and monc-&gt;monmap being&#xA;particularly susceptible to quickly being reused.&#xA;&#xA;To fix this:&#xA;&#xA;- clear monc-&gt;cur_mon and monc-&gt;hunting as part of closing the session&#xA;  in ceph_monc_stop()&#xA;- bail from delayed_work() if monc-&gt;cur_mon is cleared, similar to how&#xA;  it&#39;s done in mon_fault() and finish_hunting() (based on monc-&gt;hunting)&#xA;- call cancel_delayed_work_sync() after the session is closed&#xA;CVE-2024-42236:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()&#xA;&#xA;Userspace provided string &#39;s&#39; could trivially have the length zero. Left&#xA;unchecked this will firstly result in an OOB read in the form&#xA;`if (str[0 - 1] == &#39;\n&#39;) followed closely by an OOB write in the form&#xA;`str[0 - 1] = &#39;\0&#39;`.&#xA;&#xA;There is already a validating check to catch strings that are too long.&#xA;Let&#39;s supply an additional check for invalid strings that are too short.&#xA;CVE-2024-42283:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: nexthop: Initialize all fields in dumped nexthops&#xA;&#xA;struct nexthop_grp contains two reserved fields that are not initialized by&#xA;nla_put_nh_group(), and carry garbage. This can be observed e.g. with&#xA;strace (edited for clarity):&#xA;&#xA;    # ip nexthop add id 1 dev lo&#xA;    # ip nexthop add id 101 group 1&#xA;    # strace -e recvmsg ip nexthop get id 101&#xA;    ...&#xA;    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},&#xA;                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52&#xA;&#xA;The fields are reserved and therefore not currently used. But as they are, they&#xA;leak kernel memory, and the fact they are not just zero complicates repurposing&#xA;of the fields for new ends. Initialize the full structure.&#xA;CVE-2024-42310:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes&#xA;&#xA;In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()&#xA;is assigned to mode, which will lead to a NULL pointer dereference on&#xA;failure of drm_mode_duplicate(). Add a check to avoid npd.&#xA;CVE-2024-42305:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: check dot and dotdot of dx_root before making dir indexed&#xA;&#xA;Syzbot reports a issue as follows:&#xA;============================================&#xA;BUG: unable to handle page fault for address: ffffed11022e24fe&#xA;PGD 23ffee067 P4D 23ffee067 PUD 0&#xA;Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341&#xA; ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451&#xA; ext4_rename fs/ext4/namei.c:3936 [inline]&#xA; ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214&#xA;[...]&#xA;============================================&#xA;&#xA;The immediate cause of this problem is that there is only one valid dentry&#xA;for the block to be split during do_split, so split==0 results in out of&#xA;bounds accesses to the map triggering the issue.&#xA;&#xA;    do_split&#xA;      unsigned split&#xA;      dx_make_map&#xA;       count = 1&#xA;      split = count/2 = 0;&#xA;      continued = hash2 == map[split - 1].hash;&#xA;       ---&gt; map[4294967295]&#xA;&#xA;The maximum length of a filename is 255 and the minimum block size is 1024,&#xA;so it is always guaranteed that the number of entries is greater than or&#xA;equal to 2 when do_split() is called.&#xA;&#xA;But syzbot&#39;s crafted image has no dot and dotdot in dir, and the dentry&#xA;distribution in dirblock is as follows:&#xA;&#xA;  bus     dentry1          hole           dentry2           free&#xA;|xx--|xx-------------|...............|xx-------------|...............|&#xA;0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024&#xA;&#xA;So when renaming dentry1 increases its name_len length by 1, neither hole&#xA;nor free is sufficient to hold the new dentry, and make_indexed_dir() is&#xA;called.&#xA;&#xA;In make_indexed_dir() it is assumed that the first two entries of the&#xA;dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root&#xA;because they are treated as dot and dotdot, and only dentry2 is moved&#xA;to the new leaf block. That&#39;s why count is equal to 1.&#xA;&#xA;Therefore add the ext4_check_dx_root() helper function to add more sanity&#xA;checks to dot and dotdot before starting the conversion to avoid the above&#xA;issue.&#xA;CVE-2024-43839:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bna: adjust &#39;name&#39; buf size of bna_tcb and bna_ccb structures&#xA;&#xA;To have enough space to write all possible sprintf() args. Currently&#xA;&#39;name&#39; size is 16, but the first &#39;%s&#39; specifier may already need at&#xA;least 16 characters, since &#39;bnad-&gt;netdev-&gt;name&#39; is used there.&#xA;&#xA;For &#39;%d&#39; specifiers, assume that they require:&#xA; * 1 char for &#39;tx_id + tx_info-&gt;tcb[i]-&gt;id&#39; sum, BNAD_MAX_TXQ_PER_TX is 8&#xA; * 2 chars for &#39;rx_id + rx_info-&gt;rx_ctrl[i].ccb-&gt;id&#39;, BNAD_MAX_RXP_PER_RX&#xA;   is 16&#xA;&#xA;And replace sprintf with snprintf.&#xA;&#xA;Detected using the static analysis tool - Svace.&#xA;CVE-2024-43840:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG&#xA;&#xA;When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls&#xA;__bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them&#xA;the struct bpf_tramp_image *im pointer as an argument in R0.&#xA;&#xA;The trampoline generation code uses emit_addr_mov_i64() to emit&#xA;instructions for moving the bpf_tramp_image address into R0, but&#xA;emit_addr_mov_i64() assumes the address to be in the vmalloc() space&#xA;and uses only 48 bits. Because bpf_tramp_image is allocated using&#xA;kzalloc(), its address can use more than 48-bits, in this case the&#xA;trampoline will pass an invalid address to __bpf_tramp_enter/exit()&#xA;causing a kernel crash.&#xA;&#xA;Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()&#xA;as it can work with addresses that are greater than 48-bits.&#xA;CVE-2024-43830:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;leds: trigger: Unregister sysfs attributes before calling deactivate()&#xA;&#xA;Triggers which have trigger specific sysfs attributes typically store&#xA;related data in trigger-data allocated by the activate() callback and&#xA;freed by the deactivate() callback.&#xA;&#xA;Calling device_remove_groups() after calling deactivate() leaves a window&#xA;where the sysfs attributes show/store functions could be called after&#xA;deactivation and then operate on the just freed trigger-data.&#xA;&#xA;Move the device_remove_groups() call to before deactivate() to close&#xA;this race window.&#xA;&#xA;This also makes the deactivation path properly do things in reverse order&#xA;of the activation path which calls the activate() callback before calling&#xA;device_add_groups().&#xA;CVE-2024-26659:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xhci: handle isoc Babble and Buffer Overrun events properly&#xA;&#xA;xHCI 4.9 explicitly forbids assuming that the xHC has released its&#xA;ownership of a multi-TRB TD when it reports an error on one of the&#xA;early TRBs. Yet the driver makes such assumption and releases the TD,&#xA;allowing the remaining TRBs to be freed or overwritten by new TDs.&#xA;&#xA;The xHC should also report completion of the final TRB due to its IOC&#xA;flag being set by us, regardless of prior errors. This event cannot&#xA;be recognized if the TD has already been freed earlier, resulting in&#xA;&#34;Transfer event TRB DMA ptr not part of current TD&#34; error message.&#xA;&#xA;Fix this by reusing the logic for processing isoc Transaction Errors.&#xA;This also handles hosts which fail to report the final completion.&#xA;&#xA;Fix transfer length reporting on Babble errors. They may be caused by&#xA;device malfunction, no guarantee that the buffer has been filled.&#xA;CVE-2024-26820:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed&#xA;&#xA;If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER&#xA;handler cannot perform VF register successfully as the register call&#xA;is received before netvsc_probe is finished. This is because we&#xA;register register_netdevice_notifier() very early( even before&#xA;vmbus_driver_register()).&#xA;To fix this, we try to register each such matching VF( if it is visible&#xA;as a netdevice) at the end of netvsc_probe.&#xA;CVE-2024-42158:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings&#xA;&#xA;Replace memzero_explicit() and kfree() with kfree_sensitive() to fix&#xA;warnings reported by Coccinelle:&#xA;&#xA;WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)&#xA;WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)&#xA;WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)&#xA;CVE-2024-26753:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: virtio/akcipher - Fix stack overflow on memcpy&#xA;&#xA;sizeof(struct virtio_crypto_akcipher_session_para) is less than&#xA;sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from&#xA;stack variable leads stack overflow. Clang reports this issue by&#xA;commands:&#xA;make -j CC=clang-14 mrproper &gt;/dev/null 2&gt;&amp;1&#xA;make -j O=/tmp/crypto-build CC=clang-14 allmodconfig &gt;/dev/null 2&gt;&amp;1&#xA;make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/&#xA;  virtio_crypto_akcipher_algs.o&#xA;CVE-2024-26793:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;gtp: fix use-after-free and null-ptr-deref in gtp_newlink()&#xA;&#xA;The gtp_link_ops operations structure for the subsystem must be&#xA;registered after registering the gtp_net_ops pernet operations structure.&#xA;&#xA;Syzkaller hit &#39;general protection fault in gtp_genl_dump_pdp&#39; bug:&#xA;&#xA;[ 1010.702740] gtp: GTP module unloaded&#xA;[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI&#xA;[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1&#xA;[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014&#xA;[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]&#xA;[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00&#xA;[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203&#xA;[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000&#xA;[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282&#xA;[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000&#xA;[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80&#xA;[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400&#xA;[ 1010.715953] FS:  00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000&#xA;[ 1010.715958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0&#xA;[ 1010.715968] PKRU: 55555554&#xA;[ 1010.715972] Call Trace:&#xA;[ 1010.715985]  ? __die_body.cold+0x1a/0x1f&#xA;[ 1010.715995]  ? die_addr+0x43/0x70&#xA;[ 1010.716002]  ? exc_general_protection+0x199/0x2f0&#xA;[ 1010.716016]  ? asm_exc_general_protection+0x1e/0x30&#xA;[ 1010.716026]  ? gtp_newlink+0x4d7/0x9c0 [gtp]&#xA;[ 1010.716034]  ? gtp_net_exit+0x150/0x150 [gtp]&#xA;[ 1010.716042]  __rtnl_newlink+0x1063/0x1700&#xA;[ 1010.716051]  ? rtnl_setlink+0x3c0/0x3c0&#xA;[ 1010.716063]  ? is_bpf_text_address+0xc0/0x1f0&#xA;[ 1010.716070]  ? kernel_text_address.part.0+0xbb/0xd0&#xA;[ 1010.716076]  ? __kernel_text_address+0x56/0xa0&#xA;[ 1010.716084]  ? unwind_get_return_address+0x5a/0xa0&#xA;[ 1010.716091]  ? create_prof_cpu_mask+0x30/0x30&#xA;[ 1010.716098]  ? arch_stack_walk+0x9e/0xf0&#xA;[ 1010.716106]  ? stack_trace_save+0x91/0xd0&#xA;[ 1010.716113]  ? stack_trace_consume_entry+0x170/0x170&#xA;[ 1010.716121]  ? __lock_acquire+0x15c5/0x5380&#xA;[ 1010.716139]  ? mark_held_locks+0x9e/0xe0&#xA;[ 1010.716148]  ? kmem_cache_alloc_trace+0x35f/0x3c0&#xA;[ 1010.716155]  ? __rtnl_newlink+0x1700/0x1700&#xA;[ 1010.716160]  rtnl_newlink+0x69/0xa0&#xA;[ 1010.716166]  rtnetlink_rcv_msg+0x43b/0xc50&#xA;[ 1010.716172]  ? rtnl_fdb_dump+0x9f0/0x9f0&#xA;[ 1010.716179]  ? lock_acquire+0x1fe/0x560&#xA;[ 1010.716188]  ? netlink_deliver_tap+0x12f/0xd50&#xA;[ 1010.716196]  netlink_rcv_skb+0x14d/0x440&#xA;[ 1010.716202]  ? rtnl_fdb_dump+0x9f0/0x9f0&#xA;[ 1010.716208]  ? netlink_ack+0xab0/0xab0&#xA;[ 1010.716213]  ? netlink_deliver_tap+0x202/0xd50&#xA;[ 1010.716220]  ? netlink_deliver_tap+0x218/0xd50&#xA;[ 1010.716226]  ? __virt_addr_valid+0x30b/0x590&#xA;[ 1010.716233]  netlink_unicast+0x54b/0x800&#xA;[ 1010.716240]  ? netlink_attachskb+0x870/0x870&#xA;[ 1010.716248]  ? __check_object_size+0x2de/0x3b0&#xA;[ 1010.716254]  netlink_sendmsg+0x938/0xe40&#xA;[ 1010.716261]  ? netlink_unicast+0x800/0x800&#xA;[ 1010.716269]  ? __import_iovec+0x292/0x510&#xA;[ 1010.716276]  ? netlink_unicast+0x800/0x800&#xA;[ 1010.716284]  __sock_sendmsg+0x159/0x190&#xA;[ 1010.716290]  ____sys_sendmsg+0x712/0x880&#xA;[ 1010.716297]  ? sock_write_iter+0x3d0/0x3d0&#xA;[ 1010.716304]  ? __ia32_sys_recvmmsg+0x270/0x270&#xA;[ 1010.716309]  ? lock_acquire+0x1fe/0x560&#xA;[ 1010.716315]  ? drain_array_locked+0x90/0x90&#xA;[ 1010.716324]  ___sys_sendmsg+0xf8/0x170&#xA;[ 1010.716331]  ? sendmsg_copy_msghdr+0x170/0x170&#xA;[ 1010.716337]  ? lockdep_init_map&#xA;---truncated---&#xA;CVE-2024-26790:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read&#xA;&#xA;There is chip (ls1028a) errata:&#xA;&#xA;The SoC may hang on 16 byte unaligned read transactions by QDMA.&#xA;&#xA;Unaligned read transactions initiated by QDMA may stall in the NOC&#xA;(Network On-Chip), causing a deadlock condition. Stalled transactions will&#xA;trigger completion timeouts in PCIe controller.&#xA;&#xA;Workaround:&#xA;Enable prefetch by setting the source descriptor prefetchable bit&#xA;( SD[PF] = 1 ).&#xA;&#xA;Implement this workaround.&#xA;CVE-2024-26781:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mptcp: fix possible deadlock in subflow diag&#xA;&#xA;Syzbot and Eric reported a lockdep splat in the subflow diag:&#xA;&#xA;   WARNING: possible circular locking dependency detected&#xA;   6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted&#xA;&#xA;   syz-executor.2/24141 is trying to acquire lock:&#xA;   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:&#xA;   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]&#xA;   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:&#xA;   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137&#xA;&#xA;   but task is already holding lock:&#xA;   ffffc9000135e488 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock&#xA;   include/linux/spinlock.h:351 [inline]&#xA;   ffffc9000135e488 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}, at:&#xA;   inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038&#xA;&#xA;   which lock already depends on the new lock.&#xA;&#xA;   the existing dependency chain (in reverse order) is:&#xA;&#xA;   -&gt; #1 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}:&#xA;   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754&#xA;   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]&#xA;   _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154&#xA;   spin_lock include/linux/spinlock.h:351 [inline]&#xA;   __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743&#xA;   inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261&#xA;   __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217&#xA;   inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239&#xA;   rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316&#xA;   rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577&#xA;   ops_init+0x352/0x610 net/core/net_namespace.c:136&#xA;   __register_pernet_operations net/core/net_namespace.c:1214 [inline]&#xA;   register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283&#xA;   register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370&#xA;   rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735&#xA;   do_one_initcall+0x238/0x830 init/main.c:1236&#xA;   do_initcall_level+0x157/0x210 init/main.c:1298&#xA;   do_initcalls+0x3f/0x80 init/main.c:1314&#xA;   kernel_init_freeable+0x42f/0x5d0 init/main.c:1551&#xA;   kernel_init+0x1d/0x2a0 init/main.c:1441&#xA;   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;   ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242&#xA;&#xA;   -&gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:&#xA;   check_prev_add kernel/locking/lockdep.c:3134 [inline]&#xA;   check_prevs_add kernel/locking/lockdep.c:3253 [inline]&#xA;   validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869&#xA;   __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137&#xA;   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754&#xA;   lock_sock_fast include/net/sock.h:1723 [inline]&#xA;   subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28&#xA;   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]&#xA;   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137&#xA;   inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345&#xA;   inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061&#xA;   __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263&#xA;   inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371&#xA;   netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264&#xA;   __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370&#xA;   netlink_dump_start include/linux/netlink.h:338 [inline]&#xA;   inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405&#xA;   sock_diag_rcv_msg+0xe7/0x410&#xA;   netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543&#xA;   sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280&#xA;   netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]&#xA;   netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367&#xA;   netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908&#xA;   sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;   __sock_sendmsg+0x221/0x270 net/socket.c:745&#xA;   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584&#xA;   ___sys_sendmsg net/socket.c:2638 [inline]&#xA;   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667&#xA;   do_syscall_64+0xf9/0x240&#xA;   entry_SYSCALL_64_after_hwframe+0x6f/0x77&#xA;&#xA;As noted by Eric we can break the lock dependency chain avoid&#xA;dumping &#xA;---truncated---&#xA;CVE-2024-35825:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: gadget: ncm: Fix handling of zero block length packets&#xA;&#xA;While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX&#xA;set to 65536, it has been observed that we receive short packets,&#xA;which come at interval of 5-10 seconds sometimes and have block&#xA;length zero but still contain 1-2 valid datagrams present.&#xA;&#xA;According to the NCM spec:&#xA;&#xA;&#34;If wBlockLength = 0x0000, the block is terminated by a&#xA;short packet. In this case, the USB transfer must still&#xA;be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If&#xA;exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,&#xA;and the size is a multiple of wMaxPacketSize for the&#xA;given pipe, then no ZLP shall be sent.&#xA;&#xA;wBlockLength= 0x0000 must be used with extreme care, because&#xA;of the possibility that the host and device may get out of&#xA;sync, and because of test issues.&#xA;&#xA;wBlockLength = 0x0000 allows the sender to reduce latency by&#xA;starting to send a very large NTB, and then shortening it when&#xA;the sender discovers that there’s not sufficient data to justify&#xA;sending a large NTB&#34;&#xA;&#xA;However, there is a potential issue with the current implementation,&#xA;as it checks for the occurrence of multiple NTBs in a single&#xA;giveback by verifying if the leftover bytes to be processed is zero&#xA;or not. If the block length reads zero, we would process the same&#xA;NTB infintely because the leftover bytes is never zero and it leads&#xA;to a crash. Fix this by bailing out if block length reads zero.&#xA;CVE-2024-38594:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: stmmac: move the EST lock to struct stmmac_priv&#xA;&#xA;Reinitialize the whole EST structure would also reset the mutex&#xA;lock which is embedded in the EST structure, and then trigger&#xA;the following warning. To address this, move the lock to struct&#xA;stmmac_priv. We also need to reacquire the mutex lock when doing&#xA;this initialization.&#xA;&#xA;DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)&#xA;WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068&#xA; Modules linked in:&#xA; CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29&#xA; Hardware name: NXP i.MX8MPlus EVK board (DT)&#xA; pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : __mutex_lock+0xd84/0x1068&#xA; lr : __mutex_lock+0xd84/0x1068&#xA; sp : ffffffc0864e3570&#xA; x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003&#xA; x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac&#xA; x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000&#xA; x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff&#xA; x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000&#xA; x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8&#xA; x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698&#xA; x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001&#xA; x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027&#xA; x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000&#xA; Call trace:&#xA;  __mutex_lock+0xd84/0x1068&#xA;  mutex_lock_nested+0x28/0x34&#xA;  tc_setup_taprio+0x118/0x68c&#xA;  stmmac_setup_tc+0x50/0xf0&#xA;  taprio_change+0x868/0xc9c&#xA;CVE-2024-41049:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;filelock: fix potential use-after-free in posix_lock_inode&#xA;&#xA;Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().&#xA;The request pointer had been changed earlier to point to a lock entry&#xA;that was added to the inode&#39;s list. However, before the tracepoint could&#xA;fire, another task raced in and freed that lock.&#xA;&#xA;Fix this by moving the tracepoint inside the spinlock, which should&#xA;ensure that this doesn&#39;t happen.&#xA;CVE-2024-41055:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm: prevent derefencing NULL ptr in pfn_section_valid()&#xA;&#xA;Commit 5ec8e8ea8b77 (&#34;mm/sparsemem: fix race in accessing&#xA;memory_section-&gt;usage&#34;) changed pfn_section_valid() to add a READ_ONCE()&#xA;call around &#34;ms-&gt;usage&#34; to fix a race with section_deactivate() where&#xA;ms-&gt;usage can be cleared.  The READ_ONCE() call, by itself, is not enough&#xA;to prevent NULL pointer dereference.  We need to check its value before&#xA;dereferencing it.&#xA;CVE-2024-41064:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powerpc/eeh: avoid possible crash when edev-&gt;pdev changes&#xA;&#xA;If a PCI device is removed during eeh_pe_report_edev(), edev-&gt;pdev&#xA;will change and can cause a crash, hold the PCI rescan/remove lock&#xA;while taking a copy of edev-&gt;pdev-&gt;bus.&#xA;CVE-2024-41066:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ibmvnic: Add tx check to prevent skb leak&#xA;&#xA;Below is a summary of how the driver stores a reference to an skb during&#xA;transmit:&#xA;    tx_buff[free_map[consumer_index]]-&gt;skb = new_skb;&#xA;    free_map[consumer_index] = IBMVNIC_INVALID_MAP;&#xA;    consumer_index ++;&#xA;Where variable data looks like this:&#xA;    free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]&#xA;                                               &#x9;consumer_index^&#xA;    tx_buff == [skb=null, skb=&lt;ptr&gt;, skb=&lt;ptr&gt;, skb=null, skb=null]&#xA;&#xA;The driver has checks to ensure that free_map[consumer_index] pointed to&#xA;a valid index but there was no check to ensure that this index pointed&#xA;to an unused/null skb address. So, if, by some chance, our free_map and&#xA;tx_buff lists become out of sync then we were previously risking an&#xA;skb memory leak. This could then cause tcp congestion control to stop&#xA;sending packets, eventually leading to ETIMEDOUT.&#xA;&#xA;Therefore, add a conditional to ensure that the skb address is null. If&#xA;not then warn the user (because this is still a bug that should be&#xA;patched) and free the old pointer to prevent memleak/tcp problems.&#xA;CVE-2024-42082:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xdp: Remove WARN() from __xdp_reg_mem_model()&#xA;&#xA;syzkaller reports a warning in __xdp_reg_mem_model().&#xA;&#xA;The warning occurs only if __mem_id_init_hash_table() returns an error. It&#xA;returns the error in two cases:&#xA;&#xA;  1. memory allocation fails;&#xA;  2. rhashtable_init() fails when some fields of rhashtable_params&#xA;     struct are not initialized properly.&#xA;&#xA;The second case cannot happen since there is a static const rhashtable_params&#xA;struct with valid fields. So, warning is only triggered when there is a&#xA;problem with memory allocation.&#xA;&#xA;Thus, there is no sense in using WARN() to handle this error and it can be&#xA;safely removed.&#xA;&#xA;WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299&#xA;&#xA;CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024&#xA;RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299&#xA;&#xA;Call Trace:&#xA; xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344&#xA; xdp_test_run_setup net/bpf/test_run.c:188 [inline]&#xA; bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377&#xA; bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267&#xA; bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240&#xA; __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649&#xA; __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]&#xA; __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]&#xA; __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736&#xA; do_syscall_64+0xfb/0x240&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with syzkaller.&#xA;CVE-2024-42137:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot&#xA;&#xA;Commit 272970be3dab (&#34;Bluetooth: hci_qca: Fix driver shutdown on closed&#xA;serdev&#34;) will cause below regression issue:&#xA;&#xA;BT can&#39;t be enabled after below steps:&#xA;cold boot -&gt; enable BT -&gt; disable BT -&gt; warm reboot -&gt; BT enable failure&#xA;if property enable-gpios is not configured within DT|ACPI for QCA6390.&#xA;&#xA;The commit is to fix a use-after-free issue within qca_serdev_shutdown()&#xA;by adding condition to avoid the serdev is flushed or wrote after closed&#xA;but also introduces this regression issue regarding above steps since the&#xA;VSC is not sent to reset controller during warm reboot.&#xA;&#xA;Fixed by sending the VSC to reset controller within qca_serdev_shutdown()&#xA;once BT was ever enabled, and the use-after-free issue is also fixed by&#xA;this change since the serdev is still opened before it is flushed or wrote.&#xA;&#xA;Verified by the reported machine Dell XPS 13 9310 laptop over below two&#xA;kernel commits:&#xA;commit e00fc2700a3f (&#34;Bluetooth: btusb: Fix triggering coredump&#xA;implementation for QCA&#34;) of bluetooth-next tree.&#xA;commit b23d98d46d28 (&#34;Bluetooth: btusb: Fix triggering coredump&#xA;implementation for QCA&#34;) of linus mainline tree.&#xA;CVE-2024-26748:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: cdns3: fix memory double free when handle zero packet&#xA;&#xA;829  if (request-&gt;complete) {&#xA;830          spin_unlock(&amp;priv_dev-&gt;lock);&#xA;831          usb_gadget_giveback_request(&amp;priv_ep-&gt;endpoint,&#xA;832                                    request);&#xA;833          spin_lock(&amp;priv_dev-&gt;lock);&#xA;834  }&#xA;835&#xA;836  if (request-&gt;buf == priv_dev-&gt;zlp_buf)&#xA;837      cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, request);&#xA;&#xA;Driver append an additional zero packet request when queue a packet, which&#xA;length mod max packet size is 0. When transfer complete, run to line 831,&#xA;usb_gadget_giveback_request() will free this requestion. 836 condition is&#xA;true, so cdns3_gadget_ep_free_request() free this request again.&#xA;&#xA;Log:&#xA;&#xA;[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]&#xA;[ 1920.140696][  T150]&#xA;[ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):&#xA;[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]&#xA;[ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]&#xA;&#xA;Add check at line 829, skip call usb_gadget_giveback_request() if it is&#xA;additional zero length packet request. Needn&#39;t call&#xA;usb_gadget_giveback_request() because it is allocated in this driver.&#xA;CVE-2024-26749:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()&#xA;&#xA;  ...&#xA;  cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, &amp;priv_req-&gt;request);&#xA;  list_del_init(&amp;priv_req-&gt;list);&#xA;  ...&#xA;&#xA;&#39;priv_req&#39; actually free at cdns3_gadget_ep_free_request(). But&#xA;list_del_init() use priv_req-&gt;list after it.&#xA;&#xA;[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4&#xA;[ 1542.642868][  T534]&#xA;[ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):&#xA;[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4&#xA;[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]&#xA;[ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4&#xA;[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8&#xA;[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368&#xA;[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28&#xA;&#xA;Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this&#xA;problem.&#xA;CVE-2024-26747:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: roles: fix NULL pointer issue when put module&#39;s reference&#xA;&#xA;In current design, usb role class driver will get usb_role_switch parent&#39;s&#xA;module reference after the user get usb_role_switch device and put the&#xA;reference after the user put the usb_role_switch device. However, the&#xA;parent device of usb_role_switch may be removed before the user put the&#xA;usb_role_switch. If so, then, NULL pointer issue will be met when the user&#xA;put the parent module&#39;s reference.&#xA;&#xA;This will save the module pointer in structure of usb_role_switch. Then,&#xA;we don&#39;t need to find module by iterating long relations.&#xA;CVE-2024-35884:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;udp: do not accept non-tunnel GSO skbs landing in a tunnel&#xA;&#xA;When rx-udp-gro-forwarding is enabled UDP packets might be GROed when&#xA;being forwarded. If such packets might land in a tunnel this can cause&#xA;various issues and udp_gro_receive makes sure this isn&#39;t the case by&#xA;looking for a matching socket. This is performed in&#xA;udp4/6_gro_lookup_skb but only in the current netns. This is an issue&#xA;with tunneled packets when the endpoint is in another netns. In such&#xA;cases the packets will be GROed at the UDP level, which leads to various&#xA;issues later on. The same thing can happen with rx-gro-list.&#xA;&#xA;We saw this with geneve packets being GROed at the UDP level. In such&#xA;case gso_size is set; later the packet goes through the geneve rx path,&#xA;the geneve header is pulled, the offset are adjusted and frag_list skbs&#xA;are not adjusted with regard to geneve. When those skbs hit&#xA;skb_fragment, it will misbehave. Different outcomes are possible&#xA;depending on what the GROed skbs look like; from corrupted packets to&#xA;kernel crashes.&#xA;&#xA;One example is a BUG_ON[1] triggered in skb_segment while processing the&#xA;frag_list. Because gso_size is wrong (geneve header was pulled)&#xA;skb_segment thinks there is &#34;geneve header size&#34; of data in frag_list,&#xA;although it&#39;s in fact the next packet. The BUG_ON itself has nothing to&#xA;do with the issue. This is only one of the potential issues.&#xA;&#xA;Looking up for a matching socket in udp_gro_receive is fragile: the&#xA;lookup could be extended to all netns (not speaking about performances)&#xA;but nothing prevents those packets from being modified in between and we&#xA;could still not find a matching socket. It&#39;s OK to keep the current&#xA;logic there as it should cover most cases but we also need to make sure&#xA;we handle tunnel packets being GROed too early.&#xA;&#xA;This is done by extending the checks in udp_unexpected_gso: GSO packets&#xA;lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must&#xA;be segmented.&#xA;&#xA;[1] kernel BUG at net/core/skbuff.c:4408!&#xA;    RIP: 0010:skb_segment+0xd2a/0xf70&#xA;    __udp_gso_segment+0xaa/0x560&#xA;CVE-2024-39476:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING&#xA;&#xA;Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with&#xA;small possibility, the root cause is exactly the same as commit&#xA;bed9e27baf52 (&#34;Revert &#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&#34;&#34;)&#xA;&#xA;However, Dan reported another hang after that, and junxiao investigated&#xA;the problem and found out that this is caused by plugged bio can&#39;t issue&#xA;from raid5d().&#xA;&#xA;Current implementation in raid5d() has a weird dependence:&#xA;&#xA;1) md_check_recovery() from raid5d() must hold &#39;reconfig_mutex&#39; to clear&#xA;   MD_SB_CHANGE_PENDING;&#xA;2) raid5d() handles IO in a deadloop, until all IO are issued;&#xA;3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;&#xA;&#xA;This behaviour is introduce before v2.6, and for consequence, if other&#xA;context hold &#39;reconfig_mutex&#39;, and md_check_recovery() can&#39;t update&#xA;super_block, then raid5d() will waste one cpu 100% by the deadloop, until&#xA;&#39;reconfig_mutex&#39; is released.&#xA;&#xA;Refer to the implementation from raid1 and raid10, fix this problem by&#xA;skipping issue IO if MD_SB_CHANGE_PENDING is still set after&#xA;md_check_recovery(), daemon thread will be woken up when &#39;reconfig_mutex&#39;&#xA;is released. Meanwhile, the hang problem will be fixed as well.&#xA;CVE-2024-41006:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netrom: Fix a memory leak in nr_heartbeat_expiry()&#xA;&#xA;syzbot reported a memory leak in nr_create() [0].&#xA;&#xA;Commit 409db27e3a2e (&#34;netrom: Fix use-after-free of a listening socket.&#34;)&#xA;added sock_hold() to the nr_heartbeat_expiry() function, where&#xA;a) a socket has a SOCK_DESTROY flag or&#xA;b) a listening socket has a SOCK_DEAD flag.&#xA;&#xA;But in the case &#34;a,&#34; when the SOCK_DESTROY flag is set, the file descriptor&#xA;has already been closed and the nr_release() function has been called.&#xA;So it makes no sense to hold the reference count because no one will&#xA;call another nr_destroy_socket() and put it as in the case &#34;b.&#34;&#xA;&#xA;nr_connect&#xA;  nr_establish_data_link&#xA;    nr_start_heartbeat&#xA;&#xA;nr_release&#xA;  switch (nr-&gt;state)&#xA;  case NR_STATE_3&#xA;    nr-&gt;state = NR_STATE_2&#xA;    sock_set_flag(sk, SOCK_DESTROY);&#xA;&#xA;                        nr_rx_frame&#xA;                          nr_process_rx_frame&#xA;                            switch (nr-&gt;state)&#xA;                            case NR_STATE_2&#xA;                              nr_state2_machine()&#xA;                                nr_disconnect()&#xA;                                  nr_sk(sk)-&gt;state = NR_STATE_0&#xA;                                  sock_set_flag(sk, SOCK_DEAD)&#xA;&#xA;                        nr_heartbeat_expiry&#xA;                          switch (nr-&gt;state)&#xA;                          case NR_STATE_0&#xA;                            if (sock_flag(sk, SOCK_DESTROY) ||&#xA;                               (sk-&gt;sk_state == TCP_LISTEN&#xA;                                 &amp;&amp; sock_flag(sk, SOCK_DEAD)))&#xA;                               sock_hold()  // ( !!! )&#xA;                               nr_destroy_socket()&#xA;&#xA;To fix the memory leak, let&#39;s call sock_hold() only for a listening socket.&#xA;&#xA;Found by InfoTeCS on behalf of Linux Verification Center&#xA;(linuxtesting.org) with Syzkaller.&#xA;&#xA;[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16&#xA;CVE-2024-41022:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()&#xA;&#xA;The &#34;instance&#34; variable needs to be signed for the error handling to work.&#xA;CVE-2024-49959:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error&#xA;&#xA;In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()&#xA;to recover some journal space. But if an error occurs while executing&#xA;jbd2_cleanup_journal_tail() (e.g., an EIO), we don&#39;t stop waiting for free&#xA;space right away, we try other branches, and if j_committing_transaction&#xA;is NULL (i.e., the tid is 0), we will get the following complain:&#xA;&#xA;============================================&#xA;JBD2: I/O error when updating journal superblock for sdd-8.&#xA;__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available&#xA;__jbd2_log_wait_for_space: no way to get more journal space in sdd-8&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0&#xA;Modules linked in:&#xA;CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1&#xA;RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; add_transaction_credits+0x5d1/0x5e0&#xA; start_this_handle+0x1ef/0x6a0&#xA; jbd2__journal_start+0x18b/0x340&#xA; ext4_dirty_inode+0x5d/0xb0&#xA; __mark_inode_dirty+0xe4/0x5d0&#xA; generic_update_time+0x60/0x70&#xA;[...]&#xA;============================================&#xA;&#xA;So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to&#xA;clean up at the moment, continue to try to reclaim free space in other ways.&#xA;&#xA;Note that this fix relies on commit 6f6a6fda2945 (&#34;jbd2: fix ocfs2 corrupt&#xA;when updating journal superblock fails&#34;) to make jbd2_cleanup_journal_tail&#xA;return the correct error code.&#xA;CVE-2024-26664:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hwmon: (coretemp) Fix out-of-bounds memory access&#xA;&#xA;Fix a bug that pdata-&gt;cpu_map[] is set before out-of-bounds check.&#xA;The problem might be triggered on systems with more than 128 cores per&#xA;package.&#xA;CVE-2024-27012:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: restore set elements when delete set fails&#xA;&#xA;From abort path, nft_mapelem_activate() needs to restore refcounters to&#xA;the original state. Currently, it uses the set-&gt;ops-&gt;walk() to iterate&#xA;over these set elements. The existing set iterator skips inactive&#xA;elements in the next generation, this does not work from the abort path&#xA;to restore the original state since it has to skip active elements&#xA;instead (not inactive ones).&#xA;&#xA;This patch moves the check for inactive elements to the set iterator&#xA;callback, then it reverses the logic for the .activate case which&#xA;needs to skip active elements.&#xA;&#xA;Toggle next generation bit for elements when delete set command is&#xA;invoked and call nft_clear() from .activate (abort) path to restore the&#xA;next generation bit.&#xA;&#xA;The splat below shows an object in mappings memleak:&#xA;&#xA;[43929.457523] ------------[ cut here ]------------&#xA;[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]&#xA;[...]&#xA;[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]&#xA;[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 &lt;0f&gt; 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90&#xA;[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246&#xA;[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000&#xA;[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550&#xA;[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f&#xA;[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0&#xA;[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002&#xA;[43929.458103] FS:  00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000&#xA;[43929.458107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0&#xA;[43929.458114] Call Trace:&#xA;[43929.458118]  &lt;TASK&gt;&#xA;[43929.458121]  ? __warn+0x9f/0x1a0&#xA;[43929.458127]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]&#xA;[43929.458188]  ? report_bug+0x1b1/0x1e0&#xA;[43929.458196]  ? handle_bug+0x3c/0x70&#xA;[43929.458200]  ? exc_invalid_op+0x17/0x40&#xA;[43929.458211]  ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]&#xA;[43929.458271]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]&#xA;[43929.458332]  nft_mapelem_deactivate+0x24/0x30 [nf_tables]&#xA;[43929.458392]  nft_rhash_walk+0xdd/0x180 [nf_tables]&#xA;[43929.458453]  ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]&#xA;[43929.458512]  ? rb_insert_color+0x2e/0x280&#xA;[43929.458520]  nft_map_deactivate+0xdc/0x1e0 [nf_tables]&#xA;[43929.458582]  ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]&#xA;[43929.458642]  ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]&#xA;[43929.458701]  ? __rcu_read_unlock+0x46/0x70&#xA;[43929.458709]  nft_delset+0xff/0x110 [nf_tables]&#xA;[43929.458769]  nft_flush_table+0x16f/0x460 [nf_tables]&#xA;[43929.458830]  nf_tables_deltable+0x501/0x580 [nf_tables]&#xA;CVE-2024-27065:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: do not compare internal table flags on updates&#xA;&#xA;Restore skipping transaction if table update does not modify flags.&#xA;CVE-2024-27412:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;power: supply: bq27xxx-i2c: Do not free non existing IRQ&#xA;&#xA;The bq27xxx i2c-client may not have an IRQ, in which case&#xA;client-&gt;irq will be 0. bq27xxx_battery_i2c_probe() already has&#xA;an if (client-&gt;irq) check wrapping the request_threaded_irq().&#xA;&#xA;But bq27xxx_battery_i2c_remove() unconditionally calls&#xA;free_irq(client-&gt;irq) leading to:&#xA;&#xA;[  190.310742] ------------[ cut here ]------------&#xA;[  190.310843] Trying to free already-free IRQ 0&#xA;[  190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310&#xA;&#xA;Followed by a backtrace when unbinding the driver. Add&#xA;an if (client-&gt;irq) to bq27xxx_battery_i2c_remove() mirroring&#xA;probe() to fix this.&#xA;CVE-2024-33621:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvlan: Dont Use skb-&gt;sk in ipvlan_process_v{4,6}_outbound&#xA;&#xA;Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will&#xA;hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.&#xA;&#xA;WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70&#xA;Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper&#xA;CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;RIP: 0010:sk_mc_loop+0x2d/0x70&#xA;Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c&#xA;RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212&#xA;RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001&#xA;RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000&#xA;RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00&#xA;R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000&#xA;R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000&#xA;FS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA;&lt;IRQ&gt;&#xA; ? __warn (kernel/panic.c:693)&#xA; ? sk_mc_loop (net/core/sock.c:760)&#xA; ? report_bug (lib/bug.c:201 lib/bug.c:219)&#xA; ? handle_bug (arch/x86/kernel/traps.c:239)&#xA; ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))&#xA; ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)&#xA; ? sk_mc_loop (net/core/sock.c:760)&#xA; ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))&#xA; ? nf_hook_slow (net/netfilter/core.c:626)&#xA; ip6_finish_output (net/ipv6/ip6_output.c:222)&#xA; ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)&#xA; ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan&#xA; ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan&#xA; dev_hard_start_xmit (net/core/dev.c:3594)&#xA; sch_direct_xmit (net/sched/sch_generic.c:343)&#xA; __qdisc_run (net/sched/sch_generic.c:416)&#xA; net_tx_action (net/core/dev.c:5286)&#xA; handle_softirqs (kernel/softirq.c:555)&#xA; __irq_exit_rcu (kernel/softirq.c:589)&#xA; sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)&#xA;&#xA;The warning triggers as this:&#xA;packet_sendmsg&#xA;   packet_snd //skb-&gt;sk is packet sk&#xA;      __dev_queue_xmit&#xA;         __dev_xmit_skb //q-&gt;enqueue is not NULL&#xA;             __qdisc_run&#xA;               sch_direct_xmit&#xA;                 dev_hard_start_xmit&#xA;                   ipvlan_start_xmit&#xA;                      ipvlan_xmit_mode_l3 //l3 mode&#xA;                        ipvlan_process_outbound //vepa flag&#xA;                          ipvlan_process_v6_outbound&#xA;                            ip6_local_out&#xA;                                __ip6_finish_output&#xA;                                  ip6_finish_output2 //multicast packet&#xA;                                    sk_mc_loop //sk-&gt;sk_family is AF_PACKET&#xA;&#xA;Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.&#xA;CVE-2024-40963:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mips: bmips: BCM6358: make sure CBR is correctly set&#xA;&#xA;It was discovered that some device have CBR address set to 0 causing&#xA;kernel panic when arch_sync_dma_for_cpu_all is called.&#xA;&#xA;This was notice in situation where the system is booted from TP1 and&#xA;BMIPS_GET_CBR() returns 0 instead of a valid address and&#xA;!!(read_c0_brcm_cmt_local() &amp; (1 &lt;&lt; 31)); not failing.&#xA;&#xA;The current check whether RAC flush should be disabled or not are not&#xA;enough hence lets check if CBR is a valid address or not.&#xA;CVE-2022-48816:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;SUNRPC: lock against -&gt;sock changing during sysfs read&#xA;&#xA;-&gt;sock can be set to NULL asynchronously unless -&gt;recv_mutex is held.&#xA;So it is important to hold that mutex.  Otherwise a sysfs read can&#xA;trigger an oops.&#xA;Commit 17f09d3f619a (&#34;SUNRPC: Check if the xprt is connected before&#xA;handling sysfs reads&#34;) appears to attempt to fix this problem, but it&#xA;only narrows the race window.&#xA;CVE-2024-27416:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST&#xA;&#xA;If we received HCI_EV_IO_CAPA_REQUEST while&#xA;HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote&#xA;does support SSP since otherwise this event shouldn&#39;t be generated.&#xA;CVE-2024-39502:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ionic: fix use after netif_napi_del()&#xA;&#xA;When queues are started, netif_napi_add() and napi_enable() are called.&#xA;If there are 4 queues and only 3 queues are used for the current&#xA;configuration, only 3 queues&#39; napi should be registered and enabled.&#xA;The ionic_qcq_enable() checks whether the .poll pointer is not NULL for&#xA;enabling only the using queue&#39; napi. Unused queues&#39; napi will not be&#xA;registered by netif_napi_add(), so the .poll pointer indicates NULL.&#xA;But it couldn&#39;t distinguish whether the napi was unregistered or not&#xA;because netif_napi_del() doesn&#39;t reset the .poll pointer to NULL.&#xA;So, ionic_qcq_enable() calls napi_enable() for the queue, which was&#xA;unregistered by netif_napi_del().&#xA;&#xA;Reproducer:&#xA;   ethtool -L &lt;interface name&gt; rx 1 tx 1 combined 0&#xA;   ethtool -L &lt;interface name&gt; rx 0 tx 0 combined 1&#xA;   ethtool -L &lt;interface name&gt; rx 0 tx 0 combined 4&#xA;&#xA;Splat looks like:&#xA;kernel BUG at net/core/dev.c:6666!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16&#xA;Workqueue: events ionic_lif_deferred_work [ionic]&#xA;RIP: 0010:napi_enable+0x3b/0x40&#xA;Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f&#xA;RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029&#xA;RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28&#xA;RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001&#xA;R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000&#xA;R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20&#xA;FS:  0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? die+0x33/0x90&#xA; ? do_trap+0xd9/0x100&#xA; ? napi_enable+0x3b/0x40&#xA; ? do_error_trap+0x83/0xb0&#xA; ? napi_enable+0x3b/0x40&#xA; ? napi_enable+0x3b/0x40&#xA; ? exc_invalid_op+0x4e/0x70&#xA; ? napi_enable+0x3b/0x40&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? napi_enable+0x3b/0x40&#xA; ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]&#xA; process_one_work+0x145/0x360&#xA; worker_thread+0x2bb/0x3d0&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0xcc/0x100&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x2d/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA;CVE-2024-40934:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()&#xA;&#xA;Fix a memory leak on logi_dj_recv_send_report() error path.&#xA;CVE-2024-35893:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: act_skbmod: prevent kernel-infoleak&#xA;&#xA;syzbot found that tcf_skbmod_dump() was copying four bytes&#xA;from kernel stack to user space [1].&#xA;&#xA;The issue here is that &#39;struct tc_skbmod&#39; has a four bytes hole.&#xA;&#xA;We need to clear the structure before filling fields.&#xA;&#xA;[1]&#xA;BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA; BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]&#xA; BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]&#xA; BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]&#xA; BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]&#xA; BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185&#xA;  instrument_copy_to_user include/linux/instrumented.h:114 [inline]&#xA;  copy_to_user_iter lib/iov_iter.c:24 [inline]&#xA;  iterate_ubuf include/linux/iov_iter.h:29 [inline]&#xA;  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]&#xA;  iterate_and_advance include/linux/iov_iter.h:271 [inline]&#xA;  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185&#xA;  copy_to_iter include/linux/uio.h:196 [inline]&#xA;  simple_copy_to_iter net/core/datagram.c:532 [inline]&#xA;  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420&#xA;  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546&#xA;  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]&#xA;  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962&#xA;  sock_recvmsg_nosec net/socket.c:1046 [inline]&#xA;  sock_recvmsg+0x2c4/0x340 net/socket.c:1068&#xA;  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242&#xA;  __do_sys_recvfrom net/socket.c:2260 [inline]&#xA;  __se_sys_recvfrom net/socket.c:2256 [inline]&#xA;  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;&#xA;Uninit was stored to memory at:&#xA;  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253&#xA;  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317&#xA;  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351&#xA;  nlmsg_unicast include/net/netlink.h:1144 [inline]&#xA;  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610&#xA;  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741&#xA;  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]&#xA;  tcf_add_notify net/sched/act_api.c:2048 [inline]&#xA;  tcf_action_add net/sched/act_api.c:2071 [inline]&#xA;  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119&#xA;  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595&#xA;  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559&#xA;  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613&#xA;  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]&#xA;  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361&#xA;  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905&#xA;  sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  __sock_sendmsg+0x30f/0x380 net/socket.c:745&#xA;  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584&#xA;  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA;  __sys_sendmsg net/socket.c:2667 [inline]&#xA;  __do_sys_sendmsg net/socket.c:2676 [inline]&#xA;  __se_sys_sendmsg net/socket.c:2674 [inline]&#xA;  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674&#xA; do_syscall_64+0xd5/0x1f0&#xA; entry_SYSCALL_64_after_hwframe+0x6d/0x75&#xA;&#xA;Uninit was stored to memory at:&#xA;  __nla_put lib/nlattr.c:1041 [inline]&#xA;  nla_put+0x1c6/0x230 lib/nlattr.c:1099&#xA;  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256&#xA;  tcf_action_dump_old net/sched/act_api.c:1191 [inline]&#xA;  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227&#xA;  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251&#xA;  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628&#xA;  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]&#xA;  tcf_add_notify net/sched/act_api.c:2042 [inline]&#xA;  tcf_action_add net/sched/act_api.c:2071 [inline]&#xA;  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119&#xA;  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595&#xA;  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli&#xA;---truncated---&#xA;CVE-2024-38567:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: carl9170: add a proper sanity check for endpoints&#xA;&#xA;Syzkaller reports [1] hitting a warning which is caused by presence&#xA;of a wrong endpoint type at the URB sumbitting stage. While there&#xA;was a check for a specific 4th endpoint, since it can switch types&#xA;between bulk and interrupt, other endpoints are trusted implicitly.&#xA;Similar warning is triggered in a couple of other syzbot issues [2].&#xA;&#xA;Fix the issue by doing a comprehensive check of all endpoints&#xA;taking into account difference between high- and full-speed&#xA;configuration.&#xA;&#xA;[1] Syzkaller report:&#xA;...&#xA;WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504&#xA; carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]&#xA; carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]&#xA; carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028&#xA; request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107&#xA; process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289&#xA; worker_thread+0x669/0x1090 kernel/workqueue.c:2436&#xA; kthread+0x2e8/0x3a0 kernel/kthread.c:376&#xA; ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308&#xA; &lt;/TASK&gt;&#xA;&#xA;[2] Related syzkaller crashes:&#xA;CVE-2024-27052:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work&#xA;&#xA;The workqueue might still be running, when the driver is stopped. To&#xA;avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().&#xA;CVE-2024-27047:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: phy: fix phy_get_internal_delay accessing an empty array&#xA;&#xA;The phy_get_internal_delay function could try to access to an empty&#xA;array in the case that the driver is calling phy_get_internal_delay&#xA;without defining delay_values and rx-internal-delay-ps or&#xA;tx-internal-delay-ps is defined to 0 in the device-tree.&#xA;This will lead to &#34;unable to handle kernel NULL pointer dereference at&#xA;virtual address 0&#34;. To avoid this kernel oops, the test should be delay&#xA;&gt;= 0. As there is already delay &lt; 0 test just before, the test could&#xA;only be size == 0.&#xA;CVE-2024-27405:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs&#xA;&#xA;It is observed sometimes when tethering is used over NCM with Windows 11&#xA;as host, at some instances, the gadget_giveback has one byte appended at&#xA;the end of a proper NTB. When the NTB is parsed, unwrap call looks for&#xA;any leftover bytes in SKB provided by u_ether and if there are any pending&#xA;bytes, it treats them as a separate NTB and parses it. But in case the&#xA;second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that&#xA;were parsed properly in the first NTB and saved in rx_list are dropped.&#xA;&#xA;Adding a few custom traces showed the following:&#xA;[002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:&#xA;req 000000003868811a length 1025/16384 zsI ==&gt; 0&#xA;[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025&#xA;[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342&#xA;[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67&#xA;[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400&#xA;[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10&#xA;[002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames&#xA;&#xA;In this case, the giveback is of 1025 bytes and block length is 1024.&#xA;The rest 1 byte (which is 0x00) won&#39;t be parsed resulting in drop of&#xA;all datagrams in rx_list.&#xA;&#xA;Same is case with packets of size 2048:&#xA;[002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:&#xA;req 0000000011dfd96e length 2049/16384 zsI ==&gt; 0&#xA;[002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342&#xA;[002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800&#xA;&#xA;Lecroy shows one byte coming in extra confirming that the byte is coming&#xA;in from PC:&#xA;&#xA; Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590)&#xA; - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)&#xA; --- Packet 4063861&#xA;       Data(1024 bytes)&#xA;       Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)&#xA; --- Packet 4063863&#xA;       Data(1 byte)&#xA;       Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)&#xA;&#xA;According to Windows driver, no ZLP is needed if wBlockLength is non-zero,&#xA;because the non-zero wBlockLength has already told the function side the&#xA;size of transfer to be expected. However, there are in-market NCM devices&#xA;that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.&#xA;To deal with such devices, it pads an extra 0 at end so the transfer is no&#xA;longer multiple of wMaxPacketSize.&#xA;CVE-2024-27417:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: fix potential &#34;struct net&#34; leak in inet6_rtm_getaddr()&#xA;&#xA;It seems that if userspace provides a correct IFA_TARGET_NETNSID value&#xA;but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()&#xA;returns -EINVAL with an elevated &#34;struct net&#34; refcount.&#xA;CVE-2024-38553:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: fec: remove .ndo_poll_controller to avoid deadlocks&#xA;&#xA;There is a deadlock issue found in sungem driver, please refer to the&#xA;commit ac0a230f719b (&#34;eth: sungem: remove .ndo_poll_controller to avoid&#xA;deadlocks&#34;). The root cause of the issue is that netpoll is in atomic&#xA;context and disable_irq() is called by .ndo_poll_controller interface&#xA;of sungem driver, however, disable_irq() might sleep. After analyzing&#xA;the implementation of fec_poll_controller(), the fec driver should have&#xA;the same issue. Due to the fec driver uses NAPI for TX completions, the&#xA;.ndo_poll_controller is unnecessary to be implemented in the fec driver,&#xA;so fec_poll_controller() can be safely removed.&#xA;CVE-2024-38587:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;speakup: Fix sizeof() vs ARRAY_SIZE() bug&#xA;&#xA;The &#34;buf&#34; pointer is an array of u16 values.  This code should be&#xA;using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),&#xA;otherwise it can the still got out of bounds.&#xA;CVE-2023-39180:A flaw was found within the handling of SMB2_READ commands in the kernel ksmbd module. The issue results from not releasing memory after its effective lifetime. An attacker can leverage this to create a denial-of-service condition on affected installations of Linux. Authentication is not required to exploit this vulnerability, but only systems with ksmbd enabled are vulnerable.&#xA;CVE-2024-38381:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfc: nci: Fix uninit-value in nci_rx_work&#xA;&#xA;syzbot reported the following uninit-value access issue [1]&#xA;&#xA;nci_rx_work() parses received packet from ndev-&gt;rx_q. It should be&#xA;validated header size, payload size and total packet size before&#xA;processing the packet. If an invalid packet is detected, it should be&#xA;silently discarded.&#xA;CVE-2024-36020:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: fix vf may be used uninitialized in this function warning&#xA;&#xA;To fix the regression introduced by commit 52424f974bc5, which causes&#xA;servers hang in very hard to reproduce conditions with resets races.&#xA;Using two sources for the information is the root cause.&#xA;In this function before the fix bumping v didn&#39;t mean bumping vf&#xA;pointer. But the code used this variables interchangeably, so stale vf&#xA;could point to different/not intended vf.&#xA;&#xA;Remove redundant &#34;v&#34; variable and iterate via single VF pointer across&#xA;whole function instead to guarantee VF pointer validity.&#xA;CVE-2024-36959:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()&#xA;&#xA;If we fail to allocate propname buffer, we need to drop the reference&#xA;count we just took. Because the pinctrl_dt_free_maps() includes the&#xA;droping operation, here we call it directly.&#xA;CVE-2024-36484:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: relax socket state check at accept time.&#xA;&#xA;Christoph reported the following splat:&#xA;&#xA;WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0&#xA;Modules linked in:&#xA;CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014&#xA;RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759&#xA;Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd &lt;0f&gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80&#xA;RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293&#xA;RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64&#xA;R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000&#xA;R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800&#xA;FS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786&#xA; do_accept+0x435/0x620 net/socket.c:1929&#xA; __sys_accept4_file net/socket.c:1969 [inline]&#xA; __sys_accept4+0x9b/0x110 net/socket.c:1999&#xA; __do_sys_accept net/socket.c:2016 [inline]&#xA; __se_sys_accept net/socket.c:2013 [inline]&#xA; __x64_sys_accept+0x7d/0x90 net/socket.c:2013&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;RIP: 0033:0x4315f9&#xA;Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00&#xA;RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b&#xA;RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004&#xA;RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300&#xA;R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055&#xA; &lt;/TASK&gt;&#xA;&#xA;The reproducer invokes shutdown() before entering the listener status.&#xA;After commit 94062790aedb (&#34;tcp: defer shutdown(SEND_SHUTDOWN) for&#xA;TCP_SYN_RECV sockets&#34;), the above causes the child to reach the accept&#xA;syscall in FIN_WAIT1 status.&#xA;&#xA;Eric noted we can relax the existing assertion in __inet_accept()&#xA;CVE-2024-26835:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: set dormant flag on hook register failure&#xA;&#xA;We need to set the dormant flag again if we fail to register&#xA;the hooks.&#xA;&#xA;During memory pressure hook registration can fail and we end up&#xA;with a table marked as active but no registered hooks.&#xA;&#xA;On table/base chain deletion, nf_tables will attempt to unregister&#xA;the hook again which yields a warn splat from the nftables core.&#xA;CVE-2024-36903:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: Fix potential uninit-value access in __ip6_make_skb()&#xA;&#xA;As it was done in commit fc1092f51567 (&#34;ipv4: Fix uninit-value access in&#xA;__ip_make_skb()&#34;) for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6-&gt;flowi6_flags&#xA;instead of testing HDRINCL on the socket to avoid a race condition which&#xA;causes uninit-value access.&#xA;CVE-2024-27408:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup&#xA;&#xA;The Linked list element and pointer are not stored in the same memory as&#xA;the eDMA controller register. If the doorbell register is toggled before&#xA;the full write of the linked list a race condition error will occur.&#xA;In remote setup we can only use a readl to the memory to assure the full&#xA;write has occurred.&#xA;CVE-2024-35852:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work&#xA;&#xA;The rehash delayed work is rescheduled with a delay if the number of&#xA;credits at end of the work is not negative as supposedly it means that&#xA;the migration ended. Otherwise, it is rescheduled immediately.&#xA;&#xA;After &#34;mlxsw: spectrum_acl_tcam: Fix possible use-after-free during&#xA;rehash&#34; the above is no longer accurate as a non-negative number of&#xA;credits is no longer indicative of the migration being done. It can also&#xA;happen if the work encountered an error in which case the migration will&#xA;resume the next time the work is scheduled.&#xA;&#xA;The significance of the above is that it is possible for the work to be&#xA;pending and associated with hints that were allocated when the migration&#xA;started. This leads to the hints being leaked [1] when the work is&#xA;canceled while pending as part of ACL region dismantle.&#xA;&#xA;Fix by freeing the hints if hints are associated with a work that was&#xA;canceled while pending.&#xA;&#xA;Blame the original commit since the reliance on not having a pending&#xA;work associated with hints is fragile.&#xA;&#xA;[1]&#xA;unreferenced object 0xffff88810e7c3000 (size 256):&#xA;  comm &#34;kworker/0:16&#34;, pid 176, jiffies 4295460353&#xA;  hex dump (first 32 bytes):&#xA;    00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80  .0......a.......&#xA;    00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00  ..a.@...........&#xA;  backtrace (crc 2544ddb9):&#xA;    [&lt;00000000cf8cfab3&gt;] kmalloc_trace+0x23f/0x2a0&#xA;    [&lt;000000004d9a1ad9&gt;] objagg_hints_get+0x42/0x390&#xA;    [&lt;000000000b143cf3&gt;] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400&#xA;    [&lt;0000000059bdb60a&gt;] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160&#xA;    [&lt;00000000e81fd734&gt;] process_one_work+0x59c/0xf20&#xA;    [&lt;00000000ceee9e81&gt;] worker_thread+0x799/0x12c0&#xA;    [&lt;00000000bda6fe39&gt;] kthread+0x246/0x300&#xA;    [&lt;0000000070056d23&gt;] ret_from_fork+0x34/0x70&#xA;    [&lt;00000000dea2b93e&gt;] ret_from_fork_asm+0x1a/0x30&#xA;CVE-2024-35962:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: complete validation of user input&#xA;&#xA;In my recent commit, I missed that do_replace() handlers&#xA;use copy_from_sockptr() (which I fixed), followed&#xA;by unsafe copy_from_sockptr_offset() calls.&#xA;&#xA;In all functions, we can perform the @optlen validation&#xA;before even calling xt_alloc_table_info() with the following&#xA;check:&#xA;&#xA;if ((u64)optlen &lt; (u64)tmp.size + sizeof(tmp))&#xA;        return -EINVAL;&#xA;CVE-2024-38662:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Allow delete from sockmap/sockhash only if update is allowed&#xA;&#xA;We have seen an influx of syzkaller reports where a BPF program attached to&#xA;a tracepoint triggers a locking rule violation by performing a map_delete&#xA;on a sockmap/sockhash.&#xA;&#xA;We don&#39;t intend to support this artificial use scenario. Extend the&#xA;existing verifier allowed-program-type check for updating sockmap/sockhash&#xA;to also cover deleting from a map.&#xA;&#xA;From now on only BPF programs which were previously allowed to update&#xA;sockmap/sockhash can delete from these map types.&#xA;CVE-2024-41002:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: hisilicon/sec - Fix memory leak for sec resource release&#xA;&#xA;The AIV is one of the SEC resources. When releasing resources,&#xA;it need to release the AIV resources at the same time.&#xA;Otherwise, memory leakage occurs.&#xA;&#xA;The aiv resource release is added to the sec resource release&#xA;function.&#xA;CVE-2024-27414:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back&#xA;&#xA;In the commit d73ef2d69c0d (&#34;rtnetlink: let rtnl_bridge_setlink checks&#xA;IFLA_BRIDGE_MODE length&#34;), an adjustment was made to the old loop logic&#xA;in the function `rtnl_bridge_setlink` to enable the loop to also check&#xA;the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment&#xA;removed the `break` statement and led to an error logic of the flags&#xA;writing back at the end of this function.&#xA;&#xA;if (have_flags)&#xA;    memcpy(nla_data(attr), &amp;flags, sizeof(flags));&#xA;    // attr should point to IFLA_BRIDGE_FLAGS NLA !!!&#xA;&#xA;Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS.&#xA;However, this is not necessarily true fow now as the updated loop will let&#xA;the attr point to the last NLA, even an invalid NLA which could cause&#xA;overflow writes.&#xA;&#xA;This patch introduces a new variable `br_flag` to save the NLA pointer&#xA;that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned&#xA;error logic.&#xA;CVE-2024-35808:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;md/dm-raid: don&#39;t call md_reap_sync_thread() directly&#xA;&#xA;Currently md_reap_sync_thread() is called from raid_message() directly&#xA;without holding &#39;reconfig_mutex&#39;, this is definitely unsafe because&#xA;md_reap_sync_thread() can change many fields that is protected by&#xA;&#39;reconfig_mutex&#39;.&#xA;&#xA;However, hold &#39;reconfig_mutex&#39; here is still problematic because this&#xA;will cause deadlock, for example, commit 130443d60b1b (&#34;md: refactor&#xA;idle/frozen_sync_thread() to fix deadlock&#34;).&#xA;&#xA;Fix this problem by using stop_sync_thread() to unregister sync_thread,&#xA;like md/raid did.&#xA;CVE-2024-35900:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: reject new basechain after table flag update&#xA;&#xA;When dormant flag is toggled, hooks are disabled in the commit phase by&#xA;iterating over current chains in table (existing and new).&#xA;&#xA;The following configuration allows for an inconsistent state:&#xA;&#xA;  add table x&#xA;  add chain x y { type filter hook input priority 0; }&#xA;  add table x { flags dormant; }&#xA;  add chain x w { type filter hook input priority 1; }&#xA;&#xA;which triggers the following warning when trying to unregister chain w&#xA;which is already unregistered.&#xA;&#xA;[  127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50                                                                     1 __nf_unregister_net_hook+0x21a/0x260&#xA;[...]&#xA;[  127.322519] Call Trace:&#xA;[  127.322521]  &lt;TASK&gt;&#xA;[  127.322524]  ? __warn+0x9f/0x1a0&#xA;[  127.322531]  ? __nf_unregister_net_hook+0x21a/0x260&#xA;[  127.322537]  ? report_bug+0x1b1/0x1e0&#xA;[  127.322545]  ? handle_bug+0x3c/0x70&#xA;[  127.322552]  ? exc_invalid_op+0x17/0x40&#xA;[  127.322556]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[  127.322563]  ? kasan_save_free_info+0x3b/0x60&#xA;[  127.322570]  ? __nf_unregister_net_hook+0x6a/0x260&#xA;[  127.322577]  ? __nf_unregister_net_hook+0x21a/0x260&#xA;[  127.322583]  ? __nf_unregister_net_hook+0x6a/0x260&#xA;[  127.322590]  ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]&#xA;[  127.322655]  nft_table_disable+0x75/0xf0 [nf_tables]&#xA;[  127.322717]  nf_tables_commit+0x2571/0x2620 [nf_tables]&#xA;CVE-2023-52831:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cpu/hotplug: Don&#39;t offline the last non-isolated CPU&#xA;&#xA;If a system has isolated CPUs via the &#34;isolcpus=&#34; command line parameter,&#xA;then an attempt to offline the last housekeeping CPU will result in a&#xA;WARN_ON() when rebuilding the scheduler domains and a subsequent panic due&#xA;to and unhandled empty CPU mas in partition_sched_domains_locked().&#xA;&#xA;cpuset_hotplug_workfn()&#xA;  rebuild_sched_domains_locked()&#xA;    ndoms = generate_sched_domains(&amp;doms, &amp;attr);&#xA;      cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));&#xA;&#xA;Thus results in an empty CPU mask which triggers the warning and then the&#xA;subsequent crash:&#xA;&#xA;WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408&#xA;Call trace:&#xA; build_sched_domains+0x120c/0x1408&#xA; partition_sched_domains_locked+0x234/0x880&#xA; rebuild_sched_domains_locked+0x37c/0x798&#xA; rebuild_sched_domains+0x30/0x58&#xA; cpuset_hotplug_workfn+0x2a8/0x930&#xA;&#xA;Unable to handle kernel paging request at virtual address fffe80027ab37080&#xA; partition_sched_domains_locked+0x318/0x880&#xA; rebuild_sched_domains_locked+0x37c/0x798&#xA;&#xA;Aside of the resulting crash, it does not make any sense to offline the last&#xA;last housekeeping CPU.&#xA;&#xA;Prevent this by masking out the non-housekeeping CPUs when selecting a&#xA;target CPU for initiating the CPU unplug operation via the work queue.&#xA;CVE-2024-26886:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: af_bluetooth: Fix deadlock&#xA;&#xA;Attemting to do sock_lock on .recvmsg may cause a deadlock as shown&#xA;bellow, so instead of using sock_sock this uses sk_receive_queue.lock&#xA;on bt_sock_ioctl to avoid the UAF:&#xA;&#xA;INFO: task kworker/u9:1:121 blocked for more than 30 seconds.&#xA;      Not tainted 6.7.6-lemon #183&#xA;Workqueue: hci0 hci_rx_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __schedule+0x37d/0xa00&#xA; schedule+0x32/0xe0&#xA; __lock_sock+0x68/0xa0&#xA; ? __pfx_autoremove_wake_function+0x10/0x10&#xA; lock_sock_nested+0x43/0x50&#xA; l2cap_sock_recv_cb+0x21/0xa0&#xA; l2cap_recv_frame+0x55b/0x30a0&#xA; ? psi_task_switch+0xeb/0x270&#xA; ? finish_task_switch.isra.0+0x93/0x2a0&#xA; hci_rx_work+0x33a/0x3f0&#xA; process_one_work+0x13a/0x2f0&#xA; worker_thread+0x2f0/0x410&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0xe0/0x110&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x2c/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1b/0x30&#xA; &lt;/TASK&gt;&#xA;CVE-2024-27428:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2023-52682:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix to wait on block writeback for post_read case&#xA;&#xA;If inode is compressed, but not encrypted, it missed to call&#xA;f2fs_wait_on_block_writeback() to wait for GCed page writeback&#xA;in IPU write path.&#xA;&#xA;Thread A&#x9;&#x9;&#x9;&#x9;GC-Thread&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;- f2fs_gc&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; - do_garbage_collect&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  - gc_data_segment&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;   - move_data_block&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;    - f2fs_submit_page_write&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;     migrate normal cluster&#39;s block via&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;     meta_inode&#39;s page cache&#xA;- f2fs_write_single_data_page&#xA; - f2fs_do_write_data_page&#xA;  - f2fs_inplace_write_data&#xA;   - f2fs_submit_page_bio&#xA;&#xA;IRQ&#xA;- f2fs_read_end_io&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;IRQ&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;old data overrides new data due to&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;out-of-order GC and common IO.&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;- f2fs_read_end_io&#xA;CVE-2024-35897:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: discard table flag update with pending basechain deletion&#xA;&#xA;Hook unregistration is deferred to the commit phase, same occurs with&#xA;hook updates triggered by the table dormant flag. When both commands are&#xA;combined, this results in deleting a basechain while leaving its hook&#xA;still registered in the core.&#xA;CVE-2024-39507:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hns3: fix kernel crash problem in concurrent scenario&#xA;&#xA;When link status change, the nic driver need to notify the roce&#xA;driver to handle this event, but at this time, the roce driver&#xA;may uninit, then cause kernel crash.&#xA;&#xA;To fix the problem, when link status change, need to check&#xA;whether the roce registered, and when uninit, need to wait link&#xA;update finish.&#xA;CVE-2023-4244:A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.&#xA;&#xA;Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.&#xA;&#xA;We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.&#xA;CVE-2023-28746:Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.&#xA;CVE-2024-26920:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing/trigger: Fix to return error if failed to alloc snapshot&#xA;&#xA;Fix register_snapshot_trigger() to return error code if it failed to&#xA;allocate a snapshot instead of 0 (success). Unless that, it will register&#xA;snapshot trigger without an error.&#xA;CVE-2024-27013:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tun: limit printing rate when illegal packet received by tun dev&#xA;&#xA;vhost_worker will call tun call backs to receive packets. If too many&#xA;illegal packets arrives, tun_do_read will keep dumping packet contents.&#xA;When console is enabled, it will costs much more cpu time to dump&#xA;packet and soft lockup will be detected.&#xA;&#xA;net_ratelimit mechanism can be used to limit the dumping rate.&#xA;&#xA;PID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: &#34;vhost-32980&#34;&#xA; #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253&#xA; #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3&#xA; #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e&#xA; #3 [fffffe00003fced0] do_nmi at ffffffff8922660d&#xA; #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663&#xA;    [exception RIP: io_serial_in+20]&#xA;    RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002&#xA;    RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: 0000000000000000&#xA;    RDX: 00000000000003fd  RSI: 0000000000000005  RDI: ffffffff8af428a0&#xA;    RBP: 0000000000002710   R8: 0000000000000004   R9: 000000000000000f&#xA;    R10: 0000000000000000  R11: ffffffff8acbf64f  R12: 0000000000000020&#xA;    R13: ffffffff8acbf698  R14: 0000000000000058  R15: 0000000000000000&#xA;    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018&#xA; #5 [ffffa655314979e8] io_serial_in at ffffffff89792594&#xA; #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470&#xA; #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6&#xA; #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605&#xA; #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558&#xA; #10 [ffffa65531497ac8] console_unlock at ffffffff89316124&#xA; #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07&#xA; #12 [ffffa65531497b68] printk at ffffffff89318306&#xA; #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765&#xA; #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]&#xA; #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]&#xA; #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]&#xA; #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]&#xA; #18 [ffffa65531497f10] kthread at ffffffff892d2e72&#xA; #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f&#xA;CVE-2024-26957:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;s390/zcrypt: fix reference counting on zcrypt card objects&#xA;&#xA;Tests with hot-plugging crytpo cards on KVM guests with debug&#xA;kernel build revealed an use after free for the load field of&#xA;the struct zcrypt_card. The reason was an incorrect reference&#xA;handling of the zcrypt card object which could lead to a free&#xA;of the zcrypt card object while it was still in use.&#xA;&#xA;This is an example of the slab message:&#xA;&#xA;    kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b&#xA;    kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43&#xA;    kernel:  kmalloc_trace+0x3f2/0x470&#xA;    kernel:  zcrypt_card_alloc+0x36/0x70 [zcrypt]&#xA;    kernel:  zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]&#xA;    kernel:  ap_device_probe+0x15c/0x290&#xA;    kernel:  really_probe+0xd2/0x468&#xA;    kernel:  driver_probe_device+0x40/0xf0&#xA;    kernel:  __device_attach_driver+0xc0/0x140&#xA;    kernel:  bus_for_each_drv+0x8c/0xd0&#xA;    kernel:  __device_attach+0x114/0x198&#xA;    kernel:  bus_probe_device+0xb4/0xc8&#xA;    kernel:  device_add+0x4d2/0x6e0&#xA;    kernel:  ap_scan_adapter+0x3d0/0x7c0&#xA;    kernel:  ap_scan_bus+0x5a/0x3b0&#xA;    kernel:  ap_scan_bus_wq_callback+0x40/0x60&#xA;    kernel:  process_one_work+0x26e/0x620&#xA;    kernel:  worker_thread+0x21c/0x440&#xA;    kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43&#xA;    kernel:  kfree+0x37e/0x418&#xA;    kernel:  zcrypt_card_put+0x54/0x80 [zcrypt]&#xA;    kernel:  ap_device_remove+0x4c/0xe0&#xA;    kernel:  device_release_driver_internal+0x1c4/0x270&#xA;    kernel:  bus_remove_device+0x100/0x188&#xA;    kernel:  device_del+0x164/0x3c0&#xA;    kernel:  device_unregister+0x30/0x90&#xA;    kernel:  ap_scan_adapter+0xc8/0x7c0&#xA;    kernel:  ap_scan_bus+0x5a/0x3b0&#xA;    kernel:  ap_scan_bus_wq_callback+0x40/0x60&#xA;    kernel:  process_one_work+0x26e/0x620&#xA;    kernel:  worker_thread+0x21c/0x440&#xA;    kernel:  kthread+0x150/0x168&#xA;    kernel:  __ret_from_fork+0x3c/0x58&#xA;    kernel:  ret_from_fork+0xa/0x30&#xA;    kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)&#xA;    kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88&#xA;    kernel: Redzone  00000000885a74b0: bb bb bb bb bb bb bb bb                          ........&#xA;    kernel: Object   00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk&#xA;    kernel: Object   00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk&#xA;    kernel: Object   00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk&#xA;    kernel: Object   00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk&#xA;    kernel: Object   00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk&#xA;    kernel: Object   00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5  kkkkkkkkkkhKkkk.&#xA;    kernel: Redzone  00000000885a7518: bb bb bb bb bb bb bb bb                          ........&#xA;    kernel: Padding  00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ&#xA;    kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2&#xA;    kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)&#xA;    kernel: Call Trace:&#xA;    kernel:  [&lt;00000000ca5ab5b8&gt;] dump_stack_lvl+0x90/0x120&#xA;    kernel:  [&lt;00000000c99d78bc&gt;] check_bytes_and_report+0x114/0x140&#xA;    kernel:  [&lt;00000000c99d53cc&gt;] check_object+0x334/0x3f8&#xA;    kernel:  [&lt;00000000c99d820c&gt;] alloc_debug_processing+0xc4/0x1f8&#xA;    kernel:  [&lt;00000000c99d852e&gt;] get_partial_node.part.0+0x1ee/0x3e0&#xA;    kernel:  [&lt;00000000c99d94ec&gt;] ___slab_alloc+0xaf4/0x13c8&#xA;    kernel:  [&lt;00000000c99d9e38&gt;] __slab_alloc.constprop.0+0x78/0xb8&#xA;    kernel:  [&lt;00000000c99dc8dc&gt;] __kmalloc+0x434/0x590&#xA;    kernel:  [&lt;00000000c9b4c0ce&gt;] ext4_htree_store_dirent+0x4e/0x1c0&#xA;    kernel:  [&lt;00000000c9b908a2&gt;] htree_dirblock_to_tree+0x17a/0x3f0&#xA;    kernel: &#xA;---truncated---&#xA;CVE-2024-27017:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nft_set_pipapo: walk over current view on netlink dump&#xA;&#xA;The generation mask can be updated while netlink dump is in progress.&#xA;The pipapo set backend walk iterator cannot rely on it to infer what&#xA;view of the datastructure is to be used. Add notation to specify if user&#xA;wants to read/update the set.&#xA;&#xA;Based on patch from Florian Westphal.&#xA;CVE-2023-52653:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;SUNRPC: fix a memleak in gss_import_v2_context&#xA;&#xA;The ctx-&gt;mech_used.data allocated by kmemdup is not freed in neither&#xA;gss_import_v2_context nor it only caller gss_krb5_import_sec_context,&#xA;which frees ctx on error.&#xA;&#xA;Thus, this patch reform the last call of gss_import_v2_context to the&#xA;gss_krb5_import_ctx_v2, preventing the memleak while keepping the return&#xA;formation.&#xA;CVE-2024-27388:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;SUNRPC: fix some memleaks in gssx_dec_option_array&#xA;&#xA;The creds and oa-&gt;data need to be freed in the error-handling paths after&#xA;their allocation. So this patch add these deallocations in the&#xA;corresponding paths.&#xA;CVE-2024-27045:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Fix a potential buffer overflow in &#39;dp_dsc_clock_en_read()&#39;&#xA;&#xA;Tell snprintf() to store at most 10 bytes in the output buffer&#xA;instead of 30.&#xA;&#xA;Fixes the below:&#xA;drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10&#xA;CVE-2024-27024:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/rds: fix WARNING in rds_conn_connect_if_down&#xA;&#xA;If connection isn&#39;t established yet, get_mr() will fail, trigger connection after&#xA;get_mr().&#xA;CVE-2023-52691:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/pm: fix a double-free in si_dpm_init&#xA;&#xA;When the allocation of&#xA;adev-&gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,&#xA;amdgpu_free_extended_power_table is called to free some fields of adev.&#xA;However, when the control flow returns to si_dpm_sw_init, it goes to&#xA;label dpm_failed and calls si_dpm_fini, which calls&#xA;amdgpu_free_extended_power_table again and free those fields again. Thus&#xA;a double-free is triggered.&#xA;CVE-2022-49135:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Fix memory leak&#xA;&#xA;[why]&#xA;Resource release is needed on the error handling path&#xA;to prevent memory leak.&#xA;&#xA;[how]&#xA;Fix this by adding kfree on the error handling path.&#xA;CVE-2022-49371:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;driver core: fix deadlock in __device_attach&#xA;&#xA;In __device_attach function, The lock holding logic is as follows:&#xA;...&#xA;__device_attach&#xA;device_lock(dev)      // get lock dev&#xA;  async_schedule_dev(__device_attach_async_helper, dev); // func&#xA;    async_schedule_node&#xA;      async_schedule_node_domain(func)&#xA;        entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);&#xA;&#x9;/* when fail or work limit, sync to execute func, but&#xA;&#x9;   __device_attach_async_helper will get lock dev as&#xA;&#x9;   well, which will lead to A-A deadlock.  */&#xA;&#x9;if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK) {&#xA;&#x9;  func;&#xA;&#x9;else&#xA;&#x9;  queue_work_node(node, system_unbound_wq, &amp;entry-&gt;work)&#xA;  device_unlock(dev)&#xA;&#xA;As shown above, when it is allowed to do async probes, because of&#xA;out of memory or work limit, async work is not allowed, to do&#xA;sync execute instead. it will lead to A-A deadlock because of&#xA;__device_attach_async_helper getting lock dev.&#xA;&#xA;To fix the deadlock, move the async_schedule_dev outside device_lock,&#xA;as we can see, in async_schedule_node_domain, the parameter of&#xA;queue_work_node is system_unbound_wq, so it can accept concurrent&#xA;operations. which will also not change the code logic, and will&#xA;not lead to deadlock.&#xA;CVE-2024-26845:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: core: Add TMF to tmr_list handling&#xA;&#xA;An abort that is responded to by iSCSI itself is added to tmr_list but does&#xA;not go to target core. A LUN_RESET that goes through tmr_list takes a&#xA;refcounter on the abort and waits for completion. However, the abort will&#xA;be never complete because it was not started in target core.&#xA;&#xA; Unable to locate ITT: 0x05000000 on CID: 0&#xA; Unable to locate RefTaskTag: 0x05000000 on CID: 0.&#xA; wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop&#xA; wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop&#xA;...&#xA; INFO: task kworker/0:2:49 blocked for more than 491 seconds.&#xA; task:kworker/0:2     state:D stack:    0 pid:   49 ppid:     2 flags:0x00000800&#xA; Workqueue: events target_tmr_work [target_core_mod]&#xA;Call Trace:&#xA; __switch_to+0x2c4/0x470&#xA; _schedule+0x314/0x1730&#xA; schedule+0x64/0x130&#xA; schedule_timeout+0x168/0x430&#xA; wait_for_completion+0x140/0x270&#xA; target_put_cmd_and_wait+0x64/0xb0 [target_core_mod]&#xA; core_tmr_lun_reset+0x30/0xa0 [target_core_mod]&#xA; target_tmr_work+0xc8/0x1b0 [target_core_mod]&#xA; process_one_work+0x2d4/0x5d0&#xA; worker_thread+0x78/0x6c0&#xA;&#xA;To fix this, only add abort to tmr_list if it will be handled by target&#xA;core.&#xA;CVE-2024-26846:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-fc: do not wait in vain when unloading module&#xA;&#xA;The module exit path has race between deleting all controllers and&#xA;freeing &#39;left over IDs&#39;. To prevent double free a synchronization&#xA;between nvme_delete_ctrl and ida_destroy has been added by the initial&#xA;commit.&#xA;&#xA;There is some logic around trying to prevent from hanging forever in&#xA;wait_for_completion, though it does not handling all cases. E.g.&#xA;blktests is able to reproduce the situation where the module unload&#xA;hangs forever.&#xA;&#xA;If we completely rely on the cleanup code executed from the&#xA;nvme_delete_ctrl path, all IDs will be freed eventually. This makes&#xA;calling ida_destroy unnecessary. We only have to ensure that all&#xA;nvme_delete_ctrl code has been executed before we leave&#xA;nvme_fc_exit_module. This is done by flushing the nvme_delete_wq&#xA;workqueue.&#xA;&#xA;While at it, remove the unused nvme_fc_wq workqueue too.&#xA;CVE-2024-26880:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm: call the resume method on internal suspend&#xA;&#xA;There is this reported crash when experimenting with the lvm2 testsuite.&#xA;The list corruption is caused by the fact that the postsuspend and resume&#xA;methods were not paired correctly; there were two consecutive calls to the&#xA;origin_postsuspend function. The second call attempts to remove the&#xA;&#34;hash_list&#34; entry from a list, while it was already removed by the first&#xA;call.&#xA;&#xA;Fix __dm_internal_resume so that it calls the preresume and resume&#xA;methods of the table&#39;s targets.&#xA;&#xA;If a preresume method of some target fails, we are in a tricky situation.&#xA;We can&#39;t return an error because dm_internal_resume isn&#39;t supposed to&#xA;return errors. We can&#39;t return success, because then the &#34;resume&#34; and&#xA;&#34;postsuspend&#34; methods would not be paired correctly. So, we set the&#xA;DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace&#xA;tools, but it won&#39;t cause a kernel crash.&#xA;&#xA;------------[ cut here ]------------&#xA;kernel BUG at lib/list_debug.c:56!&#xA;invalid opcode: 0000 [#1] PREEMPT SMP&#xA;CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014&#xA;RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0&#xA;&lt;snip&gt;&#xA;RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282&#xA;RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000&#xA;RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff&#xA;RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058&#xA;R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001&#xA;R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0&#xA;FS:  00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033&#xA;CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? die+0x2d/0x80&#xA; ? do_trap+0xeb/0xf0&#xA; ? __list_del_entry_valid_or_report+0x77/0xc0&#xA; ? do_error_trap+0x60/0x80&#xA; ? __list_del_entry_valid_or_report+0x77/0xc0&#xA; ? exc_invalid_op+0x49/0x60&#xA; ? __list_del_entry_valid_or_report+0x77/0xc0&#xA; ? asm_exc_invalid_op+0x16/0x20&#xA; ? table_deps+0x1b0/0x1b0 [dm_mod]&#xA; ? __list_del_entry_valid_or_report+0x77/0xc0&#xA; origin_postsuspend+0x1a/0x50 [dm_snapshot]&#xA; dm_table_postsuspend_targets+0x34/0x50 [dm_mod]&#xA; dm_suspend+0xd8/0xf0 [dm_mod]&#xA; dev_suspend+0x1f2/0x2f0 [dm_mod]&#xA; ? table_deps+0x1b0/0x1b0 [dm_mod]&#xA; ctl_ioctl+0x300/0x5f0 [dm_mod]&#xA; dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]&#xA; __x64_compat_sys_ioctl+0x104/0x170&#xA; do_syscall_64+0x184/0x1b0&#xA; entry_SYSCALL_64_after_hwframe+0x46/0x4e&#xA;RIP: 0033:0xf7e6aead&#xA;&lt;snip&gt;&#xA;---[ end trace 0000000000000000 ]---&#xA;CVE-2024-26859:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/bnx2x: Prevent access to a freed page in page_pool&#xA;&#xA;Fix race condition leading to system crash during EEH error handling&#xA;&#xA;During EEH error recovery, the bnx2x driver&#39;s transmit timeout logic&#xA;could cause a race condition when handling reset tasks. The&#xA;bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),&#xA;which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()&#xA;SGEs are freed using bnx2x_free_rx_sge_range(). However, this could&#xA;overlap with the EEH driver&#39;s attempt to reset the device using&#xA;bnx2x_io_slot_reset(), which also tries to free SGEs. This race&#xA;condition can result in system crashes due to accessing freed memory&#xA;locations in bnx2x_free_rx_sge()&#xA;&#xA;799  static inline void bnx2x_free_rx_sge(struct bnx2x *bp,&#xA;800&#x9;&#x9;&#x9;&#x9;struct bnx2x_fastpath *fp, u16 index)&#xA;801  {&#xA;802&#x9;struct sw_rx_page *sw_buf = &amp;fp-&gt;rx_page_ring[index];&#xA;803     struct page *page = sw_buf-&gt;page;&#xA;....&#xA;where sw_buf was set to NULL after the call to dma_unmap_page()&#xA;by the preceding thread.&#xA;&#xA;    EEH: Beginning: &#39;slot_reset&#39;&#xA;    PCI 0011:01:00.0#10000: EEH: Invoking bnx2x-&gt;slot_reset()&#xA;    bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...&#xA;    bnx2x 0011:01:00.0: enabling device (0140 -&gt; 0142)&#xA;    bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --&gt; driver unload&#xA;    Kernel attempted to read user page (0) - exploit attempt? (uid: 0)&#xA;    BUG: Kernel NULL pointer dereference on read at 0x00000000&#xA;    Faulting instruction address: 0xc0080000025065fc&#xA;    Oops: Kernel access of bad area, sig: 11 [#1]&#xA;    .....&#xA;    Call Trace:&#xA;    [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)&#xA;    [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0&#xA;    [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550&#xA;    [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60&#xA;    [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170&#xA;    [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0&#xA;    [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64&#xA;&#xA;To solve this issue, we need to verify page pool allocations before&#xA;freeing.&#xA;CVE-2024-26739:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: act_mirred: don&#39;t override retval if we already lost the skb&#xA;&#xA;If we&#39;re redirecting the skb, and haven&#39;t called tcf_mirred_forward(),&#xA;yet, we need to tell the core to drop the skb by setting the retcode&#xA;to SHOT. If we have called tcf_mirred_forward(), however, the skb&#xA;is out of our hands and returning SHOT will lead to UaF.&#xA;&#xA;Move the retval override to the error path which actually need it.&#xA;CVE-2024-26804:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ip_tunnel: prevent perpetual headroom growth&#xA;&#xA;syzkaller triggered following kasan splat:&#xA;BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170&#xA;Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191&#xA;[..]&#xA; kasan_report+0xda/0x110 mm/kasan/report.c:588&#xA; __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170&#xA; skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]&#xA; ___skb_get_hash net/core/flow_dissector.c:1791 [inline]&#xA; __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856&#xA; skb_get_hash include/linux/skbuff.h:1556 [inline]&#xA; ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748&#xA; ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308&#xA; __netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA; xmit_one net/core/dev.c:3548 [inline]&#xA; dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564&#xA; __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349&#xA; dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA; neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592&#xA; ...&#xA; ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235&#xA; ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323&#xA; ..&#xA; iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82&#xA; ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831&#xA; ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665&#xA; __netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA; xmit_one net/core/dev.c:3548 [inline]&#xA; dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564&#xA; ...&#xA;&#xA;The splat occurs because skb-&gt;data points past skb-&gt;head allocated area.&#xA;This is because neigh layer does:&#xA;  __skb_pull(skb, skb_network_offset(skb));&#xA;&#xA;... but skb_network_offset() returns a negative offset and __skb_pull()&#xA;arg is unsigned.  IOW, we skb-&gt;data gets &#34;adjusted&#34; by a huge value.&#xA;&#xA;The negative value is returned because skb-&gt;head and skb-&gt;data distance is&#xA;more than 64k and skb-&gt;network_header (u16) has wrapped around.&#xA;&#xA;The bug is in the ip_tunnel infrastructure, which can cause&#xA;dev-&gt;needed_headroom to increment ad infinitum.&#xA;&#xA;The syzkaller reproducer consists of packets getting routed via a gre&#xA;tunnel, and route of gre encapsulated packets pointing at another (ipip)&#xA;tunnel.  The ipip encapsulation finds gre0 as next output device.&#xA;&#xA;This results in the following pattern:&#xA;&#xA;1). First packet is to be sent out via gre0.&#xA;Route lookup found an output device, ipip0.&#xA;&#xA;2).&#xA;ip_tunnel_xmit for gre0 bumps gre0-&gt;needed_headroom based on the future&#xA;output device, rt.dev-&gt;needed_headroom (ipip0).&#xA;&#xA;3).&#xA;ip output / start_xmit moves skb on to ipip0. which runs the same&#xA;code path again (xmit recursion).&#xA;&#xA;4).&#xA;Routing step for the post-gre0-encap packet finds gre0 as output device&#xA;to use for ipip0 encapsulated packet.&#xA;&#xA;tunl0-&gt;needed_headroom is then incremented based on the (already bumped)&#xA;gre0 device headroom.&#xA;&#xA;This repeats for every future packet:&#xA;&#xA;gre0-&gt;needed_headroom gets inflated because previous packets&#39; ipip0 step&#xA;incremented rt-&gt;dev (gre0) headroom, and ipip0 incremented because gre0&#xA;needed_headroom was increased.&#xA;&#xA;For each subsequent packet, gre/ipip0-&gt;needed_headroom grows until&#xA;post-expand-head reallocations result in a skb-&gt;head/data distance of&#xA;more than 64k.&#xA;&#xA;Once that happens, skb-&gt;network_header (u16) wraps around when&#xA;pskb_expand_head tries to make sure that skb_network_offset() is unchanged&#xA;after the headroom expansion/reallocation.&#xA;&#xA;After this skb_network_offset(skb) returns a different (and negative)&#xA;result post headroom expansion.&#xA;&#xA;The next trip to neigh layer (or anything else that would __skb_pull the&#xA;network header) makes skb-&gt;data point to a memory location outside&#xA;skb-&gt;head area.&#xA;&#xA;v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to&#xA;prevent perpetual increase instead of dropping the headroom increment&#xA;completely.&#xA;CVE-2023-52631:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix an NULL dereference bug&#xA;&#xA;The issue here is when this is called from ntfs_load_attr_list().  The&#xA;&#34;size&#34; comes from le32_to_cpu(attr-&gt;res.data_size) so it can&#39;t overflow&#xA;on a 64bit systems but on 32bit systems the &#34;+ 1023&#34; can overflow and&#xA;the result is zero.  This means that the kmalloc will succeed by&#xA;returning the ZERO_SIZE_PTR and then the memcpy() will crash with an&#xA;Oops on the next line.&#xA;CVE-2024-26687:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xen/events: close evtchn after mapping cleanup&#xA;&#xA;shutdown_pirq and startup_pirq are not taking the&#xA;irq_mapping_update_lock because they can&#39;t due to lock inversion. Both&#xA;are called with the irq_desc-&gt;lock being taking. The lock order,&#xA;however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.&#xA;&#xA;This opens multiple races:&#xA;- shutdown_pirq can be interrupted by a function that allocates an event&#xA;  channel:&#xA;&#xA;  CPU0                        CPU1&#xA;  shutdown_pirq {&#xA;    xen_evtchn_close(e)&#xA;                              __startup_pirq {&#xA;                                EVTCHNOP_bind_pirq&#xA;                                  -&gt; returns just freed evtchn e&#xA;                                set_evtchn_to_irq(e, irq)&#xA;                              }&#xA;    xen_irq_info_cleanup() {&#xA;      set_evtchn_to_irq(e, -1)&#xA;    }&#xA;  }&#xA;&#xA;  Assume here event channel e refers here to the same event channel&#xA;  number.&#xA;  After this race the evtchn_to_irq mapping for e is invalid (-1).&#xA;&#xA;- __startup_pirq races with __unbind_from_irq in a similar way. Because&#xA;  __startup_pirq doesn&#39;t take irq_mapping_update_lock it can grab the&#xA;  evtchn that __unbind_from_irq is currently freeing and cleaning up. In&#xA;  this case even though the event channel is allocated, its mapping can&#xA;  be unset in evtchn_to_irq.&#xA;&#xA;The fix is to first cleanup the mappings and then close the event&#xA;channel. In this way, when an event channel gets allocated it&#39;s&#xA;potential previous evtchn_to_irq mappings are guaranteed to be unset already.&#xA;This is also the reverse order of the allocation where first the event&#xA;channel is allocated and then the mappings are setup.&#xA;&#xA;On a 5.10 kernel prior to commit 3fcdaf3d7634 (&#34;xen/events: modify internal&#xA;[un]bind interfaces&#34;), we hit a BUG like the following during probing of NVMe&#xA;devices. The issue is that during nvme_setup_io_queues, pci_free_irq&#xA;is called for every device which results in a call to shutdown_pirq.&#xA;With many nvme devices it&#39;s therefore likely to hit this race during&#xA;boot because there will be multiple calls to shutdown_pirq and&#xA;startup_pirq are running potentially in parallel.&#xA;&#xA;  ------------[ cut here ]------------&#xA;  blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled&#xA;  kernel BUG at drivers/xen/events/events_base.c:499!&#xA;  invalid opcode: 0000 [#1] SMP PTI&#xA;  CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1&#xA;  Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006&#xA;  Workqueue: nvme-reset-wq nvme_reset_work&#xA;  RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0&#xA;  Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff &lt;0f&gt; 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00&#xA;  RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046&#xA;  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006&#xA;  RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff&#xA;  RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00&#xA;  R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed&#xA;  R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002&#xA;  FS:  0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0&#xA;  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;  Call Trace:&#xA;   ? show_trace_log_lvl+0x1c1/0x2d9&#xA;   ? show_trace_log_lvl+0x1c1/0x2d9&#xA;   ? set_affinity_irq+0xdc/0x1c0&#xA;   ? __die_body.cold+0x8/0xd&#xA;   ? die+0x2b/0x50&#xA;   ? do_trap+0x90/0x110&#xA;   ? bind_evtchn_to_cpu+0xdf/0xf0&#xA;   ? do_error_trap+0x65/0x80&#xA;   ? bind_evtchn_to_cpu+0xdf/0xf0&#xA;   ? exc_invalid_op+0x4e/0x70&#xA;   ? bind_evtchn_to_cpu+0xdf/0xf0&#xA;   ? asm_exc_invalid_op+0x12/0x20&#xA;   ? bind_evtchn_to_cpu+0xdf/0x&#xA;---truncated---&#xA;CVE-2024-26779:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mac80211: fix race condition on enabling fast-xmit&#xA;&#xA;fast-xmit must only be enabled after the sta has been uploaded to the driver,&#xA;otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls&#xA;to the driver, leading to potential crashes because of uninitialized drv_priv&#xA;data.&#xA;Add a missing sta-&gt;uploaded check and re-check fast xmit after inserting a sta.&#xA;CVE-2024-26766:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;IB/hfi1: Fix sdma.h tx-&gt;num_descs off-by-one error&#xA;&#xA;Unfortunately the commit `fd8958efe877` introduced another error&#xA;causing the `descs` array to overflow. This reults in further crashes&#xA;easily reproducible by `sendmsg` system call.&#xA;&#xA;[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI&#xA;[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]&#xA;--&#xA;[ 1080.974535] Call Trace:&#xA;[ 1080.976990]  &lt;TASK&gt;&#xA;[ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]&#xA;[ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]&#xA;[ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]&#xA;[ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]&#xA;[ 1081.046978]  dev_hard_start_xmit+0xc4/0x210&#xA;--&#xA;[ 1081.148347]  __sys_sendmsg+0x59/0xa0&#xA;&#xA;crash&gt; ipoib_txreq 0xffff9cfeba229f00&#xA;struct ipoib_txreq {&#xA;  txreq = {&#xA;    list = {&#xA;      next = 0xffff9cfeba229f00,&#xA;      prev = 0xffff9cfeba229f00&#xA;    },&#xA;    descp = 0xffff9cfeba229f40,&#xA;    coalesce_buf = 0x0,&#xA;    wait = 0xffff9cfea4e69a48,&#xA;    complete = 0xffffffffc0fe0760 &lt;hfi1_ipoib_sdma_complete&gt;,&#xA;    packet_len = 0x46d,&#xA;    tlen = 0x0,&#xA;    num_desc = 0x0,&#xA;    desc_limit = 0x6,&#xA;    next_descq_idx = 0x45c,&#xA;    coalesce_idx = 0x0,&#xA;    flags = 0x0,&#xA;    descs = {{&#xA;        qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)&#xA;      }, {&#xA;        qw = {  0x3800014231b108, 0x4}&#xA;      }, {&#xA;        qw = { 0x310000e4ee0fcf0, 0x8}&#xA;      }, {&#xA;        qw = {  0x3000012e9f8000, 0x8}&#xA;      }, {&#xA;        qw = {  0x59000dfb9d0000, 0x8}&#xA;      }, {&#xA;        qw = {  0x78000e02e40000, 0x8}&#xA;      }}&#xA;  },&#xA;  sdma_hdr =  0x400300015528b000,  &lt;&lt;&lt; invalid pointer in the tx request structure&#xA;  sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)&#xA;  complete = 0x0,&#xA;  priv = 0x0,&#xA;  txq = 0xffff9cfea4e69880,&#xA;  skb = 0xffff9d099809f400&#xA;}&#xA;&#xA;If an SDMA send consists of exactly 6 descriptors and requires dword&#xA;padding (in the 7th descriptor), the sdma_txreq descriptor array is not&#xA;properly expanded and the packet will overflow into the container&#xA;structure. This results in a panic when the send completion runs. The&#xA;exact panic varies depending on what elements of the container structure&#xA;get corrupted. The fix is to use the correct expression in&#xA;_pad_sdma_tx_descs() to test the need to expand the descriptor array.&#xA;&#xA;With this patch the crashes are no longer reproducible and the machine is&#xA;stable.&#xA;CVE-2023-52514:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2023-52489:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/sparsemem: fix race in accessing memory_section-&gt;usage&#xA;&#xA;The below race is observed on a PFN which falls into the device memory&#xA;region with the system memory configuration where PFN&#39;s are such that&#xA;[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL].  Since normal zone start and end&#xA;pfn contains the device memory PFN&#39;s as well, the compaction triggered&#xA;will try on the device memory PFN&#39;s too though they end up in NOP(because&#xA;pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections).  When&#xA;from other core, the section mappings are being removed for the&#xA;ZONE_DEVICE region, that the PFN in question belongs to, on which&#xA;compaction is currently being operated is resulting into the kernel crash&#xA;with CONFIG_SPASEMEM_VMEMAP enabled.  The crash logs can be seen at [1].&#xA;&#xA;compact_zone()&#x9;&#x9;&#x9;memunmap_pages&#xA;-------------&#x9;&#x9;&#x9;---------------&#xA;__pageblock_pfn_to_page&#xA;   ......&#xA; (a)pfn_valid():&#xA;     valid_section()//return true&#xA;&#x9;&#x9;&#x9;      (b)__remove_pages()-&gt;&#xA;&#x9;&#x9;&#x9;&#x9;  sparse_remove_section()-&gt;&#xA;&#x9;&#x9;&#x9;&#x9;    section_deactivate():&#xA;&#x9;&#x9;&#x9;&#x9;    [Free the array ms-&gt;usage and set&#xA;&#x9;&#x9;&#x9;&#x9;     ms-&gt;usage = NULL]&#xA;     pfn_section_valid()&#xA;     [Access ms-&gt;usage which&#xA;     is NULL]&#xA;&#xA;NOTE: From the above it can be said that the race is reduced to between&#xA;the pfn_valid()/pfn_section_valid() and the section deactivate with&#xA;SPASEMEM_VMEMAP enabled.&#xA;&#xA;The commit b943f045a9af(&#34;mm/sparse: fix kernel crash with&#xA;pfn_section_valid check&#34;) tried to address the same problem by clearing&#xA;the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns&#xA;false thus ms-&gt;usage is not accessed.&#xA;&#xA;Fix this issue by the below steps:&#xA;&#xA;a) Clear SECTION_HAS_MEM_MAP before freeing the -&gt;usage.&#xA;&#xA;b) RCU protected read side critical section will either return NULL&#xA;   when SECTION_HAS_MEM_MAP is cleared or can successfully access -&gt;usage.&#xA;&#xA;c) Free the -&gt;usage with kfree_rcu() and set ms-&gt;usage = NULL.  No&#xA;   attempt will be made to access -&gt;usage after this as the&#xA;   SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.&#xA;&#xA;Thanks to David/Pavan for their inputs on this patch.&#xA;&#xA;[1] https://lore.kernel.org/linux-mm/[email protected]/&#xA;&#xA;On Snapdragon SoC, with the mentioned memory configuration of PFN&#39;s as&#xA;[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of&#xA;issues daily while testing on a device farm.&#xA;&#xA;For this particular issue below is the log.  Though the below log is&#xA;not directly pointing to the pfn_section_valid(){ ms-&gt;usage;}, when we&#xA;loaded this dump on T32 lauterbach tool, it is pointing.&#xA;&#xA;[  540.578056] Unable to handle kernel NULL pointer dereference at&#xA;virtual address 0000000000000000&#xA;[  540.578068] Mem abort info:&#xA;[  540.578070]   ESR = 0x0000000096000005&#xA;[  540.578073]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[  540.578077]   SET = 0, FnV = 0&#xA;[  540.578080]   EA = 0, S1PTW = 0&#xA;[  540.578082]   FSC = 0x05: level 1 translation fault&#xA;[  540.578085] Data abort info:&#xA;[  540.578086]   ISV = 0, ISS = 0x00000005&#xA;[  540.578088]   CM = 0, WnR = 0&#xA;[  540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)&#xA;[  540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c&#xA;[  540.579454] lr : compact_zone+0x994/0x1058&#xA;[  540.579460] sp : ffffffc03579b510&#xA;[  540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c&#xA;[  540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640&#xA;[  540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000&#xA;[  540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140&#xA;[  540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff&#xA;[  540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001&#xA;[  540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440&#xA;[  540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4&#xA;[  540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000&#xA;---truncated---&#xA;CVE-2023-52619:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pstore/ram: Fix crash when setting number of cpus to an odd number&#xA;&#xA;When the number of cpu cores is adjusted to 7 or other odd numbers,&#xA;the zone size will become an odd number.&#xA;The address of the zone will become:&#xA;    addr of zone0 = BASE&#xA;    addr of zone1 = BASE + zone_size&#xA;    addr of zone2 = BASE + zone_size*2&#xA;    ...&#xA;The address of zone1/3/5/7 will be mapped to non-alignment va.&#xA;Eventually crashes will occur when accessing these va.&#xA;&#xA;So, use ALIGN_DOWN() to make sure the zone size is even&#xA;to avoid this bug.&#xA;CVE-2023-52586:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/msm/dpu: Add mutex lock in control vblank irq&#xA;&#xA;Add a mutex lock to control vblank irq to synchronize vblank&#xA;enable/disable operations happening from different threads to prevent&#xA;race conditions while registering/unregistering the vblank irq callback.&#xA;&#xA;v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a&#xA;    parameter of dpu_encoder_phys.&#xA;    -Switch from atomic refcnt to a simple int counter as mutex has&#xA;    now been added&#xA;v3: Mistakenly did not change wording in last version. It is done now.&#xA;v2: Slightly changed wording of commit message&#xA;&#xA;Patchwork: https://patchwork.freedesktop.org/patch/571854/&#xA;CVE-2023-52577:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dccp: fix dccp_v4_err()/dccp_v6_err() again&#xA;&#xA;dh-&gt;dccph_x is the 9th byte (offset 8) in &#34;struct dccp_hdr&#34;,&#xA;not in the &#34;byte 7&#34; as Jann claimed.&#xA;&#xA;We need to make sure the ICMP messages are big enough,&#xA;using more standard ways (no more assumptions).&#xA;&#xA;syzbot reported:&#xA;BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]&#xA;BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline]&#xA;BUG: KMSAN: uninit-value in dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94&#xA;pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]&#xA;pskb_may_pull include/linux/skbuff.h:2681 [inline]&#xA;dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94&#xA;icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867&#xA;icmpv6_rcv+0x19d5/0x30d0&#xA;ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438&#xA;ip6_input_finish net/ipv6/ip6_input.c:483 [inline]&#xA;NF_HOOK include/linux/netfilter.h:304 [inline]&#xA;ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492&#xA;ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586&#xA;dst_input include/net/dst.h:468 [inline]&#xA;ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79&#xA;NF_HOOK include/linux/netfilter.h:304 [inline]&#xA;ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310&#xA;__netif_receive_skb_one_core net/core/dev.c:5523 [inline]&#xA;__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637&#xA;netif_receive_skb_internal net/core/dev.c:5723 [inline]&#xA;netif_receive_skb+0x58/0x660 net/core/dev.c:5782&#xA;tun_rx_batched+0x83b/0x920&#xA;tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002&#xA;tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA;call_write_iter include/linux/fs.h:1985 [inline]&#xA;new_sync_write fs/read_write.c:491 [inline]&#xA;vfs_write+0x8ef/0x15c0 fs/read_write.c:584&#xA;ksys_write+0x20f/0x4c0 fs/read_write.c:637&#xA;__do_sys_write fs/read_write.c:649 [inline]&#xA;__se_sys_write fs/read_write.c:646 [inline]&#xA;__x64_sys_write+0x93/0xd0 fs/read_write.c:646&#xA;do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80&#xA;entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;Uninit was created at:&#xA;slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767&#xA;slab_alloc_node mm/slub.c:3478 [inline]&#xA;kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523&#xA;kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559&#xA;__alloc_skb+0x318/0x740 net/core/skbuff.c:650&#xA;alloc_skb include/linux/skbuff.h:1286 [inline]&#xA;alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313&#xA;sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795&#xA;tun_alloc_skb drivers/net/tun.c:1531 [inline]&#xA;tun_get_user+0x23cf/0x6940 drivers/net/tun.c:1846&#xA;tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048&#xA;call_write_iter include/linux/fs.h:1985 [inline]&#xA;new_sync_write fs/read_write.c:491 [inline]&#xA;vfs_write+0x8ef/0x15c0 fs/read_write.c:584&#xA;ksys_write+0x20f/0x4c0 fs/read_write.c:637&#xA;__do_sys_write fs/read_write.c:649 [inline]&#xA;__se_sys_write fs/read_write.c:646 [inline]&#xA;__x64_sys_write+0x93/0xd0 fs/read_write.c:646&#xA;do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80&#xA;entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023&#xA;CVE-2023-52525:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet&#xA;&#xA;Only skip the code path trying to access the rfc1042 headers when the&#xA;buffer is too small, so the driver can still process packets without&#xA;rfc1042 headers.&#xA;CVE-2024-26581:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nft_set_rbtree: skip end interval element from gc&#xA;&#xA;rbtree lazy gc on insert might collect an end interval element that has&#xA;been just added in this transactions, skip end interval elements that&#xA;are not yet active.&#xA;CVE-2024-26585:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tls: fix race between tx work scheduling and socket close&#xA;&#xA;Similarly to previous commit, the submitting thread (recvmsg/sendmsg)&#xA;may exit as soon as the async crypto handler calls complete().&#xA;Reorder scheduling the work before calling complete().&#xA;This seems more logical in the first place, as it&#39;s&#xA;the inverse order of what the submitting thread will do.&#xA;CVE-2024-26601:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: regenerate buddy after block freeing failed if under fc replay&#xA;&#xA;This mostly reverts commit 6bd97bf273bd (&#34;ext4: remove redundant&#xA;mb_regenerate_buddy()&#34;) and reintroduces mb_regenerate_buddy(). Based on&#xA;code in mb_free_blocks(), fast commit replay can end up marking as free&#xA;blocks that are already marked as such. This causes corruption of the&#xA;buddy bitmap so we need to regenerate it in that case.&#xA;CVE-2023-52482:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/srso: Add SRSO mitigation for Hygon processors&#xA;&#xA;Add mitigation for the speculative return stack overflow vulnerability&#xA;which exists on Hygon processors too.&#xA;CVE-2023-20569:&#xA;&#xA;&#xA;A side channel vulnerability on some of the AMD CPUs may allow an attacker to influence the return address prediction. This may result in speculative execution at an attacker-controlled address, potentially leading to information disclosure.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;CVE-2023-0597:A flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.&#xA;CVE-2023-0615:A memory leak flaw and potential divide by zero and Integer overflow was found in the Linux kernel V4L2 and vivid test code functionality. This issue occurs when a user triggers ioctls, such as VIDIOC_S_DV_TIMINGS ioctl. This could allow a local user to crash the system if vivid test code enabled.&#xA;CVE-2023-2860:An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.&#xA;CVE-2023-0590:A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem. This flaw leads to a denial of service issue. If patch ebda44da44f6 (&#34;net: sched: fix race condition in qdisc_graft()&#34;) not applied yet, then kernel could be affected.&#xA;CVE-2022-4129:A flaw was found in the Linux kernel&#39;s Layer 2 Tunneling Protocol (L2TP). A missing lock when clearing sk_user_data can lead to a race condition and NULL pointer dereference. A local user could use this flaw to potentially crash the system causing a denial of service.&#xA;CVE-2022-45934:An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets.&#xA;CVE-2022-4139:An incorrect TLB flush issue was found in the Linux kernel’s GPU i915 kernel driver, potentially leading to random memory corruption or data leaks. This flaw could allow a local user to crash the system or escalate their privileges on the system.&#xA;CVE-2022-20566:In l2cap_chan_put of l2cap_core, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-165329981References: Upstream kernel&#xA;CVE-2022-3643:Guests can trigger NIC interface reset/abort/crash via netback It is possible for a guest to trigger a NIC interface reset/abort/crash in a Linux based network backend by sending certain kinds of packets. It appears to be an (unwritten?) assumption in the rest of the Linux network stack that packet protocol headers are all contained within the linear section of the SKB and some NICs behave badly if this is not the case. This has been reported to occur with Cisco (enic) and Broadcom NetXtrem II BCM5780 (bnx2x) though it may be an issue with other NICs/drivers as well. In case the frontend is sending requests with split headers, netback will forward those violating above mentioned assumption to the networking core, resulting in said misbehavior.&#xA;CVE-2022-4378:A stack overflow flaw was found in the Linux kernel&#39;s SYSCTL subsystem in how a user changes certain kernel parameters and variables. This flaw allows a local user to crash or potentially escalate their privileges on the system.&#xA;CVE-2022-3114:An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.&#xA;CVE-2022-42896:There are use-after-free vulnerabilities in the Linux kernel&#39;s net/bluetooth/l2cap_core.c&#39;s l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim.&#xA;&#xA;We recommend upgrading past commit   https://www.google.com/url  https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url &#xA;&#xA;&#xA;CVE-2022-42895:There is an infoleak vulnerability in the Linux kernel&#39;s net/bluetooth/l2cap_core.c&#39;s l2cap_parse_conf_req function which can be used to leak kernel pointers remotely.&#xA;We recommend upgrading past commit  https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e https://www.google.com/url &#xA;&#xA;&#xA;CVE-2022-39842:An issue was discovered in the Linux kernel before 5.19. In pxa3xx_gcu_write in drivers/video/fbdev/pxa3xx-gcu.c, the count parameter has a type conflict of size_t versus int, causing an integer overflow and bypassing the size check. After that, because it is used as the third argument to copy_from_user(), a heap overflow may occur. NOTE: the original discoverer disputes that the overflow can actually happen.&#xA;CVE-2022-49535:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI&#xA;&#xA;If lpfc_issue_els_flogi() fails and returns non-zero status, the node&#xA;reference count is decremented to trigger the release of the nodelist&#xA;structure. However, if there is a prior registration or dev-loss-evt work&#xA;pending, the node may be released prematurely.  When dev-loss-evt&#xA;completes, the released node is referenced causing a use-after-free null&#xA;pointer dereference.&#xA;&#xA;Similarly, when processing non-zero ELS PLOGI completion status in&#xA;lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport&#xA;registration before triggering node removal.  If dev-loss-evt work is&#xA;pending, the node may be released prematurely and a subsequent call to&#xA;lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.&#xA;&#xA;Add test for pending dev-loss before decrementing the node reference count&#xA;for FLOGI, PLOGI, PRLI, and ADISC handling.&#xA;CVE-2024-58095:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: add check read-only before txBeginAnon() call&#xA;&#xA;Added a read-only check before calling `txBeginAnon` in `extAlloc`&#xA;and `extRecord`. This prevents modification attempts on a read-only&#xA;mounted filesystem, avoiding potential errors or crashes.&#xA;&#xA;Call trace:&#xA; txBeginAnon+0xac/0x154&#xA; extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78&#xA; jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248&#xA; __block_write_begin_int+0x580/0x166c fs/buffer.c:2128&#xA; __block_write_begin fs/buffer.c:2177 [inline]&#xA; block_write_begin+0x98/0x11c fs/buffer.c:2236&#xA; jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299&#xA;CVE-2022-50098:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts&#xA;&#xA;Ensure SRB is returned during I/O timeout error escalation. If that is not&#xA;possible fail the escalation path.&#xA;&#xA;Following crash stack was seen:&#xA;&#xA;BUG: unable to handle kernel paging request at 0000002f56aa90f8&#xA;IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]&#xA;Call Trace:&#xA; ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]&#xA; ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]&#xA; ? dma_pool_alloc+0x1d6/0x210&#xA; ? mempool_alloc+0x54/0x130&#xA; ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]&#xA; ? qla_do_work+0x2d/0x40 [qla2xxx]&#xA; ? process_one_work+0x14c/0x390&#xA;CVE-2025-38015:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: idxd: fix memory leak in error handling path of idxd_alloc&#xA;&#xA;Memory allocated for idxd is not freed if an error occurs during&#xA;idxd_alloc(). To fix it, free the allocated memory in the reverse order&#xA;of allocation before exiting the function in case of an error.&#xA;CVE-2025-38035:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvmet-tcp: don&#39;t restore null sk_state_change&#xA;&#xA;queue-&gt;state_change is set as part of nvmet_tcp_set_queue_sock(), but if&#xA;the TCP connection isn&#39;t established when nvmet_tcp_set_queue_sock() is&#xA;called then queue-&gt;state_change isn&#39;t set and sock-&gt;sk-&gt;sk_state_change&#xA;isn&#39;t replaced.&#xA;&#xA;As such we don&#39;t need to restore sock-&gt;sk-&gt;sk_state_change if&#xA;queue-&gt;state_change is NULL.&#xA;&#xA;This avoids NULL pointer dereferences such as this:&#xA;&#xA;[  286.462026][    C0] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[  286.462814][    C0] #PF: supervisor instruction fetch in kernel mode&#xA;[  286.463796][    C0] #PF: error_code(0x0010) - not-present page&#xA;[  286.464392][    C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0&#xA;[  286.465086][    C0] Oops: Oops: 0010 [#1] SMP KASAN PTI&#xA;[  286.465559][    C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)&#xA;[  286.466393][    C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014&#xA;[  286.467147][    C0] RIP: 0010:0x0&#xA;[  286.467420][    C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.&#xA;[  286.467977][    C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246&#xA;[  286.468425][    C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43&#xA;[  286.469019][    C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100&#xA;[  286.469545][    C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c&#xA;[  286.470072][    C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3&#xA;[  286.470585][    C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268&#xA;[  286.471070][    C0] FS:  00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000&#xA;[  286.471644][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  286.472543][    C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0&#xA;[  286.473500][    C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  286.474467][    C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400&#xA;[  286.475453][    C0] Call Trace:&#xA;[  286.476102][    C0]  &lt;IRQ&gt;&#xA;[  286.476719][    C0]  tcp_fin+0x2bb/0x440&#xA;[  286.477429][    C0]  tcp_data_queue+0x190f/0x4e60&#xA;[  286.478174][    C0]  ? __build_skb_around+0x234/0x330&#xA;[  286.478940][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.479659][    C0]  ? __pfx_tcp_data_queue+0x10/0x10&#xA;[  286.480431][    C0]  ? tcp_try_undo_loss+0x640/0x6c0&#xA;[  286.481196][    C0]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90&#xA;[  286.482046][    C0]  ? kvm_clock_get_cycles+0x14/0x30&#xA;[  286.482769][    C0]  ? ktime_get+0x66/0x150&#xA;[  286.483433][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.484146][    C0]  tcp_rcv_established+0x6e4/0x2050&#xA;[  286.484857][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.485523][    C0]  ? ipv4_dst_check+0x160/0x2b0&#xA;[  286.486203][    C0]  ? __pfx_tcp_rcv_established+0x10/0x10&#xA;[  286.486917][    C0]  ? lock_release+0x217/0x2c0&#xA;[  286.487595][    C0]  tcp_v4_do_rcv+0x4d6/0x9b0&#xA;[  286.488279][    C0]  tcp_v4_rcv+0x2af8/0x3e30&#xA;[  286.488904][    C0]  ? raw_local_deliver+0x51b/0xad0&#xA;[  286.489551][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.490198][    C0]  ? __pfx_tcp_v4_rcv+0x10/0x10&#xA;[  286.490813][    C0]  ? __pfx_raw_local_deliver+0x10/0x10&#xA;[  286.491487][    C0]  ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]&#xA;[  286.492275][    C0]  ? rcu_is_watching+0x11/0xb0&#xA;[  286.492900][    C0]  ip_protocol_deliver_rcu+0x8f/0x370&#xA;[  286.493579][    C0]  ip_local_deliver_finish+0x297/0x420&#xA;[  286.494268][    C0]  ip_local_deliver+0x168/0x430&#xA;[  286.494867][    C0]  ? __pfx_ip_local_deliver+0x10/0x10&#xA;[  286.495498][    C0]  ? __pfx_ip_local_deliver_finish+0x10/0x10&#xA;[  286.496204][    C0]  ? ip_rcv_finish_core+0x19a/0x1f20&#xA;[  286.496806][    C0]  ? lock_release+0x217/0x2c0&#xA;[  286.497414][    C0]  ip_rcv+0x455/0x6e0&#xA;[  286.497945][    C0]  ? __pfx_ip_rcv+0x10/0x10&#xA;[ &#xA;---truncated---&#xA;CVE-2025-38245:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().&#xA;&#xA;syzbot reported a warning below during atm_dev_register(). [0]&#xA;&#xA;Before creating a new device and procfs/sysfs for it, atm_dev_register()&#xA;looks up a duplicated device by __atm_dev_lookup().  These operations are&#xA;done under atm_dev_mutex.&#xA;&#xA;However, when removing a device in atm_dev_deregister(), it releases the&#xA;mutex just after removing the device from the list that __atm_dev_lookup()&#xA;iterates over.&#xA;&#xA;So, there will be a small race window where the device does not exist on&#xA;the device list but procfs/sysfs are still not removed, triggering the&#xA;splat.&#xA;&#xA;Let&#39;s hold the mutex until procfs/sysfs are removed in&#xA;atm_dev_deregister().&#xA;&#xA;[0]:&#xA;proc_dir_entry &#39;atm/atmtcp:0&#39; already registered&#xA;WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377&#xA;Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 &lt;0f&gt; 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48&#xA;RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248&#xA;RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001&#xA;RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140&#xA;R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444&#xA;FS:  00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; proc_create_data+0xbe/0x110 fs/proc/generic.c:585&#xA; atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361&#xA; atm_dev_register+0x46d/0x890 net/atm/resources.c:113&#xA; atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369&#xA; atmtcp_attach drivers/atm/atmtcp.c:403 [inline]&#xA; atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464&#xA; do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159&#xA; sock_do_ioctl+0x115/0x280 net/socket.c:1190&#xA; sock_ioctl+0x227/0x6b0 net/socket.c:1311&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:893 [inline]&#xA; __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f38b3b74459&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459&#xA;RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005&#xA;RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f&#xA;R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac&#xA;R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b&#xA; &lt;/TASK&gt;&#xA;CVE-2025-38324:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().&#xA;&#xA;As syzbot reported [0], mpls_route_input_rcu() can be called&#xA;from mpls_getroute(), where is under RTNL.&#xA;&#xA;net-&gt;mpls.platform_label is only updated under RTNL.&#xA;&#xA;Let&#39;s use rcu_dereference_rtnl() in mpls_route_input_rcu() to&#xA;silence the splat.&#xA;&#xA;[0]:&#xA;WARNING: suspicious RCU usage&#xA;6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted&#xA; ----------------------------&#xA;net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!&#xA;&#xA;other info that might help us debug this:&#xA;&#xA;rcu_scheduler_active = 2, debug_locks = 1&#xA;1 lock held by syz.2.4451/17730:&#xA; #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]&#xA; #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961&#xA;&#xA;stack backtrace:&#xA;CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120&#xA; lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865&#xA; mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84&#xA; mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381&#xA; rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964&#xA; netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]&#xA; netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339&#xA; netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg net/socket.c:727 [inline]&#xA; ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566&#xA; ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620&#xA; __sys_sendmmsg+0x200/0x420 net/socket.c:2709&#xA; __do_sys_sendmmsg net/socket.c:2736 [inline]&#xA; __se_sys_sendmmsg net/socket.c:2733 [inline]&#xA; __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f0a2818e969&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133&#xA;RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969&#xA;RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003&#xA;RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268&#xA; &lt;/TASK&gt;&#xA;CVE-2025-38391:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: altmodes/displayport: do not index invalid pin_assignments&#xA;&#xA;A poorly implemented DisplayPort Alt Mode port partner can indicate&#xA;that its pin assignment capabilities are greater than the maximum&#xA;value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show&#xA;will cause a BRK exception due to an out of bounds array access.&#xA;&#xA;Prevent for loop in pin_assignment_show from accessing&#xA;invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX&#xA;value in typec_dp.h and using i &lt; DP_PIN_ASSIGN_MAX as a loop&#xA;condition.&#xA;CVE-2025-38424:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf: Fix sample vs do_exit()&#xA;&#xA;Baisheng Gao reported an ARM64 crash, which Mark decoded as being a&#xA;synchronous external abort -- most likely due to trying to access&#xA;MMIO in bad ways.&#xA;&#xA;The crash further shows perf trying to do a user stack sample while in&#xA;exit_mmap()&#39;s tlb_finish_mmu() -- i.e. while tearing down the address&#xA;space it is trying to access.&#xA;&#xA;It turns out that we stop perf after we tear down the userspace mm; a&#xA;receipie for disaster, since perf likes to access userspace for&#xA;various reasons.&#xA;&#xA;Flip this order by moving up where we stop perf in do_exit().&#xA;&#xA;Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER&#xA;to abort when the current task does not have an mm (exit_mm() makes&#xA;sure to set current-&gt;mm = NULL; before commencing with the actual&#xA;teardown). Such that CPU wide events don&#39;t trip on this same problem.&#xA;CVE-2025-38466:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf: Revert to requiring CAP_SYS_ADMIN for uprobes&#xA;&#xA;Jann reports that uprobes can be used destructively when used in the&#xA;middle of an instruction. The kernel only verifies there is a valid&#xA;instruction at the requested offset, but due to variable instruction&#xA;length cannot determine if this is an instruction as seen by the&#xA;intended execution stream.&#xA;&#xA;Additionally, Mark Rutland notes that on architectures that mix data&#xA;in the text segment (like arm64), a similar things can be done if the&#xA;data word is &#39;mistaken&#39; for an instruction.&#xA;&#xA;As such, require CAP_SYS_ADMIN for uprobes.&#xA;CVE-2024-56616:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/dp_mst: Fix MST sideband message body length check&#xA;&#xA;Fix the MST sideband message body length check, which must be at least 1&#xA;byte accounting for the message body CRC (aka message data CRC) at the&#xA;end of the message.&#xA;&#xA;This fixes a case where an MST branch device returns a header with a&#xA;correct header CRC (indicating a correctly received body length), with&#xA;the body length being incorrectly set to 0. This will later lead to a&#xA;memory corruption in drm_dp_sideband_append_payload() and the following&#xA;errors in dmesg:&#xA;&#xA;   UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25&#xA;   index -1 is out of range for type &#39;u8 [48]&#39;&#xA;   Call Trace:&#xA;    drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]&#xA;    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]&#xA;    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]&#xA;&#xA;   memcpy: detected field-spanning write (size 18446744073709551615) of single field &#34;&amp;msg-&gt;msg[msg-&gt;curlen]&#34; at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)&#xA;   Call Trace:&#xA;    drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]&#xA;    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]&#xA;    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]&#xA;CVE-2024-57798:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()&#xA;&#xA;While receiving an MST up request message from one thread in&#xA;drm_dp_mst_handle_up_req(), the MST topology could be removed from&#xA;another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing&#xA;mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.&#xA;This could lead to a NULL deref/use-after-free of mst_primary in&#xA;drm_dp_mst_handle_up_req().&#xA;&#xA;Avoid the above by holding a reference for mst_primary in&#xA;drm_dp_mst_handle_up_req() while it&#39;s used.&#xA;&#xA;v2: Fix kfreeing the request if getting an mst_primary reference fails.&#xA;CVE-2025-21692:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sched: fix ets qdisc OOB Indexing&#xA;&#xA;Haowei Yan &lt;[email protected]&gt; found that ets_class_from_arg() can&#xA;index an Out-Of-Bound class in ets_class_from_arg() when passed clid of&#xA;0. The overflow may cause local privilege escalation.&#xA;&#xA; [   18.852298] ------------[ cut here ]------------&#xA; [   18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20&#xA; [   18.853743] index 18446744073709551615 is out of range for type &#39;ets_class [16]&#39;&#xA; [   18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17&#xA; [   18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA; [   18.856532] Call Trace:&#xA; [   18.857441]  &lt;TASK&gt;&#xA; [   18.858227]  dump_stack_lvl+0xc2/0xf0&#xA; [   18.859607]  dump_stack+0x10/0x20&#xA; [   18.860908]  __ubsan_handle_out_of_bounds+0xa7/0xf0&#xA; [   18.864022]  ets_class_change+0x3d6/0x3f0&#xA; [   18.864322]  tc_ctl_tclass+0x251/0x910&#xA; [   18.864587]  ? lock_acquire+0x5e/0x140&#xA; [   18.865113]  ? __mutex_lock+0x9c/0xe70&#xA; [   18.866009]  ? __mutex_lock+0xa34/0xe70&#xA; [   18.866401]  rtnetlink_rcv_msg+0x170/0x6f0&#xA; [   18.866806]  ? __lock_acquire+0x578/0xc10&#xA; [   18.867184]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10&#xA; [   18.867503]  netlink_rcv_skb+0x59/0x110&#xA; [   18.867776]  rtnetlink_rcv+0x15/0x30&#xA; [   18.868159]  netlink_unicast+0x1c3/0x2b0&#xA; [   18.868440]  netlink_sendmsg+0x239/0x4b0&#xA; [   18.868721]  ____sys_sendmsg+0x3e2/0x410&#xA; [   18.869012]  ___sys_sendmsg+0x88/0xe0&#xA; [   18.869276]  ? rseq_ip_fixup+0x198/0x260&#xA; [   18.869563]  ? rseq_update_cpu_node_id+0x10a/0x190&#xA; [   18.869900]  ? trace_hardirqs_off+0x5a/0xd0&#xA; [   18.870196]  ? syscall_exit_to_user_mode+0xcc/0x220&#xA; [   18.870547]  ? do_syscall_64+0x93/0x150&#xA; [   18.870821]  ? __memcg_slab_free_hook+0x69/0x290&#xA; [   18.871157]  __sys_sendmsg+0x69/0xd0&#xA; [   18.871416]  __x64_sys_sendmsg+0x1d/0x30&#xA; [   18.871699]  x64_sys_call+0x9e2/0x2670&#xA; [   18.871979]  do_syscall_64+0x87/0x150&#xA; [   18.873280]  ? do_syscall_64+0x93/0x150&#xA; [   18.874742]  ? lock_release+0x7b/0x160&#xA; [   18.876157]  ? do_user_addr_fault+0x5ce/0x8f0&#xA; [   18.877833]  ? irqentry_exit_to_user_mode+0xc2/0x210&#xA; [   18.879608]  ? irqentry_exit+0x77/0xb0&#xA; [   18.879808]  ? clear_bhb_loop+0x15/0x70&#xA; [   18.880023]  ? clear_bhb_loop+0x15/0x70&#xA; [   18.880223]  ? clear_bhb_loop+0x15/0x70&#xA; [   18.880426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA; [   18.880683] RIP: 0033:0x44a957&#xA; [   18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10&#xA; [   18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA; [   18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957&#xA; [   18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003&#xA; [   18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0&#xA; [   18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001&#xA; [   18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001&#xA; [   18.888395]  &lt;/TASK&gt;&#xA; [   18.888610] ---[ end trace ]---&#xA;CVE-2025-21700:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sched: Disallow replacing of child qdisc from one parent to another&#xA;&#xA;Lion Ackermann was able to create a UAF which can be abused for privilege&#xA;escalation with the following script&#xA;&#xA;Step 1. create root qdisc&#xA;tc qdisc add dev lo root handle 1:0 drr&#xA;&#xA;step2. a class for packet aggregation do demonstrate uaf&#xA;tc class add dev lo classid 1:1 drr&#xA;&#xA;step3. a class for nesting&#xA;tc class add dev lo classid 1:2 drr&#xA;&#xA;step4. a class to graft qdisc to&#xA;tc class add dev lo classid 1:3 drr&#xA;&#xA;step5.&#xA;tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024&#xA;&#xA;step6.&#xA;tc qdisc add dev lo parent 1:2 handle 3:0 drr&#xA;&#xA;step7.&#xA;tc class add dev lo classid 3:1 drr&#xA;&#xA;step 8.&#xA;tc qdisc add dev lo parent 3:1 handle 4:0 pfifo&#xA;&#xA;step 9. Display the class/qdisc layout&#xA;&#xA;tc class ls dev lo&#xA; class drr 1:1 root leaf 2: quantum 64Kb&#xA; class drr 1:2 root leaf 3: quantum 64Kb&#xA; class drr 3:1 root leaf 4: quantum 64Kb&#xA;&#xA;tc qdisc ls&#xA; qdisc drr 1: dev lo root refcnt 2&#xA; qdisc plug 2: dev lo parent 1:1&#xA; qdisc pfifo 4: dev lo parent 3:1 limit 1000p&#xA; qdisc drr 3: dev lo parent 1:2&#xA;&#xA;step10. trigger the bug &lt;=== prevented by this patch&#xA;tc qdisc replace dev lo parent 1:3 handle 4:0&#xA;&#xA;step 11. Redisplay again the qdiscs/classes&#xA;&#xA;tc class ls dev lo&#xA; class drr 1:1 root leaf 2: quantum 64Kb&#xA; class drr 1:2 root leaf 3: quantum 64Kb&#xA; class drr 1:3 root leaf 4: quantum 64Kb&#xA; class drr 3:1 root leaf 4: quantum 64Kb&#xA;&#xA;tc qdisc ls&#xA; qdisc drr 1: dev lo root refcnt 2&#xA; qdisc plug 2: dev lo parent 1:1&#xA; qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p&#xA; qdisc drr 3: dev lo parent 1:2&#xA;&#xA;Observe that a) parent for 4:0 does not change despite the replace request.&#xA;There can only be one parent.  b) refcount has gone up by two for 4:0 and&#xA;c) both class 1:3 and 3:1 are pointing to it.&#xA;&#xA;Step 12.  send one packet to plug&#xA;echo &#34;&#34; | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))&#xA;step13.  send one packet to the grafted fifo&#xA;echo &#34;&#34; | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))&#xA;&#xA;step14. lets trigger the uaf&#xA;tc class delete dev lo classid 1:3&#xA;tc class delete dev lo classid 1:1&#xA;&#xA;The semantics of &#34;replace&#34; is for a del/add _on the same node_ and not&#xA;a delete from one node(3:1) and add to another node (1:3) as in step10.&#xA;While we could &#34;fix&#34; with a more complex approach there could be&#xA;consequences to expectations so the patch takes the preventive approach of&#xA;&#34;disallow such config&#34;.&#xA;&#xA;Joint work with Lion Ackermann &lt;[email protected]&gt;&#xA;CVE-2025-21702:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pfifo_tail_enqueue: Drop new packet when sch-&gt;limit == 0&#xA;&#xA;Expected behaviour:&#xA;In case we reach scheduler&#39;s limit, pfifo_tail_enqueue() will drop a&#xA;packet in scheduler&#39;s queue and decrease scheduler&#39;s qlen by one.&#xA;Then, pfifo_tail_enqueue() enqueue new packet and increase&#xA;scheduler&#39;s qlen by one. Finally, pfifo_tail_enqueue() return&#xA;`NET_XMIT_CN` status code.&#xA;&#xA;Weird behaviour:&#xA;In case we set `sch-&gt;limit == 0` and trigger pfifo_tail_enqueue() on a&#xA;scheduler that has no packet, the &#39;drop a packet&#39; step will do nothing.&#xA;This means the scheduler&#39;s qlen still has value equal 0.&#xA;Then, we continue to enqueue new packet and increase scheduler&#39;s qlen by&#xA;one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by&#xA;one and return `NET_XMIT_CN` status code.&#xA;&#xA;The problem is:&#xA;Let&#39;s say we have two qdiscs: Qdisc_A and Qdisc_B.&#xA; - Qdisc_A&#39;s type must have &#39;-&gt;graft()&#39; function to create parent/child relationship.&#xA;   Let&#39;s say Qdisc_A&#39;s type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.&#xA; - Qdisc_B&#39;s type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.&#xA; - Qdisc_B is configured to have `sch-&gt;limit == 0`.&#xA; - Qdisc_A is configured to route the enqueued&#39;s packet to Qdisc_B.&#xA;&#xA;Enqueue packet through Qdisc_A will lead to:&#xA; - hfsc_enqueue(Qdisc_A) -&gt; pfifo_tail_enqueue(Qdisc_B)&#xA; - Qdisc_B-&gt;q.qlen += 1&#xA; - pfifo_tail_enqueue() return `NET_XMIT_CN`&#xA; - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` =&gt; hfsc_enqueue() don&#39;t increase qlen of Qdisc_A.&#xA;&#xA;The whole process lead to a situation where Qdisc_A-&gt;q.qlen == 0 and Qdisc_B-&gt;q.qlen == 1.&#xA;Replace &#39;hfsc&#39; with other type (for example: &#39;drr&#39;) still lead to the same problem.&#xA;This violate the design where parent&#39;s qlen should equal to the sum of its childrens&#39;qlen.&#xA;&#xA;Bug impact: This issue can be used for user-&gt;kernel privilege escalation when it is reachable.&#xA;CVE-2022-49183:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: act_ct: fix ref leak when switching zones&#xA;&#xA;When switching zones or network namespaces without doing a ct clear in&#xA;between, it is now leaking a reference to the old ct entry. That&#39;s&#xA;because tcf_ct_skb_nfct_cached() returns false and&#xA;tcf_ct_flow_table_lookup() may simply overwrite it.&#xA;&#xA;The fix is to, as the ct entry is not reusable, free it already at&#xA;tcf_ct_skb_nfct_cached().&#xA;CVE-2022-49420:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: annotate races around sk-&gt;sk_bound_dev_if&#xA;&#xA;UDP sendmsg() is lockless, and reads sk-&gt;sk_bound_dev_if while&#xA;this field can be changed by another thread.&#xA;&#xA;Adds minimal annotations to avoid KCSAN splats for UDP.&#xA;Following patches will add more annotations to potential lockless readers.&#xA;&#xA;BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg&#xA;&#xA;write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0:&#xA; __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221&#xA; ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272&#xA; inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576&#xA; __sys_connect_file net/socket.c:1900 [inline]&#xA; __sys_connect+0x197/0x1b0 net/socket.c:1917&#xA; __do_sys_connect net/socket.c:1927 [inline]&#xA; __se_sys_connect net/socket.c:1924 [inline]&#xA; __x64_sys_connect+0x3d/0x50 net/socket.c:1924&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;&#xA;read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1:&#xA; udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436&#xA; inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652&#xA; sock_sendmsg_nosec net/socket.c:705 [inline]&#xA; sock_sendmsg net/socket.c:725 [inline]&#xA; ____sys_sendmsg+0x39a/0x510 net/socket.c:2413&#xA; ___sys_sendmsg net/socket.c:2467 [inline]&#xA; __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553&#xA; __do_sys_sendmmsg net/socket.c:2582 [inline]&#xA; __se_sys_sendmmsg net/socket.c:2579 [inline]&#xA; __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;&#xA;value changed: 0x00000000 -&gt; 0xffffff9b&#xA;&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G        W         5.18.0-rc1-syzkaller-dirty #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;&#xA;I chose to not add Fixes: tag because race has minor consequences&#xA;and stable teams busy enough.&#xA;CVE-2025-21891:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvlan: ensure network headers are in skb linear part&#xA;&#xA;syzbot found that ipvlan_process_v6_outbound() was assuming&#xA;the IPv6 network header isis present in skb-&gt;head [1]&#xA;&#xA;Add the needed pskb_network_may_pull() calls for both&#xA;IPv4 and IPv6 handlers.&#xA;&#xA;[1]&#xA;BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47&#xA;  __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47&#xA;  ipv6_addr_type include/net/ipv6.h:555 [inline]&#xA;  ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline]&#xA;  ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651&#xA;  ip6_route_output include/net/ip6_route.h:93 [inline]&#xA;  ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476&#xA;  ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline]&#xA;  ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline]&#xA;  ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline]&#xA;  ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671&#xA;  ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223&#xA;  __netdev_start_xmit include/linux/netdevice.h:5150 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:5159 [inline]&#xA;  xmit_one net/core/dev.c:3735 [inline]&#xA;  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751&#xA;  sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343&#xA;  qdisc_restart net/sched/sch_generic.c:408 [inline]&#xA;  __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416&#xA;  qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127&#xA;  net_tx_action+0x78b/0x940 net/core/dev.c:5484&#xA;  handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561&#xA;  __do_softirq+0x14/0x1a kernel/softirq.c:595&#xA;  do_softirq+0x9a/0x100 kernel/softirq.c:462&#xA;  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389&#xA;  local_bh_enable include/linux/bottom_half.h:33 [inline]&#xA;  rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]&#xA;  __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611&#xA;  dev_queue_xmit include/linux/netdevice.h:3311 [inline]&#xA;  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276&#xA;  packet_snd net/packet/af_packet.c:3132 [inline]&#xA;  packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164&#xA;  sock_sendmsg_nosec net/socket.c:718 [inline]&#xA;CVE-2025-38063:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm: fix unconditional IO throttle caused by REQ_PREFLUSH&#xA;&#xA;When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()&#xA;generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,&#xA;which causes the flush_bio to be throttled by wbt_wait().&#xA;&#xA;An example from v5.4, similar problem also exists in upstream:&#xA;&#xA;    crash&gt; bt 2091206&#xA;    PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: &#34;kworker/u260:0&#34;&#xA;     #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8&#xA;     #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4&#xA;     #2 [ffff800084a2f880] schedule at ffff800040bfa4b4&#xA;     #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4&#xA;     #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc&#xA;     #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0&#xA;     #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254&#xA;     #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38&#xA;     #8 [ffff800084a2fa60] generic_make_request at ffff800040570138&#xA;     #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4&#xA;    #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]&#xA;    #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]&#xA;    #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]&#xA;    #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]&#xA;    #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]&#xA;    #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]&#xA;    #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08&#xA;    #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc&#xA;    #18 [ffff800084a2fe70] kthread at ffff800040118de4&#xA;&#xA;After commit 2def2845cc33 (&#34;xfs: don&#39;t allow log IO to be throttled&#34;),&#xA;the metadata submitted by xlog_write_iclog() should not be throttled.&#xA;But due to the existence of the dm layer, throttling flush_bio indirectly&#xA;causes the metadata bio to be throttled.&#xA;&#xA;Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes&#xA;wbt_should_throttle() return false to avoid wbt_wait().&#xA;CVE-2025-38125:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: stmmac: make sure that ptp_rate is not 0 before configuring EST&#xA;&#xA;If the ptp_rate recorded earlier in the driver happens to be 0, this&#xA;bogus value will propagate up to EST configuration, where it will&#xA;trigger a division by 0.&#xA;&#xA;Prevent this division by 0 by adding the corresponding check and error&#xA;code.&#xA;CVE-2025-38181:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().&#xA;&#xA;syzkaller reported a null-ptr-deref in sock_omalloc() while allocating&#xA;a CALIPSO option.  [0]&#xA;&#xA;The NULL is of struct sock, which was fetched by sk_to_full_sk() in&#xA;calipso_req_setattr().&#xA;&#xA;Since commit a1a5344ddbe8 (&#34;tcp: avoid two atomic ops for syncookies&#34;),&#xA;reqsk-&gt;rsk_listener could be NULL when SYN Cookie is returned to its&#xA;client, as hinted by the leading SYN Cookie log.&#xA;&#xA;Here are 3 options to fix the bug:&#xA;&#xA;  1) Return 0 in calipso_req_setattr()&#xA;  2) Return an error in calipso_req_setattr()&#xA;  3) Alaways set rsk_listener&#xA;&#xA;1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie&#xA;for CALIPSO.  3) is also no go as there have been many efforts to reduce&#xA;atomic ops and make TCP robust against DDoS.  See also commit 3b24d854cb35&#xA;(&#34;tcp/dccp: do not touch listener sk_refcnt under synflood&#34;).&#xA;&#xA;As of the blamed commit, SYN Cookie already did not need refcounting,&#xA;and no one has stumbled on the bug for 9 years, so no CALIPSO user will&#xA;care about SYN Cookie.&#xA;&#xA;Let&#39;s return an error in calipso_req_setattr() and calipso_req_delattr()&#xA;in the SYN Cookie case.&#xA;&#xA;This can be reproduced by [1] on Fedora and now connect() of nc times out.&#xA;&#xA;[0]:&#xA;TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]&#xA;CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]&#xA;RIP: 0010:sock_net include/net/sock.h:655 [inline]&#xA;RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806&#xA;Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b&#xA;RSP: 0018:ffff88811af89038 EFLAGS: 00010216&#xA;RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400&#xA;RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030&#xA;RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e&#xA;R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000&#xA;R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050&#xA;FS:  00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0&#xA;PKRU: 80000000&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288&#xA; calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204&#xA; calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597&#xA; netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249&#xA; selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342&#xA; selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551&#xA; security_inet_conn_request+0x50/0xa0 security/security.c:4945&#xA; tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825&#xA; tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275&#xA; tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328&#xA; tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781&#xA; tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667&#xA; tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904&#xA; ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436&#xA; ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480&#xA; NF_HOOK include/linux/netfilter.h:314 [inline]&#xA; NF_HOOK include/linux/netfilter.h:308 [inline]&#xA; ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491&#xA; dst_input include/net/dst.h:469 [inline]&#xA; ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]&#xA; ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69&#xA; NF_HOOK include/linux/netfilter.h:314 [inline]&#xA; NF_HOOK include/linux/netf&#xA;---truncated---&#xA;CVE-2025-38222:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: inline: fix len overflow in ext4_prepare_inline_data&#xA;&#xA;When running the following code on an ext4 filesystem with inline_data&#xA;feature enabled, it will lead to the bug below.&#xA;&#xA;        fd = open(&#34;file1&#34;, O_RDWR | O_CREAT | O_TRUNC, 0666);&#xA;        ftruncate(fd, 30);&#xA;        pwrite(fd, &#34;a&#34;, 1, (1UL &lt;&lt; 40) + 5UL);&#xA;&#xA;That happens because write_begin will succeed as when&#xA;ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len&#xA;will be truncated, leading to ext4_prepare_inline_data parameter to be 6&#xA;instead of 0x10000000006.&#xA;&#xA;Then, later when write_end is called, we hit:&#xA;&#xA;        BUG_ON(pos + len &gt; EXT4_I(inode)-&gt;i_inline_size);&#xA;&#xA;at ext4_write_inline_data.&#xA;&#xA;Fix it by using a loff_t type for the len parameter in&#xA;ext4_prepare_inline_data instead of an unsigned int.&#xA;&#xA;[   44.545164] ------------[ cut here ]------------&#xA;[   44.545530] kernel BUG at fs/ext4/inline.c:240!&#xA;[   44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI&#xA;[   44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full)  112853fcebfdb93254270a7959841d2c6aa2c8bb&#xA;[   44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100&#xA;[   44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b &lt;0f&gt; 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49&#xA;[   44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216&#xA;[   44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006&#xA;[   44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738&#xA;[   44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000&#xA;[   44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000&#xA;[   44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738&#xA;[   44.546523] FS:  00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000&#xA;[   44.546523] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0&#xA;[   44.546523] PKRU: 55555554&#xA;[   44.546523] Call Trace:&#xA;[   44.546523]  &lt;TASK&gt;&#xA;[   44.546523]  ext4_write_inline_data_end+0x126/0x2d0&#xA;[   44.546523]  generic_perform_write+0x17e/0x270&#xA;[   44.546523]  ext4_buffered_write_iter+0xc8/0x170&#xA;[   44.546523]  vfs_write+0x2be/0x3e0&#xA;[   44.546523]  __x64_sys_pwrite64+0x6d/0xc0&#xA;[   44.546523]  do_syscall_64+0x6a/0xf0&#xA;[   44.546523]  ? __wake_up+0x89/0xb0&#xA;[   44.546523]  ? xas_find+0x72/0x1c0&#xA;[   44.546523]  ? next_uptodate_folio+0x317/0x330&#xA;[   44.546523]  ? set_pte_range+0x1a6/0x270&#xA;[   44.546523]  ? filemap_map_pages+0x6ee/0x840&#xA;[   44.546523]  ? ext4_setattr+0x2fa/0x750&#xA;[   44.546523]  ? do_pte_missing+0x128/0xf70&#xA;[   44.546523]  ? security_inode_post_setattr+0x3e/0xd0&#xA;[   44.546523]  ? ___pte_offset_map+0x19/0x100&#xA;[   44.546523]  ? handle_mm_fault+0x721/0xa10&#xA;[   44.546523]  ? do_user_addr_fault+0x197/0x730&#xA;[   44.546523]  ? do_syscall_64+0x76/0xf0&#xA;[   44.546523]  ? arch_exit_to_user_mode_prepare+0x1e/0x60&#xA;[   44.546523]  ? irqentry_exit_to_user_mode+0x79/0x90&#xA;[   44.546523]  entry_SYSCALL_64_after_hwframe+0x55/0x5d&#xA;[   44.546523] RIP: 0033:0x7f42999c6687&#xA;[   44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 &lt;5b&gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff&#xA;[   44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012&#xA;[   44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687&#xA;[   44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003&#xA;[   44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000&#xA;[   44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000&#xA;---truncated---&#xA;CVE-2025-38263:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bcache: fix NULL pointer in cache_set_flush()&#xA;&#xA;1. LINE#1794 - LINE#1887 is some codes about function of&#xA;   bch_cache_set_alloc().&#xA;2. LINE#2078 - LINE#2142 is some codes about function of&#xA;   register_cache_set().&#xA;3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.&#xA;&#xA; 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)&#xA; 1795 {&#xA; ...&#xA; 1860         if (!(c-&gt;devices = kcalloc(c-&gt;nr_uuids, sizeof(void *), GFP_KERNEL)) ||&#xA; 1861             mempool_init_slab_pool(&amp;c-&gt;search, 32, bch_search_cache) ||&#xA; 1862             mempool_init_kmalloc_pool(&amp;c-&gt;bio_meta, 2,&#xA; 1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *&#xA; 1864                                 bucket_pages(c)) ||&#xA; 1865             mempool_init_kmalloc_pool(&amp;c-&gt;fill_iter, 1, iter_size) ||&#xA; 1866             bioset_init(&amp;c-&gt;bio_split, 4, offsetof(struct bbio, bio),&#xA; 1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||&#xA; 1868             !(c-&gt;uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||&#xA; 1869             !(c-&gt;moving_gc_wq = alloc_workqueue(&#34;bcache_gc&#34;,&#xA; 1870                                                 WQ_MEM_RECLAIM, 0)) ||&#xA; 1871             bch_journal_alloc(c) ||&#xA; 1872             bch_btree_cache_alloc(c) ||&#xA; 1873             bch_open_buckets_alloc(c) ||&#xA; 1874             bch_bset_sort_state_init(&amp;c-&gt;sort, ilog2(c-&gt;btree_pages)))&#xA; 1875                 goto err;&#xA;                      ^^^^^^^^&#xA; 1876&#xA; ...&#xA; 1883         return c;&#xA; 1884 err:&#xA; 1885         bch_cache_set_unregister(c);&#xA;              ^^^^^^^^^^^^^^^^^^^^^^^^^^^&#xA; 1886         return NULL;&#xA; 1887 }&#xA; ...&#xA; 2078 static const char *register_cache_set(struct cache *ca)&#xA; 2079 {&#xA; ...&#xA; 2098         c = bch_cache_set_alloc(&amp;ca-&gt;sb);&#xA; 2099         if (!c)&#xA; 2100                 return err;&#xA;                      ^^^^^^^^^^&#xA; ...&#xA; 2128         ca-&gt;set = c;&#xA; 2129         ca-&gt;set-&gt;cache[ca-&gt;sb.nr_this_dev] = ca;&#xA;              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^&#xA; ...&#xA; 2138         return NULL;&#xA; 2139 err:&#xA; 2140         bch_cache_set_unregister(c);&#xA; 2141         return err;&#xA; 2142 }&#xA;&#xA;(1) If LINE#1860 - LINE#1874 is true, then do &#39;goto err&#39;(LINE#1875) and&#xA;    call bch_cache_set_unregister()(LINE#1885).&#xA;(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.&#xA;(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the&#xA;    value to c-&gt;cache[], it means that c-&gt;cache[] is NULL.&#xA;&#xA;LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().&#xA;As (1), in LINE#1885 call&#xA;bch_cache_set_unregister()&#xA;---&gt; bch_cache_set_stop()&#xA;     ---&gt; closure_queue()&#xA;          -.-&gt; cache_set_flush() (as below LINE#1624)&#xA;&#xA; 1624 static void cache_set_flush(struct closure *cl)&#xA; 1625 {&#xA; ...&#xA; 1654         for_each_cache(ca, c, i)&#xA; 1655                 if (ca-&gt;alloc_thread)&#xA;                          ^^&#xA; 1656                         kthread_stop(ca-&gt;alloc_thread);&#xA; ...&#xA; 1665 }&#xA;&#xA;(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the&#xA;    kernel crash occurred as below:&#xA;[  846.712887] bcache: register_cache() error drbd6: cannot allocate memory&#xA;[  846.713242] bcache: register_bcache() error : failed to register device&#xA;[  846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered&#xA;[  846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8&#xA;[  846.714790] PGD 0 P4D 0&#xA;[  846.715129] Oops: 0000 [#1] SMP PTI&#xA;[  846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1&#xA;[  846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018&#xA;[  846.716451] Workqueue: events cache_set_flush [bcache]&#xA;[  846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]&#xA;[  846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 &lt;48&gt; 8b b8 f8 09 00 0&#xA;---truncated---&#xA;CVE-2025-38332:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: lpfc: Use memcpy() for BIOS version&#xA;&#xA;The strlcat() with FORTIFY support is triggering a panic because it&#xA;thinks the target buffer will overflow although the correct target&#xA;buffer size is passed in.&#xA;&#xA;Anyway, instead of memset() with 0 followed by a strlcat(), just use&#xA;memcpy() and ensure that the resulting buffer is NULL terminated.&#xA;&#xA;BIOSVersion is only used for the lpfc_printf_log() which expects a&#xA;properly terminated string.&#xA;CVE-2025-38387:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/mlx5: Initialize obj_event-&gt;obj_sub_list before xa_insert&#xA;&#xA;The obj_event may be loaded immediately after inserted, then if the&#xA;list_head is not initialized then we may get a poisonous pointer.  This&#xA;fixes the crash below:&#xA;&#xA; mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced)&#xA; mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056&#xA; mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0&#xA; mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps&#xA; IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready&#xA; Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060&#xA; Mem abort info:&#xA;   ESR = 0x96000006&#xA;   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;   SET = 0, FnV = 0&#xA;   EA = 0, S1PTW = 0&#xA; Data abort info:&#xA;   ISV = 0, ISS = 0x00000006&#xA;   CM = 0, WnR = 0&#xA; user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000&#xA; [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000&#xA; Internal error: Oops: 96000006 [#1] SMP&#xA; Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E)&#xA;  [last unloaded: mst_pci]&#xA; CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G           OE K   5.10.134-13.1.an8.aarch64 #1&#xA; Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023&#xA; pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--)&#xA; pc : dispatch_event_fd+0x68/0x300 [mlx5_ib]&#xA; lr : devx_event_notifier+0xcc/0x228 [mlx5_ib]&#xA; sp : ffff80001005bcf0&#xA; x29: ffff80001005bcf0 x28: 0000000000000001&#xA; x27: ffff244e0740a1d8 x26: ffff244e0740a1d0&#xA; x25: ffffda56beff5ae0 x24: ffffda56bf911618&#xA; x23: ffff244e0596a480 x22: ffff244e0596a480&#xA; x21: ffff244d8312ad90 x20: ffff244e0596a480&#xA; x19: fffffffffffffff0 x18: 0000000000000000&#xA; x17: 0000000000000000 x16: ffffda56be66d620&#xA; x15: 0000000000000000 x14: 0000000000000000&#xA; x13: 0000000000000000 x12: 0000000000000000&#xA; x11: 0000000000000040 x10: ffffda56bfcafb50&#xA; x9 : ffffda5655c25f2c x8 : 0000000000000010&#xA; x7 : 0000000000000000 x6 : ffff24545a2e24b8&#xA; x5 : 0000000000000003 x4 : ffff80001005bd28&#xA; x3 : 0000000000000000 x2 : 0000000000000000&#xA; x1 : ffff244e0596a480 x0 : ffff244d8312ad90&#xA; Call trace:&#xA;  dispatch_event_fd+0x68/0x300 [mlx5_ib]&#xA;  devx_event_notifier+0xcc/0x228 [mlx5_ib]&#xA;  atomic_notifier_call_chain+0x58/0x80&#xA;  mlx5_eq_async_int+0x148/0x2b0 [mlx5_core]&#xA;  atomic_notifier_call_chain+0x58/0x80&#xA;  irq_int_handler+0x20/0x30 [mlx5_core]&#xA;  __handle_irq_event_percpu+0x60/0x220&#xA;  handle_irq_event_percpu+0x3c/0x90&#xA;  handle_irq_event+0x58/0x158&#xA;  handle_fasteoi_irq+0xfc/0x188&#xA;  generic_handle_irq+0x34/0x48&#xA;  ...&#xA;CVE-2025-38362:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Add null pointer check for get_first_active_display()&#xA;&#xA;The function mod_hdcp_hdcp1_enable_encryption() calls the function&#xA;get_first_active_display(), but does not check its return value.&#xA;The return value is a null pointer if the display list is empty.&#xA;This will lead to a null pointer dereference in&#xA;mod_hdcp_hdcp2_enable_encryption().&#xA;&#xA;Add a null pointer check for get_first_active_display() and return&#xA;MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.&#xA;CVE-2025-38371:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/v3d: Disable interrupts before resetting the GPU&#xA;&#xA;Currently, an interrupt can be triggered during a GPU reset, which can&#xA;lead to GPU hangs and NULL pointer dereference in an interrupt context&#xA;as shown in the following trace:&#xA;&#xA; [  314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0&#xA; [  314.043822] Mem abort info:&#xA; [  314.046606]   ESR = 0x0000000096000005&#xA; [  314.050347]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA; [  314.055651]   SET = 0, FnV = 0&#xA; [  314.058695]   EA = 0, S1PTW = 0&#xA; [  314.061826]   FSC = 0x05: level 1 translation fault&#xA; [  314.066694] Data abort info:&#xA; [  314.069564]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000&#xA; [  314.075039]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA; [  314.080080]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA; [  314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000&#xA; [  314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000&#xA; [  314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP&#xA; [  314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight&#xA; [  314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1  Debian 1:6.12.25-1+rpt1&#xA; [  314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)&#xA; [  314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; [  314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]&#xA; [  314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]&#xA; [  314.160198] sp : ffffffc080003ea0&#xA; [  314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000&#xA; [  314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0&#xA; [  314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000&#xA; [  314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000&#xA; [  314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000&#xA; [  314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001&#xA; [  314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874&#xA; [  314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180&#xA; [  314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb&#xA; [  314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000&#xA; [  314.234807] Call trace:&#xA; [  314.237243]  v3d_irq+0xec/0x2e0 [v3d]&#xA; [  314.240906]  __handle_irq_event_percpu+0x58/0x218&#xA; [  314.245609]  handle_irq_event+0x54/0xb8&#xA; [  314.249439]  handle_fasteoi_irq+0xac/0x240&#xA; [  314.253527]  handle_irq_desc+0x48/0x68&#xA; [  314.257269]  generic_handle_domain_irq+0x24/0x38&#xA; [  314.261879]  gic_handle_irq+0x48/0xd8&#xA; [  314.265533]  call_on_irq_stack+0x24/0x58&#xA; [  314.269448]  do_interrupt_handler+0x88/0x98&#xA; [  314.273624]  el1_interrupt+0x34/0x68&#xA; [  314.277193]  el1h_64_irq_handler+0x18/0x28&#xA; [  314.281281]  el1h_64_irq+0x64/0x68&#xA; [  314.284673]  default_idle_call+0x3c/0x168&#xA; [  314.288675]  do_idle+0x1fc/0x230&#xA; [  314.291895]  cpu_startup_entry+0x3c/0x50&#xA; [  314.295810]  rest_init+0xe4/0xf0&#xA; [  314.299030]  start_kernel+0x5e8/0x790&#xA; [  314.302684]  __primary_switched+0x80/0x90&#xA; [  314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)&#xA; [  314.312775] ---[ end trace 0000000000000000 ]---&#xA; [  314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt&#xA; [  314.324249] SMP: stopping secondary CPUs&#xA; [  314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000&#xA; [  314.334076] PHYS_OFFSET: 0x0&#xA; [  314.336946] CPU features: 0x08,00002013,c0200000,0200421b&#xA; [  314.342337] Memory Limit: none&#xA; [  314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---&#xA;&#xA;Before resetting the G&#xA;---truncated---&#xA;CVE-2025-38386:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPICA: Refuse to evaluate a method if arguments are missing&#xA;&#xA;As reported in [1], a platform firmware update that increased the number&#xA;of method parameters and forgot to update a least one of its callers,&#xA;caused ACPICA to crash due to use-after-free.&#xA;&#xA;Since this a result of a clear AML issue that arguably cannot be fixed&#xA;up by the interpreter (it cannot produce missing data out of thin air),&#xA;address it by making ACPICA refuse to evaluate a method if the caller&#xA;attempts to pass fewer arguments than expected to it.&#xA;CVE-2025-38439:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT&#xA;&#xA;When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()&#xA;with the proper length instead of 0.  This bug triggers this warning&#xA;on a system with IOMMU enabled:&#xA;&#xA;WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170&#xA;RIP: 0010:__iommu_dma_unmap+0x159/0x170&#xA;Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45&#xA;b8 4c 89 45 c0 e9 77 ff ff ff &lt;0f&gt; 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00&#xA;RSP: 0018:ff22d31181150c88 EFLAGS: 00010206&#xA;RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000&#xA;R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00&#xA;FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA;&lt;IRQ&gt;&#xA;? show_regs+0x6d/0x80&#xA;? __warn+0x89/0x160&#xA;? __iommu_dma_unmap+0x159/0x170&#xA;? report_bug+0x17e/0x1b0&#xA;? handle_bug+0x46/0x90&#xA;? exc_invalid_op+0x18/0x80&#xA;? asm_exc_invalid_op+0x1b/0x20&#xA;? __iommu_dma_unmap+0x159/0x170&#xA;? __iommu_dma_unmap+0xb3/0x170&#xA;iommu_dma_unmap_page+0x4f/0x100&#xA;dma_unmap_page_attrs+0x52/0x220&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? xdp_return_frame+0x2e/0xd0&#xA;bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]&#xA;__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]&#xA;bnxt_poll+0xd3/0x1e0 [bnxt_en]&#xA;CVE-2025-38459:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: clip: Fix infinite recursive call of clip_push().&#xA;&#xA;syzbot reported the splat below. [0]&#xA;&#xA;This happens if we call ioctl(ATMARP_MKIP) more than once.&#xA;&#xA;During the first call, clip_mkip() sets clip_push() to vcc-&gt;push(),&#xA;and the second call copies it to clip_vcc-&gt;old_push().&#xA;&#xA;Later, when the socket is close()d, vcc_destroy_socket() passes&#xA;NULL skb to clip_push(), which calls clip_vcc-&gt;old_push(),&#xA;triggering the infinite recursion.&#xA;&#xA;Let&#39;s prevent the second ioctl(ATMARP_MKIP) by checking&#xA;vcc-&gt;user_back, which is allocated by the first call as clip_vcc.&#xA;&#xA;Note also that we use lock_sock() to prevent racy calls.&#xA;&#xA;[0]:&#xA;BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)&#xA;Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI&#xA;CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191&#xA;Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 &lt;41&gt; 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00&#xA;RSP: 0018:ffffc9000d670000 EFLAGS: 00010246&#xA;RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000&#xA;RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e&#xA;R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300&#xA;R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578&#xA;FS:  000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; clip_push+0x6dc/0x720 net/atm/clip.c:200&#xA; clip_push+0x6dc/0x720 net/atm/clip.c:200&#xA; clip_push+0x6dc/0x720 net/atm/clip.c:200&#xA;...&#xA; clip_push+0x6dc/0x720 net/atm/clip.c:200&#xA; clip_push+0x6dc/0x720 net/atm/clip.c:200&#xA; clip_push+0x6dc/0x720 net/atm/clip.c:200&#xA; vcc_destroy_socket net/atm/common.c:183 [inline]&#xA; vcc_release+0x157/0x460 net/atm/common.c:205&#xA; __sock_release net/socket.c:647 [inline]&#xA; sock_close+0xc0/0x240 net/socket.c:1391&#xA; __fput+0x449/0xa70 fs/file_table.c:465&#xA; task_work_run+0x1d1/0x260 kernel/task_work.c:227&#xA; resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]&#xA; exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114&#xA; exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline]&#xA; syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline]&#xA; syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline]&#xA; do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7ff31c98e929&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4&#xA;RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929&#xA;RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003&#xA;RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f&#xA;R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c&#xA;R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;CVE-2025-38474:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: net: sierra: check for no status endpoint&#xA;&#xA;The driver checks for having three endpoints and&#xA;having bulk in and out endpoints, but not that&#xA;the third endpoint is interrupt input.&#xA;Rectify the omission.&#xA;CVE-2025-21920:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vlan: enforce underlying device type&#xA;&#xA;Currently, VLAN devices can be created on top of non-ethernet devices.&#xA;&#xA;Besides the fact that it doesn&#39;t make much sense, this also causes a&#xA;bug which leaks the address of a kernel function to usermode.&#xA;&#xA;When creating a VLAN device, we initialize GARP (garp_init_applicant)&#xA;and MRP (mrp_init_applicant) for the underlying device.&#xA;&#xA;As part of the initialization process, we add the multicast address of&#xA;each applicant to the underlying device, by calling dev_mc_add.&#xA;&#xA;__dev_mc_add uses dev-&gt;addr_len to determine the length of the new&#xA;multicast address.&#xA;&#xA;This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6,&#xA;since the multicast addresses provided by GARP and MRP are only 6&#xA;bytes long.&#xA;&#xA;This behaviour can be reproduced using the following commands:&#xA;&#xA;ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo&#xA;ip l set up dev gretest&#xA;ip link add link gretest name vlantest type vlan id 100&#xA;&#xA;Then, the following command will display the address of garp_pdu_rcv:&#xA;&#xA;ip maddr show | grep 01:80:c2:00:00:21&#xA;&#xA;Fix the bug by enforcing the type of the underlying device during VLAN&#xA;device initialization.&#xA;CVE-2025-21926:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: gso: fix ownership in __udp_gso_segment&#xA;&#xA;In __udp_gso_segment the skb destructor is removed before segmenting the&#xA;skb but the socket reference is kept as-is. This is an issue if the&#xA;original skb is later orphaned as we can hit the following bug:&#xA;&#xA;  kernel BUG at ./include/linux/skbuff.h:3312!  (skb_orphan)&#xA;  RIP: 0010:ip_rcv_core+0x8b2/0xca0&#xA;  Call Trace:&#xA;   ip_rcv+0xab/0x6e0&#xA;   __netif_receive_skb_one_core+0x168/0x1b0&#xA;   process_backlog+0x384/0x1100&#xA;   __napi_poll.constprop.0+0xa1/0x370&#xA;   net_rx_action+0x925/0xe50&#xA;&#xA;The above can happen following a sequence of events when using&#xA;OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an&#xA;OVS_ACTION_ATTR_OUTPUT action:&#xA;&#xA;1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb&#xA;   goes through queue_gso_packets and then __udp_gso_segment, where its&#xA;   destructor is removed.&#xA;2. The segments&#39; data are copied and sent to userspace.&#xA;3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the&#xA;   same original skb is sent to its path.&#xA;4. If it later hits skb_orphan, we hit the bug.&#xA;&#xA;Fix this by also removing the reference to the socket in&#xA;__udp_gso_segment.&#xA;CVE-2025-22004:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: atm: fix use after free in lec_send()&#xA;&#xA;The -&gt;send() operation frees skb so save the length before calling&#xA;-&gt;send() to avoid a use after free.&#xA;CVE-2025-23142:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: detect and prevent references to a freed transport in sendmsg&#xA;&#xA;sctp_sendmsg() re-uses associations and transports when possible by&#xA;doing a lookup based on the socket endpoint and the message destination&#xA;address, and then sctp_sendmsg_to_asoc() sets the selected transport in&#xA;all the message chunks to be sent.&#xA;&#xA;There&#39;s a possible race condition if another thread triggers the removal&#xA;of that selected transport, for instance, by explicitly unbinding an&#xA;address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have&#xA;been set up and before the message is sent. This can happen if the send&#xA;buffer is full, during the period when the sender thread temporarily&#xA;releases the socket lock in sctp_wait_for_sndbuf().&#xA;&#xA;This causes the access to the transport data in&#xA;sctp_outq_select_transport(), when the association outqueue is flushed,&#xA;to result in a use-after-free read.&#xA;&#xA;This change avoids this scenario by having sctp_transport_free() signal&#xA;the freeing of the transport, tagging it as &#34;dead&#34;. In order to do this,&#xA;the patch restores the &#34;dead&#34; bit in struct sctp_transport, which was&#xA;removed in&#xA;commit 47faa1e4c50e (&#34;sctp: remove the dead field of sctp_transport&#34;).&#xA;&#xA;Then, in the scenario where the sender thread has released the socket&#xA;lock in sctp_wait_for_sndbuf(), the bit is checked again after&#xA;re-acquiring the socket lock to detect the deletion. This is done while&#xA;holding a reference to the transport to prevent it from being freed in&#xA;the process.&#xA;&#xA;If the transport was deleted while the socket lock was relinquished,&#xA;sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the&#xA;send.&#xA;&#xA;The bug was found by a private syzbot instance (see the error report [1]&#xA;and the C reproducer that triggers it [2]).&#xA;CVE-2025-37823:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too&#xA;&#xA;Similarly to the previous patch, we need to safe guard hfsc_dequeue()&#xA;too. But for this one, we don&#39;t have a reliable reproducer.&#xA;CVE-2024-58237:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: consider that tail calls invalidate packet pointers&#xA;&#xA;Tail-called programs could execute any of the helpers that invalidate&#xA;packet pointers. Hence, conservatively assume that each tail call&#xA;invalidates packet pointers.&#xA;&#xA;Making the change in bpf_helper_changes_pkt_data() automatically makes&#xA;use of check_cfg() logic that computes &#39;changes_pkt_data&#39; effect for&#xA;global sub-programs, such that the following program could be&#xA;rejected:&#xA;&#xA;    int tail_call(struct __sk_buff *sk)&#xA;    {&#xA;    &#x9;bpf_tail_call_static(sk, &amp;jmp_table, 0);&#xA;    &#x9;return 0;&#xA;    }&#xA;&#xA;    SEC(&#34;tc&#34;)&#xA;    int not_safe(struct __sk_buff *sk)&#xA;    {&#xA;    &#x9;int *p = (void *)(long)sk-&gt;data;&#xA;    &#x9;... make p valid ...&#xA;    &#x9;tail_call(sk);&#xA;    &#x9;*p = 42; /* this is unsafe */&#xA;    &#x9;...&#xA;    }&#xA;&#xA;The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that&#xA;can invalidate packet pointers. Otherwise, it can&#39;t be freplaced with&#xA;tailcall_freplace.c:entry_freplace() that does a tail call.&#xA;CVE-2025-38352:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()&#xA;&#xA;If an exiting non-autoreaping task has already passed exit_notify() and&#xA;calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent&#xA;or debugger right after unlock_task_sighand().&#xA;&#xA;If a concurrent posix_cpu_timer_del() runs at that moment, it won&#39;t be&#xA;able to detect timer-&gt;it.cpu.firing != 0: cpu_timer_task_rcu() and/or&#xA;lock_task_sighand() will fail.&#xA;&#xA;Add the tsk-&gt;exit_state check into run_posix_cpu_timers() to fix this.&#xA;&#xA;This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because&#xA;exit_task_work() is called before exit_notify(). But the check still&#xA;makes sense, task_work_add(&amp;tsk-&gt;posix_cputimers_work.work) will fail&#xA;anyway in this case.&#xA;CVE-2022-49623:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powerpc/xive/spapr: correct bitmap allocation size&#xA;&#xA;kasan detects access beyond the end of the xibm-&gt;bitmap allocation:&#xA;&#xA;BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140&#xA;Read of size 8 at addr c00000001d1d0118 by task swapper/0/1&#xA;&#xA;CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28&#xA;Call Trace:&#xA;[c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable)&#xA;[c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710&#xA;[c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354&#xA;[c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0&#xA;[c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140&#xA;[c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260&#xA;[c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450&#xA;[c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118&#xA;[c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac&#xA;[c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640&#xA;[c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0&#xA;[c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64&#xA;&#xA;Allocated by task 0:&#xA; kasan_save_stack+0x34/0x70&#xA; __kasan_kmalloc+0xb4/0xf0&#xA; __kmalloc+0x268/0x540&#xA; xive_spapr_init+0x4d0/0x77c&#xA; pseries_init_irq+0x40/0x27c&#xA; init_IRQ+0x44/0x84&#xA; start_kernel+0x2a4/0x538&#xA; start_here_common+0x1c/0x20&#xA;&#xA;The buggy address belongs to the object at c00000001d1d0118&#xA; which belongs to the cache kmalloc-8 of size 8&#xA;The buggy address is located 0 bytes inside of&#xA; 8-byte region [c00000001d1d0118, c00000001d1d0120)&#xA;&#xA;The buggy address belongs to the physical page:&#xA;page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d&#xA;flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff)&#xA;raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480&#xA;raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;&#xA;Memory state around the buggy address:&#xA; c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA; c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;&gt;c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc&#xA;                            ^&#xA; c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc&#xA; c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc&#xA;&#xA;This happens because the allocation uses the wrong unit (bits) when it&#xA;should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small&#xA;numbers of bits, the allocated object can be smaller than sizeof(long),&#xA;which results in invalid accesses.&#xA;&#xA;Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with&#xA;bitmap_free() for consistency.&#xA;CVE-2024-58093:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI/ASPM: Fix link state exit during switch upstream function removal&#xA;&#xA;Before 456d8aa37d0f (&#34;PCI/ASPM: Disable ASPM on MFD function removal to&#xA;avoid use-after-free&#34;), we would free the ASPM link only after the last&#xA;function on the bus pertaining to the given link was removed.&#xA;&#xA;That was too late. If function 0 is removed before sibling function,&#xA;link-&gt;downstream would point to free&#39;d memory after.&#xA;&#xA;After above change, we freed the ASPM parent link state upon any function&#xA;removal on the bus pertaining to a given link.&#xA;&#xA;That is too early. If the link is to a PCIe switch with MFD on the upstream&#xA;port, then removing functions other than 0 first would free a link which&#xA;still remains parent_link to the remaining downstream ports.&#xA;&#xA;The resulting GPFs are especially frequent during hot-unplug, because&#xA;pciehp removes devices on the link bus in reverse order.&#xA;&#xA;On that switch, function 0 is the virtual P2P bridge to the internal bus.&#xA;Free exactly when function 0 is removed -- before the parent link is&#xA;obsolete, but after all subordinate links are gone.&#xA;&#xA;[kwilczynski: commit log]&#xA;CVE-2025-37796:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: at76c50x: fix use after free access in at76_disconnect&#xA;&#xA;The memory pointed to by priv is freed at the end of at76_delete_device&#xA;function (using ieee80211_free_hw). But the code then accesses the udev&#xA;field of the freed object to put the USB device. This may also lead to a&#xA;memory leak of the usb device. Fix this by using udev from interface.&#xA;CVE-2025-37798:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;codel: remove sch-&gt;q.qlen check before qdisc_tree_reduce_backlog()&#xA;&#xA;After making all -&gt;qlen_notify() callbacks idempotent, now it is safe to&#xA;remove the check of qlen!=0 from both fq_codel_dequeue() and&#xA;codel_qdisc_dequeue().&#xA;CVE-2025-37915:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: drr: Fix double list add in class with netem as child qdisc&#xA;&#xA;As described in Gerrard&#39;s report [1], there are use cases where a netem&#xA;child qdisc will make the parent qdisc&#39;s enqueue callback reentrant.&#xA;In the case of drr, there won&#39;t be a UAF, but the code will add the same&#xA;classifier to the list twice, which will cause memory corruption.&#xA;&#xA;In addition to checking for qlen being zero, this patch checks whether the&#xA;class was already added to the active_list (cl_is_active) before adding&#xA;to the list to cover for the reentrant case.&#xA;&#xA;[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/&#xA;CVE-2025-37913:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: qfq: Fix double list add in class with netem as child qdisc&#xA;&#xA;As described in Gerrard&#39;s report [1], there are use cases where a netem&#xA;child qdisc will make the parent qdisc&#39;s enqueue callback reentrant.&#xA;In the case of qfq, there won&#39;t be a UAF, but the code will add the same&#xA;classifier to the list twice, which will cause memory corruption.&#xA;&#xA;This patch checks whether the class was already added to the agg-&gt;active&#xA;list (cl_is_active) before doing the addition to cater for the reentrant&#xA;case.&#xA;&#xA;[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/&#xA;CVE-2025-38180:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: atm: fix /proc/net/atm/lec handling&#xA;&#xA;/proc/net/atm/lec must ensure safety against dev_lec[] changes.&#xA;&#xA;It appears it had dev_put() calls without prior dev_hold(),&#xA;leading to imbalance and UAF.&#xA;CVE-2025-38323:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: atm: add lec_mutex&#xA;&#xA;syzbot found its way in net/atm/lec.c, and found an error path&#xA;in lecd_attach() could leave a dangling pointer in dev_lec[].&#xA;&#xA;Add a mutex to protect dev_lecp[] uses from lecd_attach(),&#xA;lec_vcc_attach() and lec_mcast_attach().&#xA;&#xA;Following patch will use this mutex for /proc/net/atm/lec.&#xA;&#xA;BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]&#xA;BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008&#xA;Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142&#xA;&#xA;CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:94 [inline]&#xA;  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA;  print_address_description mm/kasan/report.c:408 [inline]&#xA;  print_report+0xcd/0x680 mm/kasan/report.c:521&#xA;  kasan_report+0xe0/0x110 mm/kasan/report.c:634&#xA;  lecd_attach net/atm/lec.c:751 [inline]&#xA;  lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008&#xA;  do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159&#xA;  sock_do_ioctl+0x118/0x280 net/socket.c:1190&#xA;  sock_ioctl+0x227/0x6b0 net/socket.c:1311&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;  __se_sys_ioctl fs/ioctl.c:893 [inline]&#xA;  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893&#xA;  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;  do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 6132:&#xA;  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47&#xA;  kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA;  poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA;  __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394&#xA;  kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA;  __do_kmalloc_node mm/slub.c:4328 [inline]&#xA;  __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015&#xA;  alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711&#xA;  lecd_attach net/atm/lec.c:737 [inline]&#xA;  lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008&#xA;  do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159&#xA;  sock_do_ioctl+0x118/0x280 net/socket.c:1190&#xA;  sock_ioctl+0x227/0x6b0 net/socket.c:1311&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;  __se_sys_ioctl fs/ioctl.c:893 [inline]&#xA;  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893&#xA;  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;  do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Freed by task 6132:&#xA;  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47&#xA;  kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA;  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576&#xA;  poison_slab_object mm/kasan/common.c:247 [inline]&#xA;  __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264&#xA;  kasan_slab_free include/linux/kasan.h:233 [inline]&#xA;  slab_free_hook mm/slub.c:2381 [inline]&#xA;  slab_free mm/slub.c:4643 [inline]&#xA;  kfree+0x2b4/0x4d0 mm/slub.c:4842&#xA;  free_netdev+0x6c5/0x910 net/core/dev.c:11892&#xA;  lecd_attach net/atm/lec.c:744 [inline]&#xA;  lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008&#xA;  do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159&#xA;  sock_do_ioctl+0x118/0x280 net/socket.c:1190&#xA;  sock_ioctl+0x227/0x6b0 net/socket.c:1311&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;  __se_sys_ioctl fs/ioctl.c:893 [inline]&#xA;  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893&#xA;CVE-2025-38495:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: core: ensure the allocated report buffer can contain the reserved report ID&#xA;&#xA;When the report ID is not used, the low level transport drivers expect&#xA;the first byte to be 0. However, currently the allocated buffer not&#xA;account for that extra byte, meaning that instead of having 8 guaranteed&#xA;bytes for implement to be working, we only have 7.&#xA;CVE-2025-38529:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;comedi: aio_iiro_16: Fix bit shift out of bounds&#xA;&#xA;When checking for a supported IRQ number, the following test is used:&#xA;&#xA;&#x9;if ((1 &lt;&lt; it-&gt;options[1]) &amp; 0xdcfc) {&#xA;&#xA;However, `it-&gt;options[i]` is an unchecked `int` value from userspace, so&#xA;the shift amount could be negative or out of bounds.  Fix the test by&#xA;requiring `it-&gt;options[1]` to be within bounds before proceeding with&#xA;the original test.  Valid `it-&gt;options[1]` values that select the IRQ&#xA;will be in the range [1,15]. The value 0 explicitly disables the use of&#xA;interrupts.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-tools-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/kernel-tools-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="278.0.0.181.u183" version="5.10.0">
					<filename>python3-perf-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/python3-perf-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="278.0.0.181.u183" version="5.10.0">
					<filename>perf-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/perf-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-devel-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/kernel-devel-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="278.0.0.181.u183" version="5.10.0">
					<filename>bpftool-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/bpftool-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/kernel-tools-devel-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/kernel-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-headers-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/kernel-headers-5.10.0-278.0.0.181.u183.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-tools-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/kernel-tools-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/kernel-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="278.0.0.181.u183" version="5.10.0">
					<filename>python3-perf-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/python3-perf-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/kernel-tools-devel-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="278.0.0.181.u183" version="5.10.0">
					<filename>perf-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/perf-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="278.0.0.181.u183" version="5.10.0">
					<filename>bpftool-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/bpftool-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-devel-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/kernel-devel-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="278.0.0.181.u183" version="5.10.0">
					<filename>kernel-headers-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/kernel-headers-5.10.0-278.0.0.181.u183.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2265</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55668&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55668" id="CVE-2025-55668" title="CVE-2025-55668" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48989&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48989" id="CVE-2025-48989" title="CVE-2025-48989" type="cve"></reference>
		</references>
		<description>CVE-2025-55668:Session Fixation vulnerability in Apache Tomcat via rewrite valve.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105.&#xA;Older, EOL versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.&#xA;CVE-2025-48989:Improper Resource Shutdown or Release vulnerability in Apache Tomcat made Tomcat vulnerable to the made you reset attack.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.9, from 10.1.0-M1 through 10.1.43 and from 9.0.0.M1 through 9.0.107. Older, EOL versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to one of versions 11.0.10, 10.1.44 or 9.0.108 which fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="1" name="tomcat" release="8.u20" version="9.0.100">
					<filename>tomcat-9.0.100-8.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/tomcat-9.0.100-8.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="8.u20" version="9.0.100">
					<filename>tomcat-help-9.0.100-8.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/tomcat-help-9.0.100-8.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="8.u20" version="9.0.100">
					<filename>tomcat-jsvc-9.0.100-8.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/tomcat-jsvc-9.0.100-8.u20.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2266</id>
		<title>An update for rubygem-rack is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46727" id="CVE-2025-46727" title="CVE-2025-46727" type="cve"></reference>
		</references>
		<description>CVE-2025-46727:Rack is a modular Ruby web server interface. Prior to versions 2.2.14, 3.0.16, and 3.1.14, `Rack::QueryParser` parses query strings and `application/x-www-form-urlencoded` bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters. The vulnerability arises because `Rack::QueryParser` iterates over each `&amp;`-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing. An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted. Versions 2.2.14, 3.0.16, and 3.1.14 fix the issue. Some other mitigations are available. One may use middleware to enforce a maximum query string size or parameter count, or employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies. Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="1" name="rubygem-rack" release="9.u5" version="2.2.3.1">
					<filename>rubygem-rack-2.2.3.1-9.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rubygem-rack-2.2.3.1-9.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-rack-help" release="9.u5" version="2.2.3.1">
					<filename>rubygem-rack-help-2.2.3.1-9.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rubygem-rack-help-2.2.3.1-9.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2267</id>
		<title>An update for rust is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24575&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24575" id="CVE-2024-24575" title="CVE-2024-24575" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21658&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-21658" id="CVE-2022-21658" title="CVE-2022-21658" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-46176" id="CVE-2022-46176" title="CVE-2022-46176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38497&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-38497" id="CVE-2023-38497" title="CVE-2023-38497" type="cve"></reference>
		</references>
		<description>CVE-2024-24575:libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Using well-crafted inputs to `git_revparse_single` can cause the function to enter an infinite loop, potentially causing a Denial of Service attack in the calling application. The revparse function in `src/libgit2/revparse.c` uses a loop to parse the user-provided spec string. There is an edge-case during parsing that allows a bad actor to force the loop conditions to access arbitrary memory. Potentially, this could also leak memory if the extracted rev spec is reflected back to the attacker. As such, libgit2 versions before 1.4.0 are not affected. Users should upgrade to version 1.6.5 or 1.7.2.&#xA;CVE-2022-21658:Rust is a multi-paradigm, general-purpose programming language designed for performance and safety, especially safe concurrency. The Rust Security Response WG was notified that the `std::fs::remove_dir_all` standard library function is vulnerable a race condition enabling symlink following (CWE-363). An attacker could use this security issue to trick a privileged program into deleting files and directories the attacker couldn&#39;t otherwise access or delete. Rust 1.0.0 through Rust 1.58.0 is affected by this vulnerability with 1.58.1 containing a patch. Note that the following build targets don&#39;t have usable APIs to properly mitigate the attack, and are thus still vulnerable even with a patched toolchain: macOS before version 10.10 (Yosemite) and REDOX. We recommend everyone to update to Rust 1.58.1 as soon as possible, especially people developing programs expected to run in privileged contexts (including system daemons and setuid binaries), as those have the highest risk of being affected by this. Note that adding checks in your codebase before calling remove_dir_all will not mitigate the vulnerability, as they would also be vulnerable to race conditions like remove_dir_all itself. The existing mitigation is working as intended outside of race conditions.&#xA;CVE-2022-46176:Cargo is a Rust package manager. The Rust Security Response WG was notified that Cargo did not perform SSH host key verification when cloning indexes and dependencies via SSH. An attacker could exploit this to perform man-in-the-middle (MITM) attacks. This vulnerability has been assigned CVE-2022-46176. All Rust versions containing Cargo before 1.66.1 are vulnerable. Note that even if you don&#39;t explicitly use SSH for alternate registry indexes or crate dependencies, you might be affected by this vulnerability if you have configured git to replace HTTPS connections to GitHub with SSH (through git&#39;s [`url.&lt;base&gt;.insteadOf`][1] setting), as that&#39;d cause you to clone the crates.io index through SSH. Rust 1.66.1 will ensure Cargo checks the SSH host key and abort the connection if the server&#39;s public key is not already trusted. We recommend everyone to upgrade as soon as possible. &#xA;CVE-2023-38497:Cargo downloads the Rust project’s dependencies and compiles the project. Cargo prior to version 0.72.2, bundled with Rust prior to version 1.71.1, did not respect the umask when extracting crate archives on UNIX-like systems. If the user downloaded a crate containing files writeable by any local user, another local user could exploit this to change the source code compiled and executed by the current user. To prevent existing cached extractions from being exploitable, the Cargo binary version 0.72.2 included in Rust 1.71.1 or later will purge caches generated by older Cargo versions automatically. As a workaround, configure one&#39;s system to prevent other local users from accessing the Cargo directory, usually located in `~/.cargo`.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="rust-debugger-common" release="1.u2" version="1.76.0">
					<filename>rust-debugger-common-1.76.0-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-debugger-common-1.76.0-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-gdb" release="1.u2" version="1.76.0">
					<filename>rust-gdb-1.76.0-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-gdb-1.76.0-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-src" release="1.u2" version="1.76.0">
					<filename>rust-src-1.76.0-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-src-1.76.0-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rust-lldb" release="1.u2" version="1.76.0">
					<filename>rust-lldb-1.76.0-1.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-lldb-1.76.0-1.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rustfmt" release="1.u2" version="1.76.0">
					<filename>rustfmt-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rustfmt-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust" release="1.u2" version="1.76.0">
					<filename>rust-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clippy" release="1.u2" version="1.76.0">
					<filename>clippy-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clippy-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-help" release="1.u2" version="1.76.0">
					<filename>rust-help-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-help-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cargo" release="1.u2" version="1.76.0">
					<filename>cargo-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/cargo-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-analyzer" release="1.u2" version="1.76.0">
					<filename>rust-analyzer-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-analyzer-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rust-std-static" release="1.u2" version="1.76.0">
					<filename>rust-std-static-1.76.0-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/rust-std-static-1.76.0-1.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-analyzer" release="1.u2" version="1.76.0">
					<filename>rust-analyzer-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/rust-analyzer-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rustfmt" release="1.u2" version="1.76.0">
					<filename>rustfmt-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/rustfmt-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-help" release="1.u2" version="1.76.0">
					<filename>rust-help-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/rust-help-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cargo" release="1.u2" version="1.76.0">
					<filename>cargo-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/cargo-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clippy" release="1.u2" version="1.76.0">
					<filename>clippy-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/clippy-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust-std-static" release="1.u2" version="1.76.0">
					<filename>rust-std-static-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/rust-std-static-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rust" release="1.u2" version="1.76.0">
					<filename>rust-1.76.0-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/rust-1.76.0-1.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2268</id>
		<title>An update for linux-firmware is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56161" id="CVE-2024-56161" title="CVE-2024-56161" type="cve"></reference>
		</references>
		<description>CVE-2024-56161:Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="linux-firmware-mrvl" release="1.u7" version="20250808">
					<filename>linux-firmware-mrvl-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-mrvl-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-ti-connectivity" release="1.u7" version="20250808">
					<filename>linux-firmware-ti-connectivity-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-ti-connectivity-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-cypress" release="1.u7" version="20250808">
					<filename>linux-firmware-cypress-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-cypress-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware" release="1.u7" version="20250808">
					<filename>linux-firmware-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-ath" release="1.u7" version="20250808">
					<filename>linux-firmware-ath-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-ath-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-iwlwifi" release="1.u7" version="20250808">
					<filename>linux-firmware-iwlwifi-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-iwlwifi-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-libertas" release="1.u7" version="20250808">
					<filename>linux-firmware-libertas-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-libertas-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-mediatek" release="1.u7" version="20250808">
					<filename>linux-firmware-mediatek-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-mediatek-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="linux-firmware-netronome" release="1.u7" version="20250808">
					<filename>linux-firmware-netronome-20250808-1.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/linux-firmware-netronome-20250808-1.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2269</id>
		<title>An update for libxslt is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7424&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7424" id="CVE-2025-7424" title="CVE-2025-7424" type="cve"></reference>
		</references>
		<description>CVE-2025-7424:A flaw was found in the libxslt library. The same memory field, psvi, is used for both stylesheet and input data, which can lead to type confusion during XML transformations. This vulnerability allows an attacker to crash the application or corrupt memory. In some cases, it may lead to denial of service or unexpected behavior.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="libxslt-help" release="4.u3" version="1.1.37">
					<filename>libxslt-help-1.1.37-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libxslt-help-1.1.37-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt" release="4.u3" version="1.1.37">
					<filename>libxslt-1.1.37-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libxslt-1.1.37-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxslt" release="4.u3" version="1.1.37">
					<filename>python3-libxslt-1.1.37-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/python3-libxslt-1.1.37-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt-devel" release="4.u3" version="1.1.37">
					<filename>libxslt-devel-1.1.37-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libxslt-devel-1.1.37-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxslt" release="4.u3" version="1.1.37">
					<filename>python3-libxslt-1.1.37-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/python3-libxslt-1.1.37-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt" release="4.u3" version="1.1.37">
					<filename>libxslt-1.1.37-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libxslt-1.1.37-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt-devel" release="4.u3" version="1.1.37">
					<filename>libxslt-devel-1.1.37-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libxslt-devel-1.1.37-4.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2270</id>
		<title>An update for hive is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29869&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29869" id="CVE-2024-29869" title="CVE-2024-29869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23953&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23953" id="CVE-2024-23953" title="CVE-2024-23953" type="cve"></reference>
		</references>
		<description>CVE-2024-29869:Hive creates a credentials file to a temporary directory in the file system with permissions 644 by default when the file permissions are not set explicitly. Any unauthorized user having access to the directory can read the sensitive information written into this file. Users are recommended to upgrade to version 4.0.1, which fixes this issue.&#xA;CVE-2024-23953:Use of Arrays.equals() in LlapSignerImpl in Apache Hive to compare message signatures allows attacker to forge a valid signature for an arbitrary message byte by byte. The attacker should be an authorized user of the product to perform this attack. Users are recommended to upgrade to version 4.0.0, which fixes this issue.&#xA;&#xA;The problem occurs when an application doesn’t use a constant-time algorithm for validating a signature. The method Arrays.equals() returns false right away when it sees that one of the input’s bytes are different. It means that the comparison time depends on the contents of the arrays. This little thing may allow an attacker to forge a valid signature for an arbitrary message byte by byte. So it might allow malicious users to submit splits/work with selected signatures to LLAP without running as a privileged user, potentially leading to DDoS attack.&#xA;&#xA;More details in the reference section.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="hive" release="2.u2" version="3.1.3">
					<filename>hive-3.1.3-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/hive-3.1.3-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2271</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0745&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0745" id="CVE-2024-0745" title="CVE-2024-0745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36315&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-36315" id="CVE-2022-36315" title="CVE-2022-36315" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36316&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-36316" id="CVE-2022-36316" title="CVE-2022-36316" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38475&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-38475" id="CVE-2022-38475" title="CVE-2022-38475" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45419" id="CVE-2022-45419" title="CVE-2022-45419" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45407&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45407" id="CVE-2022-45407" title="CVE-2022-45407" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45417&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45417" id="CVE-2022-45417" title="CVE-2022-45417" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45415&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45415" id="CVE-2022-45415" title="CVE-2022-45415" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46879&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-46879" id="CVE-2022-46879" title="CVE-2022-46879" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46885&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-46885" id="CVE-2022-46885" title="CVE-2022-46885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46883&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-46883" id="CVE-2022-46883" title="CVE-2022-46883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46873&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-46873" id="CVE-2022-46873" title="CVE-2022-46873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25733&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-25733" id="CVE-2023-25733" title="CVE-2023-25733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25731&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-25731" id="CVE-2023-25731" title="CVE-2023-25731" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25736&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-25736" id="CVE-2023-25736" title="CVE-2023-25736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-28160" id="CVE-2023-28160" title="CVE-2023-28160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-28161" id="CVE-2023-28161" title="CVE-2023-28161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-28177" id="CVE-2023-28177" title="CVE-2023-28177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25750&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-25750" id="CVE-2023-25750" title="CVE-2023-25750" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29549&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29549" id="CVE-2023-29549" title="CVE-2023-29549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29538&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29538" id="CVE-2023-29538" title="CVE-2023-29538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29543&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29543" id="CVE-2023-29543" title="CVE-2023-29543" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29547&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29547" id="CVE-2023-29547" title="CVE-2023-29547" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29551&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29551" id="CVE-2023-29551" title="CVE-2023-29551" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29540&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29540" id="CVE-2023-29540" title="CVE-2023-29540" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29537&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29537" id="CVE-2023-29537" title="CVE-2023-29537" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32216&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32216" id="CVE-2023-32216" title="CVE-2023-32216" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32208&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32208" id="CVE-2023-32208" title="CVE-2023-32208" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32209&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32209" id="CVE-2023-32209" title="CVE-2023-32209" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34417&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-34417" id="CVE-2023-34417" title="CVE-2023-34417" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34415&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-34415" id="CVE-2023-34415" title="CVE-2023-34415" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32210&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32210" id="CVE-2023-32210" title="CVE-2023-32210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37206&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37206" id="CVE-2023-37206" title="CVE-2023-37206" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37203&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37203" id="CVE-2023-37203" title="CVE-2023-37203" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37205&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37205" id="CVE-2023-37205" title="CVE-2023-37205" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37204" id="CVE-2023-37204" title="CVE-2023-37204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37210&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37210" id="CVE-2023-37210" title="CVE-2023-37210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3482&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-3482" id="CVE-2023-3482" title="CVE-2023-3482" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37212" id="CVE-2023-37212" title="CVE-2023-37212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37209&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37209" id="CVE-2023-37209" title="CVE-2023-37209" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3600&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-3600" id="CVE-2023-3600" title="CVE-2023-3600" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4058" id="CVE-2023-4058" title="CVE-2023-4058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4051&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4051" id="CVE-2023-4051" title="CVE-2023-4051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4053&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4053" id="CVE-2023-4053" title="CVE-2023-4053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4577&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4577" id="CVE-2023-4577" title="CVE-2023-4577" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4585&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4585" id="CVE-2023-4585" title="CVE-2023-4585" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4579&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4579" id="CVE-2023-4579" title="CVE-2023-4579" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4583&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4583" id="CVE-2023-4583" title="CVE-2023-4583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4582&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4582" id="CVE-2023-4582" title="CVE-2023-4582" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4580&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4580" id="CVE-2023-4580" title="CVE-2023-4580" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4578&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-4578" id="CVE-2023-4578" title="CVE-2023-4578" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5169&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5169" id="CVE-2023-5169" title="CVE-2023-5169" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5175&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5175" id="CVE-2023-5175" title="CVE-2023-5175" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5172&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5172" id="CVE-2023-5172" title="CVE-2023-5172" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5170&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5170" id="CVE-2023-5170" title="CVE-2023-5170" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5176" id="CVE-2023-5176" title="CVE-2023-5176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5173&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5173" id="CVE-2023-5173" title="CVE-2023-5173" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5171" id="CVE-2023-5171" title="CVE-2023-5171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5732&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5732" id="CVE-2023-5732" title="CVE-2023-5732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5731&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5731" id="CVE-2023-5731" title="CVE-2023-5731" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5725&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5725" id="CVE-2023-5725" title="CVE-2023-5725" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5730&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5730" id="CVE-2023-5730" title="CVE-2023-5730" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5723" id="CVE-2023-5723" title="CVE-2023-5723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5721&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5721" id="CVE-2023-5721" title="CVE-2023-5721" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5724" id="CVE-2023-5724" title="CVE-2023-5724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5722&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5722" id="CVE-2023-5722" title="CVE-2023-5722" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5728" id="CVE-2023-5728" title="CVE-2023-5728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5729" id="CVE-2023-5729" title="CVE-2023-5729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6206&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6206" id="CVE-2023-6206" title="CVE-2023-6206" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6210&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6210" id="CVE-2023-6210" title="CVE-2023-6210" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6207&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6207" id="CVE-2023-6207" title="CVE-2023-6207" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6211&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6211" id="CVE-2023-6211" title="CVE-2023-6211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6209&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6209" id="CVE-2023-6209" title="CVE-2023-6209" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6213&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6213" id="CVE-2023-6213" title="CVE-2023-6213" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6204" id="CVE-2023-6204" title="CVE-2023-6204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6212" id="CVE-2023-6212" title="CVE-2023-6212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6205&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6205" id="CVE-2023-6205" title="CVE-2023-6205" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6208&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6208" id="CVE-2023-6208" title="CVE-2023-6208" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6856" id="CVE-2023-6856" title="CVE-2023-6856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6871&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6871" id="CVE-2023-6871" title="CVE-2023-6871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6869&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6869" id="CVE-2023-6869" title="CVE-2023-6869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6859" id="CVE-2023-6859" title="CVE-2023-6859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6873&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6873" id="CVE-2023-6873" title="CVE-2023-6873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6857" id="CVE-2023-6857" title="CVE-2023-6857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6872&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6872" id="CVE-2023-6872" title="CVE-2023-6872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6860&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6860" id="CVE-2023-6860" title="CVE-2023-6860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6867&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6867" id="CVE-2023-6867" title="CVE-2023-6867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6866&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6866" id="CVE-2023-6866" title="CVE-2023-6866" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6858" id="CVE-2023-6858" title="CVE-2023-6858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6865&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6865" id="CVE-2023-6865" title="CVE-2023-6865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6863&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6863" id="CVE-2023-6863" title="CVE-2023-6863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6861&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6861" id="CVE-2023-6861" title="CVE-2023-6861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6864&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6864" id="CVE-2023-6864" title="CVE-2023-6864" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6135&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6135" id="CVE-2023-6135" title="CVE-2023-6135" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6879&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6879" id="CVE-2023-6879" title="CVE-2023-6879" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0742&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0742" id="CVE-2024-0742" title="CVE-2024-0742" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0741&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0741" id="CVE-2024-0741" title="CVE-2024-0741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0747&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0747" id="CVE-2024-0747" title="CVE-2024-0747" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0743&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0743" id="CVE-2024-0743" title="CVE-2024-0743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0751&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0751" id="CVE-2024-0751" title="CVE-2024-0751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0748&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0748" id="CVE-2024-0748" title="CVE-2024-0748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0744&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0744" id="CVE-2024-0744" title="CVE-2024-0744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0749&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0749" id="CVE-2024-0749" title="CVE-2024-0749" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0754&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0754" id="CVE-2024-0754" title="CVE-2024-0754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0753&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0753" id="CVE-2024-0753" title="CVE-2024-0753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0755&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0755" id="CVE-2024-0755" title="CVE-2024-0755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1549&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1549" id="CVE-2024-1549" title="CVE-2024-1549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1547&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1547" id="CVE-2024-1547" title="CVE-2024-1547" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1553&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1553" id="CVE-2024-1553" title="CVE-2024-1553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1551&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1551" id="CVE-2024-1551" title="CVE-2024-1551" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1557&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1557" id="CVE-2024-1557" title="CVE-2024-1557" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1548&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1548" id="CVE-2024-1548" title="CVE-2024-1548" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1550&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1550" id="CVE-2024-1550" title="CVE-2024-1550" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1554&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1554" id="CVE-2024-1554" title="CVE-2024-1554" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1556&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1556" id="CVE-2024-1556" title="CVE-2024-1556" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1555&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-1555" id="CVE-2024-1555" title="CVE-2024-1555" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2613&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2613" id="CVE-2024-2613" title="CVE-2024-2613" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2615" id="CVE-2024-2615" title="CVE-2024-2615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2609&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2609" id="CVE-2024-2609" title="CVE-2024-2609" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2607&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2607" id="CVE-2024-2607" title="CVE-2024-2607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2611" id="CVE-2024-2611" title="CVE-2024-2611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2606&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2606" id="CVE-2024-2606" title="CVE-2024-2606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2616&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2616" id="CVE-2024-2616" title="CVE-2024-2616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2608&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2608" id="CVE-2024-2608" title="CVE-2024-2608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2610&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2610" id="CVE-2024-2610" title="CVE-2024-2610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2612&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2612" id="CVE-2024-2612" title="CVE-2024-2612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2614&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-2614" id="CVE-2024-2614" title="CVE-2024-2614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5388&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5388" id="CVE-2023-5388" title="CVE-2023-5388" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29944&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29944" id="CVE-2024-29944" title="CVE-2024-29944" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29943&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-29943" id="CVE-2024-29943" title="CVE-2024-29943" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6862&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-6862" id="CVE-2023-6862" title="CVE-2023-6862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3302&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3302" id="CVE-2024-3302" title="CVE-2024-3302" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3862&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3862" id="CVE-2024-3862" title="CVE-2024-3862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3857" id="CVE-2024-3857" title="CVE-2024-3857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3858" id="CVE-2024-3858" title="CVE-2024-3858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3865&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3865" id="CVE-2024-3865" title="CVE-2024-3865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3855&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3855" id="CVE-2024-3855" title="CVE-2024-3855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3853&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3853" id="CVE-2024-3853" title="CVE-2024-3853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3856" id="CVE-2024-3856" title="CVE-2024-3856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3861&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3861" id="CVE-2024-3861" title="CVE-2024-3861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3859" id="CVE-2024-3859" title="CVE-2024-3859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3864&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3864" id="CVE-2024-3864" title="CVE-2024-3864" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3852&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3852" id="CVE-2024-3852" title="CVE-2024-3852" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3854&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3854" id="CVE-2024-3854" title="CVE-2024-3854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3860&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3860" id="CVE-2024-3860" title="CVE-2024-3860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4778" id="CVE-2024-4778" title="CVE-2024-4778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4774&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4774" id="CVE-2024-4774" title="CVE-2024-4774" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4764&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4764" id="CVE-2024-4764" title="CVE-2024-4764" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4776&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4776" id="CVE-2024-4776" title="CVE-2024-4776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4772&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4772" id="CVE-2024-4772" title="CVE-2024-4772" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4367&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4367" id="CVE-2024-4367" title="CVE-2024-4367" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4770&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4770" id="CVE-2024-4770" title="CVE-2024-4770" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4771&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4771" id="CVE-2024-4771" title="CVE-2024-4771" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4773&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4773" id="CVE-2024-4773" title="CVE-2024-4773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4775&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4775" id="CVE-2024-4775" title="CVE-2024-4775" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4768&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4768" id="CVE-2024-4768" title="CVE-2024-4768" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4767&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4767" id="CVE-2024-4767" title="CVE-2024-4767" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4777&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4777" id="CVE-2024-4777" title="CVE-2024-4777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4769&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4769" id="CVE-2024-4769" title="CVE-2024-4769" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5690&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5690" id="CVE-2024-5690" title="CVE-2024-5690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5696&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5696" id="CVE-2024-5696" title="CVE-2024-5696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5691" id="CVE-2024-5691" title="CVE-2024-5691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5697" id="CVE-2024-5697" title="CVE-2024-5697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5694&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5694" id="CVE-2024-5694" title="CVE-2024-5694" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5702&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5702" id="CVE-2024-5702" title="CVE-2024-5702" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5695&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5695" id="CVE-2024-5695" title="CVE-2024-5695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5700&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5700" id="CVE-2024-5700" title="CVE-2024-5700" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5692" id="CVE-2024-5692" title="CVE-2024-5692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5689&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5689" id="CVE-2024-5689" title="CVE-2024-5689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5693&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5693" id="CVE-2024-5693" title="CVE-2024-5693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5701&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5701" id="CVE-2024-5701" title="CVE-2024-5701" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5698&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5698" id="CVE-2024-5698" title="CVE-2024-5698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5688&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5688" id="CVE-2024-5688" title="CVE-2024-5688" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5699" id="CVE-2024-5699" title="CVE-2024-5699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6603&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6603" id="CVE-2024-6603" title="CVE-2024-6603" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6605&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6605" id="CVE-2024-6605" title="CVE-2024-6605" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6608&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6608" id="CVE-2024-6608" title="CVE-2024-6608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6601" id="CVE-2024-6601" title="CVE-2024-6601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6615" id="CVE-2024-6615" title="CVE-2024-6615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6609&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6609" id="CVE-2024-6609" title="CVE-2024-6609" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6611" id="CVE-2024-6611" title="CVE-2024-6611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6607&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6607" id="CVE-2024-6607" title="CVE-2024-6607" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6604&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6604" id="CVE-2024-6604" title="CVE-2024-6604" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6606&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6606" id="CVE-2024-6606" title="CVE-2024-6606" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6610&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6610" id="CVE-2024-6610" title="CVE-2024-6610" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6612&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6612" id="CVE-2024-6612" title="CVE-2024-6612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6602&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6602" id="CVE-2024-6602" title="CVE-2024-6602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6613&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6613" id="CVE-2024-6613" title="CVE-2024-6613" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6614&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6614" id="CVE-2024-6614" title="CVE-2024-6614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7531&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7531" id="CVE-2024-7531" title="CVE-2024-7531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7521&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7521" id="CVE-2024-7521" title="CVE-2024-7521" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7525&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7525" id="CVE-2024-7525" title="CVE-2024-7525" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7526&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7526" id="CVE-2024-7526" title="CVE-2024-7526" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7529&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7529" id="CVE-2024-7529" title="CVE-2024-7529" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7524&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7524" id="CVE-2024-7524" title="CVE-2024-7524" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7519&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7519" id="CVE-2024-7519" title="CVE-2024-7519" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7522&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7522" id="CVE-2024-7522" title="CVE-2024-7522" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7527&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7527" id="CVE-2024-7527" title="CVE-2024-7527" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8382&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8382" id="CVE-2024-8382" title="CVE-2024-8382" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8384&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8384" id="CVE-2024-8384" title="CVE-2024-8384" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8383&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8383" id="CVE-2024-8383" title="CVE-2024-8383" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8381&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8381" id="CVE-2024-8381" title="CVE-2024-8381" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7652&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7652" id="CVE-2024-7652" title="CVE-2024-7652" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9400&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9400" id="CVE-2024-9400" title="CVE-2024-9400" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9401&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9401" id="CVE-2024-9401" title="CVE-2024-9401" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9399&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9399" id="CVE-2024-9399" title="CVE-2024-9399" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9402&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9402" id="CVE-2024-9402" title="CVE-2024-9402" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9392&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9392" id="CVE-2024-9392" title="CVE-2024-9392" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9397&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9397" id="CVE-2024-9397" title="CVE-2024-9397" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9396&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9396" id="CVE-2024-9396" title="CVE-2024-9396" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9393&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9393" id="CVE-2024-9393" title="CVE-2024-9393" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9394&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9394" id="CVE-2024-9394" title="CVE-2024-9394" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9398&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9398" id="CVE-2024-9398" title="CVE-2024-9398" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9680&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-9680" id="CVE-2024-9680" title="CVE-2024-9680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10464&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10464" id="CVE-2024-10464" title="CVE-2024-10464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10459&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10459" id="CVE-2024-10459" title="CVE-2024-10459" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10467&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10467" id="CVE-2024-10467" title="CVE-2024-10467" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10466&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10466" id="CVE-2024-10466" title="CVE-2024-10466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10462&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10462" id="CVE-2024-10462" title="CVE-2024-10462" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10458&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10458" id="CVE-2024-10458" title="CVE-2024-10458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10465&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10465" id="CVE-2024-10465" title="CVE-2024-10465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10463&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10463" id="CVE-2024-10463" title="CVE-2024-10463" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10460&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10460" id="CVE-2024-10460" title="CVE-2024-10460" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10461&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10461" id="CVE-2024-10461" title="CVE-2024-10461" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10941&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-10941" id="CVE-2024-10941" title="CVE-2024-10941" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11694&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11694" id="CVE-2024-11694" title="CVE-2024-11694" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11697" id="CVE-2024-11697" title="CVE-2024-11697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11692" id="CVE-2024-11692" title="CVE-2024-11692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11699" id="CVE-2024-11699" title="CVE-2024-11699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11696&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11696" id="CVE-2024-11696" title="CVE-2024-11696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11695&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11695" id="CVE-2024-11695" title="CVE-2024-11695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0237" id="CVE-2025-0237" title="CVE-2025-0237" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0242&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-0242" id="CVE-2025-0242" title="CVE-2025-0242" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1016&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1016" id="CVE-2025-1016" title="CVE-2025-1016" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1009&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1009" id="CVE-2025-1009" title="CVE-2025-1009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1017&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1017" id="CVE-2025-1017" title="CVE-2025-1017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1013&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1013" id="CVE-2025-1013" title="CVE-2025-1013" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1010&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1010" id="CVE-2025-1010" title="CVE-2025-1010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1014" id="CVE-2025-1014" title="CVE-2025-1014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1011&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1011" id="CVE-2025-1011" title="CVE-2025-1011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1012&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1012" id="CVE-2025-1012" title="CVE-2025-1012" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43097&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43097" id="CVE-2024-43097" title="CVE-2024-43097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1931&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1931" id="CVE-2025-1931" title="CVE-2025-1931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1932&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1932" id="CVE-2025-1932" title="CVE-2025-1932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1933&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1933" id="CVE-2025-1933" title="CVE-2025-1933" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1934&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1934" id="CVE-2025-1934" title="CVE-2025-1934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1935" id="CVE-2025-1935" title="CVE-2025-1935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1936&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1936" id="CVE-2025-1936" title="CVE-2025-1936" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1937&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1937" id="CVE-2025-1937" title="CVE-2025-1937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1938&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1938" id="CVE-2025-1938" title="CVE-2025-1938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3028&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3028" id="CVE-2025-3028" title="CVE-2025-3028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3029&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3029" id="CVE-2025-3029" title="CVE-2025-3029" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3030&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3030" id="CVE-2025-3030" title="CVE-2025-3030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2817" id="CVE-2025-2817" title="CVE-2025-2817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4083" id="CVE-2025-4083" title="CVE-2025-4083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4084" id="CVE-2025-4084" title="CVE-2025-4084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4087&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4087" id="CVE-2025-4087" title="CVE-2025-4087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4091&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4091" id="CVE-2025-4091" title="CVE-2025-4091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4093&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4093" id="CVE-2025-4093" title="CVE-2025-4093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4918&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4918" id="CVE-2025-4918" title="CVE-2025-4918" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4919&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4919" id="CVE-2025-4919" title="CVE-2025-4919" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5263&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5263" id="CVE-2025-5263" title="CVE-2025-5263" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5264&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5264" id="CVE-2025-5264" title="CVE-2025-5264" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5266&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5266" id="CVE-2025-5266" title="CVE-2025-5266" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5267&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5267" id="CVE-2025-5267" title="CVE-2025-5267" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5268&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5268" id="CVE-2025-5268" title="CVE-2025-5268" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5269&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5269" id="CVE-2025-5269" title="CVE-2025-5269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6424&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6424" id="CVE-2025-6424" title="CVE-2025-6424" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6425&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6425" id="CVE-2025-6425" title="CVE-2025-6425" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6429&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6429" id="CVE-2025-6429" title="CVE-2025-6429" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6430&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6430" id="CVE-2025-6430" title="CVE-2025-6430" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8027&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8027" id="CVE-2025-8027" title="CVE-2025-8027" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8028&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8028" id="CVE-2025-8028" title="CVE-2025-8028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8029&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8029" id="CVE-2025-8029" title="CVE-2025-8029" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8030&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8030" id="CVE-2025-8030" title="CVE-2025-8030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8031&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8031" id="CVE-2025-8031" title="CVE-2025-8031" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8032&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8032" id="CVE-2025-8032" title="CVE-2025-8032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8033&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8033" id="CVE-2025-8033" title="CVE-2025-8033" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8034" id="CVE-2025-8034" title="CVE-2025-8034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8035" id="CVE-2025-8035" title="CVE-2025-8035" type="cve"></reference>
		</references>
		<description>CVE-2024-0745:The WebAudio `OscillatorNode` object was susceptible to a stack buffer overflow. This could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 122.&#xA;CVE-2022-36315:When loading a script with Subresource Integrity, attackers with an injection capability could trigger the reuse of previously cached entries with incorrect, different integrity metadata. This vulnerability affects Firefox &lt; 103.&#xA;CVE-2022-36316:When using the Performance API, an attacker was able to notice subtle differences between PerformanceEntries and thus learn whether the target URL had been subject to a redirect. This vulnerability affects Firefox &lt; 103.&#xA;CVE-2022-38475:An attacker could have written a value to the first element in a zero-length JavaScript array. Although the array was zero-length, the value was not written to an invalid memory address. This vulnerability affects Firefox &lt; 104.&#xA;CVE-2022-45419:If the user added a security exception for an invalid TLS certificate, opened an ongoing TLS connection with a server that used that certificate, and then deleted the exception, Firefox would have kept the connection alive, making it seem like the certificate was still trusted. This vulnerability affects Firefox &lt; 107.&#xA;CVE-2022-45407:If an attacker loaded a font using &lt;code&gt;FontFace()&lt;/code&gt; on a background worker, a use-after-free could have occurred, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 107.&#xA;CVE-2022-45417:Service Workers did not detect Private Browsing Mode correctly in all cases, which could have led to Service Workers being written to disk for websites visited in Private Browsing Mode. This would not have persisted them in a state where they would run again, but it would have leaked Private Browsing Mode details to disk. This vulnerability affects Firefox &lt; 107.&#xA;CVE-2022-45415:When downloading an HTML file, if the title of the page was formatted as a filename with a malicious extension, Firefox may have saved the file with that extension, leading to possible system compromise if the downloaded file was later ran. This vulnerability affects Firefox &lt; 107.&#xA;CVE-2022-46879:Mozilla developers and community members Lukas Bernhard, Gabriele Svelto, Randell Jesup, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 107. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 108.&#xA;CVE-2022-46885:Mozilla developers Timothy Nikkel, Ashley Hale, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 105. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 106.&#xA;CVE-2022-46883:Mozilla developers Gabriele Svelto, Yulia Startsev, Andrew McCreight and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 106. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.&lt;br /&gt;*Note*: This advisory was added on December 13th, 2022 after discovering it was inadvertently left out of the original advisory. The fix was included in the original release of Firefox 107. This vulnerability affects Firefox &lt; 107.&#xA;CVE-2022-46873:Because Firefox did not implement the &lt;code&gt;unsafe-hashes&lt;/code&gt; CSP directive, an attacker who was able to inject markup into a page otherwise protected by a Content Security Policy may have been able to inject executable script. This would be severely constrained by the specified Content Security Policy of the document. This vulnerability affects Firefox &lt; 108.&#xA;CVE-2023-25733:The return value from `gfx::SourceSurfaceSkia::Map()` wasn&#39;t being verified which could have potentially lead to a null pointer dereference. This vulnerability affects Firefox &lt; 110.&#xA;CVE-2023-25731:Due to URL previews in the network panel of developer tools improperly storing URLs, query parameters could potentially be used to overwrite global objects in privileged code. This vulnerability affects Firefox &lt; 110.&#xA;CVE-2023-25736:An invalid downcast from `nsHTMLDocument` to `nsIContent` could have lead to undefined behavior. This vulnerability affects Firefox &lt; 110.&#xA;CVE-2023-28160:When following a redirect to a publicly accessible web extension file, the URL may have been translated to the actual local path, leaking potentially sensitive information. This vulnerability affects Firefox &lt; 111.&#xA;CVE-2023-28161:If temporary &#34;one-time&#34; permissions, such as the ability to use the Camera, were granted to a document loaded using a file: URL, that permission persisted in that tab for all other documents loaded from a file: URL. This is potentially dangerous if the local files came from different sources, such as in a download directory. This vulnerability affects Firefox &lt; 111.&#xA;CVE-2023-28177:Memory safety bugs present in Firefox 110. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 111.&#xA;CVE-2023-25750:Under certain circumstances, a ServiceWorker&#39;s offline cache may have leaked to the file system when using private browsing mode. This vulnerability affects Firefox &lt; 111.&#xA;CVE-2023-29549:Under certain circumstances, a call to the &lt;code&gt;bind&lt;/code&gt; function may have resulted in the incorrect realm. This may have created a vulnerability relating to JavaScript-implemented sandboxes such as SES. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-29538:Under specific circumstances a WebExtension may have received a &lt;code&gt;jar:file:///&lt;/code&gt; URI instead of a &lt;code&gt;moz-extension:///&lt;/code&gt; URI during a load request. This leaked directory paths on the user&#39;s machine. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-29543:An attacker could have caused memory corruption and a potentially exploitable use-after-free of a pointer in a global object&#39;s debugger vector. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-29547:When a secure cookie existed in the Firefox cookie jar an insecure cookie for the same domain could have been created, when it should have silently failed. This could have led to a desynchronization in expected results when reading from the secure cookie. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-29551:Memory safety bugs present in Firefox 111. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-29540:Using a redirect embedded into &lt;code&gt;sourceMappingUrls&lt;/code&gt; could allow for navigation to external protocol links in sandboxed iframes without &lt;code&gt;allow-top-navigation-to-custom-protocols&lt;/code&gt;. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-29537:Multiple race conditions in the font initialization could have led to memory corruption and execution of attacker-controlled code. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;CVE-2023-32216:Mozilla developers and community members Ronald Crane, Andrew McCreight, Randell Jesup and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 112. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 113.&#xA;CVE-2023-32208:Service workers could reveal script base URL due to dynamic `import()`. This vulnerability affects Firefox &lt; 113.&#xA;CVE-2023-32209:A maliciously crafted favicon could have led to an out of memory crash. This vulnerability affects Firefox &lt; 113.&#xA;CVE-2023-34417:Memory safety bugs present in Firefox 113. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 114.&#xA;CVE-2023-34415:When choosing a site-isolated process for a document loaded from a data: URL that was the result of a redirect, Firefox would load that document in the same process as the site that issued the redirect. This bypassed the site-isolation protections against Spectre-like attacks on sites that host an &#34;open redirect&#34;. Firefox no longer follows HTTP redirects to data: URLs. This vulnerability affects Firefox &lt; 114.&#xA;CVE-2023-32210:Documents were incorrectly assuming an ordering of principal objects when ensuring we were loading an appropriately privileged principal. In certain circumstances it might have been possible to cause a document to be loaded with a higher privileged principal than intended. This vulnerability affects Firefox &lt; 113.&#xA;CVE-2023-37206:Uploading files which contain symlinks may have allowed an attacker to trick a user into submitting sensitive data to a malicious website. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-37203:Insufficient validation in the Drag and Drop API in conjunction with social engineering, may have allowed an attacker to trick end-users into creating a shortcut to local system files.  This could have been leveraged to execute arbitrary code. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-37205:The use of RTL Arabic characters in the address bar may have allowed for URL spoofing. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-37204:A website could have obscured the fullscreen notification by using an option element by introducing lag via an expensive computational function. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-37210:A website could prevent a user from exiting full-screen mode via alert and prompt calls.  This could lead to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-3482:When Firefox is configured to block storage of all cookies, it was still possible to store data in localstorage by using an iframe with a source of &#39;about:blank&#39;. This could have led to malicious websites storing tracking data without permission. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-37212:Memory safety bugs present in Firefox 114. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-37209:A use-after-free condition existed in `NotifyOnHistoryReload` where a `LoadingSessionHistoryEntry` object was freed and a reference to that object remained.  This resulted in a potentially exploitable condition when the reference to that object was later reused. This vulnerability affects Firefox &lt; 115.&#xA;CVE-2023-3600:During the worker lifecycle, a use-after-free condition could have occured, which could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 115.0.2, Firefox ESR &lt; 115.0.2, and Thunderbird &lt; 115.0.1.&#xA;CVE-2023-4058:Memory safety bugs present in Firefox 115. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 116.&#xA;CVE-2023-4051:A website could have obscured the full screen notification by using the file open dialog. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4053:A website could have obscured the full screen notification by using a URL with a scheme handled by an external program, such as a mailto URL. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4577:When `UpdateRegExpStatics` attempted to access `initialStringHeap` it could already have been garbage collected prior to entering the function, which could potentially have led to an exploitable crash. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4585:Memory safety bugs present in Firefox 116, Firefox ESR 115.1, and Thunderbird 115.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4579:Search queries in the default search engine could appear to have been the currently navigated URL if the search query itself was a well formed URL. This could have led to a site spoofing another if it had been maliciously set as the default search engine. This vulnerability affects Firefox &lt; 117.&#xA;CVE-2023-4583:When checking if the Browsing Context had been discarded in `HttpBaseChannel`, if the load group was not available then it was assumed to have already been discarded which was not always the case for private channels after the private session had ended. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4582:Due to large allocation checks in Angle for glsl shaders being too lenient a buffer overflow could have occured when allocating too much private shader memory on mac OS. &#xA;*This bug only affects Firefox on macOS. Other operating systems are unaffected.* This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4580:Push notifications stored on disk in private browsing mode were not being encrypted potentially allowing the leak of sensitive information. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-4578:When calling `JS::CheckRegExpSyntax` a Syntax Error could have been set which would end in calling `convertToRuntimeErrorAndClear`. A path in the function could attempt to allocate memory when none is available which would have caused a newly created Out of Memory exception to be mishandled as a Syntax Error. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.&#xA;CVE-2023-5169:A compromised content process could have provided malicious data in a `PathRecording` resulting in an out-of-bounds write, leading to a potentially exploitable crash in a privileged process. This vulnerability affects Firefox &lt; 118, Firefox ESR &lt; 115.3, and Thunderbird &lt; 115.3.&#xA;CVE-2023-5175:During process shutdown, it was possible that an `ImageBitmap` was created that would later be used after being freed from a different codepath, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 118.&#xA;CVE-2023-5172:A hashtable  in the Ion Engine could have been mutated while there was a live interior reference, leading to a potential use-after-free and exploitable crash. This vulnerability affects Firefox &lt; 118.&#xA;CVE-2023-5170:In canvas rendering, a compromised content process could have caused a surface to change unexpectedly, leading to a memory leak of a privileged process. This memory leak could be used to effect a sandbox escape if the correct data was leaked. This vulnerability affects Firefox &lt; 118.&#xA;CVE-2023-5176:Memory safety bugs present in Firefox 117, Firefox ESR 115.2, and Thunderbird 115.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 118, Firefox ESR &lt; 115.3, and Thunderbird &lt; 115.3.&#xA;CVE-2023-5173:In a non-standard configuration of Firefox, an integer overflow could have occurred based on network traffic (possibly under influence of a local unprivileged webpage), leading to an out-of-bounds write to privileged process memory. &#xA;*This bug only affects Firefox if a non-standard preference allowing non-HTTPS Alternate Services (`network.http.altsvc.oe`) is enabled.* This vulnerability affects Firefox &lt; 118.&#xA;CVE-2023-5171:During Ion compilation, a Garbage Collection could have resulted in a use-after-free condition, allowing an attacker to write two NUL bytes, and cause a potentially exploitable crash. This vulnerability affects Firefox &lt; 118, Firefox ESR &lt; 115.3, and Thunderbird &lt; 115.3.&#xA;CVE-2023-5732:An attacker could have created a malicious link using bidirectional characters to spoof the location in the address bar when visited. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.&#xA;CVE-2023-5731:Memory safety bugs present in Firefox 118. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 119.&#xA;CVE-2023-5725:A malicious installed WebExtension could open arbitrary URLs, which under the right circumstance could be leveraged to collect sensitive user data. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.&#xA;CVE-2023-5730:Memory safety bugs present in Firefox 118, Firefox ESR 115.3, and Thunderbird 115.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.&#xA;CVE-2023-5723:An attacker with temporary script access to a site could have set a cookie containing invalid characters using `document.cookie` that could have led to unknown errors. This vulnerability affects Firefox &lt; 119.&#xA;CVE-2023-5721:It was possible for certain browser prompts and dialogs to be activated or dismissed unintentionally by the user due to an insufficient activation-delay. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.&#xA;CVE-2023-5724:Drivers are not always robust to extremely large draw calls and in some cases this scenario could have led to a crash. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.&#xA;CVE-2023-5722:Using iterative requests an attacker was able to learn the size of an opaque response, as well as the contents of a server-supplied Vary header. This vulnerability affects Firefox &lt; 119.&#xA;CVE-2023-5728:During garbage collection extra operations were performed on a object that should not be. This could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.&#xA;CVE-2023-5729:A malicious web site can enter fullscreen mode while simultaneously triggering a WebAuthn prompt. This could have obscured the fullscreen notification and could have been leveraged in a spoofing attack. This vulnerability affects Firefox &lt; 119.&#xA;CVE-2023-6206:The black fade animation when exiting fullscreen is roughly the length of the anti-clickjacking delay on permission prompts. It was possible to use this fact to surprise users by luring them to click where the permission grant button would be about to appear. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6210:When an https: web page created a pop-up from a &#34;javascript:&#34; URL, that pop-up was incorrectly allowed to load blockable content such as iframes from insecure http: URLs This vulnerability affects Firefox &lt; 120.&#xA;CVE-2023-6207:Ownership mismanagement led to a use-after-free in ReadableByteStreams This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6211:If an attacker needed a user to load an insecure http: page and knew that user had enabled HTTPS-only mode, the attacker could have tricked the user into clicking to grant an HTTPS-only exception if they could get the user to participate in a clicking game. This vulnerability affects Firefox &lt; 120.&#xA;CVE-2023-6209:Relative URLs starting with three slashes were incorrectly parsed, and a path-traversal &#34;/../&#34; part in the path could be used to override the specified host. This could contribute to security problems in web sites. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6213:Memory safety bugs present in Firefox 119. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 120.&#xA;CVE-2023-6204:On some systems—depending on the graphics settings and drivers—it was possible to force an out-of-bounds read and leak memory data into the images created on the canvas element. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6212:Memory safety bugs present in Firefox 119, Firefox ESR 115.4, and Thunderbird 115.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6205:It was possible to cause the use of a MessagePort after it had already been freed, which could potentially have led to an exploitable crash. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6208:When using X11, text selected by the page using the Selection API was erroneously copied into the primary selection, a temporary storage not unlike the clipboard.&#xA;*This bug only affects Firefox on X11. Other systems are unaffected.* This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.&#xA;CVE-2023-6856:The WebGL `DrawElementsInstanced` method was susceptible to a heap buffer overflow when used on systems with the Mesa VM driver.  This issue could allow an attacker to perform remote code execution and sandbox escape. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6871:Under certain conditions, Firefox did not display a warning when a user attempted to navigate to a new protocol handler. This vulnerability affects Firefox &lt; 121.&#xA;CVE-2023-6869:A `&amp;lt;dialog&gt;` element could have been manipulated to paint content outside of a sandboxed iframe. This could allow untrusted content to display under the guise of trusted content. This vulnerability affects Firefox &lt; 121.&#xA;CVE-2023-6859:A use-after-free condition affected TLS socket creation when under memory pressure. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6873:Memory safety bugs present in Firefox 120. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 121.&#xA;CVE-2023-6857:When resolving a symlink, a race may occur where the buffer passed to `readlink` may actually be smaller than necessary. &#xA;*This bug only affects Firefox on Unix-based operating systems (Android, Linux, MacOS). Windows is unaffected.* This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6872:Browser tab titles were being leaked by GNOME to system logs. This could potentially expose the browsing habits of users running in a private tab. This vulnerability affects Firefox &lt; 121.&#xA;CVE-2023-6860:The `VideoBridge` allowed any content process to use textures produced by remote decoders.  This could be abused to escape the sandbox. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6867:The timing of a button click causing a popup to disappear was approximately the same length as the anti-clickjacking delay on permission prompts. It was possible to use this fact to surprise users by luring them to click where the permission grant button would be about to appear. This vulnerability affects Firefox ESR &lt; 115.6 and Firefox &lt; 121.&#xA;CVE-2023-6866:TypedArrays can be fallible and lacked proper exception handling. This could lead to abuse in other APIs which expect TypedArrays to always succeed. This vulnerability affects Firefox &lt; 121.&#xA;CVE-2023-6858:Firefox was susceptible to a heap buffer overflow in `nsTextFragment` due to insufficient OOM handling. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6865:`EncryptingOutputStream` was susceptible to exposing uninitialized data.  This issue could only be abused in order to write data to a local disk which may have implications for private browsing mode. This vulnerability affects Firefox ESR &lt; 115.6 and Firefox &lt; 121.&#xA;CVE-2023-6863:The `ShutdownObserver()` was susceptible to potentially undefined behavior due to its reliance on a dynamic type that lacked a virtual destructor. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6861:The `nsWindow::PickerOpen(void)` method was susceptible to a heap buffer overflow when running in headless mode. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6864:Memory safety bugs present in Firefox 120, Firefox ESR 115.5, and Thunderbird 115.5. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.&#xA;CVE-2023-6135:Multiple NSS NIST curves were susceptible to a side-channel attack known as &#34;Minerva&#34;. This attack could potentially allow an attacker to recover the private key. This vulnerability affects Firefox &lt; 121.&#xA;CVE-2023-6879:Increasing the resolution of video frames, while performing a multi-threaded encode, can result in a heap overflow in av1_loop_restoration_dealloc().&#xA;CVE-2024-0742:It was possible for certain browser prompts and dialogs to be activated or dismissed unintentionally by the user due to an incorrect timestamp used to prevent input after page load. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.&#xA;CVE-2024-0741:An out of bounds write in ANGLE could have allowed an attacker to corrupt memory leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.&#xA;CVE-2024-0747:When a parent page loaded a child in an iframe with `unsafe-inline`, the parent Content Security Policy could have overridden the child Content Security Policy. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.&#xA;CVE-2024-0743:An unchecked return value in TLS handshake code could have caused a potentially exploitable crash. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-0751:A malicious devtools extension could have been used to escalate privileges. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.&#xA;CVE-2024-0748:A compromised content process could have updated the document URI. This could have allowed an attacker to set an arbitrary URI in the address bar or history. This vulnerability affects Firefox &lt; 122.&#xA;CVE-2024-0744:In some circumstances, JIT compiled code could have dereferenced a wild pointer value. This could have led to an exploitable crash. This vulnerability affects Firefox &lt; 122.&#xA;CVE-2024-0749:A phishing site could have repurposed an `about:` dialog to show phishing content with an incorrect origin in the address bar. This vulnerability affects Firefox &lt; 122 and Thunderbird &lt; 115.7.&#xA;CVE-2024-0754:Some WASM source files could have caused a crash when loaded in devtools. This vulnerability affects Firefox &lt; 122.&#xA;CVE-2024-0753:In specific HSTS configurations an attacker could have bypassed HSTS on a subdomain. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.&#xA;CVE-2024-0755:Memory safety bugs present in Firefox 121, Firefox ESR 115.6, and Thunderbird 115.6. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.&#xA;CVE-2024-1549:If a website set a large custom cursor, portions of the cursor could have overlapped with the permission dialog, potentially resulting in user confusion and unexpected granted permissions. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.&#xA;CVE-2024-1547:Through a series of API calls and redirects, an attacker-controlled alert dialog could have been displayed on another website (with the victim website&#39;s URL shown). This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.&#xA;CVE-2024-1553:Memory safety bugs present in Firefox 122, Firefox ESR 115.7, and Thunderbird 115.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.&#xA;CVE-2024-1551:Set-Cookie response headers were being incorrectly honored in multipart HTTP responses. If an attacker could control the Content-Type response header, as well as control part of the response body, they could inject Set-Cookie response headers that would have been honored by the browser. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.&#xA;CVE-2024-1557:Memory safety bugs present in Firefox 122. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 123.&#xA;CVE-2024-1548:A website could have obscured the fullscreen notification by using a dropdown select input element. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.&#xA;CVE-2024-1550:A malicious website could have used a combination of exiting fullscreen mode and `requestPointerLock` to cause the user&#39;s mouse to be re-positioned unexpectedly, which could have led to user confusion and inadvertently granting permissions they did not intend to grant. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.&#xA;CVE-2024-1554:The `fetch()` API and navigation incorrectly shared the same cache, as the cache key did not include the optional headers `fetch()` may contain.  Under the correct circumstances, an attacker may have been able to poison the local browser cache by priming it with a `fetch()` response controlled by the additional headers. Upon navigation to the same URL, the user would see the cached response instead of the expected response. This vulnerability affects Firefox &lt; 123.&#xA;CVE-2024-1556:The incorrect object was checked for NULL in the built-in profiler, potentially leading to invalid memory access and undefined behavior. *Note:* This issue only affects the application when the profiler is running. This vulnerability affects Firefox &lt; 123.&#xA;CVE-2024-1555:When opening a website using the `firefox://` protocol handler, SameSite cookies were not properly respected. This vulnerability affects Firefox &lt; 123.&#xA;CVE-2024-2613:Data was not properly sanitized when decoding a QUIC ACK frame; this could have led to unrestricted memory consumption and a crash. This vulnerability affects Firefox &lt; 124.&#xA;CVE-2024-2615:Memory safety bugs present in Firefox 123. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 124.&#xA;CVE-2024-2609:The permission prompt input delay could expire while the window is not in focus. This makes it vulnerable to clickjacking by malicious websites. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-2607:Return registers were overwritten which could have allowed an attacker to execute arbitrary code. *Note:* This issue only affected Armv7-A systems. Other operating systems are unaffected. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-2611:A missing delay on when pointer lock was used could have allowed a malicious page to trick a user into granting permissions. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-2606:Passing invalid data could have led to invalid wasm values being created, such as arbitrary integers turning into pointer values. This vulnerability affects Firefox &lt; 124.&#xA;CVE-2024-2616:To harden ICU against exploitation, the behavior for out-of-memory conditions was changed to crash instead of attempt to continue. This vulnerability affects Firefox ESR &lt; 115.9 and Thunderbird &lt; 115.9.&#xA;CVE-2024-2608:`AppendEncodedAttributeValue(), ExtraSpaceNeededForAttrEncoding()` and `AppendEncodedCharacters()` could have experienced integer overflows, causing underallocation of an output buffer leading to an out of bounds write. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-2610:Using a markup injection an attacker could have stolen nonce values. This could have been used to bypass strict content security policies. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-2612:If an attacker could find a way to trigger a particular code path in `SafeRefPtr`, it could have triggered a crash or potentially be leveraged to achieve code execution. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-2614:Memory safety bugs present in Firefox 123, Firefox ESR 115.8, and Thunderbird 115.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2023-5388:NSS was susceptible to a timing side-channel attack when performing RSA decryption. This attack could potentially allow an attacker to recover the private data. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.&#xA;CVE-2024-29944:An attacker was able to inject an event handler into a privileged object that would allow arbitrary JavaScript execution in the parent process. Note: This vulnerability affects Desktop Firefox only, it does not affect mobile versions of Firefox. This vulnerability affects Firefox &lt; 124.0.1 and Firefox ESR &lt; 115.9.1.&#xA;CVE-2024-29943:An attacker was able to perform an out-of-bounds read or write on a JavaScript object by fooling range-based bounds check elimination. This vulnerability affects Firefox &lt; 124.0.1.&#xA;CVE-2023-6862:A use-after-free was identified in the `nsDNSService::Init`.  This issue appears to manifest rarely during start-up. This vulnerability affects Firefox ESR &lt; 115.6 and Thunderbird &lt; 115.6.&#xA;CVE-2024-3302:There was no limit to the number of HTTP/2 CONTINUATION frames that would be processed. A server could abuse this to create an Out of Memory condition in the browser. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3862:The MarkStack assignment operator, part of the JavaScript engine, could access uninitialized memory if it were used in a self-assignment. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-3857:The JIT created incorrect code for arguments in certain cases. This led to potential use-after-free crashes during garbage collection. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3858:It was possible to mutate a JavaScript object so that the JIT could crash while tracing it. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-3865:Memory safety bugs present in Firefox 124. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-3855:In certain cases the JIT incorrectly optimized MSubstr operations, which led to out-of-bounds reads. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-3853:A use-after-free could result if a JavaScript realm was in the process of being initialized when a garbage collection started. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-3856:A use-after-free could occur during WASM execution if garbage collection ran during the creation of an array. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-3861:If an AlignedBuffer were assigned to itself, the subsequent self-move could result in an incorrect reference count and later use-after-free. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3859:On 32-bit versions there were integer-overflows that led to an out-of-bounds-read that potentially could be triggered by a malformed OpenType font. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3864:Memory safety bug present in Firefox 124, Firefox ESR 115.9, and Thunderbird 115.9. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3852:GetBoundName could return the wrong version of an object when JIT optimizations were applied. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3854:In some code patterns the JIT incorrectly optimized switch statements and generated code with out-of-bounds-reads. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.&#xA;CVE-2024-3860:An out-of-memory condition during object initialization could result in an empty shape list. If the JIT subsequently traced the object it would crash. This vulnerability affects Firefox &lt; 125.&#xA;CVE-2024-4778:Memory safety bugs present in Firefox 125. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4774:The `ShmemCharMapHashEntry()` code was susceptible to potentially undefined behavior by bypassing the move semantics for one of its data members. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4764:Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4776:A file dialog shown while in full-screen mode could have resulted in the window remaining disabled. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4772:An HTTP digest authentication nonce value was generated using `rand()` which could lead to predictable values. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4367:A type check was missing when handling fonts in PDF.js, which would allow arbitrary JavaScript execution in the PDF.js context. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.&#xA;CVE-2024-4770:When saving a page to PDF, certain font styles could have led to a potential use-after-free crash. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.&#xA;CVE-2024-4771:A memory allocation check was missing which would lead to a use-after-free if the allocation failed. This could have triggered a crash or potentially be leveraged to achieve code execution. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4773:When a network error occurred during page load, the prior content could have remained in view with a blank URL bar. This could have been used to obfuscate a spoofed web site. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4775:An iterator stop condition was missing when handling WASM code in the built-in profiler, potentially leading to invalid memory access and undefined behavior. *Note:* This issue only affects the application when the profiler is running. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-4768:A bug in popup notifications&#39; interaction with WebAuthn made it easier for an attacker to trick a user into granting permissions. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.&#xA;CVE-2024-4767:If the `browser.privatebrowsing.autostart` preference is enabled, IndexedDB files were not properly deleted when the window was closed. This preference is disabled by default in Firefox. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.&#xA;CVE-2024-4777:Memory safety bugs present in Firefox 125, Firefox ESR 115.10, and Thunderbird 115.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.&#xA;CVE-2024-4769:When importing resources using Web Workers, error messages would distinguish the difference between `application/javascript` responses and non-script responses.  This could have been abused to learn information cross-origin. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.&#xA;CVE-2024-5690:By monitoring the time certain operations take, an attacker could have guessed which external protocol handlers were functional on a user&#39;s system. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5696:By manipulating the text in an `&amp;lt;input&amp;gt;` tag, an attacker could have caused corrupt memory leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5691:By tricking the browser with a `X-Frame-Options` header, a sandboxed iframe could have presented a button that, if clicked by a user, would bypass restrictions to open a new window. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5697:A website was able to detect when a user took a screenshot of a page using the built-in Screenshot functionality in Firefox. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-5694:An attacker could have caused a use-after-free in the JavaScript engine to read memory in the JavaScript string section of the heap. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-5702:Memory corruption in the networking stack could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5695:If an out-of-memory condition occurs at a specific point using allocations in the probabilistic heap checker, an assertion could have been triggered, and in rarer situations, memory corruption could have occurred. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-5700:Memory safety bugs present in Firefox 126, Firefox ESR 115.11, and Thunderbird 115.11. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5692:On Windows 10, when using the &#39;Save As&#39; functionality, an attacker could have tricked the browser into saving the file with a disallowed extension such as `.url` by including an invalid character in the extension. *Note:* This issue only affected Windows operating systems. Other operating systems are unaffected. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5689:In addition to detecting when a user was taking a screenshot (XXX), a website was able to overlay the &#39;My Shots&#39; button that appeared, and direct the user to a replica Firefox Screenshots page that could be used for phishing. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-5693:Offscreen Canvas did not properly track cross-origin tainting, which could be used to access image data from another site in violation of same-origin policy. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5701:Memory safety bugs present in Firefox 126. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-5698:By manipulating the fullscreen feature while opening a data-list, an attacker could have overlaid a text box over the address bar. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-5688:If a garbage collection was triggered at the right time, a use-after-free could have occurred during object transplant. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.&#xA;CVE-2024-5699:In violation of spec, cookie prefixes such as `__Secure` were being ignored if they were not correctly capitalized - by spec they should be checked with a case-insensitive comparison. This could have resulted in the browser not correctly honoring the behaviors specified by the prefix. This vulnerability affects Firefox &lt; 127.&#xA;CVE-2024-6603:In an out-of-memory scenario an allocation could fail but free would have been called on the pointer afterwards leading to memory corruption. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.&#xA;CVE-2024-6605:Firefox Android allowed immediate interaction with permission prompts. This could be used for tapjacking. This vulnerability affects Firefox &lt; 128.&#xA;CVE-2024-6608:It was possible to move the cursor using pointerlock from an iframe. This allowed moving the cursor outside of the viewport and the Firefox window. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6601:A race condition could lead to a cross-origin container obtaining permissions of the top-level origin. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.&#xA;CVE-2024-6615:Memory safety bugs present in Firefox 127 and Thunderbird 127. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6609:When almost out-of-memory an elliptic curve key which was never allocated could have been freed again. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6611:A nested iframe, triggering a cross-site navigation, could send SameSite=Strict or Lax cookies. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6607:It was possible to prevent a user from exiting pointerlock when pressing escape and to overlay customValidity notifications from a `&amp;lt;select&amp;gt;` element over certain permission prompts. This could be used to confuse a user into giving a site unintended permissions. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6604:Memory safety bugs present in Firefox 127, Firefox ESR 115.12, and Thunderbird 115.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.&#xA;CVE-2024-6606:Clipboard code failed to check the index on an array access. This could have led to an out-of-bounds read. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6610:Form validation popups could capture escape key presses. Therefore, spamming form validation messages could be used to prevent users from exiting full-screen mode. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6612:CSP violations generated links in the console tab of the developer tools, pointing to the violating resource. This caused a DNS prefetch which leaked that a CSP violation happened. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6602:A mismatch between allocator and deallocator could have led to memory corruption. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.&#xA;CVE-2024-6613:The frame iterator could get stuck in a loop when encountering certain wasm frames leading to incorrect stack traces. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-6614:The frame iterator could get stuck in a loop when encountering certain wasm frames leading to incorrect stack traces. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.&#xA;CVE-2024-7531:Calling `PK11_Encrypt()` in NSS using CKM_CHACHA20 and the same buffer for input and output can result in plaintext on an Intel Sandy Bridge processor. In Firefox this only affects the QUIC header protection feature when the connection is using the ChaCha20-Poly1305 cipher suite. The most likely outcome is connection failure, but if the connection persists despite the high packet loss it could be possible for a network observer to identify packets as coming from the same source despite a network path change. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, and Firefox ESR &lt; 128.1.&#xA;CVE-2024-7521:Incomplete WebAssembly exception handing could have led to a use-after-free. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-7525:It was possible for a web extension with minimal permissions to create a `StreamFilter` which could be used to read and modify the response body of requests on any site. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-7526:ANGLE failed to initialize parameters which lead to reading from uninitialized memory. This could be leveraged to leak sensitive data from memory. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-7529:The date picker could partially obscure security prompts. This could be used by a malicious site to trick a user into granting permissions. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-7524:Firefox adds web-compatibility shims in place of some tracking scripts blocked by Enhanced Tracking Protection.  On a site protected by Content Security Policy in &#34;strict-dynamic&#34; mode, an attacker able to inject an HTML element could have used a DOM Clobbering attack on some of the shims and achieved XSS, bypassing the CSP strict-dynamic protection. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, and Firefox ESR &lt; 128.1.&#xA;CVE-2024-7519:Insufficient checks when processing graphics shared memory could have led to memory corruption. This could be leveraged by an attacker to perform a sandbox escape. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-7522:Editor code failed to check an attribute value. This could have led to an out-of-bounds read. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-7527:Unexpected marking work at the start of sweeping could have led to a use-after-free. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.&#xA;CVE-2024-8382:Internal browser event interfaces were exposed to web content when privileged EventHandler listener callbacks ran for those events. Web content that tried to use those interfaces would not be able to use them with elevated privileges, but their presence would indicate certain browser features had been used, such as when a user opened the Dev Tools console. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, Firefox ESR &lt; 115.15, Thunderbird &lt; 128.2, and Thunderbird &lt; 115.15.&#xA;CVE-2024-8384:The JavaScript garbage collector could mis-color cross-compartment objects if OOM conditions were detected at the right point between two passes. This could have led to memory corruption. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, Firefox ESR &lt; 115.15, Thunderbird &lt; 128.2, and Thunderbird &lt; 115.15.&#xA;CVE-2024-8383:Firefox normally asks for confirmation before asking the operating system to find an application to handle a scheme that the browser does not support. It did not ask before doing so for the Usenet-related schemes news: and snews:. Since most operating systems don&#39;t have a trusted newsreader installed by default, an unscrupulous program that the user downloaded could register itself as a handler. The website that served the application download could then launch that application at will. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, and Firefox ESR &lt; 115.15.&#xA;CVE-2024-8381:A potentially exploitable type confusion could be triggered when looking up a property name on an object being used as the `with` environment. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, Firefox ESR &lt; 115.15, Thunderbird &lt; 128.2, and Thunderbird &lt; 115.15.&#xA;CVE-2024-7652:An error in the ECMA-262 specification relating to Async Generators could have resulted in a type confusion, potentially leading to memory corruption and an exploitable crash. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.&#xA;CVE-2024-9400:A potential memory corruption vulnerability could be triggered if an attacker had the ability to trigger an OOM at a specific moment during JIT compilation. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9401:Memory safety bugs present in Firefox 130, Firefox ESR 115.15, Firefox ESR 128.2, and Thunderbird 128.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9399:A website configured to initiate a specially crafted WebTransport session could crash the Firefox process leading to a denial of service condition. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9402:Memory safety bugs present in Firefox 130, Firefox ESR 128.2, and Thunderbird 128.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9392:A compromised content process could have allowed for the arbitrary loading of cross-origin pages. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9397:A missing delay in directory upload UI could have made it possible for an attacker to trick a user into granting permission via clickjacking. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9396:It is currently unknown if this issue is exploitable but a condition may arise where the structured clone of certain objects could lead to memory corruption. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9393:An attacker could, via a specially crafted multipart response, execute arbitrary JavaScript under the `resource://pdf.js` origin.  This could allow them to access cross-origin PDF content. This access is limited to &#34;same site&#34; documents by the Site Isolation feature on desktop clients, but full cross-origin access is possible on Android versions. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9394:An attacker could, via a specially crafted multipart response, execute arbitrary JavaScript under the `resource://devtools` origin.  This could allow them to access cross-origin JSON content. This access is limited to &#34;same site&#34; documents by the Site Isolation feature on desktop clients, but full cross-origin access is possible on Android versions. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9398:By checking the result of calls to `window.open` with specifically set protocol handlers, an attacker could determine if the application which implements that protocol handler is installed. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.&#xA;CVE-2024-9680:An attacker was able to achieve code execution in the content process by exploiting a use-after-free in Animation timelines. We have had reports of this vulnerability being exploited in the wild. This vulnerability affects Firefox &lt; 131.0.2, Firefox ESR &lt; 128.3.1, Firefox ESR &lt; 115.16.1, Thunderbird &lt; 131.0.1, Thunderbird &lt; 128.3.1, and Thunderbird &lt; 115.16.0.&#xA;CVE-2024-10464:Repeated writes to history interface attributes could have been used to cause a Denial of Service condition in the browser. This was addressed by introducing rate-limiting to this API. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10459:An attacker could have caused a use-after-free when accessibility was enabled, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Firefox ESR &lt; 115.17, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10467:Memory safety bugs present in Firefox 131, Firefox ESR 128.3, and Thunderbird 128.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10466:By sending a specially crafted push message, a remote server could have hung the parent process, causing the browser to become unresponsive. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10462:Truncation of a long URL could have allowed origin spoofing in a permission prompt. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10458:A permission leak could have occurred from a trusted site to an untrusted site via `embed` or `object` elements. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Firefox ESR &lt; 115.17, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10465:A clipboard &#34;paste&#34; button could persist across tabs which allowed a spoofing attack. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10463:Video frames could have been leaked between origins in some situations. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Firefox ESR &lt; 115.17, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10460:The origin of an external protocol handler prompt could have been obscured using a data: URL within an `iframe`. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10461:In multipart/x-mixed-replace responses, `Content-Disposition: attachment` in the response header was not respected and did not force a download, which could allow XSS attacks. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.&#xA;CVE-2024-10941:A malicious website could have included an iframe with an malformed URI resulting in a non-exploitable browser crash. This vulnerability affects Firefox &lt; 126.&#xA;CVE-2024-11694:Enhanced Tracking Protection&#39;s Strict mode may have inadvertently allowed a CSP `frame-src` bypass and DOM-based XSS through the Google SafeFrame shim in the Web Compatibility extension. This issue could have exposed users to malicious frames masquerading as legitimate content. This vulnerability affects Firefox &lt; 133, Firefox ESR &lt; 128.5, Firefox ESR &lt; 115.18, Thunderbird &lt; 133, Thunderbird &lt; 128.5, and Thunderbird &lt; 115.18.&#xA;CVE-2024-11697:When handling keypress events, an attacker may have been able to trick a user into bypassing the &#34;Open Executable File?&#34; confirmation dialog. This could have led to malicious code execution. This vulnerability affects Firefox &lt; 133, Firefox ESR &lt; 128.5, Thunderbird &lt; 133, and Thunderbird &lt; 128.5.&#xA;CVE-2024-11692:An attacker could cause a select dropdown to be shown over another tab; this could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 133, Firefox ESR &lt; 128.5, Thunderbird &lt; 133, and Thunderbird &lt; 128.5.&#xA;CVE-2024-11699:Memory safety bugs present in Firefox 132, Firefox ESR 128.4, and Thunderbird 128.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 133, Firefox ESR &lt; 128.5, Thunderbird &lt; 133, and Thunderbird &lt; 128.5.&#xA;CVE-2024-11696:The application failed to account for exceptions thrown by the `loadManifestFromFile` method during add-on signature verification. This flaw, triggered by an invalid or unsupported extension manifest, could have caused runtime errors that disrupted the signature validation process. As a result, the enforcement of signature validation for unrelated add-ons may have been bypassed.  Signature validation in this context is used to ensure that third-party applications on the user&#39;s computer have not tampered with the user&#39;s extensions, limiting the impact of this issue. This vulnerability affects Firefox &lt; 133, Firefox ESR &lt; 128.5, Thunderbird &lt; 133, and Thunderbird &lt; 128.5.&#xA;CVE-2024-11695:A crafted URL containing Arabic script and whitespace characters could have hidden the true origin of the page, resulting in a potential spoofing attack. This vulnerability affects Firefox &lt; 133, Firefox ESR &lt; 128.5, Thunderbird &lt; 133, and Thunderbird &lt; 128.5.&#xA;CVE-2025-0237:The WebChannel API, which is used to transport various information across processes, did not check the sending principal but rather accepted the principal being sent. This could have led to privilege escalation attacks. This vulnerability affects Firefox &lt; 134, Firefox ESR &lt; 128.6, Thunderbird &lt; 134, and Thunderbird &lt; 128.6.&#xA;CVE-2025-0242:Memory safety bugs present in Firefox 133, Thunderbird 133, Firefox ESR 115.18, Firefox ESR 128.5, Thunderbird 115.18, and Thunderbird 128.5. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 134, Firefox ESR &lt; 128.6, Firefox ESR &lt; 115.19, Thunderbird &lt; 134, and Thunderbird &lt; 128.6.&#xA;CVE-2025-1016:Memory safety bugs present in Firefox 134, Thunderbird 134, Firefox ESR 115.19, Firefox ESR 128.6, Thunderbird 115.19, and Thunderbird 128.6. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 115.20, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1009:An attacker could have caused a use-after-free via crafted XSLT data, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 115.20, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1017:Memory safety bugs present in Firefox 134, Thunderbird 134, Firefox ESR 128.6, and Thunderbird 128.6. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1013:A race condition could have led to private browsing tabs being opened in normal browsing windows. This could have resulted in a potential privacy leak. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1010:An attacker could have caused a use-after-free via the Custom Highlight API, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 115.20, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1014:Certificate length was not properly checked when added to a certificate store. In practice only trusted data was processed. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1011:A bug in WebAssembly code generation could have lead to a crash. It may have been possible for an attacker to leverage this to achieve code execution. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2025-1012:A race during concurrent delazification could have led to a use-after-free. This vulnerability affects Firefox &lt; 135, Firefox ESR &lt; 115.20, Firefox ESR &lt; 128.7, Thunderbird &lt; 128.7, and Thunderbird &lt; 135.&#xA;CVE-2024-43097:In resizeToAtLeast of SkRegion.cpp, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.&#xA;CVE-2025-1931:It was possible to cause a use-after-free in the content process side of a WebTransport connection, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 115.21, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1932:An inconsistent comparator in xslt/txNodeSorter could have resulted in potentially exploitable out-of-bounds access. Only affected version 122 and later. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1933:On 64-bit CPUs, when the JIT compiles WASM i32 return values they can pick up bits from left over memory. This can potentially cause them to be treated as a different type. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 115.21, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1934:It was possible to interrupt the processing of a RegExp bailout and run additional JavaScript, potentially triggering garbage collection when the engine was not expecting it. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1935:A web page could trick a user into setting that site as the default handler for a custom URL protocol. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1936:jar: URLs retrieve local file content packaged in a ZIP archive. The null and everything after it was ignored when retrieving the content from the archive, but the fake extension after the null was used to determine the type of content. This could have been used to hide code in a web extension disguised as something else like an image. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1937:Memory safety bugs present in Firefox 135, Thunderbird 135, Firefox ESR 115.20, Firefox ESR 128.7, and Thunderbird 128.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 115.21, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-1938:Memory safety bugs present in Firefox 135, Thunderbird 135, Firefox ESR 128.7, and Thunderbird 128.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.&#xA;CVE-2025-3028:JavaScript code running while transforming a document with the XSLTProcessor could lead to a use-after-free. This vulnerability affects Firefox &lt; 137, Firefox ESR &lt; 115.22, Firefox ESR &lt; 128.9, Thunderbird &lt; 137, and Thunderbird &lt; 128.9.&#xA;CVE-2025-3029:A crafted URL containing specific Unicode characters could have hidden the true origin of the page, resulting in a potential spoofing attack. This vulnerability affects Firefox &lt; 137, Firefox ESR &lt; 128.9, Thunderbird &lt; 137, and Thunderbird &lt; 128.9.&#xA;CVE-2025-3030:Memory safety bugs present in Firefox 136, Thunderbird 136, Firefox ESR 128.8, and Thunderbird 128.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 137, Firefox ESR &lt; 128.9, Thunderbird &lt; 137, and Thunderbird &lt; 128.9.&#xA;CVE-2025-2817:Thunderbird&#39;s update mechanism allowed a medium-integrity user process to interfere with the SYSTEM-level updater by manipulating the file-locking behavior. By injecting code into the user-privileged process, an attacker could bypass intended access controls, allowing SYSTEM-level file operations on paths controlled by a non-privileged user and enabling privilege escalation. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Firefox ESR &lt; 115.23, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.&#xA;CVE-2025-4083:A process isolation vulnerability in Thunderbird stemmed from improper handling of javascript: URIs, which could allow content to execute in the top-level document&#39;s process instead of the intended frame, potentially enabling a sandbox escape. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Firefox ESR &lt; 115.23, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.&#xA;CVE-2025-4084:Due to insufficient escaping of the special characters in the &#34;copy as cURL&#34; feature, an attacker could trick a user into using this command, potentially leading to local code execution on the user&#39;s system.&#xA;*This bug only affects Firefox for Windows. Other versions of Firefox are unaffected.* This vulnerability affects Firefox ESR &lt; 128.10, Firefox ESR &lt; 115.23, and Thunderbird &lt; 128.10.&#xA;CVE-2025-4087:A vulnerability was identified in Thunderbird where XPath parsing could trigger undefined behavior due to missing null checks during attribute access. This could lead to out-of-bounds read access and potentially, memory corruption. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.&#xA;CVE-2025-4091:Memory safety bugs present in Firefox 137, Thunderbird 137, Firefox ESR 128.9, and Thunderbird 128.9. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.&#xA;CVE-2025-4093:Memory safety bug present in Firefox ESR 128.9, and Thunderbird 128.9. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 128.10 and Thunderbird &lt; 128.10.&#xA;CVE-2025-4918:An attacker was able to perform an out-of-bounds read or write on a JavaScript `Promise` object. This vulnerability affects Firefox &lt; 138.0.4, Firefox ESR &lt; 128.10.1, Firefox ESR &lt; 115.23.1, Thunderbird &lt; 128.10.2, and Thunderbird &lt; 138.0.2.&#xA;CVE-2025-4919:An attacker was able to perform an out-of-bounds read or write on a JavaScript object by confusing array index sizes. This vulnerability affects Firefox &lt; 138.0.4, Firefox ESR &lt; 128.10.1, Firefox ESR &lt; 115.23.1, Thunderbird &lt; 128.10.2, and Thunderbird &lt; 138.0.2.&#xA;CVE-2025-5263:Error handling for script execution was incorrectly isolated from web content, which could have allowed cross-origin leak attacks. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 115.24, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.&#xA;CVE-2025-5264:Due to insufficient escaping of the newline character in the “Copy as cURL” feature, an attacker could trick a user into using this command, potentially leading to local code execution on the user&#39;s system. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 115.24, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.&#xA;CVE-2025-5266:Script elements loading cross-origin resources generated load and error events which leaked information enabling XS-Leaks attacks. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.&#xA;CVE-2025-5267:A clickjacking vulnerability could have been used to trick a user into leaking saved payment card details to a malicious page. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.&#xA;CVE-2025-5268:Memory safety bugs present in Firefox 138, Thunderbird 138, Firefox ESR 128.10, and Thunderbird 128.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.&#xA;CVE-2025-5269:Memory safety bug present in Firefox ESR 128.10, and Thunderbird 128.10. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 128.11 and Thunderbird &lt; 128.11.&#xA;CVE-2025-6424:A use-after-free in FontFaceSet resulted in a potentially exploitable crash. This vulnerability affects Firefox &lt; 140, Firefox ESR &lt; 115.25, Firefox ESR &lt; 128.12, Thunderbird &lt; 140, and Thunderbird &lt; 128.12.&#xA;CVE-2025-6425:An attacker who enumerated resources from the WebCompat extension could have obtained a persistent UUID that identified the browser, and persisted between containers and normal/private browsing mode, but not profiles. This vulnerability affects Firefox &lt; 140, Firefox ESR &lt; 115.25, Firefox ESR &lt; 128.12, Thunderbird &lt; 140, and Thunderbird &lt; 128.12.&#xA;CVE-2025-6429:Firefox could have incorrectly parsed a URL and rewritten it to the youtube.com domain when parsing the URL specified in an `embed` tag.  This could have bypassed website security checks that restricted which domains users were allowed to embed. This vulnerability affects Firefox &lt; 140, Firefox ESR &lt; 128.12, Thunderbird &lt; 140, and Thunderbird &lt; 128.12.&#xA;CVE-2025-6430:When a file download is specified via the `Content-Disposition` header, that directive would be ignored if the file was included via a `&amp;lt;embed&amp;gt;` or `&amp;lt;object&amp;gt;` tag, potentially making a website vulnerable to a cross-site scripting attack. This vulnerability affects Firefox &lt; 140, Firefox ESR &lt; 128.12, Thunderbird &lt; 140, and Thunderbird &lt; 128.12.&#xA;CVE-2025-8027:On 64-bit platforms IonMonkey-JIT only wrote 32 bits of the 64-bit return value space on the stack. Baseline-JIT, however, read the entire 64 bits. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 115.26, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8028:On arm64, a WASM `br_table` instruction with a lot of entries could lead to the label being too far from the instruction causing truncation and incorrect computation of the branch address. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 115.26, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8029:Thunderbird executed `javascript:` URLs when used in `object` and `embed` tags. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8030:Insufficient escaping in the “Copy as cURL” feature could potentially be used to trick a user into executing unexpected code. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8031:The `username:password` part was not correctly stripped from URLs in CSP reports potentially leaking HTTP Basic Authentication credentials. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8032:XSLT document loading did not correctly propagate the source document which bypassed its CSP. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8033:The JavaScript engine did not handle closed generators correctly and it was possible to resume them leading to a nullptr deref. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 115.26, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8034:Memory safety bugs present in Firefox ESR 115.25, Firefox ESR 128.12, Thunderbird ESR 128.12, Firefox ESR 140.0, Thunderbird ESR 140.0, Firefox 140 and Thunderbird 140. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 115.26, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;CVE-2025-8035:Memory safety bugs present in Firefox ESR 128.12, Thunderbird ESR 128.12, Firefox ESR 140.0, Thunderbird ESR 140.0, Firefox 140 and Thunderbird 140. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 141, Firefox ESR &lt; 128.13, Firefox ESR &lt; 140.1, Thunderbird &lt; 141, Thunderbird &lt; 128.13, and Thunderbird &lt; 140.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="firefox" release="1.u9" version="128.14.0">
					<filename>firefox-128.14.0-1.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/firefox-128.14.0-1.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="firefox" release="1.u9" version="128.14.0">
					<filename>firefox-128.14.0-1.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/firefox-128.14.0-1.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2272</id>
		<title>An update for exiv2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54080&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54080" id="CVE-2025-54080" title="CVE-2025-54080" type="cve"></reference>
		</references>
		<description>CVE-2025-54080:Exiv2 is a C++ library and a command-line utility to read, write, delete and modify Exif, IPTC, XMP and ICC image metadata. An out-of-bounds read was found in Exiv2 versions 0.28.5 and earlier. The out-of-bounds read is triggered when Exiv2 is used to write metadata into a crafted image file. An attacker could potentially exploit the vulnerability to cause a denial of service by crashing Exiv2, if they can trick the victim into running Exiv2 on a crafted image file. Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata. The bug is fixed in version 0.28.6.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="exiv2-help" release="4.u1" version="0.27.5">
					<filename>exiv2-help-0.27.5-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/exiv2-help-0.27.5-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="exiv2-devel" release="4.u1" version="0.27.5">
					<filename>exiv2-devel-0.27.5-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/exiv2-devel-0.27.5-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="exiv2" release="4.u1" version="0.27.5">
					<filename>exiv2-0.27.5-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/exiv2-0.27.5-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="exiv2" release="4.u1" version="0.27.5">
					<filename>exiv2-0.27.5-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/exiv2-0.27.5-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="exiv2-devel" release="4.u1" version="0.27.5">
					<filename>exiv2-devel-0.27.5-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/exiv2-devel-0.27.5-4.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2273</id>
		<title>An update for krb5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3576&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3576" id="CVE-2025-3576" title="CVE-2025-3576" type="cve"></reference>
		</references>
		<description>CVE-2025-3576:A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="krb5-help" release="26.u14" version="1.19.2">
					<filename>krb5-help-1.19.2-26.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/krb5-help-1.19.2-26.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5" release="26.u14" version="1.19.2">
					<filename>krb5-1.19.2-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/krb5-1.19.2-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-devel" release="26.u14" version="1.19.2">
					<filename>krb5-devel-1.19.2-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/krb5-devel-1.19.2-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-server" release="26.u14" version="1.19.2">
					<filename>krb5-server-1.19.2-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/krb5-server-1.19.2-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-client" release="26.u14" version="1.19.2">
					<filename>krb5-client-1.19.2-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/krb5-client-1.19.2-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="krb5-libs" release="26.u14" version="1.19.2">
					<filename>krb5-libs-1.19.2-26.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/krb5-libs-1.19.2-26.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5" release="26.u14" version="1.19.2">
					<filename>krb5-1.19.2-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/krb5-1.19.2-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-client" release="26.u14" version="1.19.2">
					<filename>krb5-client-1.19.2-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/krb5-client-1.19.2-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-devel" release="26.u14" version="1.19.2">
					<filename>krb5-devel-1.19.2-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/krb5-devel-1.19.2-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-server" release="26.u14" version="1.19.2">
					<filename>krb5-server-1.19.2-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/krb5-server-1.19.2-26.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="krb5-libs" release="26.u14" version="1.19.2">
					<filename>krb5-libs-1.19.2-26.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/krb5-libs-1.19.2-26.u14.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2274</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8058" id="CVE-2025-8058" title="CVE-2025-8058" type="cve"></reference>
		</references>
		<description>CVE-2025-8058:The regcomp function in the GNU C library version from 2.4 to 2.41 is &#xA;subject to a double free if some previous allocation fails. It can be &#xA;accomplished either by a malloc failure or by using an interposed malloc&#xA; that injects random malloc failures. The double free can allow buffer &#xA;manipulation depending of how the regex is constructed. This issue &#xA;affects all architectures and ABIs supported by the GNU C library.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="151.u28" version="2.34">
					<filename>glibc-locale-archive-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-locale-archive-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="151.u28" version="2.34">
					<filename>glibc-nss-devel-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-nss-devel-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="151.u28" version="2.34">
					<filename>nscd-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nscd-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="151.u28" version="2.34">
					<filename>glibc-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="151.u28" version="2.34">
					<filename>glibc-common-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-common-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="151.u28" version="2.34">
					<filename>glibc-all-langpacks-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-all-langpacks-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="151.u28" version="2.34">
					<filename>glibc-compat-2.17-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-compat-2.17-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="151.u28" version="2.34">
					<filename>glibc-debugutils-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-debugutils-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="151.u28" version="2.34">
					<filename>glibc-devel-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-devel-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="151.u28" version="2.34">
					<filename>glibc-locale-source-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/glibc-locale-source-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="151.u28" version="2.34">
					<filename>libnsl-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libnsl-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="151.u28" version="2.34">
					<filename>nss_modules-2.34-151.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nss_modules-2.34-151.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="151.u28" version="2.34">
					<filename>glibc-nss-devel-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-nss-devel-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="151.u28" version="2.34">
					<filename>glibc-common-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-common-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc" release="151.u28" version="2.34">
					<filename>glibc-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="151.u28" version="2.34">
					<filename>glibc-debugutils-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-debugutils-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="151.u28" version="2.34">
					<filename>glibc-locale-source-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-locale-source-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="151.u28" version="2.34">
					<filename>glibc-locale-archive-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-locale-archive-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="151.u28" version="2.34">
					<filename>libnsl-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libnsl-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="151.u28" version="2.34">
					<filename>glibc-compat-2.17-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-compat-2.17-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="151.u28" version="2.34">
					<filename>glibc-all-langpacks-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-all-langpacks-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="151.u28" version="2.34">
					<filename>glibc-devel-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-devel-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="151.u28" version="2.34">
					<filename>nscd-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nscd-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="151.u28" version="2.34">
					<filename>nss_modules-2.34-151.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nss_modules-2.34-151.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="151.u28" version="2.34">
					<filename>glibc-help-2.34-151.u28.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/glibc-help-2.34-151.u28.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2275</id>
		<title>An update for netty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-24823" id="CVE-2022-24823" title="CVE-2022-24823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55163&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55163" id="CVE-2025-55163" title="CVE-2025-55163" type="cve"></reference>
		</references>
		<description>CVE-2022-24823:Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty&#39;s multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one&#39;s own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.&#xA;CVE-2025-55163:Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.124.Final and 4.2.4.Final, Netty is vulnerable to MadeYouReset DDoS. This is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. This issue has been patched in versions 4.1.124.Final and 4.2.4.Final.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="netty" release="22.u4" version="4.1.13">
					<filename>netty-4.1.13-22.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/netty-4.1.13-22.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="netty-help" release="22.u4" version="4.1.13">
					<filename>netty-help-4.1.13-22.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/netty-help-4.1.13-22.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netty" release="22.u4" version="4.1.13">
					<filename>netty-4.1.13-22.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/netty-4.1.13-22.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2276</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53905&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53905" id="CVE-2025-53905" title="CVE-2025-53905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53906&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53906" id="CVE-2025-53906" title="CVE-2025-53906" type="cve"></reference>
		</references>
		<description>CVE-2025-53905:Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim’s tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.&#xA;CVE-2025-53906:Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim’s zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="35.u22" version="9.0">
					<filename>vim-filesystem-9.0-35.u22.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/vim-filesystem-9.0-35.u22.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="35.u22" version="9.0">
					<filename>vim-X11-9.0-35.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/vim-X11-9.0-35.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-common" release="35.u22" version="9.0">
					<filename>vim-common-9.0-35.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/vim-common-9.0-35.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="35.u22" version="9.0">
					<filename>vim-minimal-9.0-35.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/vim-minimal-9.0-35.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="35.u22" version="9.0">
					<filename>vim-enhanced-9.0-35.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/vim-enhanced-9.0-35.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="35.u22" version="9.0">
					<filename>vim-common-9.0-35.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/vim-common-9.0-35.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="35.u22" version="9.0">
					<filename>vim-enhanced-9.0-35.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/vim-enhanced-9.0-35.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-X11" release="35.u22" version="9.0">
					<filename>vim-X11-9.0-35.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/vim-X11-9.0-35.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="35.u22" version="9.0">
					<filename>vim-minimal-9.0-35.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/vim-minimal-9.0-35.u22.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2277</id>
		<title>An update for iputils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48964" id="CVE-2025-48964" title="CVE-2025-48964" type="cve"></reference>
		</references>
		<description>CVE-2025-48964:ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="iputils-help" release="8.u6" version="20221126">
					<filename>iputils-help-20221126-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/iputils-help-20221126-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="iputils" release="8.u6" version="20221126">
					<filename>iputils-20221126-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/iputils-20221126-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="iputils" release="8.u6" version="20221126">
					<filename>iputils-20221126-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/iputils-20221126-8.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2278</id>
		<title>An update for gnuplot is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31176" id="CVE-2025-31176" title="CVE-2025-31176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31179&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31179" id="CVE-2025-31179" title="CVE-2025-31179" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31180&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31180" id="CVE-2025-31180" title="CVE-2025-31180" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31181" id="CVE-2025-31181" title="CVE-2025-31181" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3359&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3359" id="CVE-2025-3359" title="CVE-2025-3359" type="cve"></reference>
		</references>
		<description>CVE-2025-31176:A flaw was found in gnuplot. The plot3d_points() function may lead to a segmentation fault and cause a system crash.&#xA;CVE-2025-31179:A flaw was found in gnuplot. The xstrftime() function may lead to a segmentation fault, causing a system crash.&#xA;CVE-2025-31180:A flaw was found in gnuplot. The CANVAS_text() function may lead to a segmentation fault and cause a system crash.&#xA;CVE-2025-31181:A flaw was found in gnuplot. The X11_graphics() function may lead to a segmentation fault and cause a system crash.&#xA;CVE-2025-3359:A flaw was found in GNUPlot. A segmentation fault via IO_str_init_static_internal may jeopardize the environment.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="gnuplot" release="15.u2" version="5.0.6">
					<filename>gnuplot-5.0.6-15.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/gnuplot-5.0.6-15.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnuplot-help" release="15.u2" version="5.0.6">
					<filename>gnuplot-help-5.0.6-15.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/gnuplot-help-5.0.6-15.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnuplot" release="15.u2" version="5.0.6">
					<filename>gnuplot-5.0.6-15.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/gnuplot-5.0.6-15.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2279</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57360&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57360" id="CVE-2024-57360" title="CVE-2024-57360" type="cve"></reference>
		</references>
		<description>CVE-2024-57360:https://www.gnu.org/software/binutils/ nm &gt;=2.43 is affected by: Incorrect Access Control. The type of exploitation is: local. The component is: `nm --without-symbol-version` function.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="aarch64" epoch="0" name="binutils" release="26.u16" version="2.37">
					<filename>binutils-2.37-26.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/binutils-2.37-26.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="26.u16" version="2.37">
					<filename>binutils-devel-2.37-26.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/binutils-devel-2.37-26.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="26.u16" version="2.37">
					<filename>binutils-help-2.37-26.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/binutils-help-2.37-26.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils" release="26.u16" version="2.37">
					<filename>binutils-2.37-26.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/binutils-2.37-26.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="26.u16" version="2.37">
					<filename>binutils-devel-2.37-26.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/binutils-devel-2.37-26.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="26.u16" version="2.37">
					<filename>binutils-help-2.37-26.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/binutils-help-2.37-26.u16.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2280</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4877&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4877" id="CVE-2025-4877" title="CVE-2025-4877" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4878&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4878" id="CVE-2025-4878" title="CVE-2025-4878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5372&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5372" id="CVE-2025-5372" title="CVE-2025-5372" type="cve"></reference>
		</references>
		<description>CVE-2025-4877:There&#39;s a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it&#39;s possible that the program perform out of bounds write leading to a heap corruption.&#xA;This issue affects only 32-bits builds of libssh.&#xA;CVE-2025-4878:A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn&#39;t exist and may lead to possible signing failures or heap corruption.&#xA;CVE-2025-5372:A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success—the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions&#39; confidentiality, integrity, and availability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="11.u6" version="0.9.6">
					<filename>libssh-devel-0.9.6-11.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libssh-devel-0.9.6-11.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="11.u6" version="0.9.6">
					<filename>libssh-0.9.6-11.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libssh-0.9.6-11.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh" release="11.u6" version="0.9.6">
					<filename>libssh-0.9.6-11.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libssh-0.9.6-11.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="11.u6" version="0.9.6">
					<filename>libssh-devel-0.9.6-11.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libssh-devel-0.9.6-11.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="11.u6" version="0.9.6">
					<filename>libssh-help-0.9.6-11.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libssh-help-0.9.6-11.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2281</id>
		<title>An update for nginx is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53859" id="CVE-2025-53859" title="CVE-2025-53859" type="cve"></reference>
		</references>
		<description>CVE-2025-53859:NGINX Open Source and NGINX Plus have a vulnerability in the ngx_mail_smtp_module that might allow an unauthenticated attacker to over-read NGINX SMTP authentication process memory; as a result, the server side may leak arbitrary bytes sent in a request to the authentication server. This issue happens during the NGINX SMTP authentication process and requires the attacker to make preparations against the target system to extract the leaked data. The issue affects NGINX only if (1) it is built with the ngx_mail_smtp_module, (2) the smtp_auth directive is configured with method &#34;none,&#34; and (3) the authentication server returns the &#34;Auth-Wait&#34; response header.&#xA;&#xA;&#xA;&#xA;&#xA;Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="10.u7" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-mod-http-image-filter-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="10.u7" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-mod-http-perl-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="10.u7" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-mod-devel-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="10.u7" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-mod-http-xslt-filter-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="10.u7" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-mod-stream-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx" release="10.u7" version="1.21.5">
					<filename>nginx-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="10.u7" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-10.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/nginx-mod-mail-1.21.5-10.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="10.u7" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-all-modules-1.21.5-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="10.u7" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-filesystem-1.21.5-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="10.u7" version="1.21.5">
					<filename>nginx-help-1.21.5-10.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-help-1.21.5-10.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="10.u7" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-mod-http-image-filter-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="10.u7" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-mod-http-xslt-filter-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="10.u7" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-mod-http-perl-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="10.u7" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-mod-stream-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="10.u7" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-mod-devel-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="10.u7" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-mod-mail-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx" release="10.u7" version="1.21.5">
					<filename>nginx-1.21.5-10.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/nginx-1.21.5-10.u7.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2282</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-13978&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-13978" id="CVE-2024-13978" title="CVE-2024-13978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8534&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8534" id="CVE-2025-8534" title="CVE-2025-8534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8851&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8851" id="CVE-2025-8851" title="CVE-2025-8851" type="cve"></reference>
		</references>
		<description>CVE-2024-13978:A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as problematic. Affected by this vulnerability is the function t2p_read_tiff_init of the file tools/tiff2pdf.c of the component fax2ps. The manipulation leads to null pointer dereference. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation appears to be difficult. The patch is named 2ebfffb0e8836bfb1cd7d85c059cd285c59761a4. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-8534:A vulnerability classified as problematic was found in libtiff 4.6.0. This vulnerability affects the function PS_Lvl2page of the file tools/tiff2ps.c of the component tiff2ps. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 6ba36f159fd396ad11bf6b7874554197736ecc8b. It is recommended to apply a patch to fix this issue. One of the maintainers explains, that &#34;[t]his error only occurs if DEFER_STRILE_LOAD (defer-strile-load:BOOL=ON) or TIFFOpen( .. &#34;rD&#34;) option is used.&#34;&#xA;CVE-2025-8851:A vulnerability was determined in LibTIFF up to 4.5.1. Affected by this issue is the function readSeparateStripsetoBuffer of the file tools/tiffcrop.c of the component tiffcrop. The manipulation leads to stack-based buffer overflow. Local access is required to approach this attack. The patch is identified as 8a7a48d7a645992ca83062b3a1873c951661e2b3. It is recommended to apply a patch to fix this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="42.u18" version="4.3.0">
					<filename>libtiff-4.3.0-42.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libtiff-4.3.0-42.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="42.u18" version="4.3.0">
					<filename>libtiff-static-4.3.0-42.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libtiff-static-4.3.0-42.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="42.u18" version="4.3.0">
					<filename>libtiff-tools-4.3.0-42.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libtiff-tools-4.3.0-42.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="42.u18" version="4.3.0">
					<filename>libtiff-devel-4.3.0-42.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libtiff-devel-4.3.0-42.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="42.u18" version="4.3.0">
					<filename>libtiff-help-4.3.0-42.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libtiff-help-4.3.0-42.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="42.u18" version="4.3.0">
					<filename>libtiff-4.3.0-42.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libtiff-4.3.0-42.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="42.u18" version="4.3.0">
					<filename>libtiff-devel-4.3.0-42.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libtiff-devel-4.3.0-42.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="42.u18" version="4.3.0">
					<filename>libtiff-tools-4.3.0-42.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libtiff-tools-4.3.0-42.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="42.u18" version="4.3.0">
					<filename>libtiff-static-4.3.0-42.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libtiff-static-4.3.0-42.u18.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2283</id>
		<title>An update for udisks2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8067&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8067" id="CVE-2025-8067" title="CVE-2025-8067" type="cve"></reference>
		</references>
		<description>CVE-2025-8067:A flaw was found in the Udisks daemon, where it allows unprivileged users to create loop devices using the D-BUS system. This is achieved via the loop device handler, which handles requests sent through the D-BUS interface. As two of the parameters of this handle, it receives the file descriptor list and index specifying the file where the loop device should be backed. The function itself validates the index value to ensure it isn&#39;t bigger than the maximum value allowed. However, it fails to validate the lower bound, allowing the index parameter to be a negative value. Under these circumstances, an attacker can cause the UDisks daemon to crash or perform a local privilege escalation by gaining access to files owned by privileged users.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="aarch64" epoch="0" name="udisks2" release="8.u9" version="2.9.4">
					<filename>udisks2-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/udisks2-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libudisks2-devel" release="8.u9" version="2.9.4">
					<filename>libudisks2-devel-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libudisks2-devel-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-lvm2" release="8.u9" version="2.9.4">
					<filename>udisks2-lvm2-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/udisks2-lvm2-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-vdo" release="8.u9" version="2.9.4">
					<filename>udisks2-vdo-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/udisks2-vdo-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-zram" release="8.u9" version="2.9.4">
					<filename>udisks2-zram-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/udisks2-zram-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libudisks2" release="8.u9" version="2.9.4">
					<filename>libudisks2-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/libudisks2-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-lsm" release="8.u9" version="2.9.4">
					<filename>udisks2-lsm-2.9.4-8.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/udisks2-lsm-2.9.4-8.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-lsm" release="8.u9" version="2.9.4">
					<filename>udisks2-lsm-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/udisks2-lsm-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-lvm2" release="8.u9" version="2.9.4">
					<filename>udisks2-lvm2-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/udisks2-lvm2-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-vdo" release="8.u9" version="2.9.4">
					<filename>udisks2-vdo-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/udisks2-vdo-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libudisks2-devel" release="8.u9" version="2.9.4">
					<filename>libudisks2-devel-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libudisks2-devel-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-zram" release="8.u9" version="2.9.4">
					<filename>udisks2-zram-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/udisks2-zram-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libudisks2" release="8.u9" version="2.9.4">
					<filename>libudisks2-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/libudisks2-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2" release="8.u9" version="2.9.4">
					<filename>udisks2-2.9.4-8.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/udisks2-2.9.4-8.u9.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2284</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47907&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47907" id="CVE-2025-47907" title="CVE-2025-47907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47906&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47906" id="CVE-2025-47906" title="CVE-2025-47906" type="cve"></reference>
		</references>
		<description>CVE-2025-47907:Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error.&#xA;CVE-2025-47906:A vulnerability was found in Google Go up to 1.23.11/1.24.5 (Programming Language Software). It has been declared as problematic.The manipulation of the argument PATH with an unknown input leads to a unknown weakness.As an impact it is known to affect integrity.Upgrading to version 1.23.12 or 1.24.6 eliminates this vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="golang" release="3.u13" version="1.20.5">
					<filename>golang-1.20.5-3.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/golang-1.20.5-3.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="3.u13" version="1.20.5">
					<filename>golang-devel-1.20.5-3.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/golang-devel-1.20.5-3.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="3.u13" version="1.20.5">
					<filename>golang-help-1.20.5-3.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/golang-help-1.20.5-3.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="3.u13" version="1.20.5">
					<filename>golang-1.20.5-3.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/golang-1.20.5-3.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2285</id>
		<title>An update for clamav is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20260&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-20260" id="CVE-2025-20260" title="CVE-2025-20260" type="cve"></reference>
		</references>
		<description>CVE-2025-20260:A vulnerability in the PDF scanning processes of ClamAV could allow an unauthenticated, remote attacker to cause a buffer overflow condition, cause a denial of service (DoS) condition, or execute arbitrary code on an affected device.&#xA;&#xA;This vulnerability exists because memory buffers are allocated incorrectly when PDF files are processed. An attacker could exploit this vulnerability by submitting a crafted PDF file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to trigger a buffer overflow, likely resulting in the termination of the ClamAV scanning process and a DoS condition on the affected software. Although unproven, there is also a possibility that an attacker could leverage the buffer overflow to execute arbitrary code with the privileges of the ClamAV process.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="noarch" epoch="0" name="clamav-help" release="2" version="1.0.9">
					<filename>clamav-help-1.0.9-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-help-1.0.9-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-data" release="2" version="1.0.9">
					<filename>clamav-data-1.0.9-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-data-1.0.9-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="clamav-filesystem" release="2" version="1.0.9">
					<filename>clamav-filesystem-1.0.9-2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-filesystem-1.0.9-2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-update" release="2" version="1.0.9">
					<filename>clamav-update-1.0.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-update-1.0.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav" release="2" version="1.0.9">
					<filename>clamav-1.0.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-1.0.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-milter" release="2" version="1.0.9">
					<filename>clamav-milter-1.0.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-milter-1.0.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamav-devel" release="2" version="1.0.9">
					<filename>clamav-devel-1.0.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamav-devel-1.0.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="clamd" release="2" version="1.0.9">
					<filename>clamd-1.0.9-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/clamd-1.0.9-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav" release="2" version="1.0.9">
					<filename>clamav-1.0.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/clamav-1.0.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-update" release="2" version="1.0.9">
					<filename>clamav-update-1.0.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/clamav-update-1.0.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-milter" release="2" version="1.0.9">
					<filename>clamav-milter-1.0.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/clamav-milter-1.0.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamd" release="2" version="1.0.9">
					<filename>clamd-1.0.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/clamd-1.0.9-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="clamav-devel" release="2" version="1.0.9">
					<filename>clamav-devel-1.0.9-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/clamav-devel-1.0.9-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2286</id>
		<title>An update for sleuthkit is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-09-17"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10232&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-10232" id="CVE-2020-10232" title="CVE-2020-10232" type="cve"></reference>
		</references>
		<description>CVE-2020-10232:In version 4.8.0 and earlier of The Sleuth Kit (TSK), there is a stack buffer overflow vulnerability in the YAFFS file timestamp parsing logic in yaffsfs_istat() in fs/yaffs.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20</name>
				<package arch="x86_64" epoch="0" name="sleuthkit" release="13.u4" version="4.6.7">
					<filename>sleuthkit-4.6.7-13.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/sleuthkit-4.6.7-13.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sleuthkit-devel" release="13.u4" version="4.6.7">
					<filename>sleuthkit-devel-4.6.7-13.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/sleuthkit-devel-4.6.7-13.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sleuthkit-help" release="13.u4" version="4.6.7">
					<filename>sleuthkit-help-4.6.7-13.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20/sleuthkit-help-4.6.7-13.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sleuthkit-devel" release="13.u4" version="4.6.7">
					<filename>sleuthkit-devel-4.6.7-13.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/sleuthkit-devel-4.6.7-13.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sleuthkit" release="13.u4" version="4.6.7">
					<filename>sleuthkit-4.6.7-13.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/sleuthkit-4.6.7-13.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sleuthkit-help" release="13.u4" version="4.6.7">
					<filename>sleuthkit-help-4.6.7-13.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20/sleuthkit-help-4.6.7-13.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2287</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21772&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21772" id="CVE-2025-21772" title="CVE-2025-21772" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56779&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56779" id="CVE-2024-56779" title="CVE-2024-56779" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38465&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38465" id="CVE-2025-38465" title="CVE-2025-38465" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38445&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38445" id="CVE-2025-38445" title="CVE-2025-38445" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49377&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49377" id="CVE-2022-49377" title="CVE-2022-49377" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38565&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38565" id="CVE-2025-38565" title="CVE-2025-38565" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57982&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57982" id="CVE-2024-57982" title="CVE-2024-57982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37780&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37780" id="CVE-2025-37780" title="CVE-2025-37780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58069&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58069" id="CVE-2024-58069" title="CVE-2024-58069" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22075&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22075" id="CVE-2025-22075" title="CVE-2025-22075" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37797&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37797" id="CVE-2025-37797" title="CVE-2025-37797" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38184&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38184" id="CVE-2025-38184" title="CVE-2025-38184" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38052&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38052" id="CVE-2025-38052" title="CVE-2025-38052" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38464&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38464" id="CVE-2025-38464" title="CVE-2025-38464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38192&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38192" id="CVE-2025-38192" title="CVE-2025-38192" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38115&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38115" id="CVE-2025-38115" title="CVE-2025-38115" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38124&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38124" id="CVE-2025-38124" title="CVE-2025-38124" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22018&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22018" id="CVE-2025-22018" title="CVE-2025-22018" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22058" id="CVE-2025-22058" title="CVE-2025-22058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49390&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49390" id="CVE-2022-49390" title="CVE-2022-49390" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21687&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21687" id="CVE-2025-21687" title="CVE-2025-21687" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37992&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37992" id="CVE-2025-37992" title="CVE-2025-37992" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37890&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37890" id="CVE-2025-37890" title="CVE-2025-37890" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38539&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38539" id="CVE-2025-38539" title="CVE-2025-38539" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57906&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57906" id="CVE-2024-57906" title="CVE-2024-57906" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56678" id="CVE-2024-56678" title="CVE-2024-56678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38001&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38001" id="CVE-2025-38001" title="CVE-2025-38001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38000&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38000" id="CVE-2025-38000" title="CVE-2025-38000" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53214&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53214" id="CVE-2024-53214" title="CVE-2024-53214" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39689&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39689" id="CVE-2025-39689" title="CVE-2025-39689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39813&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39813" id="CVE-2025-39813" title="CVE-2025-39813" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39829&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39829" id="CVE-2025-39829" title="CVE-2025-39829" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53216&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53216" id="CVE-2024-53216" title="CVE-2024-53216" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56558&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56558" id="CVE-2024-56558" title="CVE-2024-56558" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38602&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38602" id="CVE-2025-38602" title="CVE-2025-38602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38611" id="CVE-2025-38611" title="CVE-2025-38611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38632&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38632" id="CVE-2025-38632" title="CVE-2025-38632" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38652&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38652" id="CVE-2025-38652" title="CVE-2025-38652" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38563&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38563" id="CVE-2025-38563" title="CVE-2025-38563" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21759&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21759" id="CVE-2025-21759" title="CVE-2025-21759" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38174&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38174" id="CVE-2025-38174" title="CVE-2025-38174" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37885&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37885" id="CVE-2025-37885" title="CVE-2025-37885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21934&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21934" id="CVE-2025-21934" title="CVE-2025-21934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21665&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21665" id="CVE-2025-21665" title="CVE-2025-21665" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58052&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58052" id="CVE-2024-58052" title="CVE-2024-58052" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49135&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49135" id="CVE-2022-49135" title="CVE-2022-49135" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-54458&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-54458" id="CVE-2024-54458" title="CVE-2024-54458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37834&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37834" id="CVE-2025-37834" title="CVE-2025-37834" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38085" id="CVE-2025-38085" title="CVE-2025-38085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49622&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49622" id="CVE-2022-49622" title="CVE-2022-49622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22056&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22056" id="CVE-2025-22056" title="CVE-2025-22056" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56602&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56602" id="CVE-2024-56602" title="CVE-2024-56602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37911&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37911" id="CVE-2025-37911" title="CVE-2025-37911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38671&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38671" id="CVE-2025-38671" title="CVE-2025-38671" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38129&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38129" id="CVE-2025-38129" title="CVE-2025-38129" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38502&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38502" id="CVE-2025-38502" title="CVE-2025-38502" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38645&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38645" id="CVE-2025-38645" title="CVE-2025-38645" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38119&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38119" id="CVE-2025-38119" title="CVE-2025-38119" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38399&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38399" id="CVE-2025-38399" title="CVE-2025-38399" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38695&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38695" id="CVE-2025-38695" title="CVE-2025-38695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38710&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38710" id="CVE-2025-38710" title="CVE-2025-38710" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38724" id="CVE-2025-38724" title="CVE-2025-38724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38693&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38693" id="CVE-2025-38693" title="CVE-2025-38693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39773&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39773" id="CVE-2025-39773" title="CVE-2025-39773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50255&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50255" id="CVE-2022-50255" title="CVE-2022-50255" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53221&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53221" id="CVE-2023-53221" title="CVE-2023-53221" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49234&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49234" id="CVE-2022-49234" title="CVE-2022-49234" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21801&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21801" id="CVE-2025-21801" title="CVE-2025-21801" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22073&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22073" id="CVE-2025-22073" title="CVE-2025-22073" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38086&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38086" id="CVE-2025-38086" title="CVE-2025-38086" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38313&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38313" id="CVE-2025-38313" title="CVE-2025-38313" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38615" id="CVE-2025-38615" title="CVE-2025-38615" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39752&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39752" id="CVE-2025-39752" title="CVE-2025-39752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53259&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53259" id="CVE-2023-53259" title="CVE-2023-53259" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53241&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53241" id="CVE-2023-53241" title="CVE-2023-53241" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50350&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50350" id="CVE-2022-50350" title="CVE-2022-50350" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53438&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53438" id="CVE-2023-53438" title="CVE-2023-53438" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39866&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39866" id="CVE-2025-39866" title="CVE-2025-39866" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39865&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39865" id="CVE-2025-39865" title="CVE-2025-39865" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39883&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39883" id="CVE-2025-39883" title="CVE-2025-39883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50410&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50410" id="CVE-2022-50410" title="CVE-2022-50410" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39850&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39850" id="CVE-2025-39850" title="CVE-2025-39850" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38700&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38700" id="CVE-2025-38700" title="CVE-2025-38700" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38709&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38709" id="CVE-2025-38709" title="CVE-2025-38709" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39697" id="CVE-2025-39697" title="CVE-2025-39697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39795" id="CVE-2025-39795" title="CVE-2025-39795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50306&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50306" id="CVE-2022-50306" title="CVE-2022-50306" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53292&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53292" id="CVE-2023-53292" title="CVE-2023-53292" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57904&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57904" id="CVE-2024-57904" title="CVE-2024-57904" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39898&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39898" id="CVE-2025-39898" title="CVE-2025-39898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39971&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39971" id="CVE-2025-39971" title="CVE-2025-39971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39998&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39998" id="CVE-2025-39998" title="CVE-2025-39998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53728" id="CVE-2023-53728" title="CVE-2023-53728" type="cve"></reference>
		</references>
		<description>CVE-2025-21772:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;partitions: mac: fix handling of bogus partition table&#xA;&#xA;Fix several issues in partition probing:&#xA;&#xA; - The bailout for a bad partoffset must use put_dev_sector(), since the&#xA;   preceding read_part_sector() succeeded.&#xA; - If the partition table claims a silly sector size like 0xfff bytes&#xA;   (which results in partition table entries straddling sector boundaries),&#xA;   bail out instead of accessing out-of-bounds memory.&#xA; - We must not assume that the partition table contains proper NUL&#xA;   termination - use strnlen() and strncmp() instead of strlen() and&#xA;   strcmp().&#xA;CVE-2024-56779:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur&#xA;&#xA;The action force umount(umount -f) will attempt to kill all rpc_task even&#xA;umount operation may ultimately fail if some files remain open.&#xA;Consequently, if an action attempts to open a file, it can potentially&#xA;send two rpc_task to nfs server.&#xA;&#xA;                   NFS CLIENT&#xA;thread1                             thread2&#xA;open(&#34;file&#34;)&#xA;...&#xA;nfs4_do_open&#xA; _nfs4_do_open&#xA;  _nfs4_open_and_get_state&#xA;   _nfs4_proc_open&#xA;    nfs4_run_open_task&#xA;     /* rpc_task1 */&#xA;     rpc_run_task&#xA;     rpc_wait_for_completion_task&#xA;&#xA;                                    umount -f&#xA;                                    nfs_umount_begin&#xA;                                     rpc_killall_tasks&#xA;                                      rpc_signal_task&#xA;     rpc_task1 been wakeup&#xA;     and return -512&#xA; _nfs4_do_open // while loop&#xA;    ...&#xA;    nfs4_run_open_task&#xA;     /* rpc_task2 */&#xA;     rpc_run_task&#xA;     rpc_wait_for_completion_task&#xA;&#xA;While processing an open request, nfsd will first attempt to find or&#xA;allocate an nfs4_openowner. If it finds an nfs4_openowner that is not&#xA;marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since&#xA;two rpc_task can attempt to open the same file simultaneously from the&#xA;client to server, and because two instances of nfsd can run&#xA;concurrently, this situation can lead to lots of memory leak.&#xA;Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be&#xA;triggered.&#xA;&#xA;                    NFS SERVER&#xA;nfsd1                  nfsd2       echo 0 &gt; /proc/fs/nfsd/threads&#xA;&#xA;nfsd4_open&#xA; nfsd4_process_open1&#xA;  find_or_alloc_open_stateowner&#xA;   // alloc oo1, stateid1&#xA;                       nfsd4_open&#xA;                        nfsd4_process_open1&#xA;                        find_or_alloc_open_stateowner&#xA;                        // find oo1, without NFS4_OO_CONFIRMED&#xA;                         release_openowner&#xA;                          unhash_openowner_locked&#xA;                          list_del_init(&amp;oo-&gt;oo_perclient)&#xA;                          // cannot find this oo&#xA;                          // from client, LEAK!!!&#xA;                         alloc_stateowner // alloc oo2&#xA;&#xA; nfsd4_process_open2&#xA;  init_open_stateid&#xA;  // associate oo1&#xA;  // with stateid1, stateid1 LEAK!!!&#xA;  nfs4_get_vfs_file&#xA;  // alloc nfsd_file1 and nfsd_file_mark1&#xA;  // all LEAK!!!&#xA;&#xA;                         nfsd4_process_open2&#xA;                         ...&#xA;&#xA;                                    write_threads&#xA;                                     ...&#xA;                                     nfsd_destroy_serv&#xA;                                      nfsd_shutdown_net&#xA;                                       nfs4_state_shutdown_net&#xA;                                        nfs4_state_destroy_net&#xA;                                         destroy_client&#xA;                                          __destroy_client&#xA;                                          // won&#39;t find oo1!!!&#xA;                                     nfsd_shutdown_generic&#xA;                                      nfsd_file_cache_shutdown&#xA;                                       kmem_cache_destroy&#xA;                                       for nfsd_file_slab&#xA;                                       and nfsd_file_mark_slab&#xA;                                       // bark since nfsd_file1&#xA;                                       // and nfsd_file_mark1&#xA;                                       // still alive&#xA;&#xA;=======================================================================&#xA;BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on&#xA;__kmem_cache_shutdown()&#xA;-----------------------------------------------------------------------&#xA;&#xA;Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28&#xA;flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)&#xA;CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;1.16.1-2.fc37 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dum&#xA;---truncated---&#xA;CVE-2025-38465:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netlink: Fix wraparounds of sk-&gt;sk_rmem_alloc.&#xA;&#xA;Netlink has this pattern in some places&#xA;&#xA;  if (atomic_read(&amp;sk-&gt;sk_rmem_alloc) &gt; sk-&gt;sk_rcvbuf)&#xA;  &#x9;atomic_add(skb-&gt;truesize, &amp;sk-&gt;sk_rmem_alloc);&#xA;&#xA;, which has the same problem fixed by commit 5a465a0da13e (&#34;udp:&#xA;Fix multiple wraparounds of sk-&gt;sk_rmem_alloc.&#34;).&#xA;&#xA;For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition&#xA;is always false as the two operands are of int.&#xA;&#xA;Then, a single socket can eat as many skb as possible until OOM&#xA;happens, and we can see multiple wraparounds of sk-&gt;sk_rmem_alloc.&#xA;&#xA;Let&#39;s fix it by using atomic_add_return() and comparing the two&#xA;variables as unsigned int.&#xA;&#xA;Before:&#xA;  [root@fedora ~]# ss -f netlink&#xA;  Recv-Q      Send-Q Local Address:Port                Peer Address:Port&#xA;  -1668710080 0               rtnl:nl_wraparound/293               *&#xA;&#xA;After:&#xA;  [root@fedora ~]# ss -f netlink&#xA;  Recv-Q     Send-Q Local Address:Port                Peer Address:Port&#xA;  2147483072 0               rtnl:nl_wraparound/290               *&#xA;  ^&#xA;  `--- INT_MAX - 576&#xA;CVE-2025-38445:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;md/raid1: Fix stack memory use after return in raid1_reshape&#xA;&#xA;In the raid1_reshape function, newpool is&#xA;allocated on the stack and assigned to conf-&gt;r1bio_pool.&#xA;This results in conf-&gt;r1bio_pool.wait.head pointing&#xA;to a stack address.&#xA;Accessing this address later can lead to a kernel panic.&#xA;&#xA;Example access path:&#xA;&#xA;raid1_reshape()&#xA;{&#xA;&#x9;// newpool is on the stack&#xA;&#x9;mempool_t newpool, oldpool;&#xA;&#x9;// initialize newpool.wait.head to stack address&#xA;&#x9;mempool_init(&amp;newpool, ...);&#xA;&#x9;conf-&gt;r1bio_pool = newpool;&#xA;}&#xA;&#xA;raid1_read_request() or raid1_write_request()&#xA;{&#xA;&#x9;alloc_r1bio()&#xA;&#x9;{&#xA;&#x9;&#x9;mempool_alloc()&#xA;&#x9;&#x9;{&#xA;&#x9;&#x9;&#x9;// if pool-&gt;alloc fails&#xA;&#x9;&#x9;&#x9;remove_element()&#xA;&#x9;&#x9;&#x9;{&#xA;&#x9;&#x9;&#x9;&#x9;--pool-&gt;curr_nr;&#xA;&#x9;&#x9;&#x9;}&#xA;&#x9;&#x9;}&#xA;&#x9;}&#xA;}&#xA;&#xA;mempool_free()&#xA;{&#xA;&#x9;if (pool-&gt;curr_nr &lt; pool-&gt;min_nr) {&#xA;&#x9;&#x9;// pool-&gt;wait.head is a stack address&#xA;&#x9;&#x9;// wake_up() will try to access this invalid address&#xA;&#x9;&#x9;// which leads to a kernel panic&#xA;&#x9;&#x9;return;&#xA;&#x9;&#x9;wake_up(&amp;pool-&gt;wait);&#xA;&#x9;}&#xA;}&#xA;&#xA;Fix:&#xA;reinit conf-&gt;r1bio_pool.wait after assigning newpool.&#xA;CVE-2022-49377:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;blk-mq: don&#39;t touch -&gt;tagset in blk_mq_get_sq_hctx&#xA;&#xA;blk_mq_run_hw_queues() could be run when there isn&#39;t queued request and&#xA;after queue is cleaned up, at that time tagset is freed, because tagset&#xA;lifetime is covered by driver, and often freed after blk_cleanup_queue()&#xA;returns.&#xA;&#xA;So don&#39;t touch -&gt;tagset for figuring out current default hctx by the mapping&#xA;built in request queue, so use-after-free on tagset can be avoided. Meantime&#xA;this way should be fast than retrieving mapping from tagset.&#xA;CVE-2025-38565:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf/core: Exit early on perf_mmap() fail&#xA;&#xA;When perf_mmap() fails to allocate a buffer, it still invokes the&#xA;event_mapped() callback of the related event. On X86 this might increase&#xA;the perf_rdpmc_allowed reference counter. But nothing undoes this as&#xA;perf_mmap_close() is never called in this case, which causes another&#xA;reference count leak.&#xA;&#xA;Return early on failure to prevent that.&#xA;CVE-2024-57982:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xfrm: state: fix out-of-bounds read during lookup&#xA;&#xA;lookup and resize can run in parallel.&#xA;&#xA;The xfrm_state_hash_generation seqlock ensures a retry, but the hash&#xA;functions can observe a hmask value that is too large for the new hlist&#xA;array.&#xA;&#xA;rehash does:&#xA;  rcu_assign_pointer(net-&gt;xfrm.state_bydst, ndst) [..]&#xA;  net-&gt;xfrm.state_hmask = nhashmask;&#xA;&#xA;While state lookup does:&#xA;  h = xfrm_dst_hash(net, daddr, saddr, tmpl-&gt;reqid, encap_family);&#xA;  hlist_for_each_entry_rcu(x, net-&gt;xfrm.state_bydst + h, bydst) {&#xA;&#xA;This is only safe in case the update to state_bydst is larger than&#xA;net-&gt;xfrm.xfrm_state_hmask (or if the lookup function gets&#xA;serialized via state spinlock again).&#xA;&#xA;Fix this by prefetching state_hmask and the associated pointers.&#xA;The xfrm_state_hash_generation seqlock retry will ensure that the pointer&#xA;and the hmask will be consistent.&#xA;&#xA;The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,&#xA;add lockdep assertions to document that they are only safe for insert&#xA;side.&#xA;&#xA;xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.&#xA;AFAICS this is an oversight from back when state lookup was converted to&#xA;RCU, this lock should be replaced with RCU in a future patch.&#xA;CVE-2025-37780:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;isofs: Prevent the use of too small fid&#xA;&#xA;syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]&#xA;&#xA;The handle_bytes value passed in by the reproducing program is equal to 12.&#xA;In handle_to_path(), only 12 bytes of memory are allocated for the structure&#xA;file_handle-&gt;f_handle member, which causes an out-of-bounds access when&#xA;accessing the member parent_block of the structure isofs_fid in isofs,&#xA;because accessing parent_block requires at least 16 bytes of f_handle.&#xA;Here, fh_len is used to indirectly confirm that the value of handle_bytes&#xA;is greater than 3 before accessing parent_block.&#xA;&#xA;[1]&#xA;BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183&#xA;Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466&#xA;CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025&#xA;Call trace:&#xA; show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:408 [inline]&#xA; print_report+0x198/0x550 mm/kasan/report.c:521&#xA; kasan_report+0xd8/0x138 mm/kasan/report.c:634&#xA; __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380&#xA; isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183&#xA; exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523&#xA; do_handle_to_path+0xa0/0x198 fs/fhandle.c:257&#xA; handle_to_path fs/fhandle.c:385 [inline]&#xA; do_handle_open+0x8cc/0xb8c fs/fhandle.c:403&#xA; __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]&#xA; __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]&#xA; __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434&#xA; __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]&#xA; invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49&#xA; el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132&#xA; do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151&#xA; el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744&#xA; el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762&#xA; el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600&#xA;&#xA;Allocated by task 6466:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x40/0x78 mm/kasan/common.c:68&#xA; kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562&#xA; poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA; __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394&#xA; kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA; __do_kmalloc_node mm/slub.c:4294 [inline]&#xA; __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306&#xA; kmalloc_noprof include/linux/slab.h:905 [inline]&#xA; handle_to_path fs/fhandle.c:357 [inline]&#xA; do_handle_open+0x5a4/0xb8c fs/fhandle.c:403&#xA; __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]&#xA; __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]&#xA; __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434&#xA; __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]&#xA; invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49&#xA; el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132&#xA; do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151&#xA; el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744&#xA; el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762&#xA; el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600&#xA;CVE-2024-58069:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read&#xA;&#xA;The nvmem interface supports variable buffer sizes, while the regmap&#xA;interface operates with fixed-size storage. If an nvmem client uses a&#xA;buffer size less than 4 bytes, regmap_read will write out of bounds&#xA;as it expects the buffer to point at an unsigned int.&#xA;&#xA;Fix this by using an intermediary unsigned int to hold the value.&#xA;CVE-2025-22075:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rtnetlink: Allocate vfinfo size for VF GUIDs when supported&#xA;&#xA;Commit 30aad41721e0 (&#34;net/core: Add support for getting VF GUIDs&#34;)&#xA;added support for getting VF port and node GUIDs in netlink ifinfo&#xA;messages, but their size was not taken into consideration in the&#xA;function that allocates the netlink message, causing the following&#xA;warning when a netlink message is filled with many VF port and node&#xA;GUIDs:&#xA; # echo 64 &gt; /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs&#xA; # ip link show dev ib0&#xA; RTNETLINK answers: Message too long&#xA; Cannot send link get request: Message too long&#xA;&#xA;Kernel warning:&#xA;&#xA; ------------[ cut here ]------------&#xA; WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0&#xA; Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core&#xA; CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA; RIP: 0010:rtnl_getlink+0x586/0x5a0&#xA; Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff &lt;0f&gt; 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00&#xA; RSP: 0018:ffff888113557348 EFLAGS: 00010246&#xA; RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000&#xA; RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8&#xA; RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000&#xA; R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00&#xA; R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff&#xA; FS:  00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; PKRU: 55555554&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? __warn+0xa5/0x230&#xA;  ? rtnl_getlink+0x586/0x5a0&#xA;  ? report_bug+0x22d/0x240&#xA;  ? handle_bug+0x53/0xa0&#xA;  ? exc_invalid_op+0x14/0x50&#xA;  ? asm_exc_invalid_op+0x16/0x20&#xA;  ? skb_trim+0x6a/0x80&#xA;  ? rtnl_getlink+0x586/0x5a0&#xA;  ? __pfx_rtnl_getlink+0x10/0x10&#xA;  ? rtnetlink_rcv_msg+0x1e5/0x860&#xA;  ? __pfx___mutex_lock+0x10/0x10&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ? __pfx_lock_acquire+0x10/0x10&#xA;  ? stack_trace_save+0x90/0xd0&#xA;  ? filter_irq_stacks+0x1d/0x70&#xA;  ? kasan_save_stack+0x30/0x40&#xA;  ? kasan_save_stack+0x20/0x40&#xA;  ? kasan_save_track+0x10/0x30&#xA;  rtnetlink_rcv_msg+0x21c/0x860&#xA;  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;  ? __pfx_rtnetlink_rcv_msg+0x10/0x10&#xA;  ? arch_stack_walk+0x9e/0xf0&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ? lock_acquire+0xd5/0x410&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  netlink_rcv_skb+0xe0/0x210&#xA;  ? __pfx_rtnetlink_rcv_msg+0x10/0x10&#xA;  ? __pfx_netlink_rcv_skb+0x10/0x10&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ? __pfx___netlink_lookup+0x10/0x10&#xA;  ? lock_release+0x62/0x200&#xA;  ? netlink_deliver_tap+0xfd/0x290&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ? lock_release+0x62/0x200&#xA;  ? netlink_deliver_tap+0x95/0x290&#xA;  netlink_unicast+0x31f/0x480&#xA;  ? __pfx_netlink_unicast+0x10/0x10&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ? lock_acquire+0xd5/0x410&#xA;  netlink_sendmsg+0x369/0x660&#xA;  ? lock_release+0x62/0x200&#xA;  ? __pfx_netlink_sendmsg+0x10/0x10&#xA;  ? import_ubuf+0xb9/0xf0&#xA;  ? __import_iovec+0x254/0x2b0&#xA;  ? lock_release+0x62/0x200&#xA;  ? __pfx_netlink_sendmsg+0x10/0x10&#xA;  ____sys_sendmsg+0x559/0x5a0&#xA;  ? __pfx_____sys_sendmsg+0x10/0x10&#xA;  ? __pfx_copy_msghdr_from_user+0x10/0x10&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ? do_read_fault+0x213/0x4a0&#xA;  ? rcu_is_watching+0x34/0x60&#xA;  ___sys_sendmsg+0xe4/0x150&#xA;  ? __pfx____sys_sendmsg+0x10/0x10&#xA;  ? do_fault+0x2cc/0x6f0&#xA;  ? handle_pte_fault+0x2e3/0x3d0&#xA;  ? __pfx_handle_pte_fault+0x10/0x10&#xA;---truncated---&#xA;CVE-2025-37797:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: hfsc: Fix a UAF vulnerability in class handling&#xA;&#xA;This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class&#xA;handling. The issue occurs due to a time-of-check/time-of-use condition&#xA;in hfsc_change_class() when working with certain child qdiscs like netem&#xA;or codel.&#xA;&#xA;The vulnerability works as follows:&#xA;1. hfsc_change_class() checks if a class has packets (q.qlen != 0)&#xA;2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,&#xA;   codel, netem) might drop packets and empty the queue&#xA;3. The code continues assuming the queue is still non-empty, adding&#xA;   the class to vttree&#xA;4. This breaks HFSC scheduler assumptions that only non-empty classes&#xA;   are in vttree&#xA;5. Later, when the class is destroyed, this can lead to a Use-After-Free&#xA;&#xA;The fix adds a second queue length check after qdisc_peek_len() to verify&#xA;the queue wasn&#39;t emptied.&#xA;CVE-2025-38184:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer&#xA;&#xA;The reproduction steps:&#xA;1. create a tun interface&#xA;2. enable l2 bearer&#xA;3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun&#xA;&#xA;tipc: Started in network mode&#xA;tipc: Node identity 8af312d38a21, cluster identity 4711&#xA;tipc: Enabled bearer &lt;eth:syz_tun&gt;, priority 1&#xA;Oops: general protection fault&#xA;KASAN: null-ptr-deref in range&#xA;CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT&#xA;Hardware name: QEMU Ubuntu 24.04 PC&#xA;RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0&#xA;&#xA;the ub was in fact a struct dev.&#xA;&#xA;when bid != 0 &amp;&amp; skip_cnt != 0, bearer_list[bid] may be NULL or&#xA;other media when other thread changes it.&#xA;&#xA;fix this by checking media_id.&#xA;CVE-2025-38052:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done&#xA;&#xA;Syzbot reported a slab-use-after-free with the following call trace:&#xA;&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840&#xA;  Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25&#xA;&#xA;  Call Trace:&#xA;   kasan_report+0xd9/0x110 mm/kasan/report.c:601&#xA;   tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840&#xA;   crypto_request_complete include/crypto/algapi.h:266&#xA;   aead_request_complete include/crypto/internal/aead.h:85&#xA;   cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772&#xA;   crypto_request_complete include/crypto/algapi.h:266&#xA;   cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181&#xA;   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231&#xA;&#xA;  Allocated by task 8355:&#xA;   kzalloc_noprof include/linux/slab.h:778&#xA;   tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466&#xA;   tipc_init_net+0x2dd/0x430 net/tipc/core.c:72&#xA;   ops_init+0xb9/0x650 net/core/net_namespace.c:139&#xA;   setup_net+0x435/0xb40 net/core/net_namespace.c:343&#xA;   copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508&#xA;   create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110&#xA;   unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228&#xA;   ksys_unshare+0x419/0x970 kernel/fork.c:3323&#xA;   __do_sys_unshare kernel/fork.c:3394&#xA;&#xA;  Freed by task 63:&#xA;   kfree+0x12a/0x3b0 mm/slub.c:4557&#xA;   tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539&#xA;   tipc_exit_net+0x8c/0x110 net/tipc/core.c:119&#xA;   ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173&#xA;   cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640&#xA;   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231&#xA;&#xA;After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done&#xA;may still visit it in cryptd_queue_worker workqueue.&#xA;&#xA;I reproduce this issue by:&#xA;  ip netns add ns1&#xA;  ip link add veth1 type veth peer name veth2&#xA;  ip link set veth1 netns ns1&#xA;  ip netns exec ns1 tipc bearer enable media eth dev veth1&#xA;  ip netns exec ns1 tipc node set key this_is_a_master_key master&#xA;  ip netns exec ns1 tipc bearer disable media eth dev veth1&#xA;  ip netns del ns1&#xA;&#xA;The key of reproduction is that, simd_aead_encrypt is interrupted, leading&#xA;to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is&#xA;triggered, and the tipc_crypto tx will be visited.&#xA;&#xA;  tipc_disc_timeout&#xA;    tipc_bearer_xmit_skb&#xA;      tipc_crypto_xmit&#xA;        tipc_aead_encrypt&#xA;          crypto_aead_encrypt&#xA;            // encrypt()&#xA;            simd_aead_encrypt&#xA;              // crypto_simd_usable() is false&#xA;              child = &amp;ctx-&gt;cryptd_tfm-&gt;base;&#xA;&#xA;  simd_aead_encrypt&#xA;    crypto_aead_encrypt&#xA;      // encrypt()&#xA;      cryptd_aead_encrypt_enqueue&#xA;        cryptd_aead_enqueue&#xA;          cryptd_enqueue_request&#xA;            // trigger cryptd_queue_worker&#xA;            queue_work_on(smp_processor_id(), cryptd_wq, &amp;cpu_queue-&gt;work)&#xA;&#xA;Fix this by holding net reference count before encrypt.&#xA;CVE-2025-38464:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tipc: Fix use-after-free in tipc_conn_close().&#xA;&#xA;syzbot reported a null-ptr-deref in tipc_conn_close() during netns&#xA;dismantle. [0]&#xA;&#xA;tipc_topsrv_stop() iterates tipc_net(net)-&gt;topsrv-&gt;conn_idr and calls&#xA;tipc_conn_close() for each tipc_conn.&#xA;&#xA;The problem is that tipc_conn_close() is called after releasing the&#xA;IDR lock.&#xA;&#xA;At the same time, there might be tipc_conn_recv_work() running and it&#xA;could call tipc_conn_close() for the same tipc_conn and release its&#xA;last -&gt;kref.&#xA;&#xA;Once we release the IDR lock in tipc_topsrv_stop(), there is no&#xA;guarantee that the tipc_conn is alive.&#xA;&#xA;Let&#39;s hold the ref before releasing the lock and put the ref after&#xA;tipc_conn_close() in tipc_topsrv_stop().&#xA;&#xA;[0]:&#xA;BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165&#xA;Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435&#xA;&#xA;CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011&#xA;Workqueue: netns cleanup_net&#xA;Call Trace:&#xA; __dump_stack lib/dump_stack.c:77 [inline]&#xA; dump_stack+0x1fc/0x2ef lib/dump_stack.c:118&#xA; print_address_description.cold+0x54/0x219 mm/kasan/report.c:256&#xA; kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354&#xA; kasan_report mm/kasan/report.c:412 [inline]&#xA; __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433&#xA; tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165&#xA; tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]&#xA; tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722&#xA; ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153&#xA; cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553&#xA; process_one_work+0x864/0x1570 kernel/workqueue.c:2153&#xA; worker_thread+0x64c/0x1130 kernel/workqueue.c:2296&#xA; kthread+0x33f/0x460 kernel/kthread.c:259&#xA; ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415&#xA;&#xA;Allocated by task 23:&#xA; kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625&#xA; kmalloc include/linux/slab.h:515 [inline]&#xA; kzalloc include/linux/slab.h:709 [inline]&#xA; tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192&#xA; tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470&#xA; process_one_work+0x864/0x1570 kernel/workqueue.c:2153&#xA; worker_thread+0x64c/0x1130 kernel/workqueue.c:2296&#xA; kthread+0x33f/0x460 kernel/kthread.c:259&#xA; ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415&#xA;&#xA;Freed by task 23:&#xA; __cache_free mm/slab.c:3503 [inline]&#xA; kfree+0xcc/0x210 mm/slab.c:3822&#xA; tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]&#xA; kref_put include/linux/kref.h:70 [inline]&#xA; conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155&#xA; process_one_work+0x864/0x1570 kernel/workqueue.c:2153&#xA; worker_thread+0x64c/0x1130 kernel/workqueue.c:2296&#xA; kthread+0x33f/0x460 kernel/kthread.c:259&#xA; ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415&#xA;&#xA;The buggy address belongs to the object at ffff888099305a00&#xA; which belongs to the cache kmalloc-512 of size 512&#xA;The buggy address is located 8 bytes inside of&#xA; 512-byte region [ffff888099305a00, ffff888099305c00)&#xA;The buggy address belongs to the page:&#xA;page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0&#xA;flags: 0xfff00000000100(slab)&#xA;raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940&#xA;raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;&#xA;Memory state around the buggy address:&#xA; ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA; ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;&gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;                      ^&#xA; ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA; ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;CVE-2025-38192:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: clear the dst when changing skb protocol&#xA;&#xA;A not-so-careful NAT46 BPF program can crash the kernel&#xA;if it indiscriminately flips ingress packets from v4 to v6:&#xA;&#xA;  BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;    ip6_rcv_core (net/ipv6/ip6_input.c:190:20)&#xA;    ipv6_rcv (net/ipv6/ip6_input.c:306:8)&#xA;    process_backlog (net/core/dev.c:6186:4)&#xA;    napi_poll (net/core/dev.c:6906:9)&#xA;    net_rx_action (net/core/dev.c:7028:13)&#xA;    do_softirq (kernel/softirq.c:462:3)&#xA;    netif_rx (net/core/dev.c:5326:3)&#xA;    dev_loopback_xmit (net/core/dev.c:4015:2)&#xA;    ip_mc_finish_output (net/ipv4/ip_output.c:363:8)&#xA;    NF_HOOK (./include/linux/netfilter.h:314:9)&#xA;    ip_mc_output (net/ipv4/ip_output.c:400:5)&#xA;    dst_output (./include/net/dst.h:459:9)&#xA;    ip_local_out (net/ipv4/ip_output.c:130:9)&#xA;    ip_send_skb (net/ipv4/ip_output.c:1496:8)&#xA;    udp_send_skb (net/ipv4/udp.c:1040:8)&#xA;    udp_sendmsg (net/ipv4/udp.c:1328:10)&#xA;&#xA;The output interface has a 4-&gt;6 program attached at ingress.&#xA;We try to loop the multicast skb back to the sending socket.&#xA;Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr&#xA;and changes skb-&gt;protocol to v6. We enter ip6_rcv_core which&#xA;tries to use skb_dst(). But the dst is still an IPv4 one left&#xA;after IPv4 mcast output.&#xA;&#xA;Clear the dst in all BPF helpers which change the protocol.&#xA;Try to preserve metadata dsts, those may carry non-routing&#xA;metadata.&#xA;CVE-2025-38115:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: sch_sfq: fix a potential crash on gso_skb handling&#xA;&#xA;SFQ has an assumption of always being able to queue at least one packet.&#xA;&#xA;However, after the blamed commit, sch-&gt;q.len can be inflated by packets&#xA;in sch-&gt;gso_skb, and an enqueue() on an empty SFQ qdisc can be followed&#xA;by an immediate drop.&#xA;&#xA;Fix sfq_drop() to properly clear q-&gt;tail in this situation.&#xA;&#xA;&#xA;ip netns add lb&#xA;ip link add dev to-lb type veth peer name in-lb netns lb&#xA;ethtool -K to-lb tso off                 # force qdisc to requeue gso_skb&#xA;ip netns exec lb ethtool -K in-lb gro on # enable NAPI&#xA;ip link set dev to-lb up&#xA;ip -netns lb link set dev in-lb up&#xA;ip addr add dev to-lb 192.168.20.1/24&#xA;ip -netns lb addr add dev in-lb 192.168.20.2/24&#xA;tc qdisc replace dev to-lb root sfq limit 100&#xA;&#xA;ip netns exec lb netserver&#xA;&#xA;netperf -H 192.168.20.2 -l 100 &amp;&#xA;netperf -H 192.168.20.2 -l 100 &amp;&#xA;netperf -H 192.168.20.2 -l 100 &amp;&#xA;netperf -H 192.168.20.2 -l 100 &amp;&#xA;CVE-2025-38124:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: fix udp gso skb_segment after pull from frag_list&#xA;&#xA;Commit a1e40ac5b5e9 (&#34;net: gso: fix udp gso fraglist segmentation after&#xA;pull from frag_list&#34;) detected invalid geometry in frag_list skbs and&#xA;redirects them from skb_segment_list to more robust skb_segment. But some&#xA;packets with modified geometry can also hit bugs in that code. We don&#39;t&#xA;know how many such cases exist. Addressing each one by one also requires&#xA;touching the complex skb_segment code, which risks introducing bugs for&#xA;other types of skbs. Instead, linearize all these packets that fail the&#xA;basic invariants on gso fraglist skbs. That is more robust.&#xA;&#xA;If only part of the fraglist payload is pulled into head_skb, it will&#xA;always cause exception when splitting skbs by skb_segment. For detailed&#xA;call stack information, see below.&#xA;&#xA;Valid SKB_GSO_FRAGLIST skbs&#xA;- consist of two or more segments&#xA;- the head_skb holds the protocol headers plus first gso_size&#xA;- one or more frag_list skbs hold exactly one segment&#xA;- all but the last must be gso_size&#xA;&#xA;Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can&#xA;modify fraglist skbs, breaking these invariants.&#xA;&#xA;In extreme cases they pull one part of data into skb linear. For UDP,&#xA;this  causes three payloads with lengths of (11,11,10) bytes were&#xA;pulled tail to become (12,10,10) bytes.&#xA;&#xA;The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because&#xA;payload was pulled into head_skb, it needs to be linearized before pass&#xA;to regular skb_segment.&#xA;&#xA;    skb_segment+0xcd0/0xd14&#xA;    __udp_gso_segment+0x334/0x5f4&#xA;    udp4_ufo_fragment+0x118/0x15c&#xA;    inet_gso_segment+0x164/0x338&#xA;    skb_mac_gso_segment+0xc4/0x13c&#xA;    __skb_gso_segment+0xc4/0x124&#xA;    validate_xmit_skb+0x9c/0x2c0&#xA;    validate_xmit_skb_list+0x4c/0x80&#xA;    sch_direct_xmit+0x70/0x404&#xA;    __dev_queue_xmit+0x64c/0xe5c&#xA;    neigh_resolve_output+0x178/0x1c4&#xA;    ip_finish_output2+0x37c/0x47c&#xA;    __ip_finish_output+0x194/0x240&#xA;    ip_finish_output+0x20/0xf4&#xA;    ip_output+0x100/0x1a0&#xA;    NF_HOOK+0xc4/0x16c&#xA;    ip_forward+0x314/0x32c&#xA;    ip_rcv+0x90/0x118&#xA;    __netif_receive_skb+0x74/0x124&#xA;    process_backlog+0xe8/0x1a4&#xA;    __napi_poll+0x5c/0x1f8&#xA;    net_rx_action+0x154/0x314&#xA;    handle_softirqs+0x154/0x4b8&#xA;&#xA;    [118.376811] [C201134] rxq0_pus: [name:bug&amp;]kernel BUG at net/core/skbuff.c:4278!&#xA;    [118.376829] [C201134] rxq0_pus: [name:traps&amp;]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP&#xA;    [118.470774] [C201134] rxq0_pus: [name:mrdump&amp;]Kernel Offset: 0x178cc00000 from 0xffffffc008000000&#xA;    [118.470810] [C201134] rxq0_pus: [name:mrdump&amp;]PHYS_OFFSET: 0x40000000&#xA;    [118.470827] [C201134] rxq0_pus: [name:mrdump&amp;]pstate: 60400005 (nZCv daif +PAN -UAO)&#xA;    [118.470848] [C201134] rxq0_pus: [name:mrdump&amp;]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14&#xA;    [118.470900] [C201134] rxq0_pus: [name:mrdump&amp;]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14&#xA;    [118.470928] [C201134] rxq0_pus: [name:mrdump&amp;]sp : ffffffc008013770&#xA;CVE-2025-22018:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: Fix NULL pointer dereference&#xA;&#xA;When MPOA_cache_impos_rcvd() receives the msg, it can trigger&#xA;Null Pointer Dereference Vulnerability if both entry and&#xA;holding_time are NULL. Because there is only for the situation&#xA;where entry is NULL and holding_time exists, it can be passed&#xA;when both entry and holding_time are NULL. If these are NULL,&#xA;the entry will be passd to eg_cache_put() as parameter and&#xA;it is referenced by entry-&gt;use code in it.&#xA;&#xA;kasan log:&#xA;&#xA;[    3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I&#xA;[    3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]&#xA;[    3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102&#xA;[    3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;[    3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470&#xA;[    3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80&#xA;[    3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006&#xA;[    3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e&#xA;[    3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030&#xA;[    3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88&#xA;[    3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15&#xA;[    3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068&#xA;[    3.324185] FS:  000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000&#xA;[    3.325042] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[    3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0&#xA;[    3.326430] Call Trace:&#xA;[    3.326725]  &lt;TASK&gt;&#xA;[    3.326927]  ? die_addr+0x3c/0xa0&#xA;[    3.327330]  ? exc_general_protection+0x161/0x2a0&#xA;[    3.327662]  ? asm_exc_general_protection+0x26/0x30&#xA;[    3.328214]  ? vprintk_emit+0x15e/0x420&#xA;[    3.328543]  ? eg_cache_remove_entry+0xa5/0x470&#xA;[    3.328910]  ? eg_cache_remove_entry+0x9a/0x470&#xA;[    3.329294]  ? __pfx_eg_cache_remove_entry+0x10/0x10&#xA;[    3.329664]  ? console_unlock+0x107/0x1d0&#xA;[    3.329946]  ? __pfx_console_unlock+0x10/0x10&#xA;[    3.330283]  ? do_syscall_64+0xa6/0x1a0&#xA;[    3.330584]  ? entry_SYSCALL_64_after_hwframe+0x47/0x7f&#xA;[    3.331090]  ? __pfx_prb_read_valid+0x10/0x10&#xA;[    3.331395]  ? down_trylock+0x52/0x80&#xA;[    3.331703]  ? vprintk_emit+0x15e/0x420&#xA;[    3.331986]  ? __pfx_vprintk_emit+0x10/0x10&#xA;[    3.332279]  ? down_trylock+0x52/0x80&#xA;[    3.332527]  ? _printk+0xbf/0x100&#xA;[    3.332762]  ? __pfx__printk+0x10/0x10&#xA;[    3.333007]  ? _raw_write_lock_irq+0x81/0xe0&#xA;[    3.333284]  ? __pfx__raw_write_lock_irq+0x10/0x10&#xA;[    3.333614]  msg_from_mpoad+0x1185/0x2750&#xA;[    3.333893]  ? __build_skb_around+0x27b/0x3a0&#xA;[    3.334183]  ? __pfx_msg_from_mpoad+0x10/0x10&#xA;[    3.334501]  ? __alloc_skb+0x1c0/0x310&#xA;[    3.334809]  ? __pfx___alloc_skb+0x10/0x10&#xA;[    3.335283]  ? _raw_spin_lock+0xe0/0xe0&#xA;[    3.335632]  ? finish_wait+0x8d/0x1e0&#xA;[    3.335975]  vcc_sendmsg+0x684/0xba0&#xA;[    3.336250]  ? __pfx_vcc_sendmsg+0x10/0x10&#xA;[    3.336587]  ? __pfx_autoremove_wake_function+0x10/0x10&#xA;[    3.337056]  ? fdget+0x176/0x3e0&#xA;[    3.337348]  __sys_sendto+0x4a2/0x510&#xA;[    3.337663]  ? __pfx___sys_sendto+0x10/0x10&#xA;[    3.337969]  ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400&#xA;[    3.338364]  ? sock_ioctl+0x1bb/0x5a0&#xA;[    3.338653]  ? __rseq_handle_notify_resume+0x825/0xd20&#xA;[    3.339017]  ? __pfx_sock_ioctl+0x10/0x10&#xA;[    3.339316]  ? __pfx___rseq_handle_notify_resume+0x10/0x10&#xA;[    3.339727]  ? selinux_file_ioctl+0xa4/0x260&#xA;[    3.340166]  __x64_sys_sendto+0xe0/0x1c0&#xA;[    3.340526]  ? syscall_exit_to_user_mode+0x123/0x140&#xA;[    3.340898]  do_syscall_64+0xa6/0x1a0&#xA;[    3.341170]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[    3.341533] RIP: 0033:0x44a380&#xA;[    3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00&#xA;[    &#xA;---truncated---&#xA;CVE-2025-22058:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;udp: Fix memory accounting leak.&#xA;&#xA;Matt Dowling reported a weird UDP memory usage issue.&#xA;&#xA;Under normal operation, the UDP memory usage reported in /proc/net/sockstat&#xA;remains close to zero.  However, it occasionally spiked to 524,288 pages&#xA;and never dropped.  Moreover, the value doubled when the application was&#xA;terminated.  Finally, it caused intermittent packet drops.&#xA;&#xA;We can reproduce the issue with the script below [0]:&#xA;&#xA;  1. /proc/net/sockstat reports 0 pages&#xA;&#xA;    # cat /proc/net/sockstat | grep UDP:&#xA;    UDP: inuse 1 mem 0&#xA;&#xA;  2. Run the script till the report reaches 524,288&#xA;&#xA;    # python3 test.py &amp; sleep 5&#xA;    # cat /proc/net/sockstat | grep UDP:&#xA;    UDP: inuse 3 mem 524288  &lt;-- (INT_MAX + 1) &gt;&gt; PAGE_SHIFT&#xA;&#xA;  3. Kill the socket and confirm the number never drops&#xA;&#xA;    # pkill python3 &amp;&amp; sleep 5&#xA;    # cat /proc/net/sockstat | grep UDP:&#xA;    UDP: inuse 1 mem 524288&#xA;&#xA;  4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()&#xA;&#xA;    # python3 test.py &amp; sleep 1 &amp;&amp; pkill python3&#xA;&#xA;  5. The number doubles&#xA;&#xA;    # cat /proc/net/sockstat | grep UDP:&#xA;    UDP: inuse 1 mem 1048577&#xA;&#xA;The application set INT_MAX to SO_RCVBUF, which triggered an integer&#xA;overflow in udp_rmem_release().&#xA;&#xA;When a socket is close()d, udp_destruct_common() purges its receive&#xA;queue and sums up skb-&gt;truesize in the queue.  This total is calculated&#xA;and stored in a local unsigned integer variable.&#xA;&#xA;The total size is then passed to udp_rmem_release() to adjust memory&#xA;accounting.  However, because the function takes a signed integer&#xA;argument, the total size can wrap around, causing an overflow.&#xA;&#xA;Then, the released amount is calculated as follows:&#xA;&#xA;  1) Add size to sk-&gt;sk_forward_alloc.&#xA;  2) Round down sk-&gt;sk_forward_alloc to the nearest lower multiple of&#xA;      PAGE_SIZE and assign it to amount.&#xA;  3) Subtract amount from sk-&gt;sk_forward_alloc.&#xA;  4) Pass amount &gt;&gt; PAGE_SHIFT to __sk_mem_reduce_allocated().&#xA;&#xA;When the issue occurred, the total in udp_destruct_common() was 2147484480&#xA;(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().&#xA;&#xA;At 1) sk-&gt;sk_forward_alloc is changed from 3264 to -2147479552, and&#xA;2) sets -2147479552 to amount.  3) reverts the wraparound, so we don&#39;t&#xA;see a warning in inet_sock_destruct().  However, udp_memory_allocated&#xA;ends up doubling at 4).&#xA;&#xA;Since commit 3cd3399dd7a8 (&#34;net: implement per-cpu reserves for&#xA;memory_allocated&#34;), memory usage no longer doubles immediately after&#xA;a socket is close()d because __sk_mem_reduce_allocated() caches the&#xA;amount in udp_memory_per_cpu_fw_alloc.  However, the next time a UDP&#xA;socket receives a packet, the subtraction takes effect, causing UDP&#xA;memory usage to double.&#xA;&#xA;This issue makes further memory allocation fail once the socket&#39;s&#xA;sk-&gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet&#xA;drops.&#xA;&#xA;To prevent this issue, let&#39;s use unsigned int for the calculation and&#xA;call sk_forward_alloc_add() only once for the small delta.&#xA;&#xA;Note that first_packet_length() also potentially has the same problem.&#xA;&#xA;[0]:&#xA;from socket import *&#xA;&#xA;SO_RCVBUFFORCE = 33&#xA;INT_MAX = (2 ** 31) - 1&#xA;&#xA;s = socket(AF_INET, SOCK_DGRAM)&#xA;s.bind((&#39;&#39;, 0))&#xA;s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)&#xA;&#xA;c = socket(AF_INET, SOCK_DGRAM)&#xA;c.connect(s.getsockname())&#xA;&#xA;data = b&#39;a&#39; * 100&#xA;&#xA;while True:&#xA;    c.send(data)&#xA;CVE-2022-49390:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;macsec: fix UAF bug for real_dev&#xA;&#xA;Create a new macsec device but not get reference to real_dev. That can&#xA;not ensure that real_dev is freed after macsec. That will trigger the&#xA;UAF bug for real_dev as following:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662&#xA;Call Trace:&#xA; ...&#xA; macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662&#xA; dev_get_iflink+0x73/0xe0 net/core/dev.c:637&#xA; default_operstate net/core/link_watch.c:42 [inline]&#xA; rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54&#xA; linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161&#xA;&#xA;Allocated by task 22209:&#xA; ...&#xA; alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549&#xA; rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235&#xA; veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748&#xA;&#xA;Freed by task 8:&#xA; ...&#xA; kfree+0xd6/0x4d0 mm/slub.c:4552&#xA; kvfree+0x42/0x50 mm/util.c:615&#xA; device_release+0x9f/0x240 drivers/base/core.c:2229&#xA; kobject_cleanup lib/kobject.c:673 [inline]&#xA; kobject_release lib/kobject.c:704 [inline]&#xA; kref_put include/linux/kref.h:65 [inline]&#xA; kobject_put+0x1c8/0x540 lib/kobject.c:721&#xA; netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327&#xA;&#xA;After commit faab39f63c1f (&#34;net: allow out-of-order netdev unregistration&#34;)&#xA;and commit e5f80fcf869a (&#34;ipv6: give an IPv6 dev to blackhole_netdev&#34;), we&#xA;can add dev_hold_track() in macsec_dev_init() and dev_put_track() in&#xA;macsec_free_netdev() to fix the problem.&#xA;CVE-2025-21687:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vfio/platform: check the bounds of read/write syscalls&#xA;&#xA;count and offset are passed from user space and not checked, only&#xA;offset is capped to 40 bits, which can be used to read/write out of&#xA;bounds of the device.&#xA;CVE-2025-37992:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: Flush gso_skb list too during -&gt;change()&#xA;&#xA;Previously, when reducing a qdisc&#39;s limit via the -&gt;change() operation, only&#xA;the main skb queue was trimmed, potentially leaving packets in the gso_skb&#xA;list. This could result in NULL pointer dereference when we only check&#xA;sch-&gt;limit against sch-&gt;q.qlen.&#xA;&#xA;This patch introduces a new helper, qdisc_dequeue_internal(), which ensures&#xA;both the gso_skb list and the main queue are properly flushed when trimming&#xA;excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)&#xA;are updated to use this helper in their -&gt;change() routines.&#xA;CVE-2025-37890:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc&#xA;&#xA;As described in Gerrard&#39;s report [1], we have a UAF case when an hfsc class&#xA;has a netem child qdisc. The crux of the issue is that hfsc is assuming&#xA;that checking for cl-&gt;qdisc-&gt;q.qlen == 0 guarantees that it hasn&#39;t inserted&#xA;the class in the vttree or eltree (which is not true for the netem&#xA;duplicate case).&#xA;&#xA;This patch checks the n_active class variable to make sure that the code&#xA;won&#39;t insert the class in the vttree or eltree twice, catering for the&#xA;reentrant case.&#xA;&#xA;[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/&#xA;CVE-2025-38539:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Add down_write(trace_event_sem) when adding trace event&#xA;&#xA;When a module is loaded, it adds trace events defined by the module. It&#xA;may also need to modify the modules trace printk formats to replace enum&#xA;names with their values.&#xA;&#xA;If two modules are loaded at the same time, the adding of the event to the&#xA;ftrace_events list can corrupt the walking of the list in the code that is&#xA;modifying the printk format strings and crash the kernel.&#xA;&#xA;The addition of the event should take the trace_event_sem for write while&#xA;it adds the new event.&#xA;&#xA;Also add a lockdep_assert_held() on that semaphore in&#xA;__trace_add_event_dirs() as it iterates the list.&#xA;CVE-2024-57906:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: adc: ti-ads8688: fix information leak in triggered buffer&#xA;&#xA;The &#39;buffer&#39; local array is used to push data to user space from a&#xA;triggered buffer, but it does not set values for inactive channels, as&#xA;it only uses iio_for_each_active_channel() to assign new values.&#xA;&#xA;Initialize the array to zero before using it to avoid pushing&#xA;uninitialized information to userspace.&#xA;CVE-2024-56678:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powerpc/mm/fault: Fix kfence page fault reporting&#xA;&#xA;copy_from_kernel_nofault() can be called when doing read of /proc/kcore.&#xA;/proc/kcore can have some unmapped kfence objects which when read via&#xA;copy_from_kernel_nofault() can cause page faults. Since *_nofault()&#xA;functions define their own fixup table for handling fault, use that&#xA;instead of asking kfence to handle such faults.&#xA;&#xA;Hence we search the exception tables for the nip which generated the&#xA;fault. If there is an entry then we let the fixup table handler handle the&#xA;page fault by returning an error from within ___do_page_fault().&#xA;&#xA;This can be easily triggered if someone tries to do dd from /proc/kcore.&#xA;eg. dd if=/proc/kcore of=/dev/null bs=1M&#xA;&#xA;Some example false negatives:&#xA;&#xA;  ===============================&#xA;  BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0&#xA;  Invalid read at 0xc0000000fdff0000:&#xA;   copy_from_kernel_nofault+0x9c/0x1a0&#xA;   0xc00000000665f950&#xA;   read_kcore_iter+0x57c/0xa04&#xA;   proc_reg_read_iter+0xe4/0x16c&#xA;   vfs_read+0x320/0x3ec&#xA;   ksys_read+0x90/0x154&#xA;   system_call_exception+0x120/0x310&#xA;   system_call_vectored_common+0x15c/0x2ec&#xA;&#xA;  BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0&#xA;  Use-after-free read at 0xc0000000fe050000 (in kfence-#2):&#xA;   copy_from_kernel_nofault+0x9c/0x1a0&#xA;   0xc00000000665f950&#xA;   read_kcore_iter+0x57c/0xa04&#xA;   proc_reg_read_iter+0xe4/0x16c&#xA;   vfs_read+0x320/0x3ec&#xA;   ksys_read+0x90/0x154&#xA;   system_call_exception+0x120/0x310&#xA;   system_call_vectored_common+0x15c/0x2ec&#xA;CVE-2025-38001:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: hfsc: Address reentrant enqueue adding class to eltree twice&#xA;&#xA;Savino says:&#xA;    &#34;We are writing to report that this recent patch&#xA;    (141d34391abbb315d68556b7c67ad97885407547) [1]&#xA;    can be bypassed, and a UAF can still occur when HFSC is utilized with&#xA;    NETEM.&#xA;&#xA;    The patch only checks the cl-&gt;cl_nactive field to determine whether&#xA;    it is the first insertion or not [2], but this field is only&#xA;    incremented by init_vf [3].&#xA;&#xA;    By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the&#xA;    check and insert the class twice in the eltree.&#xA;    Under normal conditions, this would lead to an infinite loop in&#xA;    hfsc_dequeue for the reasons we already explained in this report [5].&#xA;&#xA;    However, if TBF is added as root qdisc and it is configured with a&#xA;    very low rate,&#xA;    it can be utilized to prevent packets from being dequeued.&#xA;    This behavior can be exploited to perform subsequent insertions in the&#xA;    HFSC eltree and cause a UAF.&#34;&#xA;&#xA;To fix both the UAF and the infinite loop, with netem as an hfsc child,&#xA;check explicitly in hfsc_enqueue whether the class is already in the eltree&#xA;whenever the HFSC_RSC flag is set.&#xA;&#xA;[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547&#xA;[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572&#xA;[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677&#xA;[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574&#xA;[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u&#xA;CVE-2025-38000:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()&#xA;&#xA;When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the&#xA;child qdisc&#39;s peek() operation before incrementing sch-&gt;q.qlen and&#xA;sch-&gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may&#xA;trigger an immediate dequeue and potential packet drop. In such cases,&#xA;qdisc_tree_reduce_backlog() is called, but the HFSC qdisc&#39;s qlen and backlog&#xA;have not yet been updated, leading to inconsistent queue accounting. This&#xA;can leave an empty HFSC class in the active list, causing further&#xA;consequences like use-after-free.&#xA;&#xA;This patch fixes the bug by moving the increment of sch-&gt;q.qlen and&#xA;sch-&gt;qstats.backlog before the call to the child qdisc&#39;s peek() operation.&#xA;This ensures that queue length and backlog are always accurate when packet&#xA;drops or dequeues are triggered during the peek.&#xA;CVE-2024-53214:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vfio/pci: Properly hide first-in-list PCIe extended capability&#xA;&#xA;There are cases where a PCIe extended capability should be hidden from&#xA;the user. For example, an unknown capability (i.e., capability with ID&#xA;greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally&#xA;chosen to be hidden from the user.&#xA;&#xA;Hiding a capability is done by virtualizing and modifying the &#39;Next&#xA;Capability Offset&#39; field of the previous capability so it points to the&#xA;capability after the one that should be hidden.&#xA;&#xA;The special case where the first capability in the list should be hidden&#xA;is handled differently because there is no previous capability that can&#xA;be modified. In this case, the capability ID and version are zeroed&#xA;while leaving the next pointer intact. This hides the capability and&#xA;leaves an anchor for the rest of the capability list.&#xA;&#xA;However, today, hiding the first capability in the list is not done&#xA;properly if the capability is unknown, as struct&#xA;vfio_pci_core_device-&gt;pci_config_map is set to the capability ID during&#xA;initialization but the capability ID is not properly checked later when&#xA;used in vfio_config_do_rw(). This leads to the following warning [1] and&#xA;to an out-of-bounds access to ecap_perms array.&#xA;&#xA;Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater&#xA;than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct&#xA;read only access instead of the ecap_perms array.&#xA;&#xA;Note that this is safe since the above is the only case where cap_id can&#xA;exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which&#xA;are already checked before).&#xA;&#xA;[1]&#xA;&#xA;WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]&#xA;CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1&#xA;(snip)&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? show_regs+0x69/0x80&#xA; ? __warn+0x8d/0x140&#xA; ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]&#xA; ? report_bug+0x18f/0x1a0&#xA; ? handle_bug+0x63/0xa0&#xA; ? exc_invalid_op+0x19/0x70&#xA; ? asm_exc_invalid_op+0x1b/0x20&#xA; ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]&#xA; ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]&#xA; vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]&#xA; vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]&#xA; vfio_device_fops_read+0x27/0x40 [vfio]&#xA; vfs_read+0xbd/0x340&#xA; ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]&#xA; ? __rseq_handle_notify_resume+0xa4/0x4b0&#xA; __x64_sys_pread64+0x96/0xc0&#xA; x64_sys_call+0x1c3d/0x20d0&#xA; do_syscall_64+0x4d/0x120&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2025-39689:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ftrace: Also allocate and copy hash for reading of filter files&#xA;&#xA;Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds&#xA;the pointer to the global tracer hash to its iterator. Unlike the writer&#xA;that allocates a copy of the hash, the reader keeps the pointer to the&#xA;filter hashes. This is problematic because this pointer is static across&#xA;function calls that release the locks that can update the global tracer&#xA;hashes. This can cause UAF and similar bugs.&#xA;&#xA;Allocate and copy the hash for reading the filter files like it is done&#xA;for the writers. This not only fixes UAF bugs, but also makes the code a&#xA;bit simpler as it doesn&#39;t have to differentiate when to free the&#xA;iterator&#39;s hash between writers and readers.&#xA;CVE-2025-39813:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ftrace: Fix potential warning in trace_printk_seq during ftrace_dump&#xA;&#xA;When calling ftrace_dump_one() concurrently with reading trace_pipe,&#xA;a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race&#xA;condition.&#xA;&#xA;The issue occurs because:&#xA;&#xA;CPU0 (ftrace_dump)                              CPU1 (reader)&#xA;echo z &gt; /proc/sysrq-trigger&#xA;&#xA;!trace_empty(&amp;iter)&#xA;trace_iterator_reset(&amp;iter) &lt;- len = size = 0&#xA;                                                cat /sys/kernel/tracing/trace_pipe&#xA;trace_find_next_entry_inc(&amp;iter)&#xA;  __find_next_entry&#xA;    ring_buffer_empty_cpu &lt;- all empty&#xA;  return NULL&#xA;&#xA;trace_printk_seq(&amp;iter.seq)&#xA;  WARN_ON_ONCE(s-&gt;seq.len &gt;= s-&gt;seq.size)&#xA;&#xA;In the context between trace_empty() and trace_find_next_entry_inc()&#xA;during ftrace_dump, the ring buffer data was consumed by other readers.&#xA;This caused trace_find_next_entry_inc to return NULL, failing to populate&#xA;`iter.seq`. At this point, due to the prior trace_iterator_reset, both&#xA;`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,&#xA;the WARN_ON_ONCE condition is triggered.&#xA;&#xA;Move the trace_printk_seq() into the if block that checks to make sure the&#xA;return value of trace_find_next_entry_inc() is non-NULL in&#xA;ftrace_dump_one(), ensuring the &#39;iter.seq&#39; is properly populated before&#xA;subsequent operations.&#xA;CVE-2025-39829:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;trace/fgraph: Fix the warning caused by missing unregister notifier&#xA;&#xA;This warning was triggered during testing on v6.16:&#xA;&#xA;notifier callback ftrace_suspend_notifier_call already registered&#xA;WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; blocking_notifier_chain_register+0x34/0x60&#xA; register_ftrace_graph+0x330/0x410&#xA; ftrace_profile_write+0x1e9/0x340&#xA; vfs_write+0xf8/0x420&#xA; ? filp_flush+0x8a/0xa0&#xA; ? filp_close+0x1f/0x30&#xA; ? do_dup2+0xaf/0x160&#xA; ksys_write+0x65/0xe0&#xA; do_syscall_64+0xa4/0x260&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;When writing to the function_profile_enabled interface, the notifier was&#xA;not unregistered after start_graph_tracing failed, causing a warning the&#xA;next time function_profile_enabled was written.&#xA;&#xA;Fixed by adding unregister_pm_notifier in the exception path.&#xA;CVE-2024-53216:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: release svc_expkey/svc_export with rcu_work&#xA;&#xA;The last reference for `cache_head` can be reduced to zero in `c_show`&#xA;and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,&#xA;`svc_export_put` and `expkey_put` will be invoked, leading to two&#xA;issues:&#xA;&#xA;1. The `svc_export_put` will directly free ex_uuid. However,&#xA;   `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can&#xA;   trigger a use-after-free issue, shown below.&#xA;&#xA;   ==================================================================&#xA;   BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]&#xA;   Read of size 1 at addr ff11000010fdc120 by task cat/870&#xA;&#xA;   CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1&#xA;   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;   1.16.1-2.fc37 04/01/2014&#xA;   Call Trace:&#xA;    &lt;TASK&gt;&#xA;    dump_stack_lvl+0x53/0x70&#xA;    print_address_description.constprop.0+0x2c/0x3a0&#xA;    print_report+0xb9/0x280&#xA;    kasan_report+0xae/0xe0&#xA;    svc_export_show+0x362/0x430 [nfsd]&#xA;    c_show+0x161/0x390 [sunrpc]&#xA;    seq_read_iter+0x589/0x770&#xA;    seq_read+0x1e5/0x270&#xA;    proc_reg_read+0xe1/0x140&#xA;    vfs_read+0x125/0x530&#xA;    ksys_read+0xc1/0x160&#xA;    do_syscall_64+0x5f/0x170&#xA;    entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;   Allocated by task 830:&#xA;    kasan_save_stack+0x20/0x40&#xA;    kasan_save_track+0x14/0x30&#xA;    __kasan_kmalloc+0x8f/0xa0&#xA;    __kmalloc_node_track_caller_noprof+0x1bc/0x400&#xA;    kmemdup_noprof+0x22/0x50&#xA;    svc_export_parse+0x8a9/0xb80 [nfsd]&#xA;    cache_do_downcall+0x71/0xa0 [sunrpc]&#xA;    cache_write_procfs+0x8e/0xd0 [sunrpc]&#xA;    proc_reg_write+0xe1/0x140&#xA;    vfs_write+0x1a5/0x6d0&#xA;    ksys_write+0xc1/0x160&#xA;    do_syscall_64+0x5f/0x170&#xA;    entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;   Freed by task 868:&#xA;    kasan_save_stack+0x20/0x40&#xA;    kasan_save_track+0x14/0x30&#xA;    kasan_save_free_info+0x3b/0x60&#xA;    __kasan_slab_free+0x37/0x50&#xA;    kfree+0xf3/0x3e0&#xA;    svc_export_put+0x87/0xb0 [nfsd]&#xA;    cache_purge+0x17f/0x1f0 [sunrpc]&#xA;    nfsd_destroy_serv+0x226/0x2d0 [nfsd]&#xA;    nfsd_svc+0x125/0x1e0 [nfsd]&#xA;    write_threads+0x16a/0x2a0 [nfsd]&#xA;    nfsctl_transaction_write+0x74/0xa0 [nfsd]&#xA;    vfs_write+0x1a5/0x6d0&#xA;    ksys_write+0xc1/0x160&#xA;    do_syscall_64+0x5f/0x170&#xA;    entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.&#xA;   However, `svc_export_put`/`expkey_put` will call path_put, which&#xA;   subsequently triggers a sleeping operation due to the following&#xA;   `dput`.&#xA;&#xA;   =============================&#xA;   WARNING: suspicious RCU usage&#xA;   5.10.0-dirty #141 Not tainted&#xA;   -----------------------------&#xA;   ...&#xA;   Call Trace:&#xA;   dump_stack+0x9a/0xd0&#xA;   ___might_sleep+0x231/0x240&#xA;   dput+0x39/0x600&#xA;   path_put+0x1b/0x30&#xA;   svc_export_put+0x17/0x80&#xA;   e_show+0x1c9/0x200&#xA;   seq_read_iter+0x63f/0x7c0&#xA;   seq_read+0x226/0x2d0&#xA;   vfs_read+0x113/0x2c0&#xA;   ksys_read+0xc9/0x170&#xA;   do_syscall_64+0x33/0x40&#xA;   entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;&#xA;Fix these issues by using `rcu_work` to help release&#xA;`svc_expkey`/`svc_export`. This approach allows for an asynchronous&#xA;context to invoke `path_put` and also facilitates the freeing of&#xA;`uuid/exp/key` after an RCU grace period.&#xA;CVE-2024-56558:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: make sure exp active before svc_export_show&#xA;&#xA;The function `e_show` was called with protection from RCU. This only&#xA;ensures that `exp` will not be freed. Therefore, the reference count for&#xA;`exp` can drop to zero, which will trigger a refcount use-after-free&#xA;warning when `exp_get` is called. To resolve this issue, use&#xA;`cache_get_rcu` to ensure that `exp` remains active.&#xA;&#xA;------------[ cut here ]------------&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 3 PID: 819 at lib/refcount.c:25&#xA;refcount_warn_saturate+0xb1/0x120&#xA;CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;1.16.1-2.fc37 04/01/2014&#xA;RIP: 0010:refcount_warn_saturate+0xb1/0x120&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; e_show+0x20b/0x230 [nfsd]&#xA; seq_read_iter+0x589/0x770&#xA; seq_read+0x1e5/0x270&#xA; vfs_read+0x125/0x530&#xA; ksys_read+0xc1/0x160&#xA; do_syscall_64+0x5f/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2025-38602:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iwlwifi: Add missing check for alloc_ordered_workqueue&#xA;&#xA;Add check for the return value of alloc_ordered_workqueue since it may&#xA;return NULL pointer.&#xA;CVE-2025-38611:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2025-38632:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pinmux: fix race causing mux_owner NULL with active mux_usecount&#xA;&#xA;commit 5a3e85c3c397 (&#34;pinmux: Use sequential access to access&#xA;desc-&gt;pinmux data&#34;) tried to address the issue when two client of the&#xA;same gpio calls pinctrl_select_state() for the same functionality, was&#xA;resulting in NULL pointer issue while accessing desc-&gt;mux_owner.&#xA;However, issue was not completely fixed due to the way it was handled&#xA;and it can still result in the same NULL pointer.&#xA;&#xA;The issue occurs due to the following interleaving:&#xA;&#xA;     cpu0 (process A)                   cpu1 (process B)&#xA;&#xA;      pin_request() {                   pin_free() {&#xA;&#xA;                                         mutex_lock()&#xA;                                         desc-&gt;mux_usecount--; //becomes 0&#xA;                                         ..&#xA;                                         mutex_unlock()&#xA;&#xA;  mutex_lock(desc-&gt;mux)&#xA;  desc-&gt;mux_usecount++; // becomes 1&#xA;  desc-&gt;mux_owner = owner;&#xA;  mutex_unlock(desc-&gt;mux)&#xA;&#xA;                                         mutex_lock(desc-&gt;mux)&#xA;                                         desc-&gt;mux_owner = NULL;&#xA;                                         mutex_unlock(desc-&gt;mux)&#xA;&#xA;This sequence leads to a state where the pin appears to be in use&#xA;(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can&#xA;cause NULL pointer on next pin_request on the same pin.&#xA;&#xA;Ensure that updates to mux_usecount and mux_owner are performed&#xA;atomically under the same lock. Only clear mux_owner when mux_usecount&#xA;reaches zero and no new owner has been assigned.&#xA;CVE-2025-38652:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix to avoid out-of-boundary access in devs.path&#xA;&#xA;- touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123&#xA;- truncate -s $((1024*1024*1024)) \&#xA;  /mnt/f2fs/012345678901234567890123456789012345678901234567890123&#xA;- touch /mnt/f2fs/file&#xA;- truncate -s $((1024*1024*1024)) /mnt/f2fs/file&#xA;- mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \&#xA;  -c /mnt/f2fs/file&#xA;- mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \&#xA;  /mnt/f2fs/loop&#xA;&#xA;[16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01,      511,        0 -    3ffff&#xA;[16937.192268] F2FS-fs (loop0): Failed to find devices&#xA;&#xA;If device path length equals to MAX_PATH_LEN, sbi-&gt;devs.path[] may&#xA;not end up w/ null character due to path array is fully filled, So&#xA;accidently, fields locate after path[] may be treated as part of&#xA;device path, result in parsing wrong device path.&#xA;&#xA;struct f2fs_dev_info {&#xA;...&#xA;&#x9;char path[MAX_PATH_LEN];&#xA;...&#xA;};&#xA;&#xA;Let&#39;s add one byte space for sbi-&gt;devs.path[] to store null&#xA;character of device path string.&#xA;CVE-2025-38563:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf/core: Prevent VMA split of buffer mappings&#xA;&#xA;The perf mmap code is careful about mmap()&#39;ing the user page with the&#xA;ringbuffer and additionally the auxiliary buffer, when the event supports&#xA;it. Once the first mapping is established, subsequent mapping have to use&#xA;the same offset and the same size in both cases. The reference counting for&#xA;the ringbuffer and the auxiliary buffer depends on this being correct.&#xA;&#xA;Though perf does not prevent that a related mapping is split via mmap(2),&#xA;munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,&#xA;which take reference counts, but then the subsequent perf_mmap_close()&#xA;calls are not longer fulfilling the offset and size checks. This leads to&#xA;reference count leaks.&#xA;&#xA;As perf already has the requirement for subsequent mappings to match the&#xA;initial mapping, the obvious consequence is that VMA splits, caused by&#xA;resizing of a mapping or partial unmapping, have to be prevented.&#xA;&#xA;Implement the vm_operations_struct::may_split() callback and return&#xA;unconditionally -EINVAL.&#xA;&#xA;That ensures that the mapping offsets and sizes cannot be changed after the&#xA;fact. Remapping to a different fixed address with the same size is still&#xA;possible as it takes the references for the new mapping and drops those of&#xA;the old mapping.&#xA;CVE-2025-21759:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: mcast: extend RCU protection in igmp6_send()&#xA;&#xA;igmp6_send() can be called without RTNL or RCU being held.&#xA;&#xA;Extend RCU protection so that we can safely fetch the net pointer&#xA;and avoid a potential UAF.&#xA;&#xA;Note that we no longer can use sock_alloc_send_skb() because&#xA;ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.&#xA;&#xA;Instead use alloc_skb() and charge the net-&gt;ipv6.igmp_sk&#xA;socket under RCU protection.&#xA;CVE-2025-38174:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;thunderbolt: Do not double dequeue a configuration request&#xA;&#xA;Some of our devices crash in tb_cfg_request_dequeue():&#xA;&#xA; general protection fault, probably for non-canonical address 0xdead000000000122&#xA;&#xA; CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65&#xA; RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0&#xA; Call Trace:&#xA; &lt;TASK&gt;&#xA; ? tb_cfg_request_dequeue+0x2d/0xa0&#xA; tb_cfg_request_work+0x33/0x80&#xA; worker_thread+0x386/0x8f0&#xA; kthread+0xed/0x110&#xA; ret_from_fork+0x38/0x50&#xA; ret_from_fork_asm+0x1b/0x30&#xA;&#xA;The circumstances are unclear, however, the theory is that&#xA;tb_cfg_request_work() can be scheduled twice for a request:&#xA;first time via frame.callback from ring_work() and second&#xA;time from tb_cfg_request().  Both times kworkers will execute&#xA;tb_cfg_request_dequeue(), which results in double list_del()&#xA;from the ctl-&gt;request_queue (the list poison deference hints&#xA;at it: 0xdead000000000122).&#xA;&#xA;Do not dequeue requests that don&#39;t have TB_CFG_REQUEST_ACTIVE&#xA;bit set.&#xA;CVE-2025-37885:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable&#xA;&#xA;Restore an IRTE back to host control (remapped or posted MSI mode) if the&#xA;*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of&#xA;the GSI routing type.  Updating the IRTE if and only if the new GSI is an&#xA;MSI results in KVM leaving an IRTE posting to a vCPU.&#xA;&#xA;The dangling IRTE can result in interrupts being incorrectly delivered to&#xA;the guest, and in the worst case scenario can result in use-after-free,&#xA;e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.&#xA;CVE-2025-21934:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rapidio: fix an API misues when rio_add_net() fails&#xA;&#xA;rio_add_net() calls device_register() and fails when device_register()&#xA;fails.  Thus, put_device() should be used rather than kfree().  Add&#xA;&#34;mport-&gt;net = NULL;&#34; to avoid a use after free issue.&#xA;CVE-2025-21665:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;filemap: avoid truncating 64-bit offset to 32 bits&#xA;&#xA;On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a&#xA;64-bit value to 32 bits, leading to a possible infinite loop when writing&#xA;to an xfs filesystem.&#xA;CVE-2024-58052:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table&#xA;&#xA;The function atomctrl_get_smc_sclk_range_table() does not check the return&#xA;value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to&#xA;retrieve SMU_Info table, it returns NULL which is later dereferenced.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;&#xA;In practice this should never happen as this code only gets called&#xA;on polaris chips and the vbios data table will always be present on&#xA;those chips.&#xA;CVE-2022-49135:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Fix memory leak&#xA;&#xA;[why]&#xA;Resource release is needed on the error handling path&#xA;to prevent memory leak.&#xA;&#xA;[how]&#xA;Fix this by adding kfree on the error handling path.&#xA;CVE-2024-54458:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: ufs: bsg: Set bsg_queue to NULL after removal&#xA;&#xA;Currently, this does not cause any issues, but I believe it is necessary to&#xA;set bsg_queue to NULL after removing it to prevent potential use-after-free&#xA;(UAF) access.&#xA;CVE-2025-37834:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/vmscan: don&#39;t try to reclaim hwpoison folio&#xA;&#xA;Syzkaller reports a bug as follows:&#xA;&#xA;Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000&#xA;Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users&#xA;Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed&#xA;page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e&#xA;memcg:ffff0000dd6d9000&#xA;anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)&#xA;raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9&#xA;raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000&#xA;page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))&#xA;------------[ cut here ]------------&#xA;kernel BUG at mm/swap_state.c:184!&#xA;Internal error: Oops - BUG: 00000000f2000800 [#1] SMP&#xA;Modules linked in:&#xA;CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3&#xA;Hardware name: linux,dummy-virt (DT)&#xA;pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : add_to_swap+0xbc/0x158&#xA;lr : add_to_swap+0xbc/0x158&#xA;sp : ffff800087f37340&#xA;x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780&#xA;x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0&#xA;x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4&#xA;x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000&#xA;x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c&#xA;x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b&#xA;x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000&#xA;x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001&#xA;x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000&#xA;x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000&#xA;Call trace:&#xA; add_to_swap+0xbc/0x158&#xA; shrink_folio_list+0x12ac/0x2648&#xA; shrink_inactive_list+0x318/0x948&#xA; shrink_lruvec+0x450/0x720&#xA; shrink_node_memcgs+0x280/0x4a8&#xA; shrink_node+0x128/0x978&#xA; balance_pgdat+0x4f0/0xb20&#xA; kswapd+0x228/0x438&#xA; kthread+0x214/0x230&#xA; ret_from_fork+0x10/0x20&#xA;&#xA;I can reproduce this issue with the following steps:&#xA;&#xA;1) When a dirty swapcache page is isolated by reclaim process and the&#xA;   page isn&#39;t locked, inject memory failure for the page. &#xA;   me_swapcache_dirty() clears uptodate flag and tries to delete from lru,&#xA;   but fails.  Reclaim process will put the hwpoisoned page back to lru.&#xA;&#xA;2) The process that maps the hwpoisoned page exits, the page is deleted&#xA;   the page will never be freed and will be in the lru forever.&#xA;&#xA;3) If we trigger a reclaim again and tries to reclaim the page,&#xA;   add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is&#xA;   cleared.&#xA;&#xA;To fix it, skip the hwpoisoned page in shrink_folio_list().  Besides, the&#xA;hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap&#xA;it in shrink_folio_list(), otherwise the folio will fail to be unmaped by&#xA;hwpoison_user_mappings() since the folio isn&#39;t in lru list.&#xA;CVE-2025-38085:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race&#xA;&#xA;huge_pmd_unshare() drops a reference on a page table that may have&#xA;previously been shared across processes, potentially turning it into a&#xA;normal page table used in another process in which unrelated VMAs can&#xA;afterwards be installed.&#xA;&#xA;If this happens in the middle of a concurrent gup_fast(), gup_fast() could&#xA;end up walking the page tables of another process.  While I don&#39;t see any&#xA;way in which that immediately leads to kernel memory corruption, it is&#xA;really weird and unexpected.&#xA;&#xA;Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),&#xA;just like we do in khugepaged when removing page tables for a THP&#xA;collapse.&#xA;CVE-2022-49622:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: avoid skb access on nf_stolen&#xA;&#xA;When verdict is NF_STOLEN, the skb might have been freed.&#xA;&#xA;When tracing is enabled, this can result in a use-after-free:&#xA;1. access to skb-&gt;nf_trace&#xA;2. access to skb-&gt;mark&#xA;3. computation of trace id&#xA;4. dump of packet payload&#xA;&#xA;To avoid 1, keep a cached copy of skb-&gt;nf_trace in the&#xA;trace state struct.&#xA;Refresh this copy whenever verdict is != STOLEN.&#xA;&#xA;Avoid 2 by skipping skb-&gt;mark access if verdict is STOLEN.&#xA;&#xA;3 is avoided by precomputing the trace id.&#xA;&#xA;Only dump the packet when verdict is not &#34;STOLEN&#34;.&#xA;CVE-2025-22056:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nft_tunnel: fix geneve_opt type confusion addition&#xA;&#xA;When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the&#xA;parsing logic should place every geneve_opt structure one by one&#xA;compactly. Hence, when deciding the next geneve_opt position, the&#xA;pointer addition should be in units of char *.&#xA;&#xA;However, the current implementation erroneously does type conversion&#xA;before the addition, which will lead to heap out-of-bounds write.&#xA;&#xA;[    6.989857] ==================================================================&#xA;[    6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70&#xA;[    6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178&#xA;[    6.991162]&#xA;[    6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1&#xA;[    6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;[    6.992281] Call Trace:&#xA;[    6.992423]  &lt;TASK&gt;&#xA;[    6.992586]  dump_stack_lvl+0x44/0x5c&#xA;[    6.992801]  print_report+0x184/0x4be&#xA;[    6.993790]  kasan_report+0xc5/0x100&#xA;[    6.994252]  kasan_check_range+0xf3/0x1a0&#xA;[    6.994486]  memcpy+0x38/0x60&#xA;[    6.994692]  nft_tunnel_obj_init+0x977/0xa70&#xA;[    6.995677]  nft_obj_init+0x10c/0x1b0&#xA;[    6.995891]  nf_tables_newobj+0x585/0x950&#xA;[    6.996922]  nfnetlink_rcv_batch+0xdf9/0x1020&#xA;[    6.998997]  nfnetlink_rcv+0x1df/0x220&#xA;[    6.999537]  netlink_unicast+0x395/0x530&#xA;[    7.000771]  netlink_sendmsg+0x3d0/0x6d0&#xA;[    7.001462]  __sock_sendmsg+0x99/0xa0&#xA;[    7.001707]  ____sys_sendmsg+0x409/0x450&#xA;[    7.002391]  ___sys_sendmsg+0xfd/0x170&#xA;[    7.003145]  __sys_sendmsg+0xea/0x170&#xA;[    7.004359]  do_syscall_64+0x5e/0x90&#xA;[    7.005817]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;[    7.006127] RIP: 0033:0x7ec756d4e407&#xA;[    7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 &lt;5b&gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf&#xA;[    7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e&#xA;[    7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407&#xA;[    7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003&#xA;[    7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000&#xA;[    7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000&#xA;[    7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8&#xA;&#xA;Fix this bug with correct pointer addition and conversion in parse&#xA;and dump code.&#xA;CVE-2024-56602:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()&#xA;&#xA;sock_init_data() attaches the allocated sk object to the provided sock&#xA;object. If ieee802154_create() fails later, the allocated sk object is&#xA;freed, but the dangling pointer remains in the provided sock object, which&#xA;may allow use-after-free.&#xA;&#xA;Clear the sk pointer in the sock object on error.&#xA;CVE-2025-37911:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bnxt_en: Fix out-of-bound memcpy() during ethtool -w&#xA;&#xA;When retrieving the FW coredump using ethtool, it can sometimes cause&#xA;memory corruption:&#xA;&#xA;BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]&#xA;Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):&#xA;__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]&#xA;ethtool_get_dump_data+0xdc/0x1a0&#xA;__dev_ethtool+0xa1e/0x1af0&#xA;dev_ethtool+0xa8/0x170&#xA;dev_ioctl+0x1b5/0x580&#xA;sock_do_ioctl+0xab/0xf0&#xA;sock_ioctl+0x1ce/0x2e0&#xA;__x64_sys_ioctl+0x87/0xc0&#xA;do_syscall_64+0x5c/0xf0&#xA;entry_SYSCALL_64_after_hwframe+0x78/0x80&#xA;&#xA;...&#xA;&#xA;This happens when copying the coredump segment list in&#xA;bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.&#xA;The info-&gt;dest_buf buffer is allocated based on the number of coredump&#xA;segments returned by the FW.  The segment list is then DMA&#39;ed by&#xA;the FW and the length of the DMA is returned by FW.  The driver then&#xA;copies this DMA&#39;ed segment list to info-&gt;dest_buf.&#xA;&#xA;In some cases, this DMA length may exceed the info-&gt;dest_buf length&#xA;and cause the above BUG condition.  Fix it by capping the copy&#xA;length to not exceed the length of info-&gt;dest_buf.  The extra&#xA;DMA data contains no useful information.&#xA;&#xA;This code path is shared for the HWRM_DBG_COREDUMP_LIST and the&#xA;HWRM_DBG_COREDUMP_RETRIEVE FW commands.  The buffering is different&#xA;for these 2 FW commands.  To simplify the logic, we need to move&#xA;the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE&#xA;up, so that the new check to cap the copy length will work for both&#xA;commands.&#xA;CVE-2025-38671:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i2c: qup: jump out of the loop in case of timeout&#xA;&#xA;Original logic only sets the return value but doesn&#39;t jump out of the&#xA;loop if the bus is kept active by a client. This is not expected. A&#xA;malicious or buggy i2c client can hang the kernel in this case and&#xA;should be avoided. This is observed during a long time test with a&#xA;PCA953x GPIO extender.&#xA;&#xA;Fix it by changing the logic to not only sets the return value, but also&#xA;jumps out of the loop and return to the caller with -ETIMEDOUT.&#xA;CVE-2025-38129:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;page_pool: Fix use-after-free in page_pool_recycle_in_ring&#xA;&#xA;syzbot reported a uaf in page_pool_recycle_in_ring:&#xA;&#xA;BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862&#xA;Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943&#xA;&#xA;CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:378 [inline]&#xA; print_report+0x169/0x550 mm/kasan/report.c:489&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:602&#xA; lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862&#xA; __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]&#xA; _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210&#xA; spin_unlock_bh include/linux/spinlock.h:396 [inline]&#xA; ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]&#xA; page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]&#xA; page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826&#xA; page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]&#xA; page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]&#xA; napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036&#xA; skb_pp_recycle net/core/skbuff.c:1047 [inline]&#xA; skb_free_head net/core/skbuff.c:1094 [inline]&#xA; skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125&#xA; skb_release_all net/core/skbuff.c:1190 [inline]&#xA; __kfree_skb net/core/skbuff.c:1204 [inline]&#xA; sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242&#xA; kfree_skb_reason include/linux/skbuff.h:1263 [inline]&#xA; __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]&#xA;&#xA;root cause is:&#xA;&#xA;page_pool_recycle_in_ring&#xA;  ptr_ring_produce&#xA;    spin_lock(&amp;r-&gt;producer_lock);&#xA;    WRITE_ONCE(r-&gt;queue[r-&gt;producer++], ptr)&#xA;      //recycle last page to pool&#xA;&#x9;&#x9;&#x9;&#x9;page_pool_release&#xA;&#x9;&#x9;&#x9;&#x9;  page_pool_scrub&#xA;&#x9;&#x9;&#x9;&#x9;    page_pool_empty_ring&#xA;&#x9;&#x9;&#x9;&#x9;      ptr_ring_consume&#xA;&#x9;&#x9;&#x9;&#x9;      page_pool_return_page  //release all page&#xA;&#x9;&#x9;&#x9;&#x9;  __page_pool_destroy&#xA;&#x9;&#x9;&#x9;&#x9;     free_percpu(pool-&gt;recycle_stats);&#xA;&#x9;&#x9;&#x9;&#x9;     free(pool) //free&#xA;&#xA;     spin_unlock(&amp;r-&gt;producer_lock); //pool-&gt;ring uaf read&#xA;  recycle_stat_inc(pool, ring);&#xA;&#xA;page_pool can be free while page pool recycle the last page in ring.&#xA;Add producer-lock barrier to page_pool_release to prevent the page&#xA;pool from being free before all pages have been recycled.&#xA;&#xA;recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not&#xA;enabled, which will trigger Wempty-body build warning. Add definition&#xA;for pool stat macro to fix warning.&#xA;CVE-2025-38502:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Fix oob access in cgroup local storage&#xA;&#xA;Lonial reported that an out-of-bounds access in cgroup local storage&#xA;can be crafted via tail calls. Given two programs each utilizing a&#xA;cgroup local storage with a different value size, and one program&#xA;doing a tail call into the other. The verifier will validate each of&#xA;the indivial programs just fine. However, in the runtime context&#xA;the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the&#xA;BPF program as well as any cgroup local storage flavor the program&#xA;uses. Helpers such as bpf_get_local_storage() pick this up from the&#xA;runtime context:&#xA;&#xA;  ctx = container_of(current-&gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);&#xA;  storage = ctx-&gt;prog_item-&gt;cgroup_storage[stype];&#xA;&#xA;  if (stype == BPF_CGROUP_STORAGE_SHARED)&#xA;    ptr = &amp;READ_ONCE(storage-&gt;buf)-&gt;data[0];&#xA;  else&#xA;    ptr = this_cpu_ptr(storage-&gt;percpu_buf);&#xA;&#xA;For the second program which was called from the originally attached&#xA;one, this means bpf_get_local_storage() will pick up the former&#xA;program&#39;s map, not its own. With mismatching sizes, this can result&#xA;in an unintended out-of-bounds access.&#xA;&#xA;To fix this issue, we need to extend bpf_map_owner with an array of&#xA;storage_cookie[] to match on i) the exact maps from the original&#xA;program if the second program was using bpf_get_local_storage(), or&#xA;ii) allow the tail call combination if the second program was not&#xA;using any of the cgroup local storage maps.&#xA;CVE-2025-38645:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mlx5: Check device memory pointer before usage&#xA;&#xA;Add a NULL check before accessing device memory to prevent a crash if&#xA;dev-&gt;dm allocation in mlx5_init_once() fails.&#xA;CVE-2025-38119:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: core: ufs: Fix a hang in the error handler&#xA;&#xA;ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter&#xA;function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because&#xA;resuming involves submitting a SCSI command and ufshcd_queuecommand()&#xA;returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this&#xA;hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has&#xA;been called instead of before.&#xA;&#xA;Backtrace:&#xA;__switch_to+0x174/0x338&#xA;__schedule+0x600/0x9e4&#xA;schedule+0x7c/0xe8&#xA;schedule_timeout+0xa4/0x1c8&#xA;io_schedule_timeout+0x48/0x70&#xA;wait_for_common_io+0xa8/0x160 //waiting on START_STOP&#xA;wait_for_completion_io_timeout+0x10/0x20&#xA;blk_execute_rq+0xe4/0x1e4&#xA;scsi_execute_cmd+0x108/0x244&#xA;ufshcd_set_dev_pwr_mode+0xe8/0x250&#xA;__ufshcd_wl_resume+0x94/0x354&#xA;ufshcd_wl_runtime_resume+0x3c/0x174&#xA;scsi_runtime_resume+0x64/0xa4&#xA;rpm_resume+0x15c/0xa1c&#xA;__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing&#xA;ufshcd_err_handler+0x1a0/0xd08&#xA;process_one_work+0x174/0x808&#xA;worker_thread+0x15c/0x490&#xA;kthread+0xf4/0x1ec&#xA;ret_from_fork+0x10/0x20&#xA;&#xA;[ bvanassche: rewrote patch description ]&#xA;CVE-2025-38399:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()&#xA;&#xA;The function core_scsi3_decode_spec_i_port(), in its error code path,&#xA;unconditionally calls core_scsi3_lunacl_undepend_item() passing the&#xA;dest_se_deve pointer, which may be NULL.&#xA;&#xA;This can lead to a NULL pointer dereference if dest_se_deve remains&#xA;unset.&#xA;&#xA;SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg&#xA;Unable to handle kernel paging request at virtual address dfff800000000012&#xA;Call trace:&#xA;  core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P)&#xA;  core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod]&#xA;  core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod]&#xA;  target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]&#xA;&#xA;Fix this by adding a NULL check before calling&#xA;core_scsi3_lunacl_undepend_item()&#xA;CVE-2025-38695:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure&#xA;&#xA;If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the&#xA;resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may&#xA;occur before sli4_hba.hdwqs are allocated.  This may result in a null&#xA;pointer dereference when attempting to take the abts_io_buf_list_lock for&#xA;the first hardware queue.  Fix by adding a null ptr check on&#xA;phba-&gt;sli4_hba.hdwq and early return because this situation means there&#xA;must have been an error during port initialization.&#xA;CVE-2025-38710:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;gfs2: Validate i_depth for exhash directories&#xA;&#xA;A fuzzer test introduced corruption that ends up with a depth of 0 in&#xA;dir_e_read(), causing an undefined shift by 32 at:&#xA;&#xA;  index = hash &gt;&gt; (32 - dip-&gt;i_depth);&#xA;&#xA;As calculated in an open-coded way in dir_make_exhash(), the minimum&#xA;depth for an exhash directory is ilog2(sdp-&gt;sd_hash_ptrs) and 0 is&#xA;invalid as sdp-&gt;sd_hash_ptrs is fixed as sdp-&gt;bsize / 16 at mount time.&#xA;&#xA;So we can avoid the undefined behaviour by checking for depth values&#xA;lower than the minimum in gfs2_dinode_in(). Values greater than the&#xA;maximum are already being checked for there.&#xA;&#xA;Also switch the calculation in dir_make_exhash() to use ilog2() to&#xA;clarify how the depth is calculated.&#xA;&#xA;Tested with the syzkaller repro.c and xfstests &#39;-g quick&#39;.&#xA;CVE-2025-38724:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()&#xA;&#xA;Lei Lu recently reported that nfsd4_setclientid_confirm() did not check&#xA;the return value from get_client_locked(). a SETCLIENTID_CONFIRM could&#xA;race with a confirmed client expiring and fail to get a reference. That&#xA;could later lead to a UAF.&#xA;&#xA;Fix this by getting a reference early in the case where there is an&#xA;extant confirmed client. If that fails then treat it as if there were no&#xA;confirmed client found at all.&#xA;&#xA;In the case where the unconfirmed client is expiring, just fail and&#xA;return the result from get_client_locked().&#xA;CVE-2025-38693:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar&#xA;&#xA;In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add&#xA;check on msg[0].len to prevent crash.&#xA;&#xA;Similar commit: commit 0ed554fd769a (&#34;media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()&#34;)&#xA;CVE-2025-39773:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: bridge: fix soft lockup in br_multicast_query_expired()&#xA;&#xA;When set multicast_query_interval to a large value, the local variable&#xA;&#39;time&#39; in br_multicast_send_query() may overflow. If the time is smaller&#xA;than jiffies, the timer will expire immediately, and then call mod_timer()&#xA;again, which creates a loop and may trigger the following soft lockup&#xA;issue.&#xA;&#xA;  watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]&#xA;  CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   __netdev_alloc_skb+0x2e/0x3a0&#xA;   br_ip6_multicast_alloc_query+0x212/0x1b70&#xA;   __br_multicast_send_query+0x376/0xac0&#xA;   br_multicast_send_query+0x299/0x510&#xA;   br_multicast_query_expired.constprop.0+0x16d/0x1b0&#xA;   call_timer_fn+0x3b/0x2a0&#xA;   __run_timers+0x619/0x950&#xA;   run_timer_softirq+0x11c/0x220&#xA;   handle_softirqs+0x18e/0x560&#xA;   __irq_exit_rcu+0x158/0x1a0&#xA;   sysvec_apic_timer_interrupt+0x76/0x90&#xA;   &lt;/IRQ&gt;&#xA;&#xA;This issue can be reproduced with:&#xA;  ip link add br0 type bridge&#xA;  echo 1 &gt; /sys/class/net/br0/bridge/multicast_querier&#xA;  echo 0xffffffffffffffff &gt;&#xA;  &#x9;/sys/class/net/br0/bridge/multicast_query_interval&#xA;  ip link set dev br0 up&#xA;&#xA;The multicast_startup_query_interval can also cause this issue. Similar to&#xA;the commit 99b40610956a (&#34;net: bridge: mcast: add and enforce query&#xA;interval minimum&#34;), add check for the query interval maximum to fix this&#xA;issue.&#xA;CVE-2022-50255:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Fix reading strings from synthetic events&#xA;&#xA;The follow commands caused a crash:&#xA;&#xA;  # cd /sys/kernel/tracing&#xA;  # echo &#39;s:open char file[]&#39; &gt; dynamic_events&#xA;  # echo &#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&#39; &gt; events/syscalls/sys_enter_openat/trigger&#39;&#xA;  # echo 1 &gt; events/synthetic/open/enable&#xA;&#xA;BOOM!&#xA;&#xA;The problem is that the synthetic event field &#34;char file[]&#34; will read&#xA;the value given to it as a string without any memory checks to make sure&#xA;the address is valid. The above example will pass in the user space&#xA;address and the sythetic event code will happily call strlen() on it&#xA;and then strscpy() where either one will cause an oops when accessing&#xA;user space addresses.&#xA;&#xA;Use the helper functions from trace_kprobe and trace_eprobe that can&#xA;read strings safely (and actually succeed when the address is from user&#xA;space and the memory is mapped in).&#xA;&#xA;Now the above can show:&#xA;&#xA;     packagekitd-1721    [000] ...2.   104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr&#xA;    in:imjournal-978     [006] ...2.   104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp&#xA;     packagekitd-1721    [000] ...2.   104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr&#xA;CVE-2023-53221:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Fix memleak due to fentry attach failure&#xA;&#xA;If it fails to attach fentry, the allocated bpf trampoline image will be&#xA;left in the system. That can be verified by checking /proc/kallsyms.&#xA;&#xA;This meamleak can be verified by a simple bpf program as follows:&#xA;&#xA;  SEC(&#34;fentry/trap_init&#34;)&#xA;  int fentry_run()&#xA;  {&#xA;      return 0;&#xA;  }&#xA;&#xA;It will fail to attach trap_init because this function is freed after&#xA;kernel init, and then we can find the trampoline image is left in the&#xA;system by checking /proc/kallsyms.&#xA;&#xA;  $ tail /proc/kallsyms&#xA;  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]&#xA;  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]&#xA;&#xA;  $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &#34;FUNC &#39;trap_init&#39;&#34;&#xA;  [2522] FUNC &#39;trap_init&#39; type_id=119 linkage=static&#xA;&#xA;  $ echo $((6442453466 &amp; 0x7fffffff))&#xA;  2522&#xA;&#xA;Note that there are two left bpf trampoline images, that is because the&#xA;libbpf will fallback to raw tracepoint if -EINVAL is returned.&#xA;CVE-2022-49234:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: dsa: Avoid cross-chip syncing of VLAN filtering&#xA;&#xA;Changes to VLAN filtering are not applicable to cross-chip&#xA;notifications.&#xA;&#xA;On a system like this:&#xA;&#xA;.-----.   .-----.   .-----.&#xA;| sw1 +---+ sw2 +---+ sw3 |&#xA;&#39;-1-2-&#39;   &#39;-1-2-&#39;   &#39;-1-2-&#39;&#xA;&#xA;Before this change, upon sw1p1 leaving a bridge, a call to&#xA;dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.&#xA;&#xA;In this scenario:&#xA;&#xA;.---------.   .-----.   .-----.&#xA;|   sw1   +---+ sw2 +---+ sw3 |&#xA;&#39;-1-2-3-4-&#39;   &#39;-1-2-&#39;   &#39;-1-2-&#39;&#xA;&#xA;When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be&#xA;called for sw2 and sw3 with a non-existing port - leading to array&#xA;out-of-bounds accesses and crashes on mv88e6xxx.&#xA;CVE-2025-21801:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ravb: Fix missing rtnl lock in suspend/resume path&#xA;&#xA;Fix the suspend/resume path by ensuring the rtnl lock is held where&#xA;required. Calls to ravb_open, ravb_close and wol operations must be&#xA;performed under the rtnl lock to prevent conflicts with ongoing ndo&#xA;operations.&#xA;&#xA;Without this fix, the following warning is triggered:&#xA;[   39.032969] =============================&#xA;[   39.032983] WARNING: suspicious RCU usage&#xA;[   39.033019] -----------------------------&#xA;[   39.033033] drivers/net/phy/phy_device.c:2004 suspicious&#xA;rcu_dereference_protected() usage!&#xA;...&#xA;[   39.033597] stack backtrace:&#xA;[   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted&#xA;6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7&#xA;[   39.033623] Hardware name: Renesas SMARC EVK version 2 based on&#xA;r9a08g045s33 (DT)&#xA;[   39.033628] Call trace:&#xA;[   39.033633]  show_stack+0x14/0x1c (C)&#xA;[   39.033652]  dump_stack_lvl+0xb4/0xc4&#xA;[   39.033664]  dump_stack+0x14/0x1c&#xA;[   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c&#xA;[   39.033682]  phy_detach+0x160/0x190&#xA;[   39.033694]  phy_disconnect+0x40/0x54&#xA;[   39.033703]  ravb_close+0x6c/0x1cc&#xA;[   39.033714]  ravb_suspend+0x48/0x120&#xA;[   39.033721]  dpm_run_callback+0x4c/0x14c&#xA;[   39.033731]  device_suspend+0x11c/0x4dc&#xA;[   39.033740]  dpm_suspend+0xdc/0x214&#xA;[   39.033748]  dpm_suspend_start+0x48/0x60&#xA;[   39.033758]  suspend_devices_and_enter+0x124/0x574&#xA;[   39.033769]  pm_suspend+0x1ac/0x274&#xA;[   39.033778]  state_store+0x88/0x124&#xA;[   39.033788]  kobj_attr_store+0x14/0x24&#xA;[   39.033798]  sysfs_kf_write+0x48/0x6c&#xA;[   39.033808]  kernfs_fop_write_iter+0x118/0x1a8&#xA;[   39.033817]  vfs_write+0x27c/0x378&#xA;[   39.033825]  ksys_write+0x64/0xf4&#xA;[   39.033833]  __arm64_sys_write+0x18/0x20&#xA;[   39.033841]  invoke_syscall+0x44/0x104&#xA;[   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4&#xA;[   39.033862]  do_el0_svc+0x18/0x20&#xA;[   39.033870]  el0_svc+0x3c/0xf0&#xA;[   39.033880]  el0t_64_sync_handler+0xc0/0xc4&#xA;[   39.033888]  el0t_64_sync+0x154/0x158&#xA;[   39.041274] ravb 11c30000.ethernet eth0: Link is Down&#xA;CVE-2025-22073:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;spufs: fix a leak on spufs_new_file() failure&#xA;&#xA;It&#39;s called from spufs_fill_dir(), and caller of that will do&#xA;spufs_rmdir() in case of failure.  That does remove everything&#xA;we&#39;d managed to create, but... the problem dentry is still&#xA;negative.  IOW, it needs to be explicitly dropped.&#xA;CVE-2025-38086:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ch9200: fix uninitialised access during mii_nway_restart&#xA;&#xA;In mii_nway_restart() the code attempts to call&#xA;mii-&gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()&#xA;utilises a local buffer called &#34;buff&#34;, which is initialised&#xA;with control_read(). However &#34;buff&#34; is conditionally&#xA;initialised inside control_read():&#xA;&#xA;        if (err == size) {&#xA;                memcpy(data, buf, size);&#xA;        }&#xA;&#xA;If the condition of &#34;err == size&#34; is not met, then&#xA;&#34;buff&#34; remains uninitialised. Once this happens the&#xA;uninitialised &#34;buff&#34; is accessed and returned during&#xA;ch9200_mdio_read():&#xA;&#xA;        return (buff[0] | buff[1] &lt;&lt; 8);&#xA;&#xA;The problem stems from the fact that ch9200_mdio_read()&#xA;ignores the return value of control_read(), leading to&#xA;uinit-access of &#34;buff&#34;.&#xA;&#xA;To fix this we should check the return value of&#xA;control_read() and return early on error.&#xA;CVE-2025-38313:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bus: fsl-mc: fix double-free on mc_dev&#xA;&#xA;The blamed commit tried to simplify how the deallocations are done but,&#xA;in the process, introduced a double-free on the mc_dev variable.&#xA;&#xA;In case the MC device is a DPRC, a new mc_bus is allocated and the&#xA;mc_dev variable is just a reference to one of its fields. In this&#xA;circumstance, on the error path only the mc_bus should be freed.&#xA;&#xA;This commit introduces back the following checkpatch warning which is a&#xA;false-positive.&#xA;&#xA;WARNING: kfree(NULL) is safe and this check is probably not required&#xA;+       if (mc_bus)&#xA;+               kfree(mc_bus);&#xA;CVE-2025-38615:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: cancle set bad inode after removing name fails&#xA;&#xA;The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.&#xA;When renaming, the file0&#39;s inode is marked as a bad inode because the file&#xA;name cannot be deleted.&#xA;&#xA;The underlying bug is that make_bad_inode() is called on a live inode.&#xA;In some cases it&#39;s &#34;icache lookup finds a normal inode, d_splice_alias()&#xA;is called to attach it to dentry, while another thread decides to call&#xA;make_bad_inode() on it - that would evict it from icache, but we&#39;d already&#xA;found it there earlier&#34;.&#xA;In some it&#39;s outright &#34;we have an inode attached to dentry - that&#39;s how we&#xA;got it in the first place; let&#39;s call make_bad_inode() on it just for shits&#xA;and giggles&#34;.&#xA;CVE-2025-39752:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ARM: rockchip: fix kernel hang during smp initialization&#xA;&#xA;In order to bring up secondary CPUs main CPU write trampoline&#xA;code to SRAM. The trampoline code is written while secondary&#xA;CPUs are powered on (at least that true for RK3188 CPU).&#xA;Sometimes that leads to kernel hang. Probably because secondary&#xA;CPU execute trampoline code while kernel doesn&#39;t expect.&#xA;&#xA;The patch moves SRAM initialization step to the point where all&#xA;secondary CPUs are powered down.&#xA;&#xA;That fixes rarely hangs on RK3188:&#xA;[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000&#xA;[    0.091996] rockchip_smp_prepare_cpus: ncores 4&#xA;CVE-2023-53259:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;VMCI: check context-&gt;notify_page after call to get_user_pages_fast() to avoid GPF&#xA;&#xA;The call to get_user_pages_fast() in vmci_host_setup_notify() can return&#xA;NULL context-&gt;notify_page causing a GPF. To avoid GPF check if&#xA;context-&gt;notify_page == NULL and return error if so.&#xA;&#xA;general protection fault, probably for non-canonical address&#xA;    0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: maybe wild-memory-access in range [0x0005088000000300-&#xA;    0x0005088000000307]&#xA;CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1&#xA;Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014&#xA;RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; vmci_host_unlocked_ioctl+0x362/0x1f40&#xA; __x64_sys_ioctl+0x1a1/0x230&#xA; do_syscall_64+0x3a/0x90&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;CVE-2023-53241:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: call op_release, even when op_func returns an error&#xA;&#xA;For ops with &#34;trivial&#34; replies, nfsd4_encode_operation will shortcut&#xA;most of the encoding work and skip to just marshalling up the status.&#xA;One of the things it skips is calling op_release. This could cause a&#xA;memory leak in the layoutget codepath if there is an error at an&#xA;inopportune time.&#xA;&#xA;Have the compound processing engine always call op_release, even when&#xA;op_func sets an error in op-&gt;status. With this change, we also need&#xA;nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL&#xA;on error to avoid a double free.&#xA;CVE-2022-50350:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: iscsi: Fix a race condition between login_work and the login thread&#xA;&#xA;In case a malicious initiator sends some random data immediately after a&#xA;login PDU; the iscsi_target_sk_data_ready() callback will schedule the&#xA;login_work and, at the same time, the negotiation may end without clearing&#xA;the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are&#xA;required to complete the login).&#xA;&#xA;The login has been completed but the login_work function will find the&#xA;LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling&#xA;itself; at this point, if the initiator drops the connection, the&#xA;iscsit_conn structure will be freed, login_work will dereference a released&#xA;socket structure and the kernel crashes.&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000230&#xA;PF: supervisor write access in kernel mode&#xA;PF: error_code(0x0002) - not-present page&#xA;Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]&#xA;RIP: 0010:_raw_read_lock_bh+0x15/0x30&#xA;Call trace:&#xA; iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]&#xA; process_one_work+0x1e8/0x3c0&#xA;&#xA;Fix this bug by forcing login_work to stop after the login has been&#xA;completed and the socket callbacks have been restored.&#xA;&#xA;Add a comment to clearify the return values of iscsi_target_do_login()&#xA;CVE-2023-53438:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/MCE: Always save CS register on AMD Zen IF Poison errors&#xA;&#xA;The Instruction Fetch (IF) units on current AMD Zen-based systems do not&#xA;guarantee a synchronous #MC is delivered for poison consumption errors.&#xA;Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the&#xA;microarchitecture does guarantee that the exception is delivered within&#xA;the same context. In other words, the exact rIP is not known, but the&#xA;context is known to not have changed.&#xA;&#xA;There is no architecturally-defined method to determine this behavior.&#xA;&#xA;The Code Segment (CS) register is always valid on such IF unit poison&#xA;errors regardless of the value of MCG_STATUS[EIPV|RIPV].&#xA;&#xA;Add a quirk to save the CS register for poison consumption from the IF&#xA;unit banks.&#xA;&#xA;This is needed to properly determine the context of the error.&#xA;Otherwise, the severity grading function will assume the context is&#xA;IN_KERNEL due to the m-&gt;cs value being 0 (the initialized value). This&#xA;leads to unnecessary kernel panics on data poison errors due to the&#xA;kernel believing the poison consumption occurred in kernel context.&#xA;CVE-2025-39866:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs: writeback: fix use-after-free in __mark_inode_dirty()&#xA;&#xA;An use-after-free issue occurred when __mark_inode_dirty() get the&#xA;bdi_writeback that was in the progress of switching.&#xA;&#xA;CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1&#xA;......&#xA;pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : __mark_inode_dirty+0x124/0x418&#xA;lr : __mark_inode_dirty+0x118/0x418&#xA;sp : ffffffc08c9dbbc0&#xA;........&#xA;Call trace:&#xA; __mark_inode_dirty+0x124/0x418&#xA; generic_update_time+0x4c/0x60&#xA; file_modified+0xcc/0xd0&#xA; ext4_buffered_write_iter+0x58/0x124&#xA; ext4_file_write_iter+0x54/0x704&#xA; vfs_write+0x1c0/0x308&#xA; ksys_write+0x74/0x10c&#xA; __arm64_sys_write+0x1c/0x28&#xA; invoke_syscall+0x48/0x114&#xA; el0_svc_common.constprop.0+0xc0/0xe0&#xA; do_el0_svc+0x1c/0x28&#xA; el0_svc+0x40/0xe4&#xA; el0t_64_sync_handler+0x120/0x12c&#xA; el0t_64_sync+0x194/0x198&#xA;&#xA;Root cause is:&#xA;&#xA;systemd-random-seed                         kworker&#xA;----------------------------------------------------------------------&#xA;___mark_inode_dirty                     inode_switch_wbs_work_fn&#xA;&#xA;  spin_lock(&amp;inode-&gt;i_lock);&#xA;  inode_attach_wb&#xA;  locked_inode_to_wb_and_lock_list&#xA;     get inode-&gt;i_wb&#xA;     spin_unlock(&amp;inode-&gt;i_lock);&#xA;     spin_lock(&amp;wb-&gt;list_lock)&#xA;  spin_lock(&amp;inode-&gt;i_lock)&#xA;  inode_io_list_move_locked&#xA;  spin_unlock(&amp;wb-&gt;list_lock)&#xA;  spin_unlock(&amp;inode-&gt;i_lock)&#xA;                                    spin_lock(&amp;old_wb-&gt;list_lock)&#xA;                                      inode_do_switch_wbs&#xA;                                        spin_lock(&amp;inode-&gt;i_lock)&#xA;                                        inode-&gt;i_wb = new_wb&#xA;                                        spin_unlock(&amp;inode-&gt;i_lock)&#xA;                                    spin_unlock(&amp;old_wb-&gt;list_lock)&#xA;                                    wb_put_many(old_wb, nr_switched)&#xA;                                      cgwb_release&#xA;                                      old wb released&#xA;  wb_wakeup_delayed() accesses wb,&#xA;  then trigger the use-after-free&#xA;  issue&#xA;&#xA;Fix this race condition by holding inode spinlock until&#xA;wb_wakeup_delayed() finished.&#xA;CVE-2025-39865:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tee: fix NULL pointer dereference in tee_shm_put&#xA;&#xA;tee_shm_put have NULL pointer dereference:&#xA;&#xA;__optee_disable_shm_cache --&gt;&#xA;&#x9;shm = reg_pair_to_ptr(...);//shm maybe return NULL&#xA;        tee_shm_free(shm); --&gt;&#xA;&#x9;&#x9;tee_shm_put(shm);//crash&#xA;&#xA;Add check in tee_shm_put to fix it.&#xA;&#xA;panic log:&#xA;Unable to handle kernel paging request at virtual address 0000000000100cca&#xA;Mem abort info:&#xA;ESR = 0x0000000096000004&#xA;EC = 0x25: DABT (current EL), IL = 32 bits&#xA;SET = 0, FnV = 0&#xA;EA = 0, S1PTW = 0&#xA;FSC = 0x04: level 0 translation fault&#xA;Data abort info:&#xA;ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000&#xA;CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000&#xA;[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000&#xA;Internal error: Oops: 0000000096000004 [#1] SMP&#xA;CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----&#xA;6.6.0-39-generic #38&#xA;Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07&#xA;Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0&#xA;10/26/2022&#xA;pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : tee_shm_put+0x24/0x188&#xA;lr : tee_shm_free+0x14/0x28&#xA;sp : ffff001f98f9faf0&#xA;x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000&#xA;x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048&#xA;x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88&#xA;x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff&#xA;x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003&#xA;x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101&#xA;x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c&#xA;x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000&#xA;x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000&#xA;x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca&#xA;Call trace:&#xA;tee_shm_put+0x24/0x188&#xA;tee_shm_free+0x14/0x28&#xA;__optee_disable_shm_cache+0xa8/0x108&#xA;optee_shutdown+0x28/0x38&#xA;platform_shutdown+0x28/0x40&#xA;device_shutdown+0x144/0x2b0&#xA;kernel_power_off+0x3c/0x80&#xA;hibernate+0x35c/0x388&#xA;state_store+0x64/0x80&#xA;kobj_attr_store+0x14/0x28&#xA;sysfs_kf_write+0x48/0x60&#xA;kernfs_fop_write_iter+0x128/0x1c0&#xA;vfs_write+0x270/0x370&#xA;ksys_write+0x6c/0x100&#xA;__arm64_sys_write+0x20/0x30&#xA;invoke_syscall+0x4c/0x120&#xA;el0_svc_common.constprop.0+0x44/0xf0&#xA;do_el0_svc+0x24/0x38&#xA;el0_svc+0x24/0x88&#xA;el0t_64_sync_handler+0x134/0x150&#xA;el0t_64_sync+0x14c/0x15&#xA;CVE-2025-39883:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory&#xA;&#xA;When I did memory failure tests, below panic occurs:&#xA;&#xA;page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))&#xA;kernel BUG at include/linux/page-flags.h:616!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40&#xA;RIP: 0010:unpoison_memory+0x2f3/0x590&#xA;RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246&#xA;RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8&#xA;RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0&#xA;RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb&#xA;R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000&#xA;R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe&#xA;FS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; unpoison_memory+0x2f3/0x590&#xA; simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110&#xA; debugfs_attr_write+0x42/0x60&#xA; full_proxy_write+0x5b/0x80&#xA; vfs_write+0xd5/0x540&#xA; ksys_write+0x64/0xe0&#xA; do_syscall_64+0xb9/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f08f0314887&#xA;RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887&#xA;RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001&#xA;RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009&#xA;R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00&#xA; &lt;/TASK&gt;&#xA;Modules linked in: hwpoison_inject&#xA;---[ end trace 0000000000000000 ]---&#xA;RIP: 0010:unpoison_memory+0x2f3/0x590&#xA;RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246&#xA;RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8&#xA;RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0&#xA;RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb&#xA;R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000&#xA;R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe&#xA;FS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0&#xA;Kernel panic - not syncing: Fatal exception&#xA;Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)&#xA;---[ end Kernel panic - not syncing: Fatal exception ]---&#xA;&#xA;The root cause is that unpoison_memory() tries to check the PG_HWPoison&#xA;flags of an uninitialized page.  So VM_BUG_ON_PAGE(PagePoisoned(page)) is&#xA;triggered.  This can be reproduced by below steps:&#xA;&#xA;1.Offline memory block:&#xA;&#xA; echo offline &gt; /sys/devices/system/memory/memory12/state&#xA;&#xA;2.Get offlined memory pfn:&#xA;&#xA; page-types -b n -rlN&#xA;&#xA;3.Write pfn to unpoison-pfn&#xA;&#xA; echo &lt;pfn&gt; &gt; /sys/kernel/debug/hwpoison/unpoison-pfn&#xA;&#xA;This scenario can be identified by pfn_to_online_page() returning NULL. &#xA;And ZONE_DEVICE pages are never expected, so we can simply fail if&#xA;pfn_to_online_page() == NULL to fix the bug.&#xA;CVE-2022-50410:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Protect against send buffer overflow in NFSv2 READ&#xA;&#xA;Since before the git era, NFSD has conserved the number of pages&#xA;held by each nfsd thread by combining the RPC receive and send&#xA;buffers into a single array of pages. This works because there are&#xA;no cases where an operation needs a large RPC Call message and a&#xA;large RPC Reply at the same time.&#xA;&#xA;Once an RPC Call has been received, svc_process() updates&#xA;svc_rqst::rq_res to describe the part of rq_pages that can be&#xA;used for constructing the Reply. This means that the send buffer&#xA;(rq_res) shrinks when the received RPC record containing the RPC&#xA;Call is large.&#xA;&#xA;A client can force this shrinkage on TCP by sending a correctly-&#xA;formed RPC Call header contained in an RPC record that is&#xA;excessively large. The full maximum payload size cannot be&#xA;constructed in that case.&#xA;CVE-2025-39850:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects&#xA;&#xA;When the &#34;proxy&#34; option is enabled on a VXLAN device, the device will&#xA;suppress ARP requests and IPv6 Neighbor Solicitation messages if it is&#xA;able to reply on behalf of the remote host. That is, if a matching and&#xA;valid neighbor entry is configured on the VXLAN device whose MAC address&#xA;is not behind the &#34;any&#34; remote (0.0.0.0 / ::).&#xA;&#xA;The code currently assumes that the FDB entry for the neighbor&#39;s MAC&#xA;address points to a valid remote destination, but this is incorrect if&#xA;the entry is associated with an FDB nexthop group. This can result in a&#xA;NPD [1][3] which can be reproduced using [2][4].&#xA;&#xA;Fix by checking that the remote destination exists before dereferencing&#xA;it.&#xA;&#xA;[1]&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[...]&#xA;CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014&#xA;RIP: 0010:vxlan_xmit+0xb58/0x15f0&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dev_hard_start_xmit+0x5d/0x1c0&#xA; __dev_queue_xmit+0x246/0xfd0&#xA; packet_sendmsg+0x113a/0x1850&#xA; __sock_sendmsg+0x38/0x70&#xA; __sys_sendto+0x126/0x180&#xA; __x64_sys_sendto+0x24/0x30&#xA; do_syscall_64+0xa4/0x260&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;[2]&#xA; #!/bin/bash&#xA;&#xA; ip address add 192.0.2.1/32 dev lo&#xA;&#xA; ip nexthop add id 1 via 192.0.2.2 fdb&#xA; ip nexthop add id 10 group 1 fdb&#xA;&#xA; ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy&#xA;&#xA; ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0&#xA;&#xA; bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10&#xA;&#xA; arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3&#xA;&#xA;[3]&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[...]&#xA;CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014&#xA;RIP: 0010:vxlan_xmit+0x803/0x1600&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dev_hard_start_xmit+0x5d/0x1c0&#xA; __dev_queue_xmit+0x246/0xfd0&#xA; ip6_finish_output2+0x210/0x6c0&#xA; ip6_finish_output+0x1af/0x2b0&#xA; ip6_mr_output+0x92/0x3e0&#xA; ip6_send_skb+0x30/0x90&#xA; rawv6_sendmsg+0xe6e/0x12e0&#xA; __sock_sendmsg+0x38/0x70&#xA; __sys_sendto+0x126/0x180&#xA; __x64_sys_sendto+0x24/0x30&#xA; do_syscall_64+0xa4/0x260&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;RIP: 0033:0x7f383422ec77&#xA;&#xA;[4]&#xA; #!/bin/bash&#xA;&#xA; ip address add 2001:db8:1::1/128 dev lo&#xA;&#xA; ip nexthop add id 1 via 2001:db8:1::1 fdb&#xA; ip nexthop add id 10 group 1 fdb&#xA;&#xA; ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy&#xA;&#xA; ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0&#xA;&#xA; bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10&#xA;&#xA; ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0&#xA;CVE-2025-38700:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: libiscsi: Initialize iscsi_conn-&gt;dd_data only if memory is allocated&#xA;&#xA;In case of an ib_fast_reg_mr allocation failure during iSER setup, the&#xA;machine hits a panic because iscsi_conn-&gt;dd_data is initialized&#xA;unconditionally, even when no memory is allocated (dd_size == 0).  This&#xA;leads invalid pointer dereference during connection teardown.&#xA;&#xA;Fix by setting iscsi_conn-&gt;dd_data only if memory is actually allocated.&#xA;&#xA;Panic trace:&#xA;------------&#xA; iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12&#xA; iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers&#xA; BUG: unable to handle page fault for address: fffffffffffffff8&#xA; RIP: 0010:swake_up_locked.part.5+0xa/0x40&#xA; Call Trace:&#xA;  complete+0x31/0x40&#xA;  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]&#xA;  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]&#xA;  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]&#xA;  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]&#xA;  ? netlink_lookup+0x12f/0x1b0&#xA;  ? netlink_deliver_tap+0x2c/0x200&#xA;  netlink_unicast+0x1ab/0x280&#xA;  netlink_sendmsg+0x257/0x4f0&#xA;  ? _copy_from_user+0x29/0x60&#xA;  sock_sendmsg+0x5f/0x70&#xA;CVE-2025-38709:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;loop: Avoid updating block size under exclusive owner&#xA;&#xA;Syzbot came up with a reproducer where a loop device block size is&#xA;changed underneath a mounted filesystem. This causes a mismatch between&#xA;the block device block size and the block size stored in the superblock&#xA;causing confusion in various places such as fs/buffer.c. The particular&#xA;issue triggered by syzbot was a warning in __getblk_slow() due to&#xA;requested buffer size not matching block device block size.&#xA;&#xA;Fix the problem by getting exclusive hold of the loop device to change&#xA;its block size. This fails if somebody (such as filesystem) has already&#xA;an exclusive ownership of the block device and thus prevents modifying&#xA;the loop device under some exclusive owner which doesn&#39;t expect it.&#xA;CVE-2025-39697:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFS: Fix a race when updating an existing write&#xA;&#xA;After nfs_lock_and_join_requests() tests for whether the request is&#xA;still attached to the mapping, nothing prevents a call to&#xA;nfs_inode_remove_request() from succeeding until we actually lock the&#xA;page group.&#xA;The reason is that whoever called nfs_inode_remove_request() doesn&#39;t&#xA;necessarily have a lock on the page group head.&#xA;&#xA;So in order to avoid races, let&#39;s take the page group lock earlier in&#xA;nfs_lock_and_join_requests(), and hold it across the removal of the&#xA;request in nfs_inode_remove_request().&#xA;CVE-2025-39795:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;block: avoid possible overflow for chunk_sectors check in blk_stack_limits()&#xA;&#xA;In blk_stack_limits(), we check that the t-&gt;chunk_sectors value is a&#xA;multiple of the t-&gt;physical_block_size value.&#xA;&#xA;However, by finding the chunk_sectors value in bytes, we may overflow&#xA;the unsigned int which holds chunk_sectors, so change the check to be&#xA;based on sectors.&#xA;CVE-2022-50306:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: fix potential out of bound read in ext4_fc_replay_scan()&#xA;&#xA;For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain&#xA;space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read&#xA;when mounting corrupt file system image.&#xA;ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this&#xA;three tags will read data during scan, tag length couldn&#39;t less than data length&#xA;which will read.&#xA;CVE-2023-53292:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;blk-mq: fix NULL dereference on q-&gt;elevator in blk_mq_elv_switch_none&#xA;&#xA;After grabbing q-&gt;sysfs_lock, q-&gt;elevator may become NULL because of&#xA;elevator switch.&#xA;&#xA;Fix the NULL dereference on q-&gt;elevator by checking it with lock.&#xA;CVE-2024-57904:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: adc: at91: call input_free_device() on allocated iio_dev&#xA;&#xA;Current implementation of at91_ts_register() calls input_free_deivce()&#xA;on st-&gt;ts_input, however, the err label can be reached before the&#xA;allocated iio_dev is stored to st-&gt;ts_input. Thus call&#xA;input_free_device() on input instead of st-&gt;ts_input.&#xA;CVE-2025-39898:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2025-39971:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: fix idx validation in config queues msg&#xA;&#xA;Ensure idx is within range of active/initialized TCs when iterating over&#xA;vf-&gt;ch[idx] in i40e_vc_config_queues_msg().&#xA;CVE-2025-39998:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: target_core_configfs: Add length check to avoid buffer overflow&#xA;&#xA;A buffer overflow arises from the usage of snprintf to write into the&#xA;buffer &#34;buf&#34; in target_lu_gp_members_show function located in&#xA;/drivers/target/target_core_configfs.c. This buffer is allocated with&#xA;size LU_GROUP_NAME_BUF (256 bytes).&#xA;&#xA;snprintf(...) formats multiple strings into buf with the HBA name&#xA;(hba-&gt;hba_group.cg_item), a slash character, a devicename (dev-&gt;&#xA;dev_group.cg_item) and a newline character, the total formatted string&#xA;length may exceed the buffer size of 256 bytes.&#xA;&#xA;Since snprintf() returns the total number of bytes that would have been&#xA;written (the length of %s/%sn ), this value may exceed the buffer length&#xA;(256 bytes) passed to memcpy(), this will ultimately cause function&#xA;memcpy reporting a buffer overflow error.&#xA;&#xA;An additional check of the return value of snprintf() can avoid this&#xA;buffer overflow.&#xA;CVE-2023-53728:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;posix-timers: Ensure timer ID search-loop limit is valid&#xA;&#xA;posix_timer_add() tries to allocate a posix timer ID by starting from the&#xA;cached ID which was stored by the last successful allocation.&#xA;&#xA;This is done in a loop searching the ID space for a free slot one by&#xA;one. The loop has to terminate when the search wrapped around to the&#xA;starting point.&#xA;&#xA;But that&#39;s racy vs. establishing the starting point. That is read out&#xA;lockless, which leads to the following problem:&#xA;&#xA;CPU0&#x9;  &#x9;      &#x9;     &#x9;   CPU1&#xA;posix_timer_add()&#xA;  start = sig-&gt;posix_timer_id;&#xA;  lock(hash_lock);&#xA;  ...&#x9;&#x9;&#x9;&#x9;   posix_timer_add()&#xA;  if (++sig-&gt;posix_timer_id &lt; 0)&#xA;      &#x9;&#x9;&#x9;             start = sig-&gt;posix_timer_id;&#xA;     sig-&gt;posix_timer_id = 0;&#xA;&#xA;So CPU1 can observe a negative start value, i.e. -1, and the loop break&#xA;never happens because the condition can never be true:&#xA;&#xA;  if (sig-&gt;posix_timer_id == start)&#xA;     break;&#xA;&#xA;While this is unlikely to ever turn into an endless loop as the ID space is&#xA;huge (INT_MAX), the racy read of the start value caught the attention of&#xA;KCSAN and Dmitry unearthed that incorrectness.&#xA;&#xA;Rewrite it so that all id operations are under the hash lock.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-headers-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/kernel-headers-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/kernel-tools-devel-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/kernel-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-tools-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/kernel-tools-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-devel-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/kernel-devel-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="287.0.0.190.u185" version="5.10.0">
					<filename>python3-perf-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-perf-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="287.0.0.190.u185" version="5.10.0">
					<filename>bpftool-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/bpftool-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="287.0.0.190.u185" version="5.10.0">
					<filename>perf-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/perf-5.10.0-287.0.0.190.u185.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="287.0.0.190.u185" version="5.10.0">
					<filename>bpftool-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/bpftool-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-headers-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/kernel-headers-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-tools-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/kernel-tools-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="287.0.0.190.u185" version="5.10.0">
					<filename>python3-perf-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-perf-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/kernel-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-devel-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/kernel-devel-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="287.0.0.190.u185" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/kernel-tools-devel-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="287.0.0.190.u185" version="5.10.0">
					<filename>perf-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/perf-5.10.0-287.0.0.190.u185.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2288</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5824&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5824" id="CVE-2023-5824" title="CVE-2023-5824" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54574&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54574" id="CVE-2025-54574" title="CVE-2025-54574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59362&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59362" id="CVE-2025-59362" title="CVE-2025-59362" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62168" id="CVE-2025-62168" title="CVE-2025-62168" type="cve"></reference>
		</references>
		<description>CVE-2023-5824:A flaw was found in Squid. The limits applied for validation of HTTP response headers are applied before caching. However, Squid may grow a cached HTTP response header beyond the configured maximum size, causing a stall or crash of the worker process when a large header is retrieved from the disk cache, resulting in a denial of service.&#xA;CVE-2025-54574:Squid is a caching proxy for the Web. In versions 6.3 and below, Squid is vulnerable to a heap buffer overflow and possible remote code execution attack when processing URN due to incorrect buffer management. This has been fixed in version 6.4. To work around this issue, disable URN access permissions.&#xA;CVE-2025-59362:Squid through 7.1 mishandles ASN.1 encoding of long SNMP OIDs. This occurs in asn_build_objid in lib/snmplib/asn1.c.&#xA;CVE-2025-62168:Squid is a caching proxy for the Web. In Squid versions prior to 7.2, a failure to redact HTTP authentication credentials in error handling allows information disclosure. The vulnerability allows a script to bypass browser security protections and learn the credentials a trusted client uses to authenticate. This potentially allows a remote client to identify security tokens or credentials used internally by a web application using Squid for backend load balancing. These attacks do not require Squid to be configured with HTTP authentication. The vulnerability is fixed in version 7.2. As a workaround, disable debug information in administrator mailto links generated by Squid by configuring squid.conf with email_err_data off.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="7" name="squid" release="28.u11" version="4.9">
					<filename>squid-4.9-28.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/squid-4.9-28.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="28.u11" version="4.9">
					<filename>squid-4.9-28.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/squid-4.9-28.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2289</id>
		<title>An update for open-vm-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-41244&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-41244" id="CVE-2025-41244" title="CVE-2025-41244" type="cve"></reference>
		</references>
		<description>CVE-2025-41244:VMware Aria Operations and VMware Tools contain a local privilege escalation vulnerability. A malicious local actor with non-administrative privileges having access to a VM with VMware Tools installed and managed by Aria Operations with SDMP enabled may exploit this vulnerability to escalate privileges to root on the same VM.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="open-vm-tools" release="4.u4" version="12.0.5">
					<filename>open-vm-tools-12.0.5-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/open-vm-tools-12.0.5-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-desktop" release="4.u4" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/open-vm-tools-desktop-12.0.5-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="open-vm-tools-sdmp" release="4.u4" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/open-vm-tools-sdmp-12.0.5-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-desktop" release="4.u4" version="12.0.5">
					<filename>open-vm-tools-desktop-12.0.5-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/open-vm-tools-desktop-12.0.5-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools" release="4.u4" version="12.0.5">
					<filename>open-vm-tools-12.0.5-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/open-vm-tools-12.0.5-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="open-vm-tools-sdmp" release="4.u4" version="12.0.5">
					<filename>open-vm-tools-sdmp-12.0.5-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/open-vm-tools-sdmp-12.0.5-4.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2290</id>
		<title>An update for sssd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11561&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11561" id="CVE-2025-11561" title="CVE-2025-11561" type="cve"></reference>
		</references>
		<description>CVE-2025-11561:A flaw was found in the integration of Active Directory and the System Security Services Daemon (SSSD) on Linux systems. In default configurations, the Kerberos local authentication plugin (sssd_krb5_localauth_plugin) is enabled, but a fallback to the an2ln plugin is possible. This fallback allows an attacker with permission to modify certain AD attributes (such as userPrincipalName or samAccountName) to impersonate privileged users, potentially resulting in unauthorized access or privilege escalation on domain-joined Linux hosts.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="sssd" release="22.u14" version="2.6.1">
					<filename>sssd-2.6.1-22.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/sssd-2.6.1-22.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sssd-devel" release="22.u14" version="2.6.1">
					<filename>sssd-devel-2.6.1-22.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/sssd-devel-2.6.1-22.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-sssd" release="22.u14" version="2.6.1">
					<filename>python3-sssd-2.6.1-22.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-sssd-2.6.1-22.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-sssd" release="22.u14" version="2.6.1">
					<filename>python3-sssd-2.6.1-22.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-sssd-2.6.1-22.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sssd" release="22.u14" version="2.6.1">
					<filename>sssd-2.6.1-22.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/sssd-2.6.1-22.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sssd-devel" release="22.u14" version="2.6.1">
					<filename>sssd-devel-2.6.1-22.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/sssd-devel-2.6.1-22.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sssd-help" release="22.u14" version="2.6.1">
					<filename>sssd-help-2.6.1-22.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/sssd-help-2.6.1-22.u14.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2291</id>
		<title>An update for logback is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12798" id="CVE-2024-12798" title="CVE-2024-12798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12801&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12801" id="CVE-2024-12801" title="CVE-2024-12801" type="cve"></reference>
		</references>
		<description>CVE-2024-12798:ACE vulnerability in JaninoEventEvaluator  by QOS.CH logback-core&#xA;      upto including version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 in Java applications allows&#xA;      attacker to execute arbitrary code by compromising an existing&#xA;      logback configuration file or by injecting an environment variable&#xA;      before program execution.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Malicious logback configuration files can allow the attacker to execute &#xA;arbitrary code using the JaninoEventEvaluator extension.&#xA;&#xA;&#xA;&#xA;A successful attack requires the user to have write access to a &#xA;configuration file. Alternatively, the attacker could inject a malicious &#xA;environment variable pointing to a malicious configuration file. In both &#xA;cases, the attack requires existing privilege.&#xA;CVE-2024-12801:Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12  on the Java platform, allows an attacker to &#xA;forge requests by compromising logback configuration files in XML.&#xA;&#xA;&#xA;&#xA;The attacks involves the modification of DOCTYPE declaration in  XML configuration files.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="logback" release="4.u2" version="1.2.8">
					<filename>logback-1.2.8-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/logback-1.2.8-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="logback-access" release="4.u2" version="1.2.8">
					<filename>logback-access-1.2.8-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/logback-access-1.2.8-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="logback-examples" release="4.u2" version="1.2.8">
					<filename>logback-examples-1.2.8-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/logback-examples-1.2.8-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="logback-help" release="4.u2" version="1.2.8">
					<filename>logback-help-1.2.8-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/logback-help-1.2.8-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2292</id>
		<title>An update for patch is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17942&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-17942" id="CVE-2018-17942" title="CVE-2018-17942" type="cve"></reference>
		</references>
		<description>CVE-2018-17942:The convert_to_decimal function in vasnprintf.c in Gnulib before 2018-09-23 has a heap-based buffer overflow because memory is not allocated for a trailing &#39;\0&#39; character during %f processing.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="patch-help" release="15.u2" version="2.7.6">
					<filename>patch-help-2.7.6-15.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/patch-help-2.7.6-15.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="patch" release="15.u2" version="2.7.6">
					<filename>patch-2.7.6-15.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/patch-2.7.6-15.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="patch" release="15.u2" version="2.7.6">
					<filename>patch-2.7.6-15.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/patch-2.7.6-15.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2293</id>
		<title>An update for fetchmail is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61962&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61962" id="CVE-2025-61962" title="CVE-2025-61962" type="cve"></reference>
		</references>
		<description>CVE-2025-61962:In fetchmail before 6.5.6, the SMTP client can crash when authenticating upon receiving a 334 status code in a malformed context.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="fetchmail" release="3.u1" version="6.4.22">
					<filename>fetchmail-6.4.22-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/fetchmail-6.4.22-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fetchmail" release="3.u1" version="6.4.22">
					<filename>fetchmail-6.4.22-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/fetchmail-6.4.22-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2294</id>
		<title>An update for xorg-x11-server-xwayland is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26594&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26594" id="CVE-2025-26594" title="CVE-2025-26594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26595&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26595" id="CVE-2025-26595" title="CVE-2025-26595" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26596&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26596" id="CVE-2025-26596" title="CVE-2025-26596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26597&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26597" id="CVE-2025-26597" title="CVE-2025-26597" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26598&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26598" id="CVE-2025-26598" title="CVE-2025-26598" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26599&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26599" id="CVE-2025-26599" title="CVE-2025-26599" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26000&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26000" id="CVE-2025-26600" title="CVE-2025-26600" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26601" id="CVE-2025-26601" title="CVE-2025-26601" type="cve"></reference>
		</references>
		<description>CVE-2025-26594:A use-after-free flaw was found in X.Org and Xwayland. The root cursor is referenced in the X server as a global variable. If a client frees the root cursor, the internal reference points to freed memory and causes a use-after-free.&#xA;CVE-2025-26595:A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.&#xA;CVE-2025-26596:A heap overflow flaw was found in X.Org and Xwayland. The computation of the length in XkbSizeKeySyms() differs from what is written in XkbWriteKeySyms(), which may lead to a heap-based buffer overflow.&#xA;CVE-2025-26597:A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.&#xA;CVE-2025-26598:An out-of-bounds write flaw was found in X.Org and Xwayland. The function GetBarrierDevice() searches for the pointer device based on its device ID and returns the matching value, or supposedly NULL, if no match was found. However, the code will return the last element of the list if no matching device ID is found, which can lead to out-of-bounds memory access.&#xA;CVE-2025-26599:An access to an uninitialized pointer flaw was found in X.Org and Xwayland. The function compCheckRedirect() may fail if it cannot allocate the backing pixmap. In that case, compRedirectWindow() will return a BadAlloc error without validating the window tree marked just before, which leaves the validated data partly initialized and the use of an uninitialized pointer later.&#xA;CVE-2025-26600:A use-after-free flaw was found in X.Org and Xwayland. When a device is removed while still frozen, the events queued for that device remain while the device is freed. Replaying the events will cause a use-after-free.&#xA;CVE-2025-26601:A use-after-free flaw was found in X.Org and Xwayland. When changing an alarm, the values of the change mask are evaluated one after the other, changing the trigger values as requested, and eventually, SyncInitTrigger() is called. If one of the changes triggers an error, the function will return early, not adding the new sync object, possibly causing a use-after-free when the alarm eventually triggers.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland" release="6.u6" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/xorg-x11-server-Xwayland-22.1.2-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="6.u6" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-6.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/xorg-x11-server-Xwayland-devel-22.1.2-6.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland" release="6.u6" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-22.1.2-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/xorg-x11-server-Xwayland-22.1.2-6.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xwayland-devel" release="6.u6" version="22.1.2">
					<filename>xorg-x11-server-Xwayland-devel-22.1.2-6.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/xorg-x11-server-Xwayland-devel-22.1.2-6.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2295</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9900&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9900" id="CVE-2025-9900" title="CVE-2025-9900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9165&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9165" id="CVE-2025-9165" title="CVE-2025-9165" type="cve"></reference>
		</references>
		<description>CVE-2025-9900:A flaw was found in Libtiff. This vulnerability is a &#34;write-what-where&#34; condition, triggered when the library processes a specially crafted TIFF image file.&#xA;&#xA;By providing an abnormally large image height value in the file&#39;s metadata, an attacker can trick the library into writing attacker-controlled color data to an arbitrary memory location. This memory corruption can be exploited to cause a denial of service (application crash) or to achieve arbitrary code execution with the permissions of the user.&#xA;CVE-2025-9165:A flaw has been found in LibTIFF 4.7.0. This affects the function _TIFFmallocExt/_TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the file tools/tiffcmp.c of the component tiffcmp. Executing manipulation can lead to memory leak. The attack is restricted to local execution. This attack is characterized by high complexity. It is indicated that the exploitability is difficult. The exploit has been published and may be used. There is ongoing doubt regarding the real existence of this vulnerability. This patch is called ed141286a37f6e5ddafb5069347ff5d587e7a4e0. It is best practice to apply a patch to resolve this issue. A researcher disputes the security impact of this issue, because &#34;this is a memory leak on a command line tool that is about to exit anyway&#34;. In the reply the project maintainer declares this issue as &#34;a simple &#39;bug&#39; when leaving the command line tool and (...) not a security issue at all&#34;.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="45.u21" version="4.3.0">
					<filename>libtiff-static-4.3.0-45.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libtiff-static-4.3.0-45.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="45.u21" version="4.3.0">
					<filename>libtiff-4.3.0-45.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libtiff-4.3.0-45.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="45.u21" version="4.3.0">
					<filename>libtiff-devel-4.3.0-45.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libtiff-devel-4.3.0-45.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="45.u21" version="4.3.0">
					<filename>libtiff-tools-4.3.0-45.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libtiff-tools-4.3.0-45.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff" release="45.u21" version="4.3.0">
					<filename>libtiff-4.3.0-45.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libtiff-4.3.0-45.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="45.u21" version="4.3.0">
					<filename>libtiff-static-4.3.0-45.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libtiff-static-4.3.0-45.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="45.u21" version="4.3.0">
					<filename>libtiff-devel-4.3.0-45.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libtiff-devel-4.3.0-45.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="45.u21" version="4.3.0">
					<filename>libtiff-tools-4.3.0-45.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libtiff-tools-4.3.0-45.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="45.u21" version="4.3.0">
					<filename>libtiff-help-4.3.0-45.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libtiff-help-4.3.0-45.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2296</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8277&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8277" id="CVE-2025-8277" title="CVE-2025-8277" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8114&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8114" id="CVE-2025-8114" title="CVE-2025-8114" type="cve"></reference>
		</references>
		<description>CVE-2025-8277:A flaw was found in libssh&#39;s handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.&#xA;CVE-2025-8114:A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="13.u8" version="0.9.6">
					<filename>libssh-devel-0.9.6-13.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libssh-devel-0.9.6-13.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh" release="13.u8" version="0.9.6">
					<filename>libssh-0.9.6-13.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libssh-0.9.6-13.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="13.u8" version="0.9.6">
					<filename>libssh-0.9.6-13.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libssh-0.9.6-13.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="13.u8" version="0.9.6">
					<filename>libssh-devel-0.9.6-13.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libssh-devel-0.9.6-13.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="13.u8" version="0.9.6">
					<filename>libssh-help-0.9.6-13.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libssh-help-0.9.6-13.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2297</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27831&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27831" id="CVE-2025-27831" title="CVE-2025-27831" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48708&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48708" id="CVE-2025-48708" title="CVE-2025-48708" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43115&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-43115" id="CVE-2023-43115" title="CVE-2023-43115" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59798" id="CVE-2025-59798" title="CVE-2025-59798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59799&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59799" id="CVE-2025-59799" title="CVE-2025-59799" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59800&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59800" id="CVE-2025-59800" title="CVE-2025-59800" type="cve"></reference>
		</references>
		<description>CVE-2025-27831:An issue was discovered in Artifex Ghostscript before 10.05.0. The DOCXWRITE TXTWRITE device has a text buffer overflow via long characters to devices/vector/doc_common.c.&#xA;CVE-2025-48708:gs_lib_ctx_stash_sanitized_arg in base/gslibctx.c in Artifex Ghostscript before 10.05.1 lacks argument sanitization for the # case. A created PDF document includes its password in cleartext.&#xA;CVE-2023-43115:In Artifex Ghostscript through 10.01.2, gdevijs.c in GhostPDL can lead to remote code execution via crafted PostScript documents because they can switch to the IJS device, or change the IjsServer parameter, after SAFER has been activated. NOTE: it is a documented risk that the IJS server can be specified on a gs command line (the IJS device inherently must execute a command to start the IJS server).&#xA;CVE-2025-59798:Artifex Ghostscript through 10.05.1 has a stack-based buffer overflow in pdf_write_cmap in devices/vector/gdevpdtw.c.&#xA;CVE-2025-59799:Artifex Ghostscript through 10.05.1 has a stack-based buffer overflow in pdfmark_coerce_dest in devices/vector/gdevpdfm.c via a large size value.&#xA;CVE-2025-59800:In Artifex Ghostscript through 10.05.1, ocr_begin_page in devices/gdevpdfocr.c has an integer overflow that leads to a heap-based buffer overflow in ocr_line8.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="21.u17" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-21.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ghostscript-devel-9.55.0-21.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript" release="21.u17" version="9.55.0">
					<filename>ghostscript-9.55.0-21.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ghostscript-9.55.0-21.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="21.u17" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-21.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ghostscript-tools-dvipdf-9.55.0-21.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="21.u17" version="9.55.0">
					<filename>ghostscript-9.55.0-21.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/ghostscript-9.55.0-21.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="21.u17" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-21.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/ghostscript-devel-9.55.0-21.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="21.u17" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-21.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/ghostscript-tools-dvipdf-9.55.0-21.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="21.u17" version="9.55.0">
					<filename>ghostscript-help-9.55.0-21.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ghostscript-help-9.55.0-21.u17.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2298</id>
		<title>An update for udisks2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8067&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8067" id="CVE-2025-8067" title="CVE-2025-8067" type="cve"></reference>
		</references>
		<description>CVE-2025-8067:A flaw was found in the Udisks daemon, where it allows unprivileged users to create loop devices using the D-BUS system. This is achieved via the loop device handler, which handles requests sent through the D-BUS interface. As two of the parameters of this handle, it receives the file descriptor list and index specifying the file where the loop device should be backed. The function itself validates the index value to ensure it isn&#39;t bigger than the maximum value allowed. However, it fails to validate the lower bound, allowing the index parameter to be a negative value. Under these circumstances, an attacker can cause the UDisks daemon to crash or perform a local privilege escalation by gaining access to files owned by privileged users.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="udisks2-vdo" release="9.u10" version="2.9.4">
					<filename>udisks2-vdo-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/udisks2-vdo-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libudisks2-devel" release="9.u10" version="2.9.4">
					<filename>libudisks2-devel-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libudisks2-devel-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2" release="9.u10" version="2.9.4">
					<filename>udisks2-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/udisks2-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libudisks2" release="9.u10" version="2.9.4">
					<filename>libudisks2-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libudisks2-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-lsm" release="9.u10" version="2.9.4">
					<filename>udisks2-lsm-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/udisks2-lsm-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-lvm2" release="9.u10" version="2.9.4">
					<filename>udisks2-lvm2-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/udisks2-lvm2-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="udisks2-zram" release="9.u10" version="2.9.4">
					<filename>udisks2-zram-2.9.4-9.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/udisks2-zram-2.9.4-9.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libudisks2" release="9.u10" version="2.9.4">
					<filename>libudisks2-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libudisks2-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libudisks2-devel" release="9.u10" version="2.9.4">
					<filename>libudisks2-devel-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libudisks2-devel-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-lvm2" release="9.u10" version="2.9.4">
					<filename>udisks2-lvm2-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/udisks2-lvm2-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2" release="9.u10" version="2.9.4">
					<filename>udisks2-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/udisks2-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-lsm" release="9.u10" version="2.9.4">
					<filename>udisks2-lsm-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/udisks2-lsm-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-vdo" release="9.u10" version="2.9.4">
					<filename>udisks2-vdo-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/udisks2-vdo-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="udisks2-zram" release="9.u10" version="2.9.4">
					<filename>udisks2-zram-2.9.4-9.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/udisks2-zram-2.9.4-9.u10.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2299</id>
		<title>An update for apache-mime4j is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45787&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-45787" id="CVE-2022-45787" title="CVE-2022-45787" type="cve"></reference>
		</references>
		<description>CVE-2022-45787:Unproper laxist permissions on the temporary files used by MIME4J TempFileStorageProvider may lead to information disclosure to other local users. This issue affects Apache James MIME4J version 0.8.8 and prior versions.&#xA;&#xA;We recommend users to upgrade to MIME4j version 0.8.9 or later.&#xA;&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="apache-mime4j" release="3.u2" version="0.8.3">
					<filename>apache-mime4j-0.8.3-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/apache-mime4j-0.8.3-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mime4j-javadoc" release="3.u2" version="0.8.3">
					<filename>apache-mime4j-javadoc-0.8.3-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/apache-mime4j-javadoc-0.8.3-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2300</id>
		<title>An update for sqlite is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6965&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6965" id="CVE-2025-6965" title="CVE-2025-6965" type="cve"></reference>
		</references>
		<description>CVE-2025-6965:There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="sqlite-devel" release="7.u5" version="3.37.2">
					<filename>sqlite-devel-3.37.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/sqlite-devel-3.37.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sqlite" release="7.u5" version="3.37.2">
					<filename>sqlite-3.37.2-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/sqlite-3.37.2-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite" release="7.u5" version="3.37.2">
					<filename>sqlite-3.37.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/sqlite-3.37.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite-devel" release="7.u5" version="3.37.2">
					<filename>sqlite-devel-3.37.2-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/sqlite-devel-3.37.2-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sqlite-help" release="7.u5" version="3.37.2">
					<filename>sqlite-help-3.37.2-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/sqlite-help-3.37.2-7.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2301</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-10230&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-10230" id="CVE-2025-10230" title="CVE-2025-10230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9640&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9640" id="CVE-2025-9640" title="CVE-2025-9640" type="cve"></reference>
		</references>
		<description>CVE-2025-10230:A flaw was found in Samba, in the front-end WINS hook handling: NetBIOS names from registration packets are passed to a shell without proper validation or escaping. Unsanitized NetBIOS name data from WINS registration packets are inserted into a shell command and executed by the Samba Active Directory Domain Controller’s wins hook, allowing an unauthenticated network attacker to achieve remote command execution as the Samba process.&#xA;CVE-2025-9640:A flaw was found in Samba, in the vfs_streams_xattr module, where uninitialized heap memory could be written into alternate data streams. This allows an authenticated user to read residual memory content that may include sensitive data, resulting in an information disclosure vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="samba-krb5-printing" release="14.u9" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-krb5-printing-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-krb5-locator" release="14.u9" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-winbind-krb5-locator-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-modules" release="14.u9" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-winbind-modules-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-dc" release="14.u9" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-samba-dc-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba" release="14.u9" version="4.17.5">
					<filename>samba-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient-devel" release="14.u9" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libsmbclient-devel-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-bind-dlz" release="14.u9" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-dc-bind-dlz-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba-test" release="14.u9" version="4.17.5">
					<filename>python3-samba-test-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-samba-test-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient" release="14.u9" version="4.17.5">
					<filename>libwbclient-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libwbclient-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client-libs" release="14.u9" version="4.17.5">
					<filename>samba-client-libs-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-client-libs-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common-tools" release="14.u9" version="4.17.5">
					<filename>samba-common-tools-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-common-tools-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-provision" release="14.u9" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-dc-provision-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-client" release="14.u9" version="4.17.5">
					<filename>samba-client-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-client-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc" release="14.u9" version="4.17.5">
					<filename>samba-dc-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-dc-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-dc-libs" release="14.u9" version="4.17.5">
					<filename>samba-dc-libs-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-dc-libs-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-test" release="14.u9" version="4.17.5">
					<filename>samba-test-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-test-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-samba" release="14.u9" version="4.17.5">
					<filename>python3-samba-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-samba-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-common" release="14.u9" version="4.17.5">
					<filename>samba-common-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-common-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind-clients" release="14.u9" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-winbind-clients-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-winbind" release="14.u9" version="4.17.5">
					<filename>samba-winbind-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-winbind-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmbclient" release="14.u9" version="4.17.5">
					<filename>libsmbclient-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libsmbclient-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-devel" release="14.u9" version="4.17.5">
					<filename>samba-devel-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-devel-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-help" release="14.u9" version="4.17.5">
					<filename>samba-help-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-help-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-usershares" release="14.u9" version="4.17.5">
					<filename>samba-usershares-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-usershares-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwbclient-devel" release="14.u9" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libwbclient-devel-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="samba-libs" release="14.u9" version="4.17.5">
					<filename>samba-libs-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/samba-libs-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ctdb" release="14.u9" version="4.17.5">
					<filename>ctdb-4.17.5-14.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/ctdb-4.17.5-14.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-krb5-printing" release="14.u9" version="4.17.5">
					<filename>samba-krb5-printing-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-krb5-printing-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba" release="14.u9" version="4.17.5">
					<filename>samba-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient" release="14.u9" version="4.17.5">
					<filename>libwbclient-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libwbclient-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwbclient-devel" release="14.u9" version="4.17.5">
					<filename>libwbclient-devel-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libwbclient-devel-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient" release="14.u9" version="4.17.5">
					<filename>libsmbclient-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libsmbclient-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common" release="14.u9" version="4.17.5">
					<filename>samba-common-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-common-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-vfs-glusterfs" release="14.u9" version="4.17.5">
					<filename>samba-vfs-glusterfs-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-vfs-glusterfs-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-test" release="14.u9" version="4.17.5">
					<filename>python3-samba-test-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-samba-test-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client-libs" release="14.u9" version="4.17.5">
					<filename>samba-client-libs-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-client-libs-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-client" release="14.u9" version="4.17.5">
					<filename>samba-client-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-client-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-libs" release="14.u9" version="4.17.5">
					<filename>samba-dc-libs-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-dc-libs-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-libs" release="14.u9" version="4.17.5">
					<filename>samba-libs-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-libs-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba" release="14.u9" version="4.17.5">
					<filename>python3-samba-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-samba-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc" release="14.u9" version="4.17.5">
					<filename>samba-dc-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-dc-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-provision" release="14.u9" version="4.17.5">
					<filename>samba-dc-provision-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-dc-provision-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-help" release="14.u9" version="4.17.5">
					<filename>samba-help-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-help-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-usershares" release="14.u9" version="4.17.5">
					<filename>samba-usershares-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-usershares-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ctdb" release="14.u9" version="4.17.5">
					<filename>ctdb-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ctdb-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind" release="14.u9" version="4.17.5">
					<filename>samba-winbind-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-winbind-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-modules" release="14.u9" version="4.17.5">
					<filename>samba-winbind-modules-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-winbind-modules-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmbclient-devel" release="14.u9" version="4.17.5">
					<filename>libsmbclient-devel-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libsmbclient-devel-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-samba-dc" release="14.u9" version="4.17.5">
					<filename>python3-samba-dc-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-samba-dc-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-dc-bind-dlz" release="14.u9" version="4.17.5">
					<filename>samba-dc-bind-dlz-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-dc-bind-dlz-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-devel" release="14.u9" version="4.17.5">
					<filename>samba-devel-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-devel-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-test" release="14.u9" version="4.17.5">
					<filename>samba-test-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-test-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-clients" release="14.u9" version="4.17.5">
					<filename>samba-winbind-clients-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-winbind-clients-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-winbind-krb5-locator" release="14.u9" version="4.17.5">
					<filename>samba-winbind-krb5-locator-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-winbind-krb5-locator-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="samba-common-tools" release="14.u9" version="4.17.5">
					<filename>samba-common-tools-4.17.5-14.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-common-tools-4.17.5-14.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="samba-pidl" release="14.u9" version="4.17.5">
					<filename>samba-pidl-4.17.5-14.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/samba-pidl-4.17.5-14.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2302</id>
		<title>An update for nss is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22747&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-22747" id="CVE-2022-22747" title="CVE-2022-22747" type="cve"></reference>
		</references>
		<description>CVE-2022-22747:After accepting an untrusted certificate, handling an empty pkcs7 sequence as part of the certificate data could have lead to a crash. This crash is believed to be unexploitable. This vulnerability affects Firefox ESR &lt; 91.5, Firefox &lt; 96, and Thunderbird &lt; 91.5.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="nss-devel" release="10.u3" version="3.72.0">
					<filename>nss-devel-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-devel-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss-util-devel" release="10.u3" version="3.72.0">
					<filename>nss-util-devel-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-util-devel-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss" release="10.u3" version="3.72.0">
					<filename>nss-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss-softokn" release="10.u3" version="3.72.0">
					<filename>nss-softokn-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-softokn-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss-util" release="10.u3" version="3.72.0">
					<filename>nss-util-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-util-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss-softokn-devel" release="10.u3" version="3.72.0">
					<filename>nss-softokn-devel-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-softokn-devel-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss-help" release="10.u3" version="3.72.0">
					<filename>nss-help-3.72.0-10.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/nss-help-3.72.0-10.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss-softokn-devel" release="10.u3" version="3.72.0">
					<filename>nss-softokn-devel-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-softokn-devel-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss-util" release="10.u3" version="3.72.0">
					<filename>nss-util-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-util-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss-help" release="10.u3" version="3.72.0">
					<filename>nss-help-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-help-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss-softokn" release="10.u3" version="3.72.0">
					<filename>nss-softokn-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-softokn-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss-devel" release="10.u3" version="3.72.0">
					<filename>nss-devel-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-devel-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss-util-devel" release="10.u3" version="3.72.0">
					<filename>nss-util-devel-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-util-devel-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss" release="10.u3" version="3.72.0">
					<filename>nss-3.72.0-10.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/nss-3.72.0-10.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2303</id>
		<title>An update for python-xmltodict is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9375&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9375" id="CVE-2025-9375" title="CVE-2025-9375" type="cve"></reference>
		</references>
		<description>CVE-2025-9375:XML Injection vulnerability in xmltodict allows Input Data Manipulation.&#xA;This issue affects xmltodict: from 0.14.2 before 0.15.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="python3-xmltodict" release="1" version="1.0.0">
					<filename>python3-xmltodict-1.0.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-xmltodict-1.0.0-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2304</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59375&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59375" id="CVE-2025-59375" title="CVE-2025-59375" type="cve"></reference>
		</references>
		<description>CVE-2025-59375:libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="expat" release="17.u5" version="2.4.1">
					<filename>expat-2.4.1-17.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/expat-2.4.1-17.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat-devel" release="17.u5" version="2.4.1">
					<filename>expat-devel-2.4.1-17.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/expat-devel-2.4.1-17.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat" release="17.u5" version="2.4.1">
					<filename>expat-2.4.1-17.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/expat-2.4.1-17.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat-devel" release="17.u5" version="2.4.1">
					<filename>expat-devel-2.4.1-17.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/expat-devel-2.4.1-17.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="expat-help" release="17.u5" version="2.4.1">
					<filename>expat-help-2.4.1-17.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/expat-help-2.4.1-17.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2305</id>
		<title>An update for perl-JSON-XS is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40928&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40928" id="CVE-2025-40928" title="CVE-2025-40928" type="cve"></reference>
		</references>
		<description>CVE-2025-40928:JSON::XS before version 4.04 for Perl has an integer buffer overflow causing a segfault when parsing crafted JSON, enabling denial-of-service attacks or other unspecified impact&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="1" name="perl-JSON-XS" release="2.u1" version="4.03">
					<filename>perl-JSON-XS-4.03-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/perl-JSON-XS-4.03-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="perl-JSON-XS" release="2.u1" version="4.03">
					<filename>perl-JSON-XS-4.03-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/perl-JSON-XS-4.03-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="perl-JSON-XS-help" release="2.u1" version="4.03">
					<filename>perl-JSON-XS-help-4.03-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/perl-JSON-XS-help-4.03-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2306</id>
		<title>An update for yasm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33454&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-33454" id="CVE-2021-33454" title="CVE-2021-33454" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33464&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-33464" id="CVE-2021-33464" title="CVE-2021-33464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29579&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29579" id="CVE-2023-29579" title="CVE-2023-29579" type="cve"></reference>
		</references>
		<description>CVE-2021-33454:An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in yasm_expr_get_intnum() in libyasm/expr.c.&#xA;CVE-2021-33464:An issue was discovered in yasm version 1.3.0. There is a heap-buffer-overflow in inc_fopen() in modules/preprocs/nasm/nasm-pp.c.&#xA;CVE-2023-29579:yasm 1.3.0.55.g101bc was discovered to contain a stack overflow via the component yasm/yasm+0x43b466 in vsprintf. Note: This has been disputed by third parties who argue this is a bug and not a security issue because yasm is a standalone program not designed to run untrusted code.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="yasm" release="13.u4" version="1.3.0">
					<filename>yasm-1.3.0-13.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/yasm-1.3.0-13.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yasm" release="13.u4" version="1.3.0">
					<filename>yasm-1.3.0-13.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/yasm-1.3.0-13.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2307</id>
		<title>An update for polkit is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7519&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7519" id="CVE-2025-7519" title="CVE-2025-7519" type="cve"></reference>
		</references>
		<description>CVE-2025-7519:A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it&#39;s required to place the malicious policy file properly.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="polkit" release="11.u3" version="0.120">
					<filename>polkit-0.120-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/polkit-0.120-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="polkit-libs" release="11.u3" version="0.120">
					<filename>polkit-libs-0.120-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/polkit-libs-0.120-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="polkit-devel" release="11.u3" version="0.120">
					<filename>polkit-devel-0.120-11.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/polkit-devel-0.120-11.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="polkit-help" release="11.u3" version="0.120">
					<filename>polkit-help-0.120-11.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/polkit-help-0.120-11.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="polkit-devel" release="11.u3" version="0.120">
					<filename>polkit-devel-0.120-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/polkit-devel-0.120-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="polkit-libs" release="11.u3" version="0.120">
					<filename>polkit-libs-0.120-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/polkit-libs-0.120-11.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="polkit" release="11.u3" version="0.120">
					<filename>polkit-0.120-11.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/polkit-0.120-11.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2308</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49844&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49844" id="CVE-2025-49844" title="CVE-2025-49844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46817" id="CVE-2025-46817" title="CVE-2025-46817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46819&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46819" id="CVE-2025-46819" title="CVE-2025-46819" type="cve"></reference>
		</references>
		<description>CVE-2025-49844:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free and potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.&#xA;CVE-2025-46817:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2.&#xA;CVE-2025-46819:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted LUA script to read out-of-bound data or crash the server and subsequent denial of service. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u13" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/redis5-devel-5.0.7-6.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u13" version="5.0.7">
					<filename>redis5-5.0.7-6.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/redis5-5.0.7-6.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u13" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/redis5-doc-5.0.7-6.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u13" version="5.0.7">
					<filename>redis5-5.0.7-6.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/redis5-5.0.7-6.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u13" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/redis5-devel-5.0.7-6.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2309</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8194&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8194" id="CVE-2025-8194" title="CVE-2025-8194" type="cve"></reference>
		</references>
		<description>CVE-2025-8194:There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. &#xA;&#xA;This vulnerability can be mitigated by including the following patch after importing the “tarfile” module:  https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="python3-debug" release="42.u21" version="3.9.9">
					<filename>python3-debug-3.9.9-42.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-debug-3.9.9-42.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="42.u21" version="3.9.9">
					<filename>python3-devel-3.9.9-42.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-devel-3.9.9-42.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3" release="42.u21" version="3.9.9">
					<filename>python3-3.9.9-42.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-3.9.9-42.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="42.u21" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-42.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-unversioned-command-3.9.9-42.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="42.u21" version="3.9.9">
					<filename>python3-debug-3.9.9-42.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-debug-3.9.9-42.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="42.u21" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-42.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-unversioned-command-3.9.9-42.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="42.u21" version="3.9.9">
					<filename>python3-3.9.9-42.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-3.9.9-42.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="42.u21" version="3.9.9">
					<filename>python3-devel-3.9.9-42.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/python3-devel-3.9.9-42.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="42.u21" version="3.9.9">
					<filename>python3-help-3.9.9-42.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-help-3.9.9-42.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2310</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11230&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11230" id="CVE-2025-11230" title="CVE-2025-11230" type="cve"></reference>
		</references>
		<description>CVE-2025-11230:This is a security vulnerability affecting Debian systems, requiring further analysis for specific details.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="18.u16" version="2.6.6">
					<filename>haproxy-2.6.6-18.u16.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/haproxy-2.6.6-18.u16.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="18.u16" version="2.6.6">
					<filename>haproxy-2.6.6-18.u16.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/haproxy-2.6.6-18.u16.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="18.u16" version="2.6.6">
					<filename>haproxy-help-2.6.6-18.u16.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/haproxy-help-2.6.6-18.u16.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2311</id>
		<title>An update for yajl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-16516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2017-16516" id="CVE-2017-16516" title="CVE-2017-16516" type="cve"></reference>
		</references>
		<description>CVE-2017-16516:In the yajl-ruby gem 1.3.0 for Ruby, when a crafted JSON file is supplied to Yajl::Parser.new.parse, the whole ruby process crashes with a SIGABRT in the yajl_string_decode function in yajl_encode.c. This results in the whole ruby process terminating and potentially a denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="yajl" release="21.u1" version="2.1.0">
					<filename>yajl-2.1.0-21.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/yajl-2.1.0-21.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yajl-devel" release="21.u1" version="2.1.0">
					<filename>yajl-devel-2.1.0-21.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/yajl-devel-2.1.0-21.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="yajl" release="21.u1" version="2.1.0">
					<filename>yajl-2.1.0-21.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/yajl-2.1.0-21.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="yajl-devel" release="21.u1" version="2.1.0">
					<filename>yajl-devel-2.1.0-21.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/yajl-devel-2.1.0-21.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2312</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9086&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9086" id="CVE-2025-9086" title="CVE-2025-9086" type="cve"></reference>
		</references>
		<description>CVE-2025-9086:1. A cookie is set using the `secure` keyword for `https://target`&#xA;2. curl is redirected to or otherwise made to speak with `http://target` (same&#xA;   hostname, but using clear text HTTP) using the same cookie set&#xA;3. The same cookie name is set - but with just a slash as path (`path=&#39;/&#39;`).&#xA;   Since this site is not secure, the cookie *should* just be ignored.&#xA;4. A bug in the path comparison logic makes curl read outside a heap buffer&#xA;   boundary&#xA;&#xA;The bug either causes a crash or it potentially makes the comparison come to&#xA;the wrong conclusion and lets the clear-text site override the contents of the&#xA;secure cookie, contrary to expectations and depending on the memory contents&#xA;immediately following the single-byte allocation that holds the path.&#xA;&#xA;The presumed and correct behavior would be to plainly ignore the second set of&#xA;the cookie since it was already set as secure on a secure host so overriding&#xA;it on an insecure host should not be okay.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="42.u27" version="7.79.1">
					<filename>libcurl-devel-7.79.1-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libcurl-devel-7.79.1-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="42.u27" version="7.79.1">
					<filename>libcurl-7.79.1-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/libcurl-7.79.1-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="42.u27" version="7.79.1">
					<filename>curl-7.79.1-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/curl-7.79.1-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="42.u27" version="7.79.1">
					<filename>curl-help-7.79.1-42.u27.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/curl-help-7.79.1-42.u27.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="42.u27" version="7.79.1">
					<filename>libcurl-7.79.1-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libcurl-7.79.1-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="curl" release="42.u27" version="7.79.1">
					<filename>curl-7.79.1-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/curl-7.79.1-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="42.u27" version="7.79.1">
					<filename>libcurl-devel-7.79.1-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/libcurl-devel-7.79.1-42.u27.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2313</id>
		<title>An update for gstreamer1-plugins-good is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47183" id="CVE-2025-47183" title="CVE-2025-47183" type="cve"></reference>
		</references>
		<description>CVE-2025-47183:In GStreamer through 1.26.1, the isomp4 plugin&#39;s qtdemux_parse_tree function may read past the end of a heap buffer while parsing an MP4 file, leading to information disclosure.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-good-help" release="11.u6" version="1.16.2">
					<filename>gstreamer1-plugins-good-help-1.16.2-11.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/gstreamer1-plugins-good-help-1.16.2-11.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good-gtk" release="11.u6" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-11.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/gstreamer1-plugins-good-gtk-1.16.2-11.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good" release="11.u6" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-11.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/gstreamer1-plugins-good-1.16.2-11.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good" release="11.u6" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-11.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/gstreamer1-plugins-good-1.16.2-11.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good-gtk" release="11.u6" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-11.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/gstreamer1-plugins-good-gtk-1.16.2-11.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2314</id>
		<title>An update for gstreamer1 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47606&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47606" id="CVE-2024-47606" title="CVE-2024-47606" type="cve"></reference>
		</references>
		<description>CVE-2024-47606:GStreamer is a library for constructing graphs of media-handling components. An integer underflow has been detected in the function qtdemux_parse_theora_extension within qtdemux.c. The vulnerability occurs due to an underflow of the gint size variable, which causes size to hold a large unintended value when cast to an unsigned integer. This 32-bit negative value is then cast to a 64-bit unsigned integer (0xfffffffffffffffa) in a subsequent call to gst_buffer_new_and_alloc. The function gst_buffer_new_allocate then attempts to allocate memory, eventually calling _sysmem_new_block. The function _sysmem_new_block adds alignment and header size to the (unsigned) size, causing the overflow of the &#39;slice_size&#39; variable. As a result, only 0x89 bytes are allocated, despite the large input size. When the following memcpy call occurs in gst_buffer_fill, the data from the input file will overwrite the content of the GstMapInfo info structure. Finally, during the call to gst_memory_unmap, the overwritten memory may cause a function pointer hijack, as the mem-&gt;allocator-&gt;mem_unmap_full function is called with a corrupted pointer. This function pointer overwrite could allow an attacker to alter the execution flow of the program, leading to arbitrary code execution. This vulnerability is fixed in 1.24.10.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="gstreamer1" release="4.u3" version="1.19.3">
					<filename>gstreamer1-1.19.3-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/gstreamer1-1.19.3-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-devel" release="4.u3" version="1.19.3">
					<filename>gstreamer1-devel-1.19.3-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/gstreamer1-devel-1.19.3-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-help" release="4.u3" version="1.19.3">
					<filename>gstreamer1-help-1.19.3-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/gstreamer1-help-1.19.3-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1" release="4.u3" version="1.19.3">
					<filename>gstreamer1-1.19.3-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/gstreamer1-1.19.3-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-devel" release="4.u3" version="1.19.3">
					<filename>gstreamer1-devel-1.19.3-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/gstreamer1-devel-1.19.3-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2315</id>
		<title>An update for google-oauth-java-client is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-22573&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-22573" id="CVE-2021-22573" title="CVE-2021-22573" type="cve"></reference>
		</references>
		<description>CVE-2021-22573:The vulnerability is that IDToken verifier does not verify if token is properly signed. Signature verification makes sure that the token&#39;s payload comes from valid provider, not from someone else. An attacker can provide a compromised token with custom payload. The token will pass the validation on the client side. We recommend upgrading to version 1.33.3 or above&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="google-oauth-java-client" release="6.u1" version="1.22.0">
					<filename>google-oauth-java-client-1.22.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/google-oauth-java-client-1.22.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="google-oauth-java-client-help" release="6.u1" version="1.22.0">
					<filename>google-oauth-java-client-help-1.22.0-6.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/google-oauth-java-client-help-1.22.0-6.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2316</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58060&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58060" id="CVE-2025-58060" title="CVE-2025-58060" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58364&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58364" id="CVE-2025-58364" title="CVE-2025-58364" type="cve"></reference>
		</references>
		<description>CVE-2025-58060:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.&#xA;CVE-2025-58364:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, an unsafe deserialization and validation of printer attributes causes null dereference in the libcups library. This is a remote DoS vulnerability available in local subnet in default configurations. It can cause the cups &amp; cups-browsed to crash, on all the machines in local network who are listening for printers (so by default for all regular linux machines). On systems where the vulnerability CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was not fixed, and the firewall on the machine does not reject incoming communication to IPP port, and the machine is set to be available to public internet, attack vector &#34;Network&#34; is possible. The current versions of CUPS and cups-browsed projects have the attack vector &#34;Adjacent&#34; in their default configurations. Version 2.4.13 contains a patch for CVE-2025-58364.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="1" name="cups" release="15.u8" version="2.4.0">
					<filename>cups-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="15.u8" version="2.4.0">
					<filename>cups-client-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-client-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="15.u8" version="2.4.0">
					<filename>cups-libs-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-libs-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="15.u8" version="2.4.0">
					<filename>cups-devel-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-devel-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="15.u8" version="2.4.0">
					<filename>cups-ipptool-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-ipptool-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="15.u8" version="2.4.0">
					<filename>cups-lpd-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-lpd-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="15.u8" version="2.4.0">
					<filename>cups-printerapp-2.4.0-15.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cups-printerapp-2.4.0-15.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="15.u8" version="2.4.0">
					<filename>cups-filesystem-2.4.0-15.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-filesystem-2.4.0-15.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="15.u8" version="2.4.0">
					<filename>cups-help-2.4.0-15.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-help-2.4.0-15.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="15.u8" version="2.4.0">
					<filename>cups-lpd-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-lpd-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="15.u8" version="2.4.0">
					<filename>cups-client-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-client-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="15.u8" version="2.4.0">
					<filename>cups-printerapp-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-printerapp-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="15.u8" version="2.4.0">
					<filename>cups-devel-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-devel-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="15.u8" version="2.4.0">
					<filename>cups-ipptool-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-ipptool-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="15.u8" version="2.4.0">
					<filename>cups-libs-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-libs-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups" release="15.u8" version="2.4.0">
					<filename>cups-2.4.0-15.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cups-2.4.0-15.u8.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2317</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3770&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3770" id="CVE-2025-3770" title="CVE-2025-3770" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38805&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-38805" id="CVE-2024-38805" title="CVE-2024-38805" type="cve"></reference>
		</references>
		<description>CVE-2025-3770:EDK2 contains a vulnerability in BIOS where an attacker may cause “Protection Mechanism Failure” by local access. Successful exploitation of this vulnerability will lead to arbitrary code execution and impact Confidentiality, Integrity, and Availability.&#xA;CVE-2024-38805:EDK2 contains a vulnerability in BIOS where a user may cause an Integer Overflow or Wraparound by network means. A successful exploitation of this vulnerability may lead to denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="28.u17" version="202011">
					<filename>edk2-devel-202011-28.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/edk2-devel-202011-28.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="28.u17" version="202011">
					<filename>edk2-ovmf-202011-28.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/edk2-ovmf-202011-28.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="28.u17" version="202011">
					<filename>edk2-help-202011-28.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/edk2-help-202011-28.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="28.u17" version="202011">
					<filename>python3-edk2-devel-202011-28.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-edk2-devel-202011-28.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="28.u17" version="202011">
					<filename>edk2-aarch64-202011-28.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/edk2-aarch64-202011-28.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="28.u17" version="202011">
					<filename>edk2-devel-202011-28.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/edk2-devel-202011-28.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2318</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49844&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49844" id="CVE-2025-49844" title="CVE-2025-49844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46817" id="CVE-2025-46817" title="CVE-2025-46817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46818&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46818" id="CVE-2025-46818" title="CVE-2025-46818" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46819&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46819" id="CVE-2025-46819" title="CVE-2025-46819" type="cve"></reference>
		</references>
		<description>CVE-2025-49844:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free and potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.&#xA;CVE-2025-46817:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2.&#xA;CVE-2025-46818:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user. The problem exists in all versions of Redis with LUA scripting. This issue is fixed in version 8.2.2. A workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing LUA scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.&#xA;CVE-2025-46819:Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted LUA script to read out-of-bound data or crash the server and subsequent denial of service. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u15" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/redis6-devel-6.2.7-3.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u15" version="6.2.7">
					<filename>redis6-6.2.7-3.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/redis6-6.2.7-3.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u15" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/redis6-devel-6.2.7-3.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u15" version="6.2.7">
					<filename>redis6-6.2.7-3.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/redis6-6.2.7-3.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u15" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/redis6-doc-6.2.7-3.u15.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2319</id>
		<title>An update for ansible is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-3697" id="CVE-2022-3697" title="CVE-2022-3697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5115&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5115" id="CVE-2023-5115" title="CVE-2023-5115" type="cve"></reference>
		</references>
		<description>CVE-2022-3697:A flaw was found in Ansible in the amazon.aws collection when using the tower_callback parameter from the amazon.aws.ec2_instance module. This flaw allows an attacker to take advantage of this issue as the module is handling the parameter insecurely, leading to the password leaking in the logs.&#xA;CVE-2023-5115:An absolute path traversal attack exists in the Ansible automation platform. This flaw allows an attacker to craft a malicious Ansible role and make the victim execute the role. A symlink can be used to overwrite a file outside of the extraction path.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="ansible" release="6.u7" version="2.9.27">
					<filename>ansible-2.9.27-6.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ansible-2.9.27-6.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ansible-help" release="6.u7" version="2.9.27">
					<filename>ansible-help-2.9.27-6.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ansible-help-2.9.27-6.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2320</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5455&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5455" id="CVE-2025-5455" title="CVE-2025-5455" type="cve"></reference>
		</references>
		<description>CVE-2025-5455:An issue was found in the private API function qDecodeDataUrl() in QtCore, which is used in QTextDocument and QNetworkReply, and, potentially, in user code.&#xA;&#xA;If the function was called with malformed data, for example, an URL that&#xA;contained a &#34;charset&#34; parameter that lacked a value (such as&#xA;&#34;data:charset,&#34;), and Qt was built with assertions enabled, then it would hit an assertion, resulting in a denial of service&#xA;(abort).&#xA;&#xA;This impacts Qt up to 5.15.18, 6.0.0-&gt;6.5.8, 6.6.0-&gt;6.8.3 and 6.9.0. This has been fixed in 5.15.19, 6.5.9, 6.8.4 and 6.9.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-examples-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-gui-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-mysql-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-odbc-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-private-devel-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-devel-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-static-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-postgresql-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-18.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-5.15.2-18.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-static-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-postgresql-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-private-devel-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-mysql-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-examples-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-odbc-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-devel-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-18.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtbase-gui-5.15.2-18.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="18.u12" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-18.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtbase-common-5.15.2-18.u12.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2321</id>
		<title>An update for cjson is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-57052&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-57052" id="CVE-2025-57052" title="CVE-2025-57052" type="cve"></reference>
		</references>
		<description>CVE-2025-57052:cJSON 1.5.0 through 1.7.18 allows out-of-bounds access via the decode_array_index_from_pointer function in cJSON_Utils.c, allowing remote attackers to bypass array bounds checking and access restricted data via malformed JSON pointer strings containing alphanumeric characters.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="aarch64" epoch="0" name="cjson" release="5.u5" version="1.7.15">
					<filename>cjson-1.7.15-5.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cjson-1.7.15-5.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cjson-devel" release="5.u5" version="1.7.15">
					<filename>cjson-devel-1.7.15-5.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/cjson-devel-1.7.15-5.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cjson-devel" release="5.u5" version="1.7.15">
					<filename>cjson-devel-1.7.15-5.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cjson-devel-1.7.15-5.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cjson" release="5.u5" version="1.7.15">
					<filename>cjson-1.7.15-5.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/cjson-1.7.15-5.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2322</id>
		<title>An update for python-pip is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47081&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47081" id="CVE-2024-47081" title="CVE-2024-47081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50181" id="CVE-2025-50181" title="CVE-2025-50181" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32681&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32681" id="CVE-2023-32681" title="CVE-2023-32681" type="cve"></reference>
		</references>
		<description>CVE-2024-47081:Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one&#39;s Requests Session.&#xA;CVE-2025-50181:urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.&#xA;CVE-2023-32681:Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use `rebuild_proxies` to reattach the `Proxy-Authorization` header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="python-pip-help" release="11.u6" version="21.3.1">
					<filename>python-pip-help-21.3.1-11.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python-pip-help-21.3.1-11.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-wheel" release="11.u6" version="21.3.1">
					<filename>python-pip-wheel-21.3.1-11.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python-pip-wheel-21.3.1-11.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pip" release="11.u6" version="21.3.1">
					<filename>python3-pip-21.3.1-11.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/python3-pip-21.3.1-11.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2323</id>
		<title>An update for ongres-scram is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59432&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59432" id="CVE-2025-59432" title="CVE-2025-59432" type="cve"></reference>
		</references>
		<description>CVE-2025-59432:SCRAM (Salted Challenge Response Authentication Mechanism) is part of the family of Simple Authentication and Security Layer (SASL, RFC 4422) authentication mechanisms. Prior to version 3.2, a timing attack vulnerability exists in the SCRAM Java implementation. The issue arises because Arrays.equals was used to compare secret values such as client proofs and server signatures. Since Arrays.equals performs a short-circuit comparison, the execution time varies depending on how many leading bytes match. This behavior could allow an attacker to perform a timing side-channel attack and potentially infer sensitive authentication material. All users relying on SCRAM authentication are impacted. This vulnerability has been patched in version 3.1 by replacing Arrays.equals with MessageDigest.isEqual, which ensures constant-time comparison.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="noarch" epoch="0" name="ongres-scram" release="2.u1" version="2.1">
					<filename>ongres-scram-2.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ongres-scram-2.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ongres-scram-client" release="2.u1" version="2.1">
					<filename>ongres-scram-client-2.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ongres-scram-client-2.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ongres-scram-help" release="2.u1" version="2.1">
					<filename>ongres-scram-help-2.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ongres-scram-help-2.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ongres-scram-parent" release="2.u1" version="2.1">
					<filename>ongres-scram-parent-2.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/ongres-scram-parent-2.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2324</id>
		<title>An update for qt5-qtimageformats is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-11-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5683&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5683" id="CVE-2025-5683" title="CVE-2025-5683" type="cve"></reference>
		</references>
		<description>CVE-2025-5683:When loading a specifically crafted ICNS format image file in QImage then it will trigger a crash. This issue affects Qt from versions 6.3.0 through 6.5.9, from 6.6.0 through 6.8.4, 6.9.0. This is fixed in 6.5.10, 6.8.5 and 6.9.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.20.1</name>
				<package arch="x86_64" epoch="0" name="qt5-qtimageformats" release="2.u1" version="5.15.2">
					<filename>qt5-qtimageformats-5.15.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.20.1/qt5-qtimageformats-5.15.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtimageformats" release="2.u1" version="5.15.2">
					<filename>qt5-qtimageformats-5.15.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.20.1/qt5-qtimageformats-5.15.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2325</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9230&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9230" id="CVE-2025-9230" title="CVE-2025-9230" type="cve"></reference>
		</references>
		<description>CVE-2025-9230:Issue summary: An application trying to decrypt CMS messages encrypted using&#xA;password based encryption can trigger an out-of-bounds read and write.&#xA;&#xA;Impact summary: This out-of-bounds read may trigger a crash which leads to&#xA;Denial of Service for an application. The out-of-bounds write can cause&#xA;a memory corruption which can have various consequences including&#xA;a Denial of Service or Execution of attacker-supplied code.&#xA;&#xA;Although the consequences of a successful exploit of this vulnerability&#xA;could be severe, the probability that the attacker would be able to&#xA;perform it is low. Besides, password based (PWRI) encryption support in CMS&#xA;messages is very rarely used. For that reason the issue was assessed as&#xA;Moderate severity according to our Security Policy.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this&#xA;issue, as the CMS implementation is outside the OpenSSL FIPS module&#xA;boundary.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="29.u20" version="202011">
					<filename>edk2-aarch64-202011-29.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/edk2-aarch64-202011-29.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="29.u20" version="202011">
					<filename>edk2-help-202011-29.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/edk2-help-202011-29.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="29.u20" version="202011">
					<filename>edk2-ovmf-202011-29.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/edk2-ovmf-202011-29.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="29.u20" version="202011">
					<filename>python3-edk2-devel-202011-29.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-edk2-devel-202011-29.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="29.u20" version="202011">
					<filename>edk2-devel-202011-29.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/edk2-devel-202011-29.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="29.u20" version="202011">
					<filename>edk2-devel-202011-29.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/edk2-devel-202011-29.u20.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2326</id>
		<title>An update for erlang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30211&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30211" id="CVE-2025-30211" title="CVE-2025-30211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32433&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32433" id="CVE-2025-32433" title="CVE-2025-32433" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4748&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4748" id="CVE-2025-4748" title="CVE-2025-4748" type="cve"></reference>
		</references>
		<description>CVE-2025-30211:Erlang/OTP is a set of libraries for the Erlang programming language. Prior to versions OTP-27.3.1, 26.2.5.10, and 25.3.2.19, a maliciously formed KEX init message can result with high memory usage. Implementation does not verify RFC specified limits on algorithm names (64 characters) provided in KEX init message. Big KEX init packet may lead to inefficient processing of the error data. As a result, large amount of memory will be allocated for processing malicious data. Versions OTP-27.3.1, OTP-26.2.5.10, and OTP-25.3.2.19 fix the issue. Some workarounds are available. One may set option `parallel_login` to `false` and/or reduce the `max_sessions` option.&#xA;CVE-2025-32433:Erlang/OTP is a set of libraries for the Erlang programming language. Prior to versions OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20, a SSH server may allow an attacker to perform unauthenticated remote code execution (RCE). By exploiting a flaw in SSH protocol message handling, a malicious actor could gain unauthorized access to affected systems and execute arbitrary commands without valid credentials. This issue is patched in versions OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20. A temporary workaround involves disabling the SSH server or to prevent access via firewall rules.&#xA;CVE-2025-4748:Improper Limitation of a Pathname to a Restricted Directory (&#39;Path Traversal&#39;) vulnerability in Erlang OTP (stdlib modules) allows Absolute Path Traversal, File Manipulation. This vulnerability is associated with program files lib/stdlib/src/zip.erl and program routines zip:unzip/1, zip:unzip/2, zip:extract/1, zip:extract/2 unless the memory option is passed.&#xA;&#xA;This issue affects OTP from OTP 17.0 until OTP 28.0.1, OTP 27.3.4.1 and OTP 26.2.5.13, corresponding to stdlib from 2.0 until 7.0.1, 6.2.2.1 and 5.2.3.4.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="erlang-erts" release="7.u4" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-erts-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-xmerl" release="7.u4" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-xmerl-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-debugger" release="7.u4" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-debugger-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-kernel" release="7.u4" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-kernel-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-megaco" release="7.u4" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-megaco-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-diameter" release="7.u4" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-diameter-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-examples" release="7.u4" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-examples-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eunit" release="7.u4" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-eunit-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-et" release="7.u4" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-et-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-public_key" release="7.u4" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-public_key-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-wx" release="7.u4" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-wx-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-mnesia" release="7.u4" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-mnesia-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-snmp" release="7.u4" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-snmp-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tools" release="7.u4" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-tools-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eldap" release="7.u4" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-eldap-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-odbc" release="7.u4" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-odbc-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-runtime_tools" release="7.u4" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-runtime_tools-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-asn1" release="7.u4" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-asn1-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssh" release="7.u4" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-ssh-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tftp" release="7.u4" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-tftp-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_interface" release="7.u4" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-erl_interface-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang" release="7.u4" version="23.3.4.9">
					<filename>erlang-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-dialyzer" release="7.u4" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-dialyzer-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-edoc" release="7.u4" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-edoc-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-sasl" release="7.u4" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-sasl-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ftp" release="7.u4" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-ftp-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-hipe" release="7.u4" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-hipe-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-inets" release="7.u4" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-inets-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-os_mon" release="7.u4" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-os_mon-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-stdlib" release="7.u4" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-stdlib-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_docgen" release="7.u4" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-erl_docgen-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-crypto" release="7.u4" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-crypto-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-parsetools" release="7.u4" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-parsetools-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-common_test" release="7.u4" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-common_test-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-compiler" release="7.u4" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-compiler-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-observer" release="7.u4" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-observer-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-reltool" release="7.u4" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-reltool-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-jinterface" release="7.u4" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-jinterface-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssl" release="7.u4" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-ssl-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-syntax_tools" release="7.u4" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/erlang-syntax_tools-23.3.4.9-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-edoc" release="7.u4" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-edoc-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssh" release="7.u4" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-ssh-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-asn1" release="7.u4" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-asn1-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-xmerl" release="7.u4" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-xmerl-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-examples" release="7.u4" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-examples-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-inets" release="7.u4" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-inets-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-snmp" release="7.u4" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-snmp-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tftp" release="7.u4" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-tftp-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ftp" release="7.u4" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-ftp-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_interface" release="7.u4" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-erl_interface-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-parsetools" release="7.u4" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-parsetools-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tools" release="7.u4" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-tools-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-dialyzer" release="7.u4" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-dialyzer-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_docgen" release="7.u4" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-erl_docgen-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-megaco" release="7.u4" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-megaco-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-observer" release="7.u4" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-observer-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eldap" release="7.u4" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-eldap-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-debugger" release="7.u4" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-debugger-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-os_mon" release="7.u4" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-os_mon-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssl" release="7.u4" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-ssl-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-crypto" release="7.u4" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-crypto-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang" release="7.u4" version="23.3.4.9">
					<filename>erlang-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-hipe" release="7.u4" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-hipe-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-mnesia" release="7.u4" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-mnesia-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-odbc" release="7.u4" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-odbc-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-reltool" release="7.u4" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-reltool-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-runtime_tools" release="7.u4" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-runtime_tools-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-wx" release="7.u4" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-wx-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-et" release="7.u4" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-et-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-compiler" release="7.u4" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-compiler-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erts" release="7.u4" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-erts-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eunit" release="7.u4" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-eunit-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-jinterface" release="7.u4" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-jinterface-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-public_key" release="7.u4" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-public_key-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-sasl" release="7.u4" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-sasl-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-common_test" release="7.u4" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-common_test-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-diameter" release="7.u4" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-diameter-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-stdlib" release="7.u4" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-stdlib-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-kernel" release="7.u4" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-kernel-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-syntax_tools" release="7.u4" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/erlang-syntax_tools-23.3.4.9-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2327</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20109&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-20109" id="CVE-2025-20109" title="CVE-2025-20109" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21090&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21090" id="CVE-2025-21090" title="CVE-2025-21090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22839&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22839" id="CVE-2025-22839" title="CVE-2025-22839" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22840&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22840" id="CVE-2025-22840" title="CVE-2025-22840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22889&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22889" id="CVE-2025-22889" title="CVE-2025-22889" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24305&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-24305" id="CVE-2025-24305" title="CVE-2025-24305" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26403&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26403" id="CVE-2025-26403" title="CVE-2025-26403" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32086&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32086" id="CVE-2025-32086" title="CVE-2025-32086" type="cve"></reference>
		</references>
		<description>CVE-2025-20109:Improper Isolation or Compartmentalization in the stream cache mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.&#xA;CVE-2025-21090:Missing reference to active allocated resource for some Intel(R) Xeon(R) processors may allow an authenticated user to potentially enable denial of service via local access.&#xA;CVE-2025-22839:Insufficient granularity of access control in the OOB-MSM for some Intel(R) Xeon(R) 6 Scalable processors may allow a privileged user to potentially enable escalation of privilege via adjacent access.&#xA;CVE-2025-22840:Sequence of processor instructions leads to unexpected behavior for some Intel(R) Xeon(R) 6 Scalable processors may allow an authenticated user to potentially enable escalation of privilege via local access&#xA;CVE-2025-22889:Improper handling of overlap between protected memory ranges for some Intel(R) Xeon(R) 6 processor with Intel(R) TDX may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2025-24305:Insufficient control flow management in the Alias Checking Trusted Module (ACTM) firmware for some Intel(R) Xeon(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2025-26403:Out-of-bounds write in the memory subsystem for some Intel(R) Xeon(R) 6 processors when using Intel(R) SGX or Intel(R) TDX may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;CVE-2025-32086:Improperly implemented security check for standard in the DDRIO configuration for some Intel(R) Xeon(R) 6 Processors when using Intel(R) SGX or Intel(R) TDX may allow a privileged user to potentially enable escalation of privilege via local access.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="1.u3" version="20251111">
					<filename>microcode_ctl-20251111-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/microcode_ctl-20251111-1.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2328</id>
		<title>An update for json-smart is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57699" id="CVE-2024-57699" title="CVE-2024-57699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1370&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-1370" id="CVE-2023-1370" title="CVE-2023-1370" type="cve"></reference>
		</references>
		<description>CVE-2024-57699:A security issue was found in Netplex Json-smart 2.5.0 through 2.5.1. When loading a specially crafted JSON input, containing a large number of ’{’, a stack exhaustion can be trigger, which could allow an attacker to cause a Denial of Service (DoS). This issue exists because of an incomplete fix for CVE-2023-1370.&#xA;CVE-2023-1370:[Json-smart](https://netplex.github.io/json-smart/) is a performance focused, JSON processor lib.&#xA;&#xA;When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively.&#xA;&#xA;It was discovered that the code does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause a stack exhaustion (stack overflow) and crash the software.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="json-smart" release="1.u1" version="2.5.2">
					<filename>json-smart-2.5.2-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/json-smart-2.5.2-1.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="json-smart-javadoc" release="1.u1" version="2.5.2">
					<filename>json-smart-javadoc-2.5.2-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/json-smart-javadoc-2.5.2-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2329</id>
		<title>An update for fontforge is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50949&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50949" id="CVE-2025-50949" title="CVE-2025-50949" type="cve"></reference>
		</references>
		<description>CVE-2025-50949:FontForge v20230101 was discovered to contain a memory leak via the component DlgCreate8.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="fontforge-devel" release="9.u2" version="20200314">
					<filename>fontforge-devel-20200314-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/fontforge-devel-20200314-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fontforge" release="9.u2" version="20200314">
					<filename>fontforge-20200314-9.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/fontforge-20200314-9.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fontforge" release="9.u2" version="20200314">
					<filename>fontforge-20200314-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/fontforge-20200314-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fontforge-devel" release="9.u2" version="20200314">
					<filename>fontforge-devel-20200314-9.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/fontforge-devel-20200314-9.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="fontforge-help" release="9.u2" version="20200314">
					<filename>fontforge-help-20200314-9.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/fontforge-help-20200314-9.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2330</id>
		<title>An update for apache-commons-fileupload is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48976&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48976" id="CVE-2025-48976" title="CVE-2025-48976" type="cve"></reference>
		</references>
		<description>CVE-2025-48976:Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload.&#xA;&#xA;This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4.&#xA;&#xA;Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="apache-commons-fileupload" release="3.u3" version="1.4">
					<filename>apache-commons-fileupload-1.4-3.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/apache-commons-fileupload-1.4-3.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-commons-fileupload-help" release="3.u3" version="1.4">
					<filename>apache-commons-fileupload-help-1.4-3.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/apache-commons-fileupload-help-1.4-3.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2331</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-1795" id="CVE-2025-1795" title="CVE-2025-1795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4516" id="CVE-2025-4516" title="CVE-2025-4516" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4517&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4517" id="CVE-2025-4517" title="CVE-2025-4517" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4138&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4138" id="CVE-2025-4138" title="CVE-2025-4138" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12718&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-12718" id="CVE-2024-12718" title="CVE-2024-12718" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4330&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4330" id="CVE-2025-4330" title="CVE-2025-4330" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4435&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4435" id="CVE-2025-4435" title="CVE-2025-4435" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8291&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8291" id="CVE-2025-8291" title="CVE-2025-8291" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5642&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-5642" id="CVE-2024-5642" title="CVE-2024-5642" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6075&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6075" id="CVE-2025-6075" title="CVE-2025-6075" type="cve"></reference>
		</references>
		<description>CVE-2025-1795:During an address list folding when a separating comma ends up on a folded line and that line is to be unicode-encoded then the separator itself is also unicode-encoded. Expected behavior is that the separating comma remains a plan comma. This can result in the address header being misinterpreted by some mail servers.&#xA;CVE-2025-4516:There is an issue in CPython when using `bytes.decode(&#34;unicode_escape&#34;, error=&#34;ignore|replace&#34;)`. If you are not using the &#34;unicode_escape&#34; encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.&#xA;CVE-2025-4517:Allows arbitrary filesystem writes outside the extraction directory during extraction with filter=&#34;data&#34;.&#xA;&#xA;&#xA;You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of &#34;data&#34; or &#34;tar&#34;. See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information.&#xA;&#xA;Note that for Python 3.14 or later the default value of filter= changed from &#34;no filtering&#34; to `&#34;data&#34;, so if you are relying on this new default behavior then your usage is also affected.&#xA;&#xA;Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it&#39;s important to avoid installing source distributions with suspicious links.&#xA;CVE-2025-4138:Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.&#xA;&#xA;&#xA;You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of &#34;data&#34; or &#34;tar&#34;. See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information.&#xA;&#xA;Note that for Python 3.14 or later the default value of filter= changed from &#34;no filtering&#34; to `&#34;data&#34;, so if you are relying on this new default behavior then your usage is also affected.&#xA;&#xA;Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it&#39;s important to avoid installing source distributions with suspicious links.&#xA;CVE-2024-12718:Allows modifying some file metadata (e.g. last modified) with filter=&#34;data&#34; or file permissions (chmod) with filter=&#34;tar&#34; of files outside the extraction directory.&#xA;You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of &#34;data&#34; or &#34;tar&#34;. See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don&#39;t include the extraction filter feature.&#xA;&#xA;Note that for Python 3.14 or later the default value of filter= changed from &#34;no filtering&#34; to `&#34;data&#34;, so if you are relying on this new default behavior then your usage is also affected.&#xA;&#xA;Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it&#39;s important to avoid installing source distributions with suspicious links.&#xA;CVE-2025-4330:Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.&#xA;&#xA;&#xA;You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of &#34;data&#34; or &#34;tar&#34;. See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information.&#xA;&#xA;Note that for Python 3.14 or later the default value of filter= changed from &#34;no filtering&#34; to `&#34;data&#34;, so if you are relying on this new default behavior then your usage is also affected.&#xA;&#xA;Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it&#39;s important to avoid installing source distributions with suspicious links.&#xA;CVE-2025-4435:When using a TarFile.errorlevel = 0 and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0 in affected versions is that the member would still be extracted and not skipped.&#xA;CVE-2025-8291:The &#39;zipfile&#39; module would not check the validity of the ZIP64 End of&#xA;Central Directory (EOCD) Locator record offset value would not be used to&#xA;locate the ZIP64 EOCD record, instead the ZIP64 EOCD record would be&#xA;assumed to be the previous record in the ZIP archive. This could be abused&#xA;to create ZIP archives that are handled differently by the &#39;zipfile&#39; module&#xA;compared to other ZIP implementations.&#xA;&#xA;&#xA;Remediation maintains this behavior, but checks that the offset specified&#xA;in the ZIP64 EOCD Locator record matches the expected value.&#xA;CVE-2024-5642:CPython 3.9 and earlier doesn&#39;t disallow configuring an empty list (&#34;[]&#34;) for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).&#xA;CVE-2025-6075:If the value passed to os.path.expandvars() is user-controlled a &#xA;performance degradation is possible when expanding environment &#xA;variables.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="python3-help" release="49.u23" version="3.9.9">
					<filename>python3-help-3.9.9-49.u23.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-help-3.9.9-49.u23.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="49.u23" version="3.9.9">
					<filename>python3-debug-3.9.9-49.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-debug-3.9.9-49.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="49.u23" version="3.9.9">
					<filename>python3-3.9.9-49.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-3.9.9-49.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="49.u23" version="3.9.9">
					<filename>python3-devel-3.9.9-49.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-devel-3.9.9-49.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="49.u23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-49.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-unversioned-command-3.9.9-49.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="49.u23" version="3.9.9">
					<filename>python3-debug-3.9.9-49.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-debug-3.9.9-49.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="49.u23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-49.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-unversioned-command-3.9.9-49.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3" release="49.u23" version="3.9.9">
					<filename>python3-3.9.9-49.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-3.9.9-49.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="49.u23" version="3.9.9">
					<filename>python3-devel-3.9.9-49.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-devel-3.9.9-49.u23.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2332</id>
		<title>An update for kata-containers is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-27151&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-27151" id="CVE-2020-27151" title="CVE-2020-27151" type="cve"></reference>
		</references>
		<description>CVE-2020-27151:An issue was discovered in Kata Containers through 1.11.3 and 2.x through 2.0-rc1. The runtime will execute binaries given using annotations without any kind of validation. Someone who is granted access rights to a cluster will be able to have kata-runtime execute arbitrary binaries as root on the worker nodes.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="kata-containers" release="29.u1" version="1.11.1">
					<filename>kata-containers-1.11.1-29.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/kata-containers-1.11.1-29.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kata-containers" release="29.u1" version="1.11.1">
					<filename>kata-containers-1.11.1-29.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/kata-containers-1.11.1-29.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2333</id>
		<title>An update for cloud-init is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6174&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-6174" id="CVE-2024-6174" title="CVE-2024-6174" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11584&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11584" id="CVE-2024-11584" title="CVE-2024-11584" type="cve"></reference>
		</references>
		<description>CVE-2024-6174:When a non-x86 platform is detected, cloud-init grants root access to a hardcoded url with a local IP address. To prevent this, cloud-init default configurations disable platform enumeration.&#xA;CVE-2024-11584:cloud-init through 25.1.2 includes the systemd socket unit cloud-init-hotplugd.socket with default SocketMode that grants 0666 permissions, making it world-writable. This is used for the &#34;/run/cloud-init/hook-hotplug-cmd&#34; FIFO. An unprivileged user could trigger hotplug-hook commands.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="cloud-init" release="36.u17" version="21.4">
					<filename>cloud-init-21.4-36.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/cloud-init-21.4-36.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cloud-init-help" release="36.u17" version="21.4">
					<filename>cloud-init-help-21.4-36.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/cloud-init-help-21.4-36.u17.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2334</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-10966&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-10966" id="CVE-2025-10966" title="CVE-2025-10966" type="cve"></reference>
		</references>
		<description>CVE-2025-10966:curl&#39;s code for managing SSH connections when SFTP was done using the wolfSSH&#xA;powered backend was flawed and missed host verification mechanisms.&#xA;&#xA;This prevents curl from detecting MITM attackers and more.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="aarch64" epoch="0" name="libcurl" release="42.u28" version="7.79.1">
					<filename>libcurl-7.79.1-42.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/libcurl-7.79.1-42.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="42.u28" version="7.79.1">
					<filename>curl-7.79.1-42.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/curl-7.79.1-42.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="42.u28" version="7.79.1">
					<filename>libcurl-devel-7.79.1-42.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/libcurl-devel-7.79.1-42.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="42.u28" version="7.79.1">
					<filename>curl-help-7.79.1-42.u28.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/curl-help-7.79.1-42.u28.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="42.u28" version="7.79.1">
					<filename>libcurl-devel-7.79.1-42.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/libcurl-devel-7.79.1-42.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="curl" release="42.u28" version="7.79.1">
					<filename>curl-7.79.1-42.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/curl-7.79.1-42.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="42.u28" version="7.79.1">
					<filename>libcurl-7.79.1-42.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/libcurl-7.79.1-42.u28.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2335</id>
		<title>An update for mozjs91 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34481&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-34481" id="CVE-2022-34481" title="CVE-2022-34481" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29532&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29532" id="CVE-2023-29532" title="CVE-2023-29532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25736&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-25736" id="CVE-2023-25736" title="CVE-2023-25736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29543&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-29543" id="CVE-2023-29543" title="CVE-2023-29543" type="cve"></reference>
		</references>
		<description>CVE-2022-34481:In the &lt;code&gt;nsTArray_Impl::ReplaceElementsAt()&lt;/code&gt; function, an integer overflow could have occurred when the number of elements to replace was too large for the container. This vulnerability affects Firefox &lt; 102, Firefox ESR &lt; 91.11, Thunderbird &lt; 102, and Thunderbird &lt; 91.11.&#xA;CVE-2023-29532:A local attacker can trick the Mozilla Maintenance Service into applying an unsigned update file by pointing the service at an update file on a malicious SMB server. The update file can be replaced after the signature check, before the use, because the write-lock requested by the service does not work on a SMB server.&#xA;&#xA;*Note: This attack requires local system access and only affects Windows. Other operating systems are not affected.* This vulnerability affects Firefox &lt; 112, Firefox ESR &lt; 102.10, and Thunderbird &lt; 102.10.&#xA;&#xA;&#xA;CVE-2023-25736:An invalid downcast from `nsHTMLDocument` to `nsIContent` could have lead to undefined behavior. This vulnerability affects Firefox &lt; 110.&#xA;CVE-2023-29543:An attacker could have caused memory corruption and a potentially exploitable use-after-free of a pointer in a global object&#39;s debugger vector. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="libmozjs-91-0" release="6.u2" version="91.6.0">
					<filename>libmozjs-91-0-91.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/libmozjs-91-0-91.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mozjs91" release="6.u2" version="91.6.0">
					<filename>mozjs91-91.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mozjs91-91.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mozjs91-devel" release="6.u2" version="91.6.0">
					<filename>mozjs91-devel-91.6.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mozjs91-devel-91.6.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mozjs91" release="6.u2" version="91.6.0">
					<filename>mozjs91-91.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mozjs91-91.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mozjs91-devel" release="6.u2" version="91.6.0">
					<filename>mozjs91-devel-91.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mozjs91-devel-91.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libmozjs-91-0" release="6.u2" version="91.6.0">
					<filename>libmozjs-91-0-91.6.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/libmozjs-91-0-91.6.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2336</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23085" id="CVE-2025-23085" title="CVE-2025-23085" type="cve"></reference>
		</references>
		<description>CVE-2025-23085:A memory leak could occur when a remote peer abruptly closes the socket without sending a GOAWAY notification. Additionally, if an invalid header was detected by nghttp2, causing the connection to be terminated by the peer, the same leak was triggered. This flaw could lead to increased memory consumption and potential denial of service under certain conditions.&#xA;&#xA;This vulnerability affects HTTP/2 Server users on Node.js v18.x, v20.x, v22.x and v23.x.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.12.u8" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/v8-devel-7.8.279.23-1.12.22.11.12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="12.u8" version="12.22.11">
					<filename>nodejs-devel-12.22.11-12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/nodejs-devel-12.22.11-12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.12.u8" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/npm-6.14.16-1.12.22.11.12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="12.u8" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/nodejs-full-i18n-12.22.11-12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="12.u8" version="12.22.11">
					<filename>nodejs-libs-12.22.11-12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/nodejs-libs-12.22.11-12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs" release="12.u8" version="12.22.11">
					<filename>nodejs-12.22.11-12.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/nodejs-12.22.11-12.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="12.u8" version="12.22.11">
					<filename>nodejs-docs-12.22.11-12.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/nodejs-docs-12.22.11-12.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.12.u8" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/npm-6.14.16-1.12.22.11.12.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="12.u8" version="12.22.11">
					<filename>nodejs-devel-12.22.11-12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/nodejs-devel-12.22.11-12.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.12.u8" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/v8-devel-7.8.279.23-1.12.22.11.12.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="12.u8" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/nodejs-full-i18n-12.22.11-12.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="12.u8" version="12.22.11">
					<filename>nodejs-libs-12.22.11-12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/nodejs-libs-12.22.11-12.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="12.u8" version="12.22.11">
					<filename>nodejs-12.22.11-12.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/nodejs-12.22.11-12.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2337</id>
		<title>An update for audiofile is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50950&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50950" id="CVE-2025-50950" title="CVE-2025-50950" type="cve"></reference>
		</references>
		<description>CVE-2025-50950:Audiofile v0.3.7 was discovered to contain a NULL pointer dereference via the ModuleState::setup function.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="aarch64" epoch="0" name="audiofile-devel" release="29.u1" version="0.3.6">
					<filename>audiofile-devel-0.3.6-29.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/audiofile-devel-0.3.6-29.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="audiofile" release="29.u1" version="0.3.6">
					<filename>audiofile-0.3.6-29.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/audiofile-0.3.6-29.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="audiofile-devel" release="29.u1" version="0.3.6">
					<filename>audiofile-devel-0.3.6-29.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/audiofile-devel-0.3.6-29.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="audiofile" release="29.u1" version="0.3.6">
					<filename>audiofile-0.3.6-29.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/audiofile-0.3.6-29.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="audiofile-help" release="29.u1" version="0.3.6">
					<filename>audiofile-help-0.3.6-29.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/audiofile-help-0.3.6-29.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2338</id>
		<title>An update for containerd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25621&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-25621" id="CVE-2024-25621" title="CVE-2024-25621" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64329&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64329" id="CVE-2025-64329" title="CVE-2025-64329" type="cve"></reference>
		</references>
		<description>CVE-2024-25621:containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.&#xA;CVE-2025-64329:containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="containerd" release="11.u11" version="1.6.22">
					<filename>containerd-1.6.22-11.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/containerd-1.6.22-11.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="containerd-stress" release="11.u11" version="1.6.22">
					<filename>containerd-stress-1.6.22-11.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/containerd-stress-1.6.22-11.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd" release="11.u11" version="1.6.22">
					<filename>containerd-1.6.22-11.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/containerd-1.6.22-11.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="containerd-stress" release="11.u11" version="1.6.22">
					<filename>containerd-stress-1.6.22-11.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/containerd-stress-1.6.22-11.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2339</id>
		<title>An update for libxslt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-10911&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-10911" id="CVE-2025-10911" title="CVE-2025-10911" type="cve"></reference>
		</references>
		<description>CVE-2025-10911:A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="aarch64" epoch="0" name="libxslt-devel" release="5.u4" version="1.1.37">
					<filename>libxslt-devel-1.1.37-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/libxslt-devel-1.1.37-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxslt" release="5.u4" version="1.1.37">
					<filename>python3-libxslt-1.1.37-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-libxslt-1.1.37-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt" release="5.u4" version="1.1.37">
					<filename>libxslt-1.1.37-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/libxslt-1.1.37-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt-devel" release="5.u4" version="1.1.37">
					<filename>libxslt-devel-1.1.37-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/libxslt-devel-1.1.37-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxslt" release="5.u4" version="1.1.37">
					<filename>python3-libxslt-1.1.37-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-libxslt-1.1.37-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt" release="5.u4" version="1.1.37">
					<filename>libxslt-1.1.37-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/libxslt-1.1.37-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxslt-help" release="5.u4" version="1.1.37">
					<filename>libxslt-help-1.1.37-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/libxslt-help-1.1.37-5.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2340</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57929&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57929" id="CVE-2024-57929" title="CVE-2024-57929" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39973&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39973" id="CVE-2025-39973" title="CVE-2025-39973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39993&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39993" id="CVE-2025-39993" title="CVE-2025-39993" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40021&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40021" id="CVE-2025-40021" title="CVE-2025-40021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40081&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40081" id="CVE-2025-40081" title="CVE-2025-40081" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40042&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40042" id="CVE-2025-40042" title="CVE-2025-40042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40044&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40044" id="CVE-2025-40044" title="CVE-2025-40044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40115&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40115" id="CVE-2025-40115" title="CVE-2025-40115" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38415&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38415" id="CVE-2025-38415" title="CVE-2025-38415" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21914&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21914" id="CVE-2025-21914" title="CVE-2025-21914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53034" id="CVE-2023-53034" title="CVE-2023-53034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39757&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39757" id="CVE-2025-39757" title="CVE-2025-39757" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37810&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37810" id="CVE-2025-37810" title="CVE-2025-37810" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40157" id="CVE-2025-40157" title="CVE-2025-40157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40123&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40123" id="CVE-2025-40123" title="CVE-2025-40123" type="cve"></reference>
		</references>
		<description>CVE-2024-57929:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm array: fix releasing a faulty array block twice in dm_array_cursor_end&#xA;&#xA;When dm_bm_read_lock() fails due to locking or checksum errors, it&#xA;releases the faulty block implicitly while leaving an invalid output&#xA;pointer behind. The caller of dm_bm_read_lock() should not operate on&#xA;this invalid dm_block pointer, or it will lead to undefined result.&#xA;For example, the dm_array_cursor incorrectly caches the invalid pointer&#xA;on reading a faulty array block, causing a double release in&#xA;dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().&#xA;&#xA;Reproduce steps:&#xA;&#xA;1. initialize a cache device&#xA;&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;&#xA;dmsetup create corig --table &#34;0 524288 linear /dev/sdc $262144&#34;&#xA;dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1&#xA;dmsetup create cache --table &#34;0 524288 cache /dev/mapper/cmeta \&#xA;/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;&#xA;&#xA;2. wipe the second array block offline&#xA;&#xA;dmsteup remove cache cmeta cdata corig&#xA;mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \&#xA;2&gt;/dev/null | hexdump -e &#39;1/8 &#34;%u\n&#34;&#39;)&#xA;ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \&#xA;2&gt;/dev/null | hexdump -e &#39;1/8 &#34;%u\n&#34;&#39;)&#xA;dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock&#xA;&#xA;3. try reopen the cache device&#xA;&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;&#xA;dmsetup create corig --table &#34;0 524288 linear /dev/sdc $262144&#34;&#xA;dmsetup create cache --table &#34;0 524288 cache /dev/mapper/cmeta \&#xA;/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;&#xA;&#xA;Kernel logs:&#xA;&#xA;(snip)&#xA;device-mapper: array: array_block_check failed: blocknr 0 != wanted 10&#xA;device-mapper: block manager: array validator check failed for block 10&#xA;device-mapper: array: get_ablock failed&#xA;device-mapper: cache metadata: dm_array_cursor_next for mapping failed&#xA;------------[ cut here ]------------&#xA;kernel BUG at drivers/md/dm-bufio.c:638!&#xA;&#xA;Fix by setting the cached block pointer to NULL on errors.&#xA;&#xA;In addition to the reproducer described above, this fix can be&#xA;verified using the &#34;array_cursor/damaged&#34; test in dm-unit:&#xA;  dm-unit run /pdata/array_cursor/damaged --kernel-dir &lt;KERNEL_DIR&gt;&#xA;CVE-2025-39973:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: add validation for ring_len param&#xA;&#xA;The `ring_len` parameter provided by the virtual function (VF)&#xA;is assigned directly to the hardware memory context (HMC) without&#xA;any validation.&#xA;&#xA;To address this, introduce an upper boundary check for both Tx and Rx&#xA;queue lengths. The maximum number of descriptors supported by the&#xA;hardware is 8k-32.&#xA;Additionally, enforce alignment constraints: Tx rings must be a multiple&#xA;of 8, and Rx rings must be a multiple of 32.&#xA;CVE-2025-39993:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: rc: fix races with imon_disconnect()&#xA;&#xA;Syzbot reports a KASAN issue as below:&#xA;BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]&#xA;BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627&#xA;Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465&#xA;&#xA;CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;__dump_stack lib/dump_stack.c:88 [inline]&#xA;dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106&#xA;print_address_description mm/kasan/report.c:317 [inline]&#xA;print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433&#xA;kasan_report+0xb1/0x1e0 mm/kasan/report.c:495&#xA;__create_pipe include/linux/usb.h:1945 [inline]&#xA;send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627&#xA;vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991&#xA;vfs_write+0x2d7/0xdd0 fs/read_write.c:576&#xA;ksys_write+0x127/0x250 fs/read_write.c:631&#xA;do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80&#xA;entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;The iMON driver improperly releases the usb_device reference in&#xA;imon_disconnect without coordinating with active users of the&#xA;device.&#xA;&#xA;Specifically, the fields usbdev_intf0 and usbdev_intf1 are not&#xA;protected by the users counter (ictx-&gt;users). During probe,&#xA;imon_init_intf0 or imon_init_intf1 increments the usb_device&#xA;reference count depending on the interface. However, during&#xA;disconnect, usb_put_dev is called unconditionally, regardless of&#xA;actual usage.&#xA;&#xA;As a result, if vfd_write or other operations are still in&#xA;progress after disconnect, this can lead to a use-after-free of&#xA;the usb_device pointer.&#xA;&#xA;Thread 1 vfd_write                      Thread 2 imon_disconnect&#xA;                                        ...&#xA;                                        if&#xA;                                          usb_put_dev(ictx-&gt;usbdev_intf0)&#xA;                                        else&#xA;                                          usb_put_dev(ictx-&gt;usbdev_intf1)&#xA;...&#xA;while&#xA;  send_packet&#xA;    if&#xA;      pipe = usb_sndintpipe(&#xA;        ictx-&gt;usbdev_intf0) UAF&#xA;    else&#xA;      pipe = usb_sndctrlpipe(&#xA;        ictx-&gt;usbdev_intf0, 0) UAF&#xA;&#xA;Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by&#xA;checking ictx-&gt;disconnected in all writer paths. Add early return&#xA;with -ENODEV in send_packet(), vfd_write(), lcd_write() and&#xA;display_open() if the device is no longer present.&#xA;&#xA;Set and read ictx-&gt;disconnected under ictx-&gt;lock to ensure memory&#xA;synchronization. Acquire the lock in imon_disconnect() before setting&#xA;the flag to synchronize with any ongoing operations.&#xA;&#xA;Ensure writers exit early and safely after disconnect before the USB&#xA;core proceeds with cleanup.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2025-40021:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: dynevent: Add a missing lockdown check on dynevent&#xA;&#xA;Since dynamic_events interface on tracefs is compatible with&#xA;kprobe_events and uprobe_events, it should also check the lockdown&#xA;status and reject if it is set.&#xA;CVE-2025-40081:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf: arm_spe: Prevent overflow in PERF_IDX2OFF()&#xA;&#xA;Cast nr_pages to unsigned long to avoid overflow when handling large&#xA;AUX buffer sizes (&gt;= 2 GiB).&#xA;CVE-2025-40042:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Fix race condition in kprobe initialization causing NULL pointer dereference&#xA;&#xA;There is a critical race condition in kprobe initialization that can lead to&#xA;NULL pointer dereference and kernel crash.&#xA;&#xA;[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000&#xA;...&#xA;[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)&#xA;[1135630.269239] pc : kprobe_perf_func+0x30/0x260&#xA;[1135630.277643] lr : kprobe_dispatcher+0x44/0x60&#xA;[1135630.286041] sp : ffffaeff4977fa40&#xA;[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400&#xA;[1135630.302837] x27: 0000000000000000 x26: 0000000000000000&#xA;[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528&#xA;[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50&#xA;[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50&#xA;[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000&#xA;[1135630.349985] x17: 0000000000000000 x16: 0000000000000000&#xA;[1135630.359285] x15: 0000000000000000 x14: 0000000000000000&#xA;[1135630.368445] x13: 0000000000000000 x12: 0000000000000000&#xA;[1135630.377473] x11: 0000000000000000 x10: 0000000000000000&#xA;[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000&#xA;[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000&#xA;[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000&#xA;[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006&#xA;[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000&#xA;[1135630.429410] Call trace:&#xA;[1135630.434828]  kprobe_perf_func+0x30/0x260&#xA;[1135630.441661]  kprobe_dispatcher+0x44/0x60&#xA;[1135630.448396]  aggr_pre_handler+0x70/0xc8&#xA;[1135630.454959]  kprobe_breakpoint_handler+0x140/0x1e0&#xA;[1135630.462435]  brk_handler+0xbc/0xd8&#xA;[1135630.468437]  do_debug_exception+0x84/0x138&#xA;[1135630.475074]  el1_dbg+0x18/0x8c&#xA;[1135630.480582]  security_file_permission+0x0/0xd0&#xA;[1135630.487426]  vfs_write+0x70/0x1c0&#xA;[1135630.493059]  ksys_write+0x5c/0xc8&#xA;[1135630.498638]  __arm64_sys_write+0x24/0x30&#xA;[1135630.504821]  el0_svc_common+0x78/0x130&#xA;[1135630.510838]  el0_svc_handler+0x38/0x78&#xA;[1135630.516834]  el0_svc+0x8/0x1b0&#xA;&#xA;kernel/trace/trace_kprobe.c: 1308&#xA;0xffff3df8995039ec &lt;kprobe_perf_func+0x2c&gt;:     ldr     x21, [x24,#120]&#xA;include/linux/compiler.h: 294&#xA;0xffff3df8995039f0 &lt;kprobe_perf_func+0x30&gt;:     ldr     x1, [x21,x0]&#xA;&#xA;kernel/trace/trace_kprobe.c&#xA;1308: head = this_cpu_ptr(call-&gt;perf_events);&#xA;1309: if (hlist_empty(head))&#xA;1310: &#x9;return 0;&#xA;&#xA;crash&gt; struct trace_event_call -o&#xA;struct trace_event_call {&#xA;  ...&#xA;  [120] struct hlist_head *perf_events;  //(call-&gt;perf_event)&#xA;  ...&#xA;}&#xA;&#xA;crash&gt; struct trace_event_call ffffaf015340e528&#xA;struct trace_event_call {&#xA;  ...&#xA;  perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0&#xA;  ...&#xA;}&#xA;&#xA;Race Condition Analysis:&#xA;&#xA;The race occurs between kprobe activation and perf_events initialization:&#xA;&#xA;  CPU0                                    CPU1&#xA;  ====                                    ====&#xA;  perf_kprobe_init&#xA;    perf_trace_event_init&#xA;      tp_event-&gt;perf_events = list;(1)&#xA;      tp_event-&gt;class-&gt;reg (2)← KPROBE ACTIVE&#xA;                                          Debug exception triggers&#xA;                                          ...&#xA;                                          kprobe_dispatcher&#xA;                                            kprobe_perf_func (tk-&gt;tp.flags &amp; TP_FLAG_PROFILE)&#xA;                                              head = this_cpu_ptr(call-&gt;perf_events)(3)&#xA;                                              (perf_events is still NULL)&#xA;&#xA;Problem:&#xA;1. CPU0 executes (1) assigning tp_event-&gt;perf_events = list&#xA;2. CPU0 executes (2) enabling kprobe functionality via class-&gt;reg()&#xA;3. CPU1 triggers and reaches kprobe_dispatcher&#xA;4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)&#xA;5. CPU1 calls kprobe_perf_func() and crashes at (3) because&#xA;   call-&gt;perf_events is still NULL&#xA;&#xA;CPU1 sees that kprobe functionality is enabled but does not see that&#xA;perf_events has been assigned.&#xA;&#xA;Add pairing read an&#xA;---truncated---&#xA;CVE-2025-40044:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs: udf: fix OOB read in lengthAllocDescs handling&#xA;&#xA;When parsing Allocation Extent Descriptor, lengthAllocDescs comes from&#xA;on-disk data and must be validated against the block size. Crafted or&#xA;corrupted images may set lengthAllocDescs so that the total descriptor&#xA;length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,&#xA;leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and&#xA;trigger a KASAN use-after-free read.&#xA;&#xA;BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60&#xA;Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309&#xA;&#xA;CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:377 [inline]&#xA; print_report+0x169/0x550 mm/kasan/report.c:488&#xA; kasan_report+0x143/0x180 mm/kasan/report.c:601&#xA; crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60&#xA; udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261&#xA; udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179&#xA; extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46&#xA; udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106&#xA; udf_release_file+0xc1/0x120 fs/udf/file.c:185&#xA; __fput+0x23f/0x880 fs/file_table.c:431&#xA; task_work_run+0x24f/0x310 kernel/task_work.c:239&#xA; exit_task_work include/linux/task_work.h:43 [inline]&#xA; do_exit+0xa2f/0x28e0 kernel/exit.c:939&#xA; do_group_exit+0x207/0x2c0 kernel/exit.c:1088&#xA; __do_sys_exit_group kernel/exit.c:1099 [inline]&#xA; __se_sys_exit_group kernel/exit.c:1097 [inline]&#xA; __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097&#xA; x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA; &lt;/TASK&gt;&#xA;&#xA;Validate the computed total length against epos-&gt;bh-&gt;b_size.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2025-40115:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()&#xA;&#xA;During mpt3sas_transport_port_remove(), messages were logged with&#xA;dev_printk() against &amp;mpt3sas_port-&gt;port-&gt;dev. At this point the SAS&#xA;transport device may already be partially unregistered or freed, leading&#xA;to a crash when accessing its struct device.&#xA;&#xA;Using ioc_info(), which logs via the PCI device (ioc-&gt;pdev-&gt;dev),&#xA;guaranteed to remain valid until driver removal.&#xA;&#xA;[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI&#xA;[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G           OE       6.16.0-rc1+ #1 PREEMPT(voluntary)&#xA;[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE&#xA;[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024&#xA;[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70&#xA;[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 &lt;48&gt; 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff&#xA;[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206&#xA;[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32&#xA;[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845&#xA;[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8&#xA;[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000&#xA;[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30&#xA;[83428.295833] FS:  00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000&#xA;[83428.295837] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0&#xA;[83428.295844] PKRU: 55555554&#xA;[83428.295846] Call Trace:&#xA;[83428.295848]  &lt;TASK&gt;&#xA;[83428.295850]  _dev_printk+0x5c/0x80&#xA;[83428.295857]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[83428.295863]  mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas]&#xA;[83428.295882]  _scsih_remove_device+0x21b/0x280 [mpt3sas]&#xA;[83428.295894]  ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas]&#xA;[83428.295906]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[83428.295910]  mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas]&#xA;[83428.295921]  _scsih_expander_node_remove+0x129/0x140 [mpt3sas]&#xA;[83428.295933]  _scsih_expander_node_remove+0x6a/0x140 [mpt3sas]&#xA;[83428.295944]  scsih_remove+0x3f0/0x4a0 [mpt3sas]&#xA;[83428.295957]  pci_device_remove+0x3b/0xb0&#xA;[83428.295962]  device_release_driver_internal+0x193/0x200&#xA;[83428.295968]  driver_detach+0x44/0x90&#xA;[83428.295971]  bus_remove_driver+0x69/0xf0&#xA;[83428.295975]  pci_unregister_driver+0x2a/0xb0&#xA;[83428.295979]  _mpt3sas_exit+0x1f/0x300 [mpt3sas]&#xA;[83428.295991]  __do_sys_delete_module.constprop.0+0x174/0x310&#xA;[83428.295997]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[83428.296000]  ? __x64_sys_getdents64+0x9a/0x110&#xA;[83428.296005]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[83428.296009]  ? syscall_trace_enter+0xf6/0x1b0&#xA;[83428.296014]  do_syscall_64+0x7b/0x2c0&#xA;[83428.296019]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[83428.296023]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2025-38415:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Squashfs: check return result of sb_min_blocksize&#xA;&#xA;Syzkaller reports an &#34;UBSAN: shift-out-of-bounds in squashfs_bio_read&#34; bug.&#xA;&#xA;Syzkaller forks multiple processes which after mounting the Squashfs&#xA;filesystem, issues an ioctl(&#34;/dev/loop0&#34;, LOOP_SET_BLOCK_SIZE, 0x8000). &#xA;Now if this ioctl occurs at the same time another process is in the&#xA;process of mounting a Squashfs filesystem on /dev/loop0, the failure&#xA;occurs.  When this happens the following code in squashfs_fill_super()&#xA;fails.&#xA;&#xA;----&#xA;msblk-&gt;devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);&#xA;msblk-&gt;devblksize_log2 = ffz(~msblk-&gt;devblksize);&#xA;----&#xA;&#xA;sb_min_blocksize() returns 0, which means msblk-&gt;devblksize is set to 0.&#xA;&#xA;As a result, ffz(~msblk-&gt;devblksize) returns 64, and msblk-&gt;devblksize_log2&#xA;is set to 64.&#xA;&#xA;This subsequently causes the&#xA;&#xA;UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36&#xA;shift exponent 64 is too large for 64-bit type &#39;u64&#39; (aka&#xA;&#39;unsigned long long&#39;)&#xA;&#xA;This commit adds a check for a 0 return by sb_min_blocksize().&#xA;CVE-2025-21914:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;slimbus: messaging: Free transaction ID in delayed interrupt scenario&#xA;&#xA;In case of interrupt delay for any reason, slim_do_transfer()&#xA;returns timeout error but the transaction ID (TID) is not freed.&#xA;This results into invalid memory access inside&#xA;qcom_slim_ngd_rx_msgq_cb() due to invalid TID.&#xA;&#xA;Fix the issue by freeing the TID in slim_do_transfer() before&#xA;returning timeout error to avoid invalid memory access.&#xA;&#xA;Call trace:&#xA;__memcpy_fromio+0x20/0x190&#xA;qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]&#xA;vchan_complete+0x2a0/0x4a0&#xA;tasklet_action_common+0x274/0x700&#xA;tasklet_action+0x28/0x3c&#xA;_stext+0x188/0x620&#xA;run_ksoftirqd+0x34/0x74&#xA;smpboot_thread_fn+0x1d8/0x464&#xA;kthread+0x178/0x238&#xA;ret_from_fork+0x10/0x20&#xA;Code: aa0003e8 91000429 f100044a 3940002b (3800150b)&#xA;---[ end trace 0fe00bec2b975c99 ]---&#xA;Kernel panic - not syncing: Oops: Fatal exception in interrupt.&#xA;CVE-2023-53034:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans&#xA;&#xA;There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and&#xA;size. This would make xlate_pos negative.&#xA;&#xA;[   23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000&#xA;[   23.734158] ================================================================================&#xA;[   23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7&#xA;[   23.734418] shift exponent -1 is negative&#xA;&#xA;Ensuring xlate_pos is a positive or zero before BIT.&#xA;CVE-2025-39757:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Validate UAC3 cluster segment descriptors&#xA;&#xA;UAC3 class segment descriptors need to be verified whether their sizes&#xA;match with the declared lengths and whether they fit with the&#xA;allocated buffer sizes, too.  Otherwise malicious firmware may lead to&#xA;the unexpected OOB accesses.&#xA;CVE-2025-37810:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: dwc3: gadget: check that event count does not exceed event buffer length&#xA;&#xA;The event count is read from register DWC3_GEVNTCOUNT.&#xA;There is a check for the count being zero, but not for exceeding the&#xA;event buffer length.&#xA;Check that event count does not exceed event buffer length,&#xA;avoiding an out-of-bounds access when memcpy&#39;ing the event.&#xA;Crash log:&#xA;Unable to handle kernel paging request at virtual address ffffffc0129be000&#xA;pc : __memcpy+0x114/0x180&#xA;lr : dwc3_check_event_buf+0xec/0x348&#xA;x3 : 0000000000000030 x2 : 000000000000dfc4&#xA;x1 : ffffffc0129be000 x0 : ffffff87aad60080&#xA;Call trace:&#xA;__memcpy+0x114/0x180&#xA;dwc3_interrupt+0x24/0x34&#xA;CVE-2025-40157:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller&#xA;&#xA;When loading the i10nm_edac driver on some Intel Granite Rapids servers,&#xA;a call trace may appear as follows:&#xA;&#xA;  UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16&#xA;  shift exponent -66 is negative&#xA;  ...&#xA;  __ubsan_handle_shift_out_of_bounds+0x1e3/0x390&#xA;  skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]&#xA;  i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]&#xA;  skx_register_mci+0x159/0x220 [skx_edac_common]&#xA;  i10nm_init+0xcb0/0x1ff0 [i10nm_edac]&#xA;  ...&#xA;&#xA;This occurs because some BIOS may disable a memory controller if there&#xA;aren&#39;t any memory DIMMs populated on this memory controller. The DIMMMTR&#xA;register of this disabled memory controller contains the invalid value&#xA;~0, resulting in the call trace above.&#xA;&#xA;Fix this call trace by skipping DIMM enumeration on a disabled memory&#xA;controller.&#xA;CVE-2025-40123:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Enforce expected_attach_type for tailcall compatibility&#xA;&#xA;Yinhao et al. recently reported:&#xA;&#xA;  Our fuzzer tool discovered an uninitialized pointer issue in the&#xA;  bpf_prog_test_run_xdp() function within the Linux kernel&#39;s BPF subsystem.&#xA;  This leads to a NULL pointer dereference when a BPF program attempts to&#xA;  deference the txq member of struct xdp_buff object.&#xA;&#xA;The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the&#xA;entry point for bpf_prog_test_run_xdp() and its expected_attach_type can&#xA;neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot&#xA;of a tailcall map it owns. progB&#39;s expected_attach_type must be BPF_XDP_DEVMAP&#xA;to pass xdp_is_valid_access() validation. The program returns struct xdp_md&#39;s&#xA;egress_ifindex, and the latter is only allowed to be accessed under mentioned&#xA;expected_attach_type. progB is then inserted into the tailcall which progA&#xA;calls.&#xA;&#xA;The underlying issue goes beyond XDP though. Another example are programs&#xA;of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well&#xA;as sock_addr_func_proto() have different logic depending on the programs&#39;&#xA;expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME&#xA;should not be allowed doing a tailcall into a program which calls bpf_bind()&#xA;out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.&#xA;&#xA;In short, specifying expected_attach_type allows to open up additional&#xA;functionality or restrictions beyond what the basic bpf_prog_type enables.&#xA;The use of tailcalls must not violate these constraints. Fix it by enforcing&#xA;expected_attach_type in __bpf_prog_map_compatible().&#xA;&#xA;Note that we only enforce this for tailcall maps, but not for BPF devmaps or&#xA;cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and&#xA;cpu_map_bpf_prog_run*() which set up a new environment / context and therefore&#xA;these situations are not prone to this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-devel-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/kernel-devel-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/kernel-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="291.0.0.194.u187" version="5.10.0">
					<filename>python3-perf-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-perf-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/kernel-tools-devel-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="291.0.0.194.u187" version="5.10.0">
					<filename>bpftool-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bpftool-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-headers-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/kernel-headers-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-tools-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/kernel-tools-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="291.0.0.194.u187" version="5.10.0">
					<filename>perf-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/perf-5.10.0-291.0.0.194.u187.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/kernel-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/kernel-tools-devel-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-devel-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/kernel-devel-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="291.0.0.194.u187" version="5.10.0">
					<filename>python3-perf-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-perf-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="291.0.0.194.u187" version="5.10.0">
					<filename>perf-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/perf-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-tools-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/kernel-tools-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="291.0.0.194.u187" version="5.10.0">
					<filename>bpftool-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bpftool-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="291.0.0.194.u187" version="5.10.0">
					<filename>kernel-headers-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/kernel-headers-5.10.0-291.0.0.194.u187.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2341</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61661&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61661" id="CVE-2025-61661" title="CVE-2025-61661" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61662&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61662" id="CVE-2025-61662" title="CVE-2025-61662" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54771&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54771" id="CVE-2025-54771" title="CVE-2025-54771" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61663&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61663" id="CVE-2025-61663" title="CVE-2025-61663" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61664&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61664" id="CVE-2025-61664" title="CVE-2025-61664" type="cve"></reference>
		</references>
		<description>CVE-2025-61661:A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.&#xA;CVE-2025-61662:A Use-After-Free vulnerability has been discovered in GRUB&#39;s gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.&#xA;CVE-2025-54771:A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.&#xA;CVE-2025-61663:A vulnerability has been identified in the GRUB2 bootloader&#39;s normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.&#xA;CVE-2025-61664:A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="1" name="grub2-efi-x64-modules" release="53.u19" version="2.06">
					<filename>grub2-efi-x64-modules-2.06-53.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-x64-modules-2.06-53.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-pc-modules" release="53.u19" version="2.06">
					<filename>grub2-pc-modules-2.06-53.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-pc-modules-2.06-53.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-aa64-modules" release="53.u19" version="2.06">
					<filename>grub2-efi-aa64-modules-2.06-53.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-aa64-modules-2.06-53.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-efi-ia32-modules" release="53.u19" version="2.06">
					<filename>grub2-efi-ia32-modules-2.06-53.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-ia32-modules-2.06-53.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-help" release="53.u19" version="2.06">
					<filename>grub2-help-2.06-53.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-help-2.06-53.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="grub2-common" release="53.u19" version="2.06">
					<filename>grub2-common-2.06-53.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-common-2.06-53.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools" release="53.u19" version="2.06">
					<filename>grub2-tools-2.06-53.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/grub2-tools-2.06-53.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-efi-aa64-cdboot" release="53.u19" version="2.06">
					<filename>grub2-efi-aa64-cdboot-2.06-53.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/grub2-efi-aa64-cdboot-2.06-53.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-efi-aa64" release="53.u19" version="2.06">
					<filename>grub2-efi-aa64-2.06-53.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/grub2-efi-aa64-2.06-53.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-extra" release="53.u19" version="2.06">
					<filename>grub2-tools-extra-2.06-53.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/grub2-tools-extra-2.06-53.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="grub2-tools-minimal" release="53.u19" version="2.06">
					<filename>grub2-tools-minimal-2.06-53.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/grub2-tools-minimal-2.06-53.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32" release="53.u19" version="2.06">
					<filename>grub2-efi-ia32-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-ia32-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64-cdboot" release="53.u19" version="2.06">
					<filename>grub2-efi-x64-cdboot-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-x64-cdboot-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-extra" release="53.u19" version="2.06">
					<filename>grub2-tools-extra-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-tools-extra-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-x64" release="53.u19" version="2.06">
					<filename>grub2-efi-x64-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-x64-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-minimal" release="53.u19" version="2.06">
					<filename>grub2-tools-minimal-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-tools-minimal-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-pc" release="53.u19" version="2.06">
					<filename>grub2-pc-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-pc-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools" release="53.u19" version="2.06">
					<filename>grub2-tools-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-tools-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-tools-efi" release="53.u19" version="2.06">
					<filename>grub2-tools-efi-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-tools-efi-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="grub2-efi-ia32-cdboot" release="53.u19" version="2.06">
					<filename>grub2-efi-ia32-cdboot-2.06-53.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/grub2-efi-ia32-cdboot-2.06-53.u19.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2342</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3470&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-3470" id="CVE-2021-3470" title="CVE-2021-3470" type="cve"></reference>
		</references>
		<description>CVE-2021-3470:A heap overflow issue was found in Redis in versions before 5.0.10, before 6.0.9 and before 6.2.0 when using a heap allocator other than jemalloc or glibc&#39;s malloc, leading to potential out of bound write or process crash. Effectively this flaw does not affect the vast majority of users, who use jemalloc or glibc malloc.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u14" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/redis5-doc-5.0.7-6.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u14" version="5.0.7">
					<filename>redis5-5.0.7-6.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/redis5-5.0.7-6.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u14" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/redis5-devel-5.0.7-6.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u14" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/redis5-devel-5.0.7-6.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u14" version="5.0.7">
					<filename>redis5-5.0.7-6.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/redis5-5.0.7-6.u14.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2343</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-12818&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-12818" id="CVE-2025-12818" title="CVE-2025-12818" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-12817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-12817" id="CVE-2025-12817" title="CVE-2025-12817" type="cve"></reference>
		</references>
		<description>CVE-2025-12818:Integer wraparound in multiple PostgreSQL libpq client library functions allows an application input provider or network peer to cause libpq to undersize an allocation and write out-of-bounds by hundreds of megabytes.  This results in a segmentation fault for the application using libpq.  Versions before PostgreSQL 18.1, 17.7, 16.11, 15.15, 14.20, and 13.23 are affected.&#xA;CVE-2025-12817:Missing authorization in PostgreSQL CREATE STATISTICS command allows a table owner to achieve denial of service against other CREATE STATISTICS users by creating in any schema.  A later CREATE STATISTICS for the same name, from a user having the CREATE privilege, would then fail.  Versions before PostgreSQL 18.1, 17.7, 16.11, 15.15, 14.20, and 13.23 are affected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u4" version="13.23">
					<filename>postgresql-private-devel-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-private-devel-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u4" version="13.23">
					<filename>postgresql-static-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-static-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u4" version="13.23">
					<filename>postgresql-private-libs-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-private-libs-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u4" version="13.23">
					<filename>postgresql-test-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-test-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u4" version="13.23">
					<filename>postgresql-llvmjit-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-llvmjit-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u4" version="13.23">
					<filename>postgresql-plpython3-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-plpython3-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u4" version="13.23">
					<filename>postgresql-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u4" version="13.23">
					<filename>postgresql-server-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-server-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u4" version="13.23">
					<filename>postgresql-contrib-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-contrib-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u4" version="13.23">
					<filename>postgresql-docs-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-docs-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u4" version="13.23">
					<filename>postgresql-pltcl-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-pltcl-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u4" version="13.23">
					<filename>postgresql-server-devel-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-server-devel-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u4" version="13.23">
					<filename>postgresql-plperl-13.23-1.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/postgresql-plperl-13.23-1.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u4" version="13.23">
					<filename>postgresql-server-devel-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-server-devel-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u4" version="13.23">
					<filename>postgresql-private-libs-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-private-libs-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u4" version="13.23">
					<filename>postgresql-docs-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-docs-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u4" version="13.23">
					<filename>postgresql-llvmjit-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-llvmjit-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u4" version="13.23">
					<filename>postgresql-server-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-server-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u4" version="13.23">
					<filename>postgresql-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u4" version="13.23">
					<filename>postgresql-test-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-test-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u4" version="13.23">
					<filename>postgresql-plperl-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-plperl-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u4" version="13.23">
					<filename>postgresql-plpython3-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-plpython3-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u4" version="13.23">
					<filename>postgresql-pltcl-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-pltcl-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u4" version="13.23">
					<filename>postgresql-private-devel-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-private-devel-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u4" version="13.23">
					<filename>postgresql-static-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-static-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u4" version="13.23">
					<filename>postgresql-contrib-13.23-1.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-contrib-13.23-1.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u4" version="13.23">
					<filename>postgresql-test-rpm-macros-13.23-1.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/postgresql-test-rpm-macros-13.23-1.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2344</id>
		<title>An update for plexus-archiver is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37460&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-37460" id="CVE-2023-37460" title="CVE-2023-37460" type="cve"></reference>
		</references>
		<description>CVE-2023-37460:Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified `Archiver`/`UnArchiver` API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the `resolveFile()` function will return the symlink&#39;s source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later `Files.newOutputStream()`, that follows symlinks by default,  will actually write the entry&#39;s content to the symlink&#39;s target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="plexus-archiver" release="2.u1" version="4.2.6">
					<filename>plexus-archiver-4.2.6-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/plexus-archiver-4.2.6-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2345</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32364&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32364" id="CVE-2025-32364" title="CVE-2025-32364" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32365&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-32365" id="CVE-2025-32365" title="CVE-2025-32365" type="cve"></reference>
		</references>
		<description>CVE-2025-32364:A floating-point exception in the PSStack::roll function of Poppler before 25.04.0 can cause an application to crash when handling malformed inputs associated with INT_MIN.&#xA;CVE-2025-32365:Poppler before 25.04.0 allows crafted input files to trigger out-of-bounds reads in the JBIG2Bitmap::combine function in JBIG2Stream.cc because of a misplaced isOk check.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="poppler-help" release="11.u8" version="0.90.0">
					<filename>poppler-help-0.90.0-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-help-0.90.0-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="11.u8" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-glib-doc-0.90.0-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="11.u8" version="0.90.0">
					<filename>poppler-cpp-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-cpp-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="11.u8" version="0.90.0">
					<filename>poppler-devel-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-devel-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="11.u8" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-qt5-devel-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="11.u8" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-cpp-devel-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="11.u8" version="0.90.0">
					<filename>poppler-qt5-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-qt5-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler" release="11.u8" version="0.90.0">
					<filename>poppler-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="11.u8" version="0.90.0">
					<filename>poppler-glib-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-glib-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="11.u8" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-glib-devel-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="11.u8" version="0.90.0">
					<filename>poppler-utils-0.90.0-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/poppler-utils-0.90.0-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="11.u8" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-glib-devel-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="11.u8" version="0.90.0">
					<filename>poppler-qt5-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-qt5-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="11.u8" version="0.90.0">
					<filename>poppler-devel-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-devel-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="11.u8" version="0.90.0">
					<filename>poppler-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="11.u8" version="0.90.0">
					<filename>poppler-cpp-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-cpp-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="11.u8" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-qt5-devel-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="11.u8" version="0.90.0">
					<filename>poppler-glib-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-glib-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="11.u8" version="0.90.0">
					<filename>poppler-utils-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-utils-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="11.u8" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/poppler-cpp-devel-0.90.0-11.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2346</id>
		<title>An update for woodstox-core is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40152&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-40152" id="CVE-2022-40152" title="CVE-2022-40152" type="cve"></reference>
		</references>
		<description>CVE-2022-40152:Those using Woodstox to parse XML data may be vulnerable to Denial of Service attacks (DOS) if DTD support is enabled. If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="woodstox-core" release="2.u2" version="5.0.3">
					<filename>woodstox-core-5.0.3-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/woodstox-core-5.0.3-2.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="woodstox-core-javadoc" release="2.u2" version="5.0.3">
					<filename>woodstox-core-javadoc-5.0.3-2.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/woodstox-core-javadoc-5.0.3-2.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2347</id>
		<title>An update for netty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-24823" id="CVE-2022-24823" title="CVE-2022-24823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59419" id="CVE-2025-59419" title="CVE-2025-59419" type="cve"></reference>
		</references>
		<description>CVE-2022-24823:Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty&#39;s multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one&#39;s own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.&#xA;CVE-2025-59419:Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.128.Final and 4.2.7.Final, the SMTP codec in Netty contains an SMTP command injection vulnerability due to insufficient input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. The vulnerability exists in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string without sanitization. When methods such as SmtpRequests.rcpt(recipient) are called with a malicious string containing CRLF sequences, attackers can inject arbitrary SMTP commands. Because the injected commands are sent from the server&#39;s trusted IP address, resulting emails will likely pass SPF and DKIM authentication checks, making them appear legitimate. This allows remote attackers who can control SMTP command parameters (such as email recipients) to forge arbitrary emails from the trusted server, potentially impersonating executives and forging high-stakes corporate communications. This issue has been patched in versions 4.1.129.Final and 4.2.8.Final. No known workarounds exist.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="netty-help" release="24.u5" version="4.1.13">
					<filename>netty-help-4.1.13-24.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/netty-help-4.1.13-24.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="netty" release="24.u5" version="4.1.13">
					<filename>netty-4.1.13-24.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/netty-4.1.13-24.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="netty" release="24.u5" version="4.1.13">
					<filename>netty-4.1.13-24.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/netty-4.1.13-24.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2348</id>
		<title>An update for proftpd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57392&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57392" id="CVE-2024-57392" title="CVE-2024-57392" type="cve"></reference>
		</references>
		<description>CVE-2024-57392:Buffer Overflow vulnerability in Proftpd commit 4017eff8 allows a remote attacker to execute arbitrary code and can cause a Denial of Service (DoS) on the FTP service by sending a maliciously crafted message to the ProFTPD service port.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="proftpd-utils" release="6.u3" version="1.3.8b">
					<filename>proftpd-utils-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-utils-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-mysql" release="6.u3" version="1.3.8b">
					<filename>proftpd-mysql-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-mysql-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd" release="6.u3" version="1.3.8b">
					<filename>proftpd-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-sqlite" release="6.u3" version="1.3.8b">
					<filename>proftpd-sqlite-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-sqlite-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-devel" release="6.u3" version="1.3.8b">
					<filename>proftpd-devel-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-devel-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-ldap" release="6.u3" version="1.3.8b">
					<filename>proftpd-ldap-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-ldap-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="proftpd-postgresql" release="6.u3" version="1.3.8b">
					<filename>proftpd-postgresql-1.3.8b-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/proftpd-postgresql-1.3.8b-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-utils" release="6.u3" version="1.3.8b">
					<filename>proftpd-utils-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-utils-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-sqlite" release="6.u3" version="1.3.8b">
					<filename>proftpd-sqlite-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-sqlite-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd" release="6.u3" version="1.3.8b">
					<filename>proftpd-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-devel" release="6.u3" version="1.3.8b">
					<filename>proftpd-devel-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-devel-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-ldap" release="6.u3" version="1.3.8b">
					<filename>proftpd-ldap-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-ldap-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-mysql" release="6.u3" version="1.3.8b">
					<filename>proftpd-mysql-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-mysql-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="proftpd-postgresql" release="6.u3" version="1.3.8b">
					<filename>proftpd-postgresql-1.3.8b-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/proftpd-postgresql-1.3.8b-6.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2349</id>
		<title>An update for enscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17942&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-17942" id="CVE-2018-17942" title="CVE-2018-17942" type="cve"></reference>
		</references>
		<description>CVE-2018-17942:The convert_to_decimal function in vasnprintf.c in Gnulib before 2018-09-23 has a heap-based buffer overflow because memory is not allocated for a trailing &#39;\0&#39; character during %f processing.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="enscript-help" release="22.u2" version="1.6.6">
					<filename>enscript-help-1.6.6-22.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/enscript-help-1.6.6-22.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="enscript" release="22.u2" version="1.6.6">
					<filename>enscript-1.6.6-22.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/enscript-1.6.6-22.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="enscript" release="22.u2" version="1.6.6">
					<filename>enscript-1.6.6-22.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/enscript-1.6.6-22.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="enscript-help" release="22.u2" version="1.6.6">
					<filename>enscript-help-1.6.6-22.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/enscript-help-1.6.6-22.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2350</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61984&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61984" id="CVE-2025-61984" title="CVE-2025-61984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61985&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61985" id="CVE-2025-61985" title="CVE-2025-61985" type="cve"></reference>
		</references>
		<description>CVE-2025-61984:ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)&#xA;CVE-2025-61985:ssh in OpenSSH before 10.1 allows the &#39;\0&#39; character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="openssh-help" release="37.u28" version="8.8p1">
					<filename>openssh-help-8.8p1-37.u28.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssh-help-8.8p1-37.u28.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="37.u28" version="8.8p1">
					<filename>openssh-keycat-8.8p1-37.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssh-keycat-8.8p1-37.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="37.u28" version="8.8p1">
					<filename>openssh-server-8.8p1-37.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssh-server-8.8p1-37.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="37.u28" version="8.8p1">
					<filename>openssh-askpass-8.8p1-37.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssh-askpass-8.8p1-37.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh" release="37.u28" version="8.8p1">
					<filename>openssh-8.8p1-37.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssh-8.8p1-37.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.37.u28" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.37.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/pam_ssh_agent_auth-0.10.4-4.37.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="37.u28" version="8.8p1">
					<filename>openssh-clients-8.8p1-37.u28.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssh-clients-8.8p1-37.u28.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="37.u28" version="8.8p1">
					<filename>openssh-clients-8.8p1-37.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssh-clients-8.8p1-37.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="37.u28" version="8.8p1">
					<filename>openssh-keycat-8.8p1-37.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssh-keycat-8.8p1-37.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="37.u28" version="8.8p1">
					<filename>openssh-askpass-8.8p1-37.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssh-askpass-8.8p1-37.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="37.u28" version="8.8p1">
					<filename>openssh-server-8.8p1-37.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssh-server-8.8p1-37.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.37.u28" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.37.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/pam_ssh_agent_auth-0.10.4-4.37.u28.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh" release="37.u28" version="8.8p1">
					<filename>openssh-8.8p1-37.u28.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssh-8.8p1-37.u28.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2351</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40778" id="CVE-2025-40778" title="CVE-2025-40778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40780&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40780" id="CVE-2025-40780" title="CVE-2025-40780" type="cve"></reference>
		</references>
		<description>CVE-2025-40778:Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.&#xA;CVE-2025-40780:In specific circumstances, due to a weakness in the Pseudo Random Number Generator (PRNG) that is used, it is possible for an attacker to predict the source port and query ID that BIND will use.&#xA;This issue affects BIND 9 versions 9.16.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.16.8-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="28.u13" version="9.16.23">
					<filename>bind-chroot-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-chroot-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-pkcs11-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-pkcs11-libs-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-pkcs11-utils-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="28.u13" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-dnssec-utils-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="28.u13" version="9.16.23">
					<filename>bind-devel-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-devel-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-pkcs11-devel-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="28.u13" version="9.16.23">
					<filename>bind-utils-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-utils-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind" release="28.u13" version="9.16.23">
					<filename>bind-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="28.u13" version="9.16.23">
					<filename>bind-libs-9.16.23-28.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-libs-9.16.23-28.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="28.u13" version="9.16.23">
					<filename>bind-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="28.u13" version="9.16.23">
					<filename>bind-libs-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-libs-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="28.u13" version="9.16.23">
					<filename>bind-chroot-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-chroot-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-pkcs11-libs-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="28.u13" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-dnssec-utils-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-pkcs11-utils-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="28.u13" version="9.16.23">
					<filename>bind-utils-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-utils-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-pkcs11-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="28.u13" version="9.16.23">
					<filename>bind-devel-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-devel-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="28.u13" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-28.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/bind-pkcs11-devel-9.16.23-28.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="28.u13" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-28.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-dnssec-doc-9.16.23-28.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-license" release="28.u13" version="9.16.23">
					<filename>bind-license-9.16.23-28.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/bind-license-9.16.23-28.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="28.u13" version="9.16.23">
					<filename>python3-bind-9.16.23-28.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-bind-9.16.23-28.u13.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2352</id>
		<title>An update for lighttpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8671&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8671" id="CVE-2025-8671" title="CVE-2025-8671" type="cve"></reference>
		</references>
		<description>CVE-2025-8671:A mismatch caused by client-triggered server-sent stream resets between HTTP/2 specifications and the internal architectures of some HTTP/2 implementations may result in excessive server resource consumption leading to denial-of-service (DoS).  By opening streams and then rapidly triggering the server to reset them—using malformed frames or flow control errors—an attacker can exploit incorrect stream accounting. Streams reset by the server are considered closed at the protocol level, even though backend processing continues. This allows a client to cause the server to handle an unbounded number of concurrent streams on a single connection. This CVE will be updated as affected product details are released.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="aarch64" epoch="0" name="lighttpd" release="2.u1" version="1.4.67">
					<filename>lighttpd-1.4.67-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/lighttpd-1.4.67-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lighttpd-mod_mysql_vhost" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_mysql_vhost-1.4.67-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/lighttpd-mod_mysql_vhost-1.4.67-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lighttpd-mod_authn_pam" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_authn_pam-1.4.67-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/lighttpd-mod_authn_pam-1.4.67-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lighttpd-mod_authn_mysql" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_authn_mysql-1.4.67-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/lighttpd-mod_authn_mysql-1.4.67-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lighttpd-mod_authn_gssapi" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_authn_gssapi-1.4.67-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/lighttpd-mod_authn_gssapi-1.4.67-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lighttpd-fastcgi" release="2.u1" version="1.4.67">
					<filename>lighttpd-fastcgi-1.4.67-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/lighttpd-fastcgi-1.4.67-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="lighttpd-filesystem" release="2.u1" version="1.4.67">
					<filename>lighttpd-filesystem-1.4.67-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-filesystem-1.4.67-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lighttpd-mod_authn_pam" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_authn_pam-1.4.67-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-mod_authn_pam-1.4.67-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lighttpd-mod_mysql_vhost" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_mysql_vhost-1.4.67-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-mod_mysql_vhost-1.4.67-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lighttpd" release="2.u1" version="1.4.67">
					<filename>lighttpd-1.4.67-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-1.4.67-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lighttpd-fastcgi" release="2.u1" version="1.4.67">
					<filename>lighttpd-fastcgi-1.4.67-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-fastcgi-1.4.67-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lighttpd-mod_authn_gssapi" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_authn_gssapi-1.4.67-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-mod_authn_gssapi-1.4.67-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lighttpd-mod_authn_mysql" release="2.u1" version="1.4.67">
					<filename>lighttpd-mod_authn_mysql-1.4.67-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/lighttpd-mod_authn_mysql-1.4.67-2.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2353</id>
		<title>An update for mod_auth_openidc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31492&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31492" id="CVE-2025-31492" title="CVE-2025-31492" type="cve"></reference>
		</references>
		<description>CVE-2025-31492:mod_auth_openidc is an OpenID Certified authentication and authorization module for the Apache 2.x HTTP server that implements the OpenID Connect Relying Party functionality. Prior to 2.4.16.11, a bug in a mod_auth_openidc results in disclosure of protected content to unauthenticated users. The conditions for disclosure are an OIDCProviderAuthRequestMethod POST, a valid account, and there mustn&#39;t be any application-level gateway (or load balancer etc) protecting the server. When you request a protected resource, the response includes the HTTP status, the HTTP headers, the intended response (the self-submitting form), and the protected resource (with no headers). This is an example of a request for a protected resource, including all the data returned. In the case where mod_auth_openidc returns a form, it has to return OK from check_userid so as not to go down the error path in httpd. This means httpd will try to issue the protected resource. oidc_content_handler is called early, which has the opportunity to prevent the normal output being issued by httpd. oidc_content_handler has a number of checks for when it intervenes, but it doesn&#39;t check for this case, so the handler returns DECLINED. Consequently, httpd appends the protected content to the response. The issue has been patched in mod_auth_openidc versions &gt;= 2.4.16.11.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="mod_auth_openidc" release="1" version="2.4.16.11">
					<filename>mod_auth_openidc-2.4.16.11-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mod_auth_openidc-2.4.16.11-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_auth_openidc" release="1" version="2.4.16.11">
					<filename>mod_auth_openidc-2.4.16.11-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mod_auth_openidc-2.4.16.11-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2354</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-13176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-13176" id="CVE-2024-13176" title="CVE-2024-13176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9230&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9230" id="CVE-2025-9230" title="CVE-2025-9230" type="cve"></reference>
		</references>
		<description>CVE-2024-13176:Issue summary: A timing side-channel which could potentially allow recovering&#xA;the private key exists in the ECDSA signature computation.&#xA;&#xA;Impact summary: A timing side-channel in ECDSA signature computations&#xA;could allow recovering the private key by an attacker. However, measuring&#xA;the timing would require either local access to the signing application or&#xA;a very fast network connection with low latency.&#xA;&#xA;There is a timing signal of around 300 nanoseconds when the top word of&#xA;the inverted ECDSA nonce value is zero. This can happen with significant&#xA;probability only for some of the supported elliptic curves. In particular&#xA;the NIST P-521 curve is affected. To be able to measure this leak, the attacker&#xA;process must either be located in the same physical computer or must&#xA;have a very fast network connection with low latency. For that reason&#xA;the severity of this vulnerability is Low.&#xA;&#xA;The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.&#xA;CVE-2025-9230:Issue summary: An application trying to decrypt CMS messages encrypted using&#xA;password based encryption can trigger an out-of-bounds read and write.&#xA;&#xA;Impact summary: This out-of-bounds read may trigger a crash which leads to&#xA;Denial of Service for an application. The out-of-bounds write can cause&#xA;a memory corruption which can have various consequences including&#xA;a Denial of Service or Execution of attacker-supplied code.&#xA;&#xA;Although the consequences of a successful exploit of this vulnerability&#xA;could be severe, the probability that the attacker would be able to&#xA;perform it is low. Besides, password based (PWRI) encryption support in CMS&#xA;messages is very rarely used. For that reason the issue was assessed as&#xA;Moderate severity according to our Security Policy.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this&#xA;issue, as the CMS implementation is outside the OpenSSL FIPS module&#xA;boundary.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="39.u20" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssl-perl-1.1.1m-39.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="39.u20" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssl-libs-1.1.1m-39.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl" release="39.u20" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssl-1.1.1m-39.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="39.u20" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssl-devel-1.1.1m-39.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="39.u20" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssl-1.1.1m-39.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="39.u20" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssl-devel-1.1.1m-39.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="39.u20" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssl-libs-1.1.1m-39.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="39.u20" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/openssl-perl-1.1.1m-39.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="39.u20" version="1.1.1m">
					<filename>openssl-help-1.1.1m-39.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/openssl-help-1.1.1m-39.u20.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2355</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53069&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53069" id="CVE-2025-53069" title="CVE-2025-53069" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53062&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53062" id="CVE-2025-53062" title="CVE-2025-53062" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53054&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53054" id="CVE-2025-53054" title="CVE-2025-53054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53053&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53053" id="CVE-2025-53053" title="CVE-2025-53053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53045&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53045" id="CVE-2025-53045" title="CVE-2025-53045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53044&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53044" id="CVE-2025-53044" title="CVE-2025-53044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53042&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53042" id="CVE-2025-53042" title="CVE-2025-53042" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-53040&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-53040" id="CVE-2025-53040" title="CVE-2025-53040" type="cve"></reference>
		</references>
		<description>CVE-2025-53069:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-53062:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-53054:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-53053:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2025-53045:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-53044:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-53042:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-53040:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u5" version="8.0.44">
					<filename>mysql-server-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-server-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u5" version="8.0.44">
					<filename>mysql-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u5" version="8.0.44">
					<filename>mysql-help-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-help-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u5" version="8.0.44">
					<filename>mysql-common-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-common-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u5" version="8.0.44">
					<filename>mysql-errmsg-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-errmsg-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u5" version="8.0.44">
					<filename>mysql-libs-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-libs-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u5" version="8.0.44">
					<filename>mysql-config-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-config-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u5" version="8.0.44">
					<filename>mysql-devel-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-devel-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u5" version="8.0.44">
					<filename>mysql-test-8.0.44-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mysql-test-8.0.44-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u5" version="8.0.44">
					<filename>mysql-libs-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-libs-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u5" version="8.0.44">
					<filename>mysql-common-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-common-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u5" version="8.0.44">
					<filename>mysql-server-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-server-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u5" version="8.0.44">
					<filename>mysql-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u5" version="8.0.44">
					<filename>mysql-devel-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-devel-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u5" version="8.0.44">
					<filename>mysql-errmsg-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-errmsg-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u5" version="8.0.44">
					<filename>mysql-test-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-test-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u5" version="8.0.44">
					<filename>mysql-config-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-config-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u5" version="8.0.44">
					<filename>mysql-help-8.0.44-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mysql-help-8.0.44-1.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2356</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5574&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"></reference>
		</references>
		<description>CVE-2023-5574:A use-after-free flaw was found in xorg-x11-server-Xvfb. This issue occurs in Xvfb with a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode). If the pointer is warped from a screen 1 to a screen 0, a use-after-free issue may be triggered during shutdown or reset of the Xvfb server, allowing for possible escalation of privileges or denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-38.u25.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-help-1.20.11-38.u25.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-38.u25.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-source-1.20.11-38.u25.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-Xephyr-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-common-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-Xdmx-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-Xvfb-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-devel-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-38.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/xorg-x11-server-Xnest-1.20.11-38.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-Xdmx-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-Xvfb-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-Xephyr-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-Xnest-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-common-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-devel-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="38.u25" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-38.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/xorg-x11-server-1.20.11-38.u25.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2357</id>
		<title>An update for brotli is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6176" id="CVE-2025-6176" title="CVE-2025-6176" type="cve"></reference>
		</references>
		<description>CVE-2025-6176:Scrapy versions up to 2.13.2 are vulnerable to a denial of service (DoS) attack due to a flaw in its brotli decompression implementation. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="brotli" release="4.u1" version="1.0.9">
					<filename>brotli-1.0.9-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/brotli-1.0.9-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="brotli-devel" release="4.u1" version="1.0.9">
					<filename>brotli-devel-1.0.9-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/brotli-devel-1.0.9-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-brotli" release="4.u1" version="1.0.9">
					<filename>python3-brotli-1.0.9-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/python3-brotli-1.0.9-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="brotli" release="4.u1" version="1.0.9">
					<filename>brotli-1.0.9-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/brotli-1.0.9-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-brotli" release="4.u1" version="1.0.9">
					<filename>python3-brotli-1.0.9-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/python3-brotli-1.0.9-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="brotli-devel" release="4.u1" version="1.0.9">
					<filename>brotli-devel-1.0.9-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/brotli-devel-1.0.9-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="brotli-help" release="4.u1" version="1.0.9">
					<filename>brotli-help-1.0.9-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/brotli-help-1.0.9-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2025-2358</id>
		<title>An update for mod_security is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2025-12-19"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52891&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52891" id="CVE-2025-52891" title="CVE-2025-52891" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54571&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54571" id="CVE-2025-54571" title="CVE-2025-54571" type="cve"></reference>
		</references>
		<description>CVE-2025-52891:ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. In versions 2.9.8 to before 2.9.11, an empty XML tag can cause a segmentation fault. If SecParseXmlIntoArgs is set to On or OnlyArgs, and the request type is application/xml, and at least one XML tag is empty (eg &lt;foo&gt;&lt;/foo&gt;), then a segmentation fault occurs. This issue has been patched in version 2.9.11. A workaround involves setting SecParseXmlIntoArgs to Off.&#xA;CVE-2025-54571:ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. In versions 2.9.11&#xA;and below, an attacker can override the HTTP response’s Content-Type, which could lead to several issues depending on the HTTP scenario. For example, we have demonstrated the potential for XSS and arbitrary script source code disclosure in the latest version of mod_security2. This issue is fixed in version 2.9.12.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30</name>
				<package arch="x86_64" epoch="0" name="mod_security" release="1.u1" version="2.9.12">
					<filename>mod_security-2.9.12-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30/mod_security-2.9.12-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_security" release="1.u1" version="2.9.12">
					<filename>mod_security-2.9.12-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30/mod_security-2.9.12-1.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3000</id>
		<title>An update for exempi is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36045&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36045" id="CVE-2021-36045" title="CVE-2021-36045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36046&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36046" id="CVE-2021-36046" title="CVE-2021-36046" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36047&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36047" id="CVE-2021-36047" title="CVE-2021-36047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36048&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36048" id="CVE-2021-36048" title="CVE-2021-36048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36050" id="CVE-2021-36050" title="CVE-2021-36050" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36051&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36051" id="CVE-2021-36051" title="CVE-2021-36051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36052&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36052" id="CVE-2021-36052" title="CVE-2021-36052" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36053&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36053" id="CVE-2021-36053" title="CVE-2021-36053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36054&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36054" id="CVE-2021-36054" title="CVE-2021-36054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36055&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36055" id="CVE-2021-36055" title="CVE-2021-36055" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36056&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36056" id="CVE-2021-36056" title="CVE-2021-36056" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36058" id="CVE-2021-36058" title="CVE-2021-36058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-36064" id="CVE-2021-36064" title="CVE-2021-36064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-39847&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-39847" id="CVE-2021-39847" title="CVE-2021-39847" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40716&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-40716" id="CVE-2021-40716" title="CVE-2021-40716" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40732&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-40732" id="CVE-2021-40732" title="CVE-2021-40732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-42528&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-42528" id="CVE-2021-42528" title="CVE-2021-42528" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-42529&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-42529" id="CVE-2021-42529" title="CVE-2021-42529" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-42530&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-42530" id="CVE-2021-42530" title="CVE-2021-42530" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-42531&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-42531" id="CVE-2021-42531" title="CVE-2021-42531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-42532&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-42532" id="CVE-2021-42532" title="CVE-2021-42532" type="cve"></reference>
		</references>
		<description>CVE-2021-36045:XMP Toolkit SDK versions 2020.1 (and earlier) are affected by an out-of-bounds read vulnerability that could lead to disclosure of arbitrary memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.&#xA;CVE-2021-36046:XMP Toolkit version 2020.1 (and earlier) is affected by a memory corruption vulnerability, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.&#xA;CVE-2021-36047:XMP Toolkit SDK version 2020.1 (and earlier) is affected by an Improper Input Validation vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-36048:XMP Toolkit SDK version 2020.1 (and earlier) is affected by an Improper Input Validation vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-36050:XMP Toolkit SDK version 2020.1 (and earlier) is affected by a buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-36051:XMP Toolkit SDK version 2020.1 (and earlier) is affected by a buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a specially-crafted .cpp file.&#xA;CVE-2021-36052:XMP Toolkit version 2020.1 (and earlier) is affected by a memory corruption vulnerability, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.&#xA;CVE-2021-36053:XMP Toolkit SDK versions 2020.1 (and earlier) are affected by an out-of-bounds read vulnerability that could lead to disclosure of arbitrary memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.&#xA;CVE-2021-36054:XMP Toolkit SDK version 2020.1 (and earlier) is affected by a buffer overflow vulnerability potentially resulting in local application denial of service in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-36055:XMP Toolkit SDK versions 2020.1 (and earlier) are affected by a use-after-free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.&#xA;CVE-2021-36056:XMP Toolkit SDK version 2020.1 (and earlier) is affected by a buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-36058:XMP Toolkit SDK version 2020.1 (and earlier) is affected by an Integer Overflow vulnerability potentially resulting in application-level denial of service in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-36064:XMP Toolkit version 2020.1 (and earlier) is affected by a Buffer Underflow vulnerability which could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.&#xA;CVE-2021-39847:XMP Toolkit SDK version 2020.1 (and earlier) is affected by a stack-based buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-40716:XMP Toolkit SDK versions 2021.07 (and earlier) are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.&#xA;CVE-2021-40732:XMP Toolkit version 2020.1 (and earlier) is affected by a null pointer dereference vulnerability that could result in leaking data from certain memory locations and causing a local denial of service in the context of the current user. User interaction is required to exploit this vulnerability in that the victim will need to open a specially crafted MXF file.&#xA;CVE-2021-42528:XMP Toolkit 2021.07 (and earlier) is affected by a Null pointer dereference vulnerability when parsing a specially crafted file. An unauthenticated attacker could leverage this vulnerability to achieve an application denial-of-service in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.&#xA;CVE-2021-42529:XMP Toolkit SDK version 2021.07 (and earlier) is affected by a stack-based buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-42530:XMP Toolkit SDK version 2021.07 (and earlier) is affected by a stack-based buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-42531:XMP Toolkit SDK version 2021.07 (and earlier) is affected by a stack-based buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;CVE-2021-42532:XMP Toolkit SDK version 2021.07 (and earlier) is affected by a stack-based buffer overflow vulnerability potentially resulting in arbitrary code execution in the context of the current user. Exploitation requires user interaction in that a victim must open a crafted file.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="exempi-help" release="5.u1" version="2.5.2">
					<filename>exempi-help-2.5.2-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/exempi-help-2.5.2-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="exempi" release="5.u1" version="2.5.2">
					<filename>exempi-2.5.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/exempi-2.5.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="exempi-devel" release="5.u1" version="2.5.2">
					<filename>exempi-devel-2.5.2-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/exempi-devel-2.5.2-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="exempi" release="5.u1" version="2.5.2">
					<filename>exempi-2.5.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/exempi-2.5.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="exempi-devel" release="5.u1" version="2.5.2">
					<filename>exempi-devel-2.5.2-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/exempi-devel-2.5.2-5.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3001</id>
		<title>An update for texlive-base is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32668&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-32668" id="CVE-2023-32668" title="CVE-2023-32668" type="cve"></reference>
		</references>
		<description>CVE-2023-32668:LuaTeX before 1.17.0 allows a document (compiled with the default settings) to make arbitrary network requests. This occurs because full access to the socket library is permitted by default, as stated in the documentation. This also affects TeX Live before 2023 r66984 and MiKTeX before 23.5.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="7" name="texlive-pdftex" release="39.u4" version="20180414">
					<filename>texlive-pdftex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdftex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-aleph" release="39.u4" version="20180414">
					<filename>texlive-aleph-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-aleph-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mflua" release="39.u4" version="20180414">
					<filename>texlive-mflua-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mflua-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-detex" release="39.u4" version="20180414">
					<filename>texlive-detex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-detex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-kpathsea" release="39.u4" version="20180414">
					<filename>texlive-kpathsea-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-kpathsea-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-fontware" release="39.u4" version="20180414">
					<filename>texlive-fontware-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-fontware-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-autosp" release="39.u4" version="20180414">
					<filename>texlive-autosp-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-autosp-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtexu" release="39.u4" version="20180414">
					<filename>texlive-bibtexu-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-bibtexu-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cweb" release="39.u4" version="20180414">
					<filename>texlive-cweb-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-cweb-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-web" release="39.u4" version="20180414">
					<filename>texlive-web-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-web-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipdfmx" release="39.u4" version="20180414">
					<filename>texlive-dvipdfmx-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvipdfmx-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lacheck" release="39.u4" version="20180414">
					<filename>texlive-lacheck-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lacheck-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cjkutils" release="39.u4" version="20180414">
					<filename>texlive-cjkutils-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-cjkutils-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvisvgm" release="39.u4" version="20180414">
					<filename>texlive-dvisvgm-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvisvgm-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xetex" release="39.u4" version="20180414">
					<filename>texlive-xetex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-xetex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-uptex" release="39.u4" version="20180414">
					<filename>texlive-uptex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-uptex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ptex" release="39.u4" version="20180414">
					<filename>texlive-ptex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ptex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvi2tty" release="39.u4" version="20180414">
					<filename>texlive-dvi2tty-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvi2tty-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metafont" release="39.u4" version="20180414">
					<filename>texlive-metafont-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-metafont-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipos" release="39.u4" version="20180414">
					<filename>texlive-dvipos-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvipos-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib" release="39.u4" version="20180414">
					<filename>texlive-lib-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lib-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dviljk" release="39.u4" version="20180414">
					<filename>texlive-dviljk-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dviljk-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mfware" release="39.u4" version="20180414">
					<filename>texlive-mfware-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mfware-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-m-tx" release="39.u4" version="20180414">
					<filename>texlive-m-tx-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-m-tx-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gregoriotex" release="39.u4" version="20180414">
					<filename>texlive-gregoriotex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-gregoriotex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex4ht" release="39.u4" version="20180414">
					<filename>texlive-tex4ht-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-tex4ht-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-vlna" release="39.u4" version="20180414">
					<filename>texlive-vlna-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-vlna-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dtl" release="39.u4" version="20180414">
					<filename>texlive-dtl-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dtl-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-patgen" release="39.u4" version="20180414">
					<filename>texlive-patgen-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-patgen-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-base" release="39.u4" version="20180414">
					<filename>texlive-base-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-base-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-makeindex" release="39.u4" version="20180414">
					<filename>texlive-makeindex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-makeindex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pstools" release="39.u4" version="20180414">
					<filename>texlive-pstools-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pstools-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftools" release="39.u4" version="20180414">
					<filename>texlive-pdftools-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdftools-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-seetexk" release="39.u4" version="20180414">
					<filename>texlive-seetexk-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-seetexk-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib-devel" release="39.u4" version="20180414">
					<filename>texlive-lib-devel-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lib-devel-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex" release="39.u4" version="20180414">
					<filename>texlive-tex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-tex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ctie" release="39.u4" version="20180414">
					<filename>texlive-ctie-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ctie-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvidvi" release="39.u4" version="20180414">
					<filename>texlive-dvidvi-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvidvi-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex" release="39.u4" version="20180414">
					<filename>texlive-bibtex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-bibtex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipng" release="39.u4" version="20180414">
					<filename>texlive-dvipng-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvipng-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvips" release="39.u4" version="20180414">
					<filename>texlive-dvips-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvips-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-omegaware" release="39.u4" version="20180414">
					<filename>texlive-omegaware-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-omegaware-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-musixtnt" release="39.u4" version="20180414">
					<filename>texlive-musixtnt-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-musixtnt-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tie" release="39.u4" version="20180414">
					<filename>texlive-tie-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-tie-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metapost" release="39.u4" version="20180414">
					<filename>texlive-metapost-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-metapost-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-luatex" release="39.u4" version="20180414">
					<filename>texlive-luatex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-luatex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-afm2pl" release="39.u4" version="20180414">
					<filename>texlive-afm2pl-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-afm2pl-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xdvi" release="39.u4" version="20180414">
					<filename>texlive-xdvi-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-xdvi-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gsftopk" release="39.u4" version="20180414">
					<filename>texlive-gsftopk-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-gsftopk-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ttfutils" release="39.u4" version="20180414">
					<filename>texlive-ttfutils-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ttfutils-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ps2pk" release="39.u4" version="20180414">
					<filename>texlive-ps2pk-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ps2pk-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pmx" release="39.u4" version="20180414">
					<filename>texlive-pmx-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pmx-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-texware" release="39.u4" version="20180414">
					<filename>texlive-texware-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texware-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex8" release="39.u4" version="20180414">
					<filename>texlive-bibtex8-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-bibtex8-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-synctex" release="39.u4" version="20180414">
					<filename>texlive-synctex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-synctex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lcdftypetools" release="39.u4" version="20180414">
					<filename>texlive-lcdftypetools-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lcdftypetools-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-chktex" release="39.u4" version="20180414">
					<filename>texlive-chktex-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-chktex-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-velthuis" release="39.u4" version="20180414">
					<filename>texlive-velthuis-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-velthuis-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-axodraw2" release="39.u4" version="20180414">
					<filename>texlive-axodraw2-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-axodraw2-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvicopy" release="39.u4" version="20180414">
					<filename>texlive-dvicopy-20180414-39.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dvicopy-20180414-39.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipdfmx" release="39.u4" version="20180414">
					<filename>texlive-dvipdfmx-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvipdfmx-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metapost" release="39.u4" version="20180414">
					<filename>texlive-metapost-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-metapost-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ps2pk" release="39.u4" version="20180414">
					<filename>texlive-ps2pk-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-ps2pk-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvi2tty" release="39.u4" version="20180414">
					<filename>texlive-dvi2tty-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvi2tty-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-seetexk" release="39.u4" version="20180414">
					<filename>texlive-seetexk-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-seetexk-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metafont" release="39.u4" version="20180414">
					<filename>texlive-metafont-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-metafont-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-autosp" release="39.u4" version="20180414">
					<filename>texlive-autosp-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-autosp-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dviljk" release="39.u4" version="20180414">
					<filename>texlive-dviljk-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dviljk-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-chktex" release="39.u4" version="20180414">
					<filename>texlive-chktex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-chktex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gregoriotex" release="39.u4" version="20180414">
					<filename>texlive-gregoriotex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-gregoriotex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-uptex" release="39.u4" version="20180414">
					<filename>texlive-uptex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-uptex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvisvgm" release="39.u4" version="20180414">
					<filename>texlive-dvisvgm-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvisvgm-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-vlna" release="39.u4" version="20180414">
					<filename>texlive-vlna-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-vlna-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvicopy" release="39.u4" version="20180414">
					<filename>texlive-dvicopy-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvicopy-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-kpathsea" release="39.u4" version="20180414">
					<filename>texlive-kpathsea-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-kpathsea-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-musixtnt" release="39.u4" version="20180414">
					<filename>texlive-musixtnt-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-musixtnt-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pmx" release="39.u4" version="20180414">
					<filename>texlive-pmx-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-pmx-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pstools" release="39.u4" version="20180414">
					<filename>texlive-pstools-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-pstools-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-velthuis" release="39.u4" version="20180414">
					<filename>texlive-velthuis-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-velthuis-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cweb" release="39.u4" version="20180414">
					<filename>texlive-cweb-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-cweb-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xetex" release="39.u4" version="20180414">
					<filename>texlive-xetex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-xetex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex8" release="39.u4" version="20180414">
					<filename>texlive-bibtex8-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-bibtex8-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ptex" release="39.u4" version="20180414">
					<filename>texlive-ptex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-ptex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-aleph" release="39.u4" version="20180414">
					<filename>texlive-aleph-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-aleph-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftools" release="39.u4" version="20180414">
					<filename>texlive-pdftools-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-pdftools-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-texware" release="39.u4" version="20180414">
					<filename>texlive-texware-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-texware-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex4ht" release="39.u4" version="20180414">
					<filename>texlive-tex4ht-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-tex4ht-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex" release="39.u4" version="20180414">
					<filename>texlive-bibtex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-bibtex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mflua" release="39.u4" version="20180414">
					<filename>texlive-mflua-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-mflua-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftex" release="39.u4" version="20180414">
					<filename>texlive-pdftex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-pdftex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-base" release="39.u4" version="20180414">
					<filename>texlive-base-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-base-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-axodraw2" release="39.u4" version="20180414">
					<filename>texlive-axodraw2-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-axodraw2-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-m-tx" release="39.u4" version="20180414">
					<filename>texlive-m-tx-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-m-tx-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ttfutils" release="39.u4" version="20180414">
					<filename>texlive-ttfutils-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-ttfutils-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ctie" release="39.u4" version="20180414">
					<filename>texlive-ctie-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-ctie-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-luatex" release="39.u4" version="20180414">
					<filename>texlive-luatex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-luatex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mfware" release="39.u4" version="20180414">
					<filename>texlive-mfware-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-mfware-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-web" release="39.u4" version="20180414">
					<filename>texlive-web-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-web-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipng" release="39.u4" version="20180414">
					<filename>texlive-dvipng-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvipng-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gsftopk" release="39.u4" version="20180414">
					<filename>texlive-gsftopk-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-gsftopk-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-synctex" release="39.u4" version="20180414">
					<filename>texlive-synctex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-synctex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tie" release="39.u4" version="20180414">
					<filename>texlive-tie-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-tie-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-afm2pl" release="39.u4" version="20180414">
					<filename>texlive-afm2pl-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-afm2pl-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xdvi" release="39.u4" version="20180414">
					<filename>texlive-xdvi-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-xdvi-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lacheck" release="39.u4" version="20180414">
					<filename>texlive-lacheck-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-lacheck-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-detex" release="39.u4" version="20180414">
					<filename>texlive-detex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-detex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex" release="39.u4" version="20180414">
					<filename>texlive-tex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-tex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-omegaware" release="39.u4" version="20180414">
					<filename>texlive-omegaware-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-omegaware-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dtl" release="39.u4" version="20180414">
					<filename>texlive-dtl-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dtl-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipos" release="39.u4" version="20180414">
					<filename>texlive-dvipos-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvipos-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lcdftypetools" release="39.u4" version="20180414">
					<filename>texlive-lcdftypetools-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-lcdftypetools-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib-devel" release="39.u4" version="20180414">
					<filename>texlive-lib-devel-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-lib-devel-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib" release="39.u4" version="20180414">
					<filename>texlive-lib-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-lib-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-patgen" release="39.u4" version="20180414">
					<filename>texlive-patgen-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-patgen-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-fontware" release="39.u4" version="20180414">
					<filename>texlive-fontware-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-fontware-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvidvi" release="39.u4" version="20180414">
					<filename>texlive-dvidvi-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvidvi-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvips" release="39.u4" version="20180414">
					<filename>texlive-dvips-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-dvips-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtexu" release="39.u4" version="20180414">
					<filename>texlive-bibtexu-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-bibtexu-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-makeindex" release="39.u4" version="20180414">
					<filename>texlive-makeindex-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-makeindex-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cjkutils" release="39.u4" version="20180414">
					<filename>texlive-cjkutils-20180414-39.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/texlive-cjkutils-20180414-39.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst-pdf" release="39.u4" version="20180414">
					<filename>texlive-pst-pdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pst-pdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-yplan" release="39.u4" version="20180414">
					<filename>texlive-yplan-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-yplan-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst2pdf" release="39.u4" version="20180414">
					<filename>texlive-pst2pdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pst2pdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fragmaster" release="39.u4" version="20180414">
					<filename>texlive-fragmaster-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-fragmaster-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-git-log" release="39.u4" version="20180414">
					<filename>texlive-latex-git-log-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latex-git-log-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lyluatex" release="39.u4" version="svn47584">
					<filename>texlive-lyluatex-svn47584-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lyluatex-svn47584-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix" release="39.u4" version="20180414">
					<filename>texlive-pkfix-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pkfix-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex" release="39.u4" version="20180414">
					<filename>texlive-latex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bundledoc" release="39.u4" version="20180414">
					<filename>texlive-bundledoc-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-bundledoc-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glyphlist" release="39.u4" version="20180414">
					<filename>texlive-glyphlist-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-glyphlist-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-papersize" release="39.u4" version="20180414">
					<filename>texlive-latex-papersize-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latex-papersize-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-diadia" release="39.u4" version="20180414">
					<filename>texlive-diadia-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-diadia-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bib2gls" release="39.u4" version="20180414">
					<filename>texlive-bib2gls-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-bib2gls-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dosepsbin" release="39.u4" version="20180414">
					<filename>texlive-dosepsbin-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dosepsbin-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glossaries" release="39.u4" version="20180414">
					<filename>texlive-glossaries-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-glossaries-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkjobtexmf" release="39.u4" version="20180414">
					<filename>texlive-mkjobtexmf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mkjobtexmf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-l3build" release="39.u4" version="20180414">
					<filename>texlive-l3build-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-l3build-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-match_parens" release="39.u4" version="20180414">
					<filename>texlive-match_parens-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-match_parens-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pedigree-perl" release="39.u4" version="20180414">
					<filename>texlive-pedigree-perl-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pedigree-perl-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-vpe" release="39.u4" version="20180414">
					<filename>texlive-vpe-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-vpe-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive.infra" release="39.u4" version="20180414">
					<filename>texlive-texlive.infra-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texlive.infra-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ulqda" release="39.u4" version="20180414">
					<filename>texlive-ulqda-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ulqda-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texcount" release="39.u4" version="20180414">
					<filename>texlive-texcount-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texcount-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-petri-nets" release="39.u4" version="20180414">
					<filename>texlive-petri-nets-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-petri-nets-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bibexport" release="39.u4" version="20180414">
					<filename>texlive-bibexport-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-bibexport-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-luaotfload" release="39.u4" version="20180414">
					<filename>texlive-luaotfload-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-luaotfload-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfjam" release="39.u4" version="20180414">
					<filename>texlive-pdfjam-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdfjam-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pmxchords" release="39.u4" version="20180414">
					<filename>texlive-pmxchords-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pmxchords-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-a2ping" release="39.u4" version="20180414">
					<filename>texlive-a2ping-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-a2ping-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdef" release="39.u4" version="20180414">
					<filename>texlive-texdef-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texdef-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jadetex" release="39.u4" version="20180414">
					<filename>texlive-jadetex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-jadetex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexfileversion" release="39.u4" version="20180414">
					<filename>texlive-latexfileversion-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latexfileversion-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pax" release="39.u4" version="20180414">
					<filename>texlive-pax-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pax-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texosquery" release="39.u4" version="20180414">
					<filename>texlive-texosquery-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texosquery-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lwarp" release="39.u4" version="20180414">
					<filename>texlive-lwarp-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lwarp-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pygmentex" release="39.u4" version="20180414">
					<filename>texlive-pygmentex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pygmentex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviasm" release="39.u4" version="20180414">
					<filename>texlive-dviasm-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dviasm-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltximg" release="39.u4" version="20180414">
					<filename>texlive-ltximg-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ltximg-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-thumbpdf" release="39.u4" version="20180414">
					<filename>texlive-thumbpdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-thumbpdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texsis" release="39.u4" version="20180414">
					<filename>texlive-texsis-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texsis-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fig4latex" release="39.u4" version="20180414">
					<filename>texlive-fig4latex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-fig4latex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-getmap" release="39.u4" version="20180414">
					<filename>texlive-getmap-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-getmap-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-srcredact" release="39.u4" version="20180414">
					<filename>texlive-srcredact-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-srcredact-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-context" release="39.u4" version="20180414">
					<filename>texlive-context-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-context-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-csplain" release="39.u4" version="20180414">
					<filename>texlive-csplain-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-csplain-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epspdf" release="39.u4" version="20180414">
					<filename>texlive-epspdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-epspdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexpand" release="39.u4" version="20180414">
					<filename>texlive-latexpand-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latexpand-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mathspic" release="39.u4" version="20180414">
					<filename>texlive-mathspic-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mathspic-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfbook2" release="39.u4" version="20180414">
					<filename>texlive-pdfbook2-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdfbook2-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checklistings" release="39.u4" version="20180414">
					<filename>texlive-checklistings-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-checklistings-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jfmutil" release="39.u4" version="20180414">
					<filename>texlive-jfmutil-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-jfmutil-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-en" release="39.u4" version="20180414">
					<filename>texlive-texlive-en-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texlive-en-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2man" release="39.u4" version="20180414">
					<filename>texlive-latex2man-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latex2man-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoc" release="39.u4" version="20180414">
					<filename>texlive-texdoc-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texdoc-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-convbkmk" release="39.u4" version="20180414">
					<filename>texlive-convbkmk-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-convbkmk-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix-helper" release="39.u4" version="20180414">
					<filename>texlive-pkfix-helper-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pkfix-helper-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontinst" release="39.u4" version="20180414">
					<filename>texlive-fontinst-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-fontinst-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cslatex" release="39.u4" version="20180414">
					<filename>texlive-cslatex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-cslatex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cyrillic" release="39.u4" version="20180414">
					<filename>texlive-cyrillic-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-cyrillic-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-makedtx" release="39.u4" version="20180414">
					<filename>texlive-makedtx-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-makedtx-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-wordcount" release="39.u4" version="20180414">
					<filename>texlive-wordcount-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-wordcount-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mex" release="39.u4" version="20180414">
					<filename>texlive-mex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texconfig" release="39.u4" version="20180414">
					<filename>texlive-texconfig-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texconfig-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex2pdf" release="39.u4" version="20180414">
					<filename>texlive-ptex2pdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ptex2pdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tetex" release="39.u4" version="20180414">
					<filename>texlive-tetex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-tetex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texliveonfly" release="39.u4" version="20180414">
					<filename>texlive-texliveonfly-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texliveonfly-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mptopdf" release="39.u4" version="20180414">
					<filename>texlive-mptopdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mptopdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdflatexpicscale" release="39.u4" version="20180414">
					<filename>texlive-pdflatexpicscale-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdflatexpicscale-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-sty2dtx" release="39.u4" version="20180414">
					<filename>texlive-sty2dtx-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-sty2dtx-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdirflatten" release="39.u4" version="20180414">
					<filename>texlive-texdirflatten-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texdirflatten-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-kotex-utils" release="39.u4" version="20180414">
					<filename>texlive-kotex-utils-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-kotex-utils-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltxfileinfo" release="39.u4" version="20180414">
					<filename>texlive-ltxfileinfo-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ltxfileinfo-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-multibibliography" release="39.u4" version="20180414">
					<filename>texlive-multibibliography-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-multibibliography-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-de-macro" release="39.u4" version="20180414">
					<filename>texlive-de-macro-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-de-macro-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-perltex" release="39.u4" version="20180414">
					<filename>texlive-perltex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-perltex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texloganalyser" release="39.u4" version="20180414">
					<filename>texlive-texloganalyser-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texloganalyser-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctan-o-mat" release="39.u4" version="20180414">
					<filename>texlive-ctan-o-mat-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ctan-o-mat-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-oberdiek" release="39.u4" version="20180414">
					<filename>texlive-oberdiek-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-oberdiek-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfxup" release="39.u4" version="20180414">
					<filename>texlive-pdfxup-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdfxup-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-splitindex" release="39.u4" version="20180414">
					<filename>texlive-splitindex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-splitindex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdiff" release="39.u4" version="20180414">
					<filename>texlive-texdiff-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texdiff-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-accfonts" release="39.u4" version="20180414">
					<filename>texlive-accfonts-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-accfonts-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epstopdf" release="39.u4" version="20180414">
					<filename>texlive-epstopdf-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-epstopdf-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkgrkindex" release="39.u4" version="20180414">
					<filename>texlive-mkgrkindex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mkgrkindex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfcrop" release="39.u4" version="20180414">
					<filename>texlive-pdfcrop-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pdfcrop-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-typeoutfileinfo" release="39.u4" version="20180414">
					<filename>texlive-typeoutfileinfo-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-typeoutfileinfo-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-amstex" release="39.u4" version="20180414">
					<filename>texlive-amstex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-amstex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pfarrei" release="39.u4" version="20180414">
					<filename>texlive-pfarrei-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pfarrei-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-adhocfilelist" release="39.u4" version="20180414">
					<filename>texlive-adhocfilelist-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-adhocfilelist-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checkcites" release="39.u4" version="20180414">
					<filename>texlive-checkcites-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-checkcites-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-eplain" release="39.u4" version="20180414">
					<filename>texlive-eplain-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-eplain-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lollipop" release="39.u4" version="20180414">
					<filename>texlive-lollipop-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lollipop-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tex4ebook" release="39.u4" version="20180414">
					<filename>texlive-tex4ebook-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-tex4ebook-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-purifyeps" release="39.u4" version="20180414">
					<filename>texlive-purifyeps-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-purifyeps-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lua2dox" release="39.u4" version="20180414">
					<filename>texlive-lua2dox-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lua2dox-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-crossrefware" release="39.u4" version="20180414">
					<filename>texlive-crossrefware-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-crossrefware-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex-fontmaps" release="39.u4" version="20180414">
					<filename>texlive-ptex-fontmaps-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ptex-fontmaps-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pythontex" release="39.u4" version="20180414">
					<filename>texlive-pythontex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-pythontex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctanify" release="39.u4" version="20180414">
					<filename>texlive-ctanify-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ctanify-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texfot" release="39.u4" version="20180414">
					<filename>texlive-texfot-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texfot-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-authorindex" release="39.u4" version="20180414">
					<filename>texlive-authorindex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-authorindex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2nemeth" release="39.u4" version="20180414">
					<filename>texlive-latex2nemeth-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latex2nemeth-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-svn-multi" release="39.u4" version="20180414">
					<filename>texlive-svn-multi-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-svn-multi-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dtxgen" release="39.u4" version="20180414">
					<filename>texlive-dtxgen-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dtxgen-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-urlbst" release="39.u4" version="20180414">
					<filename>texlive-urlbst-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-urlbst-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cachepic" release="39.u4" version="20180414">
					<filename>texlive-cachepic-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-cachepic-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ebong" release="39.u4" version="20180414">
					<filename>texlive-ebong-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-ebong-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-musixtex" release="39.u4" version="20180414">
					<filename>texlive-musixtex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-musixtex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-rubik" release="39.u4" version="20180414">
					<filename>texlive-rubik-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-rubik-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontools" release="39.u4" version="20180414">
					<filename>texlive-fontools-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-fontools-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-arara" release="39.u4" version="20180414">
					<filename>texlive-arara-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-arara-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tpic2pdftex" release="39.u4" version="20180414">
					<filename>texlive-tpic2pdftex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-tpic2pdftex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviinfox" release="39.u4" version="20180414">
					<filename>texlive-dviinfox-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-dviinfox-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexdiff" release="39.u4" version="20180414">
					<filename>texlive-latexdiff-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-latexdiff-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-make4ht" release="39.u4" version="20180414">
					<filename>texlive-make4ht-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-make4ht-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-installfont" release="39.u4" version="20180414">
					<filename>texlive-installfont-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-installfont-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-scripts" release="39.u4" version="20180414">
					<filename>texlive-texlive-scripts-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texlive-scripts-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkpic" release="39.u4" version="20180414">
					<filename>texlive-mkpic-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mkpic-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mltex" release="39.u4" version="20180414">
					<filename>texlive-mltex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mltex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listings-ext" release="39.u4" version="20180414">
					<filename>texlive-listings-ext-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-listings-ext-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lilyglyphs" release="39.u4" version="20180414">
					<filename>texlive-lilyglyphs-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-lilyglyphs-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-xmltex" release="39.u4" version="20180414">
					<filename>texlive-xmltex-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-xmltex-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoctk" release="39.u4" version="20180414">
					<filename>texlive-texdoctk-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-texdoctk-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-findhyph" release="39.u4" version="20180414">
					<filename>texlive-findhyph-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-findhyph-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mf2pt1" release="39.u4" version="20180414">
					<filename>texlive-mf2pt1-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-mf2pt1-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listbib" release="39.u4" version="20180414">
					<filename>texlive-listbib-20180414-39.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/texlive-listbib-20180414-39.u4.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3002</id>
		<title>An update for libtasn1 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13151&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13151" id="CVE-2025-13151" title="CVE-2025-13151" type="cve"></reference>
		</references>
		<description>CVE-2025-13151:Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="libtasn1-help" release="3.u1" version="4.19.0">
					<filename>libtasn1-help-4.19.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libtasn1-help-4.19.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtasn1-devel" release="3.u1" version="4.19.0">
					<filename>libtasn1-devel-4.19.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libtasn1-devel-4.19.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtasn1" release="3.u1" version="4.19.0">
					<filename>libtasn1-4.19.0-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libtasn1-4.19.0-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtasn1-devel" release="3.u1" version="4.19.0">
					<filename>libtasn1-devel-4.19.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libtasn1-devel-4.19.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtasn1" release="3.u1" version="4.19.0">
					<filename>libtasn1-4.19.0-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libtasn1-4.19.0-3.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3003</id>
		<title>An update for raptor2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57822&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57822" id="CVE-2024-57822" title="CVE-2024-57822" type="cve"></reference>
		</references>
		<description>CVE-2024-57822:In Raptor RDF Syntax Library through 2.0.16, there is a heap-based buffer over-read when parsing triples with the nquads parser in raptor_ntriples_parse_term_internal().&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="raptor2" release="21.u2" version="2.0.15">
					<filename>raptor2-2.0.15-21.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/raptor2-2.0.15-21.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="raptor2-devel" release="21.u2" version="2.0.15">
					<filename>raptor2-devel-2.0.15-21.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/raptor2-devel-2.0.15-21.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="raptor2-help" release="21.u2" version="2.0.15">
					<filename>raptor2-help-2.0.15-21.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/raptor2-help-2.0.15-21.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="raptor2" release="21.u2" version="2.0.15">
					<filename>raptor2-2.0.15-21.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/raptor2-2.0.15-21.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="raptor2-devel" release="21.u2" version="2.0.15">
					<filename>raptor2-devel-2.0.15-21.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/raptor2-devel-2.0.15-21.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="raptor2-help" release="21.u2" version="2.0.15">
					<filename>raptor2-help-2.0.15-21.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/raptor2-help-2.0.15-21.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3004</id>
		<title>An update for libpcap is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11961&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11961" id="CVE-2025-11961" title="CVE-2025-11961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11964" id="CVE-2025-11964" title="CVE-2025-11964" type="cve"></reference>
		</references>
		<description>CVE-2025-11961:pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer.  The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented.  If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.&#xA;CVE-2025-11964:On Windows only, if libpcap needs to convert a Windows error message to UTF-8 and the message includes characters that UTF-8 represents using 4 bytes, utf_16le_to_utf_8_truncated() can write data beyond the end of the provided buffer.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="14" name="libpcap-help" release="4.u2" version="1.10.3">
					<filename>libpcap-help-1.10.3-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpcap-help-1.10.3-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="14" name="libpcap-devel" release="4.u2" version="1.10.3">
					<filename>libpcap-devel-1.10.3-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpcap-devel-1.10.3-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="14" name="libpcap" release="4.u2" version="1.10.3">
					<filename>libpcap-1.10.3-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpcap-1.10.3-4.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="libpcap" release="4.u2" version="1.10.3">
					<filename>libpcap-1.10.3-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpcap-1.10.3-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="14" name="libpcap-devel" release="4.u2" version="1.10.3">
					<filename>libpcap-devel-1.10.3-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpcap-devel-1.10.3-4.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3005</id>
		<title>An update for libpng is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66293&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66293" id="CVE-2025-66293" title="CVE-2025-66293" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64505&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64505" id="CVE-2025-64505" title="CVE-2025-64505" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64506&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64506" id="CVE-2025-64506" title="CVE-2025-64506" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64720&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64720" id="CVE-2025-64720" title="CVE-2025-64720" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-65018&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-65018" id="CVE-2025-65018" title="CVE-2025-65018" type="cve"></reference>
		</references>
		<description>CVE-2025-66293:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng&#39;s simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng&#39;s internal state management. Upgrade to libpng 1.6.52 or later.&#xA;CVE-2025-64505:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng&#39;s png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.&#xA;CVE-2025-64506:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng&#39;s png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.&#xA;CVE-2025-64720:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha × 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.&#xA;CVE-2025-65018:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="2" name="libpng-help" release="4.u3" version="1.6.38">
					<filename>libpng-help-1.6.38-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpng-help-1.6.38-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng" release="4.u3" version="1.6.38">
					<filename>libpng-1.6.38-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpng-1.6.38-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng-tools" release="4.u3" version="1.6.38">
					<filename>libpng-tools-1.6.38-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpng-tools-1.6.38-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng-static" release="4.u3" version="1.6.38">
					<filename>libpng-static-1.6.38-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpng-static-1.6.38-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng-devel" release="4.u3" version="1.6.38">
					<filename>libpng-devel-1.6.38-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libpng-devel-1.6.38-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-static" release="4.u3" version="1.6.38">
					<filename>libpng-static-1.6.38-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpng-static-1.6.38-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng" release="4.u3" version="1.6.38">
					<filename>libpng-1.6.38-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpng-1.6.38-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-help" release="4.u3" version="1.6.38">
					<filename>libpng-help-1.6.38-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpng-help-1.6.38-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-devel" release="4.u3" version="1.6.38">
					<filename>libpng-devel-1.6.38-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpng-devel-1.6.38-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-tools" release="4.u3" version="1.6.38">
					<filename>libpng-tools-1.6.38-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libpng-tools-1.6.38-4.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3006</id>
		<title>An update for libsoup is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14523&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14523" id="CVE-2025-14523" title="CVE-2025-14523" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0719&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0719" id="CVE-2026-0719" title="CVE-2026-0719" type="cve"></reference>
		</references>
		<description>CVE-2025-14523:A flaw in libsoup’s HTTP header handling allows multiple Host: headers in a request and returns the last occurrence for server-side processing. Common front proxies often honor the first Host: header, so this mismatch can cause vhost confusion where a proxy routes a request to one backend but the backend interprets it as destined for another host. This discrepancy enables request-smuggling style attacks, cache poisoning, or bypassing host-based access controls when an attacker supplies duplicate Host headers.&#xA;CVE-2026-0719:A flaw was identified in the NTLM authentication handling of the libsoup HTTP library, used by GNOME and other applications for network communication. When processing extremely long passwords, an internal size calculation can overflow due to improper use of signed integers. This results in incorrect memory allocation on the stack, followed by unsafe memory copying. As a result, applications using libsoup may crash unexpectedly, creating a denial-of-service risk.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="libsoup" release="11.u7" version="2.74.2">
					<filename>libsoup-2.74.2-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libsoup-2.74.2-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsoup-devel" release="11.u7" version="2.74.2">
					<filename>libsoup-devel-2.74.2-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libsoup-devel-2.74.2-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsoup" release="11.u7" version="2.74.2">
					<filename>libsoup-2.74.2-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libsoup-2.74.2-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsoup-devel" release="11.u7" version="2.74.2">
					<filename>libsoup-devel-2.74.2-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libsoup-devel-2.74.2-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libsoup-help" release="11.u7" version="2.74.2">
					<filename>libsoup-help-2.74.2-11.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libsoup-help-2.74.2-11.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3007</id>
		<title>An update for luksmeta is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11568&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11568" id="CVE-2025-11568" title="CVE-2025-11568" type="cve"></reference>
		</references>
		<description>CVE-2025-11568:A data corruption vulnerability has been identified in the luksmeta utility when used with the LUKS1 disk encryption format. An attacker with the necessary permissions can exploit this flaw by writing a large amount of metadata to an encrypted device. The utility fails to correctly validate the available space, causing the metadata to overwrite and corrupt the user&#39;s encrypted data. This action leads to a permanent loss of the stored information. Devices using the LUKS formats other than LUKS1 are not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="luksmeta-help" release="7.u1" version="9">
					<filename>luksmeta-help-9-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/luksmeta-help-9-7.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="luksmeta-devel" release="7.u1" version="9">
					<filename>luksmeta-devel-9-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/luksmeta-devel-9-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="luksmeta" release="7.u1" version="9">
					<filename>luksmeta-9-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/luksmeta-9-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="luksmeta" release="7.u1" version="9">
					<filename>luksmeta-9-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/luksmeta-9-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="luksmeta-devel" release="7.u1" version="9">
					<filename>luksmeta-devel-9-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/luksmeta-devel-9-7.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3008</id>
		<title>An update for nodejs-js-yaml is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64718&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64718" id="CVE-2025-64718" title="CVE-2025-64718" type="cve"></reference>
		</references>
		<description>CVE-2025-64718:js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1.1 and 3.14.2, it&#39;s possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. The problem is patched in js-yaml 4.1.1 and 3.14.2. Users can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="nodejs-js-yaml" release="2.u1" version="3.10.0">
					<filename>nodejs-js-yaml-3.10.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/nodejs-js-yaml-3.10.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3009</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8732&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8732" id="CVE-2025-8732" title="CVE-2025-8732" type="cve"></reference>
		</references>
		<description>CVE-2025-8732:A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that &#34;[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all.&#34;&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="22.u17" version="2.9.14">
					<filename>python3-libxml2-2.9.14-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-libxml2-2.9.14-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="22.u17" version="2.9.14">
					<filename>libxml2-2.9.14-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libxml2-2.9.14-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="22.u17" version="2.9.14">
					<filename>libxml2-devel-2.9.14-22.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libxml2-devel-2.9.14-22.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="22.u17" version="2.9.14">
					<filename>libxml2-help-2.9.14-22.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libxml2-help-2.9.14-22.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="22.u17" version="2.9.14">
					<filename>libxml2-devel-2.9.14-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libxml2-devel-2.9.14-22.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="22.u17" version="2.9.14">
					<filename>libxml2-2.9.14-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libxml2-2.9.14-22.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="22.u17" version="2.9.14">
					<filename>python3-libxml2-2.9.14-22.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-libxml2-2.9.14-22.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3010</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14177" id="CVE-2025-14177" title="CVE-2025-14177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14178&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14178" id="CVE-2025-14178" title="CVE-2025-14178" type="cve"></reference>
		</references>
		<description>CVE-2025-14177:In PHP versions:8.1.* before 8.1.34, 8.2.* before 8.2.30, 8.3.* before 8.3.29, 8.4.* before 8.4.16, 8.5.* before 8.5.1, the getimagesize() function may leak uninitialized heap memory into the APPn segments (e.g., APP1) when reading images in multi-chunk mode (such as via php://filter). This occurs due to a bug in php_read_stream_all_chunks() that overwrites the buffer without advancing the pointer, leaving tail bytes uninitialized. This may lead to information disclosure of sensitive heap data and affect the confidentiality of the target server.&#xA;CVE-2025-14178:In PHP versions:8.1.* before 8.1.34, 8.2.* before 8.2.30, 8.3.* before 8.3.29, 8.4.* before 8.4.16, 8.5.* before 8.5.1, a heap buffer overflow occurs in array_merge() when the total element count of packed arrays exceeds 32-bit limits or HT_MAX_SIZE, due to an integer overflow in the precomputation of element counts using zend_hash_num_elements(). This may lead to memory corruption or crashes and affect the integrity and availability of the target server.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="php-ldap" release="11.u9" version="8.0.30">
					<filename>php-ldap-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-ldap-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="11.u9" version="8.0.30">
					<filename>php-intl-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-intl-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="11.u9" version="8.0.30">
					<filename>php-soap-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-soap-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="11.u9" version="8.0.30">
					<filename>php-opcache-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-opcache-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php" release="11.u9" version="8.0.30">
					<filename>php-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="11.u9" version="8.0.30">
					<filename>php-cli-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-cli-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="11.u9" version="8.0.30">
					<filename>php-dbg-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-dbg-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="11.u9" version="8.0.30">
					<filename>php-pdo-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-pdo-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="11.u9" version="8.0.30">
					<filename>php-pgsql-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-pgsql-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="11.u9" version="8.0.30">
					<filename>php-embedded-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-embedded-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="11.u9" version="8.0.30">
					<filename>php-gmp-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-gmp-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="11.u9" version="8.0.30">
					<filename>php-sodium-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-sodium-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="11.u9" version="8.0.30">
					<filename>php-process-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-process-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="11.u9" version="8.0.30">
					<filename>php-common-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-common-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="11.u9" version="8.0.30">
					<filename>php-ffi-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-ffi-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="11.u9" version="8.0.30">
					<filename>php-mbstring-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-mbstring-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="11.u9" version="8.0.30">
					<filename>php-enchant-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-enchant-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="11.u9" version="8.0.30">
					<filename>php-fpm-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-fpm-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="11.u9" version="8.0.30">
					<filename>php-bcmath-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-bcmath-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="11.u9" version="8.0.30">
					<filename>php-dba-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-dba-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="11.u9" version="8.0.30">
					<filename>php-devel-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-devel-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="11.u9" version="8.0.30">
					<filename>php-tidy-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-tidy-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="11.u9" version="8.0.30">
					<filename>php-xml-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-xml-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="11.u9" version="8.0.30">
					<filename>php-gd-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-gd-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="11.u9" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-mysqlnd-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="11.u9" version="8.0.30">
					<filename>php-odbc-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-odbc-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="11.u9" version="8.0.30">
					<filename>php-snmp-8.0.30-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-snmp-8.0.30-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="11.u9" version="8.0.30">
					<filename>php-opcache-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-opcache-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="11.u9" version="8.0.30">
					<filename>php-cli-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-cli-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="11.u9" version="8.0.30">
					<filename>php-gmp-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-gmp-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="11.u9" version="8.0.30">
					<filename>php-odbc-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-odbc-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="11.u9" version="8.0.30">
					<filename>php-embedded-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-embedded-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="11.u9" version="8.0.30">
					<filename>php-ffi-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-ffi-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="11.u9" version="8.0.30">
					<filename>php-gd-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-gd-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="11.u9" version="8.0.30">
					<filename>php-dbg-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-dbg-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="11.u9" version="8.0.30">
					<filename>php-intl-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-intl-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="11.u9" version="8.0.30">
					<filename>php-soap-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-soap-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="11.u9" version="8.0.30">
					<filename>php-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="11.u9" version="8.0.30">
					<filename>php-common-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-common-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="11.u9" version="8.0.30">
					<filename>php-mbstring-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-mbstring-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="11.u9" version="8.0.30">
					<filename>php-ldap-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-ldap-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="11.u9" version="8.0.30">
					<filename>php-devel-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-devel-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="11.u9" version="8.0.30">
					<filename>php-fpm-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-fpm-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="11.u9" version="8.0.30">
					<filename>php-tidy-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-tidy-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="11.u9" version="8.0.30">
					<filename>php-xml-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-xml-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="11.u9" version="8.0.30">
					<filename>php-bcmath-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-bcmath-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="11.u9" version="8.0.30">
					<filename>php-snmp-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-snmp-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="11.u9" version="8.0.30">
					<filename>php-pdo-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-pdo-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="11.u9" version="8.0.30">
					<filename>php-pgsql-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-pgsql-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="11.u9" version="8.0.30">
					<filename>php-enchant-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-enchant-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="11.u9" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-mysqlnd-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="11.u9" version="8.0.30">
					<filename>php-dba-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-dba-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="11.u9" version="8.0.30">
					<filename>php-process-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-process-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="11.u9" version="8.0.30">
					<filename>php-sodium-8.0.30-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/php-sodium-8.0.30-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="php-help" release="11.u9" version="8.0.30">
					<filename>php-help-8.0.30-11.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/php-help-8.0.30-11.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3011</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55752&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55752" id="CVE-2025-55752" title="CVE-2025-55752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55754&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55754" id="CVE-2025-55754" title="CVE-2025-55754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61795" id="CVE-2025-61795" title="CVE-2025-61795" type="cve"></reference>
		</references>
		<description>CVE-2025-55752:Relative Path Traversal vulnerability in Apache Tomcat.&#xA;&#xA;The fix for bug 60013 introduced a regression where the       rewritten URL was normalized before it was decoded. This introduced the       possibility that, for rewrite rules that rewrite query parameters to the       URL, an attacker could manipulate the request URI to bypass security       constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.&#xA;&#xA;&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.&#xA;&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected.&#xA;Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.&#xA;CVE-2025-55754:Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.&#xA;&#xA;Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system, and the console supported ANSI escape sequences, it was possible for an attacker to use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker controlled command. While no attack vector was found, it may have been possible to mount this attack on other operating systems.&#xA;&#xA;&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.40 through 9.0.108.&#xA;&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.60 though 8.5.100. Other, older, EOL versions may also be affected.&#xA;Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.&#xA;CVE-2025-61795:Improper Resource Shutdown or Release vulnerability in Apache Tomcat.&#xA;&#xA;If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS.&#xA;&#xA;&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109.&#xA;&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.&#xA;Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="1" name="tomcat-help" release="9.u21" version="9.0.100">
					<filename>tomcat-help-9.0.100-9.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/tomcat-help-9.0.100-9.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="9.u21" version="9.0.100">
					<filename>tomcat-jsvc-9.0.100-9.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/tomcat-jsvc-9.0.100-9.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat" release="9.u21" version="9.0.100">
					<filename>tomcat-9.0.100-9.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/tomcat-9.0.100-9.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3012</id>
		<title>An update for apr is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49582&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-49582" id="CVE-2023-49582" title="CVE-2023-49582" type="cve"></reference>
		</references>
		<description>CVE-2023-49582:Lax permissions set by the Apache Portable Runtime library on Unix platforms would allow local users read access to named shared memory segments, potentially revealing sensitive application data. &#xA;&#xA;This issue does not affect non-Unix platforms, or builds with APR_USE_SHMEM_SHMGET=1 (apr.h)&#xA;&#xA;Users are recommended to upgrade to APR version 1.7.5, which fixes this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="apr-devel" release="6.u2" version="1.7.0">
					<filename>apr-devel-1.7.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/apr-devel-1.7.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="apr" release="6.u2" version="1.7.0">
					<filename>apr-1.7.0-6.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/apr-1.7.0-6.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="apr" release="6.u2" version="1.7.0">
					<filename>apr-1.7.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/apr-1.7.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="apr-devel" release="6.u2" version="1.7.0">
					<filename>apr-devel-1.7.0-6.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/apr-devel-1.7.0-6.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apr-help" release="6.u2" version="1.7.0">
					<filename>apr-help-1.7.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/apr-help-1.7.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3013</id>
		<title>An update for wpa_supplicant is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-24912" id="CVE-2025-24912" title="CVE-2025-24912" type="cve"></reference>
		</references>
		<description>CVE-2025-24912:hostapd fails to process crafted RADIUS packets properly. When hostapd authenticates wi-fi devices with RADIUS authentication, an attacker in the position between the hostapd and the RADIUS server may inject crafted RADIUS packets and force RADIUS authentications to fail.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-gui" release="33.u3" version="2.6">
					<filename>wpa_supplicant-gui-2.6-33.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/wpa_supplicant-gui-2.6-33.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-help" release="33.u3" version="2.6">
					<filename>wpa_supplicant-help-2.6-33.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/wpa_supplicant-help-2.6-33.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant" release="33.u3" version="2.6">
					<filename>wpa_supplicant-2.6-33.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/wpa_supplicant-2.6-33.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-gui" release="33.u3" version="2.6">
					<filename>wpa_supplicant-gui-2.6-33.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/wpa_supplicant-gui-2.6-33.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant" release="33.u3" version="2.6">
					<filename>wpa_supplicant-2.6-33.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/wpa_supplicant-2.6-33.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-help" release="33.u3" version="2.6">
					<filename>wpa_supplicant-help-2.6-33.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/wpa_supplicant-help-2.6-33.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3014</id>
		<title>An update for nasm is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31722&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-31722" id="CVE-2023-31722" title="CVE-2023-31722" type="cve"></reference>
		</references>
		<description>CVE-2023-31722:There exists a heap buffer overflow in nasm 2.16.02rc1 (GitHub commit: b952891).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="nasm" release="8.u5" version="2.15.05">
					<filename>nasm-2.15.05-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/nasm-2.15.05-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nasm" release="8.u5" version="2.15.05">
					<filename>nasm-2.15.05-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/nasm-2.15.05-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="nasm-help" release="8.u5" version="2.15.05">
					<filename>nasm-help-2.15.05-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/nasm-help-2.15.05-8.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3015</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7545&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7545" id="CVE-2025-7545" title="CVE-2025-7545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5244&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5244" id="CVE-2025-5244" title="CVE-2025-5244" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5245&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5245" id="CVE-2025-5245" title="CVE-2025-5245" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7546&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7546" id="CVE-2025-7546" title="CVE-2025-7546" type="cve"></reference>
		</references>
		<description>CVE-2025-7545:A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-5244:A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.&#xA;CVE-2025-5245:A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-7546:A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="binutils-devel" release="38.u17" version="2.37">
					<filename>binutils-devel-2.37-38.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/binutils-devel-2.37-38.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils" release="38.u17" version="2.37">
					<filename>binutils-2.37-38.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/binutils-2.37-38.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="binutils-help" release="38.u17" version="2.37">
					<filename>binutils-help-2.37-38.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/binutils-help-2.37-38.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-help" release="38.u17" version="2.37">
					<filename>binutils-help-2.37-38.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/binutils-help-2.37-38.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils" release="38.u17" version="2.37">
					<filename>binutils-2.37-38.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/binutils-2.37-38.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="binutils-devel" release="38.u17" version="2.37">
					<filename>binutils-devel-2.37-38.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/binutils-devel-2.37-38.u17.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3016</id>
		<title>An update for autogen is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8746&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8746" id="CVE-2025-8746" title="CVE-2025-8746" type="cve"></reference>
		</references>
		<description>CVE-2025-8746:A vulnerability, which was classified as problematic, was found in GNU libopts up to 27.6. Affected is the function __strstr_sse2. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. This issue was initially reported to the tcpreplay project, but the code maintainer explains, that this &#34;bug appears to be in libopts which is an external library.&#34; This vulnerability only affects products that are no longer supported by the maintainer.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="autogen-help" release="5.u2" version="5.18.16">
					<filename>autogen-help-5.18.16-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/autogen-help-5.18.16-5.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="autogen-devel" release="5.u2" version="5.18.16">
					<filename>autogen-devel-5.18.16-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/autogen-devel-5.18.16-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="autogen" release="5.u2" version="5.18.16">
					<filename>autogen-5.18.16-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/autogen-5.18.16-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="autogen" release="5.u2" version="5.18.16">
					<filename>autogen-5.18.16-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/autogen-5.18.16-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="autogen-devel" release="5.u2" version="5.18.16">
					<filename>autogen-devel-5.18.16-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/autogen-devel-5.18.16-5.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3017</id>
		<title>An update for libwebsockets is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11677&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11677" id="CVE-2025-11677" title="CVE-2025-11677" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11678" id="CVE-2025-11678" title="CVE-2025-11678" type="cve"></reference>
		</references>
		<description>CVE-2025-11677:Use After Free in WebSocket server implementation in lws_handshake_server in warmcat libwebsockets may allow an attacker, in specific configurations where the user provides a callback function that handles LWS_CALLBACK_HTTP_CONFIRM_UPGRADE, to achieve denial of service.&#xA;CVE-2025-11678:Stack-based Buffer Overflow in lws_adns_parse_label in warmcat libwebsockets allows, when the LWS_WITH_SYS_ASYNC_DNS flag is enabled during compilation, to overflow the label_stack, when the attacker is able to sniff a DNS request in order to craft a response with a matching id containing a label longer than the maximum.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="libwebsockets" release="7.u3" version="4.3.0">
					<filename>libwebsockets-4.3.0-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libwebsockets-4.3.0-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libwebsockets-devel" release="7.u3" version="4.3.0">
					<filename>libwebsockets-devel-4.3.0-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libwebsockets-devel-4.3.0-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebsockets" release="7.u3" version="4.3.0">
					<filename>libwebsockets-4.3.0-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libwebsockets-4.3.0-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libwebsockets-devel" release="7.u3" version="4.3.0">
					<filename>libwebsockets-devel-4.3.0-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libwebsockets-devel-4.3.0-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libwebsockets-help" release="7.u3" version="4.3.0">
					<filename>libwebsockets-help-4.3.0-7.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libwebsockets-help-4.3.0-7.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3018</id>
		<title>An update for ansible is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5764&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5764" id="CVE-2023-5764" title="CVE-2023-5764" type="cve"></reference>
		</references>
		<description>CVE-2023-5764:A template injection flaw was found in Ansible where a user&#39;s controller internal templating operations may remove the unsafe designation from template data. This issue could allow an attacker to use a specially crafted file to introduce templating injection when supplying templating data.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="ansible" release="7.u8" version="2.9.27">
					<filename>ansible-2.9.27-7.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ansible-2.9.27-7.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ansible-help" release="7.u8" version="2.9.27">
					<filename>ansible-help-2.9.27-7.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ansible-help-2.9.27-7.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3019</id>
		<title>An update for yasm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22653&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-22653" id="CVE-2024-22653" title="CVE-2024-22653" type="cve"></reference>
		</references>
		<description>CVE-2024-22653:yasm commit 9defefae was discovered to contain a NULL pointer dereference via the yasm_section_bcs_append function at section.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="yasm" release="14.u5" version="1.3.0">
					<filename>yasm-1.3.0-14.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/yasm-1.3.0-14.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yasm" release="14.u5" version="1.3.0">
					<filename>yasm-1.3.0-14.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/yasm-1.3.0-14.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3020</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58251&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58251" id="CVE-2024-58251" title="CVE-2024-58251" type="cve"></reference>
		</references>
		<description>CVE-2024-58251:In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="1" name="busybox-help" release="26.u5" version="1.34.1">
					<filename>busybox-help-1.34.1-26.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/busybox-help-1.34.1-26.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-petitboot" release="26.u5" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-26.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/busybox-petitboot-1.34.1-26.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox" release="26.u5" version="1.34.1">
					<filename>busybox-1.34.1-26.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/busybox-1.34.1-26.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox" release="26.u5" version="1.34.1">
					<filename>busybox-1.34.1-26.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/busybox-1.34.1-26.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-help" release="26.u5" version="1.34.1">
					<filename>busybox-help-1.34.1-26.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/busybox-help-1.34.1-26.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-petitboot" release="26.u5" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-26.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/busybox-petitboot-1.34.1-26.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3021</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-50420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-50420" id="CVE-2025-50420" title="CVE-2025-50420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52886&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52886" id="CVE-2025-52886" title="CVE-2025-52886" type="cve"></reference>
		</references>
		<description>CVE-2025-50420:An issue in the pdfseparate utility of freedesktop poppler v25.04.0 allows attackers to cause an infinite recursion via supplying a crafted PDF file. This can lead to a Denial of Service (DoS).&#xA;CVE-2025-52886:Poppler is a PDF rendering library. Versions prior to 25.06.0 use `std::atomic_int` for reference counting. Because `std::atomic_int` is only 32 bits, it is possible to overflow the reference count and trigger a use-after-free. Version 25.06.0 patches the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="13.u10" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-13.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-glib-doc-0.90.0-13.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="13.u10" version="0.90.0">
					<filename>poppler-help-0.90.0-13.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-help-0.90.0-13.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="13.u10" version="0.90.0">
					<filename>poppler-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="13.u10" version="0.90.0">
					<filename>poppler-qt5-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-qt5-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="13.u10" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-cpp-devel-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="13.u10" version="0.90.0">
					<filename>poppler-devel-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-devel-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="13.u10" version="0.90.0">
					<filename>poppler-glib-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-glib-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="13.u10" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-glib-devel-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="13.u10" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-qt5-devel-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="13.u10" version="0.90.0">
					<filename>poppler-utils-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-utils-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="13.u10" version="0.90.0">
					<filename>poppler-cpp-0.90.0-13.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/poppler-cpp-0.90.0-13.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="13.u10" version="0.90.0">
					<filename>poppler-utils-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-utils-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="13.u10" version="0.90.0">
					<filename>poppler-glib-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-glib-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="13.u10" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-cpp-devel-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="13.u10" version="0.90.0">
					<filename>poppler-devel-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-devel-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="13.u10" version="0.90.0">
					<filename>poppler-qt5-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-qt5-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="13.u10" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-qt5-devel-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler" release="13.u10" version="0.90.0">
					<filename>poppler-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="13.u10" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-glib-devel-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="13.u10" version="0.90.0">
					<filename>poppler-cpp-0.90.0-13.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/poppler-cpp-0.90.0-13.u10.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3022</id>
		<title>An update for python-pip is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-8869&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-8869" id="CVE-2025-8869" title="CVE-2025-8869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66418&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66418" id="CVE-2025-66418" title="CVE-2025-66418" type="cve"></reference>
		</references>
		<description>CVE-2025-8869:When extracting a tar archive pip may not check symbolic links point into the extraction directory if the tarfile module doesn&#39;t implement PEP 706.&#xA;Note that upgrading pip to a &#34;fixed&#34; version for this vulnerability doesn&#39;t fix all known vulnerabilities that are remediated by using a Python version that implements PEP 706.&#xA;&#xA;Note that this is a vulnerability in pip&#39;s fallback implementation of tar extraction for Python versions that don&#39;t implement PEP 706&#xA;and therefore are not secure to all vulnerabilities in the Python &#39;tarfile&#39; module. If you&#39;re using a Python version that implements PEP 706&#xA;then pip doesn&#39;t use the &#34;vulnerable&#34; fallback code.&#xA;&#xA;Mitigations include upgrading to a version of pip that includes the fix, upgrading to a Python version that implements PEP 706 (Python &gt;=3.9.17, &gt;=3.10.12, &gt;=3.11.4, or &gt;=3.12),&#xA;applying the linked patch, or inspecting source distributions (sdists) before installation as is already a best-practice.&#xA;CVE-2025-66418:urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python-pip-help" release="13.u7" version="21.3.1">
					<filename>python-pip-help-21.3.1-13.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python-pip-help-21.3.1-13.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-wheel" release="13.u7" version="21.3.1">
					<filename>python-pip-wheel-21.3.1-13.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python-pip-wheel-21.3.1-13.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pip" release="13.u7" version="21.3.1">
					<filename>python3-pip-21.3.1-13.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-pip-21.3.1-13.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3023</id>
		<title>An update for gdb is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-48064" id="CVE-2022-48064" title="CVE-2022-48064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11082&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11082" id="CVE-2025-11082" title="CVE-2025-11082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11494&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11494" id="CVE-2025-11494" title="CVE-2025-11494" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32256&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-32256" id="CVE-2021-32256" title="CVE-2021-32256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11083" id="CVE-2025-11083" title="CVE-2025-11083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11412&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11412" id="CVE-2025-11412" title="CVE-2025-11412" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11840&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11840" id="CVE-2025-11840" title="CVE-2025-11840" type="cve"></reference>
		</references>
		<description>CVE-2022-48064:GNU Binutils before 2.40 was discovered to contain an excessive memory consumption vulnerability via the function bfd_dwarf2_find_nearest_line_with_alt at dwarf2.c. The attacker could supply a crafted ELF file and cause a DNS attack.&#xA;CVE-2025-11082:A flaw has been found in GNU Binutils 2.45. Impacted is the function _bfd_elf_parse_eh_frame of the file bfd/elf-eh-frame.c of the component Linker. Executing manipulation can lead to heap-based buffer overflow. The attack is restricted to local execution. The exploit has been published and may be used. This patch is called ea1a0737c7692737a644af0486b71e4a392cbca8. A patch should be applied to remediate this issue. The code maintainer replied with &#34;[f]ixed for 2.46&#34;.&#xA;CVE-2025-11494:A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.&#xA;CVE-2021-32256:An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.36. It is a stack-overflow issue in demangle_type in rust-demangle.c.&#xA;CVE-2025-11083:A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with &#34;[f]ixed for 2.46&#34;.&#xA;CVE-2025-11412:A vulnerability has been found in GNU Binutils 2.45. This impacts the function bfd_elf_gc_record_vtentry of the file bfd/elflink.c of the component Linker. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier of the patch is 047435dd988a3975d40c6626a8f739a0b2e154bc. To fix this issue, it is recommended to deploy a patch.&#xA;CVE-2025-11840:A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="gdb-help" release="16.u6" version="11.1">
					<filename>gdb-help-11.1-16.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gdb-help-11.1-16.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb" release="16.u6" version="11.1">
					<filename>gdb-11.1-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gdb-11.1-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-headless" release="16.u6" version="11.1">
					<filename>gdb-headless-11.1-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gdb-headless-11.1-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdb-gdbserver" release="16.u6" version="11.1">
					<filename>gdb-gdbserver-11.1-16.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gdb-gdbserver-11.1-16.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-gdbserver" release="16.u6" version="11.1">
					<filename>gdb-gdbserver-11.1-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gdb-gdbserver-11.1-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb-headless" release="16.u6" version="11.1">
					<filename>gdb-headless-11.1-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gdb-headless-11.1-16.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdb" release="16.u6" version="11.1">
					<filename>gdb-11.1-16.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gdb-11.1-16.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3024</id>
		<title>An update for qt5-qtdeclarative is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-12385&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-12385" id="CVE-2025-12385" title="CVE-2025-12385" type="cve"></reference>
		</references>
		<description>CVE-2025-12385:Allocation of Resources Without Limits or Throttling, Improper Validation of Specified Quantity in Input vulnerability in The Qt Company Qt on Windows, MacOS, Linux, iOS, Android, x86, ARM, 64 bit, 32 bit allows Excessive Allocation.&#xA;This issue affects users of the Text component in Qt Quick. Missing validation of the width and height in the &lt;img&gt; tag could cause an application to become unresponsive.&#xA;&#xA;This issue affects Qt: from 5.0.0 through 6.5.10, from 6.6.0 through 6.8.5, from 6.9.0 through 6.10.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="qt5-qtdeclarative" release="2.u1" version="5.15.2">
					<filename>qt5-qtdeclarative-5.15.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qt5-qtdeclarative-5.15.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtdeclarative-devel" release="2.u1" version="5.15.2">
					<filename>qt5-qtdeclarative-devel-5.15.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qt5-qtdeclarative-devel-5.15.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtdeclarative" release="2.u1" version="5.15.2">
					<filename>qt5-qtdeclarative-5.15.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qt5-qtdeclarative-5.15.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtdeclarative-devel" release="2.u1" version="5.15.2">
					<filename>qt5-qtdeclarative-devel-5.15.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qt5-qtdeclarative-devel-5.15.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3025</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0861&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0861" id="CVE-2026-0861" title="CVE-2026-0861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0915&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0915" id="CVE-2026-0915" title="CVE-2026-0915" type="cve"></reference>
		</references>
		<description>CVE-2026-0861:Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.&#xA;&#xA;Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this.  The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument.  This limits the malicious inputs for the alignment for memalign to the range [1&lt;&lt;62+ 1, 1&lt;&lt;63] and exactly 1&lt;&lt;63 for posix_memalign and aligned_alloc.&#xA;&#xA;Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice.  An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.&#xA;CVE-2026-0915:Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library&#39;s DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="glibc-common" release="172.u32" version="2.34">
					<filename>glibc-common-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-common-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="172.u32" version="2.34">
					<filename>libnsl-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libnsl-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="172.u32" version="2.34">
					<filename>glibc-locale-archive-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-locale-archive-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="172.u32" version="2.34">
					<filename>glibc-compat-2.17-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-compat-2.17-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc" release="172.u32" version="2.34">
					<filename>glibc-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="172.u32" version="2.34">
					<filename>glibc-debugutils-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-debugutils-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="172.u32" version="2.34">
					<filename>nss_modules-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/nss_modules-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="172.u32" version="2.34">
					<filename>glibc-all-langpacks-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-all-langpacks-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="172.u32" version="2.34">
					<filename>glibc-nss-devel-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-nss-devel-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="172.u32" version="2.34">
					<filename>glibc-devel-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-devel-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="172.u32" version="2.34">
					<filename>glibc-locale-source-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-locale-source-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="172.u32" version="2.34">
					<filename>nscd-2.34-172.u32.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/nscd-2.34-172.u32.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="172.u32" version="2.34">
					<filename>glibc-help-2.34-172.u32.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glibc-help-2.34-172.u32.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="172.u32" version="2.34">
					<filename>glibc-locale-archive-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-locale-archive-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="172.u32" version="2.34">
					<filename>libnsl-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libnsl-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="172.u32" version="2.34">
					<filename>nss_modules-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/nss_modules-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="172.u32" version="2.34">
					<filename>glibc-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="172.u32" version="2.34">
					<filename>glibc-compat-2.17-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-compat-2.17-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="172.u32" version="2.34">
					<filename>glibc-devel-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-devel-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="172.u32" version="2.34">
					<filename>glibc-nss-devel-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-nss-devel-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="172.u32" version="2.34">
					<filename>nscd-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/nscd-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="172.u32" version="2.34">
					<filename>glibc-locale-source-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-locale-source-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="172.u32" version="2.34">
					<filename>glibc-all-langpacks-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-all-langpacks-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="172.u32" version="2.34">
					<filename>glibc-common-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-common-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="172.u32" version="2.34">
					<filename>glibc-debugutils-2.34-172.u32.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glibc-debugutils-2.34-172.u32.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3026</id>
		<title>An update for opencc is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-15536&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-15536" id="CVE-2025-15536" title="CVE-2025-15536" type="cve"></reference>
		</references>
		<description>CVE-2025-15536:A weakness has been identified in BYVoid OpenCC up to 1.1.9. This vulnerability affects the function opencc::MaxMatchSegmentation of the file src/MaxMatchSegmentation.cpp. This manipulation causes heap-based buffer overflow. The attack is restricted to local execution. The exploit has been made available to the public and could be used for attacks. Patch name: 345c9a50ab07018f1b4439776bad78a0d40778ec. To fix this issue, it is recommended to deploy a patch.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="opencc-help" release="3.u1" version="1.1.3">
					<filename>opencc-help-1.1.3-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/opencc-help-1.1.3-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opencc" release="3.u1" version="1.1.3">
					<filename>opencc-1.1.3-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/opencc-1.1.3-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opencc-devel" release="3.u1" version="1.1.3">
					<filename>opencc-devel-1.1.3-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/opencc-devel-1.1.3-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="opencc" release="3.u1" version="1.1.3">
					<filename>opencc-1.1.3-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/opencc-1.1.3-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="opencc-devel" release="3.u1" version="1.1.3">
					<filename>opencc-devel-1.1.3-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/opencc-devel-1.1.3-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="opencc-help" release="3.u1" version="1.1.3">
					<filename>opencc-help-1.1.3-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/opencc-help-1.1.3-3.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3027</id>
		<title>An update for glib-networking is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-60018&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-60018" id="CVE-2025-60018" title="CVE-2025-60018" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-60019&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-60019" id="CVE-2025-60019" title="CVE-2025-60019" type="cve"></reference>
		</references>
		<description>CVE-2025-60018:glib-networking&#39;s OpenSSL backend fails to properly check the return value of a call to BIO_write(), resulting in an out of bounds read.&#xA;CVE-2025-60019:glib-networking&#39;s OpenSSL backend fails to properly check the return value of memory allocation routines. An out of memory condition could potentially result in writing to an invalid memory location.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="glib-networking" release="6.u1" version="2.68.1">
					<filename>glib-networking-2.68.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glib-networking-2.68.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib-networking-tests" release="6.u1" version="2.68.1">
					<filename>glib-networking-tests-2.68.1-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glib-networking-tests-2.68.1-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib-networking" release="6.u1" version="2.68.1">
					<filename>glib-networking-2.68.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib-networking-2.68.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib-networking-tests" release="6.u1" version="2.68.1">
					<filename>glib-networking-tests-2.68.1-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib-networking-tests-2.68.1-6.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3028</id>
		<title>An update for rubygem-rack is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59830&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59830" id="CVE-2025-59830" title="CVE-2025-59830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61919&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61919" id="CVE-2025-61919" title="CVE-2025-61919" type="cve"></reference>
		</references>
		<description>CVE-2025-59830:Rack is a modular Ruby web server interface. Prior to version 2.2.18, Rack::QueryParser enforces its params_limit only for parameters separated by &amp;, while still splitting on both &amp; and ;. As a result, attackers could use ; separators to bypass the parameter count limit and submit more parameters than intended. Applications or middleware that directly invoke Rack::QueryParser with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector. This issue has been patched in version 2.2.18.&#xA;CVE-2025-61919:Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, `Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion. Users should upgrade to Rack version 2.2.20, 3.1.18, or 3.2.3, anu of which enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies. Additionally, enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="1" name="rubygem-rack" release="10.u6" version="2.2.3.1">
					<filename>rubygem-rack-2.2.3.1-10.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/rubygem-rack-2.2.3.1-10.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="rubygem-rack-help" release="10.u6" version="2.2.3.1">
					<filename>rubygem-rack-help-2.2.3.1-10.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/rubygem-rack-help-2.2.3.1-10.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3029</id>
		<title>An update for python-fonttools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45139&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-45139" id="CVE-2023-45139" title="CVE-2023-45139" type="cve"></reference>
		</references>
		<description>CVE-2023-45139:fontTools is a library for manipulating fonts, written in Python. The subsetting module has a XML External Entity Injection (XXE) vulnerability which allows an attacker to resolve arbitrary entities when a candidate font (OT-SVG fonts), which contains a SVG table, is parsed. This allows attackers to include arbitrary files from the filesystem fontTools is running on or make web requests from the host system. This vulnerability has been patched in version 4.43.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python3-fonttools" release="2.u1" version="4.39.4">
					<filename>python3-fonttools-4.39.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-fonttools-4.39.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="fonttools" release="2.u1" version="4.39.4">
					<filename>fonttools-4.39.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/fonttools-4.39.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="fonttools-help" release="2.u1" version="4.39.4">
					<filename>fonttools-help-4.39.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/fonttools-help-4.39.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3030</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49288&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-49288" id="CVE-2023-49288" title="CVE-2023-49288" type="cve"></reference>
		</references>
		<description>CVE-2023-49288:Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Affected versions of squid are subject to a a Use-After-Free bug which can lead to a Denial of Service attack via collapsed forwarding. All versions of Squid from 3.5 up to and including 5.9 configured with &#34;collapsed_forwarding on&#34; are vulnerable. Configurations with &#34;collapsed_forwarding off&#34; or without a &#34;collapsed_forwarding&#34; directive are not vulnerable. This bug is fixed by Squid version 6.0.1. Users are advised to upgrade. Users unable to upgrade should remove all collapsed_forwarding lines from their squid.conf.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="7" name="squid" release="29.u12" version="4.9">
					<filename>squid-4.9-29.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/squid-4.9-29.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="7" name="squid" release="29.u12" version="4.9">
					<filename>squid-4.9-29.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/squid-4.9-29.u12.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3031</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31133&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31133" id="CVE-2025-31133" title="CVE-2025-31133" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52565&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52565" id="CVE-2025-52565" title="CVE-2025-52565" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52881&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52881" id="CVE-2025-52881" title="CVE-2025-52881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-65637&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-65637" id="CVE-2025-65637" title="CVE-2025-65637" type="cve"></reference>
		</references>
		<description>CVE-2025-31133:runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container&#39;s /dev/null) was actually a real /dev/null inode when using the container&#39;s /dev/null to mask. This exposes two methods of attack:  an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.&#xA;CVE-2025-52565:runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.&#xA;CVE-2025-52881:runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.&#xA;CVE-2025-65637:A denial-of-service vulnerability exists in github.com/sirupsen/logrus when using Entry.Writer() to log a single-line payload larger than 64KB without newline characters. Due to limitations in the internal bufio.Scanner, the read fails with &#34;token too long&#34; and the writer pipe is closed, leaving Writer() unusable and causing application unavailability (DoS). This affects versions &lt; 1.8.3, 1.9.0, and 1.9.2. The issue is fixed in 1.8.3, 1.9.1, and 1.9.3+, where the input is chunked and the writer continues to function even if an error is logged.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="runc" release="36.u12" version="1.1.3">
					<filename>runc-1.1.3-36.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/runc-1.1.3-36.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="runc" release="36.u12" version="1.1.3">
					<filename>runc-1.1.3-36.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/runc-1.1.3-36.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3032</id>
		<title>An update for dhcp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40778" id="CVE-2025-40778" title="CVE-2025-40778" type="cve"></reference>
		</references>
		<description>CVE-2025-40778:Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.&#xA;This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="12" name="dhcp-help" release="11.u8" version="4.4.3">
					<filename>dhcp-help-4.4.3-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/dhcp-help-4.4.3-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="dhcp" release="11.u8" version="4.4.3">
					<filename>dhcp-4.4.3-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/dhcp-4.4.3-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="12" name="dhcp-devel" release="11.u8" version="4.4.3">
					<filename>dhcp-devel-4.4.3-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/dhcp-devel-4.4.3-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="dhcp" release="11.u8" version="4.4.3">
					<filename>dhcp-4.4.3-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/dhcp-4.4.3-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="12" name="dhcp-devel" release="11.u8" version="4.4.3">
					<filename>dhcp-devel-4.4.3-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/dhcp-devel-4.4.3-11.u8.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3033</id>
		<title>An update for aide is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54389&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54389" id="CVE-2025-54389" title="CVE-2025-54389" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-54409&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-54409" id="CVE-2025-54409" title="CVE-2025-54409" type="cve"></reference>
		</references>
		<description>CVE-2025-54389:AIDE is an advanced intrusion detection environment. Prior to version 0.19.2, there is an improper output neutralization vulnerability in AIDE.  An attacker can craft a malicious filename by including terminal escape sequences to hide the addition or removal of the file from the report and/or tamper with the log output. A local user might exploit this to bypass the AIDE detection of malicious files. Additionally the output of extended attribute key names and symbolic links targets are also not properly neutralized. This issue has been patched in version 0.19.2. A workaround involves configuring AIDE to write the report output to a regular file, redirecting stdout to a regular file, or redirecting the log output written to stderr to a regular file.&#xA;CVE-2025-54409:AIDE is an advanced intrusion detection environment. From versions 0.13 to 0.19.1, there is a null pointer dereference vulnerability in AIDE. An attacker can crash the program during report printing or database listing after setting extended file attributes with an empty attribute value or with a key containing a comma. A local user might exploit this to cause a local denial of service. This issue has been patched in version 0.19.2. A workaround involves removing xattrs group from rules matching files on affected file systems.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="aide" release="8.u6" version="0.17.4">
					<filename>aide-0.17.4-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/aide-0.17.4-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="aide" release="8.u6" version="0.17.4">
					<filename>aide-0.17.4-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/aide-0.17.4-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="aide-help" release="8.u6" version="0.17.4">
					<filename>aide-help-0.17.4-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/aide-help-0.17.4-8.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3034</id>
		<title>An update for git is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50349&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50349" id="CVE-2024-50349" title="CVE-2024-50349" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52006" id="CVE-2024-52006" title="CVE-2024-52006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52005" id="CVE-2024-52005" title="CVE-2024-52005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48384&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48384" id="CVE-2025-48384" title="CVE-2025-48384" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48386&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48386" id="CVE-2025-48386" title="CVE-2025-48386" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27613&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27613" id="CVE-2025-27613" title="CVE-2025-27613" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46334&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46334" id="CVE-2025-46334" title="CVE-2025-46334" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46835&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-46835" id="CVE-2025-46835" title="CVE-2025-46835" type="cve"></reference>
		</references>
		<description>CVE-2024-50349:Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When Git asks for credentials via a terminal prompt (i.e. without using any credential helper), it prints out the host name for which the user is expected to provide a username and/or a password. At this stage, any URL-encoded parts have been decoded already, and are printed verbatim. This allows attackers to craft URLs that contain ANSI escape sequences that the terminal interpret to confuse users e.g. into providing passwords for trusted Git hosting sites when in fact they are then sent to untrusted sites that are under the attacker&#39;s control. This issue has been patch via commits `7725b81` and `c903985` which are included in release versions v2.48.1, v2.47.2, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.&#xA;CVE-2024-52006:Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. Git defines a line-based protocol that is used to exchange information between Git and Git credential helpers. Some ecosystems (most notably, .NET and node.js) interpret single Carriage Return characters as newlines, which renders the protections against CVE-2020-5260 incomplete for credential helpers that treat Carriage Returns in this way. This issue has been addressed in commit `b01b9b8` which is included in release versions v2.48.1, v2.47.2, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.&#xA;CVE-2024-52005:Git is a source code management tool. When cloning from a server (or fetching, or pushing), informational or error messages are transported from the remote Git process to the client via the so-called &#34;sideband channel&#34;. These messages will be prefixed with &#34;remote:&#34; and printed directly to the standard error output. Typically, this standard error output is connected to a terminal that understands ANSI escape sequences, which Git did not protect against. Most modern terminals support control sequences that can be used by a malicious actor to hide and misrepresent information, or to mislead the user into executing untrusted scripts. As requested on the git-security mailing list, the patches are under discussion on the public mailing list. Users are advised to update as soon as possible. Users unable to upgrade should avoid recursive clones unless they are from trusted sources.&#xA;CVE-2025-48384:Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When reading a config value, Git strips any trailing carriage return and line feed (CRLF). When writing a config entry, values with a trailing CR are not quoted, causing the CR to be lost when the config is later read. When initializing a submodule, if the submodule path contains a trailing CR, the altered path is read resulting in the submodule being checked out to an incorrect location. If a symlink exists that points the altered path to the submodule hooks directory, and the submodule contains an executable post-checkout hook, the script may be unintentionally executed after checkout. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.&#xA;CVE-2025-48386:Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. The wincred credential helper uses a static buffer (target) as a unique key for storing and comparing against internal storage. This credential helper does not properly bounds check the available space remaining in the buffer before appending to it with wcsncat(), leading to potential buffer overflows. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.&#xA;CVE-2025-27613:Gitk is a Tcl/Tk based Git history browser. Starting with 1.7.0, when a user clones an untrusted repository and runs gitk without additional command arguments, files for which the user has write permission can be created and truncated. The option Support per-file encoding must have been enabled before in Gitk&#39;s Preferences. This option is disabled by default. The same happens when Show origin of this line is used in the main window (regardless of whether Support per-file encoding is enabled or not). This vulnerability is fixed in 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, and 2.50.1.&#xA;CVE-2025-46334:Git GUI allows you to use the Git source control management tools via a GUI. A malicious repository can ship versions of sh.exe or typical textconv filter programs such as astextplain. Due to the unfortunate design of Tcl on Windows, the search path when looking for an executable always includes the current directory. The mentioned programs are invoked when the user selects Git Bash or Browse Files from the menu. This vulnerability is fixed in 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, and 2.50.1.&#xA;CVE-2025-46835:Git GUI allows you to use the Git source control management tools via a GUI. When a user clones an untrusted repository and is tricked into editing a file located in a maliciously named directory in the repository, then Git GUI can create and overwrite files for which the user has write permission. This vulnerability is fixed in 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, and 2.50.1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="git-daemon" release="20.u7" version="2.33.0">
					<filename>git-daemon-2.33.0-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/git-daemon-2.33.0-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git" release="20.u7" version="2.33.0">
					<filename>git-2.33.0-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/git-2.33.0-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-core" release="20.u7" version="2.33.0">
					<filename>git-core-2.33.0-20.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/git-core-2.33.0-20.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gitk" release="20.u7" version="2.33.0">
					<filename>gitk-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gitk-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git" release="20.u7" version="2.33.0">
					<filename>perl-Git-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/perl-Git-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-email" release="20.u7" version="2.33.0">
					<filename>git-email-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-email-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-gui" release="20.u7" version="2.33.0">
					<filename>git-gui-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-gui-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-web" release="20.u7" version="2.33.0">
					<filename>git-web-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-web-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git-SVN" release="20.u7" version="2.33.0">
					<filename>perl-Git-SVN-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/perl-Git-SVN-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-svn" release="20.u7" version="2.33.0">
					<filename>git-svn-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-svn-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-help" release="20.u7" version="2.33.0">
					<filename>git-help-2.33.0-20.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-help-2.33.0-20.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git" release="20.u7" version="2.33.0">
					<filename>git-2.33.0-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-2.33.0-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-core" release="20.u7" version="2.33.0">
					<filename>git-core-2.33.0-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-core-2.33.0-20.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-daemon" release="20.u7" version="2.33.0">
					<filename>git-daemon-2.33.0-20.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/git-daemon-2.33.0-20.u7.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3035</id>
		<title>An update for libsodium is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69277&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69277" id="CVE-2025-69277" title="CVE-2025-69277" type="cve"></reference>
		</references>
		<description>CVE-2025-69277:libsodium before ad3004e, in atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren&#39;t in the main cryptographic group.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="libsodium" release="2.u1" version="1.0.18">
					<filename>libsodium-1.0.18-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libsodium-1.0.18-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsodium-devel" release="2.u1" version="1.0.18">
					<filename>libsodium-devel-1.0.18-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libsodium-devel-1.0.18-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsodium-devel" release="2.u1" version="1.0.18">
					<filename>libsodium-devel-1.0.18-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libsodium-devel-1.0.18-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsodium" release="2.u1" version="1.0.18">
					<filename>libsodium-1.0.18-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libsodium-1.0.18-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3036</id>
		<title>An update for fluidsynth is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-56225&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-56225" id="CVE-2025-56225" title="CVE-2025-56225" type="cve"></reference>
		</references>
		<description>CVE-2025-56225:fluidsynth-2.4.6 and earlier versions is vulnerable to Null pointer dereference in fluid_synth_monopoly.c, that can be triggered when loading an invalid midi file.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="fluidsynth-help" release="2.u1" version="2.2.7">
					<filename>fluidsynth-help-2.2.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/fluidsynth-help-2.2.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fluidsynth" release="2.u1" version="2.2.7">
					<filename>fluidsynth-2.2.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/fluidsynth-2.2.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fluidsynth-devel" release="2.u1" version="2.2.7">
					<filename>fluidsynth-devel-2.2.7-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/fluidsynth-devel-2.2.7-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fluidsynth" release="2.u1" version="2.2.7">
					<filename>fluidsynth-2.2.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/fluidsynth-2.2.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fluidsynth-devel" release="2.u1" version="2.2.7">
					<filename>fluidsynth-devel-2.2.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/fluidsynth-devel-2.2.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fluidsynth-help" release="2.u1" version="2.2.7">
					<filename>fluidsynth-help-2.2.7-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/fluidsynth-help-2.2.7-2.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3037</id>
		<title>An update for rsync is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-10158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-10158" id="CVE-2025-10158" title="CVE-2025-10158" type="cve"></reference>
		</references>
		<description>CVE-2025-10158:A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The &#xA;&#xA;malicious &#xA;&#xA;rsync client requires at least read access to the remote rsync module in order to trigger the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="rsync" release="5.u4" version="3.2.5">
					<filename>rsync-3.2.5-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/rsync-3.2.5-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rsync-help" release="5.u4" version="3.2.5">
					<filename>rsync-help-3.2.5-5.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/rsync-help-3.2.5-5.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rsync" release="5.u4" version="3.2.5">
					<filename>rsync-3.2.5-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/rsync-3.2.5-5.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3038</id>
		<title>An update for openvpn is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13751&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13751" id="CVE-2025-13751" title="CVE-2025-13751" type="cve"></reference>
		</references>
		<description>CVE-2025-13751:Interactive service agent in OpenVPN version 2.5.0 through 2.6.16 and 2.7_alpha1 through 2.7_rc2 on Windows allows a local authenticated user to connect to the service and trigger an error causing a local denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="openvpn-help" release="6.u5" version="2.5.5">
					<filename>openvpn-help-2.5.5-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/openvpn-help-2.5.5-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn" release="6.u5" version="2.5.5">
					<filename>openvpn-2.5.5-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/openvpn-2.5.5-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn-devel" release="6.u5" version="2.5.5">
					<filename>openvpn-devel-2.5.5-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/openvpn-devel-2.5.5-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvpn" release="6.u5" version="2.5.5">
					<filename>openvpn-2.5.5-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/openvpn-2.5.5-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvpn-devel" release="6.u5" version="2.5.5">
					<filename>openvpn-devel-2.5.5-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/openvpn-devel-2.5.5-6.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3039</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55212" id="CVE-2025-55212" title="CVE-2025-55212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55298&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55298" id="CVE-2025-55298" title="CVE-2025-55298" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-57803&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-57803" id="CVE-2025-57803" title="CVE-2025-57803" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-57807&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-57807" id="CVE-2025-57807" title="CVE-2025-57807" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62171" id="CVE-2025-62171" title="CVE-2025-62171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62594&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62594" id="CVE-2025-62594" title="CVE-2025-62594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-65955&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-65955" id="CVE-2025-65955" title="CVE-2025-65955" type="cve"></reference>
		</references>
		<description>CVE-2025-55212:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-28 and 7.1.2-2, passing a geometry string containing only a colon (&#34;:&#34;) to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service. This issue has been patched in versions 6.9.13-28 and 7.1.2-2.&#xA;CVE-2025-55298:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to ImageMagick versions 6.9.13-28 and 7.1.2-2, a format string bug vulnerability exists in InterpretImageFilename function where user input is directly passed to FormatLocaleString without proper sanitization. An attacker can overwrite arbitrary memory regions, enabling a wide range of attacks from heap overflow to remote code execution. This issue has been patched in versions 6.9.13-28 and 7.1.2-2.&#xA;CVE-2025-57803:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-28 and 7.1.2-2 for ImageMagick&#39;s 32-bit build, a 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses bytes_per_line (stride) to a tiny value while the per-row writer still emits 3 × width bytes for 24-bpp images. The row base pointer advances using the (overflowed) stride, so the first row immediately writes past its slot and into adjacent heap memory with attacker-controlled bytes. This is a classic, powerful primitive for heap corruption in common auto-convert pipelines. This issue has been patched in versions 6.9.13-28 and 7.1.2-2.&#xA;CVE-2025-57807:ImageMagick is free and open-source software used for editing and manipulating digital images. ImageMagick versions lower than 14.8.2 include  insecure functions: SeekBlob(), which permits advancing the stream offset beyond the current end without increasing capacity, and WriteBlob(), which then expands by quantum + length (amortized) instead of offset + length, and copies to data + offset. When offset ≫ extent, the copy targets memory beyond the allocation, producing a deterministic heap write on 64-bit builds. No 2⁶⁴ arithmetic wrap, external delegates, or policy settings are required. This is fixed in version 14.8.2.&#xA;CVE-2025-62171:ImageMagick is an open source software suite for displaying, converting, and editing raster image files. In ImageMagick versions prior to 7.1.2-7 and 6.9.13-32, an integer overflow vulnerability exists in the BMP decoder on 32-bit systems. The vulnerability occurs in coders/bmp.c when calculating the extent value by multiplying image columns by bits per pixel. On 32-bit systems with size_t of 4 bytes, a malicious BMP file with specific dimensions can cause this multiplication to overflow and wrap to zero. The overflow check added to address CVE-2025-57803 is placed after the overflow occurs, making it ineffective. A specially crafted 58-byte BMP file with width set to 536,870,912 and 32 bits per pixel can trigger this overflow, causing the bytes_per_line calculation to become zero. This vulnerability only affects 32-bit builds of ImageMagick where default resource limits for width, height, and area have been manually increased beyond their defaults. 64-bit systems with size_t of 8 bytes are not vulnerable, and systems using default ImageMagick resource limits are not vulnerable. The vulnerability is fixed in versions 7.1.2-7 and 6.9.13-32.&#xA;CVE-2025-62594:ImageMagick is a software suite to create, edit, compose, or convert bitmap images. ImageMagick versions prior to 7.1.2-8 are vulnerable to denial-of-service due to unsigned integer underflow and division-by-zero in the CLAHEImage function. When tile width or height is zero, unsigned underflow occurs in pointer arithmetic, leading to out-of-bounds memory access, and division-by-zero causes immediate crashes. This issue has been patched in version 7.1.2-8.&#xA;CVE-2025-65955:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-9 and 6.9.13-34, there is a vulnerability in ImageMagick’s Magick++ layer that manifests when Options::fontFamily is invoked with an empty string. Clearing a font family calls RelinquishMagickMemory on _drawInfo-&gt;font, freeing the font string but leaving _drawInfo-&gt;font pointing to freed memory while _drawInfo-&gt;family is set to that (now-invalid) pointer. Any later cleanup or reuse of _drawInfo-&gt;font re-frees or dereferences dangling memory. DestroyDrawInfo and other setters (Options::font, Image::font) assume _drawInfo-&gt;font remains valid, so destruction or subsequent updates trigger crashes or heap corruption. This vulnerability is fixed in 7.1.2-9 and 6.9.13-34.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-devel-7.1.2.9-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/ImageMagick-devel-7.1.2.9-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-perl-7.1.2.9-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/ImageMagick-perl-7.1.2.9-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-7.1.2.9-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/ImageMagick-7.1.2.9-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-c++-7.1.2.9-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/ImageMagick-c++-7.1.2.9-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-c++-devel-7.1.2.9-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/ImageMagick-c++-devel-7.1.2.9-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-c++-devel-7.1.2.9-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ImageMagick-c++-devel-7.1.2.9-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-devel-7.1.2.9-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ImageMagick-devel-7.1.2.9-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-perl-7.1.2.9-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ImageMagick-perl-7.1.2.9-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-7.1.2.9-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ImageMagick-7.1.2.9-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-c++-7.1.2.9-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ImageMagick-c++-7.1.2.9-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="ImageMagick-help" release="1.u10" version="7.1.2.9">
					<filename>ImageMagick-help-7.1.2.9-1.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/ImageMagick-help-7.1.2.9-1.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3040</id>
		<title>An update for libvirt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-12748&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-12748" id="CVE-2025-12748" title="CVE-2025-12748" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13193&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13193" id="CVE-2025-13193" title="CVE-2025-13193" type="cve"></reference>
		</references>
		<description>CVE-2025-12748:A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks. A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.&#xA;CVE-2025-13193:A flaw was found in libvirt. External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-core" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-core-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-core-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-wireshark" release="70.u11" version="6.2.0">
					<filename>libvirt-wireshark-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-wireshark-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-config-nwfilter" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-config-nwfilter-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-config-nwfilter-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-qemu" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-qemu-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-qemu-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-scsi" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-scsi-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-scsi-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-bash-completion" release="70.u11" version="6.2.0">
					<filename>libvirt-bash-completion-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-bash-completion-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-nodedev" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-nodedev-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-nodedev-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-admin" release="70.u11" version="6.2.0">
					<filename>libvirt-admin-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-admin-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-client" release="70.u11" version="6.2.0">
					<filename>libvirt-client-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-client-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-gluster" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-gluster-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-gluster-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-iscsi" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-iscsi-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-libs" release="70.u11" version="6.2.0">
					<filename>libvirt-libs-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-libs-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt" release="70.u11" version="6.2.0">
					<filename>libvirt-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-kvm" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-kvm-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-kvm-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-interface" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-interface-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-interface-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-nss" release="70.u11" version="6.2.0">
					<filename>libvirt-nss-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-nss-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-secret" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-secret-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-secret-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-logical" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-logical-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-logical-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-nwfilter" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-nwfilter-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-nwfilter-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-mpath" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-mpath-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-mpath-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-disk" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-disk-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-disk-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-network" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-network-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-network-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-docs" release="70.u11" version="6.2.0">
					<filename>libvirt-docs-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-docs-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-config-network" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-config-network-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-config-network-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-rbd" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-rbd-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-rbd-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-qemu" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-qemu-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-qemu-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-devel" release="70.u11" version="6.2.0">
					<filename>libvirt-devel-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-devel-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-lock-sanlock" release="70.u11" version="6.2.0">
					<filename>libvirt-lock-sanlock-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-lock-sanlock-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libvirt-daemon-driver-storage-iscsi-direct" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-70.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libvirt-daemon-driver-storage-iscsi-direct-6.2.0-70.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-logical" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-logical-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-logical-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-scsi" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-scsi-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-scsi-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-kvm" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-kvm-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-kvm-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-nwfilter" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-nwfilter-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-nwfilter-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-disk" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-disk-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-disk-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-devel" release="70.u11" version="6.2.0">
					<filename>libvirt-devel-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-devel-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-libs" release="70.u11" version="6.2.0">
					<filename>libvirt-libs-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-libs-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-client" release="70.u11" version="6.2.0">
					<filename>libvirt-client-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-client-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-config-network" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-config-network-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-config-network-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-config-nwfilter" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-config-nwfilter-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-config-nwfilter-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-interface" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-interface-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-interface-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-nss" release="70.u11" version="6.2.0">
					<filename>libvirt-nss-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-nss-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-admin" release="70.u11" version="6.2.0">
					<filename>libvirt-admin-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-admin-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-bash-completion" release="70.u11" version="6.2.0">
					<filename>libvirt-bash-completion-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-bash-completion-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-secret" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-secret-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-secret-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-nodedev" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-nodedev-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-nodedev-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-iscsi" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-iscsi-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-network" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-network-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-network-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-iscsi-direct" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-iscsi-direct-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-docs" release="70.u11" version="6.2.0">
					<filename>libvirt-docs-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-docs-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt" release="70.u11" version="6.2.0">
					<filename>libvirt-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-qemu" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-qemu-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-qemu-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-core" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-core-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-core-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-qemu" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-qemu-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-qemu-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-lock-sanlock" release="70.u11" version="6.2.0">
					<filename>libvirt-lock-sanlock-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-lock-sanlock-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-mpath" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-mpath-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-mpath-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-gluster" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-gluster-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-gluster-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-daemon-driver-storage-rbd" release="70.u11" version="6.2.0">
					<filename>libvirt-daemon-driver-storage-rbd-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-daemon-driver-storage-rbd-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libvirt-wireshark" release="70.u11" version="6.2.0">
					<filename>libvirt-wireshark-6.2.0-70.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libvirt-wireshark-6.2.0-70.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3041</id>
		<title>An update for zvbi is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2173&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2173" id="CVE-2025-2173" title="CVE-2025-2173" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2174&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2174" id="CVE-2025-2174" title="CVE-2025-2174" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2176" id="CVE-2025-2176" title="CVE-2025-2176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2177" id="CVE-2025-2177" title="CVE-2025-2177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2175&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2175" id="CVE-2025-2175" title="CVE-2025-2175" type="cve"></reference>
		</references>
		<description>CVE-2025-2173:A vulnerability was found in libzvbi up to 0.2.43. It has been classified as problematic. Affected is the function vbi_strndup_iconv_ucs2 of the file src/conv.c. The manipulation of the argument src_length leads to uninitialized pointer. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is identified as 8def647eea27f7fd7ad33ff79c2d6d3e39948dce. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.&#xA;CVE-2025-2174:A vulnerability was found in libzvbi up to 0.2.43. It has been declared as problematic. Affected by this vulnerability is the function vbi_strndup_iconv_ucs2 of the file src/conv.c. The manipulation of the argument src_length leads to integer overflow. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is named ca1672134b3e2962cd392212c73f44f8f4cb489f. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.&#xA;CVE-2025-2176:A vulnerability classified as critical has been found in libzvbi up to 0.2.43. This affects the function vbi_capture_sim_load_caption of the file src/io-sim.c. The manipulation leads to integer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The identifier of the patch is ca1672134b3e2962cd392212c73f44f8f4cb489f. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.&#xA;CVE-2025-2177:A vulnerability classified as critical was found in libzvbi up to 0.2.43. This vulnerability affects the function vbi_search_new of the file src/search.c. The manipulation of the argument pat_len leads to integer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is identified as ca1672134b3e2962cd392212c73f44f8f4cb489f. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.&#xA;CVE-2025-2175:A vulnerability was found in libzvbi up to 0.2.43. It has been rated as problematic. Affected by this issue is the function _vbi_strndup_iconv. The manipulation leads to integer overflow. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="zvbi-help" release="1" version="0.2.44">
					<filename>zvbi-help-0.2.44-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/zvbi-help-0.2.44-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="zvbi" release="1" version="0.2.44">
					<filename>zvbi-0.2.44-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/zvbi-0.2.44-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="zvbi-devel" release="1" version="0.2.44">
					<filename>zvbi-devel-0.2.44-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/zvbi-devel-0.2.44-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zvbi" release="1" version="0.2.44">
					<filename>zvbi-0.2.44-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/zvbi-0.2.44-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zvbi-devel" release="1" version="0.2.44">
					<filename>zvbi-devel-0.2.44-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/zvbi-devel-0.2.44-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="zvbi-help" release="1" version="0.2.44">
					<filename>zvbi-help-0.2.44-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/zvbi-help-0.2.44-1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3042</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5994&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5994" id="CVE-2025-5994" title="CVE-2025-5994" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11411&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11411" id="CVE-2025-11411" title="CVE-2025-11411" type="cve"></reference>
		</references>
		<description>CVE-2025-5994:A multi-vendor cache poisoning vulnerability named &#39;Rebirthday Attack&#39; has been discovered in caching resolvers that support EDNS Client Subnet (ECS). Unbound is also vulnerable when compiled with ECS support, i.e., &#39;--enable-subnet&#39;, AND configured to send ECS information along with queries to upstream name servers, i.e., at least one of the &#39;send-client-subnet&#39;, &#39;client-subnet-zone&#39; or &#39;client-subnet-always-forward&#39; options is used. Resolvers supporting ECS need to segregate outgoing queries to accommodate for different outgoing ECS information. This re-opens up resolvers to a birthday paradox attack (Rebirthday Attack) that tries to match the DNS transaction ID in order to cache non-ECS poisonous replies.&#xA;CVE-2025-11411:NLnet Labs Unbound up to and including version 1.24.1 is vulnerable to possible domain hijack attacks. Promiscuous NS RRSets that complement positive DNS replies in the authority section can be used to trick resolvers to update their delegation information for the zone. Usually these RRSets are used to update the resolver&#39;s knowledge of the zone&#39;s name servers. A malicious actor can exploit the possible poisonous effect by injecting NS RRSets (and possibly their respective address records) in a reply. This could be done for example by trying to spoof a packet or fragmentation attacks. Unbound would then proceed to update the NS RRSet data it already has since the new data has enough trust for it, i.e., in-zone data for the delegation point. Unbound 1.24.1 includes a fix that scrubs unsolicited NS RRSets (and their respective address records) from replies mitigating the possible poison effect. Unbound 1.24.2 includes an additional fix that scrubs unsolicited NS RRSets (and their respective address records) from YXDOMAIN and non-referral nodata replies, further mitigating the possible poison effect.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="unbound-anchor" release="20.u9" version="1.13.2">
					<filename>unbound-anchor-1.13.2-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/unbound-anchor-1.13.2-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="20.u9" version="1.13.2">
					<filename>unbound-help-1.13.2-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/unbound-help-1.13.2-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="20.u9" version="1.13.2">
					<filename>python3-unbound-1.13.2-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-unbound-1.13.2-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="20.u9" version="1.13.2">
					<filename>unbound-devel-1.13.2-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/unbound-devel-1.13.2-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="20.u9" version="1.13.2">
					<filename>unbound-libs-1.13.2-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/unbound-libs-1.13.2-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="20.u9" version="1.13.2">
					<filename>unbound-1.13.2-20.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/unbound-1.13.2-20.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="20.u9" version="1.13.2">
					<filename>unbound-libs-1.13.2-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/unbound-libs-1.13.2-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="20.u9" version="1.13.2">
					<filename>python3-unbound-1.13.2-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-unbound-1.13.2-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="20.u9" version="1.13.2">
					<filename>unbound-help-1.13.2-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/unbound-help-1.13.2-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-anchor" release="20.u9" version="1.13.2">
					<filename>unbound-anchor-1.13.2-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/unbound-anchor-1.13.2-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound" release="20.u9" version="1.13.2">
					<filename>unbound-1.13.2-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/unbound-1.13.2-20.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="20.u9" version="1.13.2">
					<filename>unbound-devel-1.13.2-20.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/unbound-devel-1.13.2-20.u9.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3043</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68301&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68301" id="CVE-2025-68301" title="CVE-2025-68301" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38584&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38584" id="CVE-2025-38584" title="CVE-2025-38584" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40324&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40324" id="CVE-2025-40324" title="CVE-2025-40324" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53432&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53432" id="CVE-2023-53432" title="CVE-2023-53432" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49426&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49426" id="CVE-2022-49426" title="CVE-2022-49426" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40105&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40105" id="CVE-2025-40105" title="CVE-2025-40105" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40271&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40271" id="CVE-2025-40271" title="CVE-2025-40271" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39756&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39756" id="CVE-2025-39756" title="CVE-2025-39756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53254&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53254" id="CVE-2023-53254" title="CVE-2023-53254" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40190&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40190" id="CVE-2025-40190" title="CVE-2025-40190" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22039&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22039" id="CVE-2025-22039" title="CVE-2025-22039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21968&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21968" id="CVE-2025-21968" title="CVE-2025-21968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57911&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57911" id="CVE-2024-57911" title="CVE-2024-57911" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53466&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53466" id="CVE-2023-53466" title="CVE-2023-53466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49196&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49196" id="CVE-2022-49196" title="CVE-2022-49196" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53491&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53491" id="CVE-2023-53491" title="CVE-2023-53491" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53673&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53673" id="CVE-2023-53673" title="CVE-2023-53673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53520&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53520" id="CVE-2023-53520" title="CVE-2023-53520" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38734&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38734" id="CVE-2025-38734" title="CVE-2025-38734" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39901&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39901" id="CVE-2025-39901" title="CVE-2025-39901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40018&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40018" id="CVE-2025-40018" title="CVE-2025-40018" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38617&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38617" id="CVE-2025-38617" title="CVE-2025-38617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38618&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38618" id="CVE-2025-38618" title="CVE-2025-38618" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38664&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38664" id="CVE-2025-38664" title="CVE-2025-38664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38572&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38572" id="CVE-2025-38572" title="CVE-2025-38572" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39851&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39851" id="CVE-2025-39851" title="CVE-2025-39851" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40102&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40102" id="CVE-2025-40102" title="CVE-2025-40102" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37776&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37776" id="CVE-2025-37776" title="CVE-2025-37776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38561&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38561" id="CVE-2025-38561" title="CVE-2025-38561" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57907&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57907" id="CVE-2024-57907" title="CVE-2024-57907" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21905&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21905" id="CVE-2025-21905" title="CVE-2025-21905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38729" id="CVE-2025-38729" title="CVE-2025-38729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38706&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38706" id="CVE-2025-38706" title="CVE-2025-38706" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58034" id="CVE-2024-58034" title="CVE-2024-58034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22022&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22022" id="CVE-2025-22022" title="CVE-2025-22022" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37927&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37927" id="CVE-2025-37927" title="CVE-2025-37927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38250&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38250" id="CVE-2025-38250" title="CVE-2025-38250" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38201&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38201" id="CVE-2025-38201" title="CVE-2025-38201" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38022&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38022" id="CVE-2025-38022" title="CVE-2025-38022" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37789&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37789" id="CVE-2025-37789" title="CVE-2025-37789" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37749&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37749" id="CVE-2025-37749" title="CVE-2025-37749" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22020" id="CVE-2025-22020" title="CVE-2025-22020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22083" id="CVE-2025-22083" title="CVE-2025-22083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23158" id="CVE-2025-23158" title="CVE-2025-23158" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39994&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39994" id="CVE-2025-39994" title="CVE-2025-39994" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58007&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58007" id="CVE-2024-58007" title="CVE-2024-58007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49470&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49470" id="CVE-2022-49470" title="CVE-2022-49470" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37994&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37994" id="CVE-2025-37994" title="CVE-2025-37994" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22107&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22107" id="CVE-2025-22107" title="CVE-2025-22107" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21945&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21945" id="CVE-2025-21945" title="CVE-2025-21945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37899&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37899" id="CVE-2025-37899" title="CVE-2025-37899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40139&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40139" id="CVE-2025-40139" title="CVE-2025-40139" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37786&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37786" id="CVE-2025-37786" title="CVE-2025-37786" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40204" id="CVE-2025-40204" title="CVE-2025-40204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49267&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49267" id="CVE-2022-49267" title="CVE-2022-49267" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38477&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38477" id="CVE-2025-38477" title="CVE-2025-38477" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38005" id="CVE-2025-38005" title="CVE-2025-38005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37997&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37997" id="CVE-2025-37997" title="CVE-2025-37997" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40200&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40200" id="CVE-2025-40200" title="CVE-2025-40200" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40074&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40074" id="CVE-2025-40074" title="CVE-2025-40074" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40049&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40049" id="CVE-2025-40049" title="CVE-2025-40049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40111&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40111" id="CVE-2025-40111" title="CVE-2025-40111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53510&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53510" id="CVE-2023-53510" title="CVE-2023-53510" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40178&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40178" id="CVE-2025-40178" title="CVE-2025-40178" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53282&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53282" id="CVE-2023-53282" title="CVE-2023-53282" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40211&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40211" id="CVE-2025-40211" title="CVE-2025-40211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21693&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21693" id="CVE-2025-21693" title="CVE-2025-21693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38084" id="CVE-2025-38084" title="CVE-2025-38084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47653&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-47653" id="CVE-2021-47653" title="CVE-2021-47653" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39817" id="CVE-2025-39817" title="CVE-2025-39817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40170&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40170" id="CVE-2025-40170" title="CVE-2025-40170" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40149&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40149" id="CVE-2025-40149" title="CVE-2025-40149" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40319&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40319" id="CVE-2025-40319" title="CVE-2025-40319" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40183" id="CVE-2025-40183" title="CVE-2025-40183" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40168" id="CVE-2025-40168" title="CVE-2025-40168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39766&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39766" id="CVE-2025-39766" title="CVE-2025-39766" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39751&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39751" id="CVE-2025-39751" title="CVE-2025-39751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22121&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22121" id="CVE-2025-22121" title="CVE-2025-22121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40019&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40019" id="CVE-2025-40019" title="CVE-2025-40019" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40194&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40194" id="CVE-2025-40194" title="CVE-2025-40194" type="cve"></reference>
		</references>
		<description>CVE-2025-68301:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: atlantic: fix fragment overflow handling in RX path&#xA;&#xA;The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)&#xA;fragments when handling large multi-descriptor packets. This causes an&#xA;out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.&#xA;&#xA;The issue occurs because the driver doesn&#39;t check the total number of&#xA;fragments before calling skb_add_rx_frag(). When a packet requires more&#xA;than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.&#xA;&#xA;Fix by assuming there will be an extra frag if buff-&gt;len &gt; AQ_CFG_RX_HDR_SIZE,&#xA;then all fragments are accounted for. And reusing the existing check to&#xA;prevent the overflow earlier in the code path.&#xA;&#xA;This crash occurred in production with an Aquantia AQC113 10G NIC.&#xA;&#xA;Stack trace from production environment:&#xA;```&#xA;RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0&#xA;Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89&#xA;ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90&#xA;c8 00 00 00 &lt;48&gt; 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48&#xA;89 fa 83&#xA;RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287&#xA;RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:&#xA;fffffffe0a0c8000&#xA;RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:&#xA;0000000000037a40&#xA;RBP: 0000000000000024 R08: 0000000000000000 R09:&#xA;0000000000000021&#xA;R10: 0000000000000848 R11: 0000000000000000 R12:&#xA;ffffa9bec02a8e24&#xA;R13: ffff925ad8615570 R14: 0000000000000000 R15:&#xA;ffff925b22e80a00&#xA;FS: 0000000000000000(0000)&#xA;GS:ffff925e47880000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:&#xA;0000000000f72ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA;&lt;IRQ&gt;&#xA;aq_ring_rx_clean+0x175/0xe60 [atlantic]&#xA;? aq_ring_rx_clean+0x14d/0xe60 [atlantic]&#xA;? aq_ring_tx_clean+0xdf/0x190 [atlantic]&#xA;? kmem_cache_free+0x348/0x450&#xA;? aq_vec_poll+0x81/0x1d0 [atlantic]&#xA;? __napi_poll+0x28/0x1c0&#xA;? net_rx_action+0x337/0x420&#xA;```&#xA;&#xA;Changes in v4:&#xA;- Add Fixes: tag to satisfy patch validation requirements.&#xA;&#xA;Changes in v3:&#xA;- Fix by assuming there will be an extra frag if buff-&gt;len &gt; AQ_CFG_RX_HDR_SIZE,&#xA;  then all fragments are accounted for.&#xA;CVE-2025-38584:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;padata: Fix pd UAF once and for all&#xA;&#xA;There is a race condition/UAF in padata_reorder that goes back&#xA;to the initial commit.  A reference count is taken at the start&#xA;of the process in padata_do_parallel, and released at the end in&#xA;padata_serial_worker.&#xA;&#xA;This reference count is (and only is) required for padata_replace&#xA;to function correctly.  If padata_replace is never called then&#xA;there is no issue.&#xA;&#xA;In the function padata_reorder which serves as the core of padata,&#xA;as soon as padata is added to queue-&gt;serial.list, and the associated&#xA;spin lock released, that padata may be processed and the reference&#xA;count on pd would go away.&#xA;&#xA;Fix this by getting the next padata before the squeue-&gt;serial lock&#xA;is released.&#xA;&#xA;In order to make this possible, simplify padata_reorder by only&#xA;calling it once the next padata arrives.&#xA;CVE-2025-40324:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Fix crash in nfsd4_read_release()&#xA;&#xA;When tracing is enabled, the trace_nfsd_read_done trace point&#xA;crashes during the pynfs read.testNoFh test.&#xA;CVE-2023-53432:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;firewire: net: fix use after free in fwnet_finish_incoming_packet()&#xA;&#xA;The netif_rx() function frees the skb so we can&#39;t dereference it to&#xA;save the skb-&gt;len.&#xA;CVE-2022-49426:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu/arm-smmu-v3-sva: Fix mm use-after-free&#xA;&#xA;We currently call arm64_mm_context_put() without holding a reference to&#xA;the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to&#xA;ensure the mm only gets freed after we unpinned the ASID.&#xA;CVE-2025-40105:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vfs: Don&#39;t leak disconnected dentries on umount&#xA;&#xA;When user calls open_by_handle_at() on some inode that is not cached, we&#xA;will create disconnected dentry for it. If such dentry is a directory,&#xA;exportfs_decode_fh_raw() will then try to connect this dentry to the&#xA;dentry tree through reconnect_path(). It may happen for various reasons&#xA;(such as corrupted fs or race with rename) that the call to&#xA;lookup_one_unlocked() in reconnect_one() will fail to find the dentry we&#xA;are trying to reconnect and instead create a new dentry under the&#xA;parent. Now this dentry will not be marked as disconnected although the&#xA;parent still may well be disconnected (at least in case this&#xA;inconsistency happened because the fs is corrupted and .. doesn&#39;t point&#xA;to the real parent directory). This creates inconsistency in&#xA;disconnected flags but AFAICS it was mostly harmless. At least until&#xA;commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;)&#xA;which removed adding of most disconnected dentries to sb-&gt;s_anon list.&#xA;Thus after this commit cleanup of disconnected dentries implicitely&#xA;relies on the fact that dput() will immediately reclaim such dentries.&#xA;However when some leaf dentry isn&#39;t marked as disconnected, as in the&#xA;scenario described above, the reclaim doesn&#39;t happen and the dentries&#xA;are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise&#xA;they stay in memory and if umount comes first, we hit infamous &#34;Busy&#xA;inodes after unmount&#34; bug. Make sure all dentries created under a&#xA;disconnected parent are marked as disconnected as well.&#xA;CVE-2025-40271:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/proc: fix uaf in proc_readdir_de()&#xA;&#xA;Pde is erased from subdir rbtree through rb_erase(), but not set the node&#xA;to EMPTY, which may result in uaf access.  We should use RB_CLEAR_NODE()&#xA;set the erased node to EMPTY, then pde_subdir_next() will return NULL to&#xA;avoid uaf access.&#xA;&#xA;We found an uaf issue while using stress-ng testing, need to run testcase&#xA;getdent and tun in the same time.  The steps of the issue is as follows:&#xA;&#xA;1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current&#xA;   pde is tun3;&#xA;&#xA;2) in the [time windows] unregister netdevice tun3 and tun2, and erase&#xA;   them from rbtree.  erase tun3 first, and then erase tun2.  the&#xA;   pde(tun2) will be released to slab;&#xA;&#xA;3) continue to getdent process, then pde_subdir_next() will return&#xA;   pde(tun2) which is released, it will case uaf access.&#xA;&#xA;CPU 0                                      |    CPU 1&#xA;-------------------------------------------------------------------------&#xA;traverse dir /proc/pid/net/dev_snmp6/      |   unregister_netdevice(tun-&gt;dev)   //tun3 tun2&#xA;sys_getdents64()                           |&#xA;  iterate_dir()                            |&#xA;    proc_readdir()                         |&#xA;      proc_readdir_de()                    |     snmp6_unregister_dev()&#xA;        pde_get(de);                       |       proc_remove()&#xA;        read_unlock(&amp;proc_subdir_lock);    |         remove_proc_subtree()&#xA;                                           |           write_lock(&amp;proc_subdir_lock);&#xA;        [time window]                      |           rb_erase(&amp;root-&gt;subdir_node, &amp;parent-&gt;subdir);&#xA;                                           |           write_unlock(&amp;proc_subdir_lock);&#xA;        read_lock(&amp;proc_subdir_lock);      |&#xA;        next = pde_subdir_next(de);        |&#xA;        pde_put(de);                       |&#xA;        de = next;    //UAF                |&#xA;&#xA;rbtree of dev_snmp6&#xA;                        |&#xA;                    pde(tun3)&#xA;                     /    \&#xA;                  NULL  pde(tun2)&#xA;CVE-2025-39756:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs: Prevent file descriptor table allocations exceeding INT_MAX&#xA;&#xA;When sysctl_nr_open is set to a very high value (for example, 1073741816&#xA;as set by systemd), processes attempting to use file descriptors near&#xA;the limit can trigger massive memory allocation attempts that exceed&#xA;INT_MAX, resulting in a WARNING in mm/slub.c:&#xA;&#xA;  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288&#xA;&#xA;This happens because kvmalloc_array() and kvmalloc() check if the&#xA;requested size exceeds INT_MAX and emit a warning when the allocation is&#xA;not flagged with __GFP_NOWARN.&#xA;&#xA;Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a&#xA;process calls dup2(oldfd, 1073741880), the kernel attempts to allocate:&#xA;- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes&#xA;- Multiple bitmaps: ~400MB&#xA;- Total allocation size: &gt; 8GB (exceeding INT_MAX = 2,147,483,647)&#xA;&#xA;Reproducer:&#xA;1. Set /proc/sys/fs/nr_open to 1073741816:&#xA;   # echo 1073741816 &gt; /proc/sys/fs/nr_open&#xA;&#xA;2. Run a program that uses a high file descriptor:&#xA;   #include &lt;unistd.h&gt;&#xA;   #include &lt;sys/resource.h&gt;&#xA;&#xA;   int main() {&#xA;       struct rlimit rlim = {1073741824, 1073741824};&#xA;       setrlimit(RLIMIT_NOFILE, &amp;rlim);&#xA;       dup2(2, 1073741880);  // Triggers the warning&#xA;       return 0;&#xA;   }&#xA;&#xA;3. Observe WARNING in dmesg at mm/slub.c:5027&#xA;&#xA;systemd commit a8b627a introduced automatic bumping of fs.nr_open to the&#xA;maximum possible value. The rationale was that systems with memory&#xA;control groups (memcg) no longer need separate file descriptor limits&#xA;since memory is properly accounted. However, this change overlooked&#xA;that:&#xA;&#xA;1. The kernel&#39;s allocation functions still enforce INT_MAX as a maximum&#xA;   size regardless of memcg accounting&#xA;2. Programs and tests that legitimately test file descriptor limits can&#xA;   inadvertently trigger massive allocations&#xA;3. The resulting allocations (&gt;8GB) are impractical and will always fail&#xA;&#xA;systemd&#39;s algorithm starts with INT_MAX and keeps halving the value&#xA;until the kernel accepts it. On most systems, this results in nr_open&#xA;being set to 1073741816 (0x3ffffff8), which is just under 1GB of file&#xA;descriptors.&#xA;&#xA;While processes rarely use file descriptors near this limit in normal&#xA;operation, certain selftests (like&#xA;tools/testing/selftests/core/unshare_test.c) and programs that test file&#xA;descriptor limits can trigger this issue.&#xA;&#xA;Fix this by adding a check in alloc_fdtable() to ensure the requested&#xA;allocation size does not exceed INT_MAX. This causes the operation to&#xA;fail with -EMFILE instead of triggering a kernel warning and avoids the&#xA;impractical &gt;8GB memory allocation request.&#xA;CVE-2023-53254:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cacheinfo: Fix shared_cpu_map to handle shared caches at different levels&#xA;&#xA;The cacheinfo sets up the shared_cpu_map by checking whether the caches&#xA;with the same index are shared between CPUs. However, this will trigger&#xA;slab-out-of-bounds access if the CPUs do not have the same cache hierarchy.&#xA;Another problem is the mismatched shared_cpu_map when the shared cache does&#xA;not have the same index between CPUs.&#xA;&#xA;CPU0&#x9;I&#x9;D&#x9;L3&#xA;index&#x9;0&#x9;1&#x9;2&#x9;x&#xA;&#x9;^&#x9;^&#x9;^&#x9;^&#xA;index&#x9;0&#x9;1&#x9;2&#x9;3&#xA;CPU1&#x9;I&#x9;D&#x9;L2&#x9;L3&#xA;&#xA;This patch checks each cache is shared with all caches on other CPUs.&#xA;CVE-2025-40190:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: guard against EA inode refcount underflow in xattr update&#xA;&#xA;syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA&#xA;inode refcount that is already &lt;= 0 and then applies ref_change (often&#xA;-1). That lets the refcount underflow and we proceed with a bogus value,&#xA;triggering errors like:&#xA;&#xA;  EXT4-fs error: EA inode &lt;n&gt; ref underflow: ref_count=-1 ref_change=-1&#xA;  EXT4-fs warning: ea_inode dec ref err=-117&#xA;&#xA;Make the invariant explicit: if the current refcount is non-positive,&#xA;treat this as on-disk corruption, emit ext4_error_inode(), and fail the&#xA;operation with -EFSCORRUPTED instead of updating the refcount. Delete the&#xA;WARN_ONCE() as negative refcounts are now impossible; keep error reporting&#xA;in ext4_error_inode().&#xA;&#xA;This prevents the underflow and the follow-on orphan/cleanup churn.&#xA;CVE-2025-22039:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix overflow in dacloffset bounds check&#xA;&#xA;The dacloffset field was originally typed as int and used in an&#xA;unchecked addition, which could overflow and bypass the existing&#xA;bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().&#xA;&#xA;This could result in out-of-bounds memory access and a kernel crash&#xA;when dereferencing the DACL pointer.&#xA;&#xA;This patch converts dacloffset to unsigned int and uses&#xA;check_add_overflow() to validate access to the DACL.&#xA;CVE-2025-21968:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Fix slab-use-after-free on hdcp_work&#xA;&#xA;[Why]&#xA;A slab-use-after-free is reported when HDCP is destroyed but the&#xA;property_validate_dwork queue is still running.&#xA;&#xA;[How]&#xA;Cancel the delayed work when destroying workqueue.&#xA;&#xA;(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)&#xA;CVE-2024-57911:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer&#xA;&#xA;The &#39;data&#39; array is allocated via kmalloc() and it is used to push data&#xA;to user space from a triggered buffer, but it does not set values for&#xA;inactive channels, as it only uses iio_for_each_active_channel()&#xA;to assign new values.&#xA;&#xA;Use kzalloc for the memory allocation to avoid pushing uninitialized&#xA;information to userspace.&#xA;CVE-2023-53466:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit&#xA;&#xA;Always purge mcu skb queues in mt7915_mcu_exit routine even if&#xA;mt7915_firmware_state fails.&#xA;CVE-2022-49196:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powerpc/pseries: Fix use after free in remove_phb_dynamic()&#xA;&#xA;In remove_phb_dynamic() we use &amp;phb-&gt;io_resource, after we&#39;ve called&#xA;device_unregister(&amp;host_bridge-&gt;dev). But the unregister may have freed&#xA;phb, because pcibios_free_controller_deferred() is the release function&#xA;for the host_bridge.&#xA;&#xA;If there are no outstanding references when we call device_unregister()&#xA;then phb will be freed out from under us.&#xA;&#xA;This has gone mainly unnoticed, but with slub_debug and page_poison&#xA;enabled it can lead to a crash:&#xA;&#xA;  PID: 7574   TASK: c0000000d492cb80  CPU: 13  COMMAND: &#34;drmgr&#34;&#xA;   #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc&#xA;   #1 [c0000000e4f075d0] oops_end at c000000000029608&#xA;   #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4&#xA;   #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8&#xA;   #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30&#xA;   Data SLB Access [380] exception frame:&#xA;   R0:  c000000000167250    R1:  c0000000e4f07a00    R2:  c000000002a46100&#xA;   R3:  c000000002b39ce8    R4:  00000000000000c0    R5:  00000000000000a9&#xA;   R6:  3894674d000000c0    R7:  0000000000000000    R8:  00000000000000ff&#xA;   R9:  0000000000000100    R10: 6b6b6b6b6b6b6b6b    R11: 0000000000008000&#xA;   R12: c00000000023da80    R13: c0000009ffd38b00    R14: 0000000000000000&#xA;   R15: 000000011c87f0f0    R16: 0000000000000006    R17: 0000000000000003&#xA;   R18: 0000000000000002    R19: 0000000000000004    R20: 0000000000000005&#xA;   R21: 000000011c87ede8    R22: 000000011c87c5a8    R23: 000000011c87d3a0&#xA;   R24: 0000000000000000    R25: 0000000000000001    R26: c0000000e4f07cc8&#xA;   R27: c00000004d1cc400    R28: c0080000031d00e8    R29: c00000004d23d800&#xA;   R30: c00000004d1d2400    R31: c00000004d1d2540&#xA;   NIP: c000000000167258    MSR: 8000000000009033    OR3: c000000000e9f474&#xA;   CTR: 0000000000000000    LR:  c000000000167250    XER: 0000000020040003&#xA;   CCR: 0000000024088420    MQ:  0000000000000000    DAR: 6b6b6b6b6b6b6ba3&#xA;   DSISR: c0000000e4f07920     Syscall Result: fffffffffffffff2&#xA;   [NIP  : release_resource+56]&#xA;   [LR   : release_resource+48]&#xA;   #5 [c0000000e4f07a00] release_resource at c000000000167258  (unreliable)&#xA;   #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648&#xA;   #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io]&#xA;   #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io]&#xA;   #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c&#xA;  #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504&#xA;  #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868&#xA;  #12 [c0000000e4f07c70] new_sync_write at c00000000054339c&#xA;  #13 [c0000000e4f07d10] vfs_write at c000000000546624&#xA;  #14 [c0000000e4f07d60] ksys_write at c0000000005469f4&#xA;  #15 [c0000000e4f07db0] system_call_exception at c000000000030840&#xA;  #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168&#xA;&#xA;To avoid it, we can take a reference to the host_bridge-&gt;dev until we&#39;re&#xA;done using phb. Then when we drop the reference the phb will be freed.&#xA;CVE-2023-53491:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;start_kernel: Add __no_stack_protector function attribute&#xA;&#xA;Back during the discussion of&#xA;commit a9a3ed1eff36 (&#34;x86: Fix early boot crash on gcc-10, third try&#34;)&#xA;we discussed the need for a function attribute to control the omission&#xA;of stack protectors on a per-function basis; at the time Clang had&#xA;support for no_stack_protector but GCC did not. This was fixed in&#xA;gcc-11. Now that the function attribute is available, let&#39;s start using&#xA;it.&#xA;&#xA;Callers of boot_init_stack_canary need to use this function attribute&#xA;unless they&#39;re compiled with -fno-stack-protector, otherwise the canary&#xA;stored in the stack slot of the caller will differ upon the call to&#xA;boot_init_stack_canary. This will lead to a call to __stack_chk_fail()&#xA;then panic.&#xA;CVE-2023-53673:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: hci_event: call disconnect callback before deleting conn&#xA;&#xA;In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.&#xA;&#xA;ISO, L2CAP and SCO connections refer to the hci_conn without&#xA;hci_conn_get, so disconn_cfm must be called so they can clean up their&#xA;conn, otherwise use-after-free occurs.&#xA;&#xA;ISO:&#xA;==========================================================&#xA;iso_sock_connect:880: sk 00000000eabd6557&#xA;iso_connect_cis:356: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da&#xA;...&#xA;iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073&#xA;hci_dev_put:1487: hci0 orig refcnt 17&#xA;__iso_chan_add:214: conn 00000000b6251073&#xA;iso_sock_clear_timer:117: sock 00000000eabd6557 state 3&#xA;...&#xA;hci_rx_work:4085: hci0 Event packet&#xA;hci_event_packet:7601: hci0: event 0x0f&#xA;hci_cmd_status_evt:4346: hci0: opcode 0x0406&#xA;hci_cs_disconnect:2760: hci0: status 0x0c&#xA;hci_sent_cmd_data:3107: hci0 opcode 0x0406&#xA;hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560&#xA;hci_conn_unlink:1102: hci0: hcon 000000001696f1fd&#xA;hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2&#xA;hci_chan_list_flush:2780: hcon 000000001696f1fd&#xA;hci_dev_put:1487: hci0 orig refcnt 21&#xA;hci_dev_put:1487: hci0 orig refcnt 20&#xA;hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c&#xA;... &lt;no iso_* activity on sk/conn&gt; ...&#xA;iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000668&#xA;PGD 0 P4D 0&#xA;Oops: 0000 [#1] PREEMPT SMP PTI&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014&#xA;RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth&#xA;==========================================================&#xA;&#xA;L2CAP:&#xA;==================================================================&#xA;hci_cmd_status_evt:4359: hci0: opcode 0x0406&#xA;hci_cs_disconnect:2760: hci0: status 0x0c&#xA;hci_sent_cmd_data:3085: hci0 opcode 0x0406&#xA;hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585&#xA;hci_conn_unlink:1102: hci0: hcon ffff88800c999000&#xA;hci_chan_list_flush:2780: hcon ffff88800c999000&#xA;hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280&#xA;...&#xA;BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]&#xA;Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175&#xA;&#xA;CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G            E      6.4.0-rc4+ #2&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x5b/0x90&#xA; print_report+0xcf/0x670&#xA; ? __virt_addr_valid+0xf8/0x180&#xA; ? hci_send_acl+0x2d/0x540 [bluetooth]&#xA; kasan_report+0xa8/0xe0&#xA; ? hci_send_acl+0x2d/0x540 [bluetooth]&#xA; hci_send_acl+0x2d/0x540 [bluetooth]&#xA; ? __pfx___lock_acquire+0x10/0x10&#xA; l2cap_chan_send+0x1fd/0x1300 [bluetooth]&#xA; ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]&#xA; ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]&#xA; ? lock_release+0x1d5/0x3c0&#xA; ? mark_held_locks+0x1a/0x90&#xA; l2cap_sock_sendmsg+0x100/0x170 [bluetooth]&#xA; sock_write_iter+0x275/0x280&#xA; ? __pfx_sock_write_iter+0x10/0x10&#xA; ? __pfx___lock_acquire+0x10/0x10&#xA; do_iter_readv_writev+0x176/0x220&#xA; ? __pfx_do_iter_readv_writev+0x10/0x10&#xA; ? find_held_lock+0x83/0xa0&#xA; ? selinux_file_permission+0x13e/0x210&#xA; do_iter_write+0xda/0x340&#xA; vfs_writev+0x1b4/0x400&#xA; ? __pfx_vfs_writev+0x10/0x10&#xA; ? __seccomp_filter+0x112/0x750&#xA; ? populate_seccomp_data+0x182/0x220&#xA; ? __fget_light+0xdf/0x100&#xA; ? do_writev+0x19d/0x210&#xA; do_writev+0x19d/0x210&#xA; ? __pfx_do_writev+0x10/0x10&#xA; ? mark_held_locks+0x1a/0x90&#xA; do_syscall_64+0x60/0x90&#xA; ? lockdep_hardirqs_on_prepare+0x149/0x210&#xA; ? do_syscall_64+0x6c/0x90&#xA; ? lockdep_hardirqs_on_prepare+0x149/0x210&#xA; entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;RIP: 0033:0x7ff45cb23e64&#xA;Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89&#xA;RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014&#xA;RAX: ffffffffffffffda RBX: &#xA;---truncated---&#xA;CVE-2023-53520:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: Fix hci_suspend_sync crash&#xA;&#xA;If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier&#xA;may still be accessing it, it can cause the program to crash.&#xA;Here&#39;s the call trace:&#xA;  &lt;4&gt;[102152.653246] Call Trace:&#xA;  &lt;4&gt;[102152.653254]  hci_suspend_sync+0x109/0x301 [bluetooth]&#xA;  &lt;4&gt;[102152.653259]  hci_suspend_dev+0x78/0xcd [bluetooth]&#xA;  &lt;4&gt;[102152.653263]  hci_suspend_notifier+0x42/0x7a [bluetooth]&#xA;  &lt;4&gt;[102152.653268]  notifier_call_chain+0x43/0x6b&#xA;  &lt;4&gt;[102152.653271]  __blocking_notifier_call_chain+0x48/0x69&#xA;  &lt;4&gt;[102152.653273]  __pm_notifier_call_chain+0x22/0x39&#xA;  &lt;4&gt;[102152.653276]  pm_suspend+0x287/0x57c&#xA;  &lt;4&gt;[102152.653278]  state_store+0xae/0xe5&#xA;  &lt;4&gt;[102152.653281]  kernfs_fop_write+0x109/0x173&#xA;  &lt;4&gt;[102152.653284]  __vfs_write+0x16f/0x1a2&#xA;  &lt;4&gt;[102152.653287]  ? selinux_file_permission+0xca/0x16f&#xA;  &lt;4&gt;[102152.653289]  ? security_file_permission+0x36/0x109&#xA;  &lt;4&gt;[102152.653291]  vfs_write+0x114/0x21d&#xA;  &lt;4&gt;[102152.653293]  __x64_sys_write+0x7b/0xdb&#xA;  &lt;4&gt;[102152.653296]  do_syscall_64+0x59/0x194&#xA;  &lt;4&gt;[102152.653299]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1&#xA;&#xA;This patch holds the reference count of the hci_dev object while&#xA;processing it in hci_suspend_notifier to avoid potential crash&#xA;caused by the race condition.&#xA;CVE-2025-38734:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/smc: fix UAF on smcsk after smc_listen_out()&#xA;&#xA;BPF CI testing report a UAF issue:&#xA;&#xA;  [   16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003  0&#xA;  [   16.447134] #PF: supervisor read access in kernel mod  e&#xA;  [   16.447516] #PF: error_code(0x0000) - not-present pag  e&#xA;  [   16.447878] PGD 0 P4D   0&#xA;  [   16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT  I&#xA;  [   16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G           OE      6.13.0-rc3-g89e8a75fda73-dirty #4  2&#xA;  [   16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL  E&#xA;  [   16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201  4&#xA;  [   16.450201] Workqueue: smc_hs_wq smc_listen_wor  k&#xA;  [   16.450531] RIP: 0010:smc_listen_work+0xc02/0x159  0&#xA;  [   16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024  6&#xA;  [   16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030  0&#xA;  [   16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000  0&#xA;  [   16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000  5&#xA;  [   16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640  0&#xA;  [   16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092  0&#xA;  [   16.454996] FS:  0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000  0&#xA;  [   16.455557] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003  3&#xA;  [   16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef  0&#xA;  [   16.456459] PKRU: 5555555  4&#xA;  [   16.456654] Call Trace  :&#xA;  [   16.456832]  &lt;TASK  &gt;&#xA;  [   16.456989]  ? __die+0x23/0x7  0&#xA;  [   16.457215]  ? page_fault_oops+0x180/0x4c  0&#xA;  [   16.457508]  ? __lock_acquire+0x3e6/0x249  0&#xA;  [   16.457801]  ? exc_page_fault+0x68/0x20  0&#xA;  [   16.458080]  ? asm_exc_page_fault+0x26/0x3  0&#xA;  [   16.458389]  ? smc_listen_work+0xc02/0x159  0&#xA;  [   16.458689]  ? smc_listen_work+0xc02/0x159  0&#xA;  [   16.458987]  ? lock_is_held_type+0x8f/0x10  0&#xA;  [   16.459284]  process_one_work+0x1ea/0x6d  0&#xA;  [   16.459570]  worker_thread+0x1c3/0x38  0&#xA;  [   16.459839]  ? __pfx_worker_thread+0x10/0x1  0&#xA;  [   16.460144]  kthread+0xe0/0x11  0&#xA;  [   16.460372]  ? __pfx_kthread+0x10/0x1  0&#xA;  [   16.460640]  ret_from_fork+0x31/0x5  0&#xA;  [   16.460896]  ? __pfx_kthread+0x10/0x1  0&#xA;  [   16.461166]  ret_from_fork_asm+0x1a/0x3  0&#xA;  [   16.461453]  &lt;/TASK  &gt;&#xA;  [   16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)  ]&#xA;  [   16.462134] CR2: 000000000000003  0&#xA;  [   16.462380] ---[ end trace 0000000000000000 ]---&#xA;  [   16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590&#xA;&#xA;The direct cause of this issue is that after smc_listen_out_connected(),&#xA;newclcsock-&gt;sk may be NULL since it will releases the smcsk. Therefore,&#xA;if the application closes the socket immediately after accept,&#xA;newclcsock-&gt;sk can be NULL. A possible execution order could be as&#xA;follows:&#xA;&#xA;smc_listen_work                                 | userspace&#xA;-----------------------------------------------------------------&#xA;lock_sock(sk)                                   |&#xA;smc_listen_out_connected()                      |&#xA;| \- smc_listen_out                             |&#xA;|    | \- release_sock                          |&#xA;     | |- sk-&gt;sk_data_ready()                   |&#xA;                                                | fd = accept();&#xA;                                                | close(fd);&#xA;                                                |  \- socket-&gt;sk = NULL;&#xA;/* newclcsock-&gt;sk is NULL now */&#xA;SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-&gt;sk))&#xA;&#xA;Since smc_listen_out_connected() will not fail, simply swapping the order&#xA;of the code can easily fix this issue.&#xA;CVE-2025-39901:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: remove read access to debugfs files&#xA;&#xA;The &#39;command&#39; and &#39;netdev_ops&#39; debugfs files are a legacy debugging&#xA;interface supported by the i40e driver since its early days by commit&#xA;02e9c290814c (&#34;i40e: debugfs interface&#34;).&#xA;&#xA;Both of these debugfs files provide a read handler which is mostly useless,&#xA;and which is implemented with questionable logic. They both use a static&#xA;256 byte buffer which is initialized to the empty string. In the case of&#xA;the &#39;command&#39; file this buffer is literally never used and simply wastes&#xA;space. In the case of the &#39;netdev_ops&#39; file, the last command written is&#xA;saved here.&#xA;&#xA;On read, the files contents are presented as the name of the device&#xA;followed by a colon and then the contents of their respective static&#xA;buffer. For &#39;command&#39; this will always be &#34;&lt;device&gt;: &#34;. For &#39;netdev_ops&#39;,&#xA;this will be &#34;&lt;device&gt;: &lt;last command written&gt;&#34;. But note the buffer is&#xA;shared between all devices operated by this module. At best, it is mostly&#xA;meaningless information, and at worse it could be accessed simultaneously&#xA;as there doesn&#39;t appear to be any locking mechanism.&#xA;&#xA;We have also recently received multiple reports for both read functions&#xA;about their use of snprintf and potential overflow that could result in&#xA;reading arbitrary kernel memory. For the &#39;command&#39; file, this is definitely&#xA;impossible, since the static buffer is always zero and never written to.&#xA;For the &#39;netdev_ops&#39; file, it does appear to be possible, if the user&#xA;carefully crafts the command input, it will be copied into the buffer,&#xA;which could be large enough to cause snprintf to truncate, which then&#xA;causes the copy_to_user to read beyond the length of the buffer allocated&#xA;by kzalloc.&#xA;&#xA;A minimal fix would be to replace snprintf() with scnprintf() which would&#xA;cap the return to the number of bytes written, preventing an overflow. A&#xA;more involved fix would be to drop the mostly useless static buffers,&#xA;saving 512 bytes and modifying the read functions to stop needing those as&#xA;input.&#xA;&#xA;Instead, lets just completely drop the read access to these files. These&#xA;are debug interfaces exposed as part of debugfs, and I don&#39;t believe that&#xA;dropping read access will break any script, as the provided output is&#xA;pretty useless. You can find the netdev name through other more standard&#xA;interfaces, and the &#39;netdev_ops&#39; interface can easily result in garbage if&#xA;you issue simultaneous writes to multiple devices at once.&#xA;&#xA;In order to properly remove the i40e_dbg_netdev_ops_buf, we need to&#xA;refactor its write function to avoid using the static buffer. Instead, use&#xA;the same logic as the i40e_dbg_command_write, with an allocated buffer.&#xA;Update the code to use this instead of the static buffer, and ensure we&#xA;free the buffer on exit. This fixes simultaneous writes to &#39;netdev_ops&#39; on&#xA;multiple devices, and allows us to remove the now unused static buffer&#xA;along with removing the read access.&#xA;CVE-2025-40018:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvs: Defer ip_vs_ftp unregister during netns cleanup&#xA;&#xA;On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp&#xA;before connections with valid cp-&gt;app pointers are flushed, leading to a&#xA;use-after-free.&#xA;&#xA;Fix this by introducing a global `exiting_module` flag, set to true in&#xA;ip_vs_ftp_exit() before unregistering the pernet subsystem. In&#xA;__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns&#xA;cleanup (when exiting_module is false) and defer it to&#xA;__ip_vs_cleanup_batch(), which unregisters all apps after all connections&#xA;are flushed. If called during module exit, unregister ip_vs_ftp&#xA;immediately.&#xA;CVE-2025-38617:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/packet: fix a race in packet_set_ring() and packet_notifier()&#xA;&#xA;When packet_set_ring() releases po-&gt;bind_lock, another thread can&#xA;run packet_notifier() and process an NETDEV_UP event.&#xA;&#xA;This race and the fix are both similar to that of commit 15fe076edea7&#xA;(&#34;net/packet: fix a race in packet_bind() and packet_notifier()&#34;).&#xA;&#xA;There too the packet_notifier NETDEV_UP event managed to run while a&#xA;po-&gt;bind_lock critical section had to be temporarily released. And&#xA;the fix was similarly to temporarily set po-&gt;num to zero to keep&#xA;the socket unhooked until the lock is retaken.&#xA;&#xA;The po-&gt;bind_lock in packet_set_ring and packet_notifier precede the&#xA;introduction of git history.&#xA;CVE-2025-38618:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vsock: Do not allow binding to VMADDR_PORT_ANY&#xA;&#xA;It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can&#xA;cause a use-after-free when a connection is made to the bound socket.&#xA;The socket returned by accept() also has port VMADDR_PORT_ANY but is not&#xA;on the list of unbound sockets. Binding it will result in an extra&#xA;refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep&#xA;the binding until socket destruction).&#xA;&#xA;Modify the check in __vsock_bind_connectible() to also prevent binding&#xA;to VMADDR_PORT_ANY.&#xA;CVE-2025-38664:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ice: Fix a null pointer dereference in ice_copy_and_init_pkg()&#xA;&#xA;Add check for the return value of devm_kmemdup()&#xA;to prevent potential null pointer dereference.&#xA;CVE-2025-38572:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: reject malicious packets in ipv6_gso_segment()&#xA;&#xA;syzbot was able to craft a packet with very long IPv6 extension headers&#xA;leading to an overflow of skb-&gt;transport_header.&#xA;&#xA;This 16bit field has a limited range.&#xA;&#xA;Add skb_reset_transport_header_careful() helper and use it&#xA;from ipv6_gso_segment()&#xA;&#xA;WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]&#xA;WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025&#xA; RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]&#xA; RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53&#xA;  nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110&#xA;  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53&#xA;  __skb_gso_segment+0x342/0x510 net/core/gso.c:124&#xA;  skb_gso_segment include/net/gso.h:83 [inline]&#xA;  validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950&#xA;  validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000&#xA;  sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329&#xA;  __dev_xmit_skb net/core/dev.c:4102 [inline]&#xA;  __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679&#xA;CVE-2025-39851:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vxlan: Fix NPD when refreshing an FDB entry with a nexthop object&#xA;&#xA;VXLAN FDB entries can point to either a remote destination or an FDB&#xA;nexthop group. The latter is usually used in EVPN deployments where&#xA;learning is disabled.&#xA;&#xA;However, when learning is enabled, an incoming packet might try to&#xA;refresh an FDB entry that points to an FDB nexthop group and therefore&#xA;does not have a remote. Such packets should be dropped, but they are&#xA;only dropped after dereferencing the non-existent remote, resulting in a&#xA;NPD [1] which can be reproduced using [2].&#xA;&#xA;Fix by dropping such packets earlier. Remove the misleading comment from&#xA;first_remote_rcu().&#xA;&#xA;[1]&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[...]&#xA;CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014&#xA;RIP: 0010:vxlan_snoop+0x98/0x1e0&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; vxlan_encap_bypass+0x209/0x240&#xA; encap_bypass_if_local+0xb1/0x100&#xA; vxlan_xmit_one+0x1375/0x17e0&#xA; vxlan_xmit+0x6b4/0x15f0&#xA; dev_hard_start_xmit+0x5d/0x1c0&#xA; __dev_queue_xmit+0x246/0xfd0&#xA; packet_sendmsg+0x113a/0x1850&#xA; __sock_sendmsg+0x38/0x70&#xA; __sys_sendto+0x126/0x180&#xA; __x64_sys_sendto+0x24/0x30&#xA; do_syscall_64+0xa4/0x260&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;[2]&#xA; #!/bin/bash&#xA;&#xA; ip address add 192.0.2.1/32 dev lo&#xA; ip address add 192.0.2.2/32 dev lo&#xA;&#xA; ip nexthop add id 1 via 192.0.2.3 fdb&#xA; ip nexthop add id 10 group 1 fdb&#xA;&#xA; ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass&#xA; ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning&#xA;&#xA; bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020&#xA; bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10&#xA;&#xA; mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q&#xA;CVE-2025-40102:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: arm64: Prevent access to vCPU events before init&#xA;&#xA;Another day, another syzkaller bug. KVM erroneously allows userspace to&#xA;pend vCPU events for a vCPU that hasn&#39;t been initialized yet, leading to&#xA;KVM interpreting a bunch of uninitialized garbage for routing /&#xA;injecting the exception.&#xA;&#xA;In one case the injection code and the hyp disagree on whether the vCPU&#xA;has a 32bit EL1 and put the vCPU into an illegal mode for AArch64,&#xA;tripping the BUG() in exception_target_el() during the next injection:&#xA;&#xA;  kernel BUG at arch/arm64/kvm/inject_fault.c:40!&#xA;  Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP&#xA;  CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT&#xA;  Hardware name: linux,dummy-virt (DT)&#xA;  pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)&#xA;  pc : exception_target_el+0x88/0x8c&#xA;  lr : pend_serror_exception+0x18/0x13c&#xA;  sp : ffff800082f03a10&#xA;  x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000&#xA;  x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000&#xA;  x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004&#xA;  x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000&#xA;  x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0&#xA;  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000&#xA;  x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000&#xA;  x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000&#xA;  x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000&#xA;  x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20&#xA;  Call trace:&#xA;   exception_target_el+0x88/0x8c (P)&#xA;   kvm_inject_serror_esr+0x40/0x3b4&#xA;   __kvm_arm_vcpu_set_events+0xf0/0x100&#xA;   kvm_arch_vcpu_ioctl+0x180/0x9d4&#xA;   kvm_vcpu_ioctl+0x60c/0x9f4&#xA;   __arm64_sys_ioctl+0xac/0x104&#xA;   invoke_syscall+0x48/0x110&#xA;   el0_svc_common.constprop.0+0x40/0xe0&#xA;   do_el0_svc+0x1c/0x28&#xA;   el0_svc+0x34/0xf0&#xA;   el0t_64_sync_handler+0xa0/0xe4&#xA;   el0t_64_sync+0x198/0x19c&#xA;  Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)&#xA;&#xA;Reject the ioctls outright as no sane VMM would call these before&#xA;KVM_ARM_VCPU_INIT anyway. Even if it did the exception would&#39;ve been&#xA;thrown away by the eventual reset of the vCPU&#39;s state.&#xA;CVE-2025-37776:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix use-after-free in smb_break_all_levII_oplock()&#xA;&#xA;There is a room in smb_break_all_levII_oplock that can cause racy issues&#xA;when unlocking in the middle of the loop. This patch use read lock&#xA;to protect whole loop.&#xA;CVE-2025-38561:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix Preauh_HashValue race condition&#xA;&#xA;If client send multiple session setup requests to ksmbd,&#xA;Preauh_HashValue race condition could happen.&#xA;There is no need to free sess-&gt;Preauh_HashValue at session setup phase.&#xA;It can be freed together with session at connection termination phase.&#xA;CVE-2024-57907:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: adc: rockchip_saradc: fix information leak in triggered buffer&#xA;&#xA;The &#39;data&#39; local struct is used to push data to user space from a&#xA;triggered buffer, but it does not set values for inactive channels, as&#xA;it only uses iio_for_each_active_channel() to assign new values.&#xA;&#xA;Initialize the struct to zero before using it to avoid pushing&#xA;uninitialized information to userspace.&#xA;CVE-2025-21905:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: iwlwifi: limit printed string from FW file&#xA;&#xA;There&#39;s no guarantee here that the file is always with a&#xA;NUL-termination, so reading the string may read beyond the&#xA;end of the TLV. If that&#39;s the last TLV in the file, it can&#xA;perhaps even read beyond the end of the file buffer.&#xA;&#xA;Fix that by limiting the print format to the size of the&#xA;buffer we have.&#xA;CVE-2025-38729:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Validate UAC3 power domain descriptors, too&#xA;&#xA;UAC3 power domain descriptors need to be verified with its variable&#xA;bLength for avoiding the unexpected OOB accesses by malicious&#xA;firmware, too.&#xA;CVE-2025-38706:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()&#xA;&#xA;snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will&#xA;leads to null pointer dereference.&#xA;This was reproduced with topology loading and marking a link as ignore&#xA;due to missing hardware component on the system.&#xA;On module removal the soc_tplg_remove_link() would call&#xA;snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,&#xA;no runtime was created.&#xA;CVE-2024-58034:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()&#xA;&#xA;As of_find_node_by_name() release the reference of the argument device&#xA;node, tegra_emc_find_node_by_ram_code() releases some device nodes while&#xA;still in use, resulting in possible UAFs. According to the bindings and&#xA;the in-tree DTS files, the &#34;emc-tables&#34; node is always device&#39;s child&#xA;node with the property &#34;nvidia,use-ram-code&#34;, and the &#34;lpddr2&#34; node is a&#xA;child of the &#34;emc-tables&#34; node. Thus utilize the&#xA;for_each_child_of_node() macro and of_get_child_by_name() instead of&#xA;of_find_node_by_name() to simplify the code.&#xA;&#xA;This bug was found by an experimental verification tool that I am&#xA;developing.&#xA;&#xA;[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]&#xA;CVE-2025-22022:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: xhci: Apply the link chain quirk on NEC isoc endpoints&#xA;&#xA;Two clearly different specimens of NEC uPD720200 (one with start/stop&#xA;bug, one without) were seen to cause IOMMU faults after some Missed&#xA;Service Errors. Faulting address is immediately after a transfer ring&#xA;segment and patched dynamic debug messages revealed that the MSE was&#xA;received when waiting for a TD near the end of that segment:&#xA;&#xA;[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0&#xA;[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]&#xA;[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]&#xA;&#xA;It gets even funnier if the next page is a ring segment accessible to&#xA;the HC. Below, it reports MSE in segment at ff1e8000, plows through a&#xA;zero-filled page at ff1e9000 and starts reporting events for TRBs in&#xA;page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.&#xA;&#xA;[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0&#xA;[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0&#xA;[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint&#xA;[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.&#xA;[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint&#xA;[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31&#xA;[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820&#xA;[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint&#xA;[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31&#xA;[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820&#xA;&#xA;At some point completion events change from Isoch Buffer Overrun to&#xA;Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.&#xA;&#xA;[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13&#xA;[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820&#xA;[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13&#xA;[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820&#xA;[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2&#xA;&#xA;It&#39;s possible that data from the isochronous device were written to&#xA;random buffers of pending TDs on other endpoints (either IN or OUT),&#xA;other devices or even other HCs in the same IOMMU domain.&#xA;&#xA;Lastly, an error from a different USB device on another HC. Was it&#xA;caused by the above? I don&#39;t know, but it may have been. The disk&#xA;was working without any other issues and generated PCIe traffic to&#xA;starve the NEC of upstream BW and trigger those MSEs. The two HCs&#xA;shared one x1 slot by means of a commercial &#34;PCIe splitter&#34; board.&#xA;&#xA;[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd&#xA;[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s&#xA;[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00&#xA;[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0&#xA;&#xA;Fortunately, it appears that this ridiculous bug is avoided by setting&#xA;the chain bit of Link TRBs on isochronous rings. Other ancient HCs are&#xA;known which also expect the bit to be set and they ignore Link TRBs if&#xA;it&#39;s not. Reportedly, 0.95 spec guaranteed that the bit is set.&#xA;&#xA;The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports&#xA;tens of MSEs per second and runs into the bug within seconds. Chaining&#xA;Link TRBs allows the same workload to run for many minutes, many times.&#xA;&#xA;No ne&#xA;---truncated---&#xA;CVE-2025-37927:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid&#xA;&#xA;There is a string parsing logic error which can lead to an overflow of hid&#xA;or uid buffers. Comparing ACPIID_LEN against a total string length doesn&#39;t&#xA;take into account the lengths of individual hid and uid buffers so the&#xA;check is insufficient in some cases. For example if the length of hid&#xA;string is 4 and the length of the uid string is 260, the length of str&#xA;will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer&#xA;which size is 256.&#xA;&#xA;The same applies to the hid string with length 13 and uid string with&#xA;length 250.&#xA;&#xA;Check the length of hid and uid strings separately to prevent&#xA;buffer overflow.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2025-38250:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: hci_core: Fix use-after-free in vhci_flush()&#xA;&#xA;syzbot reported use-after-free in vhci_flush() without repro. [0]&#xA;&#xA;From the splat, a thread close()d a vhci file descriptor while&#xA;its device was being used by iotcl() on another thread.&#xA;&#xA;Once the last fd refcnt is released, vhci_release() calls&#xA;hci_unregister_dev(), hci_free_dev(), and kfree() for struct&#xA;vhci_data, which is set to hci_dev-&gt;dev-&gt;driver_data.&#xA;&#xA;The problem is that there is no synchronisation after unlinking&#xA;hdev from hci_dev_list in hci_unregister_dev().  There might be&#xA;another thread still accessing the hdev which was fetched before&#xA;the unlink operation.&#xA;&#xA;We can use SRCU for such synchronisation.&#xA;&#xA;Let&#39;s run hci_dev_reset() under SRCU and wait for its completion&#xA;in hci_unregister_dev().&#xA;&#xA;Another option would be to restore hci_dev-&gt;destruct(), which was&#xA;removed in commit 587ae086f6e4 (&#34;Bluetooth: Remove unused&#xA;hci-destruct cb&#34;).  However, this would not be a good solution, as&#xA;we should not run hci_unregister_dev() while there are in-flight&#xA;ioctl() requests, which could lead to another data-race KCSAN splat.&#xA;&#xA;Note that other drivers seem to have the same problem, for exmaple,&#xA;virtbt_remove().&#xA;&#xA;[0]:&#xA;BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]&#xA;BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937&#xA;Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718&#xA;&#xA;CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:408 [inline]&#xA; print_report+0xd2/0x2b0 mm/kasan/report.c:521&#xA; kasan_report+0x118/0x150 mm/kasan/report.c:634&#xA; skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]&#xA; skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937&#xA; skb_queue_purge include/linux/skbuff.h:3368 [inline]&#xA; vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69&#xA; hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]&#xA; hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592&#xA; sock_do_ioctl+0xd9/0x300 net/socket.c:1190&#xA; sock_ioctl+0x576/0x790 net/socket.c:1311&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA; __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7fcf5b98e929&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929&#xA;RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009&#xA;RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 6535:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x3e/0x80 mm/kasan/common.c:68&#xA; poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA; __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394&#xA; kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA; __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359&#xA; kmalloc_noprof include/linux/slab.h:905 [inline]&#xA; kzalloc_noprof include/linux/slab.h:1039 [inline]&#xA; vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635&#xA; misc_open+0x2bc/0x330 drivers/char/misc.c:161&#xA; chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414&#xA; do_dentry_open+0xdf0/0x1970 fs/open.c:964&#xA; vfs_open+0x3b/0x340 fs/open.c:1094&#xA; do_open fs/namei.c:3887 [inline]&#xA; path_openat+0x2ee5/0x3830 fs/name&#xA;---truncated---&#xA;CVE-2025-38201:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX&#xA;&#xA;Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()&#xA;when resizing hashtable because __GFP_NOWARN is unset.&#xA;&#xA;Similar to:&#xA;&#xA;  b541ba7d1f5a (&#34;netfilter: conntrack: clamp maximum hashtable size to INT_MAX&#34;)&#xA;CVE-2025-38022:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/core: Fix &#34;KASAN: slab-use-after-free Read in ib_register_device&#34; problem&#xA;&#xA;Call Trace:&#xA;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:408 [inline]&#xA; print_report+0xc3/0x670 mm/kasan/report.c:521&#xA; kasan_report+0xe0/0x110 mm/kasan/report.c:634&#xA; strlen+0x93/0xa0 lib/string.c:420&#xA; __fortify_strlen include/linux/fortify-string.h:268 [inline]&#xA; get_kobj_path_length lib/kobject.c:118 [inline]&#xA; kobject_get_path+0x3f/0x2a0 lib/kobject.c:158&#xA; kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545&#xA; ib_register_device drivers/infiniband/core/device.c:1472 [inline]&#xA; ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393&#xA; rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552&#xA; rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550&#xA; rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225&#xA; nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796&#xA; rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195&#xA; rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]&#xA; netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339&#xA; netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg net/socket.c:727 [inline]&#xA; ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566&#xA; ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620&#xA; __sys_sendmsg+0x16d/0x220 net/socket.c:2652&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;This problem is similar to the problem that the&#xA;commit 1d6a9e7449e2 (&#34;RDMA/core: Fix use-after-free when rename device name&#34;)&#xA;fixes.&#xA;&#xA;The root cause is: the function ib_device_rename() renames the name with&#xA;lock. But in the function kobject_uevent(), this name is accessed without&#xA;lock protection at the same time.&#xA;&#xA;The solution is to add the lock protection when this name is accessed in&#xA;the function kobject_uevent().&#xA;CVE-2025-37789:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: openvswitch: fix nested key length validation in the set() action&#xA;&#xA;It&#39;s not safe to access nla_len(ovs_key) if the data is smaller than&#xA;the netlink header.  Check that the attribute is OK first.&#xA;CVE-2025-37749:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ppp: Add bound checking for skb data on ppp_sync_txmung&#xA;&#xA;Ensure we have enough data in linear buffer from skb before accessing&#xA;initial bytes. This prevents potential out-of-bounds accesses&#xA;when processing short packets.&#xA;&#xA;When ppp_sync_txmung receives an incoming package with an empty&#xA;payload:&#xA;(remote) gef➤  p *(struct pppoe_hdr *) (skb-&gt;head + skb-&gt;network_header)&#xA;$18 = {&#xA;&#x9;type = 0x1,&#xA;&#x9;ver = 0x1,&#xA;&#x9;code = 0x0,&#xA;&#x9;sid = 0x2,&#xA;        length = 0x0,&#xA;&#x9;tag = 0xffff8880371cdb96&#xA;}&#xA;&#xA;from the skb struct (trimmed)&#xA;      tail = 0x16,&#xA;      end = 0x140,&#xA;      head = 0xffff88803346f400 &#34;4&#34;,&#xA;      data = 0xffff88803346f416 &#34;:\377&#34;,&#xA;      truesize = 0x380,&#xA;      len = 0x0,&#xA;      data_len = 0x0,&#xA;      mac_len = 0xe,&#xA;      hdr_len = 0x0,&#xA;&#xA;it is not safe to access data[2].&#xA;&#xA;[[email protected]: fixed subj typo]&#xA;CVE-2025-22020:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove&#xA;&#xA;This fixes the following crash:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]&#xA;Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241&#xA;&#xA;CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G            E      6.14.0-rc6+ #1&#xA;Tainted: [E]=UNSIGNED_MODULE&#xA;Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024&#xA;Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x51/0x70&#xA; print_address_description.constprop.0+0x27/0x320&#xA; ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]&#xA; print_report+0x3e/0x70&#xA; kasan_report+0xab/0xe0&#xA; ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]&#xA; rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]&#xA; ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]&#xA; ? __pfx___schedule+0x10/0x10&#xA; ? kick_pool+0x3b/0x270&#xA; process_one_work+0x357/0x660&#xA; worker_thread+0x390/0x4c0&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0x190/0x1d0&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x2d/0x50&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 161446:&#xA; kasan_save_stack+0x20/0x40&#xA; kasan_save_track+0x10/0x30&#xA; __kasan_kmalloc+0x7b/0x90&#xA; __kmalloc_noprof+0x1a7/0x470&#xA; memstick_alloc_host+0x1f/0xe0 [memstick]&#xA; rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]&#xA; platform_probe+0x60/0xe0&#xA; call_driver_probe+0x35/0x120&#xA; really_probe+0x123/0x410&#xA; __driver_probe_device+0xc7/0x1e0&#xA; driver_probe_device+0x49/0xf0&#xA; __device_attach_driver+0xc6/0x160&#xA; bus_for_each_drv+0xe4/0x160&#xA; __device_attach+0x13a/0x2b0&#xA; bus_probe_device+0xbd/0xd0&#xA; device_add+0x4a5/0x760&#xA; platform_device_add+0x189/0x370&#xA; mfd_add_device+0x587/0x5e0&#xA; mfd_add_devices+0xb1/0x130&#xA; rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]&#xA; usb_probe_interface+0x15c/0x460&#xA; call_driver_probe+0x35/0x120&#xA; really_probe+0x123/0x410&#xA; __driver_probe_device+0xc7/0x1e0&#xA; driver_probe_device+0x49/0xf0&#xA; __device_attach_driver+0xc6/0x160&#xA; bus_for_each_drv+0xe4/0x160&#xA; __device_attach+0x13a/0x2b0&#xA; rebind_marked_interfaces.isra.0+0xcc/0x110&#xA; usb_reset_device+0x352/0x410&#xA; usbdev_do_ioctl+0xe5c/0x1860&#xA; usbdev_ioctl+0xa/0x20&#xA; __x64_sys_ioctl+0xc5/0xf0&#xA; do_syscall_64+0x59/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Freed by task 161506:&#xA; kasan_save_stack+0x20/0x40&#xA; kasan_save_track+0x10/0x30&#xA; kasan_save_free_info+0x36/0x60&#xA; __kasan_slab_free+0x34/0x50&#xA; kfree+0x1fd/0x3b0&#xA; device_release+0x56/0xf0&#xA; kobject_cleanup+0x73/0x1c0&#xA; rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]&#xA; platform_remove+0x2f/0x50&#xA; device_release_driver_internal+0x24b/0x2e0&#xA; bus_remove_device+0x124/0x1d0&#xA; device_del+0x239/0x530&#xA; platform_device_del.part.0+0x19/0xe0&#xA; platform_device_unregister+0x1c/0x40&#xA; mfd_remove_devices_fn+0x167/0x170&#xA; device_for_each_child_reverse+0xc9/0x130&#xA; mfd_remove_devices+0x6e/0xa0&#xA; rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]&#xA; usb_unbind_interface+0xf3/0x3f0&#xA; device_release_driver_internal+0x24b/0x2e0&#xA; proc_disconnect_claim+0x13d/0x220&#xA; usbdev_do_ioctl+0xb5e/0x1860&#xA; usbdev_ioctl+0xa/0x20&#xA; __x64_sys_ioctl+0xc5/0xf0&#xA; do_syscall_64+0x59/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Last potentially related work creation:&#xA; kasan_save_stack+0x20/0x40&#xA; kasan_record_aux_stack+0x85/0x90&#xA; insert_work+0x29/0x100&#xA; __queue_work+0x34a/0x540&#xA; call_timer_fn+0x2a/0x160&#xA; expire_timers+0x5f/0x1f0&#xA; __run_timer_base.part.0+0x1b6/0x1e0&#xA; run_timer_softirq+0x8b/0xe0&#xA; handle_softirqs+0xf9/0x360&#xA; __irq_exit_rcu+0x114/0x130&#xA; sysvec_apic_timer_interrupt+0x72/0x90&#xA; asm_sysvec_apic_timer_interrupt+0x16/0x20&#xA;&#xA;Second to last potentially related work creation:&#xA; kasan_save_stack+0x20/0x40&#xA; kasan_record_aux_stack+0x85/0x90&#xA; insert_work+0x29/0x100&#xA; __queue_work+0x34a/0x540&#xA; call_timer_fn+0x2a/0x160&#xA; expire_timers+0x5f/0x1f0&#xA; __run_timer_base.part.0+0x1b6/0x1e0&#xA; run_timer_softirq+0x8b/0xe0&#xA; handle_softirqs+0xf9/0x&#xA;---truncated---&#xA;CVE-2025-22083:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint&#xA;&#xA;If vhost_scsi_set_endpoint is called multiple times without a&#xA;vhost_scsi_clear_endpoint between them, we can hit multiple bugs&#xA;found by Haoran Zhang:&#xA;&#xA;1. Use-after-free when no tpgs are found:&#xA;&#xA;This fixes a use after free that occurs when vhost_scsi_set_endpoint is&#xA;called more than once and calls after the first call do not find any&#xA;tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds&#xA;tpgs to add to the vs_tpg array match=true, so we will do:&#xA;&#xA;vhost_vq_set_backend(vq, vs_tpg);&#xA;...&#xA;&#xA;kfree(vs-&gt;vs_tpg);&#xA;vs-&gt;vs_tpg = vs_tpg;&#xA;&#xA;If vhost_scsi_set_endpoint is called again and no tpgs are found&#xA;match=false so we skip the vhost_vq_set_backend call leaving the&#xA;pointer to the vs_tpg we then free via:&#xA;&#xA;kfree(vs-&gt;vs_tpg);&#xA;vs-&gt;vs_tpg = vs_tpg;&#xA;&#xA;If a scsi request is then sent we do:&#xA;&#xA;vhost_scsi_handle_vq -&gt; vhost_scsi_get_req -&gt; vhost_vq_get_backend&#xA;&#xA;which sees the vs_tpg we just did a kfree on.&#xA;&#xA;2. Tpg dir removal hang:&#xA;&#xA;This patch fixes an issue where we cannot remove a LIO/target layer&#xA;tpg (and structs above it like the target) dir due to the refcount&#xA;dropping to -1.&#xA;&#xA;The problem is that if vhost_scsi_set_endpoint detects a tpg is already&#xA;in the vs-&gt;vs_tpg array or if the tpg has been removed so&#xA;target_depend_item fails, the undepend goto handler will do&#xA;target_undepend_item on all tpgs in the vs_tpg array dropping their&#xA;refcount to 0. At this time vs_tpg contains both the tpgs we have added&#xA;in the current vhost_scsi_set_endpoint call as well as tpgs we added in&#xA;previous calls which are also in vs-&gt;vs_tpg.&#xA;&#xA;Later, when vhost_scsi_clear_endpoint runs it will do&#xA;target_undepend_item on all the tpgs in the vs-&gt;vs_tpg which will drop&#xA;their refcount to -1. Userspace will then not be able to remove the tpg&#xA;and will hang when it tries to do rmdir on the tpg dir.&#xA;&#xA;3. Tpg leak:&#xA;&#xA;This fixes a bug where we can leak tpgs and cause them to be&#xA;un-removable because the target name is overwritten when&#xA;vhost_scsi_set_endpoint is called multiple times but with different&#xA;target names.&#xA;&#xA;The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup&#xA;a vhost-scsi device to target/tpg mapping, then calls&#xA;VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we&#xA;haven&#39;t seen before (target1 has tpg1 but target2 has tpg2). When this&#xA;happens we don&#39;t teardown the old target tpg mapping and just overwrite&#xA;the target name and the vs-&gt;vs_tpg array. Later when we do&#xA;vhost_scsi_clear_endpoint, we are passed in either target1 or target2&#39;s&#xA;name and we will only match that target&#39;s tpgs when we loop over the&#xA;vs-&gt;vs_tpg. We will then return from the function without doing&#xA;target_undepend_item on the tpgs.&#xA;&#xA;Because of all these bugs, it looks like being able to call&#xA;vhost_scsi_set_endpoint multiple times was never supported. The major&#xA;user, QEMU, already has checks to prevent this use case. So to fix the&#xA;issues, this patch prevents vhost_scsi_set_endpoint from being called&#xA;if it&#39;s already successfully added tpgs. To add, remove or change the&#xA;tpg config or target name, you must do a vhost_scsi_clear_endpoint&#xA;first.&#xA;CVE-2025-23158:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: venus: hfi: add check to handle incorrect queue size&#xA;&#xA;qsize represents size of shared queued between driver and video&#xA;firmware. Firmware can modify this value to an invalid large value. In&#xA;such situation, empty_space will be bigger than the space actually&#xA;available. Since new_wr_idx is not checked, so the following code will&#xA;result in an OOB write.&#xA;...&#xA;qsize = qhdr-&gt;q_size&#xA;&#xA;if (wr_idx &gt;= rd_idx)&#xA; empty_space = qsize - (wr_idx - rd_idx)&#xA;....&#xA;if (new_wr_idx &lt; qsize) {&#xA; memcpy(wr_ptr, packet, dwords &lt;&lt; 2) --&gt; OOB write&#xA;&#xA;Add check to ensure qsize is within the allocated size while&#xA;reading and writing packets into the queue.&#xA;CVE-2025-39994:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: tuner: xc5000: Fix use-after-free in xc5000_release&#xA;&#xA;The original code uses cancel_delayed_work() in xc5000_release(), which&#xA;does not guarantee that the delayed work item timer_sleep has fully&#xA;completed if it was already running. This leads to use-after-free scenarios&#xA;where xc5000_release() may free the xc5000_priv while timer_sleep is still&#xA;active and attempts to dereference the xc5000_priv.&#xA;&#xA;A typical race condition is illustrated below:&#xA;&#xA;CPU 0 (release thread)                 | CPU 1 (delayed work callback)&#xA;xc5000_release()                       | xc5000_do_timer_sleep()&#xA;  cancel_delayed_work()                |&#xA;  hybrid_tuner_release_state(priv)     |&#xA;    kfree(priv)                        |&#xA;                                       |   priv = container_of() // UAF&#xA;&#xA;Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure&#xA;that the timer_sleep is properly canceled before the xc5000_priv memory&#xA;is deallocated.&#xA;&#xA;A deadlock concern was considered: xc5000_release() is called in a process&#xA;context and is not holding any locks that the timer_sleep work item might&#xA;also need. Therefore, the use of the _sync() variant is safe here.&#xA;&#xA;This bug was initially identified through static analysis.&#xA;&#xA;[hverkuil: fix typo in Subject: tunner -&gt; tuner]&#xA;CVE-2024-58007:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;soc: qcom: socinfo: Avoid out of bounds read of serial number&#xA;&#xA;On MSM8916 devices, the serial number exposed in sysfs is constant and does&#xA;not change across individual devices. It&#39;s always:&#xA;&#xA;  db410c:/sys/devices/soc0$ cat serial_number&#xA;  2644893864&#xA;&#xA;The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not&#xA;have support for the serial_num field in the socinfo struct. There is an&#xA;existing check to avoid exposing the serial number in that case, but it&#39;s&#xA;not correct: When checking the item_size returned by SMEM, we need to make&#xA;sure the *end* of the serial_num is within bounds, instead of comparing&#xA;with the *start* offset. The serial_number currently exposed on MSM8916&#xA;devices is just an out of bounds read of whatever comes after the socinfo&#xA;struct in SMEM.&#xA;&#xA;Fix this by changing offsetof() to offsetofend(), so that the size of the&#xA;field is also taken into account.&#xA;CVE-2022-49470:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event&#xA;&#xA;We should not access skb buffer data anymore after hci_recv_frame was&#xA;called.&#xA;&#xA;[   39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0&#xA;[   39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker&#xA;[   39.634962] Call trace:&#xA;[   39.634974]  dump_backtrace+0x0/0x3b8&#xA;[   39.634999]  show_stack+0x20/0x2c&#xA;[   39.635016]  dump_stack_lvl+0x60/0x78&#xA;[   39.635040]  print_address_description+0x70/0x2f0&#xA;[   39.635062]  kasan_report+0x154/0x194&#xA;[   39.635079]  __asan_report_load1_noabort+0x44/0x50&#xA;[   39.635099]  btmtksdio_recv_event+0x1b0/0x1c4&#xA;[   39.635129]  btmtksdio_txrx_work+0x6cc/0xac4&#xA;[   39.635157]  process_one_work+0x560/0xc5c&#xA;[   39.635177]  worker_thread+0x7ec/0xcc0&#xA;[   39.635195]  kthread+0x2d0/0x3d0&#xA;[   39.635215]  ret_from_fork+0x10/0x20&#xA;[   39.635247] Allocated by task 0:&#xA;[   39.635260] (stack is not available)&#xA;[   39.635281] Freed by task 2392:&#xA;[   39.635295]  kasan_save_stack+0x38/0x68&#xA;[   39.635319]  kasan_set_track+0x28/0x3c&#xA;[   39.635338]  kasan_set_free_info+0x28/0x4c&#xA;[   39.635357]  ____kasan_slab_free+0x104/0x150&#xA;[   39.635374]  __kasan_slab_free+0x18/0x28&#xA;[   39.635391]  slab_free_freelist_hook+0x114/0x248&#xA;[   39.635410]  kfree+0xf8/0x2b4&#xA;[   39.635427]  skb_free_head+0x58/0x98&#xA;[   39.635447]  skb_release_data+0x2f4/0x410&#xA;[   39.635464]  skb_release_all+0x50/0x60&#xA;[   39.635481]  kfree_skb+0xc8/0x25c&#xA;[   39.635498]  hci_event_packet+0x894/0xca4 [bluetooth]&#xA;[   39.635721]  hci_rx_work+0x1c8/0x68c [bluetooth]&#xA;[   39.635925]  process_one_work+0x560/0xc5c&#xA;[   39.635951]  worker_thread+0x7ec/0xcc0&#xA;[   39.635970]  kthread+0x2d0/0x3d0&#xA;[   39.635990]  ret_from_fork+0x10/0x20&#xA;[   39.636021] The buggy address belongs to the object at ffffff80cf28a600&#xA;                which belongs to the cache kmalloc-512 of size 512&#xA;[   39.636039] The buggy address is located 13 bytes inside of&#xA;                512-byte region [ffffff80cf28a600, ffffff80cf28a800)&#xA;CVE-2025-37994:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: ucsi: displayport: Fix NULL pointer access&#xA;&#xA;This patch ensures that the UCSI driver waits for all pending tasks in the&#xA;ucsi_displayport_work workqueue to finish executing before proceeding with&#xA;the partner removal.&#xA;CVE-2025-22107:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()&#xA;&#xA;There are actually 2 problems:&#xA;- deleting the last element doesn&#39;t require the memmove of elements&#xA;  [i + 1, end) over it. Actually, element i+1 is out of bounds.&#xA;- The memmove itself should move size - i - 1 elements, because the last&#xA;  element is out of bounds.&#xA;&#xA;The out-of-bounds element still remains out of bounds after being&#xA;accessed, so the problem is only that we touch it, not that it becomes&#xA;in active use. But I suppose it can lead to issues if the out-of-bounds&#xA;element is part of an unmapped page.&#xA;CVE-2025-21945:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix use-after-free in smb2_lock&#xA;&#xA;If smb_lock-&gt;zero_len has value, -&gt;llist of smb_lock is not delete and&#xA;flock is old one. It will cause use-after-free on error handling&#xA;routine.&#xA;CVE-2025-37899:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix use-after-free in session logoff&#xA;&#xA;The sess-&gt;user object can currently be in use by another thread, for&#xA;example if another connection has sent a session setup request to&#xA;bind to the session being free&#39;d. The handler for that connection could&#xA;be in the smb2_sess_setup function which makes use of sess-&gt;user.&#xA;CVE-2025-40139:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().&#xA;&#xA;smc_clc_prfx_set() is called during connect() and not under RCU&#xA;nor RTNL.&#xA;&#xA;Using sk_dst_get(sk)-&gt;dev could trigger UAF.&#xA;&#xA;Let&#39;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()&#xA;after kernel_getsockname().&#xA;&#xA;Note that the returned value of smc_clc_prfx_set() is not used&#xA;in the caller.&#xA;&#xA;While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()&#xA;not to touch dst there.&#xA;CVE-2025-37786:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: dsa: free routing table on probe failure&#xA;&#xA;If complete = true in dsa_tree_setup(), it means that we are the last&#xA;switch of the tree which is successfully probing, and we should be&#xA;setting up all switches from our probe path.&#xA;&#xA;After &#34;complete&#34; becomes true, dsa_tree_setup_cpu_ports() or any&#xA;subsequent function may fail. If that happens, the entire tree setup is&#xA;in limbo: the first N-1 switches have successfully finished probing&#xA;(doing nothing but having allocated persistent memory in the tree&#39;s&#xA;dst-&gt;ports, and maybe dst-&gt;rtable), and switch N failed to probe, ending&#xA;the tree setup process before anything is tangible from the user&#39;s PoV.&#xA;&#xA;If switch N fails to probe, its memory (ports) will be freed and removed&#xA;from dst-&gt;ports. However, the dst-&gt;rtable elements pointing to its ports,&#xA;as created by dsa_link_touch(), will remain there, and will lead to&#xA;use-after-free if dereferenced.&#xA;&#xA;If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely&#xA;possible because that is where ds-&gt;ops-&gt;setup() is, we get a kasan&#xA;report like this:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568&#xA;Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42&#xA;&#xA;Call trace:&#xA; __asan_report_load8_noabort+0x20/0x30&#xA; mv88e6xxx_setup_upstream_port+0x240/0x568&#xA; mv88e6xxx_setup+0xebc/0x1eb0&#xA; dsa_register_switch+0x1af4/0x2ae0&#xA; mv88e6xxx_register_switch+0x1b8/0x2a8&#xA; mv88e6xxx_probe+0xc4c/0xf60&#xA; mdio_probe+0x78/0xb8&#xA; really_probe+0x2b8/0x5a8&#xA; __driver_probe_device+0x164/0x298&#xA; driver_probe_device+0x78/0x258&#xA; __device_attach_driver+0x274/0x350&#xA;&#xA;Allocated by task 42:&#xA; __kasan_kmalloc+0x84/0xa0&#xA; __kmalloc_cache_noprof+0x298/0x490&#xA; dsa_switch_touch_ports+0x174/0x3d8&#xA; dsa_register_switch+0x800/0x2ae0&#xA; mv88e6xxx_register_switch+0x1b8/0x2a8&#xA; mv88e6xxx_probe+0xc4c/0xf60&#xA; mdio_probe+0x78/0xb8&#xA; really_probe+0x2b8/0x5a8&#xA; __driver_probe_device+0x164/0x298&#xA; driver_probe_device+0x78/0x258&#xA; __device_attach_driver+0x274/0x350&#xA;&#xA;Freed by task 42:&#xA; __kasan_slab_free+0x48/0x68&#xA; kfree+0x138/0x418&#xA; dsa_register_switch+0x2694/0x2ae0&#xA; mv88e6xxx_register_switch+0x1b8/0x2a8&#xA; mv88e6xxx_probe+0xc4c/0xf60&#xA; mdio_probe+0x78/0xb8&#xA; really_probe+0x2b8/0x5a8&#xA; __driver_probe_device+0x164/0x298&#xA; driver_probe_device+0x78/0x258&#xA; __device_attach_driver+0x274/0x350&#xA;&#xA;The simplest way to fix the bug is to delete the routing table in its&#xA;entirety. dsa_tree_setup_routing_table() has no problem in regenerating&#xA;it even if we deleted links between ports other than those of switch N,&#xA;because dsa_link_touch() first checks whether the port pair already&#xA;exists in dst-&gt;rtable, allocating if not.&#xA;&#xA;The deletion of the routing table in its entirety already exists in&#xA;dsa_tree_teardown(), so refactor that into a function that can also be&#xA;called from the tree setup error path.&#xA;&#xA;In my analysis of the commit to blame, it is the one which added&#xA;dsa_link elements to dst-&gt;rtable. Prior to that, each switch had its own&#xA;ds-&gt;rtable which is freed when the switch fails to probe. But the tree&#xA;is potentially persistent memory.&#xA;CVE-2025-40204:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: Fix MAC comparison to be constant-time&#xA;&#xA;To prevent timing attacks, MACs need to be compared in constant time.&#xA;Use the appropriate helper function for this.&#xA;CVE-2022-49267:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mmc: core: use sysfs_emit() instead of sprintf()&#xA;&#xA;sprintf() (still used in the MMC core for the sysfs output) is vulnerable&#xA;to the buffer overflow.  Use the new-fangled sysfs_emit() instead.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with the SVACE static&#xA;analysis tool.&#xA;CVE-2025-38477:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: sch_qfq: Fix race condition on qfq_aggregate&#xA;&#xA;A race condition can occur when &#39;agg&#39; is modified in qfq_change_agg&#xA;(called during qfq_enqueue) while other threads access it&#xA;concurrently. For example, qfq_dump_class may trigger a NULL&#xA;dereference, and qfq_delete_class may cause a use-after-free.&#xA;&#xA;This patch addresses the issue by:&#xA;&#xA;1. Moved qfq_destroy_class into the critical section.&#xA;&#xA;2. Added sch_tree_lock protection to qfq_dump_class and&#xA;qfq_dump_class_stats.&#xA;CVE-2025-38005:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: ti: k3-udma: Add missing locking&#xA;&#xA;Recent kernels complain about a missing lock in k3-udma.c when the lock&#xA;validator is enabled:&#xA;&#xA;[    4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238&#xA;[    4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28&#xA;[    4.144867] Hardware name: pp-v12 (DT)&#xA;[    4.148648] Workqueue: events udma_check_tx_completion&#xA;[    4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[    4.160834] pc : udma_start.isra.0+0x34/0x238&#xA;[    4.165227] lr : udma_start.isra.0+0x30/0x238&#xA;[    4.169618] sp : ffffffc083cabcf0&#xA;[    4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005&#xA;[    4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000&#xA;[    4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670&#xA;[    4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030&#xA;[    4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048&#xA;[    4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001&#xA;[    4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68&#xA;[    4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8&#xA;[    4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000&#xA;[    4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000&#xA;[    4.244986] Call trace:&#xA;[    4.247463]  udma_start.isra.0+0x34/0x238&#xA;[    4.251509]  udma_check_tx_completion+0xd0/0xdc&#xA;[    4.256076]  process_one_work+0x244/0x3fc&#xA;[    4.260129]  process_scheduled_works+0x6c/0x74&#xA;[    4.264610]  worker_thread+0x150/0x1dc&#xA;[    4.268398]  kthread+0xd8/0xe8&#xA;[    4.271492]  ret_from_fork+0x10/0x20&#xA;[    4.275107] irq event stamp: 220&#xA;[    4.278363] hardirqs last  enabled at (219): [&lt;ffffffc080a27c7c&gt;] _raw_spin_unlock_irq+0x38/0x50&#xA;[    4.287183] hardirqs last disabled at (220): [&lt;ffffffc080a1c154&gt;] el1_dbg+0x24/0x50&#xA;[    4.294879] softirqs last  enabled at (182): [&lt;ffffffc080037e68&gt;] handle_softirqs+0x1c0/0x3cc&#xA;[    4.303437] softirqs last disabled at (177): [&lt;ffffffc080010170&gt;] __do_softirq+0x1c/0x28&#xA;[    4.311559] ---[ end trace 0000000000000000 ]---&#xA;&#xA;This commit adds the missing locking.&#xA;CVE-2025-37997:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: ipset: fix region locking in hash types&#xA;&#xA;Region locking introduced in v5.6-rc4 contained three macros to handle&#xA;the region locks: ahash_bucket_start(), ahash_bucket_end() which gave&#xA;back the start and end hash bucket values belonging to a given region&#xA;lock and ahash_region() which should give back the region lock belonging&#xA;to a given hash bucket. The latter was incorrect which can lead to a&#xA;race condition between the garbage collector and adding new elements&#xA;when a hash type of set is defined with timeouts.&#xA;CVE-2025-40200:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Squashfs: reject negative file sizes in squashfs_read_inode()&#xA;&#xA;Syskaller reports a &#34;WARNING in ovl_copy_up_file&#34; in overlayfs.&#xA;&#xA;This warning is ultimately caused because the underlying Squashfs file&#xA;system returns a file with a negative file size.&#xA;&#xA;This commit checks for a negative file size and returns EINVAL.&#xA;&#xA;[[email protected]: only need to check 64 bit quantity]&#xA;CVE-2025-40074:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv4: start using dst_dev_rcu()&#xA;&#xA;Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.&#xA;&#xA;Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),&#xA;ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().&#xA;CVE-2025-40049:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Squashfs: fix uninit-value in squashfs_get_parent&#xA;&#xA;Syzkaller reports a &#34;KMSAN: uninit-value in squashfs_get_parent&#34; bug.&#xA;&#xA;This is caused by open_by_handle_at() being called with a file handle&#xA;containing an invalid parent inode number.  In particular the inode number&#xA;is that of a symbolic link, rather than a directory.&#xA;&#xA;Squashfs_get_parent() gets called with that symbolic link inode, and&#xA;accesses the parent member field.&#xA;&#xA;&#x9;unsigned int parent_ino = squashfs_i(inode)-&gt;parent;&#xA;&#xA;Because non-directory inodes in Squashfs do not have a parent value, this&#xA;is uninitialised, and this causes an uninitialised value access.&#xA;&#xA;The fix is to initialise parent with the invalid inode 0, which will cause&#xA;an EINVAL error to be returned.&#xA;&#xA;Regular inodes used to share the parent field with the block_list_start&#xA;field.  This is removed in this commit to enable the parent field to&#xA;contain the invalid inode number 0.&#xA;CVE-2025-40111:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/vmwgfx: Fix Use-after-free in validation&#xA;&#xA;Nodes stored in the validation duplicates hashtable come from an arena&#xA;allocator that is cleared at the end of vmw_execbuf_process. All nodes&#xA;are expected to be cleared in vmw_validation_drop_ht but this node escaped&#xA;because its resource was destroyed prematurely.&#xA;CVE-2023-53510:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: ufs: core: Fix handling of lrbp-&gt;cmd&#xA;&#xA;ufshcd_queuecommand() may be called two times in a row for a SCSI command&#xA;before it is completed. Hence make the following changes:&#xA;&#xA; - In the functions that submit a command, do not check the old value of&#xA;   lrbp-&gt;cmd nor clear lrbp-&gt;cmd in error paths.&#xA;&#xA; - In ufshcd_release_scsi_cmd(), do not clear lrbp-&gt;cmd.&#xA;&#xA;See also scsi_send_eh_cmnd().&#xA;&#xA;This commit prevents that the following appears if a command times out:&#xA;&#xA;WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8&#xA;Call trace:&#xA; ufshcd_queuecommand+0x6f8/0x9a8&#xA; scsi_send_eh_cmnd+0x2c0/0x960&#xA; scsi_eh_test_devices+0x100/0x314&#xA; scsi_eh_ready_devs+0xd90/0x114c&#xA; scsi_error_handler+0x2b4/0xb70&#xA; kthread+0x16c/0x1e0&#xA;CVE-2025-40178:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pid: Add a judgment for ns null in pid_nr_ns&#xA;&#xA;__task_pid_nr_ns&#xA;        ns = task_active_pid_ns(current);&#xA;        pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);&#xA;                if (pid &amp;&amp; ns-&gt;level &lt;= pid-&gt;level) {&#xA;&#xA;Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.&#xA;&#xA;For example:&#xA;&#x9;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058&#xA;&#x9;Mem abort info:&#xA;&#x9;ESR = 0x0000000096000007&#xA;&#x9;EC = 0x25: DABT (current EL), IL = 32 bits&#xA;&#x9;SET = 0, FnV = 0&#xA;&#x9;EA = 0, S1PTW = 0&#xA;&#x9;FSC = 0x07: level 3 translation fault&#xA;&#x9;Data abort info:&#xA;&#x9;ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000&#xA;&#x9;CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;&#x9;GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;&#x9;user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000&#xA;&#x9;[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000&#xA;&#x9;pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)&#xA;&#x9;pc : __task_pid_nr_ns+0x74/0xd0&#xA;&#x9;lr : __task_pid_nr_ns+0x24/0xd0&#xA;&#x9;sp : ffffffc08001bd10&#xA;&#x9;x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001&#xA;&#x9;x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31&#xA;&#x9;x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0&#xA;&#x9;x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000&#xA;&#x9;x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc&#xA;&#x9;x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800&#xA;&#x9;x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001&#xA;&#x9;x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449&#xA;&#x9;x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc&#xA;&#x9;x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0&#xA;&#x9;Call trace:&#xA;&#x9;__task_pid_nr_ns+0x74/0xd0&#xA;&#x9;...&#xA;&#x9;__handle_irq_event_percpu+0xd4/0x284&#xA;&#x9;handle_irq_event+0x48/0xb0&#xA;&#x9;handle_fasteoi_irq+0x160/0x2d8&#xA;&#x9;generic_handle_domain_irq+0x44/0x60&#xA;&#x9;gic_handle_irq+0x4c/0x114&#xA;&#x9;call_on_irq_stack+0x3c/0x74&#xA;&#x9;do_interrupt_handler+0x4c/0x84&#xA;&#x9;el1_interrupt+0x34/0x58&#xA;&#x9;el1h_64_irq_handler+0x18/0x24&#xA;&#x9;el1h_64_irq+0x68/0x6c&#xA;&#x9;account_kernel_stack+0x60/0x144&#xA;&#x9;exit_task_stack_account+0x1c/0x80&#xA;&#x9;do_exit+0x7e4/0xaf8&#xA;&#x9;...&#xA;&#x9;get_signal+0x7bc/0x8d8&#xA;&#x9;do_notify_resume+0x128/0x828&#xA;&#x9;el0_svc+0x6c/0x70&#xA;&#x9;el0t_64_sync_handler+0x68/0xbc&#xA;&#x9;el0t_64_sync+0x1a8/0x1ac&#xA;&#x9;Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)&#xA;&#x9;---[ end trace 0000000000000000 ]---&#xA;&#x9;Kernel panic - not syncing: Oops: Fatal exception in interrupt&#xA;CVE-2023-53282:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write&#xA;&#xA;During the sysfs firmware write process, a use-after-free read warning is&#xA;logged from the lpfc_wr_object() routine:&#xA;&#xA;  BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]&#xA;  Use-after-free read at 0x0000000000cf164d (in kfence-#111):&#xA;  lpfc_wr_object+0x235/0x310 [lpfc]&#xA;  lpfc_write_firmware.cold+0x206/0x30d [lpfc]&#xA;  lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]&#xA;  lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]&#xA;  kernfs_fop_write_iter+0x121/0x1b0&#xA;  new_sync_write+0x11c/0x1b0&#xA;  vfs_write+0x1ef/0x280&#xA;  ksys_write+0x5f/0xe0&#xA;  do_syscall_64+0x59/0x90&#xA;  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;The driver accessed wr_object pointer data, which was initialized into&#xA;mailbox payload memory, after the mailbox object was released back to the&#xA;mailbox pool.&#xA;&#xA;Fix by moving the mailbox free calls to the end of the routine ensuring&#xA;that we don&#39;t reference internal mailbox memory after release.&#xA;CVE-2025-40211:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPI: video: Fix use-after-free in acpi_video_switch_brightness()&#xA;&#xA;The switch_brightness_work delayed work accesses device-&gt;brightness&#xA;and device-&gt;backlight, freed by acpi_video_dev_unregister_backlight()&#xA;during device removal.&#xA;&#xA;If the work executes after acpi_video_bus_unregister_backlight()&#xA;frees these resources, it causes a use-after-free when&#xA;acpi_video_switch_brightness() dereferences device-&gt;brightness or&#xA;device-&gt;backlight.&#xA;&#xA;Fix this by calling cancel_delayed_work_sync() for each device&#39;s&#xA;switch_brightness_work in acpi_video_bus_remove_notify_handler()&#xA;after removing the notify handler that queues the work. This ensures&#xA;the work completes before the memory is freed.&#xA;&#xA;[ rjw: Changelog edit ]&#xA;CVE-2025-21693:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm: zswap: properly synchronize freeing resources during CPU hotunplug&#xA;&#xA;In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the&#xA;current CPU at the beginning of the operation is retrieved and used&#xA;throughout.  However, since neither preemption nor migration are disabled,&#xA;it is possible that the operation continues on a different CPU.&#xA;&#xA;If the original CPU is hotunplugged while the acomp_ctx is still in use,&#xA;we run into a UAF bug as some of the resources attached to the acomp_ctx&#xA;are freed during hotunplug in zswap_cpu_comp_dead() (i.e. &#xA;acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).&#xA;&#xA;The problem was introduced in commit 1ec3b5fe6eec (&#34;mm/zswap: move to use&#xA;crypto_acomp API for hardware acceleration&#34;) when the switch to the&#xA;crypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was&#xA;retrieved using get_cpu_ptr() which disables preemption and makes sure the&#xA;CPU cannot go away from under us.  Preemption cannot be disabled with the&#xA;crypto_acomp API as a sleepable context is needed.&#xA;&#xA;Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating&#xA;and freeing resources with compression/decompression paths.  Make sure&#xA;that acomp_ctx.req is NULL when the resources are freed.  In the&#xA;compression/decompression paths, check if acomp_ctx.req is NULL after&#xA;acquiring the mutex (meaning the CPU was offlined) and retry on the new&#xA;CPU.&#xA;&#xA;The initialization of acomp_ctx.mutex is moved from the CPU hotplug&#xA;callback to the pool initialization where it belongs (where the mutex is&#xA;allocated).  In addition to adding clarity, this makes sure that CPU&#xA;hotplug cannot reinitialize a mutex that is already locked by&#xA;compression/decompression.&#xA;&#xA;Previously a fix was attempted by holding cpus_read_lock() [1].  This&#xA;would have caused a potential deadlock as it is possible for code already&#xA;holding the lock to fall into reclaim and enter zswap (causing a&#xA;deadlock).  A fix was also attempted using SRCU for synchronization, but&#xA;Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug&#xA;notifiers [2].&#xA;&#xA;Alternative fixes that were considered/attempted and could have worked:&#xA;- Refcounting the per-CPU acomp_ctx. This involves complexity in&#xA;  handling the race between the refcount dropping to zero in&#xA;  zswap_[de]compress() and the refcount being re-initialized when the&#xA;  CPU is onlined.&#xA;- Disabling migration before getting the per-CPU acomp_ctx [3], but&#xA;  that&#39;s discouraged and is a much bigger hammer than needed, and could&#xA;  result in subtle performance issues.&#xA;&#xA;[1]https://lkml.kernel.org/[email protected]/&#xA;[2]https://lkml.kernel.org/[email protected]/&#xA;[3]https://lkml.kernel.org/[email protected]/&#xA;&#xA;[[email protected]: remove comment]&#xA;CVE-2025-38084:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/hugetlb: unshare page tables during VMA split, not before&#xA;&#xA;Currently, __split_vma() triggers hugetlb page table unsharing through&#xA;vm_ops-&gt;may_split().  This happens before the VMA lock and rmap locks are&#xA;taken - which is too early, it allows racing VMA-locked page faults in our&#xA;process and racing rmap walks from other processes to cause page tables to&#xA;be shared again before we actually perform the split.&#xA;&#xA;Fix it by explicitly calling into the hugetlb unshare logic from&#xA;__split_vma() in the same place where THP splitting also happens.  At that&#xA;point, both the VMA and the rmap(s) are write-locked.&#xA;&#xA;An annoying detail is that we can now call into the helper&#xA;hugetlb_unshare_pmds() from two different locking contexts:&#xA;&#xA;1. from hugetlb_split(), holding:&#xA;    - mmap lock (exclusively)&#xA;    - VMA lock&#xA;    - file rmap lock (exclusively)&#xA;2. hugetlb_unshare_all_pmds(), which I think is designed to be able to&#xA;   call us with only the mmap lock held (in shared mode), but currently&#xA;   only runs while holding mmap lock (exclusively) and VMA lock&#xA;&#xA;Backporting note:&#xA;This commit fixes a racy protection that was introduced in commit&#xA;b30c14cd6102 (&#34;hugetlb: unshare some PMDs when splitting VMAs&#34;); that&#xA;commit claimed to fix an issue introduced in 5.13, but it should actually&#xA;also go all the way back.&#xA;&#xA;[[email protected]: v2]&#xA;CVE-2021-47653:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: davinci: vpif: fix use-after-free on driver unbind&#xA;&#xA;The driver allocates and registers two platform device structures during&#xA;probe, but the devices were never deregistered on driver unbind.&#xA;&#xA;This results in a use-after-free on driver unbind as the device&#xA;structures were allocated using devres and would be freed by driver&#xA;core when remove() returns.&#xA;&#xA;Fix this by adding the missing deregistration calls to the remove()&#xA;callback and failing probe on registration errors.&#xA;&#xA;Note that the platform device structures must be freed using a proper&#xA;release callback to avoid leaking associated resources like device&#xA;names.&#xA;CVE-2025-39817:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare&#xA;&#xA;Observed on kernel 6.6 (present on master as well):&#xA;&#xA;  BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0&#xA;  Call trace:&#xA;   kasan_check_range+0xe8/0x190&#xA;   __asan_loadN+0x1c/0x28&#xA;   memcmp+0x98/0xd0&#xA;   efivarfs_d_compare+0x68/0xd8&#xA;   __d_lookup_rcu_op_compare+0x178/0x218&#xA;   __d_lookup_rcu+0x1f8/0x228&#xA;   d_alloc_parallel+0x150/0x648&#xA;   lookup_open.isra.0+0x5f0/0x8d0&#xA;   open_last_lookups+0x264/0x828&#xA;   path_openat+0x130/0x3f8&#xA;   do_filp_open+0x114/0x248&#xA;   do_sys_openat2+0x340/0x3c0&#xA;   __arm64_sys_openat+0x120/0x1a0&#xA;&#xA;If dentry-&gt;d_name.len &lt; EFI_VARIABLE_GUID_LEN , &#39;guid&#39; can become&#xA;negative, leadings to oob. The issue can be triggered by parallel&#xA;lookups using invalid filename:&#xA;&#xA;  T1&#x9;&#x9;&#x9;T2&#xA;  lookup_open&#xA;   -&gt;lookup&#xA;    simple_lookup&#xA;     d_add&#xA;     // invalid dentry is added to hash list&#xA;&#xA;&#x9;&#x9;&#x9;lookup_open&#xA;&#x9;&#x9;&#x9; d_alloc_parallel&#xA;&#x9;&#x9;&#x9;  __d_lookup_rcu&#xA;&#x9;&#x9;&#x9;   __d_lookup_rcu_op_compare&#xA;&#x9;&#x9;&#x9;    hlist_bl_for_each_entry_rcu&#xA;&#x9;&#x9;&#x9;    // invalid dentry can be retrieved&#xA;&#x9;&#x9;&#x9;     -&gt;d_compare&#xA;&#x9;&#x9;&#x9;      efivarfs_d_compare&#xA;&#x9;&#x9;&#x9;      // oob&#xA;&#xA;Fix it by checking &#39;guid&#39; before cmp.&#xA;CVE-2025-40170:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: use dst_dev_rcu() in sk_setup_caps()&#xA;&#xA;Use RCU to protect accesses to dst-&gt;dev from sk_setup_caps()&#xA;and sk_dst_gso_max_size().&#xA;&#xA;Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),&#xA;and ip_dst_mtu_maybe_forward().&#xA;&#xA;ip4_dst_hoplimit() can use dst_dev_net_rcu().&#xA;CVE-2025-40149:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().&#xA;&#xA;get_netdev_for_sock() is called during setsockopt(),&#xA;so not under RCU.&#xA;&#xA;Using sk_dst_get(sk)-&gt;dev could trigger UAF.&#xA;&#xA;Let&#39;s use __sk_dst_get() and dst_dev_rcu().&#xA;&#xA;Note that the only -&gt;ndo_sk_get_lower_dev() user is&#xA;bond_sk_get_lower_dev(), which uses RCU.&#xA;CVE-2025-40319:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Sync pending IRQ work before freeing ring buffer&#xA;&#xA;Fix a race where irq_work can be queued in bpf_ringbuf_commit()&#xA;but the ring buffer is freed before the work executes.&#xA;In the syzbot reproducer, a BPF program attached to sched_switch&#xA;triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer&#xA;is freed before this work executes, the irq_work thread may accesses&#xA;freed memory.&#xA;Calling `irq_work_sync(&amp;rb-&gt;work)` ensures that all pending irq_work&#xA;complete before freeing the buffer.&#xA;CVE-2025-40183:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}&#xA;&#xA;Cilium has a BPF egress gateway feature which forces outgoing K8s Pod&#xA;traffic to pass through dedicated egress gateways which then SNAT the&#xA;traffic in order to interact with stable IPs outside the cluster.&#xA;&#xA;The traffic is directed to the gateway via vxlan tunnel in collect md&#xA;mode. A recent BPF change utilized the bpf_redirect_neigh() helper to&#xA;forward packets after the arrival and decap on vxlan, which turned out&#xA;over time that the kmalloc-256 slab usage in kernel was ever-increasing.&#xA;&#xA;The issue was that vxlan allocates the metadata_dst object and attaches&#xA;it through a fake dst entry to the skb. The latter was never released&#xA;though given bpf_redirect_neigh() was merely setting the new dst entry&#xA;via skb_dst_set() without dropping an existing one first.&#xA;CVE-2025-40168:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().&#xA;&#xA;smc_clc_prfx_match() is called from smc_listen_work() and&#xA;not under RCU nor RTNL.&#xA;&#xA;Using sk_dst_get(sk)-&gt;dev could trigger UAF.&#xA;&#xA;Let&#39;s use __sk_dst_get() and dst_dev_rcu().&#xA;&#xA;Note that the returned value of smc_clc_prfx_match() is not&#xA;used in the caller.&#xA;CVE-2025-39766:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit&#xA;&#xA;The following setup can trigger a WARNING in htb_activate due to&#xA;the condition: !cl-&gt;leaf.q-&gt;q.qlen&#xA;&#xA;tc qdisc del dev lo root&#xA;tc qdisc add dev lo root handle 1: htb default 1&#xA;tc class add dev lo parent 1: classid 1:1 \&#xA;       htb rate 64bit&#xA;tc qdisc add dev lo parent 1:1 handle f: \&#xA;       cake memlimit 1b&#xA;ping -I lo -f -c1 -s64 -W0.001 127.0.0.1&#xA;&#xA;This is because the low memlimit leads to a low buffer_limit, which&#xA;causes packet dropping. However, cake_enqueue still returns&#xA;NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an&#xA;empty child qdisc. We should return NET_XMIT_CN when packets are&#xA;dropped from the same tin and flow.&#xA;&#xA;I do not believe return value of NET_XMIT_CN is necessary for packet&#xA;drops in the case of ack filtering, as that is meant to optimize&#xA;performance, not to signal congestion.&#xA;CVE-2025-39751:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2025-22121:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()&#xA;&#xA;There&#39;s issue as follows:&#xA;BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790&#xA;Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172&#xA;&#xA;CPU: 3 PID: 15172 Comm: syz-executor.0&#xA;Call Trace:&#xA; __dump_stack lib/dump_stack.c:82 [inline]&#xA; dump_stack+0xbe/0xfd lib/dump_stack.c:123&#xA; print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400&#xA; __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560&#xA; kasan_report+0x3a/0x50 mm/kasan/report.c:585&#xA; ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137&#xA; ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896&#xA; ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323&#xA; evict+0x39f/0x880 fs/inode.c:622&#xA; iput_final fs/inode.c:1746 [inline]&#xA; iput fs/inode.c:1772 [inline]&#xA; iput+0x525/0x6c0 fs/inode.c:1758&#xA; ext4_orphan_cleanup fs/ext4/super.c:3298 [inline]&#xA; ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300&#xA; mount_bdev+0x355/0x410 fs/super.c:1446&#xA; legacy_get_tree+0xfe/0x220 fs/fs_context.c:611&#xA; vfs_get_tree+0x8d/0x2f0 fs/super.c:1576&#xA; do_new_mount fs/namespace.c:2983 [inline]&#xA; path_mount+0x119a/0x1ad0 fs/namespace.c:3316&#xA; do_mount+0xfc/0x110 fs/namespace.c:3329&#xA; __do_sys_mount fs/namespace.c:3540 [inline]&#xA; __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514&#xA; do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46&#xA; entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;&#xA;Memory state around the buggy address:&#xA; ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA; ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;&gt;ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;                   ^&#xA; ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA; ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;&#xA;Above issue happens as ext4_xattr_delete_inode() isn&#39;t check xattr&#xA;is valid if xattr is in inode.&#xA;To solve above issue call xattr_check_inode() check if xattr if valid&#xA;in inode. In fact, we can directly verify in ext4_iget_extra_inode(),&#xA;so that there is no divergent verification.&#xA;CVE-2025-40019:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: essiv - Check ssize for decryption and in-place encryption&#xA;&#xA;Move the ssize check to the start in essiv_aead_crypt so that&#xA;it&#39;s also checked for decryption and in-place encryption.&#xA;CVE-2025-40194:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()&#xA;&#xA;The cpufreq_cpu_put() call in update_qos_request() takes place too early&#xA;because the latter subsequently calls freq_qos_update_request() that&#xA;indirectly accesses the policy object in question through the QoS request&#xA;object passed to it.&#xA;&#xA;Fortunately, update_qos_request() is called under intel_pstate_driver_lock,&#xA;so this issue does not matter for changing the intel_pstate operation&#xA;mode, but it theoretically can cause a crash to occur on CPU device hot&#xA;removal (which currently can only happen in virt, but it is formally&#xA;supported nevertheless).&#xA;&#xA;Address this issue by modifying update_qos_request() to drop the&#xA;reference to the policy later.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-devel-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/kernel-devel-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-headers-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/kernel-headers-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/kernel-tools-devel-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="296.0.0.199.u190" version="5.10.0">
					<filename>python3-perf-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-perf-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-tools-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/kernel-tools-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="296.0.0.199.u190" version="5.10.0">
					<filename>bpftool-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/bpftool-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="296.0.0.199.u190" version="5.10.0">
					<filename>perf-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/perf-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/kernel-5.10.0-296.0.0.199.u190.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/kernel-tools-devel-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-devel-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/kernel-devel-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="296.0.0.199.u190" version="5.10.0">
					<filename>bpftool-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/bpftool-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-headers-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/kernel-headers-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-tools-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/kernel-tools-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="296.0.0.199.u190" version="5.10.0">
					<filename>kernel-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/kernel-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="296.0.0.199.u190" version="5.10.0">
					<filename>perf-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/perf-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="296.0.0.199.u190" version="5.10.0">
					<filename>python3-perf-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-perf-5.10.0-296.0.0.199.u190.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3044</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66471&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66471" id="CVE-2025-66471" title="CVE-2025-66471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66418&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66418" id="CVE-2025-66418" title="CVE-2025-66418" type="cve"></reference>
		</references>
		<description>CVE-2025-66471:urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3&#39;s streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.&#xA;CVE-2025-66418:urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python3-urllib3" release="10.u9" version="1.26.12">
					<filename>python3-urllib3-1.26.12-10.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-urllib3-1.26.12-10.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3045</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9820&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9820" id="CVE-2025-9820" title="CVE-2025-9820" type="cve"></reference>
		</references>
		<description>CVE-2025-9820:A flaw was found in the GnuTLS library, specifically in the gnutls_pkcs11_token_init() function that handles PKCS#11 token initialization. When a token label longer than expected is processed, the function writes past the end of a fixed-size stack buffer. This programming error can cause the application using GnuTLS to crash or, in certain conditions, be exploited for code execution. As a result, systems or applications relying on GnuTLS may be vulnerable to a denial of service or local privilege escalation attacks.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="gnutls-help" release="18.u10" version="3.7.2">
					<filename>gnutls-help-3.7.2-18.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gnutls-help-3.7.2-18.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="18.u10" version="3.7.2">
					<filename>gnutls-utils-3.7.2-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gnutls-utils-3.7.2-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="18.u10" version="3.7.2">
					<filename>gnutls-devel-3.7.2-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gnutls-devel-3.7.2-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls" release="18.u10" version="3.7.2">
					<filename>gnutls-3.7.2-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gnutls-3.7.2-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="18.u10" version="3.7.2">
					<filename>gnutls-3.7.2-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gnutls-3.7.2-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="18.u10" version="3.7.2">
					<filename>gnutls-devel-3.7.2-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gnutls-devel-3.7.2-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="18.u10" version="3.7.2">
					<filename>gnutls-utils-3.7.2-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gnutls-utils-3.7.2-18.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3046</id>
		<title>An update for bwa is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10269&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-10269" id="CVE-2019-10269" title="CVE-2019-10269" type="cve"></reference>
		</references>
		<description>CVE-2019-10269:BWA (aka Burrow-Wheeler Aligner) before 2019-01-23 has a stack-based buffer overflow in the bns_restore function in bntseq.c via a long sequence name in a .alt file.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="bwa" release="2.u1" version="0.7.17">
					<filename>bwa-0.7.17-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/bwa-0.7.17-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bwa" release="2.u1" version="0.7.17">
					<filename>bwa-0.7.17-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/bwa-0.7.17-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3047</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14087&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14087" id="CVE-2025-14087" title="CVE-2025-14087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14512&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14512" id="CVE-2025-14512" title="CVE-2025-14512" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13601" id="CVE-2025-13601" title="CVE-2025-13601" type="cve"></reference>
		</references>
		<description>CVE-2025-14087:A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.&#xA;CVE-2025-14512:A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib&#39;s GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.&#xA;CVE-2025-13601:A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="24.u19" version="2.72.2">
					<filename>glib2-devel-2.72.2-24.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glib2-devel-2.72.2-24.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-static" release="24.u19" version="2.72.2">
					<filename>glib2-static-2.72.2-24.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glib2-static-2.72.2-24.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="24.u19" version="2.72.2">
					<filename>glib2-tests-2.72.2-24.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glib2-tests-2.72.2-24.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2" release="24.u19" version="2.72.2">
					<filename>glib2-2.72.2-24.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/glib2-2.72.2-24.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="24.u19" version="2.72.2">
					<filename>glib2-help-2.72.2-24.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib2-help-2.72.2-24.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-static" release="24.u19" version="2.72.2">
					<filename>glib2-static-2.72.2-24.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib2-static-2.72.2-24.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="24.u19" version="2.72.2">
					<filename>glib2-devel-2.72.2-24.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib2-devel-2.72.2-24.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2" release="24.u19" version="2.72.2">
					<filename>glib2-2.72.2-24.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib2-2.72.2-24.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="24.u19" version="2.72.2">
					<filename>glib2-tests-2.72.2-24.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/glib2-tests-2.72.2-24.u19.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3048</id>
		<title>An update for hdf5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2153&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2153" id="CVE-2025-2153" title="CVE-2025-2153" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2310&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2310" id="CVE-2025-2310" title="CVE-2025-2310" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2913&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2913" id="CVE-2025-2913" title="CVE-2025-2913" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2914&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2914" id="CVE-2025-2914" title="CVE-2025-2914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2924&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2924" id="CVE-2025-2924" title="CVE-2025-2924" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2925&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2925" id="CVE-2025-2925" title="CVE-2025-2925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2926&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2926" id="CVE-2025-2926" title="CVE-2025-2926" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-44905&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-44905" id="CVE-2025-44905" title="CVE-2025-44905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6269&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6269" id="CVE-2025-6269" title="CVE-2025-6269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6516" id="CVE-2025-6516" title="CVE-2025-6516" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6750&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6750" id="CVE-2025-6750" title="CVE-2025-6750" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6816&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6816" id="CVE-2025-6816" title="CVE-2025-6816" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6817" id="CVE-2025-6817" title="CVE-2025-6817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6818&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6818" id="CVE-2025-6818" title="CVE-2025-6818" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6856" id="CVE-2025-6856" title="CVE-2025-6856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6857" id="CVE-2025-6857" title="CVE-2025-6857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6858" id="CVE-2025-6858" title="CVE-2025-6858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7067&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7067" id="CVE-2025-7067" title="CVE-2025-7067" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7068&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7068" id="CVE-2025-7068" title="CVE-2025-7068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7069&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7069" id="CVE-2025-7069" title="CVE-2025-7069" type="cve"></reference>
		</references>
		<description>CVE-2025-2153:A vulnerability, which was classified as critical, was found in HDF5 1.14.6. Affected is the function H5SM_delete of the file H5SM.c of the component h5 File Handler. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2310:A vulnerability was found in HDF5 1.14.6 and classified as critical. This issue affects the function H5MM_strndup of the component Metadata Attribute Decoder. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The vendor plans to fix this issue in an upcoming release.&#xA;CVE-2025-2913:A vulnerability was found in HDF5 up to 1.14.6. It has been rated as critical. Affected by this issue is the function H5FL__blk_gc_list of the file src/H5FL.c. The manipulation of the argument H5FL_blk_head_t leads to use after free. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2914:A vulnerability classified as problematic has been found in HDF5 up to 1.14.6. This affects the function H5FS__sinfo_Srialize_Sct_cb of the file src/H5FScache.c. The manipulation of the argument sect leads to heap-based buffer overflow. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2924:A vulnerability, which was classified as problematic, was found in HDF5 up to 1.14.6. This affects the function H5HL__fl_deserialize of the file src/H5HLcache.c. The manipulation of the argument free_block leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2925:A vulnerability has been found in HDF5 up to 1.14.6 and classified as problematic. This vulnerability affects the function H5MM_realloc of the file src/H5MM.c. The manipulation of the argument mem leads to double free. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2926:A vulnerability was found in HDF5 up to 1.14.6 and classified as problematic. This issue affects the function H5O__cache_chk_serialize of the file src/H5Ocache.c. The manipulation leads to null pointer dereference. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-44905:hdf5 v1.14.6 was discovered to contain a heap buffer overflow via the H5Z__filter_scaleoffset function.&#xA;CVE-2025-6269:A vulnerability classified as critical was found in HDF5 up to 1.14.6. Affected by this vulnerability is the function H5C__reconstruct_cache_entry of the file H5Cimage.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6516:A vulnerability has been found in HDF5 up to 1.14.6 and classified as critical. This vulnerability affects the function H5F_addr_decode_len of the file /hdf5/src/H5Fint.c. The manipulation leads to heap-based buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6750:A vulnerability, which was classified as problematic, has been found in HDF5 1.14.6. Affected by this issue is the function H5O__mtime_new_encode of the file src/H5Omtime.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6816:A vulnerability classified as problematic was found in HDF5 1.14.6. This vulnerability affects the function H5O__fsinfo_encode of the file /src/H5Ofsinfo.c. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6817:A vulnerability, which was classified as problematic, has been found in HDF5 1.14.6. This issue affects the function H5C__load_entry of the file /src/H5Centry.c. The manipulation leads to resource consumption. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6818:A vulnerability, which was classified as problematic, was found in HDF5 1.14.6. Affected is the function H5O__chunk_protect of the file /src/H5Ochunk.c. The manipulation leads to heap-based buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6856:A vulnerability, which was classified as problematic, was found in HDF5 1.14.6. Affected is the function H5FL__reg_gc_list of the file src/H5FL.c. The manipulation leads to use after free. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6857:A vulnerability has been found in HDF5 1.14.6 and classified as problematic. Affected by this vulnerability is the function H5G__node_cmp3 of the file src/H5Gnode.c. The manipulation leads to stack-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-6858:A vulnerability was found in HDF5 1.14.6 and classified as problematic. Affected by this issue is the function H5C__flush_single_entry of the file src/H5Centry.c. The manipulation leads to null pointer dereference. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-7067:A vulnerability classified as problematic was found in HDF5 1.14.6. This vulnerability affects the function H5FS__sinfo_serialize_node_cb of the file src/H5FScache.c. The manipulation leads to heap-based buffer overflow. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-7068:A vulnerability, which was classified as problematic, has been found in HDF5 1.14.6. This issue affects the function H5FL__malloc of the file src/H5FL.c. The manipulation leads to memory leak. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-7069:A vulnerability, which was classified as problematic, was found in HDF5 1.14.6. Affected is the function H5FS__sect_link_size of the file src/H5FSsection.c. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="hdf5" release="3.u5" version="1.14.5">
					<filename>hdf5-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-static" release="3.u5" version="1.14.5">
					<filename>hdf5-openmpi-static-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-openmpi-static-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-devel" release="3.u5" version="1.14.5">
					<filename>hdf5-mpich-devel-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-mpich-devel-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi" release="3.u5" version="1.14.5">
					<filename>hdf5-openmpi-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-openmpi-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich" release="3.u5" version="1.14.5">
					<filename>hdf5-mpich-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-mpich-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-openmpi-devel" release="3.u5" version="1.14.5">
					<filename>hdf5-openmpi-devel-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-openmpi-devel-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-devel" release="3.u5" version="1.14.5">
					<filename>hdf5-devel-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-devel-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hdf5-mpich-static" release="3.u5" version="1.14.5">
					<filename>hdf5-mpich-static-1.14.5-3.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/hdf5-mpich-static-1.14.5-3.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich" release="3.u5" version="1.14.5">
					<filename>hdf5-mpich-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-mpich-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5" release="3.u5" version="1.14.5">
					<filename>hdf5-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-static" release="3.u5" version="1.14.5">
					<filename>hdf5-mpich-static-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-mpich-static-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi" release="3.u5" version="1.14.5">
					<filename>hdf5-openmpi-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-openmpi-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-static" release="3.u5" version="1.14.5">
					<filename>hdf5-openmpi-static-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-openmpi-static-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-devel" release="3.u5" version="1.14.5">
					<filename>hdf5-devel-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-devel-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-mpich-devel" release="3.u5" version="1.14.5">
					<filename>hdf5-mpich-devel-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-mpich-devel-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hdf5-openmpi-devel" release="3.u5" version="1.14.5">
					<filename>hdf5-openmpi-devel-1.14.5-3.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/hdf5-openmpi-devel-1.14.5-3.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3049</id>
		<title>An update for cmake is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9301&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9301" id="CVE-2025-9301" title="CVE-2025-9301" type="cve"></reference>
		</references>
		<description>CVE-2025-9301:A vulnerability was determined in cmake 4.1.20250725-gb5cce23. This affects the function cmForEachFunctionBlocker::ReplayItems of the file cmForEachCommand.cxx. This manipulation causes reachable assertion. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. Patch name: 37e27f71bc356d880c908040cd0cb68fa2c371b8. It is suggested to install a patch to address this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="cmake-rpm-macros" release="11.u4" version="3.22.0">
					<filename>cmake-rpm-macros-3.22.0-11.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/cmake-rpm-macros-3.22.0-11.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cmake-data" release="11.u4" version="3.22.0">
					<filename>cmake-data-3.22.0-11.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/cmake-data-3.22.0-11.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cmake-help" release="11.u4" version="3.22.0">
					<filename>cmake-help-3.22.0-11.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/cmake-help-3.22.0-11.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cmake-gui" release="11.u4" version="3.22.0">
					<filename>cmake-gui-3.22.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/cmake-gui-3.22.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cmake-filesystem" release="11.u4" version="3.22.0">
					<filename>cmake-filesystem-3.22.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/cmake-filesystem-3.22.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cmake" release="11.u4" version="3.22.0">
					<filename>cmake-3.22.0-11.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/cmake-3.22.0-11.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cmake" release="11.u4" version="3.22.0">
					<filename>cmake-3.22.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/cmake-3.22.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cmake-filesystem" release="11.u4" version="3.22.0">
					<filename>cmake-filesystem-3.22.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/cmake-filesystem-3.22.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cmake-gui" release="11.u4" version="3.22.0">
					<filename>cmake-gui-3.22.0-11.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/cmake-gui-3.22.0-11.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3050</id>
		<title>An update for erlang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48038&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48038" id="CVE-2025-48038" title="CVE-2025-48038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48039&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48039" id="CVE-2025-48039" title="CVE-2025-48039" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48041&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-48041" id="CVE-2025-48041" title="CVE-2025-48041" type="cve"></reference>
		</references>
		<description>CVE-2025-48038:Allocation of Resources Without Limits or Throttling vulnerability in Erlang OTP ssh (ssh_sftp modules) allows Excessive Allocation, Resource Leak Exposure. This vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.&#xA;&#xA;This issue affects OTP form OTP 17.0 until OTP 28.0.3, OTP 27.3.4.3 and 26.2.5.15 corresponding to ssh from 3.0.1 until 5.3.3, 5.2.11.3 and 5.1.4.12.&#xA;CVE-2025-48039:Allocation of Resources Without Limits or Throttling vulnerability in Erlang OTP ssh (ssh_sftp modules) allows Excessive Allocation, Resource Leak Exposure. This vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.&#xA;&#xA;This issue affects OTP form OTP 17.0 until OTP 28.0.3, OTP 27.3.4.3 and 26.2.5.15 corresponding to ssh from 3.0.1 until 5.3.3, 5.2.11.3 and 5.1.4.12.&#xA;CVE-2025-48041:Allocation of Resources Without Limits or Throttling vulnerability in Erlang OTP ssh (ssh_sftp modules) allows Excessive Allocation, Flooding. This vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.&#xA;&#xA;This issue affects OTP form OTP 17.0 until OTP 28.0.3, OTP 27.3.4.3 and 26.2.5.15 corresponding to ssh from 3.0.1 until 5.3.3, 5.2.11.3 and 5.1.4.12.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="erlang-erl_docgen" release="8.u5" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-erl_docgen-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang" release="8.u5" version="23.3.4.9">
					<filename>erlang-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-compiler" release="8.u5" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-compiler-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-common_test" release="8.u5" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-common_test-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-inets" release="8.u5" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-inets-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-public_key" release="8.u5" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-public_key-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-runtime_tools" release="8.u5" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-runtime_tools-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-os_mon" release="8.u5" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-os_mon-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-parsetools" release="8.u5" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-parsetools-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-xmerl" release="8.u5" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-xmerl-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-asn1" release="8.u5" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-asn1-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-examples" release="8.u5" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-examples-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-syntax_tools" release="8.u5" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-syntax_tools-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-stdlib" release="8.u5" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-stdlib-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tftp" release="8.u5" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-tftp-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ftp" release="8.u5" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-ftp-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-megaco" release="8.u5" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-megaco-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-odbc" release="8.u5" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-odbc-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-sasl" release="8.u5" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-sasl-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssl" release="8.u5" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-ssl-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-reltool" release="8.u5" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-reltool-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-diameter" release="8.u5" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-diameter-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-edoc" release="8.u5" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-edoc-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-wx" release="8.u5" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-wx-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-hipe" release="8.u5" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-hipe-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-kernel" release="8.u5" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-kernel-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eldap" release="8.u5" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-eldap-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erl_interface" release="8.u5" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-erl_interface-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-erts" release="8.u5" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-erts-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-et" release="8.u5" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-et-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-eunit" release="8.u5" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-eunit-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-snmp" release="8.u5" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-snmp-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-crypto" release="8.u5" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-crypto-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-debugger" release="8.u5" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-debugger-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-mnesia" release="8.u5" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-mnesia-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-tools" release="8.u5" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-tools-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-jinterface" release="8.u5" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-jinterface-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-observer" release="8.u5" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-observer-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-ssh" release="8.u5" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-ssh-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="erlang-dialyzer" release="8.u5" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/erlang-dialyzer-23.3.4.9-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-compiler" release="8.u5" version="23.3.4.9">
					<filename>erlang-compiler-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-compiler-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_docgen" release="8.u5" version="23.3.4.9">
					<filename>erlang-erl_docgen-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-erl_docgen-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-inets" release="8.u5" version="23.3.4.9">
					<filename>erlang-inets-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-inets-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssl" release="8.u5" version="23.3.4.9">
					<filename>erlang-ssl-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-ssl-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-asn1" release="8.u5" version="23.3.4.9">
					<filename>erlang-asn1-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-asn1-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-diameter" release="8.u5" version="23.3.4.9">
					<filename>erlang-diameter-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-diameter-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ssh" release="8.u5" version="23.3.4.9">
					<filename>erlang-ssh-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-ssh-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tools" release="8.u5" version="23.3.4.9">
					<filename>erlang-tools-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-tools-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-wx" release="8.u5" version="23.3.4.9">
					<filename>erlang-wx-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-wx-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eunit" release="8.u5" version="23.3.4.9">
					<filename>erlang-eunit-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-eunit-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-observer" release="8.u5" version="23.3.4.9">
					<filename>erlang-observer-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-observer-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-debugger" release="8.u5" version="23.3.4.9">
					<filename>erlang-debugger-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-debugger-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-examples" release="8.u5" version="23.3.4.9">
					<filename>erlang-examples-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-examples-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-common_test" release="8.u5" version="23.3.4.9">
					<filename>erlang-common_test-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-common_test-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-public_key" release="8.u5" version="23.3.4.9">
					<filename>erlang-public_key-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-public_key-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-runtime_tools" release="8.u5" version="23.3.4.9">
					<filename>erlang-runtime_tools-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-runtime_tools-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-kernel" release="8.u5" version="23.3.4.9">
					<filename>erlang-kernel-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-kernel-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-os_mon" release="8.u5" version="23.3.4.9">
					<filename>erlang-os_mon-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-os_mon-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-mnesia" release="8.u5" version="23.3.4.9">
					<filename>erlang-mnesia-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-mnesia-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-parsetools" release="8.u5" version="23.3.4.9">
					<filename>erlang-parsetools-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-parsetools-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-crypto" release="8.u5" version="23.3.4.9">
					<filename>erlang-crypto-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-crypto-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-snmp" release="8.u5" version="23.3.4.9">
					<filename>erlang-snmp-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-snmp-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-edoc" release="8.u5" version="23.3.4.9">
					<filename>erlang-edoc-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-edoc-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erts" release="8.u5" version="23.3.4.9">
					<filename>erlang-erts-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-erts-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-sasl" release="8.u5" version="23.3.4.9">
					<filename>erlang-sasl-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-sasl-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-eldap" release="8.u5" version="23.3.4.9">
					<filename>erlang-eldap-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-eldap-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-erl_interface" release="8.u5" version="23.3.4.9">
					<filename>erlang-erl_interface-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-erl_interface-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-hipe" release="8.u5" version="23.3.4.9">
					<filename>erlang-hipe-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-hipe-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-jinterface" release="8.u5" version="23.3.4.9">
					<filename>erlang-jinterface-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-jinterface-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-megaco" release="8.u5" version="23.3.4.9">
					<filename>erlang-megaco-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-megaco-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-xmerl" release="8.u5" version="23.3.4.9">
					<filename>erlang-xmerl-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-xmerl-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang" release="8.u5" version="23.3.4.9">
					<filename>erlang-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-dialyzer" release="8.u5" version="23.3.4.9">
					<filename>erlang-dialyzer-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-dialyzer-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-et" release="8.u5" version="23.3.4.9">
					<filename>erlang-et-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-et-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-ftp" release="8.u5" version="23.3.4.9">
					<filename>erlang-ftp-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-ftp-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-reltool" release="8.u5" version="23.3.4.9">
					<filename>erlang-reltool-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-reltool-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-stdlib" release="8.u5" version="23.3.4.9">
					<filename>erlang-stdlib-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-stdlib-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-syntax_tools" release="8.u5" version="23.3.4.9">
					<filename>erlang-syntax_tools-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-syntax_tools-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-odbc" release="8.u5" version="23.3.4.9">
					<filename>erlang-odbc-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-odbc-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="erlang-tftp" release="8.u5" version="23.3.4.9">
					<filename>erlang-tftp-23.3.4.9-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/erlang-tftp-23.3.4.9-8.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3051</id>
		<title>An update for python-ldap is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61912" id="CVE-2025-61912" title="CVE-2025-61912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61911&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61911" id="CVE-2025-61911" title="CVE-2025-61911" type="cve"></reference>
		</references>
		<description>CVE-2025-61912:python-ldap is a lightweight directory access protocol (LDAP) client API for Python. In versions prior to 3.4.5, ldap.dn.escape_dn_chars() escapes \x00 incorrectly by emitting a backslash followed by a literal NUL byte instead of the RFC-4514 hex form \00. Any application that uses this helper to construct DNs from untrusted input can be made to consistently fail before a request is sent to the LDAP server (e.g., AD), resulting in a client-side denial of service. Version 3.4.5 contains a patch for the issue.&#xA;CVE-2025-61911:python-ldap is a lightweight directory access protocol (LDAP) client API for Python. In versions prior to 3.4.5, the sanitization method `ldap.filter.escape_filter_chars` can be tricked to skip escaping of special characters when a crafted `list` or `dict` is supplied as the `assertion_value` parameter, and the non-default `escape_mode=1` is configured. The method `ldap.filter.escape_filter_chars` supports 3 different escaping modes. `escape_mode=0` (default) and `escape_mode=2` happen to raise exceptions when a `list` or `dict` object is supplied as the `assertion_value` parameter. However, `escape_mode=1` computes without performing adequate logic to ensure a fully escaped return value. If an application relies on the vulnerable method in the `python-ldap` library to escape untrusted user input, an attacker might be able to abuse the vulnerability to launch ldap injection attacks which could potentially disclose or manipulate ldap data meant to be inaccessible to them. Version 3.4.5 fixes the issue by adding a type check at the start of the `ldap.filter.escape_filter_chars` method to raise an exception when the supplied `assertion_value` parameter is not of type `str`.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="python3-ldap" release="7.u2" version="3.3.1">
					<filename>python3-ldap-3.3.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-ldap-3.3.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-ldap-help" release="7.u2" version="3.3.1">
					<filename>python-ldap-help-3.3.1-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python-ldap-help-3.3.1-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-ldap" release="7.u2" version="3.3.1">
					<filename>python3-ldap-3.3.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-ldap-3.3.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3052</id>
		<title>An update for python-kdcproxy is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59088&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59088" id="CVE-2025-59088" title="CVE-2025-59088" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59089&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59089" id="CVE-2025-59089" title="CVE-2025-59089" type="cve"></reference>
		</references>
		<description>CVE-2025-59088:If kdcproxy receives a request for a realm which does not have server addresses defined in its configuration, by default, it will query SRV records in the DNS zone matching the requested realm name. This creates a server-side request forgery vulnerability, since an attacker could send a request for a realm matching a DNS zone where they created SRV records pointing to arbitrary ports and hostnames (which may resolve to loopback or internal IP addresses). This vulnerability can be exploited to probe internal network topology and firewall rules, perform port scanning, and exfiltrate data. Deployments where&#xA;the &#34;use_dns&#34; setting is explicitly set to false are not affected.&#xA;CVE-2025-59089:If an attacker causes kdcproxy to connect to an attacker-controlled KDC server (e.g. through server-side request forgery), they can exploit the fact that kdcproxy does not enforce bounds on TCP response length to conduct a denial-of-service attack. While receiving the KDC&#39;s response, kdcproxy copies the entire buffered stream into a new&#xA;buffer on each recv() call, even when the transfer is incomplete, causing excessive memory allocation and CPU usage. Additionally, kdcproxy accepts incoming response chunks as long as the received data length is not exactly equal to the length indicated in the response&#xA;header, even when individual chunks or the total buffer exceed the maximum length of a Kerberos message. This allows an attacker to send unbounded data until the connection timeout is reached (approximately 12 seconds), exhausting server memory or CPU resources. Multiple concurrent requests can cause accept queue overflow, denying service to legitimate clients.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python3-kdcproxy" release="2.u1" version="1.0.0">
					<filename>python3-kdcproxy-1.0.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-kdcproxy-1.0.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3053</id>
		<title>An update for net-snmp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68615" id="CVE-2025-68615" title="CVE-2025-68615" type="cve"></reference>
		</references>
		<description>CVE-2025-68615:net-snmp is a SNMP application library, tools and daemon. Prior to versions 5.9.5 and 5.10.pre2, a specially crafted packet to an net-snmp snmptrapd daemon can cause a buffer overflow and the daemon to crash. This issue has been patched in versions 5.9.5 and 5.10.pre2.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="1" name="net-snmp-devel" release="7.u4" version="5.9.1">
					<filename>net-snmp-devel-5.9.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/net-snmp-devel-5.9.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-libs" release="7.u4" version="5.9.1">
					<filename>net-snmp-libs-5.9.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/net-snmp-libs-5.9.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-perl" release="7.u4" version="5.9.1">
					<filename>net-snmp-perl-5.9.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/net-snmp-perl-5.9.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp" release="7.u4" version="5.9.1">
					<filename>net-snmp-5.9.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/net-snmp-5.9.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="net-snmp-gui" release="7.u4" version="5.9.1">
					<filename>net-snmp-gui-5.9.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/net-snmp-gui-5.9.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="python3-net-snmp" release="7.u4" version="5.9.1">
					<filename>python3-net-snmp-5.9.1-7.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-net-snmp-5.9.1-7.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="net-snmp-help" release="7.u4" version="5.9.1">
					<filename>net-snmp-help-5.9.1-7.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/net-snmp-help-5.9.1-7.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-gui" release="7.u4" version="5.9.1">
					<filename>net-snmp-gui-5.9.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/net-snmp-gui-5.9.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-perl" release="7.u4" version="5.9.1">
					<filename>net-snmp-perl-5.9.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/net-snmp-perl-5.9.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-libs" release="7.u4" version="5.9.1">
					<filename>net-snmp-libs-5.9.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/net-snmp-libs-5.9.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp" release="7.u4" version="5.9.1">
					<filename>net-snmp-5.9.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/net-snmp-5.9.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="net-snmp-devel" release="7.u4" version="5.9.1">
					<filename>net-snmp-devel-5.9.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/net-snmp-devel-5.9.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="python3-net-snmp" release="7.u4" version="5.9.1">
					<filename>python3-net-snmp-5.9.1-7.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-net-snmp-5.9.1-7.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3054</id>
		<title>An update for podman is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37298&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-37298" id="CVE-2024-37298" title="CVE-2024-37298" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-0778" id="CVE-2023-0778" title="CVE-2023-0778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2989&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-2989" id="CVE-2022-2989" title="CVE-2022-2989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-27649&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-27649" id="CVE-2022-27649" title="CVE-2022-27649" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22872&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22872" id="CVE-2025-22872" title="CVE-2025-22872" type="cve"></reference>
		</references>
		<description>CVE-2024-37298:gorilla/schema converts structs to and from form values. Prior to version 1.4.1 Running `schema.Decoder.Decode()` on a struct that has a field of type `[]struct{...}` opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. Any use of `schema.Decoder.Decode()` on a struct with arrays of other structs could be vulnerable to this memory exhaustion vulnerability. Version 1.4.1 contains a patch for the issue.&#xA;CVE-2023-0778:A Time-of-check Time-of-use (TOCTOU) flaw was found in podman. This issue may allow a malicious user to replace a normal file in a volume with a symlink while exporting the volume, allowing for access to arbitrary files on the host file system.&#xA;CVE-2022-2989:An incorrect handling of the supplementary groups in the Podman container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.&#xA;CVE-2022-27649:A flaw was found in Podman, where containers were started incorrectly with non-empty default permissions. A vulnerability was found in Moby (Docker Engine), where containers were started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs.&#xA;CVE-2025-22872:The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. &lt;math&gt;, &lt;svg&gt;, etc contexts).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="1" name="podman-gvproxy" release="9.u4" version="3.4.4">
					<filename>podman-gvproxy-3.4.4-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/podman-gvproxy-3.4.4-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman" release="9.u4" version="3.4.4">
					<filename>podman-3.4.4-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/podman-3.4.4-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman-remote" release="9.u4" version="3.4.4">
					<filename>podman-remote-3.4.4-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/podman-remote-3.4.4-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="podman-plugins" release="9.u4" version="3.4.4">
					<filename>podman-plugins-3.4.4-9.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/podman-plugins-3.4.4-9.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="podman-docker" release="9.u4" version="3.4.4">
					<filename>podman-docker-3.4.4-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/podman-docker-3.4.4-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="podman-help" release="9.u4" version="3.4.4">
					<filename>podman-help-3.4.4-9.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/podman-help-3.4.4-9.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-remote" release="9.u4" version="3.4.4">
					<filename>podman-remote-3.4.4-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/podman-remote-3.4.4-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-plugins" release="9.u4" version="3.4.4">
					<filename>podman-plugins-3.4.4-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/podman-plugins-3.4.4-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman" release="9.u4" version="3.4.4">
					<filename>podman-3.4.4-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/podman-3.4.4-9.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="podman-gvproxy" release="9.u4" version="3.4.4">
					<filename>podman-gvproxy-3.4.4-9.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/podman-gvproxy-3.4.4-9.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3055</id>
		<title>An update for python-tornado is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-67724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-67724" id="CVE-2025-67724" title="CVE-2025-67724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-67725&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-67725" id="CVE-2025-67725" title="CVE-2025-67725" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-67726&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-67726" id="CVE-2025-67726" title="CVE-2025-67726" type="cve"></reference>
		</references>
		<description>CVE-2025-67724:Tornado is a Python web framework and asynchronous networking library. In versions 6.5.2 and below, the supplied reason phrase is used unescaped in HTTP headers (where it could be used for header injection) or in HTML in the default error page (where it could be used for XSS) and can be exploited by passing untrusted or malicious data into the reason argument. Used by both RequestHandler.set_status and tornado.web.HTTPError, the argument is designed to allow applications to pass custom &#34;reason&#34; phrases (the &#34;Not Found&#34; in HTTP/1.1 404 Not Found) to the HTTP status line (mainly for non-standard status codes). This issue is fixed in version 6.5.3.&#xA;CVE-2025-67725:Tornado is a Python web framework and asynchronous networking library. In versions 6.5.2 and below, a single maliciously crafted HTTP request can block the server&#39;s event loop for an extended period, caused by the HTTPHeaders.add method. The function accumulates values using string concatenation when the same header name is repeated, causing a Denial of Service (DoS).  Due to Python string immutability, each concatenation copies the entire string, resulting in O(n²) time complexity. The severity can vary from high if max_header_size has been increased from its default, to low if it has its default value of 64KB. This issue is fixed in version 6.5.3.&#xA;CVE-2025-67726:Tornado is a Python web framework and asynchronous networking library. Versions 6.5.2 and below use an inefficient algorithm when parsing parameters for HTTP header values, potentially causing a DoS. The _parseparam function in httputil.py is used to parse specific HTTP header values, such as those in multipart/form-data and repeatedly calls string.count() within a nested loop while processing quoted semicolons. If an attacker sends a request with a large number of maliciously crafted parameters in a Content-Disposition header, the server&#39;s CPU usage increases quadratically (O(n²)) during parsing. Due to Tornado&#39;s single event loop architecture, a single malicious request can cause the entire server to become unresponsive for an extended period. This issue is fixed in version 6.5.3.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="python-tornado-help" release="5.u4" version="6.1">
					<filename>python-tornado-help-6.1-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python-tornado-help-6.1-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-tornado" release="5.u4" version="6.1">
					<filename>python3-tornado-6.1-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-tornado-6.1-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python-tornado-help" release="5.u4" version="6.1">
					<filename>python-tornado-help-6.1-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python-tornado-help-6.1-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-tornado" release="5.u4" version="6.1">
					<filename>python3-tornado-6.1-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-tornado-6.1-5.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3056</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8354&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8354" id="CVE-2025-12464" title="CVE-2025-12464" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8354&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8354" id="CVE-2025-11234" title="CVE-2025-11234" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8354&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-8354" id="CVE-2024-8354" title="CVE-2024-8354" type="cve"></reference>
		</references>
		<description>CVE-2025-12464:A flaw was found in QEMU. An assertion failure was present in the usb_ep_get() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.&#xA;CVE-2025-11234:A flaw was found in QEMU. An assertion failure was present in the usb_ep_get() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.&#xA;CVE-2024-8354:A flaw was found in QEMU. An assertion failure was present in the usb_ep_get() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="112.u27" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-block-curl-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="112.u27" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-system-aarch64-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="112.u27" version="6.2.0">
					<filename>qemu-img-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-img-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="112.u27" version="6.2.0">
					<filename>qemu-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="112.u27" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-guest-agent-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="112.u27" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-system-x86_64-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="112.u27" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-system-riscv-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="112.u27" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-block-iscsi-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="112.u27" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-block-ssh-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="112.u27" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-hw-usb-host-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="112.u27" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-system-arm-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="112.u27" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-112.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/qemu-block-rbd-6.2.0-112.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="112.u27" version="6.2.0">
					<filename>qemu-seabios-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-seabios-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="112.u27" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-block-iscsi-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="112.u27" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-system-aarch64-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="112.u27" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-system-riscv-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="112.u27" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-block-curl-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="112.u27" version="6.2.0">
					<filename>qemu-img-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-img-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu" release="112.u27" version="6.2.0">
					<filename>qemu-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="112.u27" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-system-arm-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="112.u27" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-system-x86_64-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="112.u27" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-block-rbd-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="112.u27" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-hw-usb-host-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="112.u27" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-guest-agent-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="112.u27" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-112.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-block-ssh-6.2.0-112.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="112.u27" version="6.2.0">
					<filename>qemu-help-6.2.0-112.u27.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/qemu-help-6.2.0-112.u27.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3057</id>
		<title>An update for libxslt is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11731&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11731" id="CVE-2025-11731" title="CVE-2025-11731" type="cve"></reference>
		</references>
		<description>CVE-2025-11731:A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT &lt;func:result&gt; elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="libxslt-devel" release="6.u5" version="1.1.37">
					<filename>libxslt-devel-1.1.37-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libxslt-devel-1.1.37-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt" release="6.u5" version="1.1.37">
					<filename>libxslt-1.1.37-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libxslt-1.1.37-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxslt" release="6.u5" version="1.1.37">
					<filename>python3-libxslt-1.1.37-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-libxslt-1.1.37-6.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxslt-help" release="6.u5" version="1.1.37">
					<filename>libxslt-help-1.1.37-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libxslt-help-1.1.37-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt" release="6.u5" version="1.1.37">
					<filename>libxslt-1.1.37-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libxslt-1.1.37-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt-devel" release="6.u5" version="1.1.37">
					<filename>libxslt-devel-1.1.37-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libxslt-devel-1.1.37-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxslt" release="6.u5" version="1.1.37">
					<filename>python3-libxslt-1.1.37-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-libxslt-1.1.37-6.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3058</id>
		<title>An update for audiofile is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-13147&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2019-13147" id="CVE-2019-13147" title="CVE-2019-13147" type="cve"></reference>
		</references>
		<description>CVE-2019-13147:In Audio File Library (aka audiofile) 0.3.6, there exists one NULL pointer dereference bug in ulaw2linear_buf in G711.cpp in libmodules.a that allows an attacker to cause a denial of service via a crafted file.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="aarch64" epoch="0" name="audiofile-devel" release="30.u2" version="0.3.6">
					<filename>audiofile-devel-0.3.6-30.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/audiofile-devel-0.3.6-30.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="audiofile" release="30.u2" version="0.3.6">
					<filename>audiofile-0.3.6-30.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/audiofile-0.3.6-30.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="audiofile-help" release="30.u2" version="0.3.6">
					<filename>audiofile-help-0.3.6-30.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/audiofile-help-0.3.6-30.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="audiofile" release="30.u2" version="0.3.6">
					<filename>audiofile-0.3.6-30.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/audiofile-0.3.6-30.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="audiofile-devel" release="30.u2" version="0.3.6">
					<filename>audiofile-devel-0.3.6-30.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/audiofile-devel-0.3.6-30.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3059</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3015" id="CVE-2025-3015" title="CVE-2025-3015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3016&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3016" id="CVE-2025-3016" title="CVE-2025-3016" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3160" id="CVE-2025-3160" title="CVE-2025-3160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3159&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3159" id="CVE-2025-3159" title="CVE-2025-3159" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11277&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11277" id="CVE-2025-11277" title="CVE-2025-11277" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2152&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2152" id="CVE-2025-2152" title="CVE-2025-2152" type="cve"></reference>
		</references>
		<description>CVE-2025-3015:A vulnerability classified as critical has been found in Open Asset Import Library Assimp 5.4.3. This affects the function Assimp::ASEImporter::BuildUniqueRepresentation of the file code/AssetLib/ASE/ASELoader.cpp of the component ASE File Handler. The manipulation of the argument mIndices leads to out-of-bounds read. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 6.0 is able to address this issue. The patch is named 7c705fde418d68cca4e8eff56be01b2617b0d6fe. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-3016:A vulnerability classified as problematic was found in Open Asset Import Library Assimp 5.4.3. This vulnerability affects the function Assimp::MDLImporter::ParseTextureColorData of the file code/AssetLib/MDL/MDLMaterialLoader.cpp of the component MDL File Handler. The manipulation of the argument mWidth/mHeight leads to resource consumption. The attack can be initiated remotely. Upgrading to version 6.0 is able to address this issue. The name of the patch is 5d2a7482312db2e866439a8c05a07ce1e718bed1. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-3160:A vulnerability has been found in Open Asset Import Library Assimp 5.4.3 and classified as problematic. This vulnerability affects the function Assimp::SceneCombiner::AddNodeHashes of the file code/Common/SceneCombiner.cpp of the component File Handler. The manipulation leads to out-of-bounds read. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as a0993658f40d8e13ff5823990c30b43c82a5daf0. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-3159:A vulnerability, which was classified as critical, was found in Open Asset Import Library Assimp 5.4.3. This affects the function Assimp::ASE::Parser::ParseLV4MeshBonesVertices of the file code/AssetLib/ASE/ASEParser.cpp of the component ASE File Handler. The manipulation leads to heap-based buffer overflow. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is e8a6286542924e628e02749c4f5ac4f91fdae71b. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-11277:A weakness has been identified in Open Asset Import Library Assimp 6.0.2. This affects the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. Executing manipulation can lead to heap-based buffer overflow. The attack needs to be launched locally. The exploit has been made available to the public and could be exploited.&#xA;CVE-2025-2152:A vulnerability, which was classified as critical, has been found in Open Asset Import Library Assimp 5.4.3. This issue affects the function Assimp::BaseImporter::ConvertToUTF8 of the file BaseImporter.cpp of the component File Handler. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python3-assimp" release="8.u6" version="5.2.4">
					<filename>python3-assimp-5.2.4-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-assimp-5.2.4-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="assimp-help" release="8.u6" version="5.2.4">
					<filename>assimp-help-5.2.4-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/assimp-help-5.2.4-8.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="8.u6" version="5.2.4">
					<filename>assimp-devel-5.2.4-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/assimp-devel-5.2.4-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp" release="8.u6" version="5.2.4">
					<filename>assimp-5.2.4-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/assimp-5.2.4-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp" release="8.u6" version="5.2.4">
					<filename>assimp-5.2.4-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/assimp-5.2.4-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="8.u6" version="5.2.4">
					<filename>assimp-devel-5.2.4-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/assimp-devel-5.2.4-8.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3060</id>
		<title>An update for libarchive is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-60753&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-60753" id="CVE-2025-60753" title="CVE-2025-60753" type="cve"></reference>
		</references>
		<description>CVE-2025-60753:An issue was discovered in libarchive bsdtar before version 3.8.1 in function apply_substitution in file tar/subst.c when processing crafted -s substitution rules. This can cause unbounded memory allocation and lead to denial of service (Out-of-Memory crash).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="bsdcat" release="11.u9" version="3.5.2">
					<filename>bsdcat-3.5.2-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/bsdcat-3.5.2-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdtar" release="11.u9" version="3.5.2">
					<filename>bsdtar-3.5.2-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/bsdtar-3.5.2-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcpio" release="11.u9" version="3.5.2">
					<filename>bsdcpio-3.5.2-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/bsdcpio-3.5.2-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive" release="11.u9" version="3.5.2">
					<filename>libarchive-3.5.2-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libarchive-3.5.2-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive-devel" release="11.u9" version="3.5.2">
					<filename>libarchive-devel-3.5.2-11.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libarchive-devel-3.5.2-11.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libarchive-help" release="11.u9" version="3.5.2">
					<filename>libarchive-help-3.5.2-11.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/libarchive-help-3.5.2-11.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcat" release="11.u9" version="3.5.2">
					<filename>bsdcat-3.5.2-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/bsdcat-3.5.2-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcpio" release="11.u9" version="3.5.2">
					<filename>bsdcpio-3.5.2-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/bsdcpio-3.5.2-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive-devel" release="11.u9" version="3.5.2">
					<filename>libarchive-devel-3.5.2-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libarchive-devel-3.5.2-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive" release="11.u9" version="3.5.2">
					<filename>libarchive-3.5.2-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/libarchive-3.5.2-11.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdtar" release="11.u9" version="3.5.2">
					<filename>bsdtar-3.5.2-11.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/bsdtar-3.5.2-11.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3061</id>
		<title>An update for python-requests is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35195&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-35195" id="CVE-2024-35195" title="CVE-2024-35195" type="cve"></reference>
		</references>
		<description>CVE-2024-35195:Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python-requests-help" release="11.u8" version="2.26.0">
					<filename>python-requests-help-2.26.0-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python-requests-help-2.26.0-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-requests" release="11.u8" version="2.26.0">
					<filename>python3-requests-2.26.0-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-requests-2.26.0-11.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3062</id>
		<title>An update for python-aiomysql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62611" id="CVE-2025-62611" title="CVE-2025-62611" type="cve"></reference>
		</references>
		<description>CVE-2025-62611:aiomysql is a library for accessing a MySQL database from the asyncio. Prior to version 0.3.0, the client-side settings are not checked before sending local files to MySQL server, which allows obtaining arbitrary files from the client using a rogue server. It is possible to create a rogue MySQL server that emulates authorization, ignores client flags and requests arbitrary files from the client by sending a LOAD_LOCAL instruction packet. This issue has been patched in version 0.3.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python-aiomysql-help" release="2.u1" version="0.0.21">
					<filename>python-aiomysql-help-0.0.21-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python-aiomysql-help-0.0.21-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-aiomysql" release="2.u1" version="0.0.21">
					<filename>python3-aiomysql-0.0.21-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-aiomysql-0.0.21-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3063</id>
		<title>An update for gnupg2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68973&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68973" id="CVE-2025-68973" title="CVE-2025-68973" type="cve"></reference>
		</references>
		<description>CVE-2025-68973:In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="gnupg2-help" release="9.u6" version="2.2.32">
					<filename>gnupg2-help-2.2.32-9.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gnupg2-help-2.2.32-9.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnupg2" release="9.u6" version="2.2.32">
					<filename>gnupg2-2.2.32-9.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/gnupg2-2.2.32-9.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnupg2" release="9.u6" version="2.2.32">
					<filename>gnupg2-2.2.32-9.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/gnupg2-2.2.32-9.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3064</id>
		<title>An update for spdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-57275&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-57275" id="CVE-2025-57275" title="CVE-2025-57275" type="cve"></reference>
		</references>
		<description>CVE-2025-57275:Storage Performance Development Kit (SPDK) 25.05 is vulnerable to Buffer Overflow in the NVMe-oF target component in SPDK - lib/nvmf.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="spdk-tools" release="19.u13" version="21.01.1">
					<filename>spdk-tools-21.01.1-19.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/spdk-tools-21.01.1-19.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="spdk" release="19.u13" version="21.01.1">
					<filename>spdk-21.01.1-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/spdk-21.01.1-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="spdk-devel" release="19.u13" version="21.01.1">
					<filename>spdk-devel-21.01.1-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/spdk-devel-21.01.1-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="spdk" release="19.u13" version="21.01.1">
					<filename>spdk-21.01.1-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/spdk-21.01.1-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="spdk-devel" release="19.u13" version="21.01.1">
					<filename>spdk-devel-21.01.1-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/spdk-devel-21.01.1-19.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3065</id>
		<title>An update for xnio is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-0084" id="CVE-2022-0084" title="CVE-2022-0084" type="cve"></reference>
		</references>
		<description>CVE-2022-0084:A flaw was found in XNIO, specifically in the notifyReadClosed method. The issue revealed this method was logging a message to another expected end. This flaw allows an attacker to send flawed requests to a server, possibly causing log contention-related performance concerns or an unwanted disk fill-up.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="xnio" release="12.u2" version="3.4.0">
					<filename>xnio-3.4.0-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xnio-3.4.0-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xnio-help" release="12.u2" version="3.4.0">
					<filename>xnio-help-3.4.0-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xnio-help-3.4.0-12.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3066</id>
		<title>An update for yaml-cpp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-11692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2017-11692" id="CVE-2017-11692" title="CVE-2017-11692" type="cve"></reference>
		</references>
		<description>CVE-2017-11692:The function &#34;Token&amp; Scanner::peek&#34; in scanner.cpp in yaml-cpp 0.5.3 and earlier allows remote attackers to cause a denial of service (assertion failure and application exit) via a &#39;!2&#39; string.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="yaml-cpp" release="3.u2" version="0.6.3">
					<filename>yaml-cpp-0.6.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/yaml-cpp-0.6.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="yaml-cpp-devel" release="3.u2" version="0.6.3">
					<filename>yaml-cpp-devel-0.6.3-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/yaml-cpp-devel-0.6.3-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yaml-cpp" release="3.u2" version="0.6.3">
					<filename>yaml-cpp-0.6.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/yaml-cpp-0.6.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="yaml-cpp-devel" release="3.u2" version="0.6.3">
					<filename>yaml-cpp-devel-0.6.3-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/yaml-cpp-devel-0.6.3-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3067</id>
		<title>An update for OpenEXR is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64181" id="CVE-2025-64181" title="CVE-2025-64181" type="cve"></reference>
		</references>
		<description>CVE-2025-64181:OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="OpenEXR" release="4.u3" version="3.1.5">
					<filename>OpenEXR-3.1.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/OpenEXR-3.1.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-libs" release="4.u3" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/OpenEXR-libs-3.1.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-devel" release="4.u3" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-4.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/OpenEXR-devel-3.1.5-4.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-libs" release="4.u3" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/OpenEXR-libs-3.1.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-devel" release="4.u3" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/OpenEXR-devel-3.1.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR" release="4.u3" version="3.1.5">
					<filename>OpenEXR-3.1.5-4.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/OpenEXR-3.1.5-4.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3068</id>
		<title>An update for xorg-x11-server is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49176" id="CVE-2025-49176" title="CVE-2025-49176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49737" id="CVE-2022-49737" title="CVE-2022-49737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49175&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49175" id="CVE-2025-49175" title="CVE-2025-49175" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49178&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49178" id="CVE-2025-49178" title="CVE-2025-49178" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49179&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49179" id="CVE-2025-49179" title="CVE-2025-49179" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49180&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-49180" id="CVE-2025-49180" title="CVE-2025-49180" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62229&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62229" id="CVE-2025-62229" title="CVE-2025-62229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62230&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62230" id="CVE-2025-62230" title="CVE-2025-62230" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62231&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62231" id="CVE-2025-62231" title="CVE-2025-62231" type="cve"></reference>
		</references>
		<description>CVE-2025-49176:A flaw was found in the Big Requests extension. The request length is multiplied by 4 before checking against the maximum allowed size, potentially causing an integer overflow and bypassing the size check.&#xA;CVE-2022-49737:In X.Org X server 20.11 through 21.1.16, when a client application uses easystroke for mouse gestures, the main thread modifies various data structures used by the input thread without acquiring a lock, aka a race condition. In particular, AttachDevice in dix/devices.c does not acquire an input lock.&#xA;CVE-2025-49175:A flaw was found in the X Rendering extension&#39;s handling of animated cursors. If a client provides no cursors, the server assumes at least one is present, leading to an out-of-bounds read and potential crash.&#xA;CVE-2025-49178:A flaw was found in the X server&#39;s request handling. Non-zero &#39;bytes to ignore&#39; in a client&#39;s request can cause the server to skip processing another client&#39;s request, potentially leading to a denial of service.&#xA;CVE-2025-49179:A flaw was found in the X Record extension. The RecordSanityCheckRegisterClients function does not check for an integer overflow when computing request length, which allows a client to bypass length checks.&#xA;CVE-2025-49180:A flaw was found in the RandR extension, where the RRChangeProviderProperty function does not properly validate input. This issue leads to an integer overflow when computing the total size to allocate.&#xA;CVE-2025-62229:A flaw was found in the X.Org X server and Xwayland when processing X11 Present extension notifications. Improper error handling during notification creation can leave dangling pointers that lead to a use-after-free condition. This can cause memory corruption or a crash, potentially allowing an attacker to execute arbitrary code or cause a denial of service.&#xA;CVE-2025-62230:A flaw was discovered in the X.Org X server’s X Keyboard (Xkb) extension when handling client resource cleanup. The software frees certain data structures without properly detaching related resources, leading to a use-after-free condition. This can cause memory corruption or a crash when affected clients disconnect.&#xA;CVE-2025-62231:A flaw was identified in the X.Org X server’s X Keyboard (Xkb) extension where improper bounds checking in the XkbSetCompatMap() function can cause an unsigned short overflow. If an attacker sends specially crafted input data, the value calculation may overflow, leading to memory corruption or a crash.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="0" name="xorg-x11-server" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xdmx" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-Xdmx-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xephyr" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-Xephyr-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-common" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-common-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xnest" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-Xnest-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-Xvfb" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-Xvfb-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xorg-x11-server-devel" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-42.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-devel-1.20.11-42.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xephyr" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xephyr-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-Xephyr-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xnest" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xnest-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-Xnest-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xvfb" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xvfb-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-Xvfb-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-Xdmx" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-Xdmx-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-Xdmx-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-common" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-common-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-common-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xorg-x11-server-devel" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-devel-1.20.11-42.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/xorg-x11-server-devel-1.20.11-42.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-source" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-source-1.20.11-42.u27.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-source-1.20.11-42.u27.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xorg-x11-server-help" release="42.u27" version="1.20.11">
					<filename>xorg-x11-server-help-1.20.11-42.u27.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/xorg-x11-server-help-1.20.11-42.u27.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3069</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-12084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-12084" id="CVE-2025-12084" title="CVE-2025-12084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13836&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13836" id="CVE-2025-13836" title="CVE-2025-13836" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13837&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13837" id="CVE-2025-13837" title="CVE-2025-13837" type="cve"></reference>
		</references>
		<description>CVE-2025-12084:When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.&#xA;CVE-2025-13836:When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.&#xA;CVE-2025-13837:When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="noarch" epoch="0" name="python3-help" release="50.u24" version="3.9.9">
					<filename>python3-help-3.9.9-50.u24.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-help-3.9.9-50.u24.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="50.u24" version="3.9.9">
					<filename>python3-3.9.9-50.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-3.9.9-50.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="50.u24" version="3.9.9">
					<filename>python3-devel-3.9.9-50.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-devel-3.9.9-50.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="50.u24" version="3.9.9">
					<filename>python3-debug-3.9.9-50.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-debug-3.9.9-50.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="50.u24" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-50.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/python3-unversioned-command-3.9.9-50.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="50.u24" version="3.9.9">
					<filename>python3-debug-3.9.9-50.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-debug-3.9.9-50.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="50.u24" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-50.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-unversioned-command-3.9.9-50.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3" release="50.u24" version="3.9.9">
					<filename>python3-3.9.9-50.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-3.9.9-50.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="50.u24" version="3.9.9">
					<filename>python3-devel-3.9.9-50.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/python3-devel-3.9.9-50.u24.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3070</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-02-12"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5601&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5601" id="CVE-2025-5601" title="CVE-2025-5601" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11596&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-11596" id="CVE-2024-11596" title="CVE-2024-11596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-9817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-9817" id="CVE-2025-9817" title="CVE-2025-9817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11626&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11626" id="CVE-2025-11626" title="CVE-2025-11626" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13499&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13499" id="CVE-2025-13499" title="CVE-2025-13499" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13946&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13946" id="CVE-2025-13946" title="CVE-2025-13946" type="cve"></reference>
		</references>
		<description>CVE-2025-5601:Column handling crashes in Wireshark 4.4.0 to 4.4.6 and 4.2.0 to 4.2.12 allows denial of service via packet injection or crafted capture file&#xA;CVE-2024-11596:ECMP dissector crash in Wireshark 4.4.0 to 4.4.1 and 4.2.0 to 4.2.8 allows denial of service via packet injection or crafted capture file&#xA;CVE-2025-9817:SSH dissector crash in Wireshark 4.4.0 to 4.4.8 allows denial of service&#xA;CVE-2025-11626:MONGO dissector infinite loop in Wireshark 4.4.0 to 4.4.9 and 4.2.0 to 4.2.13 allows denial of service&#xA;CVE-2025-13499:Kafka dissector crash in Wireshark 4.6.0 and 4.4.0 to 4.4.10 allows denial of service&#xA;CVE-2025-13946:MEGACO dissector infinite loop in Wireshark 4.6.0 to 4.6.1 and 4.4.0 to 4.4.11 allows denial of service&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.30.1</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="3.u14" version="4.4.10">
					<filename>wireshark-4.4.10-3.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/wireshark-4.4.10-3.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="3.u14" version="4.4.10">
					<filename>wireshark-devel-4.4.10-3.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/wireshark-devel-4.4.10-3.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="wireshark-help" release="3.u14" version="4.4.10">
					<filename>wireshark-help-4.4.10-3.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.30.1/wireshark-help-4.4.10-3.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="3.u14" version="4.4.10">
					<filename>wireshark-4.4.10-3.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/wireshark-4.4.10-3.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="3.u14" version="4.4.10">
					<filename>wireshark-devel-4.4.10-3.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.30.1/wireshark-devel-4.4.10-3.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3071</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-11411&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-11411" id="CVE-2025-11411" title="CVE-2025-11411" type="cve"></reference>
		</references>
		<description>CVE-2025-11411:NLnet Labs Unbound up to and including version 1.24.1 is vulnerable to possible domain hijack attacks. Promiscuous NS RRSets that complement positive DNS replies in the authority section can be used to trick resolvers to update their delegation information for the zone. Usually these RRSets are used to update the resolver&#39;s knowledge of the zone&#39;s name servers. A malicious actor can exploit the possible poisonous effect by injecting NS RRSets (and possibly their respective address records) in a reply. This could be done for example by trying to spoof a packet or fragmentation attacks. Unbound would then proceed to update the NS RRSet data it already has since the new data has enough trust for it, i.e., in-zone data for the delegation point. Unbound 1.24.1 includes a fix that scrubs unsolicited NS RRSets (and their respective address records) from replies mitigating the possible poison effect. Unbound 1.24.2 includes an additional fix that scrubs unsolicited NS RRSets (and their respective address records) from YXDOMAIN and non-referral nodata replies, further mitigating the possible poison effect.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="unbound-help" release="21.u10" version="1.13.2">
					<filename>unbound-help-1.13.2-21.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/unbound-help-1.13.2-21.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="21.u10" version="1.13.2">
					<filename>python3-unbound-1.13.2-21.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-unbound-1.13.2-21.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound" release="21.u10" version="1.13.2">
					<filename>unbound-1.13.2-21.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/unbound-1.13.2-21.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-anchor" release="21.u10" version="1.13.2">
					<filename>unbound-anchor-1.13.2-21.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/unbound-anchor-1.13.2-21.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="21.u10" version="1.13.2">
					<filename>unbound-devel-1.13.2-21.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/unbound-devel-1.13.2-21.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="21.u10" version="1.13.2">
					<filename>unbound-libs-1.13.2-21.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/unbound-libs-1.13.2-21.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="21.u10" version="1.13.2">
					<filename>python3-unbound-1.13.2-21.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-unbound-1.13.2-21.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-anchor" release="21.u10" version="1.13.2">
					<filename>unbound-anchor-1.13.2-21.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/unbound-anchor-1.13.2-21.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="21.u10" version="1.13.2">
					<filename>unbound-devel-1.13.2-21.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/unbound-devel-1.13.2-21.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="21.u10" version="1.13.2">
					<filename>unbound-help-1.13.2-21.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/unbound-help-1.13.2-21.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="21.u10" version="1.13.2">
					<filename>unbound-libs-1.13.2-21.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/unbound-libs-1.13.2-21.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="21.u10" version="1.13.2">
					<filename>unbound-1.13.2-21.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/unbound-1.13.2-21.u10.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3072</id>
		<title>An update for fcgi is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23016&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23016" id="CVE-2025-23016" title="CVE-2025-23016" type="cve"></reference>
		</references>
		<description>CVE-2025-23016:FastCGI fcgi2 (aka fcgi) 2.x through 2.4.4 has an integer overflow (and resultant heap-based buffer overflow) via crafted nameLen or valueLen values in data to the IPC socket. This occurs in ReadParams in fcgiapp.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="fcgi" release="3.u2" version="2.4.2">
					<filename>fcgi-2.4.2-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/fcgi-2.4.2-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="fcgi-devel" release="3.u2" version="2.4.2">
					<filename>fcgi-devel-2.4.2-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/fcgi-devel-2.4.2-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fcgi" release="3.u2" version="2.4.2">
					<filename>fcgi-2.4.2-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/fcgi-2.4.2-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="fcgi-devel" release="3.u2" version="2.4.2">
					<filename>fcgi-devel-2.4.2-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/fcgi-devel-2.4.2-3.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3073</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-15281&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-15281" id="CVE-2025-15281" title="CVE-2025-15281" type="cve"></reference>
		</references>
		<description>CVE-2025-15281:Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="174.u34" version="2.34">
					<filename>glibc-devel-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-devel-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="174.u34" version="2.34">
					<filename>glibc-locale-archive-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-locale-archive-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="174.u34" version="2.34">
					<filename>glibc-all-langpacks-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-all-langpacks-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="174.u34" version="2.34">
					<filename>glibc-locale-source-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-locale-source-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="174.u34" version="2.34">
					<filename>nss_modules-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/nss_modules-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="174.u34" version="2.34">
					<filename>glibc-common-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-common-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="174.u34" version="2.34">
					<filename>glibc-nss-devel-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-nss-devel-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="174.u34" version="2.34">
					<filename>glibc-compat-2.17-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-compat-2.17-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="174.u34" version="2.34">
					<filename>libnsl-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libnsl-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc" release="174.u34" version="2.34">
					<filename>glibc-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="174.u34" version="2.34">
					<filename>glibc-debugutils-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-debugutils-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="174.u34" version="2.34">
					<filename>nscd-2.34-174.u34.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/nscd-2.34-174.u34.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="174.u34" version="2.34">
					<filename>glibc-help-2.34-174.u34.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glibc-help-2.34-174.u34.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="174.u34" version="2.34">
					<filename>glibc-nss-devel-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-nss-devel-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="174.u34" version="2.34">
					<filename>glibc-compat-2.17-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-compat-2.17-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="174.u34" version="2.34">
					<filename>glibc-devel-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-devel-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="174.u34" version="2.34">
					<filename>glibc-locale-source-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-locale-source-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="174.u34" version="2.34">
					<filename>nss_modules-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/nss_modules-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="174.u34" version="2.34">
					<filename>glibc-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-common" release="174.u34" version="2.34">
					<filename>glibc-common-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-common-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="174.u34" version="2.34">
					<filename>glibc-all-langpacks-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-all-langpacks-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="174.u34" version="2.34">
					<filename>glibc-locale-archive-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-locale-archive-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="174.u34" version="2.34">
					<filename>glibc-debugutils-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glibc-debugutils-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="174.u34" version="2.34">
					<filename>libnsl-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libnsl-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="174.u34" version="2.34">
					<filename>nscd-2.34-174.u34.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/nscd-2.34-174.u34.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3074</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58098&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58098" id="CVE-2025-58098" title="CVE-2025-58098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-65082&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-65082" id="CVE-2025-65082" title="CVE-2025-65082" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-55753&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-55753" id="CVE-2025-55753" title="CVE-2025-55753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66200&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66200" id="CVE-2025-66200" title="CVE-2025-66200" type="cve"></reference>
		</references>
		<description>CVE-2025-58098:Apache HTTP Server 2.4.65 and earlier with Server Side Includes (SSI) enabled and mod_cgid (but not mod_cgi) passes the shell-escaped query string to #exec cmd=&#34;...&#34; directives.&#xA;&#xA;This issue affects Apache HTTP Server before 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.66, which fixes the issue.&#xA;CVE-2025-65082:Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache HTTP Server through environment variables set via the Apache configuration unexpectedly superseding variables calculated by the server for CGI programs.&#xA;&#xA;This issue affects Apache HTTP Server from 2.4.0 through 2.4.65.&#xA;&#xA;Users are recommended to upgrade to version 2.4.66 which fixes the issue.&#xA;CVE-2025-55753:An integer overflow in the case of failed ACME certificate renewal leads, after a number of failures (~30 days in default configurations), to the backoff timer becoming 0. Attempts to renew the certificate then are repeated without delays until it succeeds.&#xA;&#xA;This issue affects Apache HTTP Server: from 2.4.30 before 2.4.66.&#xA;&#xA;&#xA;Users are recommended to upgrade to version 2.4.66, which fixes the issue.&#xA;CVE-2025-66200:mod_userdir+suexec bypass via AllowOverride FileInfo vulnerability in Apache HTTP Server. Users with access to use the RequestHeader directive in htaccess can cause some CGI scripts to run under an unexpected userid.&#xA;&#xA;This issue affects Apache HTTP Server: from 2.4.7 through 2.4.65.&#xA;&#xA;Users are recommended to upgrade to version 2.4.66, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="httpd" release="27.u17" version="2.4.51">
					<filename>httpd-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/httpd-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="27.u17" version="2.4.51">
					<filename>mod_session-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mod_session-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="27.u17" version="2.4.51">
					<filename>httpd-tools-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/httpd-tools-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="27.u17" version="2.4.51">
					<filename>mod_ssl-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mod_ssl-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="27.u17" version="2.4.51">
					<filename>mod_ldap-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mod_ldap-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="27.u17" version="2.4.51">
					<filename>mod_md-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mod_md-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="27.u17" version="2.4.51">
					<filename>httpd-devel-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/httpd-devel-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="27.u17" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-27.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mod_proxy_html-2.4.51-27.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="27.u17" version="2.4.51">
					<filename>mod_md-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mod_md-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="27.u17" version="2.4.51">
					<filename>httpd-devel-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/httpd-devel-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="27.u17" version="2.4.51">
					<filename>httpd-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/httpd-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="27.u17" version="2.4.51">
					<filename>mod_ldap-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mod_ldap-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="27.u17" version="2.4.51">
					<filename>mod_session-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mod_session-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="27.u17" version="2.4.51">
					<filename>mod_ssl-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mod_ssl-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="27.u17" version="2.4.51">
					<filename>httpd-tools-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/httpd-tools-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="27.u17" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-27.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mod_proxy_html-2.4.51-27.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="27.u17" version="2.4.51">
					<filename>httpd-help-2.4.51-27.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/httpd-help-2.4.51-27.u17.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="27.u17" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-27.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/httpd-filesystem-2.4.51-27.u17.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3075</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39810&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-39810" id="CVE-2023-39810" title="CVE-2023-39810" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68171" id="CVE-2025-68171" title="CVE-2025-68171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68734&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68734" id="CVE-2025-68734" title="CVE-2025-68734" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68745&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68745" id="CVE-2025-68745" title="CVE-2025-68745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50746&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50746" id="CVE-2022-50746" title="CVE-2022-50746" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38211&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38211" id="CVE-2025-38211" title="CVE-2025-38211" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38375&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38375" id="CVE-2025-38375" title="CVE-2025-38375" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68349&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68349" id="CVE-2025-68349" title="CVE-2025-68349" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39969&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39969" id="CVE-2025-39969" title="CVE-2025-39969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39949&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39949" id="CVE-2025-39949" title="CVE-2025-39949" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39970&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39970" id="CVE-2025-39970" title="CVE-2025-39970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39931&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39931" id="CVE-2025-39931" title="CVE-2025-39931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40016&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40016" id="CVE-2025-40016" title="CVE-2025-40016" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39825&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39825" id="CVE-2025-39825" title="CVE-2025-39825" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50737" id="CVE-2022-50737" title="CVE-2022-50737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38102&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38102" id="CVE-2025-38102" title="CVE-2025-38102" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-21823" id="CVE-2024-21823" title="CVE-2024-21823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38103&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38103" id="CVE-2025-38103" title="CVE-2025-38103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39968&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39968" id="CVE-2025-39968" title="CVE-2025-39968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39691" id="CVE-2025-39691" title="CVE-2025-39691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68241&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68241" id="CVE-2025-68241" title="CVE-2025-68241" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68354&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68354" id="CVE-2025-68354" title="CVE-2025-68354" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53680&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53680" id="CVE-2023-53680" title="CVE-2023-53680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71125" id="CVE-2025-71125" title="CVE-2025-71125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40259&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40259" id="CVE-2025-40259" title="CVE-2025-40259" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50583&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50583" id="CVE-2022-50583" title="CVE-2022-50583" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38051&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38051" id="CVE-2025-38051" title="CVE-2025-38051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53794&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53794" id="CVE-2023-53794" title="CVE-2023-53794" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68229&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68229" id="CVE-2025-68229" title="CVE-2025-68229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49157" id="CVE-2022-49157" title="CVE-2022-49157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37768&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37768" id="CVE-2025-37768" title="CVE-2025-37768" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39823&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39823" id="CVE-2025-39823" title="CVE-2025-39823" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54263&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54263" id="CVE-2023-54263" title="CVE-2023-54263" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68789&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68789" id="CVE-2025-68789" title="CVE-2025-68789" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71093&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71093" id="CVE-2025-71093" title="CVE-2025-71093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71087&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71087" id="CVE-2025-71087" title="CVE-2025-71087" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37740&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37740" id="CVE-2025-37740" title="CVE-2025-37740" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38342&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38342" id="CVE-2025-38342" title="CVE-2025-38342" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71104&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71104" id="CVE-2025-71104" title="CVE-2025-71104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39951&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39951" id="CVE-2025-39951" title="CVE-2025-39951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68800&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68800" id="CVE-2025-68800" title="CVE-2025-68800" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68801&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68801" id="CVE-2025-68801" title="CVE-2025-68801" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39856" id="CVE-2025-39856" title="CVE-2025-39856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39864&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39864" id="CVE-2025-39864" title="CVE-2025-39864" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38111&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38111" id="CVE-2025-38111" title="CVE-2025-38111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38697" id="CVE-2025-38697" title="CVE-2025-38697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38714&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38714" id="CVE-2025-38714" title="CVE-2025-38714" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38713&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38713" id="CVE-2025-38713" title="CVE-2025-38713" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38712&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38712" id="CVE-2025-38712" title="CVE-2025-38712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38705&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38705" id="CVE-2025-38705" title="CVE-2025-38705" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39737&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39737" id="CVE-2025-39737" title="CVE-2025-39737" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39839&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39839" id="CVE-2025-39839" title="CVE-2025-39839" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38512&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38512" id="CVE-2025-38512" title="CVE-2025-38512" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39828&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39828" id="CVE-2025-39828" title="CVE-2025-39828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38728" id="CVE-2025-38728" title="CVE-2025-38728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50151&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50151" id="CVE-2022-50151" title="CVE-2022-50151" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68223&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68223" id="CVE-2025-68223" title="CVE-2025-68223" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38676&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38676" id="CVE-2025-38676" title="CVE-2025-38676" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38556&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38556" id="CVE-2025-38556" title="CVE-2025-38556" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50159&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50159" id="CVE-2022-50159" title="CVE-2022-50159" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37766&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37766" id="CVE-2025-37766" title="CVE-2025-37766" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49190&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49190" id="CVE-2022-49190" title="CVE-2022-49190" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49309&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49309" id="CVE-2022-49309" title="CVE-2022-49309" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53594&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53594" id="CVE-2023-53594" title="CVE-2023-53594" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53596&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53596" id="CVE-2023-53596" title="CVE-2023-53596" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53840&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53840" id="CVE-2023-53840" title="CVE-2023-53840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40346&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40346" id="CVE-2025-40346" title="CVE-2025-40346" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54321&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54321" id="CVE-2023-54321" title="CVE-2023-54321" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38024&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38024" id="CVE-2025-38024" title="CVE-2025-38024" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38004" id="CVE-2025-38004" title="CVE-2025-38004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38154&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38154" id="CVE-2025-38154" title="CVE-2025-38154" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52927&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52927" id="CVE-2023-52927" title="CVE-2023-52927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39797&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39797" id="CVE-2025-39797" title="CVE-2025-39797" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40215&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40215" id="CVE-2025-40215" title="CVE-2025-40215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21981&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21981" id="CVE-2025-21981" title="CVE-2025-21981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23138&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23138" id="CVE-2025-23138" title="CVE-2025-23138" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49829&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49829" id="CVE-2022-49829" title="CVE-2022-49829" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37770&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37770" id="CVE-2025-37770" title="CVE-2025-37770" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38480&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38480" id="CVE-2025-38480" title="CVE-2025-38480" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39945&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39945" id="CVE-2025-39945" title="CVE-2025-39945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39835&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39835" id="CVE-2025-39835" title="CVE-2025-39835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37947&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37947" id="CVE-2025-37947" title="CVE-2025-37947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71067&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71067" id="CVE-2025-71067" title="CVE-2025-71067" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22998&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22998" id="CVE-2026-22998" title="CVE-2026-22998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40342&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40342" id="CVE-2025-40342" title="CVE-2025-40342" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50616&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50616" id="CVE-2022-50616" title="CVE-2022-50616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39749&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39749" id="CVE-2025-39749" title="CVE-2025-39749" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23038&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23038" id="CVE-2026-23038" title="CVE-2026-23038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53521&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53521" id="CVE-2023-53521" title="CVE-2023-53521" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68819&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68819" id="CVE-2025-68819" title="CVE-2025-68819" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71084" id="CVE-2025-71084" title="CVE-2025-71084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68192&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68192" id="CVE-2025-68192" title="CVE-2025-68192" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38574&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38574" id="CVE-2025-38574" title="CVE-2025-38574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54048&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54048" id="CVE-2023-54048" title="CVE-2023-54048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50735&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50735" id="CVE-2022-50735" title="CVE-2022-50735" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53179&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53179" id="CVE-2024-53179" title="CVE-2024-53179" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71120&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71120" id="CVE-2025-71120" title="CVE-2025-71120" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39744&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39744" id="CVE-2025-39744" title="CVE-2025-39744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71091&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71091" id="CVE-2025-71091" title="CVE-2025-71091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53250&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53250" id="CVE-2023-53250" title="CVE-2023-53250" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39902&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39902" id="CVE-2025-39902" title="CVE-2025-39902" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54145&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54145" id="CVE-2023-54145" title="CVE-2023-54145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39676&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39676" id="CVE-2025-39676" title="CVE-2025-39676" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38068&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38068" id="CVE-2025-38068" title="CVE-2025-38068" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23001&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23001" id="CVE-2026-23001" title="CVE-2026-23001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22999&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22999" id="CVE-2026-22999" title="CVE-2026-22999" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71085" id="CVE-2025-71085" title="CVE-2025-71085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40280&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40280" id="CVE-2025-40280" title="CVE-2025-40280" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68285&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68285" id="CVE-2025-68285" title="CVE-2025-68285" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39913&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39913" id="CVE-2025-39913" title="CVE-2025-39913" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38718&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38718" id="CVE-2025-38718" title="CVE-2025-38718" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39702&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39702" id="CVE-2025-39702" title="CVE-2025-39702" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39853&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39853" id="CVE-2025-39853" title="CVE-2025-39853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39860&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39860" id="CVE-2025-39860" title="CVE-2025-39860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39957&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39957" id="CVE-2025-39957" title="CVE-2025-39957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53712&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53712" id="CVE-2023-53712" title="CVE-2023-53712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23085" id="CVE-2026-23085" title="CVE-2026-23085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23107&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23107" id="CVE-2026-23107" title="CVE-2026-23107" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22990&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22990" id="CVE-2026-22990" title="CVE-2026-22990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23050" id="CVE-2026-23050" title="CVE-2026-23050" type="cve"></reference>
		</references>
		<description>CVE-2023-39810:An issue in the CPIO command of Busybox v1.33.2 allows attackers to execute a directory traversal.&#xA;CVE-2025-68171:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/fpu: Ensure XFD state on signal delivery&#xA;&#xA;Sean reported [1] the following splat when running KVM tests:&#xA;&#xA;   WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70&#xA;   Call Trace:&#xA;    &lt;TASK&gt;&#xA;    fpu__clear_user_states+0x9c/0x100&#xA;    arch_do_signal_or_restart+0x142/0x210&#xA;    exit_to_user_mode_loop+0x55/0x100&#xA;    do_syscall_64+0x205/0x2c0&#xA;    entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;Chao further identified [2] a reproducible scenario involving signal&#xA;delivery: a non-AMX task is preempted by an AMX-enabled task which&#xA;modifies the XFD MSR.&#xA;&#xA;When the non-AMX task resumes and reloads XSTATE with init values,&#xA;a warning is triggered due to a mismatch between fpstate::xfd and the&#xA;CPU&#39;s current XFD state. fpu__clear_user_states() does not currently&#xA;re-synchronize the XFD state after such preemption.&#xA;&#xA;Invoke xfd_update_state() which detects and corrects the mismatch if&#xA;there is a dynamic feature.&#xA;&#xA;This also benefits the sigreturn path, as fpu__restore_sig() may call&#xA;fpu__clear_user_states() when the sigframe is inaccessible.&#xA;&#xA;[ dhansen: minor changelog munging ]&#xA;CVE-2025-68734:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()&#xA;&#xA;In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when&#xA;setup_instance() fails with an error code. Fix that by freeing the urb&#xA;before freeing the hw structure. Also change the error paths to use the&#xA;goto ladder style.&#xA;&#xA;Compile tested only. Issue found using a prototype static analysis tool.&#xA;CVE-2025-68745:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Clear cmds after chip reset&#xA;&#xA;Commit aefed3e5548f (&#34;scsi: qla2xxx: target: Fix offline port handling&#xA;and host reset handling&#34;) caused two problems:&#xA;&#xA;1. Commands sent to FW, after chip reset got stuck and never freed as FW&#xA;   is not going to respond to them anymore.&#xA;&#xA;2. BUG_ON(cmd-&gt;sg_mapped) in qlt_free_cmd().  Commit 26f9ce53817a&#xA;   (&#34;scsi: qla2xxx: Fix missed DMA unmap for aborted commands&#34;)&#xA;   attempted to fix this, but introduced another bug under different&#xA;   circumstances when two different CPUs were racing to call&#xA;   qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in&#xA;   dma_unmap_sg_attrs().&#xA;&#xA;So revert &#34;scsi: qla2xxx: Fix missed DMA unmap for aborted commands&#34; and&#xA;partially revert &#34;scsi: qla2xxx: target: Fix offline port handling and&#xA;host reset handling&#34; at __qla2x00_abort_all_cmds.&#xA;CVE-2022-50746:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;erofs: validate the extent length for uncompressed pclusters&#xA;&#xA;syzkaller reported a KASAN use-after-free:&#xA;https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2&#xA;&#xA;The referenced fuzzed image actually has two issues:&#xA; - m_pa == 0 as a non-inlined pcluster;&#xA; - The logical length is longer than its physical length.&#xA;&#xA;The first issue has already been addressed.  This patch addresses&#xA;the second issue by checking the extent length validity.&#xA;CVE-2025-38211:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction&#xA;&#xA;The commit 59c68ac31e15 (&#34;iw_cm: free cm_id resources on the last&#xA;deref&#34;) simplified cm_id resource management by freeing cm_id once all&#xA;references to the cm_id were removed. The references are removed either&#xA;upon completion of iw_cm event handlers or when the application destroys&#xA;the cm_id. This commit introduced the use-after-free condition where&#xA;cm_id_private object could still be in use by event handler works during&#xA;the destruction of cm_id. The commit aee2424246f9 (&#34;RDMA/iwcm: Fix a&#xA;use-after-free related to destroying CM IDs&#34;) addressed this use-after-&#xA;free by flushing all pending works at the cm_id destruction.&#xA;&#xA;However, still another use-after-free possibility remained. It happens&#xA;with the work objects allocated for each cm_id_priv within&#xA;alloc_work_entries() during cm_id creation, and subsequently freed in&#xA;dealloc_work_entries() once all references to the cm_id are removed.&#xA;If the cm_id&#39;s last reference is decremented in the event handler work,&#xA;the work object for the work itself gets removed, and causes the use-&#xA;after-free BUG below:&#xA;&#xA;  BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250&#xA;  Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091&#xA;&#xA;  CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014&#xA;  Workqueue:  0x0 (iw_cm_wq)&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x6a/0x90&#xA;   print_report+0x174/0x554&#xA;   ? __virt_addr_valid+0x208/0x430&#xA;   ? __pwq_activate_work+0x1ff/0x250&#xA;   kasan_report+0xae/0x170&#xA;   ? __pwq_activate_work+0x1ff/0x250&#xA;   __pwq_activate_work+0x1ff/0x250&#xA;   pwq_dec_nr_in_flight+0x8c5/0xfb0&#xA;   process_one_work+0xc11/0x1460&#xA;   ? __pfx_process_one_work+0x10/0x10&#xA;   ? assign_work+0x16c/0x240&#xA;   worker_thread+0x5ef/0xfd0&#xA;   ? __pfx_worker_thread+0x10/0x10&#xA;   kthread+0x3b0/0x770&#xA;   ? __pfx_kthread+0x10/0x10&#xA;   ? rcu_is_watching+0x11/0xb0&#xA;   ? _raw_spin_unlock_irq+0x24/0x50&#xA;   ? rcu_is_watching+0x11/0xb0&#xA;   ? __pfx_kthread+0x10/0x10&#xA;   ret_from_fork+0x30/0x70&#xA;   ? __pfx_kthread+0x10/0x10&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;   &lt;/TASK&gt;&#xA;&#xA;  Allocated by task 147416:&#xA;   kasan_save_stack+0x2c/0x50&#xA;   kasan_save_track+0x10/0x30&#xA;   __kasan_kmalloc+0xa6/0xb0&#xA;   alloc_work_entries+0xa9/0x260 [iw_cm]&#xA;   iw_cm_connect+0x23/0x4a0 [iw_cm]&#xA;   rdma_connect_locked+0xbfd/0x1920 [rdma_cm]&#xA;   nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]&#xA;   cma_cm_event_handler+0xae/0x320 [rdma_cm]&#xA;   cma_work_handler+0x106/0x1b0 [rdma_cm]&#xA;   process_one_work+0x84f/0x1460&#xA;   worker_thread+0x5ef/0xfd0&#xA;   kthread+0x3b0/0x770&#xA;   ret_from_fork+0x30/0x70&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;&#xA;  Freed by task 147091:&#xA;   kasan_save_stack+0x2c/0x50&#xA;   kasan_save_track+0x10/0x30&#xA;   kasan_save_free_info+0x37/0x60&#xA;   __kasan_slab_free+0x4b/0x70&#xA;   kfree+0x13a/0x4b0&#xA;   dealloc_work_entries+0x125/0x1f0 [iw_cm]&#xA;   iwcm_deref_id+0x6f/0xa0 [iw_cm]&#xA;   cm_work_handler+0x136/0x1ba0 [iw_cm]&#xA;   process_one_work+0x84f/0x1460&#xA;   worker_thread+0x5ef/0xfd0&#xA;   kthread+0x3b0/0x770&#xA;   ret_from_fork+0x30/0x70&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;&#xA;  Last potentially related work creation:&#xA;   kasan_save_stack+0x2c/0x50&#xA;   kasan_record_aux_stack+0xa3/0xb0&#xA;   __queue_work+0x2ff/0x1390&#xA;   queue_work_on+0x67/0xc0&#xA;   cm_event_handler+0x46a/0x820 [iw_cm]&#xA;   siw_cm_upcall+0x330/0x650 [siw]&#xA;   siw_cm_work_handler+0x6b9/0x2b20 [siw]&#xA;   process_one_work+0x84f/0x1460&#xA;   worker_thread+0x5ef/0xfd0&#xA;   kthread+0x3b0/0x770&#xA;   ret_from_fork+0x30/0x70&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;&#xA;This BUG is reproducible by repeating the blktests test case nvme/061&#xA;for the rdma transport and the siw driver.&#xA;&#xA;To avoid the use-after-free of cm_id_private work objects, ensure that&#xA;the last reference to the cm_id is decremented not in the event handler&#xA;works, but in the cm_id destruction context. For that purpose, mo&#xA;---truncated---&#xA;CVE-2025-38375:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;virtio-net: ensure the received length does not exceed allocated size&#xA;&#xA;In xdp_linearize_page, when reading the following buffers from the ring,&#xA;we forget to check the received length with the true allocate size. This&#xA;can lead to an out-of-bound read. This commit adds that missing check.&#xA;CVE-2025-68349:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid&#xA;&#xA;Fixes a crash when layout is null during this call stack:&#xA;&#xA;write_inode&#xA;    -&gt; nfs4_write_inode&#xA;        -&gt; pnfs_layoutcommit_inode&#xA;&#xA;pnfs_set_layoutcommit relies on the lseg refcount to keep the layout&#xA;around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt&#xA;to reference a null layout.&#xA;CVE-2025-39969:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: fix validation of VF state in get resources&#xA;&#xA;VF state I40E_VF_STATE_ACTIVE is not the only state in which&#xA;VF is actually active so it should not be used to determine&#xA;if a VF is allowed to obtain resources.&#xA;&#xA;Use I40E_VF_STATE_RESOURCES_LOADED that is set only in&#xA;i40e_vc_get_vf_resources_msg() and cleared during reset.&#xA;CVE-2025-39949:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;qed: Don&#39;t collect too many protection override GRC elements&#xA;&#xA;In the protection override dump path, the firmware can return far too&#xA;many GRC elements, resulting in attempting to write past the end of the&#xA;previously-kmalloc&#39;ed dump buffer.&#xA;&#xA;This will result in a kernel panic with reason:&#xA;&#xA; BUG: unable to handle kernel paging request at ADDRESS&#xA;&#xA;where &#34;ADDRESS&#34; is just past the end of the protection override dump&#xA;buffer. The start address of the buffer is:&#xA; p_hwfn-&gt;cdev-&gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf&#xA;and the size of the buffer is buf_size in the same data structure.&#xA;&#xA;The panic can be arrived at from either the qede Ethernet driver path:&#xA;&#xA;    [exception RIP: qed_grc_dump_addr_range+0x108]&#xA; qed_protection_override_dump at ffffffffc02662ed [qed]&#xA; qed_dbg_protection_override_dump at ffffffffc0267792 [qed]&#xA; qed_dbg_feature at ffffffffc026aa8f [qed]&#xA; qed_dbg_all_data at ffffffffc026b211 [qed]&#xA; qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]&#xA; devlink_health_do_dump at ffffffff82497f61&#xA; devlink_health_report at ffffffff8249cf29&#xA; qed_report_fatal_error at ffffffffc0272baf [qed]&#xA; qede_sp_task at ffffffffc045ed32 [qede]&#xA; process_one_work at ffffffff81d19783&#xA;&#xA;or the qedf storage driver path:&#xA;&#xA;    [exception RIP: qed_grc_dump_addr_range+0x108]&#xA; qed_protection_override_dump at ffffffffc068b2ed [qed]&#xA; qed_dbg_protection_override_dump at ffffffffc068c792 [qed]&#xA; qed_dbg_feature at ffffffffc068fa8f [qed]&#xA; qed_dbg_all_data at ffffffffc0690211 [qed]&#xA; qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]&#xA; devlink_health_do_dump at ffffffff8aa95e51&#xA; devlink_health_report at ffffffff8aa9ae19&#xA; qed_report_fatal_error at ffffffffc0697baf [qed]&#xA; qed_hw_err_notify at ffffffffc06d32d7 [qed]&#xA; qed_spq_post at ffffffffc06b1011 [qed]&#xA; qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]&#xA; qedf_cleanup_fcport at ffffffffc05e7597 [qedf]&#xA; qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]&#xA; fc_rport_work at ffffffffc02da715 [libfc]&#xA; process_one_work at ffffffff8a319663&#xA;&#xA;Resolve this by clamping the firmware&#39;s return value to the maximum&#xA;number of legal elements the firmware should return.&#xA;CVE-2025-39970:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: fix input validation logic for action_meta&#xA;&#xA;Fix condition to check &#39;greater or equal&#39; to prevent OOB dereference.&#xA;CVE-2025-39931:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: af_alg - Set merge to zero early in af_alg_sendmsg&#xA;&#xA;If an error causes af_alg_sendmsg to abort, ctx-&gt;merge may contain&#xA;a garbage value from the previous loop.  This may then trigger a&#xA;crash on the next entry into af_alg_sendmsg when it attempts to do&#xA;a merge that can&#39;t be done.&#xA;&#xA;Fix this by setting ctx-&gt;merge to zero near the start of the loop.&#xA;CVE-2025-40016:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID&#xA;&#xA;Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero&#xA;unique ID.&#xA;&#xA;```&#xA;Each Unit and Terminal within the video function is assigned a unique&#xA;identification number, the Unit ID (UID) or Terminal ID (TID), contained in&#xA;the bUnitID or bTerminalID field of the descriptor. The value 0x00 is&#xA;reserved for undefined ID,&#xA;```&#xA;&#xA;If we add a new entity with id 0 or a duplicated ID, it will be marked&#xA;as UVC_INVALID_ENTITY_ID.&#xA;&#xA;In a previous attempt commit 3dd075fe8ebb (&#34;media: uvcvideo: Require&#xA;entities to have a non-zero unique ID&#34;), we ignored all the invalid units,&#xA;this broke a lot of non-compatible cameras. Hopefully we are more lucky&#xA;this time.&#xA;&#xA;This also prevents some syzkaller reproducers from triggering warnings due&#xA;to a chain of entities referring to themselves. In one particular case, an&#xA;Output Unit is connected to an Input Unit, both with the same ID of 1. But&#xA;when looking up for the source ID of the Output Unit, that same entity is&#xA;found instead of the input entity, which leads to such warnings.&#xA;&#xA;In another case, a backward chain was considered finished as the source ID&#xA;was 0. Later on, that entity was found, but its pads were not valid.&#xA;&#xA;Here is a sample stack trace for one of those cases.&#xA;&#xA;[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd&#xA;[   20.830206] usb 1-1: Using ep0 maxpacket: 8&#xA;[   20.833501] usb 1-1: config 0 descriptor??&#xA;[   21.038518] usb 1-1: string descriptor 0 read error: -71&#xA;[   21.038893] usb 1-1: Found UVC 0.00 device &lt;unnamed&gt; (2833:0201)&#xA;[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!&#xA;[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!&#xA;[   21.042218] ------------[ cut here ]------------&#xA;[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0&#xA;[   21.043195] Modules linked in:&#xA;[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444&#xA;[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014&#xA;[   21.044639] Workqueue: usb_hub_wq hub_event&#xA;[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0&#xA;[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 &lt;0f&gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00&#xA;[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246&#xA;[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1&#xA;[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290&#xA;[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000&#xA;[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003&#xA;[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000&#xA;[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000&#xA;[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0&#xA;[   21.051136] PKRU: 55555554&#xA;[   21.051331] Call Trace:&#xA;[   21.051480]  &lt;TASK&gt;&#xA;[   21.051611]  ? __warn+0xc4/0x210&#xA;[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0&#xA;[   21.052252]  ? report_bug+0x11b/0x1a0&#xA;[   21.052540]  ? trace_hardirqs_on+0x31/0x40&#xA;[   21.052901]  ? handle_bug+0x3d/0x70&#xA;[   21.053197]  ? exc_invalid_op+0x1a/0x50&#xA;[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[   21.053924]  ? media_create_pad_link+0x91/0x2e0&#xA;[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0&#xA;[   21.054834]  ? media_create_pad_link+0x91/0x2e0&#xA;[   21.055131]  ? _raw_spin_unlock+0x1e/0x40&#xA;[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210&#xA;[   21.055837]  uvc_mc_register_entities+0x358/0x400&#xA;[   21.056144]  uvc_register_chains+0x1&#xA;---truncated---&#xA;CVE-2025-39825:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: fix race with concurrent opens in rename(2)&#xA;&#xA;Besides sending the rename request to the server, the rename process&#xA;also involves closing any deferred close, waiting for outstanding I/O&#xA;to complete as well as marking all existing open handles as deleted to&#xA;prevent them from deferring closes, which increases the race window&#xA;for potential concurrent opens on the target file.&#xA;&#xA;Fix this by unhashing the dentry in advance to prevent any concurrent&#xA;opens on the target.&#xA;CVE-2022-50737:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Validate index root when initialize NTFS security&#xA;&#xA;This enhances the sanity check for $SDH and $SII while initializing NTFS&#xA;security, guarantees these index root are legit.&#xA;&#xA;[  162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243&#xA;[  162.460851]&#xA;[  162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42&#xA;[  162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;[  162.462609] Call Trace:&#xA;[  162.462954]  &lt;TASK&gt;&#xA;[  162.463276]  dump_stack_lvl+0x49/0x63&#xA;[  162.463822]  print_report.cold+0xf5/0x689&#xA;[  162.464608]  ? unwind_get_return_address+0x3a/0x60&#xA;[  162.465766]  ? hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.466975]  kasan_report+0xa7/0x130&#xA;[  162.467506]  ? _raw_spin_lock_irq+0xc0/0xf0&#xA;[  162.467998]  ? hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.468536]  __asan_load2+0x68/0x90&#xA;[  162.468923]  hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.469282]  ? cmp_uints+0xe0/0xe0&#xA;[  162.469557]  ? cmp_sdh+0x90/0x90&#xA;[  162.469864]  ? ni_find_attr+0x214/0x300&#xA;[  162.470217]  ? ni_load_mi+0x80/0x80&#xA;[  162.470479]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[  162.470931]  ? ntfs_bread_run+0x190/0x190&#xA;[  162.471307]  ? indx_get_root+0xe4/0x190&#xA;[  162.471556]  ? indx_get_root+0x140/0x190&#xA;[  162.471833]  ? indx_init+0x1e0/0x1e0&#xA;[  162.472069]  ? fnd_clear+0x115/0x140&#xA;[  162.472363]  ? _raw_spin_lock_irqsave+0x100/0x100&#xA;[  162.472731]  indx_find+0x184/0x470&#xA;[  162.473461]  ? sysvec_apic_timer_interrupt+0x57/0xc0&#xA;[  162.474429]  ? indx_find_buffer+0x2d0/0x2d0&#xA;[  162.474704]  ? do_syscall_64+0x3b/0x90&#xA;[  162.474962]  dir_search_u+0x196/0x2f0&#xA;[  162.475381]  ? ntfs_nls_to_utf16+0x450/0x450&#xA;[  162.475661]  ? ntfs_security_init+0x3d6/0x440&#xA;[  162.475906]  ? is_sd_valid+0x180/0x180&#xA;[  162.476191]  ntfs_extend_init+0x13f/0x2c0&#xA;[  162.476496]  ? ntfs_fix_post_read+0x130/0x130&#xA;[  162.476861]  ? iput.part.0+0x286/0x320&#xA;[  162.477325]  ntfs_fill_super+0x11e0/0x1b50&#xA;[  162.477709]  ? put_ntfs+0x1d0/0x1d0&#xA;[  162.477970]  ? vsprintf+0x20/0x20&#xA;[  162.478258]  ? set_blocksize+0x95/0x150&#xA;[  162.478538]  get_tree_bdev+0x232/0x370&#xA;[  162.478789]  ? put_ntfs+0x1d0/0x1d0&#xA;[  162.479038]  ntfs_fs_get_tree+0x15/0x20&#xA;[  162.479374]  vfs_get_tree+0x4c/0x130&#xA;[  162.479729]  path_mount+0x654/0xfe0&#xA;[  162.480124]  ? putname+0x80/0xa0&#xA;[  162.480484]  ? finish_automount+0x2e0/0x2e0&#xA;[  162.480894]  ? putname+0x80/0xa0&#xA;[  162.481467]  ? kmem_cache_free+0x1c4/0x440&#xA;[  162.482280]  ? putname+0x80/0xa0&#xA;[  162.482714]  do_mount+0xd6/0xf0&#xA;[  162.483264]  ? path_mount+0xfe0/0xfe0&#xA;[  162.484782]  ? __kasan_check_write+0x14/0x20&#xA;[  162.485593]  __x64_sys_mount+0xca/0x110&#xA;[  162.486024]  do_syscall_64+0x3b/0x90&#xA;[  162.486543]  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[  162.487141] RIP: 0033:0x7f9d374e948a&#xA;[  162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008&#xA;[  162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5&#xA;[  162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a&#xA;[  162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0&#xA;[  162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020&#xA;[  162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0&#xA;[  162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff&#xA;[  162.493644]  &lt;/TASK&gt;&#xA;[  162.493908]&#xA;[  162.494214] The buggy address belongs to the physical page:&#xA;[  162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc&#xA;[  162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)&#xA;[  162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000&#xA;[  162.498928] raw: 0000000000000000 0000000000240000 0&#xA;---truncated---&#xA;CVE-2025-38102:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify&#xA;&#xA;During our test, it is found that a warning can be trigger in try_grab_folio&#xA;as follow:&#xA;&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130&#xA;  Modules linked in:&#xA;  CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)&#xA;  RIP: 0010:try_grab_folio+0x106/0x130&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   follow_huge_pmd+0x240/0x8e0&#xA;   follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0&#xA;   follow_pud_mask.constprop.0.isra.0+0x14a/0x170&#xA;   follow_page_mask+0x1c2/0x1f0&#xA;   __get_user_pages+0x176/0x950&#xA;   __gup_longterm_locked+0x15b/0x1060&#xA;   ? gup_fast+0x120/0x1f0&#xA;   gup_fast_fallback+0x17e/0x230&#xA;   get_user_pages_fast+0x5f/0x80&#xA;   vmci_host_unlocked_ioctl+0x21c/0xf80&#xA;  RIP: 0033:0x54d2cd&#xA;  ---[ end trace 0000000000000000 ]---&#xA;&#xA;Digging into the source, context-&gt;notify_page may init by get_user_pages_fast&#xA;and can be seen in vmci_ctx_unset_notify which will try to put_page. However&#xA;get_user_pages_fast is not finished here and lead to following&#xA;try_grab_folio warning. The race condition is shown as follow:&#xA;&#xA;cpu0&#x9;&#x9;&#x9;cpu1&#xA;vmci_host_do_set_notify&#xA;vmci_host_setup_notify&#xA;get_user_pages_fast(uva, 1, FOLL_WRITE, &amp;context-&gt;notify_page);&#xA;lockless_pages_from_mm&#xA;gup_pgd_range&#xA;gup_huge_pmd  // update &amp;context-&gt;notify_page&#xA;&#x9;&#x9;&#x9;vmci_host_do_set_notify&#xA;&#x9;&#x9;&#x9;vmci_ctx_unset_notify&#xA;&#x9;&#x9;&#x9;notify_page = context-&gt;notify_page;&#xA;&#x9;&#x9;&#x9;if (notify_page)&#xA;&#x9;&#x9;&#x9;put_page(notify_page);&#x9;// page is freed&#xA;__gup_longterm_locked&#xA;__get_user_pages&#xA;follow_trans_huge_pmd&#xA;try_grab_folio // warn here&#xA;&#xA;To slove this, use local variable page to make notify_page can be seen&#xA;after finish get_user_pages_fast.&#xA;CVE-2024-21823:Hardware logic with insecure de-synchronization in Intel(R) DSA and Intel(R) IAA for some Intel(R) 4th or 5th generation Xeon(R) processors may allow an authorized user to potentially enable escalation of privilege local access&#xA;CVE-2025-38103:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()&#xA;&#xA;Update struct hid_descriptor to better reflect the mandatory and&#xA;optional parts of the HID Descriptor as per USB HID 1.11 specification.&#xA;Note: the kernel currently does not parse any optional HID class&#xA;descriptors, only the mandatory report descriptor.&#xA;&#xA;Update all references to member element desc[0] to rpt_desc.&#xA;&#xA;Add test to verify bLength and bNumDescriptors values are valid.&#xA;&#xA;Replace the for loop with direct access to the mandatory HID class&#xA;descriptor member for the report descriptor. This eliminates the&#xA;possibility of getting an out-of-bounds fault.&#xA;&#xA;Add a warning message if the HID descriptor contains any unsupported&#xA;optional HID class descriptors.&#xA;CVE-2025-39968:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: add max boundary check for VF filters&#xA;&#xA;There is no check for max filters that VF can request. Add it.&#xA;CVE-2025-39691:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/buffer: fix use-after-free when call bh_read() helper&#xA;&#xA;There&#39;s issue as follows:&#xA;BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110&#xA;Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0&#xA;CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl+0x55/0x70&#xA; print_address_description.constprop.0+0x2c/0x390&#xA; print_report+0xb4/0x270&#xA; kasan_report+0xb8/0xf0&#xA; end_buffer_read_sync+0xe3/0x110&#xA; end_bio_bh_io_sync+0x56/0x80&#xA; blk_update_request+0x30a/0x720&#xA; scsi_end_request+0x51/0x2b0&#xA; scsi_io_completion+0xe3/0x480&#xA; ? scsi_device_unbusy+0x11e/0x160&#xA; blk_complete_reqs+0x7b/0x90&#xA; handle_softirqs+0xef/0x370&#xA; irq_exit_rcu+0xa5/0xd0&#xA; sysvec_apic_timer_interrupt+0x6e/0x90&#xA; &lt;/IRQ&gt;&#xA;&#xA; Above issue happens when do ntfs3 filesystem mount, issue may happens&#xA; as follows:&#xA;           mount                            IRQ&#xA;ntfs_fill_super&#xA;  read_cache_page&#xA;    do_read_cache_folio&#xA;      filemap_read_folio&#xA;        mpage_read_folio&#xA;&#x9; do_mpage_readpage&#xA;&#x9;  ntfs_get_block_vbo&#xA;&#x9;   bh_read&#xA;&#x9;     submit_bh&#xA;&#x9;     wait_on_buffer(bh);&#xA;&#x9;                            blk_complete_reqs&#xA;&#x9;&#x9;&#x9;&#x9;     scsi_io_completion&#xA;&#x9;&#x9;&#x9;&#x9;      scsi_end_request&#xA;&#x9;&#x9;&#x9;&#x9;       blk_update_request&#xA;&#x9;&#x9;&#x9;&#x9;        end_bio_bh_io_sync&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; end_buffer_read_sync&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  __end_buffer_read_notouch&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;   unlock_buffer&#xA;&#xA;            wait_on_buffer(bh);--&gt; return will return to caller&#xA;&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;  put_bh&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;    --&gt; trigger stack-out-of-bounds&#xA;In the mpage_read_folio() function, the stack variable &#39;map_bh&#39; is&#xA;passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and&#xA;wait_on_buffer() returns to continue processing, the stack variable&#xA;is likely to be reclaimed. Consequently, during the end_buffer_read_sync()&#xA;process, calling put_bh() may result in stack overrun.&#xA;&#xA;If the bh is not allocated on the stack, it belongs to a folio.  Freeing&#xA;a buffer head which belongs to a folio is done by drop_buffers() which&#xA;will fail to free buffers which are still locked.  So it is safe to call&#xA;put_bh() before __end_buffer_read_notouch().&#xA;CVE-2025-68241:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe&#xA;&#xA;The sit driver&#39;s packet transmission path calls: sit_tunnel_xmit() -&gt;&#xA;update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called&#xA;to delete entries exceeding FNHE_RECLAIM_DEPTH+random.&#xA;&#xA;The race window is between fnhe_remove_oldest() selecting fnheX for&#xA;deletion and the subsequent kfree_rcu(). During this time, the&#xA;concurrent path&#39;s __mkroute_output() -&gt; find_exception() can fetch the&#xA;soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a&#xA;new dst using a dst_hold(). When the original fnheX is freed via RCU,&#xA;the dst reference remains permanently leaked.&#xA;&#xA;CPU 0                             CPU 1&#xA;__mkroute_output()&#xA;  find_exception() [fnheX]&#xA;                                  update_or_create_fnhe()&#xA;                                    fnhe_remove_oldest() [fnheX]&#xA;  rt_bind_exception() [bind dst]&#xA;                                  RCU callback [fnheX freed, dst leak]&#xA;&#xA;This issue manifests as a device reference count leak and a warning in&#xA;dmesg when unregistering the net device:&#xA;&#xA;  unregister_netdevice: waiting for sitX to become free. Usage count = N&#xA;&#xA;Ido Schimmel provided the simple test validation method [1].&#xA;&#xA;The fix clears &#39;oldest-&gt;fnhe_daddr&#39; before calling fnhe_flush_routes().&#xA;Since rt_bind_exception() checks this field, setting it to zero prevents&#xA;the stale fnhe from being reused and bound to a new dst just before it&#xA;is freed.&#xA;&#xA;[1]&#xA;ip netns add ns1&#xA;ip -n ns1 link set dev lo up&#xA;ip -n ns1 address add 192.0.2.1/32 dev lo&#xA;ip -n ns1 link add name dummy1 up type dummy&#xA;ip -n ns1 route add 192.0.2.2/32 dev dummy1&#xA;ip -n ns1 link add name gretap1 up arp off type gretap \&#xA;    local 192.0.2.1 remote 192.0.2.2&#xA;ip -n ns1 route add 198.51.0.0/16 dev gretap1&#xA;taskset -c 0 ip netns exec ns1 mausezahn gretap1 \&#xA;    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &amp;&#xA;taskset -c 2 ip netns exec ns1 mausezahn gretap1 \&#xA;    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &amp;&#xA;sleep 10&#xA;ip netns pids ns1 | xargs kill&#xA;ip netns del ns1&#xA;CVE-2025-68354:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex&#xA;&#xA;regulator_supply_alias_list was accessed without any locking in&#xA;regulator_supply_alias(), regulator_register_supply_alias(), and&#xA;regulator_unregister_supply_alias(). Concurrent registration,&#xA;unregistration and lookups can race, leading to:&#xA;&#xA;1 use-after-free if an alias entry is removed while being read,&#xA;2 duplicate entries when two threads register the same alias,&#xA;3 inconsistent alias mappings observed by consumers.&#xA;&#xA;Protect all traversals, insertions and deletions on&#xA;regulator_supply_alias_list with the existing regulator_list_mutex.&#xA;CVE-2023-53680:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Avoid calling OPDESC() with ops-&gt;opnum == OP_ILLEGAL&#xA;&#xA;OPDESC() simply indexes into nfsd4_ops[] by the op&#39;s operation&#xA;number, without range checking that value. It assumes callers are&#xA;careful to avoid calling it with an out-of-bounds opnum value.&#xA;&#xA;nfsd4_decode_compound() is not so careful, and can invoke OPDESC()&#xA;with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end&#xA;of nfsd4_ops[].&#xA;CVE-2025-71125:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tracing: Do not register unsupported perf events&#xA;&#xA;Synthetic events currently do not have a function to register perf events.&#xA;This leads to calling the tracepoint register functions with a NULL&#xA;function pointer which triggers:&#xA;&#xA; ------------[ cut here ]------------&#xA; WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272&#xA; Modules linked in: kvm_intel kvm irqbypass&#xA; CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014&#xA; RIP: 0010:tracepoint_add_func+0x357/0x370&#xA; Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc &lt;0f&gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f&#xA; RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246&#xA; RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000&#xA; RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8&#xA; RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780&#xA; R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a&#xA; R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78&#xA; FS:  00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  tracepoint_probe_register+0x5d/0x90&#xA;  synth_event_reg+0x3c/0x60&#xA;  perf_trace_event_init+0x204/0x340&#xA;  perf_trace_init+0x85/0xd0&#xA;  perf_tp_event_init+0x2e/0x50&#xA;  perf_try_init_event+0x6f/0x230&#xA;  ? perf_event_alloc+0x4bb/0xdc0&#xA;  perf_event_alloc+0x65a/0xdc0&#xA;  __se_sys_perf_event_open+0x290/0x9f0&#xA;  do_syscall_64+0x93/0x7b0&#xA;  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;  ? trace_hardirqs_off+0x53/0xc0&#xA;  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Instead, have the code return -ENODEV, which doesn&#39;t warn and has perf&#xA;error out with:&#xA;&#xA; # perf record -e synthetic:futex_wait&#xA;Error:&#xA;The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).&#xA;&#34;dmesg | grep -i perf&#34; may provide additional information.&#xA;&#xA;Ideally perf should support synthetic events, but for now just fix the&#xA;warning. The support can come later.&#xA;CVE-2025-40259:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: sg: Do not sleep in atomic context&#xA;&#xA;sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may&#xA;sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead&#xA;of disabled.&#xA;CVE-2022-50583:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;md/raid0, raid10: Don&#39;t set discard sectors for request queue&#xA;&#xA;It should use disk_stack_limits to get a proper max_discard_sectors&#xA;rather than setting a value by stack drivers.&#xA;&#xA;And there is a bug. If all member disks are rotational devices,&#xA;raid0/raid10 set max_discard_sectors. So the member devices are&#xA;not ssd/nvme, but raid0/raid10 export the wrong value. It reports&#xA;warning messages in function __blkdev_issue_discard when mkfs.xfs&#xA;like this:&#xA;&#xA;[ 4616.022599] ------------[ cut here ]------------&#xA;[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0&#xA;[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0&#xA;[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff &lt;0f&gt; 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7&#xA;[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246&#xA;[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080&#xA;[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080&#xA;[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000&#xA;[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000&#xA;[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080&#xA;[ 4616.213259] FS:  00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000&#xA;[ 4616.222298] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0&#xA;[ 4616.236689] Call Trace:&#xA;[ 4616.239428]  blkdev_issue_discard+0x52/0xb0&#xA;[ 4616.244108]  blkdev_common_ioctl+0x43c/0xa00&#xA;[ 4616.248883]  blkdev_ioctl+0x116/0x280&#xA;[ 4616.252977]  __x64_sys_ioctl+0x8a/0xc0&#xA;[ 4616.257163]  do_syscall_64+0x5c/0x90&#xA;[ 4616.261164]  ? handle_mm_fault+0xc5/0x2a0&#xA;[ 4616.265652]  ? do_user_addr_fault+0x1d8/0x690&#xA;[ 4616.270527]  ? do_syscall_64+0x69/0x90&#xA;[ 4616.274717]  ? exc_page_fault+0x62/0x150&#xA;[ 4616.279097]  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[ 4616.284748] RIP: 0033:0x7f9a55398c6b&#xA;CVE-2025-38051:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: Fix use-after-free in cifs_fill_dirent&#xA;&#xA;There is a race condition in the readdir concurrency process, which may&#xA;access the rsp buffer after it has been released, triggering the&#xA;following KASAN warning.&#xA;&#xA; ==================================================================&#xA; BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]&#xA; Read of size 4 at addr ffff8880099b819c by task a.out/342975&#xA;&#xA; CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)&#xA; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  dump_stack_lvl+0x53/0x70&#xA;  print_report+0xce/0x640&#xA;  kasan_report+0xb8/0xf0&#xA;  cifs_fill_dirent+0xb03/0xb60 [cifs]&#xA;  cifs_readdir+0x12cb/0x3190 [cifs]&#xA;  iterate_dir+0x1a1/0x520&#xA;  __x64_sys_getdents+0x134/0x220&#xA;  do_syscall_64+0x4b/0x110&#xA;  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA; RIP: 0033:0x7f996f64b9f9&#xA; Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89&#xA; f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01&#xA; f0 ff ff  0d f7 c3 0c 00 f7 d8 64 89 8&#xA; RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e&#xA; RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9&#xA; RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003&#xA; RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000&#xA; R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88&#xA; R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000&#xA;  &lt;/TASK&gt;&#xA;&#xA; Allocated by task 408:&#xA;  kasan_save_stack+0x20/0x40&#xA;  kasan_save_track+0x14/0x30&#xA;  __kasan_slab_alloc+0x6e/0x70&#xA;  kmem_cache_alloc_noprof+0x117/0x3d0&#xA;  mempool_alloc_noprof+0xf2/0x2c0&#xA;  cifs_buf_get+0x36/0x80 [cifs]&#xA;  allocate_buffers+0x1d2/0x330 [cifs]&#xA;  cifs_demultiplex_thread+0x22b/0x2690 [cifs]&#xA;  kthread+0x394/0x720&#xA;  ret_from_fork+0x34/0x70&#xA;  ret_from_fork_asm+0x1a/0x30&#xA;&#xA; Freed by task 342979:&#xA;  kasan_save_stack+0x20/0x40&#xA;  kasan_save_track+0x14/0x30&#xA;  kasan_save_free_info+0x3b/0x60&#xA;  __kasan_slab_free+0x37/0x50&#xA;  kmem_cache_free+0x2b8/0x500&#xA;  cifs_buf_release+0x3c/0x70 [cifs]&#xA;  cifs_readdir+0x1c97/0x3190 [cifs]&#xA;  iterate_dir+0x1a1/0x520&#xA;  __x64_sys_getdents64+0x134/0x220&#xA;  do_syscall_64+0x4b/0x110&#xA;  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA; The buggy address belongs to the object at ffff8880099b8000&#xA;  which belongs to the cache cifs_request of size 16588&#xA; The buggy address is located 412 bytes inside of&#xA;  freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)&#xA;&#xA; The buggy address belongs to the physical page:&#xA; page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8&#xA; head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0&#xA; anon flags: 0x80000000000040(head|node=0|zone=1)&#xA; page_type: f5(slab)&#xA; raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001&#xA; raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000&#xA; head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001&#xA; head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000&#xA; head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff&#xA; head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008&#xA; page dumped because: kasan: bad access detected&#xA;&#xA; Memory state around the buggy address:&#xA;  ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;  ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA; &gt;ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;                             ^&#xA;  ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;  ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA; ==================================================================&#xA;&#xA;POC is available in the link [1].&#xA;&#xA;The problem triggering process is as follows:&#xA;&#xA;Process 1                       Process 2&#xA;-----------------------------------&#xA;---truncated---&#xA;CVE-2023-53794:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cifs: fix session state check in reconnect to avoid use-after-free issue&#xA;&#xA;Don&#39;t collect exiting session in smb2_reconnect_server(), because it&#xA;will be released soon.&#xA;&#xA;Note that the exiting session will stay in server-&gt;smb_ses_list until&#xA;it complete the cifs_free_ipc() and logoff() and then delete itself&#xA;from the list.&#xA;CVE-2025-68229:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()&#xA;&#xA;If the allocation of tl_hba-&gt;sh fails in tcm_loop_driver_probe() and we&#xA;attempt to dereference it in tcm_loop_tpg_address_show() we will get a&#xA;segfault, see below for an example. So, check tl_hba-&gt;sh before&#xA;dereferencing it.&#xA;&#xA;  Unable to allocate struct scsi_host&#xA;  BUG: kernel NULL pointer dereference, address: 0000000000000194&#xA;  #PF: supervisor read access in kernel mode&#xA;  #PF: error_code(0x0000) - not-present page&#xA;  PGD 0 P4D 0&#xA;  Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;  CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1&#xA;  Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024&#xA;  RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]&#xA;...&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   configfs_read_iter+0x12d/0x1d0 [configfs]&#xA;   vfs_read+0x1b5/0x300&#xA;   ksys_read+0x6f/0xf0&#xA;...&#xA;CVE-2022-49157:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Fix premature hw access after PCI error&#xA;&#xA;After a recoverable PCI error has been detected and recovered, qla driver&#xA;needs to check to see if the error condition still persist and/or wait&#xA;for the OS to give the resume signal.&#xA;&#xA;Sep  8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440&#xA;qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]&#xA;Sep  8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60&#xA;[qla2xxx]&#xA;Sep  8 22:26:03 localhost kernel: Call Trace:&#xA;Sep  8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]&#xA;Sep  8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160&#xA;[qla2xxx]&#xA;Sep  8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]&#xA;Sep  8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120&#xA;[qla2xxx]&#xA;Sep  8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80&#xA;Sep  8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80&#xA;Sep  8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90&#xA;Sep  8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0&#xA;Sep  8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240&#xA;Sep  8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0&#xA;Sep  8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360&#xA;..&#xA;Sep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI&#xA;disconnect.&#xA;Sep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:&#xA;qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h&#xA;Sep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to&#xA;capture FW dump&#xA;Sep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,&#xA;waited 5221 msecs&#xA;Sep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio&#xA;enabled returning.&#xA;Sep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX&#xA;Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5&#xA;mb[0-3]=[0xffff 0xffff 0xffff 0xffff]&#xA;CVE-2025-37768:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/pm: Prevent division by zero&#xA;&#xA;The user can set any speed value.&#xA;If speed is greater than UINT_MAX/8, division by zero is possible.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2025-39823:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86: use array_index_nospec with indices that come from guest&#xA;&#xA;min and dest_id are guest-controlled indices. Using array_index_nospec()&#xA;after the bounds checks clamps these values to mitigate speculative execution&#xA;side-channels.&#xA;CVE-2023-54263:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP&#xA;&#xA;Fixes OOPS on boards with ANX9805 DP encoders.&#xA;CVE-2025-68789:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.&#xA;CVE-2025-71093:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;e1000: fix OOB in e1000_tbi_should_accept()&#xA;&#xA;In e1000_tbi_should_accept() we read the last byte of the frame via&#xA;&#39;data[length - 1]&#39; to evaluate the TBI workaround. If the descriptor-&#xA;reported length is zero or larger than the actual RX buffer size, this&#xA;read goes out of bounds and can hit unrelated slab objects. The issue&#xA;is observed from the NAPI receive path (e1000_clean_rx_irq):&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790&#xA;Read of size 1 at addr ffff888014114e54 by task sshd/363&#xA;&#xA;CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl+0x5a/0x74&#xA; print_address_description+0x7b/0x440&#xA; print_report+0x101/0x200&#xA; kasan_report+0xc1/0xf0&#xA; e1000_tbi_should_accept+0x610/0x790&#xA; e1000_clean_rx_irq+0xa8c/0x1110&#xA; e1000_clean+0xde2/0x3c10&#xA; __napi_poll+0x98/0x380&#xA; net_rx_action+0x491/0xa20&#xA; __do_softirq+0x2c9/0x61d&#xA; do_softirq+0xd1/0x120&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; __local_bh_enable_ip+0xfe/0x130&#xA; ip_finish_output2+0x7d5/0xb00&#xA; __ip_queue_xmit+0xe24/0x1ab0&#xA; __tcp_transmit_skb+0x1bcb/0x3340&#xA; tcp_write_xmit+0x175d/0x6bd0&#xA; __tcp_push_pending_frames+0x7b/0x280&#xA; tcp_sendmsg_locked+0x2e4f/0x32d0&#xA; tcp_sendmsg+0x24/0x40&#xA; sock_write_iter+0x322/0x430&#xA; vfs_write+0x56c/0xa60&#xA; ksys_write+0xd1/0x190&#xA; do_syscall_64+0x43/0x90&#xA; entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;RIP: 0033:0x7f511b476b10&#xA;Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24&#xA;RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001&#xA;RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10&#xA;RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003&#xA;RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00&#xA;R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003&#xA; &lt;/TASK&gt;&#xA;Allocated by task 1:&#xA; __kasan_krealloc+0x131/0x1c0&#xA; krealloc+0x90/0xc0&#xA; add_sysfs_param+0xcb/0x8a0&#xA; kernel_add_sysfs_param+0x81/0xd4&#xA; param_sysfs_builtin+0x138/0x1a6&#xA; param_sysfs_init+0x57/0x5b&#xA; do_one_initcall+0x104/0x250&#xA; do_initcall_level+0x102/0x132&#xA; do_initcalls+0x46/0x74&#xA; kernel_init_freeable+0x28f/0x393&#xA; kernel_init+0x14/0x1a0&#xA; ret_from_fork+0x22/0x30&#xA;The buggy address belongs to the object at ffff888014114000&#xA; which belongs to the cache kmalloc-2k of size 2048&#xA;The buggy address is located 1620 bytes to the right of&#xA; 2048-byte region [ffff888014114000, ffff888014114800]&#xA;The buggy address belongs to the physical page:&#xA;page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110&#xA;head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0&#xA;flags: 0x100000000010200(slab|head|node=0|zone=1)&#xA;raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000&#xA;raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;==================================================================&#xA;&#xA;This happens because the TBI check unconditionally dereferences the last&#xA;byte without validating the reported length first:&#xA;&#xA;&#x9;u8 last_byte = *(data + length - 1);&#xA;&#xA;Fix by rejecting the frame early if the length is zero, or if it exceeds&#xA;adapter-&gt;rx_buffer_len. This preserves the TBI workaround semantics for&#xA;valid frames and prevents touching memory beyond the RX buffer.&#xA;CVE-2025-71087:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iavf: fix off-by-one issues in iavf_config_rss_reg()&#xA;&#xA;There are off-by-one bugs when configuring RSS hash key and lookup&#xA;table, causing out-of-bounds reads to memory [1] and out-of-bounds&#xA;writes to device registers.&#xA;&#xA;Before commit 43a3d9ba34c9 (&#34;i40evf: Allow PF driver to configure RSS&#34;),&#xA;the loop upper bounds were:&#xA;    i &lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX&#xA;which is safe since the value is the last valid index.&#xA;&#xA;That commit changed the bounds to:&#xA;    i &lt;= adapter-&gt;rss_{key,lut}_size / 4&#xA;where `rss_{key,lut}_size / 4` is the number of dwords, so the last&#xA;valid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `&lt;=`&#xA;accesses one element past the end.&#xA;&#xA;Fix the issues by using `&lt;` instead of `&lt;=`, ensuring we do not exceed&#xA;the bounds.&#xA;&#xA;[1] KASAN splat about rss_key_size off-by-one&#xA;  BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800&#xA;  Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63&#xA;&#xA;  CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)&#xA;  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;  Workqueue: iavf iavf_watchdog_task&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x6f/0xb0&#xA;   print_report+0x170/0x4f3&#xA;   kasan_report+0xe1/0x1a0&#xA;   iavf_config_rss+0x619/0x800&#xA;   iavf_watchdog_task+0x2be7/0x3230&#xA;   process_one_work+0x7fd/0x1420&#xA;   worker_thread+0x4d1/0xd40&#xA;   kthread+0x344/0x660&#xA;   ret_from_fork+0x249/0x320&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;   &lt;/TASK&gt;&#xA;&#xA;  Allocated by task 63:&#xA;   kasan_save_stack+0x30/0x50&#xA;   kasan_save_track+0x14/0x30&#xA;   __kasan_kmalloc+0x7f/0x90&#xA;   __kmalloc_noprof+0x246/0x6f0&#xA;   iavf_watchdog_task+0x28fc/0x3230&#xA;   process_one_work+0x7fd/0x1420&#xA;   worker_thread+0x4d1/0xd40&#xA;   kthread+0x344/0x660&#xA;   ret_from_fork+0x249/0x320&#xA;   ret_from_fork_asm+0x1a/0x30&#xA;&#xA;  The buggy address belongs to the object at ffff888102c50100&#xA;   which belongs to the cache kmalloc-64 of size 64&#xA;  The buggy address is located 0 bytes to the right of&#xA;   allocated 52-byte region [ffff888102c50100, ffff888102c50134)&#xA;&#xA;  The buggy address belongs to the physical page:&#xA;  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50&#xA;  flags: 0x200000000000000(node=0|zone=2)&#xA;  page_type: f5(slab)&#xA;  raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000&#xA;  raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000&#xA;  page dumped because: kasan: bad access detected&#xA;&#xA;  Memory state around the buggy address:&#xA;   ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc&#xA;   ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc&#xA;  &gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc&#xA;                                       ^&#xA;   ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc&#xA;   ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;CVE-2025-37740:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: add sanity check for agwidth in dbMount&#xA;&#xA;The width in dmapctl of the AG is zero, it trigger a divide error when&#xA;calculating the control page level in dbAllocAG.&#xA;&#xA;To avoid this issue, add a check for agwidth in dbAllocAG.&#xA;CVE-2025-38342:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;software node: Correct a OOB check in software_node_get_reference_args()&#xA;&#xA;software_node_get_reference_args() wants to get @index-th element, so&#xA;the property value requires at least &#39;(index + 1) * sizeof(*ref)&#39; bytes&#xA;but that can not be guaranteed by current OOB check, and may cause OOB&#xA;for malformed property.&#xA;&#xA;Fix by using as OOB check &#39;((index + 1) * sizeof(*ref) &gt; prop-&gt;length)&#39;.&#xA;CVE-2025-71104:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer&#xA;&#xA;When advancing the target expiration for the guest&#39;s APIC timer in periodic&#xA;mode, set the expiration to &#34;now&#34; if the target expiration is in the past&#xA;(similar to what is done in update_target_expiration()).  Blindly adding&#xA;the period to the previous target expiration can result in KVM generating&#xA;a practically unbounded number of hrtimer IRQs due to programming an&#xA;expired timer over and over.  In extreme scenarios, e.g. if userspace&#xA;pauses/suspends a VM for an extended duration, this can even cause hard&#xA;lockups in the host.&#xA;&#xA;Currently, the bug only affects Intel CPUs when using the hypervisor timer&#xA;(HV timer), a.k.a. the VMX preemption timer.  Unlike the software timer,&#xA;a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the&#xA;HV timer only runs while the guest is active.  As a result, if the vCPU&#xA;does not run for an extended duration, there will be a huge gap between&#xA;the target expiration and the current time the vCPU resumes running.&#xA;Because the target expiration is incremented by only one period on each&#xA;timer expiration, this leads to a series of timer expirations occurring&#xA;rapidly after the vCPU/VM resumes.&#xA;&#xA;More critically, when the vCPU first triggers a periodic HV timer&#xA;expiration after resuming, advancing the expiration by only one period&#xA;will result in a target expiration in the past.  As a result, the delta&#xA;may be calculated as a negative value.  When the delta is converted into&#xA;an absolute value (tscdeadline is an unsigned u64), the resulting value&#xA;can overflow what the HV timer is capable of programming.  I.e. the large&#xA;value will exceed the VMX Preemption Timer&#39;s maximum bit width of&#xA;cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the&#xA;HV timer to the software timer (hrtimers).&#xA;&#xA;After switching to the software timer, periodic timer expiration callbacks&#xA;may be executed consecutively within a single clock interrupt handler,&#xA;because hrtimers honors KVM&#39;s request for an expiration in the past and&#xA;immediately re-invokes KVM&#39;s callback after reprogramming.  And because&#xA;the interrupt handler runs with IRQs disabled, restarting KVM&#39;s hrtimer&#xA;over and over until the target expiration is advanced to &#34;now&#34; can result&#xA;in a hard lockup.&#xA;&#xA;E.g. the following hard lockup was triggered in the host when running a&#xA;Windows VM (only relevant because it used the APIC timer in periodic mode)&#xA;after resuming the VM from a long suspend (in the host).&#xA;&#xA;  NMI watchdog: Watchdog detected hard LOCKUP on cpu 45&#xA;  ...&#xA;  RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]&#xA;  ...&#xA;  RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046&#xA;  RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc&#xA;  RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500&#xA;  RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0&#xA;  R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0&#xA;  R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8&#xA;  FS:  00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0&#xA;  PKRU: 55555554&#xA;  Call Trace:&#xA;   &lt;IRQ&gt;&#xA;   apic_timer_fn+0x31/0x50 [kvm]&#xA;   __hrtimer_run_queues+0x100/0x280&#xA;   hrtimer_interrupt+0x100/0x210&#xA;   ? ttwu_do_wakeup+0x19/0x160&#xA;   smp_apic_timer_interrupt+0x6a/0x130&#xA;   apic_timer_interrupt+0xf/0x20&#xA;   &lt;/IRQ&gt;&#xA;&#xA;Moreover, if the suspend duration of the virtual machine is not long enough&#xA;to trigger a hard lockup in this scenario, since commit 98c25ead5eda&#xA;(&#34;KVM: VMX: Move preemption timer &lt;=&gt; hrtimer dance to common x86&#34;), KVM&#xA;will continue using the software timer until the guest reprograms the APIC&#xA;timer in some way.  Since the periodic timer does not require frequent APIC&#xA;timer register programming, the guest may continue to use the software&#xA;timer in &#xA;---truncated---&#xA;CVE-2025-39951:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;um: virtio_uml: Fix use-after-free after put_device in probe&#xA;&#xA;When register_virtio_device() fails in virtio_uml_probe(),&#xA;the code sets vu_dev-&gt;registered = 1 even though&#xA;the device was not successfully registered.&#xA;This can lead to use-after-free or other issues.&#xA;CVE-2025-68800:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats&#xA;&#xA;Cited commit added a dedicated mutex (instead of RTNL) to protect the&#xA;multicast route list, so that it will not change while the driver&#xA;periodically traverses it in order to update the kernel about multicast&#xA;route stats that were queried from the device.&#xA;&#xA;One instance of list entry deletion (during route replace) was missed&#xA;and it can result in a use-after-free [1].&#xA;&#xA;Fix by acquiring the mutex before deleting the entry from the list and&#xA;releasing it afterwards.&#xA;&#xA;[1]&#xA;BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]&#xA;Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043&#xA;&#xA;CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)&#xA;Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017&#xA;Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0xba/0x110&#xA; print_report+0x174/0x4f5&#xA; kasan_report+0xdf/0x110&#xA; mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]&#xA; process_one_work+0x9cc/0x18e0&#xA; worker_thread+0x5df/0xe40&#xA; kthread+0x3b8/0x730&#xA; ret_from_fork+0x3e9/0x560&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 29933:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0x8f/0xa0&#xA; mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]&#xA; mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]&#xA; process_one_work+0x9cc/0x18e0&#xA; worker_thread+0x5df/0xe40&#xA; kthread+0x3b8/0x730&#xA; ret_from_fork+0x3e9/0x560&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;Freed by task 29933:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_save_free_info+0x3b/0x70&#xA; __kasan_slab_free+0x43/0x70&#xA; kfree+0x14e/0x700&#xA; mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]&#xA; mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]&#xA; process_one_work+0x9cc/0x18e0&#xA; worker_thread+0x5df/0xe40&#xA; kthread+0x3b8/0x730&#xA; ret_from_fork+0x3e9/0x560&#xA; ret_from_fork_asm+0x1a/0x30&#xA;CVE-2025-68801:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mlxsw: spectrum_router: Fix neighbour use-after-free&#xA;&#xA;We sometimes observe use-after-free when dereferencing a neighbour [1].&#xA;The problem seems to be that the driver stores a pointer to the&#xA;neighbour, but without holding a reference on it. A reference is only&#xA;taken when the neighbour is used by a nexthop.&#xA;&#xA;Fix by simplifying the reference counting scheme. Always take a&#xA;reference when storing a neighbour pointer in a neighbour entry. Avoid&#xA;taking a referencing when the neighbour is used by a nexthop as the&#xA;neighbour entry associated with the nexthop already holds a reference.&#xA;&#xA;Tested by running the test that uncovered the problem over 300 times.&#xA;Without this patch the problem was reproduced after a handful of&#xA;iterations.&#xA;&#xA;[1]&#xA;BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310&#xA;Read of size 8 at addr ffff88817f8e3420 by task ip/3929&#xA;&#xA;CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)&#xA;Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x6f/0xa0&#xA; print_address_description.constprop.0+0x6e/0x300&#xA; print_report+0xfc/0x1fb&#xA; kasan_report+0xe4/0x110&#xA; mlxsw_sp_neigh_entry_update+0x2d4/0x310&#xA; mlxsw_sp_router_rif_gone_sync+0x35f/0x510&#xA; mlxsw_sp_rif_destroy+0x1ea/0x730&#xA; mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0&#xA; __mlxsw_sp_inetaddr_lag_event+0xcc/0x130&#xA; __mlxsw_sp_inetaddr_event+0xf5/0x3c0&#xA; mlxsw_sp_router_netdevice_event+0x1015/0x1580&#xA; notifier_call_chain+0xcc/0x150&#xA; call_netdevice_notifiers_info+0x7e/0x100&#xA; __netdev_upper_dev_unlink+0x10b/0x210&#xA; netdev_upper_dev_unlink+0x79/0xa0&#xA; vrf_del_slave+0x18/0x50&#xA; do_set_master+0x146/0x7d0&#xA; do_setlink.isra.0+0x9a0/0x2880&#xA; rtnl_newlink+0x637/0xb20&#xA; rtnetlink_rcv_msg+0x6fe/0xb90&#xA; netlink_rcv_skb+0x123/0x380&#xA; netlink_unicast+0x4a3/0x770&#xA; netlink_sendmsg+0x75b/0xc90&#xA; __sock_sendmsg+0xbe/0x160&#xA; ____sys_sendmsg+0x5b2/0x7d0&#xA; ___sys_sendmsg+0xfd/0x180&#xA; __sys_sendmsg+0x124/0x1c0&#xA; do_syscall_64+0xbb/0xfd0&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;[...]&#xA;&#xA;Allocated by task 109:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0x7b/0x90&#xA; __kmalloc_noprof+0x2c1/0x790&#xA; neigh_alloc+0x6af/0x8f0&#xA; ___neigh_create+0x63/0xe90&#xA; mlxsw_sp_nexthop_neigh_init+0x430/0x7e0&#xA; mlxsw_sp_nexthop_type_init+0x212/0x960&#xA; mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280&#xA; mlxsw_sp_nexthop6_group_get+0x392/0x6a0&#xA; mlxsw_sp_fib6_entry_create+0x46a/0xfd0&#xA; mlxsw_sp_router_fib6_replace+0x1ed/0x5f0&#xA; mlxsw_sp_router_fib6_event_work+0x10a/0x2a0&#xA; process_one_work+0xd57/0x1390&#xA; worker_thread+0x4d6/0xd40&#xA; kthread+0x355/0x5b0&#xA; ret_from_fork+0x1d4/0x270&#xA; ret_from_fork_asm+0x11/0x20&#xA;&#xA;Freed by task 154:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_save_free_info+0x3b/0x60&#xA; __kasan_slab_free+0x43/0x70&#xA; kmem_cache_free_bulk.part.0+0x1eb/0x5e0&#xA; kvfree_rcu_bulk+0x1f2/0x260&#xA; kfree_rcu_work+0x130/0x1b0&#xA; process_one_work+0xd57/0x1390&#xA; worker_thread+0x4d6/0xd40&#xA; kthread+0x355/0x5b0&#xA; ret_from_fork+0x1d4/0x270&#xA; ret_from_fork_asm+0x11/0x20&#xA;&#xA;Last potentially related work creation:&#xA; kasan_save_stack+0x30/0x50&#xA; kasan_record_aux_stack+0x8c/0xa0&#xA; kvfree_call_rcu+0x93/0x5b0&#xA; mlxsw_sp_router_neigh_event_work+0x67d/0x860&#xA; process_one_work+0xd57/0x1390&#xA; worker_thread+0x4d6/0xd40&#xA; kthread+0x355/0x5b0&#xA; ret_from_fork+0x1d4/0x270&#xA; ret_from_fork_asm+0x11/0x20&#xA;CVE-2025-39856:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev&#xA;&#xA;In the TX completion packet stage of TI SoCs with CPSW2G instance, which&#xA;has single external ethernet port, ndev is accessed without being&#xA;initialized if no TX packets have been processed. It results into null&#xA;pointer dereference, causing kernel to crash. Fix this by having a check&#xA;on the number of TX packets which have been processed.&#xA;CVE-2025-39864:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: cfg80211: fix use-after-free in cmp_bss()&#xA;&#xA;Following bss_free() quirk introduced in commit 776b3580178f&#xA;(&#34;cfg80211: track hidden SSID networks properly&#34;), adjust&#xA;cfg80211_update_known_bss() to free the last beacon frame&#xA;elements only if they&#39;re not shared via the corresponding&#xA;&#39;hidden_beacon_bss&#39; pointer.&#xA;CVE-2025-38111:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mdiobus: Fix potential out-of-bounds read/write access&#xA;&#xA;When using publicly available tools like &#39;mdio-tools&#39; to read/write data&#xA;from/to network interface and its PHY via mdiobus, there is no verification of&#xA;parameters passed to the ioctl and it accepts any mdio address.&#xA;Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,&#xA;but it is possible to pass higher value than that via ioctl.&#xA;While read/write operation should generally fail in this case,&#xA;mdiobus provides stats array, where wrong address may allow out-of-bounds&#xA;read/write.&#xA;&#xA;Fix that by adding address verification before read/write operation.&#xA;While this excludes this access from any statistics, it improves security of&#xA;read/write operation.&#xA;CVE-2025-38697:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: upper bound check of tree index in dbAllocAG&#xA;&#xA;When computing the tree index in dbAllocAG, we never check if we are&#xA;out of bounds realative to the size of the stree.&#xA;This could happen in a scenario where the filesystem metadata are&#xA;corrupted.&#xA;CVE-2025-38714:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()&#xA;&#xA;The hfsplus_bnode_read() method can trigger the issue:&#xA;&#xA;[  174.852007][ T9784] ==================================================================&#xA;[  174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360&#xA;[  174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784&#xA;[  174.854059][ T9784]&#xA;[  174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)&#xA;[  174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[  174.854286][ T9784] Call Trace:&#xA;[  174.854289][ T9784]  &lt;TASK&gt;&#xA;[  174.854292][ T9784]  dump_stack_lvl+0x10e/0x1f0&#xA;[  174.854305][ T9784]  print_report+0xd0/0x660&#xA;[  174.854315][ T9784]  ? __virt_addr_valid+0x81/0x610&#xA;[  174.854323][ T9784]  ? __phys_addr+0xe8/0x180&#xA;[  174.854330][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360&#xA;[  174.854337][ T9784]  kasan_report+0xc6/0x100&#xA;[  174.854346][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360&#xA;[  174.854354][ T9784]  hfsplus_bnode_read+0x2f4/0x360&#xA;[  174.854362][ T9784]  hfsplus_bnode_dump+0x2ec/0x380&#xA;[  174.854370][ T9784]  ? __pfx_hfsplus_bnode_dump+0x10/0x10&#xA;[  174.854377][ T9784]  ? hfsplus_bnode_write_u16+0x83/0xb0&#xA;[  174.854385][ T9784]  ? srcu_gp_start+0xd0/0x310&#xA;[  174.854393][ T9784]  ? __mark_inode_dirty+0x29e/0xe40&#xA;[  174.854402][ T9784]  hfsplus_brec_remove+0x3d2/0x4e0&#xA;[  174.854411][ T9784]  __hfsplus_delete_attr+0x290/0x3a0&#xA;[  174.854419][ T9784]  ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10&#xA;[  174.854427][ T9784]  ? __pfx___hfsplus_delete_attr+0x10/0x10&#xA;[  174.854436][ T9784]  ? __asan_memset+0x23/0x50&#xA;[  174.854450][ T9784]  hfsplus_delete_all_attrs+0x262/0x320&#xA;[  174.854459][ T9784]  ? __pfx_hfsplus_delete_all_attrs+0x10/0x10&#xA;[  174.854469][ T9784]  ? rcu_is_watching+0x12/0xc0&#xA;[  174.854476][ T9784]  ? __mark_inode_dirty+0x29e/0xe40&#xA;[  174.854483][ T9784]  hfsplus_delete_cat+0x845/0xde0&#xA;[  174.854493][ T9784]  ? __pfx_hfsplus_delete_cat+0x10/0x10&#xA;[  174.854507][ T9784]  hfsplus_unlink+0x1ca/0x7c0&#xA;[  174.854516][ T9784]  ? __pfx_hfsplus_unlink+0x10/0x10&#xA;[  174.854525][ T9784]  ? down_write+0x148/0x200&#xA;[  174.854532][ T9784]  ? __pfx_down_write+0x10/0x10&#xA;[  174.854540][ T9784]  vfs_unlink+0x2fe/0x9b0&#xA;[  174.854549][ T9784]  do_unlinkat+0x490/0x670&#xA;[  174.854557][ T9784]  ? __pfx_do_unlinkat+0x10/0x10&#xA;[  174.854565][ T9784]  ? __might_fault+0xbc/0x130&#xA;[  174.854576][ T9784]  ? getname_flags.part.0+0x1c5/0x550&#xA;[  174.854584][ T9784]  __x64_sys_unlink+0xc5/0x110&#xA;[  174.854592][ T9784]  do_syscall_64+0xc9/0x480&#xA;[  174.854600][ T9784]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[  174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167&#xA;[  174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08&#xA;[  174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057&#xA;[  174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167&#xA;[  174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50&#xA;[  174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40&#xA;[  174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0&#xA;[  174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;[  174.854658][ T9784]  &lt;/TASK&gt;&#xA;[  174.854661][ T9784]&#xA;[  174.879281][ T9784] Allocated by task 9784:&#xA;[  174.879664][ T9784]  kasan_save_stack+0x20/0x40&#xA;[  174.880082][ T9784]  kasan_save_track+0x14/0x30&#xA;[  174.880500][ T9784]  __kasan_kmalloc+0xaa/0xb0&#xA;[  174.880908][ T9784]  __kmalloc_noprof+0x205/0x550&#xA;[  174.881337][ T9784]  __hfs_bnode_create+0x107/0x890&#xA;[  174.881779][ T9784]  hfsplus_bnode_find+0x2d0/0xd10&#xA;[  174.882222][ T9784]  hfsplus_brec_find+0x2b0/0x520&#xA;[  174.882659][ T9784]  hfsplus_delete_all_attrs+0x23b/0x3&#xA;---truncated---&#xA;CVE-2025-38713:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()&#xA;&#xA;The hfsplus_readdir() method is capable to crash by calling&#xA;hfsplus_uni2asc():&#xA;&#xA;[  667.121659][ T9805] ==================================================================&#xA;[  667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10&#xA;[  667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805&#xA;[  667.124578][ T9805]&#xA;[  667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)&#xA;[  667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[  667.124890][ T9805] Call Trace:&#xA;[  667.124893][ T9805]  &lt;TASK&gt;&#xA;[  667.124896][ T9805]  dump_stack_lvl+0x10e/0x1f0&#xA;[  667.124911][ T9805]  print_report+0xd0/0x660&#xA;[  667.124920][ T9805]  ? __virt_addr_valid+0x81/0x610&#xA;[  667.124928][ T9805]  ? __phys_addr+0xe8/0x180&#xA;[  667.124934][ T9805]  ? hfsplus_uni2asc+0x902/0xa10&#xA;[  667.124942][ T9805]  kasan_report+0xc6/0x100&#xA;[  667.124950][ T9805]  ? hfsplus_uni2asc+0x902/0xa10&#xA;[  667.124959][ T9805]  hfsplus_uni2asc+0x902/0xa10&#xA;[  667.124966][ T9805]  ? hfsplus_bnode_read+0x14b/0x360&#xA;[  667.124974][ T9805]  hfsplus_readdir+0x845/0xfc0&#xA;[  667.124984][ T9805]  ? __pfx_hfsplus_readdir+0x10/0x10&#xA;[  667.124994][ T9805]  ? stack_trace_save+0x8e/0xc0&#xA;[  667.125008][ T9805]  ? iterate_dir+0x18b/0xb20&#xA;[  667.125015][ T9805]  ? trace_lock_acquire+0x85/0xd0&#xA;[  667.125022][ T9805]  ? lock_acquire+0x30/0x80&#xA;[  667.125029][ T9805]  ? iterate_dir+0x18b/0xb20&#xA;[  667.125037][ T9805]  ? down_read_killable+0x1ed/0x4c0&#xA;[  667.125044][ T9805]  ? putname+0x154/0x1a0&#xA;[  667.125051][ T9805]  ? __pfx_down_read_killable+0x10/0x10&#xA;[  667.125058][ T9805]  ? apparmor_file_permission+0x239/0x3e0&#xA;[  667.125069][ T9805]  iterate_dir+0x296/0xb20&#xA;[  667.125076][ T9805]  __x64_sys_getdents64+0x13c/0x2c0&#xA;[  667.125084][ T9805]  ? __pfx___x64_sys_getdents64+0x10/0x10&#xA;[  667.125091][ T9805]  ? __x64_sys_openat+0x141/0x200&#xA;[  667.125126][ T9805]  ? __pfx_filldir64+0x10/0x10&#xA;[  667.125134][ T9805]  ? do_user_addr_fault+0x7fe/0x12f0&#xA;[  667.125143][ T9805]  do_syscall_64+0xc9/0x480&#xA;[  667.125151][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[  667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9&#xA;[  667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48&#xA;[  667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9&#xA;[  667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9&#xA;[  667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004&#xA;[  667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110&#xA;[  667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260&#xA;[  667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000&#xA;[  667.125207][ T9805]  &lt;/TASK&gt;&#xA;[  667.125210][ T9805]&#xA;[  667.145632][ T9805] Allocated by task 9805:&#xA;[  667.145991][ T9805]  kasan_save_stack+0x20/0x40&#xA;[  667.146352][ T9805]  kasan_save_track+0x14/0x30&#xA;[  667.146717][ T9805]  __kasan_kmalloc+0xaa/0xb0&#xA;[  667.147065][ T9805]  __kmalloc_noprof+0x205/0x550&#xA;[  667.147448][ T9805]  hfsplus_find_init+0x95/0x1f0&#xA;[  667.147813][ T9805]  hfsplus_readdir+0x220/0xfc0&#xA;[  667.148174][ T9805]  iterate_dir+0x296/0xb20&#xA;[  667.148549][ T9805]  __x64_sys_getdents64+0x13c/0x2c0&#xA;[  667.148937][ T9805]  do_syscall_64+0xc9/0x480&#xA;[  667.149291][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[  667.149809][ T9805]&#xA;[  667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000&#xA;[  667.150030][ T9805]  which belongs to the cache kmalloc-2k of size 2048&#xA;[  667.151282][ T9805] The buggy address is located 0 bytes to the right of&#xA;[  667.151282][ T9805]  allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)&#xA;[  667.1&#xA;---truncated---&#xA;CVE-2025-38712:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hfsplus: don&#39;t use BUG_ON() in hfsplus_create_attributes_file()&#xA;&#xA;When the volume header contains erroneous values that do not reflect&#xA;the actual state of the filesystem, hfsplus_fill_super() assumes that&#xA;the attributes file is not yet created, which later results in hitting&#xA;BUG_ON() when hfsplus_create_attributes_file() is called. Replace this&#xA;BUG_ON() with -EIO error with a message to suggest running fsck tool.&#xA;CVE-2025-38705:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/pm: fix null pointer access&#xA;&#xA;Writing a string without delimiters (&#39; &#39;, &#39;\n&#39;, &#39;\0&#39;) to the under&#xA;gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile&#xA;will result in a null pointer dereference.&#xA;CVE-2025-39737:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()&#xA;&#xA;A soft lockup warning was observed on a relative small system x86-64&#xA;system with 16 GB of memory when running a debug kernel with kmemleak&#xA;enabled.&#xA;&#xA;  watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]&#xA;&#xA;The test system was running a workload with hot unplug happening in&#xA;parallel.  Then kemleak decided to disable itself due to its inability to&#xA;allocate more kmemleak objects.  The debug kernel has its&#xA;CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.&#xA;&#xA;The soft lockup happened in kmemleak_do_cleanup() when the existing&#xA;kmemleak objects were being removed and deleted one-by-one in a loop via a&#xA;workqueue.  In this particular case, there are at least 40,000 objects&#xA;that need to be processed and given the slowness of a debug kernel and the&#xA;fact that a raw_spinlock has to be acquired and released in&#xA;__delete_object(), it could take a while to properly handle all these&#xA;objects.&#xA;&#xA;As kmemleak has been disabled in this case, the object removal and&#xA;deletion process can be further optimized as locking isn&#39;t really needed. &#xA;However, it is probably not worth the effort to optimize for such an edge&#xA;case that should rarely happen.  So the simple solution is to call&#xA;cond_resched() at periodic interval in the iteration loop to avoid soft&#xA;lockup.&#xA;CVE-2025-39839:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;batman-adv: fix OOB read/write in network-coding decode&#xA;&#xA;batadv_nc_skb_decode_packet() trusts coded_len and checks only against&#xA;skb-&gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing&#xA;payload headroom, and the source skb length is not verified, allowing an&#xA;out-of-bounds read and a small out-of-bounds write.&#xA;&#xA;Validate that coded_len fits within the payload area of both destination&#xA;and source sk_buffs before XORing.&#xA;CVE-2025-38512:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: prevent A-MSDU attacks in mesh networks&#xA;&#xA;This patch is a mitigation to prevent the A-MSDU spoofing vulnerability&#xA;for mesh networks. The initial update to the IEEE 802.11 standard, in&#xA;response to the FragAttacks, missed this case (CVE-2025-27558). It can&#xA;be considered a variant of CVE-2020-24588 but for mesh networks.&#xA;&#xA;This patch tries to detect if a standard MSDU was turned into an A-MSDU&#xA;by an adversary. This is done by parsing a received A-MSDU as a standard&#xA;MSDU, calculating the length of the Mesh Control header, and seeing if&#xA;the 6 bytes after this header equal the start of an rfc1042 header. If&#xA;equal, this is a strong indication of an ongoing attack attempt.&#xA;&#xA;This defense was tested with mac80211_hwsim against a mesh network that&#xA;uses an empty Mesh Address Extension field, i.e., when four addresses&#xA;are used, and when using a 12-byte Mesh Address Extension field, i.e.,&#xA;when six addresses are used. Functionality of normal MSDUs and A-MSDUs&#xA;was also tested, and confirmed working, when using both an empty and&#xA;12-byte Mesh Address Extension field.&#xA;&#xA;It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh&#xA;networks keep being detected and prevented.&#xA;&#xA;Note that the vulnerability being patched, and the defense being&#xA;implemented, was also discussed in the following paper and in the&#xA;following IEEE 802.11 presentation:&#xA;&#xA;https://papers.mathyvanhoef.com/wisec2025.pdf&#xA;https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx&#xA;CVE-2025-39828:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().&#xA;&#xA;syzbot reported the splat below. [0]&#xA;&#xA;When atmtcp_v_open() or atmtcp_v_close() is called via connect()&#xA;or close(), atmtcp_send_control() is called to send an in-kernel&#xA;special message.&#xA;&#xA;The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.&#xA;Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.&#xA;&#xA;The notable thing is struct atmtcp_control is uAPI but has a&#xA;space for an in-kernel pointer.&#xA;&#xA;  struct atmtcp_control {&#xA;  &#x9;struct atmtcp_hdr hdr;&#x9;/* must be first */&#xA;  ...&#xA;  &#x9;atm_kptr_t vcc;&#x9;&#x9;/* both directions */&#xA;  ...&#xA;  } __ATM_API_ALIGN;&#xA;&#xA;  typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;&#xA;&#xA;The special message is processed in atmtcp_recv_control() called&#xA;from atmtcp_c_send().&#xA;&#xA;atmtcp_c_send() is vcc-&gt;dev-&gt;ops-&gt;send() and called from 2 paths:&#xA;&#xA;  1. .ndo_start_xmit() (vcc-&gt;send() == atm_send_aal0())&#xA;  2. vcc_sendmsg()&#xA;&#xA;The problem is sendmsg() does not validate the message length and&#xA;userspace can abuse atmtcp_recv_control() to overwrite any kptr&#xA;by atmtcp_control.&#xA;&#xA;Let&#39;s add a new -&gt;pre_send() hook to validate messages from sendmsg().&#xA;&#xA;[0]:&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI&#xA;KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]&#xA;CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025&#xA;RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]&#xA;RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297&#xA;Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 &lt;42&gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c&#xA;RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203&#xA;RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000&#xA;RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c&#xA;RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd&#xA;R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000&#xA;R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff&#xA;FS:  00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645&#xA; sock_sendmsg_nosec net/socket.c:714 [inline]&#xA; __sock_sendmsg+0x219/0x270 net/socket.c:729&#xA; ____sys_sendmsg+0x505/0x830 net/socket.c:2614&#xA; ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668&#xA; __sys_sendmsg net/socket.c:2700 [inline]&#xA; __do_sys_sendmsg net/socket.c:2705 [inline]&#xA; __se_sys_sendmsg net/socket.c:2703 [inline]&#xA; __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f8d7e96a4a9&#xA;Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9&#xA;RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005&#xA;RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f&#xA;R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac&#xA;R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;CVE-2025-38728:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb3: fix for slab out of bounds on mount to ksmbd&#xA;&#xA;With KASAN enabled, it is possible to get a slab out of bounds&#xA;during mount to ksmbd due to missing check in parse_server_interfaces()&#xA;(see below):&#xA;&#xA; BUG: KASAN: slab-out-of-bounds in&#xA; parse_server_interfaces+0x14ee/0x1880 [cifs]&#xA; Read of size 4 at addr ffff8881433dba98 by task mount/9827&#xA;&#xA; CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G&#xA; OE       6.16.0-rc2-kasan #2 PREEMPT(voluntary)&#xA; Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE&#xA; Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,&#xA; BIOS 2.13.1 06/14/2019&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA; dump_stack_lvl+0x9f/0xf0&#xA; print_report+0xd1/0x670&#xA; __virt_addr_valid+0x22c/0x430&#xA; ? parse_server_interfaces+0x14ee/0x1880 [cifs]&#xA; ? kasan_complete_mode_report_info+0x2a/0x1f0&#xA; ? parse_server_interfaces+0x14ee/0x1880 [cifs]&#xA;   kasan_report+0xd6/0x110&#xA;   parse_server_interfaces+0x14ee/0x1880 [cifs]&#xA;   __asan_report_load_n_noabort+0x13/0x20&#xA;   parse_server_interfaces+0x14ee/0x1880 [cifs]&#xA; ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]&#xA; ? trace_hardirqs_on+0x51/0x60&#xA; SMB3_request_interfaces+0x1ad/0x3f0 [cifs]&#xA; ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]&#xA; ? SMB2_tcon+0x23c/0x15d0 [cifs]&#xA; smb3_qfs_tcon+0x173/0x2b0 [cifs]&#xA; ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]&#xA; ? cifs_get_tcon+0x105d/0x2120 [cifs]&#xA; ? do_raw_spin_unlock+0x5d/0x200&#xA; ? cifs_get_tcon+0x105d/0x2120 [cifs]&#xA; ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]&#xA; cifs_mount_get_tcon+0x369/0xb90 [cifs]&#xA; ? dfs_cache_find+0xe7/0x150 [cifs]&#xA; dfs_mount_share+0x985/0x2970 [cifs]&#xA; ? check_path.constprop.0+0x28/0x50&#xA; ? save_trace+0x54/0x370&#xA; ? __pfx_dfs_mount_share+0x10/0x10 [cifs]&#xA; ? __lock_acquire+0xb82/0x2ba0&#xA; ? __kasan_check_write+0x18/0x20&#xA; cifs_mount+0xbc/0x9e0 [cifs]&#xA; ? __pfx_cifs_mount+0x10/0x10 [cifs]&#xA; ? do_raw_spin_unlock+0x5d/0x200&#xA; ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]&#xA; cifs_smb3_do_mount+0x263/0x1990 [cifs]&#xA;CVE-2022-50151:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: cdns3: fix random warning message when driver load&#xA;&#xA;Warning log:&#xA;[    4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!&#xA;[    4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20&#xA;[    4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)&#xA;[    4.163155] Call trace:&#xA;[    4.165600]  dump_backtrace+0x0/0x1b0&#xA;[    4.169286]  show_stack+0x18/0x68&#xA;[    4.172611]  dump_stack_lvl+0x68/0x84&#xA;[    4.176286]  dump_stack+0x18/0x34&#xA;[    4.179613]  kmalloc_fix_flags+0x60/0x88&#xA;[    4.183550]  new_slab+0x334/0x370&#xA;[    4.186878]  ___slab_alloc.part.108+0x4d4/0x748&#xA;[    4.191419]  __slab_alloc.isra.109+0x30/0x78&#xA;[    4.195702]  kmem_cache_alloc+0x40c/0x420&#xA;[    4.199725]  dma_pool_alloc+0xac/0x1f8&#xA;[    4.203486]  cdns3_allocate_trb_pool+0xb4/0xd0&#xA;&#xA;pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)&#xA;{&#xA;&#x9;...&#xA;&#x9;page = kmalloc(sizeof(*page), mem_flags);&#xA;&#x9;page-&gt;vaddr = dma_alloc_coherent(pool-&gt;dev, pool-&gt;allocation,&#xA;&#x9;&#x9;&#x9;&#x9;&#x9; &amp;page-&gt;dma, mem_flags);&#xA;&#x9;...&#xA;}&#xA;&#xA;kmalloc was called with mem_flags, which is passed down in&#xA;cdns3_allocate_trb_pool() and have GFP_DMA32 flags.&#xA;kmall_fix_flags() report warning.&#xA;&#xA;GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle&#xA;DMA memory region correctly by pool-&gt;dev. GFP_DMA32 can be removed&#xA;safely.&#xA;CVE-2025-68223:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/radeon: delete radeon_fence_process in is_signaled, no deadlock&#xA;&#xA;Delete the attempt to progress the queue when checking if fence is&#xA;signaled. This avoids deadlock.&#xA;&#xA;dma-fence_ops::signaled can be called with the fence lock in unknown&#xA;state. For radeon, the fence lock is also the wait queue lock. This can&#xA;cause a self deadlock when signaled() tries to make forward progress on&#xA;the wait queue. But advancing the queue is unneeded because incorrectly&#xA;returning false from signaled() is perfectly acceptable.&#xA;&#xA;(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)&#xA;CVE-2025-38676:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu/amd: Avoid stack buffer overflow from kernel cmdline&#xA;&#xA;While the kernel command line is considered trusted in most environments,&#xA;avoid writing 1 byte past the end of &#34;acpiid&#34; if the &#34;str&#34; argument is&#xA;maximum length.&#xA;CVE-2025-38556:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: core: Harden s32ton() against conversion to 0 bits&#xA;&#xA;Testing by the syzbot fuzzer showed that the HID core gets a&#xA;shift-out-of-bounds exception when it tries to convert a 32-bit&#xA;quantity to a 0-bit quantity.  Ideally this should never occur, but&#xA;there are buggy devices and some might have a report field with size&#xA;set to zero; we shouldn&#39;t reject the report or the device just because&#xA;of that.&#xA;&#xA;Instead, harden the s32ton() routine so that it returns a reasonable&#xA;result instead of crashing when it is called with the number of bits&#xA;set to 0 -- the same as what snto32() does.&#xA;CVE-2022-50159:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;of: check previous kernel&#39;s ima-kexec-buffer against memory bounds&#xA;&#xA;Presently ima_get_kexec_buffer() doesn&#39;t check if the previous kernel&#39;s&#xA;ima-kexec-buffer lies outside the addressable memory range. This can result&#xA;in a kernel panic if the new kernel is booted with &#39;mem=X&#39; arg and the&#xA;ima-kexec-buffer was allocated beyond that range by the previous kernel.&#xA;The panic is usually of the form below:&#xA;&#xA;$ sudo kexec --initrd initrd vmlinux --append=&#39;mem=16G&#39;&#xA;&#xA;&lt;snip&gt;&#xA; BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000&#xA; Faulting instruction address: 0xc000000000837974&#xA; Oops: Kernel access of bad area, sig: 11 [#1]&#xA;&lt;snip&gt;&#xA; NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0&#xA; LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160&#xA; Call Trace:&#xA; [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160&#xA; [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108&#xA; [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120&#xA; [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0&#xA; [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec&#xA; [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0&#xA; [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64&#xA; Instruction dump:&#xA; f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330&#xA; 7c0802a6 fb610198 7c9b2378 f80101d0 &lt;a1240000&gt; 2c090001 40820614 e9240010&#xA; ---[ end trace 0000000000000000 ]---&#xA;&#xA;Fix this issue by checking returned PFN range of previous kernel&#39;s&#xA;ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.&#xA;CVE-2025-37766:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/pm: Prevent division by zero&#xA;&#xA;The user can set any speed value.&#xA;If speed is greater than UINT_MAX/8, division by zero is possible.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2022-49190:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;kernel/resource: fix kfree() of bootmem memory again&#xA;&#xA;Since commit ebff7d8f270d (&#34;mem hotunplug: fix kfree() of bootmem&#xA;memory&#34;), we could get a resource allocated during boot via&#xA;alloc_resource().  And it&#39;s required to release the resource using&#xA;free_resource().  Howerver, many people use kfree directly which will&#xA;result in kernel BUG.  In order to fix this without fixing every call&#xA;site, just leak a couple of bytes in such corner case.&#xA;CVE-2022-49309:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()&#xA;&#xA;There is a deadlock in rtw_surveydone_event_callback(),&#xA;which is shown below:&#xA;&#xA;   (Thread 1)                  |      (Thread 2)&#xA;                               | _set_timer()&#xA;rtw_surveydone_event_callback()|  mod_timer()&#xA; spin_lock_bh() //(1)          |  (wait a time)&#xA; ...                           | rtw_scan_timeout_handler()&#xA; del_timer_sync()              |  spin_lock_bh() //(2)&#xA; (wait timer to stop)          |  ...&#xA;&#xA;We hold pmlmepriv-&gt;lock in position (1) of thread 1 and use&#xA;del_timer_sync() to wait timer to stop, but timer handler&#xA;also need pmlmepriv-&gt;lock in position (2) of thread 2.&#xA;As a result, rtw_surveydone_event_callback() will block forever.&#xA;&#xA;This patch extracts del_timer_sync() from the protection of&#xA;spin_lock_bh(), which could let timer handler to obtain&#xA;the needed lock. What`s more, we change spin_lock_bh() in&#xA;rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,&#xA;spin_lock_bh() will also cause deadlock() in timer handler.&#xA;CVE-2023-53594:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;driver core: fix resource leak in device_add()&#xA;&#xA;When calling kobject_add() failed in device_add(), it will call&#xA;cleanup_glue_dir() to free resource. But in kobject_add(),&#xA;dev-&gt;kobj.parent has been set to NULL. This will cause resource leak.&#xA;&#xA;The process is as follows:&#xA;device_add()&#xA;&#x9;get_device_parent()&#xA;&#x9;&#x9;class_dir_create_and_add()&#xA;&#x9;&#x9;&#x9;kobject_add()&#x9;&#x9;//kobject_get()&#xA;&#x9;...&#xA;&#x9;dev-&gt;kobj.parent = kobj;&#xA;&#x9;...&#xA;&#x9;kobject_add()&#x9;&#x9;//failed, but set dev-&gt;kobj.parent = NULL&#xA;&#x9;...&#xA;&#x9;glue_dir = get_glue_dir(dev)&#x9;//glue_dir = NULL, and goto&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;//&#34;Error&#34; label&#xA;&#x9;...&#xA;&#x9;cleanup_glue_dir()&#x9;//becaues glue_dir is NULL, not call&#xA;&#x9;&#x9;&#x9;&#x9;//kobject_put()&#xA;&#xA;The preceding problem may cause insmod mac80211_hwsim.ko to failed.&#xA;sysfs: cannot create duplicate filename &#39;/devices/virtual/mac80211_hwsim&#39;&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;dump_stack_lvl+0x8e/0xd1&#xA;sysfs_warn_dup.cold+0x1c/0x29&#xA;sysfs_create_dir_ns+0x224/0x280&#xA;kobject_add_internal+0x2aa/0x880&#xA;kobject_add+0x135/0x1a0&#xA;get_device_parent+0x3d7/0x590&#xA;device_add+0x2aa/0x1cb0&#xA;device_create_groups_vargs+0x1eb/0x260&#xA;device_create+0xdc/0x110&#xA;mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]&#xA;init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]&#xA;do_one_initcall+0x10f/0x630&#xA;do_init_module+0x19f/0x5e0&#xA;load_module+0x64b7/0x6eb0&#xA;__do_sys_finit_module+0x140/0x200&#xA;do_syscall_64+0x35/0x80&#xA;entry_SYSCALL_64_after_hwframe+0x46/0xb0&#xA;&lt;/TASK&gt;&#xA;kobject_add_internal failed for mac80211_hwsim with -EEXIST, don&#39;t try to&#xA;register things with the same name in the same directory.&#xA;CVE-2023-53596:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drivers: base: Free devm resources when unregistering a device&#xA;&#xA;In the current code, devres_release_all() only gets called if the device&#xA;has a bus and has been probed.&#xA;&#xA;This leads to issues when using bus-less or driver-less devices where&#xA;the device might never get freed if a managed resource holds a reference&#xA;to the device. This is happening in the DRM framework for example.&#xA;&#xA;We should thus call devres_release_all() in the device_del() function to&#xA;make sure that the device-managed actions are properly executed when the&#xA;device is unregistered, even if it has neither a bus nor a driver.&#xA;&#xA;This is effectively the same change than commit 2f8d16a996da (&#34;devres:&#xA;release resources on device_del()&#34;) that got reverted by commit&#xA;a525a3ddeaca (&#34;driver core: free devres in device_release&#34;) over&#xA;memory leaks concerns.&#xA;&#xA;This patch effectively combines the two commits mentioned above to&#xA;release the resources both on device_del() and device_release() and get&#xA;the best of both worlds.&#xA;CVE-2023-53840:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: early: xhci-dbc: Fix a potential out-of-bound memory access&#xA;&#xA;If xdbc_bulk_write() fails, the values in &#39;buf&#39; can be anything. So the&#xA;string is not guaranteed to be NULL terminated when xdbc_trace() is called.&#xA;&#xA;Reserve an extra byte, which will be zeroed automatically because &#39;buf&#39; is&#xA;a static variable, in order to avoid troubles, should it happen.&#xA;CVE-2025-40346:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()&#xA;&#xA;Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()&#xA;which causes the code to proceed with NULL clock pointers. The current&#xA;logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both&#xA;valid pointers and NULL, leading to potential NULL pointer dereference&#xA;in clk_get_rate().&#xA;&#xA;Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:&#xA;&#34;The error code within @ptr if it is an error pointer; 0 otherwise.&#34;&#xA;&#xA;This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL&#xA;pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)&#xA;when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be&#xA;called when of_clk_get() returns NULL.&#xA;&#xA;Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid&#xA;pointers, preventing potential NULL pointer dereference in clk_get_rate().&#xA;CVE-2023-54321:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;driver core: fix potential null-ptr-deref in device_add()&#xA;&#xA;I got the following null-ptr-deref report while doing fault injection test:&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000058&#xA;CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G    B   W        N 6.1.0-rc3+&#xA;RIP: 0010:klist_put+0x2d/0xd0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; klist_remove+0xf1/0x1c0&#xA; device_release_driver_internal+0x196/0x210&#xA; bus_remove_device+0x1bd/0x240&#xA; device_add+0xd3d/0x1100&#xA; w1_add_master_device+0x476/0x490 [wire]&#xA; ds2482_probe+0x303/0x3e0 [ds2482]&#xA;&#xA;This is how it happened:&#xA;&#xA;w1_alloc_dev()&#xA;  // The dev-&gt;driver is set to w1_master_driver.&#xA;  memcpy(&amp;dev-&gt;dev, device, sizeof(struct device));&#xA;  device_add()&#xA;    bus_add_device()&#xA;    dpm_sysfs_add() // It fails, calls bus_remove_device.&#xA;&#xA;    // error path&#xA;    bus_remove_device()&#xA;      // The dev-&gt;driver is not null, but driver is not bound.&#xA;      __device_release_driver()&#xA;        klist_remove(&amp;dev-&gt;p-&gt;knode_driver) &lt;-- It causes null-ptr-deref.&#xA;&#xA;    // normal path&#xA;    bus_probe_device() // It&#39;s not called yet.&#xA;      device_bind_driver()&#xA;&#xA;If dev-&gt;driver is set, in the error path after calling bus_add_device()&#xA;in device_add(), bus_remove_device() is called, then the device will be&#xA;detached from driver. But device_bind_driver() is not called yet, so it&#xA;causes null-ptr-deref while access the &#39;knode_driver&#39;. To fix this, set&#xA;dev-&gt;driver to null in the error path before calling bus_remove_device().&#xA;CVE-2025-38024:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug&#xA;&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:378 [inline]&#xA; print_report+0xcf/0x610 mm/kasan/report.c:489&#xA; kasan_report+0xb5/0xe0 mm/kasan/report.c:602&#xA; rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195&#xA; rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132&#xA; __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232&#xA; rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109&#xA; create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052&#xA; ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095&#xA; ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679&#xA; vfs_write fs/read_write.c:677 [inline]&#xA; vfs_write+0x26a/0xcc0 fs/read_write.c:659&#xA; ksys_write+0x1b8/0x200 fs/read_write.c:731&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;In the function rxe_create_cq, when rxe_cq_from_init fails, the function&#xA;rxe_cleanup will be called to handle the allocated resources. In fact,&#xA;some memory resources have already been freed in the function&#xA;rxe_cq_from_init. Thus, this problem will occur.&#xA;&#xA;The solution is to let rxe_cleanup do all the work.&#xA;CVE-2025-38004:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: bcm: add locking for bcm_op runtime updates&#xA;&#xA;The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via&#xA;hrtimer. The content and also the length of the sequence can be changed&#xA;resp reduced at runtime where the &#39;currframe&#39; counter is then set to zero.&#xA;&#xA;Although this appeared to be a safe operation the updates of &#39;currframe&#39;&#xA;can be triggered from user space and hrtimer context in bcm_can_tx().&#xA;Anderson Nascimento created a proof of concept that triggered a KASAN&#xA;slab-out-of-bounds read access which can be prevented with a spin_lock_bh.&#xA;&#xA;At the rework of bcm_can_tx() the &#39;count&#39; variable has been moved into&#xA;the protected section as this variable can be modified from both contexts&#xA;too.&#xA;CVE-2025-38154:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, sockmap: Avoid using sk_socket after free when sending&#xA;&#xA;The sk-&gt;sk_socket is not locked or referenced in backlog thread, and&#xA;during the call to skb_send_sock(), there is a race condition with&#xA;the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)&#xA;will be affected.&#xA;&#xA;Race conditions:&#xA;&#39;&#39;&#39;&#xA;CPU0                               CPU1&#xA;&#xA;backlog::skb_send_sock&#xA;  sendmsg_unlocked&#xA;    sock_sendmsg&#xA;      sock_sendmsg_nosec&#xA;                                   close(fd):&#xA;                                     ...&#xA;                                     ops-&gt;release() -&gt; sock_map_close()&#xA;                                     sk_socket-&gt;ops = NULL&#xA;                                     free(socket)&#xA;      sock-&gt;ops-&gt;sendmsg&#xA;            ^&#xA;            panic here&#xA;&#39;&#39;&#39;&#xA;&#xA;The ref of psock become 0 after sock_map_close() executed.&#xA;&#39;&#39;&#39;&#xA;void sock_map_close()&#xA;{&#xA;    ...&#xA;    if (likely(psock)) {&#xA;    ...&#xA;    // !! here we remove psock and the ref of psock become 0&#xA;    sock_map_remove_links(sk, psock)&#xA;    psock = sk_psock_get(sk);&#xA;    if (unlikely(!psock))&#xA;        goto no_psock; &lt;=== Control jumps here via goto&#xA;        ...&#xA;        cancel_delayed_work_sync(&amp;psock-&gt;work); &lt;=== not executed&#xA;        sk_psock_put(sk, psock);&#xA;        ...&#xA;}&#xA;&#39;&#39;&#39;&#xA;&#xA;Based on the fact that we already wait for the workqueue to finish in&#xA;sock_map_close() if psock is held, we simply increase the psock&#xA;reference count to avoid race conditions.&#xA;&#xA;With this patch, if the backlog thread is running, sock_map_close() will&#xA;wait for the backlog thread to complete and cancel all pending work.&#xA;&#xA;If no backlog running, any pending work that hasn&#39;t started by then will&#xA;fail when invoked by sk_psock_get(), as the psock reference count have&#xA;been zeroed, and sk_psock_drop() will cancel all jobs via&#xA;cancel_delayed_work_sync().&#xA;&#xA;In summary, we require synchronization to coordinate the backlog thread&#xA;and close() thread.&#xA;&#xA;The panic I catched:&#xA;&#39;&#39;&#39;&#xA;Workqueue: events sk_psock_backlog&#xA;RIP: 0010:sock_sendmsg+0x21d/0x440&#xA;RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? die_addr+0x40/0xa0&#xA; ? exc_general_protection+0x14c/0x230&#xA; ? asm_exc_general_protection+0x26/0x30&#xA; ? sock_sendmsg+0x21d/0x440&#xA; ? sock_sendmsg+0x3e0/0x440&#xA; ? __pfx_sock_sendmsg+0x10/0x10&#xA; __skb_send_sock+0x543/0xb70&#xA; sk_psock_backlog+0x247/0xb80&#xA;...&#xA;&#39;&#39;&#39;&#xA;CVE-2023-52927:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: allow exp not to be removed in nf_ct_find_expectation&#xA;&#xA;Currently nf_conntrack_in() calling nf_ct_find_expectation() will&#xA;remove the exp from the hash table. However, in some scenario, we&#xA;expect the exp not to be removed when the created ct will not be&#xA;confirmed, like in OVS and TC conntrack in the following patches.&#xA;&#xA;This patch allows exp not to be removed by setting IPS_CONFIRMED&#xA;in the status of the tmpl.&#xA;CVE-2025-39797:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xfrm: Duplicate SPI Handling&#xA;&#xA;The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI&#xA;Netlink message, which triggers the kernel function xfrm_alloc_spi().&#xA;This function is expected to ensure uniqueness of the Security Parameter&#xA;Index (SPI) for inbound Security Associations (SAs). However, it can&#xA;return success even when the requested SPI is already in use, leading&#xA;to duplicate SPIs assigned to multiple inbound SAs, differentiated&#xA;only by their destination addresses.&#xA;&#xA;This behavior causes inconsistencies during SPI lookups for inbound packets.&#xA;Since the lookup may return an arbitrary SA among those with the same SPI,&#xA;packet processing can fail, resulting in packet drops.&#xA;&#xA;According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA&#xA;is uniquely identified by the SPI and optionally protocol.&#xA;&#xA;Reproducing the Issue Reliably:&#xA;To consistently reproduce the problem, restrict the available SPI range in&#xA;charon.conf : spi_min = 0x10000000 spi_max = 0x10000002&#xA;This limits the system to only 2 usable SPI values.&#xA;Next, create more than 2 Child SA. each using unique pair of src/dst address.&#xA;As soon as the 3rd Child SA is initiated, it will be assigned a duplicate&#xA;SPI, since the SPI pool is already exhausted.&#xA;With a narrow SPI range, the issue is consistently reproducible.&#xA;With a broader/default range, it becomes rare and unpredictable.&#xA;&#xA;Current implementation:&#xA;xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.&#xA;So if two SAs have the same SPI but different destination addresses, then&#xA;they will:&#xA;a. Hash into different buckets&#xA;b. Be stored in different linked lists (byspi + h)&#xA;c. Not be seen in the same hlist_for_each_entry_rcu() iteration.&#xA;As a result, the lookup will result in NULL and kernel allows that Duplicate SPI&#xA;&#xA;Proposed Change:&#xA;xfrm_state_lookup_spi_proto() does a truly global search - across all states,&#xA;regardless of hash bucket and matches SPI and proto.&#xA;CVE-2025-40215:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xfrm: delete x-&gt;tunnel as we delete x&#xA;&#xA;The ipcomp fallback tunnels currently get deleted (from the various&#xA;lists and hashtables) as the last user state that needed that fallback&#xA;is destroyed (not deleted). If a reference to that user state still&#xA;exists, the fallback state will remain on the hashtables/lists,&#xA;triggering the WARN in xfrm_state_fini. Because of those remaining&#xA;references, the fix in commit f75a2804da39 (&#34;xfrm: destroy xfrm_state&#xA;synchronously on net exit path&#34;) is not complete.&#xA;&#xA;We recently fixed one such situation in TCP due to defered freeing of&#xA;skbs (commit 9b6412e6979f (&#34;tcp: drop secpath at the same time as we&#xA;currently drop dst&#34;)). This can also happen due to IP reassembly: skbs&#xA;with a secpath remain on the reassembly queue until netns&#xA;destruction. If we can&#39;t guarantee that the queues are flushed by the&#xA;time xfrm_state_fini runs, there may still be references to a (user)&#xA;xfrm_state, preventing the timely deletion of the corresponding&#xA;fallback state.&#xA;&#xA;Instead of chasing each instance of skbs holding a secpath one by one,&#xA;this patch fixes the issue directly within xfrm, by deleting the&#xA;fallback state as soon as the last user state depending on it has been&#xA;deleted. Destruction will still happen when the final reference is&#xA;dropped.&#xA;&#xA;A separate lockdep class for the fallback state is required since&#xA;we&#39;re going to lock x-&gt;tunnel while x is locked.&#xA;CVE-2025-21981:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ice: fix memory leak in aRFS after reset&#xA;&#xA;Fix aRFS (accelerated Receive Flow Steering) structures memory leak by&#xA;adding a checker to verify if aRFS memory is already allocated while&#xA;configuring VSI. aRFS objects are allocated in two cases:&#xA;- as part of VSI initialization (at probe), and&#xA;- as part of reset handling&#xA;&#xA;However, VSI reconfiguration executed during reset involves memory&#xA;allocation one more time, without prior releasing already allocated&#xA;resources. This led to the memory leak with the following signature:&#xA;&#xA;[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak&#xA;unreferenced object 0xff3c1ca7252e6000 (size 8192):&#xA;  comm &#34;kworker/0:0&#34;, pid 8, jiffies 4296833052&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace (crc 0):&#xA;    [&lt;ffffffff991ec485&gt;] __kmalloc_cache_noprof+0x275/0x340&#xA;    [&lt;ffffffffc0a6e06a&gt;] ice_init_arfs+0x3a/0xe0 [ice]&#xA;    [&lt;ffffffffc09f1027&gt;] ice_vsi_cfg_def+0x607/0x850 [ice]&#xA;    [&lt;ffffffffc09f244b&gt;] ice_vsi_setup+0x5b/0x130 [ice]&#xA;    [&lt;ffffffffc09c2131&gt;] ice_init+0x1c1/0x460 [ice]&#xA;    [&lt;ffffffffc09c64af&gt;] ice_probe+0x2af/0x520 [ice]&#xA;    [&lt;ffffffff994fbcd3&gt;] local_pci_probe+0x43/0xa0&#xA;    [&lt;ffffffff98f07103&gt;] work_for_cpu_fn+0x13/0x20&#xA;    [&lt;ffffffff98f0b6d9&gt;] process_one_work+0x179/0x390&#xA;    [&lt;ffffffff98f0c1e9&gt;] worker_thread+0x239/0x340&#xA;    [&lt;ffffffff98f14abc&gt;] kthread+0xcc/0x100&#xA;    [&lt;ffffffff98e45a6d&gt;] ret_from_fork+0x2d/0x50&#xA;    [&lt;ffffffff98e083ba&gt;] ret_from_fork_asm+0x1a/0x30&#xA;    ...&#xA;CVE-2025-23138:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;watch_queue: fix pipe accounting mismatch&#xA;&#xA;Currently, watch_queue_set_size() modifies the pipe buffers charged to&#xA;user-&gt;pipe_bufs without updating the pipe-&gt;nr_accounted on the pipe&#xA;itself, due to the if (!pipe_has_watch_queue()) test in&#xA;pipe_resize_ring(). This means that when the pipe is ultimately freed,&#xA;we decrement user-&gt;pipe_bufs by something other than what than we had&#xA;charged to it, potentially leading to an underflow. This in turn can&#xA;cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.&#xA;&#xA;To remedy this, explicitly account for the pipe usage in&#xA;watch_queue_set_size() to match the number set via account_pipe_buffers()&#xA;&#xA;(It&#39;s unclear why watch_queue_set_size() does not update nr_accounted;&#xA;it may be due to intentional overprovisioning in watch_queue_set_size()?)&#xA;CVE-2022-49829:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/scheduler: fix fence ref counting&#xA;&#xA;We leaked dependency fences when processes were beeing killed.&#xA;&#xA;Additional to that grab a reference to the last scheduled fence.&#xA;CVE-2025-37770:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/pm: Prevent division by zero&#xA;&#xA;The user can set any speed value.&#xA;If speed is greater than UINT_MAX/8, division by zero is possible.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2025-38480:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;comedi: Fix use of uninitialized data in insn_rw_emulate_bits()&#xA;&#xA;For Comedi `INSN_READ` and `INSN_WRITE` instructions on &#34;digital&#34;&#xA;subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and&#xA;`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have&#xA;`insn_read` and `insn_write` handler functions, but to have an&#xA;`insn_bits` handler function for handling Comedi `INSN_BITS`&#xA;instructions.  In that case, the subdevice&#39;s `insn_read` and/or&#xA;`insn_write` function handler pointers are set to point to the&#xA;`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.&#xA;&#xA;For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the&#xA;supplied `data[0]` value is a valid copy from user memory.  It will at&#xA;least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in&#xA;&#34;comedi_fops.c&#34; ensure at lease `MIN_SAMPLES` (16) elements are&#xA;allocated.  However, if `insn-&gt;n` is 0 (which is allowable for&#xA;`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain&#xA;uninitialized data, and certainly contains invalid data, possibly from a&#xA;different instruction in the array of instructions handled by&#xA;`do_insnlist_ioctl()`.  This will result in an incorrect value being&#xA;written to the digital output channel (or to the digital input/output&#xA;channel if configured as an output), and may be reflected in the&#xA;internal saved state of the channel.&#xA;&#xA;Fix it by returning 0 early if `insn-&gt;n` is 0, before reaching the code&#xA;that accesses `data[0]`.  Previously, the function always returned 1 on&#xA;success, but it is supposed to be the number of data samples actually&#xA;read or written up to `insn-&gt;n`, which is 0 in this case.&#xA;CVE-2025-39945:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cnic: Fix use-after-free bugs in cnic_delete_task&#xA;&#xA;The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),&#xA;which does not guarantee that the delayed work item &#39;delete_task&#39; has&#xA;fully completed if it was already running. Additionally, the delayed work&#xA;item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only&#xA;blocks and waits for work items that were already queued to the&#xA;workqueue prior to its invocation. Any work items submitted after&#xA;flush_workqueue() is called are not included in the set of tasks that the&#xA;flush operation awaits. This means that after the cyclic work items have&#xA;finished executing, a delayed work item may still exist in the workqueue.&#xA;This leads to use-after-free scenarios where the cnic_dev is deallocated&#xA;by cnic_free_dev(), while delete_task remains active and attempt to&#xA;dereference cnic_dev in cnic_delete_task().&#xA;&#xA;A typical race condition is illustrated below:&#xA;&#xA;CPU 0 (cleanup)              | CPU 1 (delayed work callback)&#xA;cnic_netdev_event()          |&#xA;  cnic_stop_hw()             | cnic_delete_task()&#xA;    cnic_cm_stop_bnx2x_hw()  | ...&#xA;      cancel_delayed_work()  | /* the queue_delayed_work()&#xA;      flush_workqueue()      |    executes after flush_workqueue()*/&#xA;                             | queue_delayed_work()&#xA;  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance&#xA;                             |   dev = cp-&gt;dev; //use&#xA;&#xA;Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure&#xA;that the cyclic delayed work item is properly canceled and that any&#xA;ongoing execution of the work item completes before the cnic_dev is&#xA;deallocated. Furthermore, since cancel_delayed_work_sync() uses&#xA;__flush_work(work, true) to synchronously wait for any currently&#xA;executing instance of the work item to finish, the flush_workqueue()&#xA;becomes redundant and should be removed.&#xA;&#xA;This bug was identified through static analysis. To reproduce the issue&#xA;and validate the fix, I simulated the cnic PCI device in QEMU and&#xA;introduced intentional delays — such as inserting calls to ssleep()&#xA;within the cnic_delete_task() function — to increase the likelihood&#xA;of triggering the bug.&#xA;CVE-2025-39835:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xfs: do not propagate ENODATA disk errors into xattr code&#xA;&#xA;ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;&#xA;namely, that the requested attribute name could not be found.&#xA;&#xA;However, a medium error from disk may also return ENODATA. At best,&#xA;this medium error may escape to userspace as &#34;attribute not found&#34;&#xA;when in fact it&#39;s an IO (disk) error.&#xA;&#xA;At worst, we may oops in xfs_attr_leaf_get() when we do:&#xA;&#xA;&#x9;error = xfs_attr_leaf_hasname(args, &amp;bp);&#xA;&#x9;if (error == -ENOATTR)  {&#xA;&#x9;&#x9;xfs_trans_brelse(args-&gt;trans, bp);&#xA;&#x9;&#x9;return error;&#xA;&#x9;}&#xA;&#xA;because an ENODATA/ENOATTR error from disk leaves us with a null bp,&#xA;and the xfs_trans_brelse will then null-deref it.&#xA;&#xA;As discussed on the list, we really need to modify the lower level&#xA;IO functions to trap all disk errors and ensure that we don&#39;t let&#xA;unique errors like this leak up into higher xfs functions - many&#xA;like this should be remapped to EIO.&#xA;&#xA;However, this patch directly addresses a reported bug in the xattr&#xA;code, and should be safe to backport to stable kernels. A larger-scope&#xA;patch to handle more unique errors at lower levels can follow later.&#xA;&#xA;(Note, prior to 07120f1abdff we did not oops, but we did return the&#xA;wrong error code to userspace.)&#xA;CVE-2025-37947:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: prevent out-of-bounds stream writes by validating *pos&#xA;&#xA;ksmbd_vfs_stream_write() did not validate whether the write offset&#xA;(*pos) was within the bounds of the existing stream data length (v_len).&#xA;If *pos was greater than or equal to v_len, this could lead to an&#xA;out-of-bounds memory write.&#xA;&#xA;This patch adds a check to ensure *pos is less than v_len before&#xA;proceeding. If the condition fails, -EINVAL is returned.&#xA;CVE-2025-71067:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ntfs: set dummy blocksize to read boot_block when mounting&#xA;&#xA;When mounting, sb-&gt;s_blocksize is used to read the boot_block without&#xA;being defined or validated. Set a dummy blocksize before attempting to&#xA;read the boot_block.&#xA;&#xA;The issue can be triggered with the following syz reproducer:&#xA;&#xA;  mkdirat(0xffffffffffffff9c, &amp;(0x7f0000000080)=&#39;./file1\x00&#39;, 0x0)&#xA;  r4 = openat$nullb(0xffffffffffffff9c, &amp;(0x7f0000000040), 0x121403, 0x0)&#xA;  ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &amp;(0x7f0000000980)=0x4000)&#xA;  mount(&amp;(0x7f0000000140)=@nullb, &amp;(0x7f0000000040)=&#39;./cgroup\x00&#39;,&#xA;        &amp;(0x7f0000000000)=&#39;ntfs3\x00&#39;, 0x2208004, 0x0)&#xA;  syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)&#xA;&#xA;Here, the ioctl sets the bdev block size to 16384. During mount,&#xA;get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),&#xA;but since block_size(bdev) &gt; PAGE_SIZE, sb_set_blocksize() leaves&#xA;sb-&gt;s_blocksize at zero.&#xA;&#xA;Later, ntfs_init_from_boot() attempts to read the boot_block while&#xA;sb-&gt;s_blocksize is still zero, which triggers the bug.&#xA;&#xA;[[email protected]: changed comment style, added&#xA;return value handling]&#xA;CVE-2026-22998:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec&#xA;&#xA;Commit efa56305908b (&#34;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length&#34;)&#xA;added ttag bounds checking and data_offset&#xA;validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate&#xA;whether the command&#39;s data structures (cmd-&gt;req.sg and cmd-&gt;iov) have&#xA;been properly initialized before processing H2C_DATA PDUs.&#xA;&#xA;The nvmet_tcp_build_pdu_iovec() function dereferences these pointers&#xA;without NULL checks. This can be triggered by sending H2C_DATA PDU&#xA;immediately after the ICREQ/ICRESP handshake, before&#xA;sending a CONNECT command or NVMe write command.&#xA;&#xA;Attack vectors that trigger NULL pointer dereferences:&#xA;1. H2C_DATA PDU sent before CONNECT → both pointers NULL&#xA;2. H2C_DATA PDU for READ command → cmd-&gt;req.sg allocated, cmd-&gt;iov NULL&#xA;3. H2C_DATA PDU for uninitialized command slot → both pointers NULL&#xA;&#xA;The fix validates both cmd-&gt;req.sg and cmd-&gt;iov before calling&#xA;nvmet_tcp_build_pdu_iovec(). Both checks are required because:&#xA;- Uninitialized commands: both NULL&#xA;- READ commands: cmd-&gt;req.sg allocated, cmd-&gt;iov NULL&#xA;- WRITE commands: both allocated&#xA;CVE-2025-40342:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-fc: use lock accessing port_state and rport state&#xA;&#xA;nvme_fc_unregister_remote removes the remote port on a lport object at&#xA;any point in time when there is no active association. This races with&#xA;with the reconnect logic, because nvme_fc_create_association is not&#xA;taking a lock to check the port_state and atomically increase the&#xA;active count on the rport.&#xA;CVE-2022-50616:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;regulator: core: Use different devices for resource allocation and DT lookup&#xA;&#xA;Following by the below discussion, there&#39;s the potential UAF issue&#xA;between regulator and mfd.&#xA;https://lore.kernel.org/all/[email protected]/&#xA;&#xA;From the analysis of Yingliang&#xA;&#xA;CPU A&#x9;&#x9;&#x9;&#x9;|CPU B&#xA;mt6370_probe()&#x9;&#x9;&#x9;|&#xA;  devm_mfd_add_devices()&#x9;|&#xA;&#x9;&#x9;&#x9;&#x9;|mt6370_regulator_probe()&#xA;&#x9;&#x9;&#x9;&#x9;|  regulator_register()&#xA;&#x9;&#x9;&#x9;&#x9;|    //allocate init_data and add it to devres&#xA;&#x9;&#x9;&#x9;&#x9;|    regulator_of_get_init_data()&#xA;i2c_unregister_device()&#x9;&#x9;|&#xA;  device_del()&#x9;&#x9;&#x9;|&#xA;    devres_release_all()&#x9;|&#xA;      // init_data is freed&#x9;|&#xA;      release_nodes()&#x9;&#x9;|&#xA;&#x9;&#x9;&#x9;&#x9;|  // using init_data causes UAF&#xA;&#x9;&#x9;&#x9;&#x9;|  regulator_register()&#xA;&#xA;It&#39;s common to use mfd core to create child device for the regulator.&#xA;In order to do the DT lookup for init data, the child that registered&#xA;the regulator would pass its parent as the parameter. And this causes&#xA;init data resource allocated to its parent, not itself. The issue happen&#xA;when parent device is going to release and regulator core is still doing&#xA;some operation of init data constraint for the regulator of child device.&#xA;&#xA;To fix it, this patch expand &#39;regulator_register&#39; API to use the&#xA;different devices for init data allocation and DT lookup.&#xA;CVE-2025-39749:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rcu: Protect -&gt;defer_qs_iw_pending from data race&#xA;&#xA;On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is&#xA;invoked within an interrupts-disabled region of code [1], it will invoke&#xA;rcu_read_unlock_special(), which uses an irq-work handler to force the&#xA;system to notice when the RCU read-side critical section actually ends.&#xA;That end won&#39;t happen until interrupts are enabled at the soonest.&#xA;&#xA;In some kernels, such as those booted with rcutree.use_softirq=y, the&#xA;irq-work handler is used unconditionally.&#xA;&#xA;The per-CPU rcu_data structure&#39;s -&gt;defer_qs_iw_pending field is&#xA;updated by the irq-work handler and is both read and updated by&#xA;rcu_read_unlock_special().  This resulted in the following KCSAN splat:&#xA;&#xA;------------------------------------------------------------------------&#xA;&#xA;BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special&#xA;&#xA;read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:&#xA; rcu_read_unlock_special+0x175/0x260&#xA; __rcu_read_unlock+0x92/0xa0&#xA; rt_spin_unlock+0x9b/0xc0&#xA; __local_bh_enable+0x10d/0x170&#xA; __local_bh_enable_ip+0xfb/0x150&#xA; rcu_do_batch+0x595/0xc40&#xA; rcu_cpu_kthread+0x4e9/0x830&#xA; smpboot_thread_fn+0x24d/0x3b0&#xA; kthread+0x3bd/0x410&#xA; ret_from_fork+0x35/0x40&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:&#xA; rcu_preempt_deferred_qs_handler+0x1e/0x30&#xA; irq_work_single+0xaf/0x160&#xA; run_irq_workd+0x91/0xc0&#xA; smpboot_thread_fn+0x24d/0x3b0&#xA; kthread+0x3bd/0x410&#xA; ret_from_fork+0x35/0x40&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;no locks held by irq_work/8/88.&#xA;irq event stamp: 200272&#xA;hardirqs last  enabled at (200272): [&lt;ffffffffb0f56121&gt;] finish_task_switch+0x131/0x320&#xA;hardirqs last disabled at (200271): [&lt;ffffffffb25c7859&gt;] __schedule+0x129/0xd70&#xA;softirqs last  enabled at (0): [&lt;ffffffffb0ee093f&gt;] copy_process+0x4df/0x1cc0&#xA;softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0&#xA;&#xA;------------------------------------------------------------------------&#xA;&#xA;The problem is that irq-work handlers run with interrupts enabled, which&#xA;means that rcu_preempt_deferred_qs_handler() could be interrupted,&#xA;and that interrupt handler might contain an RCU read-side critical&#xA;section, which might invoke rcu_read_unlock_special().  In the strict&#xA;KCSAN mode of operation used by RCU, this constitutes a data race on&#xA;the -&gt;defer_qs_iw_pending field.&#xA;&#xA;This commit therefore disables interrupts across the portion of the&#xA;rcu_preempt_deferred_qs_handler() that updates the -&gt;defer_qs_iw_pending&#xA;field.  This suffices because this handler is not a fast path.&#xA;CVE-2026-23038:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()&#xA;&#xA;In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,&#xA;the function jumps to the out_scratch label without freeing the already&#xA;allocated dsaddrs list, leading to a memory leak.&#xA;&#xA;Fix this by jumping to the out_err_drain_dsaddrs label, which properly&#xA;frees the dsaddrs list before cleaning up other resources.&#xA;CVE-2023-53521:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()&#xA;&#xA;A fix for:&#xA;&#xA;BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]&#xA;Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013&#xA;&#xA;When edev-&gt;components is zero, accessing edev-&gt;component[0] members is&#xA;wrong.&#xA;CVE-2025-68819:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()&#xA;&#xA;rlen value is a user-controlled value, but dtv5100_i2c_msg() does not&#xA;check the size of the rlen value. Therefore, if it is set to a value&#xA;larger than sizeof(st-&gt;data), an out-of-bounds vuln occurs for st-&gt;data.&#xA;&#xA;Therefore, we need to add proper range checking to prevent this vuln.&#xA;CVE-2025-71084:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/cm: Fix leaking the multicast GID table reference&#xA;&#xA;If the CM ID is destroyed while the CM event for multicast creating is&#xA;still queued the cancel_work_sync() will prevent the work from running&#xA;which also prevents destroying the ah_attr. This leaks a refcount and&#xA;triggers a WARN:&#xA;&#xA;   GID entry ref leak for dev syz1 index 2 ref=573&#xA;   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]&#xA;   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886&#xA;&#xA;Destroy the ah_attr after canceling the work, it is safe to call this&#xA;twice.&#xA;CVE-2025-68192:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup&#xA;&#xA;Raw IP packets have no MAC header, leaving skb-&gt;mac_header uninitialized.&#xA;This can trigger kernel panics on ARM64 when xfrm or other subsystems&#xA;access the offset due to strict alignment checks.&#xA;&#xA;Initialize the MAC header to prevent such crashes.&#xA;&#xA;This can trigger kernel panics on ARM when running IPsec over the&#xA;qmimux0 interface.&#xA;&#xA;Example trace:&#xA;&#xA;    Internal error: Oops: 000000009600004f [#1] SMP&#xA;    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1&#xA;    Hardware name: LS1028A RDB Board (DT)&#xA;    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;    pc : xfrm_input+0xde8/0x1318&#xA;    lr : xfrm_input+0x61c/0x1318&#xA;    sp : ffff800080003b20&#xA;    Call trace:&#xA;     xfrm_input+0xde8/0x1318&#xA;     xfrm6_rcv+0x38/0x44&#xA;     xfrm6_esp_rcv+0x48/0xa8&#xA;     ip6_protocol_deliver_rcu+0x94/0x4b0&#xA;     ip6_input_finish+0x44/0x70&#xA;     ip6_input+0x44/0xc0&#xA;     ipv6_rcv+0x6c/0x114&#xA;     __netif_receive_skb_one_core+0x5c/0x8c&#xA;     __netif_receive_skb+0x18/0x60&#xA;     process_backlog+0x78/0x17c&#xA;     __napi_poll+0x38/0x180&#xA;     net_rx_action+0x168/0x2f0&#xA;CVE-2025-38574:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pptp: ensure minimal skb length in pptp_xmit()&#xA;&#xA;Commit aabc6596ffb3 (&#34;net: ppp: Add bound checking for skb data&#xA;on ppp_sync_txmung&#34;) fixed ppp_sync_txmunge()&#xA;&#xA;We need a similar fix in pptp_xmit(), otherwise we might&#xA;read uninit data as reported by syzbot.&#xA;&#xA;BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193&#xA;  pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193&#xA;  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]&#xA;  ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314&#xA;  pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379&#xA;  sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148&#xA;  __release_sock+0x1d3/0x330 net/core/sock.c:3213&#xA;  release_sock+0x6b/0x270 net/core/sock.c:3767&#xA;  pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904&#xA;  sock_sendmsg_nosec net/socket.c:712 [inline]&#xA;  __sock_sendmsg+0x330/0x3d0 net/socket.c:727&#xA;  ____sys_sendmsg+0x893/0xd80 net/socket.c:2566&#xA;  ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620&#xA;  __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709&#xA;CVE-2023-54048:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/bnxt_re: Prevent handling any completions after qp destroy&#xA;&#xA;HW may generate completions that indicates QP is destroyed.&#xA;Driver should not be scheduling any more completion handlers&#xA;for this QP, after the QP is destroyed. Since CQs are active&#xA;during the QP destroy, driver may still schedule completion&#xA;handlers. This can cause a race where the destroy_cq and poll_cq&#xA;running simultaneously.&#xA;&#xA;Snippet of kernel panic while doing bnxt_re driver load unload in loop.&#xA;This indicates a poll after the CQ is freed. &#xA;&#xA;[77786.481636] Call Trace:&#xA;[77786.481640]  &lt;TASK&gt;&#xA;[77786.481644]  bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]&#xA;[77786.481658]  ? kvm_clock_read+0x14/0x30&#xA;[77786.481693]  __ib_process_cq+0x57/0x190 [ib_core]&#xA;[77786.481728]  ib_cq_poll_work+0x26/0x80 [ib_core]&#xA;[77786.481761]  process_one_work+0x1e5/0x3f0&#xA;[77786.481768]  worker_thread+0x50/0x3a0&#xA;[77786.481785]  ? __pfx_worker_thread+0x10/0x10&#xA;[77786.481790]  kthread+0xe2/0x110&#xA;[77786.481794]  ? __pfx_kthread+0x10/0x10&#xA;[77786.481797]  ret_from_fork+0x2c/0x50&#xA;&#xA;To avoid this, complete all completion handlers before returning the&#xA;destroy QP. If free_cq is called soon after destroy_qp,  IB stack&#xA;will cancel the CQ work before invoking the destroy_cq verb and&#xA;this will prevent any race mentioned.&#xA;CVE-2022-50735:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mt76: do not run mt76u_status_worker if the device is not running&#xA;&#xA;Fix the following NULL pointer dereference avoiding to run&#xA;mt76u_status_worker thread if the device is not running yet.&#xA;&#xA;KASAN: null-ptr-deref in range&#xA;[0x0000000000000000-0x0000000000000007]&#xA;CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware&#xA;name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014&#xA;Workqueue: mt76 mt76u_tx_status_data&#xA;RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0&#xA;Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00&#xA;48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 &lt;0f&gt;&#xA;b6&#xA;04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7&#xA;RSP: 0018:ffffc900005af988 EFLAGS: 00010246&#xA;RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a&#xA;RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c&#xA;R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8&#xA;R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28&#xA;FS:  0000000000000000(0000) GS:ffff88811aa00000(0000)&#xA;knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; mt76x02_send_tx_status+0x1d2/0xeb0&#xA; mt76x02_tx_status_data+0x8e/0xd0&#xA; mt76u_tx_status_data+0xe1/0x240&#xA; process_one_work+0x92b/0x1460&#xA; worker_thread+0x95/0xe00&#xA; kthread+0x3a1/0x480&#xA; ret_from_fork+0x1f/0x30&#xA;Modules linked in:&#xA;--[ end trace 8df5d20fc5040f65 ]--&#xA;RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0&#xA;Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00&#xA;48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 &lt;0f&gt;&#xA;b6&#xA;04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7&#xA;RSP: 0018:ffffc900005af988 EFLAGS: 00010246&#xA;RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a&#xA;RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c&#xA;R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8&#xA;R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28&#xA;FS:  0000000000000000(0000) GS:ffff88811aa00000(0000)&#xA;knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;&#xA;Moreover move stat_work schedule out of the for loop.&#xA;CVE-2024-53179:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: fix use-after-free of signing key&#xA;&#xA;Customers have reported use-after-free in @ses-&gt;auth_key.response with&#xA;SMB2.1 + sign mounts which occurs due to following race:&#xA;&#xA;task A                         task B&#xA;cifs_mount()&#xA; dfs_mount_share()&#xA;  get_session()&#xA;   cifs_mount_get_session()    cifs_send_recv()&#xA;    cifs_get_smb_ses()          compound_send_recv()&#xA;     cifs_setup_session()        smb2_setup_request()&#xA;      kfree_sensitive()           smb2_calc_signature()&#xA;                                   crypto_shash_setkey() *UAF*&#xA;&#xA;Fix this by ensuring that we have a valid @ses-&gt;auth_key.response by&#xA;checking whether @ses-&gt;ses_status is SES_GOOD or SES_EXITING with&#xA;@ses-&gt;ses_lock held.  After commit 24a9799aa8ef (&#34;smb: client: fix UAF&#xA;in smb2_reconnect_server()&#34;), we made sure to call -&gt;logoff() only&#xA;when @ses was known to be good (e.g. valid -&gt;auth_key.response), so&#xA;it&#39;s safe to access signing key when @ses-&gt;ses_status == SES_EXITING.&#xA;CVE-2025-71120:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf&#xA;&#xA;A zero length gss_token results in pages == 0 and in_token-&gt;pages[0]&#xA;is NULL. The code unconditionally evaluates&#xA;page_address(in_token-&gt;pages[0]) for the initial memcpy, which can&#xA;dereference NULL even when the copy length is 0. Guard the first&#xA;memcpy so it only runs when length &gt; 0.&#xA;CVE-2025-39744:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rcu: Fix rcu_read_unlock() deadloop due to IRQ work&#xA;&#xA;During rcu_read_unlock_special(), if this happens during irq_exit(), we&#xA;can lockup if an IPI is issued. This is because the IPI itself triggers&#xA;the irq_exit() path causing a recursive lock up.&#xA;&#xA;This is precisely what Xiongfeng found when invoking a BPF program on&#xA;the trace_tick_stop() tracepoint As shown in the trace below. Fix by&#xA;managing the irq_work state correctly.&#xA;&#xA;irq_exit()&#xA;  __irq_exit_rcu()&#xA;    /* in_hardirq() returns false after this */&#xA;    preempt_count_sub(HARDIRQ_OFFSET)&#xA;    tick_irq_exit()&#xA;      tick_nohz_irq_exit()&#xA;&#x9;    tick_nohz_stop_sched_tick()&#xA;&#x9;      trace_tick_stop()  /* a bpf prog is hooked on this trace point */&#xA;&#x9;&#x9;   __bpf_trace_tick_stop()&#xA;&#x9;&#x9;      bpf_trace_run2()&#xA;&#x9;&#x9;&#x9;    rcu_read_unlock_special()&#xA;                              /* will send a IPI to itself */&#xA;&#x9;&#x9;&#x9;      irq_work_queue_on(&amp;rdp-&gt;defer_qs_iw, rdp-&gt;cpu);&#xA;&#xA;A simple reproducer can also be obtained by doing the following in&#xA;tick_irq_exit(). It will hang on boot without the patch:&#xA;&#xA;  static inline void tick_irq_exit(void)&#xA;  {&#xA; +&#x9;rcu_read_lock();&#xA; +&#x9;WRITE_ONCE(current-&gt;rcu_read_unlock_special.b.need_qs, true);&#xA; +&#x9;rcu_read_unlock();&#xA; +&#xA;&#xA;[neeraj: Apply Frederic&#39;s suggested fix for PREEMPT_RT]&#xA;CVE-2025-71091:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;team: fix check for port enabled in team_queue_override_port_prio_changed()&#xA;&#xA;There has been a syzkaller bug reported recently with the following&#xA;trace:&#xA;&#xA;list_del corruption, ffff888058bea080-&gt;prev is LIST_POISON2 (dead000000000122)&#xA;------------[ cut here ]------------&#xA;kernel BUG at lib/list_debug.c:59!&#xA;Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI&#xA;CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59&#xA;Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 &lt;0f&gt; 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff&#xA;RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286&#xA;RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000&#xA;RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005&#xA;RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000&#xA;R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230&#xA;R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480&#xA;FS:  00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __list_del_entry_valid include/linux/list.h:132 [inline]&#xA; __list_del_entry include/linux/list.h:223 [inline]&#xA; list_del_rcu include/linux/rculist.h:178 [inline]&#xA; __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]&#xA; __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]&#xA; team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]&#xA; team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534&#xA; team_option_set drivers/net/team/team_core.c:376 [inline]&#xA; team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653&#xA; genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115&#xA; genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]&#xA; genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210&#xA; netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552&#xA; genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]&#xA; netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346&#xA; netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896&#xA; sock_sendmsg_nosec net/socket.c:727 [inline]&#xA; __sock_sendmsg net/socket.c:742 [inline]&#xA; ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630&#xA; ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684&#xA; __sys_sendmsg+0x16d/0x220 net/socket.c:2716&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;The problem is in this flow:&#xA;1) Port is enabled, queue_id != 0, in qom_list&#xA;2) Port gets disabled&#xA;        -&gt; team_port_disable()&#xA;        -&gt; team_queue_override_port_del()&#xA;        -&gt; del (removed from list)&#xA;3) Port is disabled, queue_id != 0, not in any list&#xA;4) Priority changes&#xA;        -&gt; team_queue_override_port_prio_changed()&#xA;        -&gt; checks: port disabled &amp;&amp; queue_id != 0&#xA;        -&gt; calls del - hits the BUG as it is removed already&#xA;&#xA;To fix this, change the check in team_queue_override_port_prio_changed()&#xA;so it returns early if port is not enabled.&#xA;CVE-2023-53250:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle&#xA;&#xA;KASAN reported a null-ptr-deref error:&#xA;&#xA;KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;CPU: 0 PID: 1373 Comm: modprobe&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;RIP: 0010:dmi_sysfs_entry_release&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; kobject_put&#xA; dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs&#xA; dmi_decode_table (drivers/firmware/dmi_scan.c:133)&#xA; dmi_walk (drivers/firmware/dmi_scan.c:1115)&#xA; dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs&#xA; do_one_initcall (init/main.c:1296)&#xA; ...&#xA;Kernel panic - not syncing: Fatal exception&#xA;Kernel Offset: 0x4000000 from 0xffffffff81000000&#xA;---[ end Kernel panic - not syncing: Fatal exception ]---&#xA;&#xA;It is because previous patch added kobject_put() to release the memory&#xA;which will call  dmi_sysfs_entry_release() and list_del().&#xA;&#xA;However, list_add_tail(entry-&gt;list) is called after the error block,&#xA;so the list_head is uninitialized and cannot be deleted.&#xA;&#xA;Move error handling to after list_add_tail to fix this.&#xA;CVE-2025-39902:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/slub: avoid accessing metadata when pointer is invalid in object_err()&#xA;&#xA;object_err() reports details of an object for further debugging, such as&#xA;the freelist pointer, redzone, etc. However, if the pointer is invalid,&#xA;attempting to access object metadata can lead to a crash since it does&#xA;not point to a valid object.&#xA;&#xA;One known path to the crash is when alloc_consistency_checks()&#xA;determines the pointer to the allocated object is invalid because of a&#xA;freelist corruption, and calls object_err() to report it. The debug code&#xA;should report and handle the corruption gracefully and not crash in the&#xA;process.&#xA;&#xA;In case the pointer is NULL or check_valid_pointer() returns false for&#xA;the pointer, only print the pointer value and skip accessing metadata.&#xA;CVE-2023-54145:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log&#xA;&#xA;It&#39;s trivial for user to trigger &#34;verifier log line truncated&#34; warning,&#xA;as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at&#xA;least two pieces of user-provided information that can be output through&#xA;this buffer, and both can be arbitrarily sized by user:&#xA;  - BTF names;&#xA;  - BTF.ext source code lines strings.&#xA;&#xA;Verifier log buffer should be properly sized for typical verifier state&#xA;output. But it&#39;s sort-of expected that this buffer won&#39;t be long enough&#xA;in some circumstances. So let&#39;s drop the check. In any case code will&#xA;work correctly, at worst truncating a part of a single line output.&#xA;CVE-2025-39676:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla4xxx: Prevent a potential error pointer dereference&#xA;&#xA;The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,&#xA;but qla4xxx_ep_connect() returns error pointers.  Propagating the error&#xA;pointers will lead to an Oops in the caller, so change the error pointers&#xA;to NULL.&#xA;CVE-2025-38068:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: lzo - Fix compression buffer overrun&#xA;&#xA;Unlike the decompression code, the compression code in LZO never&#xA;checked for output overruns.  It instead assumes that the caller&#xA;always provides enough buffer space, disregarding the buffer length&#xA;provided by the caller.&#xA;&#xA;Add a safe compression interface that checks for the end of buffer&#xA;before each write.  Use the safe interface in crypto/lzo.&#xA;CVE-2026-23001:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;macvlan: fix possible UAF in macvlan_forward_source()&#xA;&#xA;Add RCU protection on (struct macvlan_source_entry)-&gt;vlan.&#xA;&#xA;Whenever macvlan_hash_del_source() is called, we must clear&#xA;entry-&gt;vlan pointer before RCU grace period starts.&#xA;&#xA;This allows macvlan_forward_source() to skip over&#xA;entries queued for freeing.&#xA;&#xA;Note that macvlan_dev are already RCU protected, as they&#xA;are embedded in a standard netdev (netdev_priv(ndev)).&#xA;&#xA;https: //lore.kernel.org/netdev/[email protected]/T/#u&#xA;CVE-2026-22999:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: sch_qfq: do not free existing class in qfq_change_class()&#xA;&#xA;Fixes qfq_change_class() error case.&#xA;&#xA;cl-&gt;qdisc and cl should only be freed if a new class and qdisc&#xA;were allocated, or we risk various UAF.&#xA;CVE-2025-71085:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()&#xA;&#xA;There exists a kernel oops caused by a BUG_ON(nhead &lt; 0) at&#xA;net/core/skbuff.c:2232 in pskb_expand_head().&#xA;This bug is triggered as part of the calipso_skbuff_setattr()&#xA;routine when skb_cow() is passed headroom &gt; INT_MAX&#xA;(i.e. (int)(skb_headroom(skb) + len_delta) &lt; 0).&#xA;&#xA;The root cause of the bug is due to an implicit integer cast in&#xA;__skb_cow(). The check (headroom &gt; skb_headroom(skb)) is meant to ensure&#xA;that delta = headroom - skb_headroom(skb) is never negative, otherwise&#xA;we will trigger a BUG_ON in pskb_expand_head(). However, if&#xA;headroom &gt; INT_MAX and delta &lt;= -NET_SKB_PAD, the check passes, delta&#xA;becomes negative, and pskb_expand_head() is passed a negative value for&#xA;nhead.&#xA;&#xA;Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing&#xA;&#34;negative&#34; headroom sizes to skb_cow() within calipso_skbuff_setattr()&#xA;by only using skb_cow() to grow headroom.&#xA;&#xA;PoC:&#xA;&#x9;Using `netlabelctl` tool:&#xA;&#xA;        netlabelctl map del default&#xA;        netlabelctl calipso add pass doi:7&#xA;        netlabelctl map add default address:0::1/128 protocol:calipso,7&#xA;&#xA;        Then run the following PoC:&#xA;&#xA;        int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);&#xA;&#xA;        // setup msghdr&#xA;        int cmsg_size = 2;&#xA;        int cmsg_len = 0x60;&#xA;        struct msghdr msg;&#xA;        struct sockaddr_in6 dest_addr;&#xA;        struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,&#xA;                        sizeof(struct cmsghdr) + cmsg_len);&#xA;        msg.msg_name = &amp;dest_addr;&#xA;        msg.msg_namelen = sizeof(dest_addr);&#xA;        msg.msg_iov = NULL;&#xA;        msg.msg_iovlen = 0;&#xA;        msg.msg_control = cmsg;&#xA;        msg.msg_controllen = cmsg_len;&#xA;        msg.msg_flags = 0;&#xA;&#xA;        // setup sockaddr&#xA;        dest_addr.sin6_family = AF_INET6;&#xA;        dest_addr.sin6_port = htons(31337);&#xA;        dest_addr.sin6_flowinfo = htonl(31337);&#xA;        dest_addr.sin6_addr = in6addr_loopback;&#xA;        dest_addr.sin6_scope_id = 31337;&#xA;&#xA;        // setup cmsghdr&#xA;        cmsg-&gt;cmsg_len = cmsg_len;&#xA;        cmsg-&gt;cmsg_level = IPPROTO_IPV6;&#xA;        cmsg-&gt;cmsg_type = IPV6_HOPOPTS;&#xA;        char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);&#xA;        hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80&#xA;&#xA;        sendmsg(fd, &amp;msg, 0);&#xA;CVE-2025-40280:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tipc: Fix use-after-free in tipc_mon_reinit_self().&#xA;&#xA;syzbot reported use-after-free of tipc_net(net)-&gt;monitors[]&#xA;in tipc_mon_reinit_self(). [0]&#xA;&#xA;The array is protected by RTNL, but tipc_mon_reinit_self()&#xA;iterates over it without RTNL.&#xA;&#xA;tipc_mon_reinit_self() is called from tipc_net_finalize(),&#xA;which is always under RTNL except for tipc_net_finalize_work().&#xA;&#xA;Let&#39;s hold RTNL in tipc_net_finalize_work().&#xA;&#xA;[0]:&#xA;BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]&#xA;BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162&#xA;Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989&#xA;&#xA;CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025&#xA;Workqueue: events tipc_net_finalize_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:378 [inline]&#xA; print_report+0xca/0x240 mm/kasan/report.c:482&#xA; kasan_report+0x118/0x150 mm/kasan/report.c:595&#xA; __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568&#xA; kasan_check_byte include/linux/kasan.h:399 [inline]&#xA; lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842&#xA; __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]&#xA; _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162&#xA; rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]&#xA; rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]&#xA; rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244&#xA; rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243&#xA; write_lock_bh include/linux/rwlock_rt.h:99 [inline]&#xA; tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718&#xA; tipc_net_finalize+0x115/0x190 net/tipc/net.c:140&#xA; process_one_work kernel/workqueue.c:3236 [inline]&#xA; process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319&#xA; worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400&#xA; kthread+0x70e/0x8a0 kernel/kthread.c:463&#xA; ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 6089:&#xA; kasan_save_stack mm/kasan/common.c:47 [inline]&#xA; kasan_save_track+0x3e/0x80 mm/kasan/common.c:68&#xA; poison_kmalloc_redzone mm/kasan/common.c:388 [inline]&#xA; __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405&#xA; kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA; __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407&#xA; kmalloc_noprof include/linux/slab.h:905 [inline]&#xA; kzalloc_noprof include/linux/slab.h:1039 [inline]&#xA; tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657&#xA; tipc_enable_bearer net/tipc/bearer.c:357 [inline]&#xA; __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047&#xA; __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]&#xA; tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393&#xA; tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]&#xA; tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321&#xA; genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115&#xA; genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]&#xA; genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210&#xA; netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552&#xA; genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]&#xA; netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346&#xA; netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896&#xA; sock_sendmsg_nosec net/socket.c:714 [inline]&#xA; __sock_sendmsg+0x21c/0x270 net/socket.c:729&#xA; ____sys_sendmsg+0x508/0x820 net/socket.c:2614&#xA; ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668&#xA; __sys_sendmsg net/socket.c:2700 [inline]&#xA; __do_sys_sendmsg net/socket.c:2705 [inline]&#xA; __se_sys_sendmsg net/socket.c:2703 [inline]&#xA; __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xfa/0x3b0 arch/&#xA;---truncated---&#xA;CVE-2025-68285:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: fix potential use-after-free in have_mon_and_osd_map()&#xA;&#xA;The wait loop in __ceph_open_session() can race with the client&#xA;receiving a new monmap or osdmap shortly after the initial map is&#xA;received.  Both ceph_monc_handle_map() and handle_one_map() install&#xA;a new map immediately after freeing the old one&#xA;&#xA;    kfree(monc-&gt;monmap);&#xA;    monc-&gt;monmap = monmap;&#xA;&#xA;    ceph_osdmap_destroy(osdc-&gt;osdmap);&#xA;    osdc-&gt;osdmap = newmap;&#xA;&#xA;under client-&gt;monc.mutex and client-&gt;osdc.lock respectively, but&#xA;because neither is taken in have_mon_and_osd_map() it&#39;s possible for&#xA;client-&gt;monc.monmap-&gt;epoch and client-&gt;osdc.osdmap-&gt;epoch arms in&#xA;&#xA;    client-&gt;monc.monmap &amp;&amp; client-&gt;monc.monmap-&gt;epoch &amp;&amp;&#xA;        client-&gt;osdc.osdmap &amp;&amp; client-&gt;osdc.osdmap-&gt;epoch;&#xA;&#xA;condition to dereference an already freed map.  This happens to be&#xA;reproducible with generic/395 and generic/397 with KASAN enabled:&#xA;&#xA;    BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70&#xA;    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305&#xA;    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266&#xA;    ...&#xA;    Call Trace:&#xA;    &lt;TASK&gt;&#xA;    have_mon_and_osd_map+0x56/0x70&#xA;    ceph_open_session+0x182/0x290&#xA;    ceph_get_tree+0x333/0x680&#xA;    vfs_get_tree+0x49/0x180&#xA;    do_new_mount+0x1a3/0x2d0&#xA;    path_mount+0x6dd/0x730&#xA;    do_mount+0x99/0xe0&#xA;    __do_sys_mount+0x141/0x180&#xA;    do_syscall_64+0x9f/0x100&#xA;    entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;    &lt;/TASK&gt;&#xA;&#xA;    Allocated by task 13305:&#xA;    ceph_osdmap_alloc+0x16/0x130&#xA;    ceph_osdc_init+0x27a/0x4c0&#xA;    ceph_create_client+0x153/0x190&#xA;    create_fs_client+0x50/0x2a0&#xA;    ceph_get_tree+0xff/0x680&#xA;    vfs_get_tree+0x49/0x180&#xA;    do_new_mount+0x1a3/0x2d0&#xA;    path_mount+0x6dd/0x730&#xA;    do_mount+0x99/0xe0&#xA;    __do_sys_mount+0x141/0x180&#xA;    do_syscall_64+0x9f/0x100&#xA;    entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;    Freed by task 9475:&#xA;    kfree+0x212/0x290&#xA;    handle_one_map+0x23c/0x3b0&#xA;    ceph_osdc_handle_map+0x3c9/0x590&#xA;    mon_dispatch+0x655/0x6f0&#xA;    ceph_con_process_message+0xc3/0xe0&#xA;    ceph_con_v1_try_read+0x614/0x760&#xA;    ceph_con_workfn+0x2de/0x650&#xA;    process_one_work+0x486/0x7c0&#xA;    process_scheduled_works+0x73/0x90&#xA;    worker_thread+0x1c8/0x2a0&#xA;    kthread+0x2ec/0x300&#xA;    ret_from_fork+0x24/0x40&#xA;    ret_from_fork_asm+0x1a/0x30&#xA;&#xA;Rewrite the wait loop to check the above condition directly with&#xA;client-&gt;monc.mutex and client-&gt;osdc.lock taken as appropriate.  While&#xA;at it, improve the timeout handling (previously mount_timeout could be&#xA;exceeded in case wait_event_interruptible_timeout() slept more than&#xA;once) and access client-&gt;auth_err under client-&gt;monc.mutex to match&#xA;how it&#39;s set in finish_auth().&#xA;&#xA;monmap_show() and osdmap_show() now take the respective lock before&#xA;accessing the map as well.&#xA;CVE-2025-39913:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-&gt;cork.&#xA;&#xA;syzbot reported the splat below. [0]&#xA;&#xA;The repro does the following:&#xA;&#xA;  1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)&#xA;  2. Attach the prog to a SOCKMAP&#xA;  3. Add a socket to the SOCKMAP&#xA;  4. Activate fault injection&#xA;  5. Send data less than cork_bytes&#xA;&#xA;At 5., the data is carried over to the next sendmsg() as it is&#xA;smaller than the cork_bytes specified by bpf_msg_cork_bytes().&#xA;&#xA;Then, tcp_bpf_send_verdict() tries to allocate psock-&gt;cork to hold&#xA;the data, but this fails silently due to fault injection + __GFP_NOWARN.&#xA;&#xA;If the allocation fails, we need to revert the sk-&gt;sk_forward_alloc&#xA;change done by sk_msg_alloc().&#xA;&#xA;Let&#39;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate&#xA;psock-&gt;cork.&#xA;&#xA;The &#34;*copied&#34; also needs to be updated such that a proper error can&#xA;be returned to the caller, sendmsg. It fails to allocate psock-&gt;cork.&#xA;Nothing has been corked so far, so this patch simply sets &#34;*copied&#34;&#xA;to 0.&#xA;&#xA;[0]:&#xA;WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983&#xA;Modules linked in:&#xA;CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025&#xA;RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156&#xA;Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 &lt;0f&gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc&#xA;RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246&#xA;RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80&#xA;RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000&#xA;RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4&#xA;R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380&#xA;R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872&#xA;FS:  00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; __sk_destruct+0x86/0x660 net/core/sock.c:2339&#xA; rcu_do_batch kernel/rcu/tree.c:2605 [inline]&#xA; rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861&#xA; handle_softirqs+0x286/0x870 kernel/softirq.c:579&#xA; __do_softirq kernel/softirq.c:613 [inline]&#xA; invoke_softirq kernel/softirq.c:453 [inline]&#xA; __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680&#xA; irq_exit_rcu+0x9/0x30 kernel/softirq.c:696&#xA; instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]&#xA; sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052&#xA; &lt;/IRQ&gt;&#xA;CVE-2025-38718:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: linearize cloned gso packets in sctp_rcv&#xA;&#xA;A cloned head skb still shares these frag skbs in fraglist with the&#xA;original head skb. It&#39;s not safe to access these frag skbs.&#xA;&#xA;syzbot reported two use-of-uninitialized-memory bugs caused by this:&#xA;&#xA;  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211&#xA;   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211&#xA;   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998&#xA;   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88&#xA;   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331&#xA;   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122&#xA;   __release_sock+0x1da/0x330 net/core/sock.c:3106&#xA;   release_sock+0x6b/0x250 net/core/sock.c:3660&#xA;   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360&#xA;   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885&#xA;   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031&#xA;   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851&#xA;   sock_sendmsg_nosec net/socket.c:718 [inline]&#xA;&#xA;and&#xA;&#xA;  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987&#xA;   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987&#xA;   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88&#xA;   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331&#xA;   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148&#xA;   __release_sock+0x1d3/0x330 net/core/sock.c:3213&#xA;   release_sock+0x6b/0x270 net/core/sock.c:3767&#xA;   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367&#xA;   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886&#xA;   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032&#xA;   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851&#xA;   sock_sendmsg_nosec net/socket.c:712 [inline]&#xA;&#xA;This patch fixes it by linearizing cloned gso packets in sctp_rcv().&#xA;CVE-2025-39702:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: sr: Fix MAC comparison to be constant-time&#xA;&#xA;To prevent timing attacks, MACs need to be compared in constant time.&#xA;Use the appropriate helper function for this.&#xA;CVE-2025-39853:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: Fix potential invalid access when MAC list is empty&#xA;&#xA;list_first_entry() never returns NULL - if the list is empty, it still&#xA;returns a pointer to an invalid object, leading to potential invalid&#xA;memory access when dereferenced.&#xA;&#xA;Fix this by using list_first_entry_or_null instead of list_first_entry.&#xA;CVE-2025-39860:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()&#xA;&#xA;syzbot reported the splat below without a repro.&#xA;&#xA;In the splat, a single thread calling bt_accept_dequeue() freed sk&#xA;and touched it after that.&#xA;&#xA;The root cause would be the racy l2cap_sock_cleanup_listen() call&#xA;added by the cited commit.&#xA;&#xA;bt_accept_dequeue() is called under lock_sock() except for&#xA;l2cap_sock_release().&#xA;&#xA;Two threads could see the same socket during the list iteration&#xA;in bt_accept_dequeue():&#xA;&#xA;  CPU1                        CPU2 (close())&#xA;  ----                        ----&#xA;  sock_hold(sk)               sock_hold(sk);&#xA;  lock_sock(sk)   &lt;-- block close()&#xA;  sock_put(sk)&#xA;  bt_accept_unlink(sk)&#xA;    sock_put(sk)  &lt;-- refcnt by bt_accept_enqueue()&#xA;  release_sock(sk)&#xA;                              lock_sock(sk)&#xA;                              sock_put(sk)&#xA;                              bt_accept_unlink(sk)&#xA;                                sock_put(sk)        &lt;-- last refcnt&#xA;                              bt_accept_unlink(sk)  &lt;-- UAF&#xA;&#xA;Depending on the timing, the other thread could show up in the&#xA;&#34;Freed by task&#34; part.&#xA;&#xA;Let&#39;s call l2cap_sock_cleanup_listen() under lock_sock() in&#xA;l2cap_sock_release().&#xA;&#xA;[0]:&#xA;BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]&#xA;BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115&#xA;Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995&#xA;CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:378 [inline]&#xA; print_report+0xcd/0x630 mm/kasan/report.c:482&#xA; kasan_report+0xe0/0x110 mm/kasan/report.c:595&#xA; debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]&#xA; do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115&#xA; spin_lock_bh include/linux/spinlock.h:356 [inline]&#xA; release_sock+0x21/0x220 net/core/sock.c:3746&#xA; bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312&#xA; l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451&#xA; l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425&#xA; __sock_release+0xb3/0x270 net/socket.c:649&#xA; sock_close+0x1c/0x30 net/socket.c:1439&#xA; __fput+0x3ff/0xb70 fs/file_table.c:468&#xA; task_work_run+0x14d/0x240 kernel/task_work.c:227&#xA; resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]&#xA; exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43&#xA; exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]&#xA; syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]&#xA; syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]&#xA; do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f2accf8ebe9&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4&#xA;RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9&#xA;RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003&#xA;RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f&#xA;R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c&#xA;R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 5326:&#xA; kasan_save_stack+0x33/0x60 mm/kasan/common.c:47&#xA; kasan_save_track+0x14/0x30 mm/kasan/common.c:68&#xA; poison_kmalloc_redzone mm/kasan/common.c:388 [inline]&#xA; __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405&#xA; kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA; __do_kmalloc_node mm/slub.c:4365 [inline]&#xA; __kmalloc_nopro&#xA;---truncated---&#xA;CVE-2025-39957:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mac80211: increase scan_ies_len for S1G&#xA;&#xA;Currently the S1G capability element is not taken into account&#xA;for the scan_ies_len, which leads to a buffer length validation&#xA;failure in ieee80211_prep_hw_scan() and subsequent WARN in&#xA;__ieee80211_start_scan(). This prevents hw scanning from functioning.&#xA;To fix ensure we accommodate for the S1G capability length.&#xA;CVE-2023-53712:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ARM: 9317/1: kexec: Make smp stop calls asynchronous&#xA;&#xA;If a panic is triggered by a hrtimer interrupt all online cpus will be&#xA;notified and set offline. But as highlighted by commit 19dbdcb8039c&#xA;(&#34;smp: Warn on function calls from softirq context&#34;) this call should&#xA;not be made synchronous with disabled interrupts:&#xA;&#xA; softdog: Initiating panic&#xA; Kernel panic - not syncing: Software Watchdog Timer expired&#xA; WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond&#xA;   unwind_backtrace:&#xA;     show_stack&#xA;     dump_stack_lvl&#xA;     __warn&#xA;     warn_slowpath_fmt&#xA;     smp_call_function_many_cond&#xA;     smp_call_function&#xA;     crash_smp_send_stop.part.0&#xA;     machine_crash_shutdown&#xA;     __crash_kexec&#xA;     panic&#xA;     softdog_fire&#xA;     __hrtimer_run_queues&#xA;     hrtimer_interrupt&#xA;&#xA;Make the smp call for machine_crash_nonpanic_core() asynchronous.&#xA;CVE-2026-23085:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;irqchip/gic-v3-its: Avoid truncating memory addresses&#xA;&#xA;On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem&#xA;allocations to be backed by addresses physical memory above the 32-bit&#xA;address limit, as found while experimenting with larger VMSPLIT&#xA;configurations.&#xA;&#xA;This caused the qemu virt model to crash in the GICv3 driver, which&#xA;allocates the &#39;itt&#39; object using GFP_KERNEL. Since all memory below&#xA;the 4GB physical address limit is in ZONE_DMA in this configuration,&#xA;kmalloc() defaults to higher addresses for ZONE_NORMAL, and the&#xA;ITS driver stores the physical address in a 32-bit &#39;unsigned long&#39;&#xA;variable.&#xA;&#xA;Change the itt_addr variable to the correct phys_addr_t type instead,&#xA;along with all other variables in this driver that hold a physical&#xA;address.&#xA;&#xA;The gicv5 driver correctly uses u64 variables, while all other irqchip&#xA;drivers don&#39;t call virt_to_phys or similar interfaces. It&#39;s expected that&#xA;other device drivers have similar issues, but fixing this one is&#xA;sufficient for booting a virtio based guest.&#xA;CVE-2026-23107:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA&#xA;&#xA;The code to restore a ZA context doesn&#39;t attempt to allocate the task&#39;s&#xA;sve_state before setting TIF_SME. Consequently, restoring a ZA context&#xA;can place a task into an invalid state where TIF_SME is set but the&#xA;task&#39;s sve_state is NULL.&#xA;&#xA;In legitimate but uncommon cases where the ZA signal context was NOT&#xA;created by the kernel in the context of the same task (e.g. if the task&#xA;is saved/restored with something like CRIU), we have no guarantee that&#xA;sve_state had been allocated previously. In these cases, userspace can&#xA;enter streaming mode without trapping while sve_state is NULL, causing a&#xA;later NULL pointer dereference when the kernel attempts to store the&#xA;register state:&#xA;&#xA;| # ./sigreturn-za&#xA;| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000&#xA;| Mem abort info:&#xA;|   ESR = 0x0000000096000046&#xA;|   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;|   SET = 0, FnV = 0&#xA;|   EA = 0, S1PTW = 0&#xA;|   FSC = 0x06: level 2 translation fault&#xA;| Data abort info:&#xA;|   ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000&#xA;|   CM = 0, WnR = 1, TnD = 0, TagAccess = 0&#xA;|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00&#xA;| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000&#xA;| Internal error: Oops: 0000000096000046 [#1]  SMP&#xA;| Modules linked in:&#xA;| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT&#xA;| Hardware name: linux,dummy-virt (DT)&#xA;| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)&#xA;| pc : sve_save_state+0x4/0xf0&#xA;| lr : fpsimd_save_user_state+0xb0/0x1c0&#xA;| sp : ffff80008070bcc0&#xA;| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658&#xA;| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000&#xA;| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40&#xA;| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000&#xA;| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c&#xA;| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020&#xA;| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0&#xA;| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48&#xA;| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000&#xA;| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440&#xA;| Call trace:&#xA;|  sve_save_state+0x4/0xf0 (P)&#xA;|  fpsimd_thread_switch+0x48/0x198&#xA;|  __switch_to+0x20/0x1c0&#xA;|  __schedule+0x36c/0xce0&#xA;|  schedule+0x34/0x11c&#xA;|  exit_to_user_mode_loop+0x124/0x188&#xA;|  el0_interrupt+0xc8/0xd8&#xA;|  __el0_irq_handler_common+0x18/0x24&#xA;|  el0t_64_irq_handler+0x10/0x1c&#xA;|  el0t_64_irq+0x198/0x19c&#xA;| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)&#xA;| ---[ end trace 0000000000000000 ]---&#xA;&#xA;Fix this by having restore_za_context() ensure that the task&#39;s sve_state&#xA;is allocated, matching what we do when taking an SME trap. Any live&#xA;SVE/SSVE state (which is restored earlier from a separate signal&#xA;context) must be preserved, and hence this is not zeroed.&#xA;CVE-2026-22990:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: replace overzealous BUG_ON in osdmap_apply_incremental()&#xA;&#xA;If the osdmap is (maliciously) corrupted such that the incremental&#xA;osdmap epoch is different from what is expected, there is no need to&#xA;BUG.  Instead, just declare the incremental osdmap to be invalid.&#xA;CVE-2026-23050:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pNFS: Fix a deadlock when returning a delegation during open()&#xA;&#xA;Ben Coddington reports seeing a hang in the following stack trace:&#xA;  0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415&#xA;  1 [ffffd0b50e177548] schedule at ffffffff9ca05717&#xA;  2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1&#xA;  3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb&#xA;  4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5&#xA;  5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]&#xA;  6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]&#xA;  7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]&#xA;  8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]&#xA;  9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]&#xA; 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]&#xA; 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]&#xA; 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]&#xA; 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]&#xA; 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]&#xA; 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]&#xA; 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]&#xA; 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea&#xA; 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e&#xA; 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935&#xA;&#xA;The issue is that the delegreturn is being asked to wait for a layout&#xA;return that cannot complete because a state recovery was initiated. The&#xA;state recovery cannot complete until the open() finishes processing the&#xA;delegations it was given.&#xA;&#xA;The solution is to propagate the existing flags that indicate a&#xA;non-blocking call to the function pnfs_roc(), so that it knows not to&#xA;wait in this situation.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="kernel" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/kernel-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="302.0.0.205.u192" version="5.10.0">
					<filename>perf-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/perf-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-headers-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/kernel-headers-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-tools-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/kernel-tools-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-devel-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/kernel-devel-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/kernel-tools-devel-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="302.0.0.205.u192" version="5.10.0">
					<filename>bpftool-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/bpftool-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="302.0.0.205.u192" version="5.10.0">
					<filename>python3-perf-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-perf-5.10.0-302.0.0.205.u192.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/kernel-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="302.0.0.205.u192" version="5.10.0">
					<filename>python3-perf-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-perf-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-devel-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/kernel-devel-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/kernel-tools-devel-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="302.0.0.205.u192" version="5.10.0">
					<filename>perf-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/perf-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-headers-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/kernel-headers-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="302.0.0.205.u192" version="5.10.0">
					<filename>kernel-tools-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/kernel-tools-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="302.0.0.205.u192" version="5.10.0">
					<filename>bpftool-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/bpftool-5.10.0-302.0.0.205.u192.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3076</id>
		<title>An update for tinyxml2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50614&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50614" id="CVE-2024-50614" title="CVE-2024-50614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50615&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50615" id="CVE-2024-50615" title="CVE-2024-50615" type="cve"></reference>
		</references>
		<description>CVE-2024-50614:TinyXML2 through 10.0.0 has a reachable assertion for UINT_MAX/16, that may lead to application exit, in tinyxml2.cpp XMLUtil::GetCharacterRef.&#xA;CVE-2024-50615:TinyXML2 through 10.0.0 has a reachable assertion for UINT_MAX/digit, that may lead to application exit, in tinyxml2.cpp XMLUtil::GetCharacterRef.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="tinyxml2" release="6.u1" version="6.0.0">
					<filename>tinyxml2-6.0.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/tinyxml2-6.0.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tinyxml2-devel" release="6.u1" version="6.0.0">
					<filename>tinyxml2-devel-6.0.0-6.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/tinyxml2-devel-6.0.0-6.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tinyxml2" release="6.u1" version="6.0.0">
					<filename>tinyxml2-6.0.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/tinyxml2-6.0.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tinyxml2-devel" release="6.u1" version="6.0.0">
					<filename>tinyxml2-devel-6.0.0-6.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/tinyxml2-devel-6.0.0-6.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3077</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5166&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5166" id="CVE-2025-5166" title="CVE-2025-5166" type="cve"></reference>
		</references>
		<description>CVE-2025-5166:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been classified as problematic. Affected is the function MDCImporter::InternReadFile of the file assimp/code/AssetLib/MDC/MDCLoader.cpp of the component MDC File Parser. The manipulation of the argument pcVerts leads to out-of-bounds read. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="assimp-help" release="9.u7" version="5.2.4">
					<filename>assimp-help-5.2.4-9.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/assimp-help-5.2.4-9.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-assimp" release="9.u7" version="5.2.4">
					<filename>python3-assimp-5.2.4-9.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-assimp-5.2.4-9.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp" release="9.u7" version="5.2.4">
					<filename>assimp-5.2.4-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/assimp-5.2.4-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="9.u7" version="5.2.4">
					<filename>assimp-devel-5.2.4-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/assimp-devel-5.2.4-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="9.u7" version="5.2.4">
					<filename>assimp-devel-5.2.4-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/assimp-devel-5.2.4-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp" release="9.u7" version="5.2.4">
					<filename>assimp-5.2.4-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/assimp-5.2.4-9.u7.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3078</id>
		<title>An update for libpng is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22695&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22695" id="CVE-2026-22695" title="CVE-2026-22695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22801&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22801" id="CVE-2026-22801" title="CVE-2026-22801" type="cve"></reference>
		</references>
		<description>CVE-2026-22695:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function png_image_finish_read when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.&#xA;CVE-2026-22801:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="2" name="libpng-static" release="5.u4" version="1.6.38">
					<filename>libpng-static-1.6.38-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libpng-static-1.6.38-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng-tools" release="5.u4" version="1.6.38">
					<filename>libpng-tools-1.6.38-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libpng-tools-1.6.38-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng-help" release="5.u4" version="1.6.38">
					<filename>libpng-help-1.6.38-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libpng-help-1.6.38-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng-devel" release="5.u4" version="1.6.38">
					<filename>libpng-devel-1.6.38-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libpng-devel-1.6.38-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libpng" release="5.u4" version="1.6.38">
					<filename>libpng-1.6.38-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libpng-1.6.38-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-devel" release="5.u4" version="1.6.38">
					<filename>libpng-devel-1.6.38-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libpng-devel-1.6.38-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-help" release="5.u4" version="1.6.38">
					<filename>libpng-help-1.6.38-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libpng-help-1.6.38-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-tools" release="5.u4" version="1.6.38">
					<filename>libpng-tools-1.6.38-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libpng-tools-1.6.38-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng" release="5.u4" version="1.6.38">
					<filename>libpng-1.6.38-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libpng-1.6.38-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libpng-static" release="5.u4" version="1.6.38">
					<filename>libpng-static-1.6.38-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libpng-static-1.6.38-5.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3079</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61915&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61915" id="CVE-2025-61915" title="CVE-2025-61915" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58436&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58436" id="CVE-2025-58436" title="CVE-2025-58436" type="cve"></reference>
		</references>
		<description>CVE-2025-61915:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.&#xA;CVE-2025-58436:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a client that connects to cupsd but sends slow messages, e.g. only one byte per second, delays cupsd as a whole, such that it becomes unusable by other clients. This issue has been patched in version 2.4.15.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="1" name="cups-help" release="18.u10" version="2.4.0">
					<filename>cups-help-2.4.0-18.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-help-2.4.0-18.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="18.u10" version="2.4.0">
					<filename>cups-filesystem-2.4.0-18.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-filesystem-2.4.0-18.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="18.u10" version="2.4.0">
					<filename>cups-devel-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-devel-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="18.u10" version="2.4.0">
					<filename>cups-lpd-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-lpd-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="18.u10" version="2.4.0">
					<filename>cups-ipptool-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-ipptool-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="18.u10" version="2.4.0">
					<filename>cups-libs-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-libs-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="18.u10" version="2.4.0">
					<filename>cups-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="18.u10" version="2.4.0">
					<filename>cups-client-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-client-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="18.u10" version="2.4.0">
					<filename>cups-printerapp-2.4.0-18.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-printerapp-2.4.0-18.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups" release="18.u10" version="2.4.0">
					<filename>cups-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="18.u10" version="2.4.0">
					<filename>cups-client-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-client-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="18.u10" version="2.4.0">
					<filename>cups-devel-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-devel-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="18.u10" version="2.4.0">
					<filename>cups-ipptool-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-ipptool-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="18.u10" version="2.4.0">
					<filename>cups-libs-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-libs-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="18.u10" version="2.4.0">
					<filename>cups-lpd-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-lpd-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="18.u10" version="2.4.0">
					<filename>cups-printerapp-2.4.0-18.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-printerapp-2.4.0-18.u10.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3080</id>
		<title>An update for avahi is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68276&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68276" id="CVE-2025-68276" title="CVE-2025-68276" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68468&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68468" id="CVE-2025-68468" title="CVE-2025-68468" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68471&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68471" id="CVE-2025-68471" title="CVE-2025-68471" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24401&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24401" id="CVE-2026-24401" title="CVE-2026-24401" type="cve"></reference>
		</references>
		<description>CVE-2025-68276:Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either calling&#xA;the RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.&#xA;CVE-2025-68468:Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.&#xA;CVE-2025-68471:Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.&#xA;CVE-2026-24401:Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., &#34;h.local&#34; as a CNAME for &#34;h.local&#34;). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd" release="26.u9" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-compat-libdns_sd-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-devel" release="26.u9" version="0.8">
					<filename>avahi-devel-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-devel-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-dnsconfd" release="26.u9" version="0.8">
					<filename>avahi-dnsconfd-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-dnsconfd-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-libdns_sd-devel" release="26.u9" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-compat-libdns_sd-devel-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib-devel" release="26.u9" version="0.8">
					<filename>avahi-glib-devel-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-glib-devel-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-libs" release="26.u9" version="0.8">
					<filename>avahi-libs-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-libs-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-gtk3" release="26.u9" version="0.8">
					<filename>avahi-ui-gtk3-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-ui-gtk3-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject-devel" release="26.u9" version="0.8">
					<filename>avahi-gobject-devel-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-gobject-devel-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui" release="26.u9" version="0.8">
					<filename>avahi-ui-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-ui-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-autoipd" release="26.u9" version="0.8">
					<filename>avahi-autoipd-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-autoipd-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-gobject" release="26.u9" version="0.8">
					<filename>avahi-gobject-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-gobject-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi" release="26.u9" version="0.8">
					<filename>avahi-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl" release="26.u9" version="0.8">
					<filename>avahi-compat-howl-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-compat-howl-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-tools" release="26.u9" version="0.8">
					<filename>avahi-tools-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-tools-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-devel" release="26.u9" version="0.8">
					<filename>avahi-ui-devel-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-ui-devel-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-compat-howl-devel" release="26.u9" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-compat-howl-devel-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-glib" release="26.u9" version="0.8">
					<filename>avahi-glib-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-glib-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="avahi-ui-tools" release="26.u9" version="0.8">
					<filename>avahi-ui-tools-0.8-26.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/avahi-ui-tools-0.8-26.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib-devel" release="26.u9" version="0.8">
					<filename>avahi-glib-devel-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-glib-devel-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-tools" release="26.u9" version="0.8">
					<filename>avahi-ui-tools-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-ui-tools-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject" release="26.u9" version="0.8">
					<filename>avahi-gobject-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-gobject-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-devel" release="26.u9" version="0.8">
					<filename>avahi-ui-devel-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-ui-devel-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd-devel" release="26.u9" version="0.8">
					<filename>avahi-compat-libdns_sd-devel-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-compat-libdns_sd-devel-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-devel" release="26.u9" version="0.8">
					<filename>avahi-devel-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-devel-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-libdns_sd" release="26.u9" version="0.8">
					<filename>avahi-compat-libdns_sd-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-compat-libdns_sd-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-autoipd" release="26.u9" version="0.8">
					<filename>avahi-autoipd-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-autoipd-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-dnsconfd" release="26.u9" version="0.8">
					<filename>avahi-dnsconfd-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-dnsconfd-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-gobject-devel" release="26.u9" version="0.8">
					<filename>avahi-gobject-devel-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-gobject-devel-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-tools" release="26.u9" version="0.8">
					<filename>avahi-tools-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-tools-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl-devel" release="26.u9" version="0.8">
					<filename>avahi-compat-howl-devel-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-compat-howl-devel-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi" release="26.u9" version="0.8">
					<filename>avahi-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-libs" release="26.u9" version="0.8">
					<filename>avahi-libs-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-libs-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui" release="26.u9" version="0.8">
					<filename>avahi-ui-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-ui-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-ui-gtk3" release="26.u9" version="0.8">
					<filename>avahi-ui-gtk3-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-ui-gtk3-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-compat-howl" release="26.u9" version="0.8">
					<filename>avahi-compat-howl-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-compat-howl-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="avahi-glib" release="26.u9" version="0.8">
					<filename>avahi-glib-0.8-26.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-glib-0.8-26.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="avahi-help" release="26.u9" version="0.8">
					<filename>avahi-help-0.8-26.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/avahi-help-0.8-26.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3081</id>
		<title>An update for etcd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47912" id="CVE-2025-47912" title="CVE-2025-47912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58188&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58188" id="CVE-2025-58188" title="CVE-2025-58188" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61723" id="CVE-2025-61723" title="CVE-2025-61723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58189&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58189" id="CVE-2025-58189" title="CVE-2025-58189" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58185&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58185" id="CVE-2025-58185" title="CVE-2025-58185" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24791&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24791" id="CVE-2024-24791" title="CVE-2024-24791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58186&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58186" id="CVE-2025-58186" title="CVE-2025-58186" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61729" id="CVE-2025-61729" title="CVE-2025-61729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61727" id="CVE-2025-61727" title="CVE-2025-61727" type="cve"></reference>
		</references>
		<description>CVE-2025-47912:The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: &#34;http://[::1]/&#34;. IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.&#xA;CVE-2025-58188:Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains.&#xA;CVE-2025-61723:The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs.&#xA;CVE-2025-58189:When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.&#xA;CVE-2025-58185:Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.&#xA;CVE-2024-24791:The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an &#34;Expect: 100-continue&#34; header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail. An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending &#34;Expect: 100-continue&#34; requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.&#xA;CVE-2025-58186:Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as &#34;a=;&#34;, an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.&#xA;CVE-2025-61729:Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.&#xA;CVE-2025-61727:An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="etcd" release="12.u4" version="3.4.14">
					<filename>etcd-3.4.14-12.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/etcd-3.4.14-12.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="etcd" release="12.u4" version="3.4.14">
					<filename>etcd-3.4.14-12.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/etcd-3.4.14-12.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3082</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68950&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68950" id="CVE-2025-68950" title="CVE-2025-68950" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68618&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68618" id="CVE-2025-68618" title="CVE-2025-68618" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69204" id="CVE-2025-69204" title="CVE-2025-69204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22770&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22770" id="CVE-2026-22770" title="CVE-2026-22770" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23876&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23876" id="CVE-2026-23876" title="CVE-2026-23876" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23874&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23874" id="CVE-2026-23874" title="CVE-2026-23874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23952&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23952" id="CVE-2026-23952" title="CVE-2026-23952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27799&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27799" id="CVE-2026-27799" title="CVE-2026-27799" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27798" id="CVE-2026-27798" title="CVE-2026-27798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26284&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26284" id="CVE-2026-26284" title="CVE-2026-26284" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25970&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25970" id="CVE-2026-25970" title="CVE-2026-25970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25971&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25971" id="CVE-2026-25971" title="CVE-2026-25971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25982&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25982" id="CVE-2026-25982" title="CVE-2026-25982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25576&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25576" id="CVE-2026-25576" title="CVE-2026-25576" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25983&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25983" id="CVE-2026-25983" title="CVE-2026-25983" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24481&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24481" id="CVE-2026-24481" title="CVE-2026-24481" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24484&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24484" id="CVE-2026-24484" title="CVE-2026-24484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24485&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24485" id="CVE-2026-24485" title="CVE-2026-24485" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25969&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25969" id="CVE-2026-25969" title="CVE-2026-25969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25638&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25638" id="CVE-2026-25638" title="CVE-2026-25638" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25988&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25988" id="CVE-2026-25988" title="CVE-2026-25988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25967&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25967" id="CVE-2026-25967" title="CVE-2026-25967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25798&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25798" id="CVE-2026-25798" title="CVE-2026-25798" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25966&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25966" id="CVE-2026-25966" title="CVE-2026-25966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25987&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25987" id="CVE-2026-25987" title="CVE-2026-25987" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25794&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25794" id="CVE-2026-25794" title="CVE-2026-25794" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25965&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25965" id="CVE-2026-25965" title="CVE-2026-25965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25795" id="CVE-2026-25795" title="CVE-2026-25795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26983&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26983" id="CVE-2026-26983" title="CVE-2026-26983" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25898&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25898" id="CVE-2026-25898" title="CVE-2026-25898" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25968&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25968" id="CVE-2026-25968" title="CVE-2026-25968" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26283&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26283" id="CVE-2026-26283" title="CVE-2026-26283" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25989&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25989" id="CVE-2026-25989" title="CVE-2026-25989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25799&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25799" id="CVE-2026-25799" title="CVE-2026-25799" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26066&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26066" id="CVE-2026-26066" title="CVE-2026-26066" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25986&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25986" id="CVE-2026-25986" title="CVE-2026-25986" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25637&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25637" id="CVE-2026-25637" title="CVE-2026-25637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25796&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25796" id="CVE-2026-25796" title="CVE-2026-25796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25797&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25797" id="CVE-2026-25797" title="CVE-2026-25797" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25985&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25985" id="CVE-2026-25985" title="CVE-2026-25985" type="cve"></reference>
		</references>
		<description>CVE-2025-68950:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-12, Magick fails to check for circular references between two MVGs, leading to a stack overflow. This is a DoS vulnerability, and any situation that allows reading the mvg file will be affected. Version 7.1.2-12 fixes the issue.&#xA;CVE-2025-68618:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-12, using Magick to read a malicious SVG file resulted in a DoS attack. Version 7.1.2-12 fixes the issue.&#xA;CVE-2025-69204:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-12, in the WriteSVGImage function, using an int variable to store number_attributes caused an integer overflow. This, in turn, triggered a buffer overflow and caused a DoS attack. Version 7.1.2-12 fixes the issue.&#xA;CVE-2026-22770:ImageMagick is free and open-source software used for editing and manipulating digital images. The BilateralBlurImage method will allocate a set of double buffers inside AcquireBilateralTLS. But, in versions prior to 7.1.2-13, the last element in the set is not properly initialized. This will result in a release of an invalid pointer inside DestroyBilateralTLS when the memory allocation fails. Version 7.1.2-13 contains a patch for the issue.&#xA;CVE-2026-23876:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-13 and 6.9.13-38, a heap buffer overflow vulnerability in the XBM image decoder (ReadXBMImage) allows an attacker to write controlled data past the allocated heap buffer when processing a maliciously crafted image file. Any operation that reads or identifies an image can trigger the overflow, making it exploitable via common image upload and processing pipelines. Versions 7.1.2-13 and 6.9.13-38 fix the issue.&#xA;CVE-2026-23874:ImageMagick is free and open-source software used for editing and manipulating digital images. Versions prior to 7.1.2-13 have a stack overflow via infinite recursion in MSL (Magick Scripting Language) `&lt;write&gt;` command when writing to MSL format. Version 7.1.2-13 fixes the issue.&#xA;CVE-2026-23952:ImageMagick is free and open-source software used for editing and manipulating digital images. Versions 14.10.1 and below have a NULL pointer dereference vulnerability in the MSL (Magick Scripting Language) parser when processing &lt;comment&gt; tags before images are loaded. This can lead to DoS attack due to assertion failure (debug builds) or NULL pointer dereference (release builds). This issue is fixed in version 14.10.2.&#xA;CVE-2026-27799:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap buffer over-read vulnerability exists in the DJVU image format handler. The vulnerability occurs due to integer truncation when calculating the stride (row size) for pixel buffer allocation. The stride calculation overflows a 32-bit signed integer, resulting in an out-of-bounds memory reads. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-27798:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap buffer over-read vulnerability occurs when processing an image with small dimension using the `-wavelet-denoise` operator. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-26284:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, ImageMagick lacks proper boundary checking when processing Huffman-coded data from PCD (Photo CD) files. The decoder contains an function that has an incorrect initialization that could cause an out of bounds read. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25970:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a signed integer overflow vulnerability in ImageMagick&#39;s SIXEL decoder allows an attacker to trigger memory corruption and denial of service when processing a maliciously crafted SIXEL image file. The vulnerability occurs during buffer reallocation operations where pointer arithmetic using signed 32-bit integers overflows. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25971:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, Magick fails to check for circular references between two MSLs, leading to a stack overflow. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25982:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap out-of-bounds read vulnerability exists in the `coders/dcm.c` module. When processing DICOM files with a specific configuration, the decoder loop incorrectly reads bytes per iteration. This causes the function to read past the end of the allocated buffer, potentially leading to a Denial of Service (crash) or Information Disclosure (leaking heap memory into the image). Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25576:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap buffer over-read vulnerability exists in multiple raw image format handles. The vulnerability occurs when processing images with -extract dimensions larger than -size dimensions, causing out-of-bounds memory reads from a heap-allocated buffer. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25983:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a crafted MSL script triggers a heap-use-after-free. The operation element handler replaces and frees the image while the parser continues reading from it, leading to a UAF in ReadBlobString during further parsing. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-24481:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap information disclosure vulnerability exists in ImageMagick&#39;s PSD (Adobe Photoshop) format handler. When processing a maliciously crafted PSD file containing ZIP-compressed layer data that decompresses to less than the expected size, uninitialized heap memory is leaked into the output image. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-24484:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, Magick fails to check for multi-layer nested mvg conversions to svg, leading to DoS. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-24485:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, when a PCD file does not contain a valid Sync marker, the DecodeImage() function becomes trapped in an infinite loop while searching for the Sync marker, causing the program to become unresponsive and continuously consume CPU resources, ultimately leading to system resource exhaustion and denial of service. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25969:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-15, a memory leak exists in `coders/ashlar.c`. The `WriteASHLARImage` allocates a structure.  However, when an exception is thrown, the allocated memory is not properly released, resulting in a potential memory leak. Version 7.1.2-15 contains a patch.&#xA;CVE-2026-25638:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, memory leak exists in `coders/msl.c`. In the `WriteMSLImage` function of the `msl.c` file, resources are allocated. But the function returns early without releasing these allocated resources. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25988:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, sometimes msl.c fails to update the stack index, so an image is stored in the wrong slot and never freed on error, causing leaks. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25967:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-15, a stack-based buffer overflow exists in the ImageMagick FTXT image reader. A crafted FTXT file can cause out-of-bounds writes on the stack, leading to a crash. Version 7.1.2-15 contains a patch.&#xA;CVE-2026-25798:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a NULL pointer dereference in ClonePixelCacheRepository allows a remote attacker to crash any application linked against ImageMagick by supplying a crafted image file, resulting in denial of service. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25966:ImageMagick is free and open-source software used for editing and manipulating digital images. The shipped &#34;secure&#34; security policy includes a rule intended to prevent reading/writing from standard streams. However, ImageMagick also supports fd:&lt;n&gt; pseudo-filenames (e.g., fd:0, fd:1). Prior to versions 7.1.2-15 and 6.9.13-40, this path form is not blocked by the secure policy templates, and therefore bypasses the protection goal of &#34;no stdin/stdout.&#34; Versions 7.1.2-15 and 6.9.13-40 contain a patch by including a change to the more secure policies by default. As a workaround, add the change to one&#39;s security policy manually.&#xA;CVE-2026-25987:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap buffer over-read vulnerability exists in the MAP image decoder when processing crafted MAP files, potentially leading to crashes or unintended memory disclosure during image decoding. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25794:ImageMagick is free and open-source software used for editing and manipulating digital images. `WriteUHDRImage` in `coders/uhdr.c` uses `int` arithmetic to compute the pixel buffer size. Prior to version 7.1.2-15, when image dimensions are large, the multiplication overflows 32-bit `int`, causing an undersized heap allocation followed by an out-of-bounds write. This can crash the process or potentially lead to an out of bounds heap write. Version 7.1.2-15 contains a patch.&#xA;CVE-2026-25965:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, ImageMagick’s path security policy is enforced on the raw filename string before the filesystem resolves it. As a result, a policy rule such as /etc/* can be bypassed by a path traversal. The OS resolves the traversal and opens the sensitive file, but the policy matcher only sees the unnormalized path and therefore allows the read. This enables local file disclosure (LFI) even when policy-secure.xml is applied. Actions to prevent reading from files have been taken in versions .7.1.2-15 and 6.9.13-40 But it make sure writing is also not possible the following should be added to one&#39;s policy. This will also be included in ImageMagick&#39;s more secure policies by default.&#xA;CVE-2026-25795:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, in `ReadSFWImage()` (`coders/sfw.c`), when temporary file creation fails, `read_info` is destroyed before its `filename` member is accessed, causing a NULL pointer dereference and crash. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-26983:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, the MSL interpreter crashes when processing a invalid `&lt;map&gt;` element that causes it to use an image after it has been freed. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25898:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, the UIL and XPM image encoder do not validate the pixel index value returned by `GetPixelIndex()` before using it as an array subscript. In HDRI builds, `Quantum` is a floating-point type, so pixel index values can be negative. An attacker can craft an image with negative pixel index values to trigger a global buffer overflow read during conversion, leading to information disclosure or a process crash. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25968:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a stack buffer overflow occurs when processing the an attribute in msl.c. A long value overflows a fixed-size stack buffer, leading to memory corruption. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-26283:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a `continue` statement in the JPEG extent binary search loop in the jpeg encoder causes an infinite loop when writing persistently fails. An attacker can trigger a 100% CPU consumption and process hang (Denial of Service) with a crafted image. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25989:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a crafted SVG file can cause a denial of service. An off-by-one boundary check (`&gt;` instead of `&gt;=`) that allows bypass the guard and reach an undefined `(size_t)` cast. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25799:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a logic error in YUV sampling factor validation allows an invalid sampling factor to bypass checks and trigger a division-by-zero during image loading, resulting in a reliable denial-of-service. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-26066:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a crafted profile contain invalid IPTC data may cause an infinite loop when writing it with `IPTCTEXT`. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25986:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a heap buffer overflow write vulnerability exists in ReadYUVImage() (coders/yuv.c) when processing malicious YUV 4:2:2 (NoInterlace) images. The pixel-pair loop writes one pixel beyond the allocated row buffer. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25637:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-15, a memory leak in the ASHLAR image writer allows an attacker to exhaust process memory by providing a crafted image that results in small objects that are allocated but never freed. Version 7.1.2-15 contains a patch.&#xA;CVE-2026-25796:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, in `ReadSTEGANOImage()` (`coders/stegano.c`), the `watermark` Image object is not freed on three early-return paths, resulting in a definite memory leak (~13.5KB+ per invocation) that can be exploited for denial of service. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25797:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, the ps coders, responsible for writing PostScript files, fails to sanitize the input before writing it into the PostScript header.  An attacker can provide a malicous file and inject arbitrary PostScript code. When the resulting file is processed by a printer or a viewer (like Ghostscript), the injected code is interpreted and executed. The html encoder does not properly escape strings that are written to in the html document. An attacker can provide a malicious file and injection arbitrary html code. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;CVE-2026-25985:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a crafted SVG file containing an malicious element causes ImageMagick to attempt to allocate ~674 GB of memory, leading to an out-of-memory abort. Versions 7.1.2-15 and 6.9.13-40 contain a patch.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-c++-devel-7.1.2.15-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ImageMagick-c++-devel-7.1.2.15-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-c++-7.1.2.15-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ImageMagick-c++-7.1.2.15-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-devel-7.1.2.15-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ImageMagick-devel-7.1.2.15-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-7.1.2.15-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ImageMagick-7.1.2.15-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-perl-7.1.2.15-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ImageMagick-perl-7.1.2.15-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-devel-7.1.2.15-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ImageMagick-devel-7.1.2.15-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-7.1.2.15-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ImageMagick-7.1.2.15-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-c++-7.1.2.15-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ImageMagick-c++-7.1.2.15-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-c++-devel-7.1.2.15-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ImageMagick-c++-devel-7.1.2.15-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-perl-7.1.2.15-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ImageMagick-perl-7.1.2.15-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="ImageMagick-help" release="1.u10" version="7.1.2.15">
					<filename>ImageMagick-help-7.1.2.15-1.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ImageMagick-help-7.1.2.15-1.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3083</id>
		<title>An update for python-ply is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-56005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-56005" id="CVE-2025-56005" title="CVE-2025-56005" type="cve"></reference>
		</references>
		<description>CVE-2025-56005:An undocumented and unsafe feature in the PLY (Python Lex-Yacc) library 3.11 allows Remote Code Execution (RCE) via the `picklefile` parameter in the `yacc()` function. This parameter accepts a `.pkl` file that is deserialized with `pickle.load()` without validation. Because `pickle` allows execution of embedded code via `__reduce__()`, an attacker can achieve code execution by passing a malicious pickle file. The parameter is not mentioned in official documentation or the GitHub repository, yet it is active in the PyPI version. This introduces a stealthy backdoor and persistence risk. NOTE: A third-party states that this vulnerability should be rejected because the proof of concept does not demonstrate arbitrary code execution and fails to complete successfully.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="python3-ply" release="4.u1" version="3.11">
					<filename>python3-ply-3.11-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-ply-3.11-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-ply-help" release="4.u1" version="3.11">
					<filename>python-ply-help-3.11-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python-ply-help-3.11-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3084</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0988&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0988" id="CVE-2026-0988" title="CVE-2026-0988" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-1484&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-1484" id="CVE-2026-1484" title="CVE-2026-1484" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-1485&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-1485" id="CVE-2026-1485" title="CVE-2026-1485" type="cve"></reference>
		</references>
		<description>CVE-2026-0988:A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).&#xA;CVE-2026-1484:A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.&#xA;CVE-2026-1485:A flaw was found in Glib&#39;s content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="glib2" release="25.u20" version="2.72.2">
					<filename>glib2-2.72.2-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glib2-2.72.2-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-devel" release="25.u20" version="2.72.2">
					<filename>glib2-devel-2.72.2-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glib2-devel-2.72.2-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-tests" release="25.u20" version="2.72.2">
					<filename>glib2-tests-2.72.2-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glib2-tests-2.72.2-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib2-static" release="25.u20" version="2.72.2">
					<filename>glib2-static-2.72.2-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/glib2-static-2.72.2-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glib2-help" release="25.u20" version="2.72.2">
					<filename>glib2-help-2.72.2-25.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glib2-help-2.72.2-25.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-devel" release="25.u20" version="2.72.2">
					<filename>glib2-devel-2.72.2-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glib2-devel-2.72.2-25.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2" release="25.u20" version="2.72.2">
					<filename>glib2-2.72.2-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glib2-2.72.2-25.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-tests" release="25.u20" version="2.72.2">
					<filename>glib2-tests-2.72.2-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glib2-tests-2.72.2-25.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib2-static" release="25.u20" version="2.72.2">
					<filename>glib2-static-2.72.2-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/glib2-static-2.72.2-25.u20.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3085</id>
		<title>An update for google-oauth-java-client is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-7692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-7692" id="CVE-2020-7692" title="CVE-2020-7692" type="cve"></reference>
		</references>
		<description>CVE-2020-7692:PKCE support is not implemented in accordance with the RFC for OAuth 2.0 for Native Apps. Without the use of PKCE, the authorization code returned by an authorization server is not enough to guarantee that the client that issued the initial authorization request is the one that will be authorized. An attacker is able to obtain the authorization code using a malicious app on the client-side and use it to gain authorization to the protected resource. This affects the package com.google.oauth-client:google-oauth-client before 1.31.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="google-oauth-java-client" release="7.u2" version="1.22.0">
					<filename>google-oauth-java-client-1.22.0-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/google-oauth-java-client-1.22.0-7.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="google-oauth-java-client-help" release="7.u2" version="1.22.0">
					<filename>google-oauth-java-client-help-1.22.0-7.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/google-oauth-java-client-help-1.22.0-7.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3086</id>
		<title>An update for munge is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25506&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25506" id="CVE-2026-25506" title="CVE-2026-25506" type="cve"></reference>
		</references>
		<description>CVE-2026-25506:MUNGE is an authentication service for creating and validating user credentials. From 0.5 to 0.5.17, local attacker can exploit a buffer overflow vulnerability in munged (the MUNGE authentication daemon) to leak cryptographic key material from process memory. With the leaked key material, the attacker could forge arbitrary MUNGE credentials to impersonate any user (including root) to services that rely on MUNGE for authentication. The vulnerability allows a buffer overflow by sending a crafted message with an oversized address length field, corrupting munged&#39;s internal state and enabling extraction of the MAC subkey used for credential verification. This vulnerability is fixed in 0.5.18.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="munge-libs" release="2.u1" version="0.5.14">
					<filename>munge-libs-0.5.14-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/munge-libs-0.5.14-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="munge" release="2.u1" version="0.5.14">
					<filename>munge-0.5.14-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/munge-0.5.14-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="munge-devel" release="2.u1" version="0.5.14">
					<filename>munge-devel-0.5.14-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/munge-devel-0.5.14-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="munge" release="2.u1" version="0.5.14">
					<filename>munge-0.5.14-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/munge-0.5.14-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="munge-libs" release="2.u1" version="0.5.14">
					<filename>munge-libs-0.5.14-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/munge-libs-0.5.14-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="munge-devel" release="2.u1" version="0.5.14">
					<filename>munge-devel-0.5.14-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/munge-devel-0.5.14-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3087</id>
		<title>An update for undertow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3884&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-3884" id="CVE-2024-3884" title="CVE-2024-3884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4027&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-4027" id="CVE-2024-4027" title="CVE-2024-4027" type="cve"></reference>
		</references>
		<description>CVE-2024-3884:A flaw was found in Undertow that can cause remote denial of service attacks. When the server uses the FormEncodedDataDefinition.doParse(StreamSourceChannel) method to parse large form data encoding with application/x-www-form-urlencoded, the method will cause an OutOfMemory issue. This flaw allows unauthorized users to cause a remote denial of service (DoS) attack.&#xA;CVE-2024-4027:A flaw was found in Undertow. Servlets using a method that calls HttpServletRequestImpl.getParameterNames() can cause an OutOfMemoryError when the client sends a request with large parameter names. This issue can be exploited by an unauthorized user to cause a remote denial-of-service (DoS) attack.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="1" name="undertow" release="10.u5" version="1.4.0">
					<filename>undertow-1.4.0-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/undertow-1.4.0-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="undertow-javadoc" release="10.u5" version="1.4.0">
					<filename>undertow-javadoc-1.4.0-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/undertow-javadoc-1.4.0-10.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3088</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24515&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24515" id="CVE-2026-24515" title="CVE-2026-24515" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25210&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25210" id="CVE-2026-25210" title="CVE-2026-25210" type="cve"></reference>
		</references>
		<description>CVE-2026-24515:In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.&#xA;CVE-2026-25210:In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="expat" release="21.u6" version="2.4.1">
					<filename>expat-2.4.1-21.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/expat-2.4.1-21.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat-devel" release="21.u6" version="2.4.1">
					<filename>expat-devel-2.4.1-21.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/expat-devel-2.4.1-21.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="expat-help" release="21.u6" version="2.4.1">
					<filename>expat-help-2.4.1-21.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/expat-help-2.4.1-21.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat-devel" release="21.u6" version="2.4.1">
					<filename>expat-devel-2.4.1-21.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/expat-devel-2.4.1-21.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat" release="21.u6" version="2.4.1">
					<filename>expat-2.4.1-21.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/expat-2.4.1-21.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3089</id>
		<title>An update for capstone is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-67873&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-67873" id="CVE-2025-67873" title="CVE-2025-67873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68114&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68114" id="CVE-2025-68114" title="CVE-2025-68114" type="cve"></reference>
		</references>
		<description>CVE-2025-67873:Capstone is a disassembly framework. In versions 6.0.0-Alpha5 and prior, Skipdata length is not bounds-checked, so a user-provided skipdata callback can make cs_disasm/cs_disasm_iter memcpy more than 24 bytes into cs_insn.bytes, causing a heap buffer overflow in the disassembly path. Commit cbef767ab33b82166d263895f24084b75b316df3 fixes the issue.&#xA;CVE-2025-68114:Capstone is a disassembly framework. In versions 6.0.0-Alpha5 and prior, an unchecked vsnprintf return in SStream_concat lets a malicious cs_opt_mem.vsnprintf drive SStream’s index negative or past the end, leading to a stack buffer underflow/overflow when the next write occurs. Commit 2c7797182a1618be12017d7d41e0b6581d5d529e fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="capstone-devel" release="3.u1" version="4.0.2">
					<filename>capstone-devel-4.0.2-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/capstone-devel-4.0.2-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-capstone" release="3.u1" version="4.0.2">
					<filename>python3-capstone-4.0.2-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-capstone-4.0.2-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="capstone" release="3.u1" version="4.0.2">
					<filename>capstone-4.0.2-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/capstone-4.0.2-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="capstone" release="3.u1" version="4.0.2">
					<filename>capstone-4.0.2-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/capstone-4.0.2-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="capstone-devel" release="3.u1" version="4.0.2">
					<filename>capstone-devel-4.0.2-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/capstone-devel-4.0.2-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-capstone" release="3.u1" version="4.0.2">
					<filename>python3-capstone-4.0.2-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-capstone-4.0.2-3.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3090</id>
		<title>An update for skopeo is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27144&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27144" id="CVE-2025-27144" title="CVE-2025-27144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47912" id="CVE-2025-47912" title="CVE-2025-47912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58188&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58188" id="CVE-2025-58188" title="CVE-2025-58188" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61723" id="CVE-2025-61723" title="CVE-2025-61723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58189&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58189" id="CVE-2025-58189" title="CVE-2025-58189" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61724" id="CVE-2025-61724" title="CVE-2025-61724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4674&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4674" id="CVE-2025-4674" title="CVE-2025-4674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58185&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58185" id="CVE-2025-58185" title="CVE-2025-58185" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58187" id="CVE-2025-58187" title="CVE-2025-58187" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58183" id="CVE-2025-58183" title="CVE-2025-58183" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22870&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22870" id="CVE-2025-22870" title="CVE-2025-22870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4673&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4673" id="CVE-2025-4673" title="CVE-2025-4673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58186&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58186" id="CVE-2025-58186" title="CVE-2025-58186" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61729" id="CVE-2025-61729" title="CVE-2025-61729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61727" id="CVE-2025-61727" title="CVE-2025-61727" type="cve"></reference>
		</references>
		<description>CVE-2025-27144:Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, &#34;.&#34;) to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters.  An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.&#xA;CVE-2023-39325:A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.&#xA;CVE-2025-47912:The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: &#34;http://[::1]/&#34;. IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.&#xA;CVE-2025-58188:Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains.&#xA;CVE-2025-61723:The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs.&#xA;CVE-2025-58189:When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.&#xA;CVE-2025-61724:The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption.&#xA;CVE-2025-4674:The go command may execute unexpected commands when operating in untrusted VCS repositories. This occurs when possibly dangerous VCS configuration is present in repositories. This can happen when a repository was fetched via one VCS (e.g. Git), but contains metadata for another VCS (e.g. Mercurial). Modules which are retrieved using the go command line, i.e. via &#34;go get&#34;, are not affected.&#xA;CVE-2025-58185:Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.&#xA;CVE-2025-58187:Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains.&#xA;CVE-2025-58183:tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.&#xA;CVE-2025-22870:Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to &#34;*.example.com&#34;, a request to &#34;[::1%25.example.com]:80` will incorrectly match and not be proxied.&#xA;CVE-2025-4673:Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.&#xA;CVE-2025-58186:Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as &#34;a=;&#34;, an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.&#xA;CVE-2025-61729:Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.&#xA;CVE-2025-61727:An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="1" name="skopeo" release="7.u3" version="1.8.0">
					<filename>skopeo-1.8.0-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/skopeo-1.8.0-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="containers-common" release="7.u3" version="1.8.0">
					<filename>containers-common-1.8.0-7.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/containers-common-1.8.0-7.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="containers-common" release="7.u3" version="1.8.0">
					<filename>containers-common-1.8.0-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/containers-common-1.8.0-7.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="skopeo" release="7.u3" version="1.8.0">
					<filename>skopeo-1.8.0-7.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/skopeo-1.8.0-7.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3091</id>
		<title>An update for alsa-lib is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25068&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25068" id="CVE-2026-25068" title="CVE-2026-25068" type="cve"></reference>
		</references>
		<description>CVE-2026-25068:alsa-lib versions 1.2.2 up to and including 1.2.15.2, prior to commit 5f7fe33, contain a heap-based buffer overflow in the topology mixer control decoder. The tplg_decode_control_mixer1() function reads the num_channels field from untrusted .tplg data and uses it as a loop bound without validating it against the fixed-size channel array (SND_TPLG_MAX_CHAN). A crafted topology file with an excessive num_channels value can cause out-of-bounds heap writes, leading to a crash.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="alsa-lib-devel" release="4.u1" version="1.2.5.1">
					<filename>alsa-lib-devel-1.2.5.1-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/alsa-lib-devel-1.2.5.1-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="alsa-lib" release="4.u1" version="1.2.5.1">
					<filename>alsa-lib-1.2.5.1-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/alsa-lib-1.2.5.1-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="alsa-lib" release="4.u1" version="1.2.5.1">
					<filename>alsa-lib-1.2.5.1-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/alsa-lib-1.2.5.1-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="alsa-lib-devel" release="4.u1" version="1.2.5.1">
					<filename>alsa-lib-devel-1.2.5.1-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/alsa-lib-devel-1.2.5.1-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="alsa-topology" release="4.u1" version="1.2.5.1">
					<filename>alsa-topology-1.2.5.1-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/alsa-topology-1.2.5.1-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="alsa-ucm" release="4.u1" version="1.2.5.1">
					<filename>alsa-ucm-1.2.5.1-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/alsa-ucm-1.2.5.1-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3092</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14017&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14017" id="CVE-2025-14017" title="CVE-2025-14017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14524&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14524" id="CVE-2025-14524" title="CVE-2025-14524" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-15079&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-15079" id="CVE-2025-15079" title="CVE-2025-15079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-15224&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-15224" id="CVE-2025-15224" title="CVE-2025-15224" type="cve"></reference>
		</references>
		<description>CVE-2025-14017:When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,&#xA;changing TLS options in one thread would inadvertently change them globally&#xA;and therefore possibly also affect other concurrently setup transfers.&#xA;&#xA;Disabling certificate verification for a specific transfer could&#xA;unintentionally disable the feature for other threads as well.&#xA;CVE-2025-14524:When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer&#xA;performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,&#xA;POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new&#xA;target host.&#xA;CVE-2025-15079:When doing SSH-based transfers using either SCP or SFTP, and setting the&#xA;known_hosts file, libcurl could still mistakenly accept connecting to hosts&#xA;*not present* in the specified file if they were added as recognized in the&#xA;libssh *global* known_hosts file.&#xA;CVE-2025-15224:When doing SSH-based transfers using either SCP or SFTP, and asked to do&#xA;public key authentication, curl would wrongly still ask and authenticate using&#xA;a locally running SSH agent.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="curl" release="46.u31" version="7.79.1">
					<filename>curl-7.79.1-46.u31.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/curl-7.79.1-46.u31.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="46.u31" version="7.79.1">
					<filename>libcurl-7.79.1-46.u31.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libcurl-7.79.1-46.u31.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="46.u31" version="7.79.1">
					<filename>libcurl-devel-7.79.1-46.u31.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libcurl-devel-7.79.1-46.u31.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="46.u31" version="7.79.1">
					<filename>libcurl-devel-7.79.1-46.u31.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libcurl-devel-7.79.1-46.u31.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="curl" release="46.u31" version="7.79.1">
					<filename>curl-7.79.1-46.u31.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/curl-7.79.1-46.u31.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="46.u31" version="7.79.1">
					<filename>libcurl-7.79.1-46.u31.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libcurl-7.79.1-46.u31.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="46.u31" version="7.79.1">
					<filename>curl-help-7.79.1-46.u31.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/curl-help-7.79.1-46.u31.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3093</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68160" id="CVE-2025-68160" title="CVE-2025-68160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22796&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22796" id="CVE-2026-22796" title="CVE-2026-22796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22795" id="CVE-2026-22795" title="CVE-2026-22795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69418&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69418" id="CVE-2025-69418" title="CVE-2025-69418" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69421&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69421" id="CVE-2025-69421" title="CVE-2025-69421" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69419" id="CVE-2025-69419" title="CVE-2025-69419" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69420" id="CVE-2025-69420" title="CVE-2025-69420" type="cve"></reference>
		</references>
		<description>CVE-2025-68160:Issue summary: Writing large, newline-free data into a BIO chain using the&#xA;line-buffering filter where the next BIO performs short writes can trigger&#xA;a heap-based out-of-bounds write.&#xA;&#xA;Impact summary: This out-of-bounds write can cause memory corruption which&#xA;typically results in a crash, leading to Denial of Service for an application.&#xA;&#xA;The line-buffering BIO filter (BIO_f_linebuffer) is not used by default in&#xA;TLS/SSL data paths. In OpenSSL command-line applications, it is typically&#xA;only pushed onto stdout/stderr on VMS systems. Third-party applications that&#xA;explicitly use this filter with a BIO chain that can short-write and that&#xA;write large, newline-free data influenced by an attacker would be affected.&#xA;However, the circumstances where this could happen are unlikely to be under&#xA;attacker control, and BIO_f_linebuffer is unlikely to be handling non-curated&#xA;data controlled by an attacker. For that reason the issue was assessed as&#xA;Low severity.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the BIO implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.&#xA;CVE-2026-22796:Issue summary: A type confusion vulnerability exists in the signature&#xA;verification of signed PKCS#7 data where an ASN1_TYPE union member is&#xA;accessed without first validating the type, causing an invalid or NULL&#xA;pointer dereference when processing malformed PKCS#7 data.&#xA;&#xA;Impact summary: An application performing signature verification of PKCS#7&#xA;data or calling directly the PKCS7_digest_from_attributes() function can be&#xA;caused to dereference an invalid or NULL pointer when reading, resulting in&#xA;a Denial of Service.&#xA;&#xA;The function PKCS7_digest_from_attributes() accesses the message digest attribute&#xA;value without validating its type. When the type is not V_ASN1_OCTET_STRING,&#xA;this results in accessing invalid memory through the ASN1_TYPE union, causing&#xA;a crash.&#xA;&#xA;Exploiting this vulnerability requires an attacker to provide a malformed&#xA;signed PKCS#7 to an application that verifies it. The impact of the&#xA;exploit is just a Denial of Service, the PKCS7 API is legacy and applications&#xA;should be using the CMS API instead. For these reasons the issue was&#xA;assessed as Low severity.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS#7 parsing implementation is outside the OpenSSL FIPS module&#xA;boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.&#xA;CVE-2026-22795:Issue summary: An invalid or NULL pointer dereference can happen in&#xA;an application processing a malformed PKCS#12 file.&#xA;&#xA;Impact summary: An application processing a malformed PKCS#12 file can be&#xA;caused to dereference an invalid or NULL pointer on memory read, resulting&#xA;in a Denial of Service.&#xA;&#xA;A type confusion vulnerability exists in PKCS#12 parsing code where&#xA;an ASN1_TYPE union member is accessed without first validating the type,&#xA;causing an invalid pointer read.&#xA;&#xA;The location is constrained to a 1-byte address space, meaning any&#xA;attempted pointer manipulation can only target addresses between 0x00 and 0xFF.&#xA;This range corresponds to the zero page, which is unmapped on most modern&#xA;operating systems and will reliably result in a crash, leading only to a&#xA;Denial of Service. Exploiting this issue also requires a user or application&#xA;to process a maliciously crafted PKCS#12 file. It is uncommon to accept&#xA;untrusted PKCS#12 files in applications as they are usually used to store&#xA;private keys which are trusted by definition. For these reasons, the issue&#xA;was assessed as Low severity.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&#xA;&#xA;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2025-69418:Issue summary: When using the low-level OCB API directly with AES-NI or&lt;br&gt;other hardware-accelerated code paths, inputs whose length is not a multiple&lt;br&gt;of 16 bytes can leave the final partial block unencrypted and unauthenticated.&lt;br&gt;&lt;br&gt;Impact summary: The trailing 1-15 bytes of a message may be exposed in&lt;br&gt;cleartext on encryption and are not covered by the authentication tag,&lt;br&gt;allowing an attacker to read or tamper with those bytes without detection.&lt;br&gt;&lt;br&gt;The low-level OCB encrypt and decrypt routines in the hardware-accelerated&lt;br&gt;stream path process full 16-byte blocks but do not advance the input/output&lt;br&gt;pointers. The subsequent tail-handling code then operates on the original&lt;br&gt;base pointers, effectively reprocessing the beginning of the buffer while&lt;br&gt;leaving the actual trailing bytes unprocessed. The authentication checksum&lt;br&gt;also excludes the true tail bytes.&lt;br&gt;&lt;br&gt;However, typical OpenSSL consumers using EVP are not affected because the&lt;br&gt;higher-level EVP and provider OCB implementations split inputs so that full&lt;br&gt;blocks and trailing partial blocks are processed in separate calls, avoiding&lt;br&gt;the problematic code path. Additionally, TLS does not use OCB ciphersuites.&lt;br&gt;The vulnerability only affects applications that call the low-level&lt;br&gt;CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with&lt;br&gt;non-block-aligned lengths in a single call on hardware-accelerated builds.&lt;br&gt;For these reasons the issue was assessed as Low severity.&lt;br&gt;&lt;br&gt;The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected&lt;br&gt;by this issue, as OCB mode is not a FIPS-approved algorithm.&lt;br&gt;&lt;br&gt;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&lt;br&gt;&lt;br&gt;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2025-69421:Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer&#xA;dereference in the PKCS12_item_decrypt_d2i_ex() function.&#xA;&#xA;Impact summary: A NULL pointer dereference can trigger a crash which leads to&#xA;Denial of Service for an application processing PKCS#12 files.&#xA;&#xA;The PKCS12_item_decrypt_d2i_ex() function does not check whether the oct&#xA;parameter is NULL before dereferencing it. When called from&#xA;PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can&#xA;be NULL, causing a crash. The vulnerability is limited to Denial of Service&#xA;and cannot be escalated to achieve code execution or memory disclosure.&#xA;&#xA;Exploiting this issue requires an attacker to provide a malformed PKCS#12 file&#xA;to an application that processes it. For that reason the issue was assessed as&#xA;Low severity according to our Security Policy.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.&#xA;CVE-2025-69419:Issue summary: Calling PKCS12_get_friendlyname() function on a maliciously&#xA;crafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containing&#xA;non-ASCII BMP code point can trigger a one byte write before the allocated&#xA;buffer.&#xA;&#xA;Impact summary: The out-of-bounds write can cause a memory corruption&#xA;which can have various consequences including a Denial of Service.&#xA;&#xA;The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12&#xA;BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,&#xA;the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16&#xA;source byte count as the destination buffer capacity to UTF8_putc(). For BMP&#xA;code points above U+07FF, UTF-8 requires three bytes, but the forwarded&#xA;capacity can be just two bytes. UTF8_putc() then returns -1, and this negative&#xA;value is added to the output length without validation, causing the&#xA;length to become negative. The subsequent trailing NUL byte is then written&#xA;at a negative offset, causing write outside of heap allocated buffer.&#xA;&#xA;The vulnerability is reachable via the public PKCS12_get_friendlyname() API&#xA;when parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses a&#xA;different code path that avoids this issue, PKCS12_get_friendlyname() directly&#xA;invokes the vulnerable function. Exploitation requires an attacker to provide&#xA;a malicious PKCS#12 file to be parsed by the application and the attacker&#xA;can just trigger a one zero byte write before the allocated buffer.&#xA;For that reason the issue was assessed as Low severity according to our&#xA;Security Policy.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&#xA;&#xA;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2025-69420:Issue summary: A type confusion vulnerability exists in the TimeStamp Response&#xA;verification code where an ASN1_TYPE union member is accessed without first&#xA;validating the type, causing an invalid or NULL pointer dereference when&#xA;processing a malformed TimeStamp Response file.&#xA;&#xA;Impact summary: An application calling TS_RESP_verify_response() with a&#xA;malformed TimeStamp Response can be caused to dereference an invalid or&#xA;NULL pointer when reading, resulting in a Denial of Service.&#xA;&#xA;The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()&#xA;access the signing cert attribute value without validating its type.&#xA;When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memory&#xA;through the ASN1_TYPE union, causing a crash.&#xA;&#xA;Exploiting this vulnerability requires an attacker to provide a malformed&#xA;TimeStamp Response to an application that verifies timestamp responses. The&#xA;TimeStamp protocol (RFC 3161) is not widely used and the impact of the&#xA;exploit is just a Denial of Service. For these reasons the issue was&#xA;assessed as Low severity.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the TimeStamp Response implementation is outside the OpenSSL FIPS module&#xA;boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&#xA;&#xA;OpenSSL 1.0.2 is not affected by this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="39.u21" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/openssl-perl-1.1.1m-39.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="39.u21" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/openssl-devel-1.1.1m-39.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="39.u21" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/openssl-1.1.1m-39.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="39.u21" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/openssl-libs-1.1.1m-39.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="39.u21" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/openssl-devel-1.1.1m-39.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="39.u21" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/openssl-perl-1.1.1m-39.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl" release="39.u21" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/openssl-1.1.1m-39.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="39.u21" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/openssl-libs-1.1.1m-39.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="39.u21" version="1.1.1m">
					<filename>openssl-help-1.1.1m-39.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/openssl-help-1.1.1m-39.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3094</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26269&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26269" id="CVE-2026-26269" title="CVE-2026-26269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25749&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25749" id="CVE-2026-25749" title="CVE-2026-25749" type="cve"></reference>
		</references>
		<description>CVE-2026-26269:Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim&#39;s NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.&#xA;CVE-2026-25749:Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim&#39;s tag file resolution logic when processing the &#39;helpfile&#39; option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled &#39;helpfile&#39; option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="2" name="vim-X11" release="39.u25" version="9.0">
					<filename>vim-X11-9.0-39.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/vim-X11-9.0-39.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="39.u25" version="9.0">
					<filename>vim-enhanced-9.0-39.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/vim-enhanced-9.0-39.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="39.u25" version="9.0">
					<filename>vim-common-9.0-39.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/vim-common-9.0-39.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="39.u25" version="9.0">
					<filename>vim-minimal-9.0-39.u25.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/vim-minimal-9.0-39.u25.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="39.u25" version="9.0">
					<filename>vim-filesystem-9.0-39.u25.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vim-filesystem-9.0-39.u25.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="39.u25" version="9.0">
					<filename>vim-X11-9.0-39.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vim-X11-9.0-39.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-common" release="39.u25" version="9.0">
					<filename>vim-common-9.0-39.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vim-common-9.0-39.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="39.u25" version="9.0">
					<filename>vim-minimal-9.0-39.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vim-minimal-9.0-39.u25.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="39.u25" version="9.0">
					<filename>vim-enhanced-9.0-39.u25.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vim-enhanced-9.0-39.u25.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3095</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21936&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21936" id="CVE-2026-21936" title="CVE-2026-21936" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21937&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21937" id="CVE-2026-21937" title="CVE-2026-21937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21941&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21941" id="CVE-2026-21941" title="CVE-2026-21941" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21948&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21948" id="CVE-2026-21948" title="CVE-2026-21948" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21964" id="CVE-2026-21964" title="CVE-2026-21964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21968&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21968" id="CVE-2026-21968" title="CVE-2026-21968" type="cve"></reference>
		</references>
		<description>CVE-2026-21936:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-21937:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-21941:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-21948:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-21964:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-21968:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u5" version="8.0.45">
					<filename>mysql-devel-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-devel-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u5" version="8.0.45">
					<filename>mysql-errmsg-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-errmsg-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u5" version="8.0.45">
					<filename>mysql-help-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-help-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u5" version="8.0.45">
					<filename>mysql-libs-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-libs-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u5" version="8.0.45">
					<filename>mysql-server-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-server-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u5" version="8.0.45">
					<filename>mysql-config-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-config-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u5" version="8.0.45">
					<filename>mysql-common-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-common-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u5" version="8.0.45">
					<filename>mysql-test-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-test-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u5" version="8.0.45">
					<filename>mysql-8.0.45-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/mysql-8.0.45-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u5" version="8.0.45">
					<filename>mysql-common-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-common-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u5" version="8.0.45">
					<filename>mysql-config-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-config-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u5" version="8.0.45">
					<filename>mysql-devel-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-devel-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u5" version="8.0.45">
					<filename>mysql-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u5" version="8.0.45">
					<filename>mysql-errmsg-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-errmsg-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u5" version="8.0.45">
					<filename>mysql-server-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-server-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u5" version="8.0.45">
					<filename>mysql-test-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-test-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u5" version="8.0.45">
					<filename>mysql-help-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-help-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u5" version="8.0.45">
					<filename>mysql-libs-8.0.45-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/mysql-libs-8.0.45-1.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3096</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61144&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61144" id="CVE-2025-61144" title="CVE-2025-61144" type="cve"></reference>
		</references>
		<description>CVE-2025-61144:libtiff up to v4.7.1 was discovered to contain a stack overflow via the readSeparateStripsIntoBuffer function.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="49.u22" version="4.3.0">
					<filename>libtiff-tools-4.3.0-49.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libtiff-tools-4.3.0-49.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="49.u22" version="4.3.0">
					<filename>libtiff-devel-4.3.0-49.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libtiff-devel-4.3.0-49.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="49.u22" version="4.3.0">
					<filename>libtiff-static-4.3.0-49.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libtiff-static-4.3.0-49.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff" release="49.u22" version="4.3.0">
					<filename>libtiff-4.3.0-49.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libtiff-4.3.0-49.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="49.u22" version="4.3.0">
					<filename>libtiff-4.3.0-49.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libtiff-4.3.0-49.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="49.u22" version="4.3.0">
					<filename>libtiff-devel-4.3.0-49.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libtiff-devel-4.3.0-49.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="49.u22" version="4.3.0">
					<filename>libtiff-tools-4.3.0-49.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libtiff-tools-4.3.0-49.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="49.u22" version="4.3.0">
					<filename>libtiff-static-4.3.0-49.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libtiff-static-4.3.0-49.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="49.u22" version="4.3.0">
					<filename>libtiff-help-4.3.0-49.u22.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libtiff-help-4.3.0-49.u22.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3097</id>
		<title>An update for cups-filters is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-57812&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-57812" id="CVE-2025-57812" title="CVE-2025-57812" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64503&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64503" id="CVE-2025-64503" title="CVE-2025-64503" type="cve"></reference>
		</references>
		<description>CVE-2025-57812:CUPS is a standards-based, open-source printing system, and `libcupsfilters` contains the code of the filters of the former `cups-filters` package as library functions to be used for the data format conversion tasks needed in Printer Applications. In CUPS-Filters versions up to and including 1.28.17 and libscupsfilters versions 2.0.0 through 2.1.1, CUPS-Filters&#39;s `imagetoraster` filter has an out of bounds read/write vulnerability in the processing of TIFF image files.  While the pixel buffer is allocated with the number of pixels times a pre-calculated bytes-per-pixel value, the function which processes these pixels is called with a size of the number of pixels times 3.  When suitable inputs are passed, the bytes-per-pixel value can be set to 1 and bytes outside of the buffer bounds get processed. In order to trigger the bug, an attacker must issue a print job with a crafted TIFF file, and pass appropriate print job options to control the bytes-per-pixel value of the output format. They must choose a printer configuration under which the `imagetoraster` filter or its C-function equivalent `cfFilterImageToRaster()` gets invoked. The vulnerability exists in both CUPS-Filters 1.x and the successor library libcupsfilters (CUPS-Filters 2.x). In CUPS-Filters 2.x, the vulnerable function is `_cfImageReadTIFF() in libcupsfilters`. When this function is invoked as part of `cfFilterImageToRaster()`, the caller passes a look-up-table during whose processing the out of bounds memory access happens. In CUPS-Filters 1.x, the equivalent functions are all found in the cups-filters repository, which is not split into subprojects yet, and the vulnerable code is in `_cupsImageReadTIFF()`, which is called through `cupsImageOpen()` from the `imagetoraster` tool. A patch is available in commit b69dfacec7f176281782e2f7ac44f04bf9633cfa.&#xA;CVE-2025-64503:cups-filters contains backends, filters, and other software required to get the cups printing service working on operating systems other than macos. In cups-filters prior to 1.28.18, by crafting a PDF file with a large `MediaBox` value, an attacker can cause CUPS-Filter 1.x’s `pdftoraster` tool to write beyond the bounds of an array. First, a PDF with a large `MediaBox` width value causes `header.cupsWidth` to become large.  Next, the calculation of `bytesPerLine = (header.cupsBitsPerPixel * header.cupsWidth + 7) / 8` overflows, resulting in a small value. Then, `lineBuf` is allocated with the small `bytesPerLine` size. Finally, `convertLineChunked` calls `writePixel8`, which attempts to write to `lineBuf` outside of its buffer size (out of bounds write). In libcupsfilters, the maintainers found the same `bytesPerLine` multiplication without overflow check, but the provided test case does not cause an overflow there, because the values are different. Commit 50d94ca0f2fa6177613c97c59791bde568631865 contains a patch, which is incorporated into cups-filters version 1.28.18.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="cups-filters-devel" release="6.u4" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-filters-devel-1.28.9-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters" release="6.u4" version="1.28.9">
					<filename>cups-filters-1.28.9-6.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-filters-1.28.9-6.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cups-filters-help" release="6.u4" version="1.28.9">
					<filename>cups-filters-help-1.28.9-6.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cups-filters-help-1.28.9-6.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters" release="6.u4" version="1.28.9">
					<filename>cups-filters-1.28.9-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-filters-1.28.9-6.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters-devel" release="6.u4" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-6.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cups-filters-devel-1.28.9-6.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3098</id>
		<title>An update for usbmuxd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66004" id="CVE-2025-66004" title="CVE-2025-66004" type="cve"></reference>
		</references>
		<description>CVE-2025-66004:A Path Traversal vulnerability in usbmuxd allows local users to escalate to the service user.This issue affects usbmuxd: before 3ded00c9985a5108cfc7591a309f9a23d57a8cba.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="usbmuxd" release="5.u2" version="1.1.1">
					<filename>usbmuxd-1.1.1-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/usbmuxd-1.1.1-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="usbmuxd" release="5.u2" version="1.1.1">
					<filename>usbmuxd-1.1.1-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/usbmuxd-1.1.1-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="usbmuxd-help" release="5.u2" version="1.1.1">
					<filename>usbmuxd-help-1.1.1-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/usbmuxd-help-1.1.1-5.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3099</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22852&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22852" id="CVE-2026-22852" title="CVE-2026-22852" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22854&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22854" id="CVE-2026-22854" title="CVE-2026-22854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22855&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22855" id="CVE-2026-22855" title="CVE-2026-22855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22856" id="CVE-2026-22856" title="CVE-2026-22856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22857" id="CVE-2026-22857" title="CVE-2026-22857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22859" id="CVE-2026-22859" title="CVE-2026-22859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23530&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23530" id="CVE-2026-23530" title="CVE-2026-23530" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23531&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23531" id="CVE-2026-23531" title="CVE-2026-23531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23532&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23532" id="CVE-2026-23532" title="CVE-2026-23532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23533&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23533" id="CVE-2026-23533" title="CVE-2026-23533" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23534&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23534" id="CVE-2026-23534" title="CVE-2026-23534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23732&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23732" id="CVE-2026-23732" title="CVE-2026-23732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23883&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23883" id="CVE-2026-23883" title="CVE-2026-23883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23884&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23884" id="CVE-2026-23884" title="CVE-2026-23884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24491&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24491" id="CVE-2026-24491" title="CVE-2026-24491" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24675&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24675" id="CVE-2026-24675" title="CVE-2026-24675" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24676&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24676" id="CVE-2026-24676" title="CVE-2026-24676" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24679&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24679" id="CVE-2026-24679" title="CVE-2026-24679" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24681&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24681" id="CVE-2026-24681" title="CVE-2026-24681" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24682&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24682" id="CVE-2026-24682" title="CVE-2026-24682" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24683&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24683" id="CVE-2026-24683" title="CVE-2026-24683" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24684&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24684" id="CVE-2026-24684" title="CVE-2026-24684" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25941&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25941" id="CVE-2026-25941" title="CVE-2026-25941" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25997&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25997" id="CVE-2026-25997" title="CVE-2026-25997" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26271&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26271" id="CVE-2026-26271" title="CVE-2026-26271" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26986&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26986" id="CVE-2026-26986" title="CVE-2026-26986" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27015" id="CVE-2026-27015" title="CVE-2026-27015" type="cve"></reference>
		</references>
		<description>CVE-2026-22852:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.20.1, a malicious RDP server can trigger a heap-buffer-overflow write in the FreeRDP client when processing Audio Input (AUDIN) format lists. audin_process_formats reuses callback-&gt;formats_count across multiple MSG_SNDIN_FORMATS PDUs and writes past the newly allocated formats array, causing memory corruption and a crash. This vulnerability is fixed in 3.20.1.&#xA;CVE-2026-22854:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.20.1, a heap-buffer-overflow occurs in drive read when a server-controlled read length is used to read file data into an IRP output stream buffer without a hard upper bound, allowing an oversized read to overwrite heap memory. This vulnerability is fixed in 3.20.1.&#xA;CVE-2026-22855:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.20.1, a heap out-of-bounds read occurs in the smartcard SetAttrib path when cbAttrLen does not match the actual NDR buffer length. This vulnerability is fixed in 3.20.1.&#xA;CVE-2026-22856:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.20.1, a race in the serial channel IRP thread tracking allows a heap use‑after‑free when one thread removes an entry from serial-&gt;IrpThreads while another reads it. This vulnerability is fixed in 3.20.1.&#xA;CVE-2026-22857:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.20.1, a heap use-after-free occurs in irp_thread_func because the IRP is freed by irp-&gt;Complete() and then accessed again on the error path. This vulnerability is fixed in 3.20.1.&#xA;CVE-2026-22859:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.20.1, the URBDRC client does not perform bounds checking on server‑supplied MSUSB_INTERFACE_DESCRIPTOR values and uses them as indices in libusb_udev_complete_msconfig_setup, causing an out‑of‑bounds read. This vulnerability is fixed in 3.20.1.&#xA;CVE-2026-23530:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0,`freerdp_bitmap_decompress_planar` does not validate `nSrcWidth`/`nSrcHeight` against `planar-&gt;maxWidth`/`maxHeight` before RLE decode. A malicious server can trigger a client‑side heap buffer overflow, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23531:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, in ClearCodec, when `glyphData` is present, `clear_decompress` calls `freerdp_image_copy_no_overlap` without validating the destination rectangle, allowing an out-of-bounds read/write via crafted RDPGFX surface updates. A malicious server can trigger a client‑side heap buffer overflow, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23532:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, a client-side heap buffer overflow occurs in the  FreeRDP client’s `gdi_SurfaceToSurface` path due to a mismatch between destination rectangle clamping and the actual copy size. A malicious server can trigger a client‑side heap buffer overflow, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23533:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, a client-side heap buffer overflow occurs in the RDPGFX ClearCodec decode path when maliciously crafted residual data causes out-of-bounds writes during color output. A malicious server can trigger a client‑side heap buffer overflow, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23534:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, a client-side heap buffer overflow occurs in the ClearCodec bands decode path when crafted band coordinates allow writes past the end of the destination surface buffer. A malicious server can trigger a client‑side heap buffer overflow, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23732:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, FastGlyph parsing trusts `cbData`/remaining length and never validates against the minimum size implied by `cx/cy`. A malicious server can trigger a client‑side global buffer overflow, causing a crash (DoS). Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23883:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, `xf_Pointer_New` frees `cursorPixels` on failure, then `pointer_free` calls `xf_Pointer_Free` and frees it again, triggering ASan UAF. A malicious server can trigger a client‑side use after free, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-23884:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.21.0, offscreen bitmap deletion leaves `gdi-&gt;drawing` pointing to freed memory, causing UAF when related update packets arrive. A malicious server can trigger a client‑side use after free, causing a crash (DoS) and potential heap corruption with code‑execution risk depending on allocator behavior and surrounding heap layout. Version 3.21.0 contains a patch for the issue.&#xA;CVE-2026-24491:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, video_timer can send client notifications after the control channel is closed, dereferencing a freed callback and triggering a use after free. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24675:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, urb_select_interface can free the device&#39;s MS config on error but later code still dereferences it, leading to a use after free in libusb_udev_select_interface. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24676:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, AUDIN format renegotiation frees the active format list while the capture thread continues using audin-&gt;format, leading to a use after free in audio_format_compatible. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24679:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, The URBDRC client uses server-supplied interface numbers as array indices without bounds checks, causing an out-of-bounds read in libusb_udev_select_interface. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24681:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, aAsynchronous bulk transfer completions can use a freed channel callback after URBDRC channel close, leading to a use after free in urb_write_completion. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24682:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, audin_server_recv_formats frees an incorrect number of audio formats on parse failure (i + i), leading to out-of-bounds access in audio_formats_free. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24683:FreeRDP is a free implementation of the Remote Desktop Protocol. ainput_send_input_event caches channel_callback in a local variable and later uses it without synchronization; a concurrent channel close can free or reinitialize the callback, leading to a use after free. Prior to 3.22.0, This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-24684:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.22.0, the RDPSND async playback thread can process queued PDUs after the channel is closed and internal state is freed, leading to a use after free in rdpsnd_treat_wave. This vulnerability is fixed in 3.22.0.&#xA;CVE-2026-25941:FreeRDP is a free implementation of the Remote Desktop Protocol. Versions on the 2.x branch prior to to 2.11.8 and on the 3.x branch prior to 3.23.0 have an out-of-bounds read vulnerability in the FreeRDP client&#39;s RDPGFX channel that allows a malicious RDP server to read uninitialized heap memory by sending a crafted WIRE_TO_SURFACE_2 PDU with a `bitmapDataLength` value larger than the actual data in the packet. This can lead to information disclosure or client crashes when a user connects to a malicious server. Versions 2.11.8 and 3.23.0 fix the issue.&#xA;CVE-2026-25997:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, `xf_clipboard_format_equal` reads freed `lastSentFormats` memory because `xf_clipboard_formats_free` (called from the cliprdr channel thread during auto-reconnect) frees the array while the X11 event thread concurrently iterates it in `xf_clipboard_changed`, triggering a heap use after free. Version 3.23.0 fixes the issue.&#xA;CVE-2026-26271:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, a buffer overread in `freerdp_image_copy_from_icon_data()` (libfreerdp/codec/color.c) can be triggered by crafted RDP Window Icon (TS_ICON_INFO) data. The bug is reachable over the network when a client processes icon data from an RDP server (or from a man-in-the-middle). Version 3.23.0 fixes the issue.&#xA;CVE-2026-26986:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, `rail_window_free` dereferences a freed `xfAppWindow` pointer during `HashTable_Free` cleanup because `xf_rail_window_common` calls `free(appWindow)` on title allocation failure without first removing the entry from the `railWindows` hash table, leaving a dangling pointer that is freed again on disconnect. Version 3.23.0 fixes the vulnerability.&#xA;CVE-2026-27015:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, a missing bounds check in `smartcard_unpack_read_size_align()` (`libfreerdp/utils/smartcard_pack.c:1703`) allows a malicious RDP server to crash the FreeRDP client via a reachable `WINPR_ASSERT` → `abort()`. The crash occurs in upstream builds where `WITH_VERBOSE_WINPR_ASSERT=ON` (default in FreeRDP 3.22.0 / current WinPR CMake defaults). Smartcard redirection must be explicitly enabled by the user (e.g., `xfreerdp /smartcard`; `/smartcard-logon` implies `/smartcard`). Version 3.23.0 fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="2" name="libwinpr" release="1.u1" version="2.11.8">
					<filename>libwinpr-2.11.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libwinpr-2.11.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-devel" release="1.u1" version="2.11.8">
					<filename>freerdp-devel-2.11.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/freerdp-devel-2.11.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp" release="1.u1" version="2.11.8">
					<filename>freerdp-2.11.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/freerdp-2.11.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-help" release="1.u1" version="2.11.8">
					<filename>freerdp-help-2.11.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/freerdp-help-2.11.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr-devel" release="1.u1" version="2.11.8">
					<filename>libwinpr-devel-2.11.8-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libwinpr-devel-2.11.8-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp" release="1.u1" version="2.11.8">
					<filename>freerdp-2.11.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/freerdp-2.11.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-devel" release="1.u1" version="2.11.8">
					<filename>freerdp-devel-2.11.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/freerdp-devel-2.11.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr" release="1.u1" version="2.11.8">
					<filename>libwinpr-2.11.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libwinpr-2.11.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr-devel" release="1.u1" version="2.11.8">
					<filename>libwinpr-devel-2.11.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libwinpr-devel-2.11.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-help" release="1.u1" version="2.11.8">
					<filename>freerdp-help-2.11.8-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/freerdp-help-2.11.8-1.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3100</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0990&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0990" id="CVE-2026-0990" title="CVE-2026-0990" type="cve"></reference>
		</references>
		<description>CVE-2026-0990:A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="libxml2" release="23.u18" version="2.9.14">
					<filename>libxml2-2.9.14-23.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libxml2-2.9.14-23.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="23.u18" version="2.9.14">
					<filename>libxml2-devel-2.9.14-23.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libxml2-devel-2.9.14-23.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="23.u18" version="2.9.14">
					<filename>python3-libxml2-2.9.14-23.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-libxml2-2.9.14-23.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libxml2-help" release="23.u18" version="2.9.14">
					<filename>libxml2-help-2.9.14-23.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libxml2-help-2.9.14-23.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="23.u18" version="2.9.14">
					<filename>libxml2-2.9.14-23.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libxml2-2.9.14-23.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="23.u18" version="2.9.14">
					<filename>libxml2-devel-2.9.14-23.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libxml2-devel-2.9.14-23.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="23.u18" version="2.9.14">
					<filename>python3-libxml2-2.9.14-23.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-libxml2-2.9.14-23.u18.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3101</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24791&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-24791" id="CVE-2024-24791" title="CVE-2024-24791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34155&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-34155" id="CVE-2024-34155" title="CVE-2024-34155" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34156&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-34156" id="CVE-2024-34156" title="CVE-2024-34156" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-34158" id="CVE-2024-34158" title="CVE-2024-34158" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45341&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45341" id="CVE-2024-45341" title="CVE-2024-45341" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45336&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-45336" id="CVE-2024-45336" title="CVE-2024-45336" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22870&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22870" id="CVE-2025-22870" title="CVE-2025-22870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4673&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4673" id="CVE-2025-4673" title="CVE-2025-4673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4674&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-4674" id="CVE-2025-4674" title="CVE-2025-4674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22871&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22871" id="CVE-2025-22871" title="CVE-2025-22871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58183" id="CVE-2025-58183" title="CVE-2025-58183" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58189&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58189" id="CVE-2025-58189" title="CVE-2025-58189" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61724" id="CVE-2025-61724" title="CVE-2025-61724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58188&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58188" id="CVE-2025-58188" title="CVE-2025-58188" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58185&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58185" id="CVE-2025-58185" title="CVE-2025-58185" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58187" id="CVE-2025-58187" title="CVE-2025-58187" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61723" id="CVE-2025-61723" title="CVE-2025-61723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47912&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-47912" id="CVE-2025-47912" title="CVE-2025-47912" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58186&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58186" id="CVE-2025-58186" title="CVE-2025-58186" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61729" id="CVE-2025-61729" title="CVE-2025-61729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61727" id="CVE-2025-61727" title="CVE-2025-61727" type="cve"></reference>
		</references>
		<description>CVE-2024-24791:The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an &#34;Expect: 100-continue&#34; header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail. An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending &#34;Expect: 100-continue&#34; requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.&#xA;CVE-2024-34155:Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.&#xA;CVE-2024-34156:Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635.&#xA;CVE-2024-34158:Calling Parse on a &#34;// +build&#34; build tag line with deeply nested expressions can cause a panic due to stack exhaustion.&#xA;CVE-2024-45341:A certificate with a URI which has a IPv6 address with a zone ID may incorrectly satisfy a URI name constraint that applies to the certificate chain. Certificates containing URIs are not permitted in the web PKI, so this only affects users of private PKIs which make use of URIs.&#xA;CVE-2024-45336:The HTTP client drops sensitive headers after following a cross-domain redirect. For example, a request to a.com/ containing an Authorization header which is redirected to b.com/ will not send that header to b.com. In the event that the client received a subsequent same-domain redirect, however, the sensitive headers would be restored. For example, a chain of redirects from a.com/, to b.com/1, and finally to b.com/2 would incorrectly send the Authorization header to b.com/2.&#xA;CVE-2025-22870:Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to &#34;*.example.com&#34;, a request to &#34;[::1%25.example.com]:80` will incorrectly match and not be proxied.&#xA;CVE-2025-4673:Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.&#xA;CVE-2025-4674:The go command may execute unexpected commands when operating in untrusted VCS repositories. This occurs when possibly dangerous VCS configuration is present in repositories. This can happen when a repository was fetched via one VCS (e.g. Git), but contains metadata for another VCS (e.g. Mercurial). Modules which are retrieved using the go command line, i.e. via &#34;go get&#34;, are not affected.&#xA;CVE-2025-22871:The net/http package improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. This can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext.&#xA;CVE-2025-58183:tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.&#xA;CVE-2025-58189:When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.&#xA;CVE-2025-61724:The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption.&#xA;CVE-2025-58188:Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains.&#xA;CVE-2025-58185:Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.&#xA;CVE-2025-58187:Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains.&#xA;CVE-2025-61723:The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs.&#xA;CVE-2025-47912:The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: &#34;http://[::1]/&#34;. IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.&#xA;CVE-2025-58186:Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as &#34;a=;&#34;, an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.&#xA;CVE-2025-61729:Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.&#xA;CVE-2025-61727:An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="golang-devel" release="44.u13" version="1.21.4">
					<filename>golang-devel-1.21.4-44.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/golang-devel-1.21.4-44.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="44.u13" version="1.21.4">
					<filename>golang-help-1.21.4-44.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/golang-help-1.21.4-44.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="golang" release="44.u13" version="1.21.4">
					<filename>golang-1.21.4-44.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/golang-1.21.4-44.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="golang" release="44.u13" version="1.21.4">
					<filename>golang-1.21.4-44.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/golang-1.21.4-44.u13.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3102</id>
		<title>An update for opencryptoki is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0914&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-0914" id="CVE-2024-0914" title="CVE-2024-0914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22791&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22791" id="CVE-2026-22791" title="CVE-2026-22791" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23893&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23893" id="CVE-2026-23893" title="CVE-2026-23893" type="cve"></reference>
		</references>
		<description>CVE-2024-0914:A timing side-channel vulnerability has been discovered in the opencryptoki package while processing RSA PKCS#1 v1.5 padded ciphertexts. This flaw could potentially enable unauthorized RSA ciphertext decryption or signing, even without access to the corresponding private key.&#xA;CVE-2026-22791:openCryptoki is a PKCS#11 library and tools for Linux and AIX. In 3.25.0 and 3.26.0, there is a heap buffer overflow vulnerability in the CKM_ECDH_AES_KEY_WRAP implementation allows an attacker with local access to cause out-of-bounds writes in the host process by supplying a compressed EC public key and invoking C_WrapKey. This can lead to heap corruption, or denial-of-service.&#xA;CVE-2026-23893:openCryptoki is a PKCS#11 library and provides tooling for Linux and AIX. Versions 2.3.2 and above are vulnerable to symlink-following when running in privileged contexts. A token-group user can redirect file operations to arbitrary filesystem targets by planting symlinks in group-writable token directories, resulting in privilege escalation or data exposure. Token and lock directories are 0770 (group-writable for token users), so any token-group member can plant files and symlinks inside them. When run as root, the base code handling token directory file access, as well as several openCryptoki tools used for administrative purposes, may reset ownership or permissions on existing files inside the token directories. An attacker with token-group membership can exploit the system when an administrator runs a PKCS#11 application or administrative tool that performs chown on files inside the token directory during normal maintenance. This issue is fixed in commit 5e6e4b4, but has not been included in a released version at the time of publication.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="opencryptoki" release="1" version="3.26.0">
					<filename>opencryptoki-3.26.0-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/opencryptoki-3.26.0-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="opencryptoki-devel" release="1" version="3.26.0">
					<filename>opencryptoki-devel-3.26.0-1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/opencryptoki-devel-3.26.0-1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opencryptoki" release="1" version="3.26.0">
					<filename>opencryptoki-3.26.0-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/opencryptoki-3.26.0-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="opencryptoki-devel" release="1" version="3.26.0">
					<filename>opencryptoki-devel-3.26.0-1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/opencryptoki-devel-3.26.0-1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="opencryptoki-help" release="1" version="3.26.0">
					<filename>opencryptoki-help-3.26.0-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/opencryptoki-help-3.26.0-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3103</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0960&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0960" id="CVE-2026-0960" title="CVE-2026-0960" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0962&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0962" id="CVE-2026-0962" title="CVE-2026-0962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0959&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0959" id="CVE-2026-0959" title="CVE-2026-0959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0961&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0961" id="CVE-2026-0961" title="CVE-2026-0961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3203&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3203" id="CVE-2026-3203" title="CVE-2026-3203" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3201&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3201" id="CVE-2026-3201" title="CVE-2026-3201" type="cve"></reference>
		</references>
		<description>CVE-2026-0960:HTTP3 protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.2 allows denial of service&#xA;CVE-2026-0962:SOME/IP-SD protocol dissector crash in Wireshark 4.6.0 to 4.6.2 and 4.4.0 to 4.4.12 allows denial of service&#xA;CVE-2026-0959:IEEE 802.11 protocol dissector crash in Wireshark 4.6.0 to 4.6.2 and 4.4.0 to 4.4.12 allows denial of service&#xA;CVE-2026-0961:BLF file parser crash in Wireshark 4.6.0 to 4.6.2 and 4.4.0 to 4.4.12 allows denial of service&#xA;CVE-2026-3203:RF4CE Profile protocol dissector crash in Wireshark 4.6.0 to 4.6.3 and 4.4.0 to 4.4.13 allows denial of service&#xA;CVE-2026-3201:USB HID protocol dissector memory exhaustion in Wireshark 4.6.0 to 4.6.3 and 4.4.0 to 4.4.13 allows denial of service&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="1" name="wireshark-help" release="1.u14" version="4.4.14">
					<filename>wireshark-help-4.4.14-1.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/wireshark-help-4.4.14-1.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="1.u14" version="4.4.14">
					<filename>wireshark-4.4.14-1.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/wireshark-4.4.14-1.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="1.u14" version="4.4.14">
					<filename>wireshark-devel-4.4.14-1.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/wireshark-devel-4.4.14-1.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark" release="1.u14" version="4.4.14">
					<filename>wireshark-4.4.14-1.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/wireshark-4.4.14-1.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="1.u14" version="4.4.14">
					<filename>wireshark-devel-4.4.14-1.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/wireshark-devel-4.4.14-1.u14.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3104</id>
		<title>An update for lz4 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-62813&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-62813" id="CVE-2025-62813" title="CVE-2025-62813" type="cve"></reference>
		</references>
		<description>CVE-2025-62813:Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="lz4-help" release="4.u1" version="1.9.3">
					<filename>lz4-help-1.9.3-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/lz4-help-1.9.3-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lz4" release="4.u1" version="1.9.3">
					<filename>lz4-1.9.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/lz4-1.9.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lz4-devel" release="4.u1" version="1.9.3">
					<filename>lz4-devel-1.9.3-4.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/lz4-devel-1.9.3-4.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lz4-devel" release="4.u1" version="1.9.3">
					<filename>lz4-devel-1.9.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/lz4-devel-1.9.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lz4" release="4.u1" version="1.9.3">
					<filename>lz4-1.9.3-4.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/lz4-1.9.3-4.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3105</id>
		<title>An update for libxslt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40403&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-40403" id="CVE-2023-40403" title="CVE-2023-40403" type="cve"></reference>
		</references>
		<description>CVE-2023-40403:The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.6, tvOS 17, iOS 16.7 and iPadOS 16.7, macOS Monterey 12.7, watchOS 10, iOS 17 and iPadOS 17, macOS Sonoma 14. Processing web content may disclose sensitive information.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="libxslt-help" release="7.u6" version="1.1.37">
					<filename>libxslt-help-1.1.37-7.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libxslt-help-1.1.37-7.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt-devel" release="7.u6" version="1.1.37">
					<filename>libxslt-devel-1.1.37-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libxslt-devel-1.1.37-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxslt" release="7.u6" version="1.1.37">
					<filename>libxslt-1.1.37-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libxslt-1.1.37-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxslt" release="7.u6" version="1.1.37">
					<filename>python3-libxslt-1.1.37-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-libxslt-1.1.37-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxslt" release="7.u6" version="1.1.37">
					<filename>python3-libxslt-1.1.37-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-libxslt-1.1.37-7.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt" release="7.u6" version="1.1.37">
					<filename>libxslt-1.1.37-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libxslt-1.1.37-7.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxslt-devel" release="7.u6" version="1.1.37">
					<filename>libxslt-devel-1.1.37-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libxslt-devel-1.1.37-7.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3106</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14821&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14821" id="CVE-2025-14821" title="CVE-2025-14821" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0964" id="CVE-2026-0964" title="CVE-2026-0964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0965&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0965" id="CVE-2026-0965" title="CVE-2026-0965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0966&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0966" id="CVE-2026-0966" title="CVE-2026-0966" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0967&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0967" id="CVE-2026-0967" title="CVE-2026-0967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0968&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0968" id="CVE-2026-0968" title="CVE-2026-0968" type="cve"></reference>
		</references>
		<description>CVE-2025-14821:A flaw was found in libssh. This vulnerability allows local man-in-the-middle attacks, security downgrades of SSH (Secure Shell) connections, and manipulation of trusted host information, posing a significant risk to the confidentiality, integrity, and availability of SSH communications via an insecure default configuration on Windows systems where the library automatically loads configuration files from the C:\etc directory, which can be created and modified by unprivileged local users.&#xA;CVE-2026-0964:A malicious SCP server can send unexpected paths that could make the client application override local files outside of working directory. This could be misused to create malicious executable or configuration files and make the user execute them under specific consequences. This is the same issue as in OpenSSH, tracked as CVE-2019-6111.&#xA;CVE-2026-0965:libssh can try to open any file during configuration parsing, when misconfigured or when local attacker can provide malicious configuration. This applies for all configuration loaded from default location, configuration provided through the `ssh_config_parse_file()` and `ssh_bind_config_parse_file()` functions as well as configuration files included from them directly or through glob wildcards.  The possibly dangerous files involve block devices, fifo, named pipe or huge system files that could cause Denial of Service.  The solution here is allowing to read only regular files and enforcing configuration file size limit of 16MB. Currently, maximum line length of a configuration file is 1K so this will effectively mean configuration files of 16K lines should still keep working.&#xA;CVE-2026-0966:A vulnerability was found in libssh (unknown version). It has been declared as problematic.The CWE definition for the vulnerability is CWE-120. The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.As an impact it is known to affect availability.There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.&#xA;CVE-2026-0967:A flaw was found in libssh. A remote attacker, by controlling client configuration files or known_hosts files, could craft specific hostnames that when processed by the `match_pattern()` function can lead to inefficient regular expression backtracking. This can cause timeouts and resource exhaustion, resulting in a Denial of Service (DoS) for the client.&#xA;CVE-2026-0968:A flaw was found in libssh in which a malicious SFTP (SSH File Transfer Protocol) server can exploit this by sending a malformed &#39;longname&#39; field within an `SSH_FXP_NAME` message during a file listing operation. This missing null check can lead to reading beyond allocated memory on the heap. This can cause unexpected behavior or lead to a denial of service (DoS) due to application crashes.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="libssh" release="15.u9" version="0.9.6">
					<filename>libssh-0.9.6-15.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libssh-0.9.6-15.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="15.u9" version="0.9.6">
					<filename>libssh-devel-0.9.6-15.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libssh-devel-0.9.6-15.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="15.u9" version="0.9.6">
					<filename>libssh-help-0.9.6-15.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libssh-help-0.9.6-15.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="15.u9" version="0.9.6">
					<filename>libssh-0.9.6-15.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libssh-0.9.6-15.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="15.u9" version="0.9.6">
					<filename>libssh-devel-0.9.6-15.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libssh-devel-0.9.6-15.u9.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3107</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43718&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43718" id="CVE-2025-43718" title="CVE-2025-43718" type="cve"></reference>
		</references>
		<description>CVE-2025-43718:Poppler 24.06.1 through 25.x before 25.04.0 allows stack consumption and a SIGSEGV via deeply nested structures within the metadata (such as GTS_PDFEVersion) of a PDF document, e.g., a regular expression for a long pdfsubver string. This occurs in Dict::lookup, Catalog::getMetadata, and associated functions in PDFDoc, with deep recursion in the regex executor (std::__detail::_Executor).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="14.u11" version="0.90.0">
					<filename>poppler-qt5-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-qt5-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="14.u11" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-glib-devel-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="14.u11" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-qt5-devel-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="14.u11" version="0.90.0">
					<filename>poppler-devel-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-devel-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="14.u11" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-cpp-devel-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="14.u11" version="0.90.0">
					<filename>poppler-glib-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-glib-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler" release="14.u11" version="0.90.0">
					<filename>poppler-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="14.u11" version="0.90.0">
					<filename>poppler-cpp-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-cpp-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="14.u11" version="0.90.0">
					<filename>poppler-utils-0.90.0-14.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-utils-0.90.0-14.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="14.u11" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-14.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-glib-doc-0.90.0-14.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="14.u11" version="0.90.0">
					<filename>poppler-help-0.90.0-14.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/poppler-help-0.90.0-14.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="14.u11" version="0.90.0">
					<filename>poppler-utils-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-utils-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="14.u11" version="0.90.0">
					<filename>poppler-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="14.u11" version="0.90.0">
					<filename>poppler-cpp-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-cpp-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="14.u11" version="0.90.0">
					<filename>poppler-devel-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-devel-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="14.u11" version="0.90.0">
					<filename>poppler-glib-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-glib-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="14.u11" version="0.90.0">
					<filename>poppler-qt5-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-qt5-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="14.u11" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-glib-devel-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="14.u11" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-qt5-devel-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="14.u11" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-14.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/poppler-cpp-devel-0.90.0-14.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3108</id>
		<title>An update for vsftpd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14242&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14242" id="CVE-2025-14242" title="CVE-2025-14242" type="cve"></reference>
		</references>
		<description>CVE-2025-14242:A flaw was found in vsftpd. This vulnerability allows a denial of service (DoS) via an integer overflow in the ls command parameter parsing, triggered by a remote, authenticated attacker sending a crafted STAT command with a specific byte sequence.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="aarch64" epoch="0" name="vsftpd" release="34.u1" version="3.0.3">
					<filename>vsftpd-3.0.3-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/vsftpd-3.0.3-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="vsftpd-help" release="34.u1" version="3.0.3">
					<filename>vsftpd-help-3.0.3-34.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/vsftpd-help-3.0.3-34.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="vsftpd" release="34.u1" version="3.0.3">
					<filename>vsftpd-3.0.3-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vsftpd-3.0.3-34.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="vsftpd-help" release="34.u1" version="3.0.3">
					<filename>vsftpd-help-3.0.3-34.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/vsftpd-help-3.0.3-34.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3109</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21441&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21441" id="CVE-2026-21441" title="CVE-2026-21441" type="cve"></reference>
		</references>
		<description>CVE-2026-21441:urllib3 is an HTTP client library for Python. urllib3&#39;s streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="python3-urllib3" release="11.u10" version="1.26.12">
					<filename>python3-urllib3-1.26.12-11.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-urllib3-1.26.12-11.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3110</id>
		<title>An update for python-lxml is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37388&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-37388" id="CVE-2024-37388" title="CVE-2024-37388" type="cve"></reference>
		</references>
		<description>CVE-2024-37388:An XML External Entity (XXE) vulnerability in the ebookmeta.get_metadata function of lxml before v4.9.1 allows attackers to access sensitive information or cause a Denial of Service (DoS) via crafted XML input.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="noarch" epoch="0" name="python-lxml-help" release="8.u2" version="4.7.1">
					<filename>python-lxml-help-4.7.1-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python-lxml-help-4.7.1-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-lxml" release="8.u2" version="4.7.1">
					<filename>python3-lxml-4.7.1-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-lxml-4.7.1-8.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-lxml" release="8.u2" version="4.7.1">
					<filename>python3-lxml-4.7.1-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-lxml-4.7.1-8.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3111</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-03-20"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58189&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58189" id="CVE-2025-58189" title="CVE-2025-58189" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-58186&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-58186" id="CVE-2025-58186" title="CVE-2025-58186" type="cve"></reference>
		</references>
		<description>CVE-2025-58189:When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.&#xA;CVE-2025-58186:Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as &#34;a=;&#34;, an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40</name>
				<package arch="x86_64" epoch="2" name="cephfs-mirror" release="21.u13" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cephfs-mirror-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-immutable-object-cache" release="21.u13" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-immutable-object-cache-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-radosgw" release="21.u13" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-radosgw-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mon" release="21.u13" version="16.2.7">
					<filename>ceph-mon-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mon-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper-devel" release="21.u13" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libradosstriper-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-common" release="21.u13" version="16.2.7">
					<filename>ceph-common-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-common-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw2" release="21.u13" version="16.2.7">
					<filename>librgw2-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/librgw2-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rbd" release="21.u13" version="16.2.7">
					<filename>python3-rbd-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-rbd-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rgw" release="21.u13" version="16.2.7">
					<filename>python3-rgw-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-rgw-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librgw-devel" release="21.u13" version="16.2.7">
					<filename>librgw-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/librgw-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-fuse" release="21.u13" version="16.2.7">
					<filename>rbd-fuse-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/rbd-fuse-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-mirror" release="21.u13" version="16.2.7">
					<filename>rbd-mirror-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/rbd-mirror-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd-devel" release="21.u13" version="16.2.7">
					<filename>librbd-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/librbd-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librbd1" release="21.u13" version="16.2.7">
					<filename>librbd1-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/librbd1-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-fuse" release="21.u13" version="16.2.7">
					<filename>ceph-fuse-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-fuse-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradospp-devel" release="21.u13" version="16.2.7">
					<filename>libradospp-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libradospp-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-cephfs" release="21.u13" version="16.2.7">
					<filename>python3-cephfs-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-cephfs-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite-devel" release="21.u13" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libcephsqlite-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-selinux" release="21.u13" version="16.2.7">
					<filename>ceph-selinux-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-selinux-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs-devel" release="21.u13" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libcephfs-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephsqlite" release="21.u13" version="16.2.7">
					<filename>libcephsqlite-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libcephsqlite-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libcephfs2" release="21.u13" version="16.2.7">
					<filename>libcephfs2-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libcephfs2-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libradosstriper1" release="21.u13" version="16.2.7">
					<filename>libradosstriper1-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/libradosstriper1-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-argparse" release="21.u13" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-ceph-argparse-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-ceph-common" release="21.u13" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-ceph-common-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="python3-rados" release="21.u13" version="16.2.7">
					<filename>python3-rados-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/python3-rados-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mds" release="21.u13" version="16.2.7">
					<filename>ceph-mds-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mds-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-mgr" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-osd" release="21.u13" version="16.2.7">
					<filename>ceph-osd-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-osd-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados-devel" release="21.u13" version="16.2.7">
					<filename>librados-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/librados-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rados-objclass-devel" release="21.u13" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/rados-objclass-devel-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-test" release="21.u13" version="16.2.7">
					<filename>ceph-test-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-test-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-base" release="21.u13" version="16.2.7">
					<filename>ceph-base-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-base-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph-resource-agents" release="21.u13" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-resource-agents-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="rbd-nbd" release="21.u13" version="16.2.7">
					<filename>rbd-nbd-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/rbd-nbd-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="ceph" release="21.u13" version="16.2.7">
					<filename>ceph-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="librados2" release="21.u13" version="16.2.7">
					<filename>librados2-16.2.7-21.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/librados2-16.2.7-21.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite-devel" release="21.u13" version="16.2.7">
					<filename>libcephsqlite-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libcephsqlite-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradospp-devel" release="21.u13" version="16.2.7">
					<filename>libradospp-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libradospp-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper-devel" release="21.u13" version="16.2.7">
					<filename>libradosstriper-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libradosstriper-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados2" release="21.u13" version="16.2.7">
					<filename>librados2-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/librados2-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-cephfs" release="21.u13" version="16.2.7">
					<filename>python3-cephfs-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-cephfs-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-mirror" release="21.u13" version="16.2.7">
					<filename>rbd-mirror-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/rbd-mirror-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mon" release="21.u13" version="16.2.7">
					<filename>ceph-mon-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-mon-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-resource-agents" release="21.u13" version="16.2.7">
					<filename>ceph-resource-agents-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-resource-agents-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="cephfs-mirror" release="21.u13" version="16.2.7">
					<filename>cephfs-mirror-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/cephfs-mirror-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs-devel" release="21.u13" version="16.2.7">
					<filename>libcephfs-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libcephfs-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephsqlite" release="21.u13" version="16.2.7">
					<filename>libcephsqlite-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libcephsqlite-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librados-devel" release="21.u13" version="16.2.7">
					<filename>librados-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/librados-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd1" release="21.u13" version="16.2.7">
					<filename>librbd1-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/librbd1-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-selinux" release="21.u13" version="16.2.7">
					<filename>ceph-selinux-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-selinux-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rgw" release="21.u13" version="16.2.7">
					<filename>python3-rgw-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-rgw-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-immutable-object-cache" release="21.u13" version="16.2.7">
					<filename>ceph-immutable-object-cache-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-immutable-object-cache-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-test" release="21.u13" version="16.2.7">
					<filename>ceph-test-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-test-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librbd-devel" release="21.u13" version="16.2.7">
					<filename>librbd-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/librbd-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph" release="21.u13" version="16.2.7">
					<filename>ceph-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rbd" release="21.u13" version="16.2.7">
					<filename>python3-rbd-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-rbd-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw-devel" release="21.u13" version="16.2.7">
					<filename>librgw-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/librgw-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-nbd" release="21.u13" version="16.2.7">
					<filename>rbd-nbd-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/rbd-nbd-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-fuse" release="21.u13" version="16.2.7">
					<filename>ceph-fuse-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-fuse-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-common" release="21.u13" version="16.2.7">
					<filename>ceph-common-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-common-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rados-objclass-devel" release="21.u13" version="16.2.7">
					<filename>rados-objclass-devel-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/rados-objclass-devel-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libcephfs2" release="21.u13" version="16.2.7">
					<filename>libcephfs2-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libcephfs2-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-rados" release="21.u13" version="16.2.7">
					<filename>python3-rados-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-rados-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="librgw2" release="21.u13" version="16.2.7">
					<filename>librgw2-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/librgw2-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-argparse" release="21.u13" version="16.2.7">
					<filename>python3-ceph-argparse-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-ceph-argparse-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="python3-ceph-common" release="21.u13" version="16.2.7">
					<filename>python3-ceph-common-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/python3-ceph-common-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-osd" release="21.u13" version="16.2.7">
					<filename>ceph-osd-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-osd-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="rbd-fuse" release="21.u13" version="16.2.7">
					<filename>rbd-fuse-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/rbd-fuse-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mds" release="21.u13" version="16.2.7">
					<filename>ceph-mds-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-mds-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-mgr" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-mgr-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-base" release="21.u13" version="16.2.7">
					<filename>ceph-base-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-base-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="ceph-radosgw" release="21.u13" version="16.2.7">
					<filename>ceph-radosgw-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/ceph-radosgw-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libradosstriper1" release="21.u13" version="16.2.7">
					<filename>libradosstriper1-16.2.7-21.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40/libradosstriper1-16.2.7-21.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-prometheus-alerts" release="21.u13" version="16.2.7">
					<filename>ceph-prometheus-alerts-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-prometheus-alerts-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-k8sevents" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-k8sevents-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-k8sevents-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-grafana-dashboards" release="21.u13" version="16.2.7">
					<filename>ceph-grafana-dashboards-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-grafana-dashboards-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-rook" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-rook-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-rook-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-diskprediction-local" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-diskprediction-local-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-diskprediction-local-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephadm" release="21.u13" version="16.2.7">
					<filename>cephadm-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cephadm-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-cephadm" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-cephadm-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-cephadm-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-dashboard" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-dashboard-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-dashboard-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="cephfs-top" release="21.u13" version="16.2.7">
					<filename>cephfs-top-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/cephfs-top-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="ceph-mgr-modules-core" release="21.u13" version="16.2.7">
					<filename>ceph-mgr-modules-core-16.2.7-21.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40/ceph-mgr-modules-core-16.2.7-21.u13.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3112</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26157" id="CVE-2026-26157" title="CVE-2026-26157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26158" id="CVE-2026-26158" title="CVE-2026-26158" type="cve"></reference>
		</references>
		<description>CVE-2026-26157:A flaw was found in BusyBox. Incomplete path sanitization in its archive extraction utilities allows an attacker to craft malicious archives that when extracted, and under specific conditions, may write to files outside the intended directory. This can lead to arbitrary file overwrite, potentially enabling code execution through the modification of sensitive system files.&#xA;CVE-2026-26158:A flaw was found in BusyBox. This vulnerability allows an attacker to modify files outside of the intended extraction directory by crafting a malicious tar archive containing unvalidated hardlink or symlink entries. If the tar archive is extracted with elevated privileges, this flaw can lead to privilege escalation, enabling an attacker to gain unauthorized access to critical system files.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="aarch64" epoch="1" name="busybox-petitboot" release="28.u6" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-28.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/busybox-petitboot-1.34.1-28.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox-help" release="28.u6" version="1.34.1">
					<filename>busybox-help-1.34.1-28.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/busybox-help-1.34.1-28.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="busybox" release="28.u6" version="1.34.1">
					<filename>busybox-1.34.1-28.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/busybox-1.34.1-28.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-help" release="28.u6" version="1.34.1">
					<filename>busybox-help-1.34.1-28.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/busybox-help-1.34.1-28.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox-petitboot" release="28.u6" version="1.34.1">
					<filename>busybox-petitboot-1.34.1-28.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/busybox-petitboot-1.34.1-28.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="busybox" release="28.u6" version="1.34.1">
					<filename>busybox-1.34.1-28.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/busybox-1.34.1-28.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3113</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33515&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33515" id="CVE-2026-33515" title="CVE-2026-33515" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33526&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33526" id="CVE-2026-33526" title="CVE-2026-33526" type="cve"></reference>
		</references>
		<description>CVE-2026-33515:Squid is a caching proxy for the Web. Prior to version 7.5, due to improper input validation, Squid is vulnerable to out of bounds read when handling ICP traffic. This problem allows a remote attacker to receive small amounts of memory potentially containing sensitive information when responding with errors to invalid ICP requests. This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero `icp_port`). This problem cannot be mitigated by denying ICP queries using `icp_access` rules. Version 7.5 contains a patch.&#xA;CVE-2026-33526:Squid is a caching proxy for the Web. Prior to version 7.5, due to heap Use-After-Free, Squid is vulnerable to Denial of Service when handling ICP traffic. This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol. This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero `icp_port`). This problem _cannot_ be mitigated by denying ICP queries using `icp_access` rules. Version 7.5 contains a patch.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="x86_64" epoch="7" name="squid" release="30.u13" version="4.9">
					<filename>squid-4.9-30.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/squid-4.9-30.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="30.u13" version="4.9">
					<filename>squid-4.9-30.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/squid-4.9-30.u13.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3114</id>
		<title>An update for python-fonttools is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66034" id="CVE-2025-66034" title="CVE-2025-66034" type="cve"></reference>
		</references>
		<description>CVE-2025-66034:fontTools is a library for manipulating fonts, written in Python. In versions from 4.33.0 to before 4.60.2, the fonttools varLib (or python3 -m fontTools.varLib) script has an arbitrary file write vulnerability that leads to remote code execution when a malicious .designspace file is processed. The vulnerability affects the main() code path of fontTools.varLib, used by the fonttools varLib CLI and any code that invokes fontTools.varLib.main(). This issue has been patched in version 4.60.2.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="noarch" epoch="0" name="fonttools-help" release="3.u2" version="4.39.4">
					<filename>fonttools-help-4.39.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/fonttools-help-4.39.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-fonttools" release="3.u2" version="4.39.4">
					<filename>python3-fonttools-4.39.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/python3-fonttools-4.39.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="fonttools" release="3.u2" version="4.39.4">
					<filename>fonttools-4.39.4-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/fonttools-4.39.4-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3115</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29776&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29776" id="CVE-2026-29776" title="CVE-2026-29776" type="cve"></reference>
		</references>
		<description>CVE-2026-29776:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, Integer Underflow in update_read_cache_bitmap_order Function of FreeRDP&#39;s Core Library This vulnerability is fixed in 3.24.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="x86_64" epoch="2" name="freerdp" release="2.u2" version="2.11.8">
					<filename>freerdp-2.11.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/freerdp-2.11.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr" release="2.u2" version="2.11.8">
					<filename>libwinpr-2.11.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/libwinpr-2.11.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr-devel" release="2.u2" version="2.11.8">
					<filename>libwinpr-devel-2.11.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/libwinpr-devel-2.11.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-help" release="2.u2" version="2.11.8">
					<filename>freerdp-help-2.11.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/freerdp-help-2.11.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-devel" release="2.u2" version="2.11.8">
					<filename>freerdp-devel-2.11.8-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/freerdp-devel-2.11.8-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp" release="2.u2" version="2.11.8">
					<filename>freerdp-2.11.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/freerdp-2.11.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr" release="2.u2" version="2.11.8">
					<filename>libwinpr-2.11.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/libwinpr-2.11.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr-devel" release="2.u2" version="2.11.8">
					<filename>libwinpr-devel-2.11.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/libwinpr-devel-2.11.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-devel" release="2.u2" version="2.11.8">
					<filename>freerdp-devel-2.11.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/freerdp-devel-2.11.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-help" release="2.u2" version="2.11.8">
					<filename>freerdp-help-2.11.8-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/freerdp-help-2.11.8-2.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3116</id>
		<title>An update for nginx is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-1642&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-1642" id="CVE-2026-1642" title="CVE-2026-1642" type="cve"></reference>
		</references>
		<description>CVE-2026-1642:A vulnerability exists in NGINX OSS and NGINX Plus when configured to proxy to upstream Transport Layer Security (TLS) servers. An attacker with a man-in-the-middle (MITM) position on the upstream server side—along with conditions beyond the attacker&#39;s control—may be able to inject plain text data into the response from an upstream proxied server.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="11.u8" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-all-modules-1.21.5-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="11.u8" version="1.21.5">
					<filename>nginx-help-1.21.5-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-help-1.21.5-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="11.u8" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-11.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-filesystem-1.21.5-11.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="11.u8" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-mod-devel-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="11.u8" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-mod-stream-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx" release="11.u8" version="1.21.5">
					<filename>nginx-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="11.u8" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-mod-mail-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="11.u8" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-mod-http-image-filter-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="11.u8" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-mod-http-xslt-filter-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="11.u8" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-11.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/nginx-mod-http-perl-1.21.5-11.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="11.u8" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-mod-mail-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="11.u8" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-mod-devel-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="11.u8" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-mod-stream-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx" release="11.u8" version="1.21.5">
					<filename>nginx-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="11.u8" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-mod-http-xslt-filter-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="11.u8" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-mod-http-image-filter-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="11.u8" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-11.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/nginx-mod-http-perl-1.21.5-11.u8.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3117</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3497&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3497" id="CVE-2026-3497" title="CVE-2026-3497" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35414&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35414" id="CVE-2026-35414" title="CVE-2026-35414" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35385&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35385" id="CVE-2026-35385" title="CVE-2026-35385" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35386&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35386" id="CVE-2026-35386" title="CVE-2026-35386" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35387&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35387" id="CVE-2026-35387" title="CVE-2026-35387" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35388&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35388" id="CVE-2026-35388" title="CVE-2026-35388" type="cve"></reference>
		</references>
		<description>CVE-2026-3497:Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.&#xA;CVE-2026-35414:OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.&#xA;CVE-2026-35385:In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users&#39; expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).&#xA;CVE-2026-35386:In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.&#xA;CVE-2026-35387:OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.&#xA;CVE-2026-35388:OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="aarch64" epoch="0" name="openssh" release="42.u29" version="8.8p1">
					<filename>openssh-8.8p1-42.u29.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/openssh-8.8p1-42.u29.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-askpass" release="42.u29" version="8.8p1">
					<filename>openssh-askpass-8.8p1-42.u29.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/openssh-askpass-8.8p1-42.u29.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="pam_ssh_agent_auth" release="4.42" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.42.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/pam_ssh_agent_auth-0.10.4-4.42.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-server" release="42.u29" version="8.8p1">
					<filename>openssh-server-8.8p1-42.u29.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/openssh-server-8.8p1-42.u29.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-clients" release="42.u29" version="8.8p1">
					<filename>openssh-clients-8.8p1-42.u29.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/openssh-clients-8.8p1-42.u29.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openssh-keycat" release="42.u29" version="8.8p1">
					<filename>openssh-keycat-8.8p1-42.u29.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/openssh-keycat-8.8p1-42.u29.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-clients" release="42.u29" version="8.8p1">
					<filename>openssh-clients-8.8p1-42.u29.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/openssh-clients-8.8p1-42.u29.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-keycat" release="42.u29" version="8.8p1">
					<filename>openssh-keycat-8.8p1-42.u29.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/openssh-keycat-8.8p1-42.u29.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh" release="42.u29" version="8.8p1">
					<filename>openssh-8.8p1-42.u29.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/openssh-8.8p1-42.u29.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-server" release="42.u29" version="8.8p1">
					<filename>openssh-server-8.8p1-42.u29.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/openssh-server-8.8p1-42.u29.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="pam_ssh_agent_auth" release="4.42" version="0.10.4">
					<filename>pam_ssh_agent_auth-0.10.4-4.42.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/pam_ssh_agent_auth-0.10.4-4.42.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openssh-askpass" release="42.u29" version="8.8p1">
					<filename>openssh-askpass-8.8p1-42.u29.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/openssh-askpass-8.8p1-42.u29.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openssh-help" release="42.u29" version="8.8p1">
					<filename>openssh-help-8.8p1-42.u29.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/openssh-help-8.8p1-42.u29.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3118</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-07"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31431&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31431" id="CVE-2026-31431" title="CVE-2026-31431" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23054&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23054" id="CVE-2026-23054" title="CVE-2026-23054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23097&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23097" id="CVE-2026-23097" title="CVE-2026-23097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71221&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71221" id="CVE-2025-71221" title="CVE-2025-71221" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53577&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53577" id="CVE-2023-53577" title="CVE-2023-53577" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23112&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23112" id="CVE-2026-23112" title="CVE-2026-23112" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23216&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23216" id="CVE-2026-23216" title="CVE-2026-23216" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39967&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39967" id="CVE-2025-39967" title="CVE-2025-39967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23074&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23074" id="CVE-2026-23074" title="CVE-2026-23074" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23209&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23209" id="CVE-2026-23209" title="CVE-2026-23209" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23191&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23191" id="CVE-2026-23191" title="CVE-2026-23191" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57979&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57979" id="CVE-2024-57979" title="CVE-2024-57979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37778" id="CVE-2025-37778" title="CVE-2025-37778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40304&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40304" id="CVE-2025-40304" title="CVE-2025-40304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23388&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23388" id="CVE-2026-23388" title="CVE-2026-23388" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23352&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23352" id="CVE-2026-23352" title="CVE-2026-23352" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23243&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23243" id="CVE-2026-23243" title="CVE-2026-23243" type="cve"></reference>
		</references>
		<description>CVE-2026-31431:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: algif_aead - Revert to operating out-of-place&#xA;&#xA;This mostly reverts commit 72548b093ee3 except for the copying of the associated data.&#xA;&#xA;There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.&#xA;CVE-2026-23054:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: hv_netvsc: reject RSS hash key programming without RX indirection table&#xA;&#xA;RSS configuration requires a valid RX indirection table. When the device&#xA;reports a single receive queue, rndis_filter_device_add() does not&#xA;allocate an indirection table, accepting RSS hash key updates in this&#xA;state leads to a hang.&#xA;&#xA;Fix this by gating netvsc_set_rxfh() on ndc-&gt;rx_table_sz and return&#xA;-EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device&#xA;capabilities and prevents incorrect behavior.&#xA;CVE-2026-23097:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;migrate: correct lock ordering for hugetlb file folios&#xA;&#xA;Syzbot has found a deadlock (analyzed by Lance Yang):&#xA;&#xA;1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).&#xA;2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire&#xA;folio_lock.&#xA;&#xA;migrate_pages()&#xA;  -&gt; migrate_hugetlbs()&#xA;    -&gt; unmap_and_move_huge_page()     &lt;- Takes folio_lock!&#xA;      -&gt; remove_migration_ptes()&#xA;        -&gt; __rmap_walk_file()&#xA;          -&gt; i_mmap_lock_read()       &lt;- Waits for i_mmap_rwsem(read lock)!&#xA;&#xA;hugetlbfs_fallocate()&#xA;  -&gt; hugetlbfs_punch_hole()           &lt;- Takes i_mmap_rwsem(write lock)!&#xA;    -&gt; hugetlbfs_zero_partial_page()&#xA;     -&gt; filemap_lock_hugetlb_folio()&#xA;      -&gt; filemap_lock_folio()&#xA;        -&gt; __filemap_get_folio        &lt;- Waits for folio_lock!&#xA;&#xA;The migration path is the one taking locks in the wrong order according to&#xA;the documentation at the top of mm/rmap.c.  So expand the scope of the&#xA;existing i_mmap_lock to cover the calls to remove_migration_ptes() too.&#xA;&#xA;This is (mostly) how it used to be after commit c0d0381ade79.  That was&#xA;removed by 336bf30eb765 for both file &amp; anon hugetlb pages when it should&#xA;only have been removed for anon hugetlb pages.&#xA;CVE-2025-71221:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()&#xA;&#xA;Add proper locking in mmp_pdma_residue() to prevent use-after-free when&#xA;accessing descriptor list and descriptor contents.&#xA;&#xA;The race occurs when multiple threads call tx_status() while the tasklet&#xA;on another CPU is freeing completed descriptors:&#xA;&#xA;CPU 0                              CPU 1&#xA;-----                              -----&#xA;mmp_pdma_tx_status()&#xA;mmp_pdma_residue()&#xA;  -&gt; NO LOCK held&#xA;     list_for_each_entry(sw, ..)&#xA;                                   DMA interrupt&#xA;                                   dma_do_tasklet()&#xA;                                     -&gt; spin_lock(&amp;desc_lock)&#xA;                                        list_move(sw-&gt;node, ...)&#xA;                                        spin_unlock(&amp;desc_lock)&#xA;  |                                     dma_pool_free(sw) &lt;- FREED!&#xA;  -&gt; access sw-&gt;desc &lt;- UAF!&#xA;&#xA;This issue can be reproduced when running dmatest on the same channel with&#xA;multiple threads (threads_per_chan &gt; 1).&#xA;&#xA;Fix by protecting the chain_running list iteration and descriptor access&#xA;with the chan-&gt;desc_lock spinlock.&#xA;CVE-2023-53577:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, cpumap: Make sure kthread is running before map update returns&#xA;&#xA;The following warning was reported when running stress-mode enabled&#xA;xdp_redirect_cpu with some RT threads:&#xA;&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135&#xA;  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)&#xA;  Workqueue: events cpu_map_kthread_stop&#xA;  RIP: 0010:put_cpu_map_entry+0xda/0x220&#xA;  ......&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? show_regs+0x65/0x70&#xA;   ? __warn+0xa5/0x240&#xA;   ......&#xA;   ? put_cpu_map_entry+0xda/0x220&#xA;   cpu_map_kthread_stop+0x41/0x60&#xA;   process_one_work+0x6b0/0xb80&#xA;   worker_thread+0x96/0x720&#xA;   kthread+0x1a5/0x1f0&#xA;   ret_from_fork+0x3a/0x70&#xA;   ret_from_fork_asm+0x1b/0x30&#xA;   &lt;/TASK&gt;&#xA;&#xA;The root cause is the same as commit 436901649731 (&#34;bpf: cpumap: Fix memory&#xA;leak in cpu_map_update_elem&#34;). The kthread is stopped prematurely by&#xA;kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn&#39;t call&#xA;cpu_map_kthread_run() at all but XDP program has already queued some&#xA;frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks&#xA;the ptr_ring, it will find it was not emptied and report a warning.&#xA;&#xA;An alternative fix is to use __cpu_map_ring_cleanup() to drop these&#xA;pending frames or skbs when kthread_stop() returns -EINTR, but it may&#xA;confuse the user, because these frames or skbs have been handled&#xA;correctly by XDP program. So instead of dropping these frames or skbs,&#xA;just make sure the per-cpu kthread is running before&#xA;__cpu_map_entry_alloc() returns.&#xA;&#xA;After apply the fix, the error handle for kthread_stop() will be&#xA;unnecessary because it will always return 0, so just remove it.&#xA;CVE-2026-23112:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec&#xA;&#xA;nvmet_tcp_build_pdu_iovec() could walk past cmd-&gt;req.sg when a PDU&#xA;length or offset exceeds sg_cnt and then use bogus sg-&gt;length/offset&#xA;values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining&#xA;entries, and sg-&gt;length/offset before building the bvec.&#xA;CVE-2026-23216:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()&#xA;&#xA;In iscsit_dec_conn_usage_count(), the function calls complete() while&#xA;holding the conn-&gt;conn_usage_lock. As soon as complete() is invoked, the&#xA;waiter (such as iscsit_close_connection()) may wake up and proceed to free&#xA;the iscsit_conn structure.&#xA;&#xA;If the waiter frees the memory before the current thread reaches&#xA;spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function&#xA;attempts to release a lock within the already-freed connection structure.&#xA;&#xA;Fix this by releasing the spinlock before calling complete().&#xA;CVE-2025-39967:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbcon: fix integer overflow in fbcon_do_set_font&#xA;&#xA;Fix integer overflow vulnerabilities in fbcon_do_set_font() where font&#xA;size calculations could overflow when handling user-controlled font&#xA;parameters.&#xA;&#xA;The vulnerabilities occur when:&#xA;1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount&#xA;   multiplication with user-controlled values that can overflow.&#xA;2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow&#xA;3. This results in smaller allocations than expected, leading to buffer&#xA;   overflows during font data copying.&#xA;&#xA;Add explicit overflow checking using check_mul_overflow() and&#xA;check_add_overflow() kernel helpers to safety validate all size&#xA;calculations before allocation.&#xA;CVE-2026-23074:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: Enforce that teql can only be used as root qdisc&#xA;&#xA;Design intent of teql is that it is only supposed to be used as root qdisc.&#xA;We need to check for that constraint.&#xA;&#xA;Although not important, I will describe the scenario that unearthed this&#xA;issue for the curious.&#xA;&#xA;GangMin Kim &lt;[email protected]&gt; managed to concot a scenario as follows:&#xA;&#xA;ROOT qdisc 1:0 (QFQ)&#xA;  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s&#xA;  └── class 1:2 (weight=1, lmax=1514) teql&#xA;&#xA;GangMin sends a packet which is enqueued to 1:1 (netem).&#xA;Any invocation of dequeue by QFQ from this class will not return a packet&#xA;until after 6.4s. In the meantime, a second packet is sent and it lands on&#xA;1:2. teql&#39;s enqueue will return success and this will activate class 1:2.&#xA;Main issue is that teql only updates the parent visible qlen (sch-&gt;q.qlen)&#xA;at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&#39;s&#xA;peek always returns NULL), dequeue will never be called and thus the qlen&#xA;will remain as 0. With that in mind, when GangMin updates 1:2&#39;s lmax value,&#xA;the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&#39;s&#xA;qlen was not incremented, qfq fails to deactivate the class, but still&#xA;frees its pointers from the aggregate. So when the first packet is&#xA;rescheduled after 6.4 seconds (netem&#39;s delay), a dangling pointer is&#xA;accessed causing GangMin&#39;s causing a UAF.&#xA;CVE-2026-23209:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;macvlan: fix error recovery in macvlan_common_newlink()&#xA;&#xA;valis provided a nice repro to crash the kernel:&#xA;&#xA;ip link add p1 type veth peer p2&#xA;ip link set address 00:00:00:00:00:20 dev p1&#xA;ip link set up dev p1&#xA;ip link set up dev p2&#xA;&#xA;ip link add mv0 link p2 type macvlan mode source&#xA;ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20&#xA;&#xA;ping -c1 -I p1 1.2.3.4&#xA;&#xA;He also gave a very detailed analysis:&#xA;&#xA;&lt;quote valis&gt;&#xA;&#xA;The issue is triggered when a new macvlan link is created  with&#xA;MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or&#xA;MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan&#xA;port and register_netdevice() called from macvlan_common_newlink()&#xA;fails (e.g. because of the invalid link name).&#xA;&#xA;In this case macvlan_hash_add_source is called from&#xA;macvlan_change_sources() / macvlan_common_newlink():&#xA;&#xA;This adds a reference to vlan to the port&#39;s vlan_source_hash using&#xA;macvlan_source_entry.&#xA;&#xA;vlan is a pointer to the priv data of the link that is being created.&#xA;&#xA;When register_netdevice() fails, the error is returned from&#xA;macvlan_newlink() to rtnl_newlink_create():&#xA;&#xA;        if (ops-&gt;newlink)&#xA;                err = ops-&gt;newlink(dev, &amp;params, extack);&#xA;        else&#xA;                err = register_netdevice(dev);&#xA;        if (err &lt; 0) {&#xA;                free_netdev(dev);&#xA;                goto out;&#xA;        }&#xA;&#xA;and free_netdev() is called, causing a kvfree() on the struct&#xA;net_device that is still referenced in the source entry attached to&#xA;the lower device&#39;s macvlan port.&#xA;&#xA;Now all packets sent on the macvlan port with a matching source mac&#xA;address will trigger a use-after-free in macvlan_forward_source().&#xA;&#xA;&lt;/quote valis&gt;&#xA;&#xA;With all that, my fix is to make sure we call macvlan_flush_sources()&#xA;regardless of @create value whenever &#34;goto destroy_macvlan_port;&#34;&#xA;path is taken.&#xA;&#xA;Many thanks to valis for following up on this issue.&#xA;CVE-2026-23191:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: aloop: Fix racy access at PCM trigger&#xA;&#xA;The PCM trigger callback of aloop driver tries to check the PCM state&#xA;and stop the stream of the tied substream in the corresponding cable.&#xA;Since both check and stop operations are performed outside the cable&#xA;lock, this may result in UAF when a program attempts to trigger&#xA;frequently while opening/closing the tied stream, as spotted by&#xA;fuzzers.&#xA;&#xA;For addressing the UAF, this patch changes two things:&#xA;- It covers the most of code in loopback_check_format() with&#xA;  cable-&gt;lock spinlock, and add the proper NULL checks.  This avoids&#xA;  already some racy accesses.&#xA;- In addition, now we try to check the state of the capture PCM stream&#xA;  that may be stopped in this function, which was the major pain point&#xA;  leading to UAF.&#xA;CVE-2024-57979:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pps: Fix a use-after-free&#xA;&#xA;On a board running ntpd and gpsd, I&#39;m seeing a consistent use-after-free&#xA;in sys_exit() from gpsd when rebooting:&#xA;&#xA;    pps pps1: removed&#xA;    ------------[ cut here ]------------&#xA;    kobject: &#39;(null)&#39; (00000000db4bec24): is not initialized, yet kobject_put() is being called.&#xA;    WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150&#xA;    CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1&#xA;    Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)&#xA;    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;    pc : kobject_put+0x120/0x150&#xA;    lr : kobject_put+0x120/0x150&#xA;    sp : ffffffc0803d3ae0&#xA;    x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001&#xA;    x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440&#xA;    x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600&#xA;    x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000&#xA;    x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20&#xA;    x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000&#xA;    x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000&#xA;    x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000&#xA;    x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000&#xA;    x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000&#xA;    Call trace:&#xA;     kobject_put+0x120/0x150&#xA;     cdev_put+0x20/0x3c&#xA;     __fput+0x2c4/0x2d8&#xA;     ____fput+0x1c/0x38&#xA;     task_work_run+0x70/0xfc&#xA;     do_exit+0x2a0/0x924&#xA;     do_group_exit+0x34/0x90&#xA;     get_signal+0x7fc/0x8c0&#xA;     do_signal+0x128/0x13b4&#xA;     do_notify_resume+0xdc/0x160&#xA;     el0_svc+0xd4/0xf8&#xA;     el0t_64_sync_handler+0x140/0x14c&#xA;     el0t_64_sync+0x190/0x194&#xA;    ---[ end trace 0000000000000000 ]---&#xA;&#xA;...followed by more symptoms of corruption, with similar stacks:&#xA;&#xA;    refcount_t: underflow; use-after-free.&#xA;    kernel BUG at lib/list_debug.c:62!&#xA;    Kernel panic - not syncing: Oops - BUG: Fatal exception&#xA;&#xA;This happens because pps_device_destruct() frees the pps_device with the&#xA;embedded cdev immediately after calling cdev_del(), but, as the comment&#xA;above cdev_del() notes, fops for previously opened cdevs are still&#xA;callable even after cdev_del() returns. I think this bug has always&#xA;been there: I can&#39;t explain why it suddenly started happening every time&#xA;I reboot this particular board.&#xA;&#xA;In commit d953e0e837e6 (&#34;pps: Fix a use-after free bug when&#xA;unregistering a source.&#34;), George Spelvin suggested removing the&#xA;embedded cdev. That seems like the simplest way to fix this, so I&#39;ve&#xA;implemented his suggestion, using __register_chrdev() with pps_idr&#xA;becoming the source of truth for which minor corresponds to which&#xA;device.&#xA;&#xA;But now that pps_idr defines userspace visibility instead of cdev_add(),&#xA;we need to be sure the pps-&gt;dev refcount can&#39;t reach zero while&#xA;userspace can still find it again. So, the idr_remove() call moves to&#xA;pps_unregister_cdev(), and pps_idr now holds a reference to pps-&gt;dev.&#xA;&#xA;    pps_core: source serial1 got cdev (251:1)&#xA;    &lt;...&gt;&#xA;    pps pps1: removed&#xA;    pps_core: unregistering pps1&#xA;    pps_core: deallocating pps1&#xA;CVE-2025-37778:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: Fix dangling pointer in krb_authenticate&#xA;&#xA;krb_authenticate frees sess-&gt;user and does not set the pointer&#xA;to NULL. It calls ksmbd_krb5_authenticate to reinitialise&#xA;sess-&gt;user but that function may return without doing so. If&#xA;that happens then smb2_sess_setup, which calls krb_authenticate,&#xA;will be accessing free&#39;d memory when it later uses sess-&gt;user.&#xA;CVE-2025-40304:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds&#xA;&#xA;Add bounds checking to prevent writes past framebuffer boundaries when&#xA;rendering text near screen edges. Return early if the Y position is off-screen&#xA;and clip image height to screen boundary. Break from the rendering loop if the&#xA;X position is off-screen. When clipping image width to fit the screen, update&#xA;the character count to match the clipped width to prevent buffer size&#xA;mismatches.&#xA;&#xA;Without the character count update, bit_putcs_aligned and bit_putcs_unaligned&#xA;receive mismatched parameters where the buffer is allocated for the clipped&#xA;width but cnt reflects the original larger count, causing out-of-bounds writes.&#xA;CVE-2026-23388:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Squashfs: check metadata block offset is within range&#xA;&#xA;Syzkaller reports a &#34;general protection fault in squashfs_copy_data&#34;&#xA;&#xA;This is ultimately caused by a corrupted index look-up table, which&#xA;produces a negative metadata block offset.&#xA;&#xA;This is subsequently passed to squashfs_copy_data (via&#xA;squashfs_read_metadata) where the negative offset causes an out of bounds&#xA;access.&#xA;&#xA;The fix is to check that the offset is within range in&#xA;squashfs_read_metadata.  This will trap this and other cases.&#xA;CVE-2026-23352:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/efi: defer freeing of boot services memory&#xA;&#xA;efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE&#xA;and EFI_BOOT_SERVICES_DATA using memblock_free_late().&#xA;&#xA;There are two issue with that: memblock_free_late() should be used for&#xA;memory allocated with memblock_alloc() while the memory reserved with&#xA;memblock_reserve() should be freed with free_reserved_area().&#xA;&#xA;More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y&#xA;efi_free_boot_services() is called before deferred initialization of the&#xA;memory map is complete.&#xA;&#xA;Benjamin Herrenschmidt reports that this causes a leak of ~140MB of&#xA;RAM on EC2 t3a.nano instances which only have 512MB or RAM.&#xA;&#xA;If the freed memory resides in the areas that memory map for them is&#xA;still uninitialized, they won&#39;t be actually freed because&#xA;memblock_free_late() calls memblock_free_pages() and the latter skips&#xA;uninitialized pages.&#xA;&#xA;Using free_reserved_area() at this point is also problematic because&#xA;__free_page() accesses the buddy of the freed page and that again might&#xA;end up in uninitialized part of the memory map.&#xA;&#xA;Delaying the entire efi_free_boot_services() could be problematic&#xA;because in addition to freeing boot services memory it updates&#xA;efi.memmap without any synchronization and that&#39;s undesirable late in&#xA;boot when there is concurrency.&#xA;&#xA;More robust approach is to only defer freeing of the EFI boot services&#xA;memory.&#xA;&#xA;Split efi_free_boot_services() in two. First efi_unmap_boot_services()&#xA;collects ranges that should be freed into an array then&#xA;efi_free_boot_services() later frees them after deferred init is complete.&#xA;CVE-2026-23243:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/umad: Reject negative data_len in ib_umad_write&#xA;&#xA;ib_umad_write computes data_len from user-controlled count and the&#xA;MAD header sizes. With a mismatched user MAD header size and RMPP&#xA;header length, data_len can become negative and reach ib_create_send_mad().&#xA;This can make the padding calculation exceed the segment size and trigger&#xA;an out-of-bounds memset in alloc_send_rmpp_list().&#xA;&#xA;Add an explicit check to reject negative data_len before creating the&#xA;send buffer.&#xA;&#xA;KASAN splat:&#xA;[  211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0&#xA;[  211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102&#xA;[  211.365867] ib_create_send_mad+0xa01/0x11b0&#xA;[  211.365887] ib_umad_write+0x853/0x1c80&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.1</name>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-headers-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/kernel-headers-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/kernel-tools-devel-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="307.0.0.210.u195" version="5.10.0">
					<filename>perf-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/perf-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="307.0.0.210.u195" version="5.10.0">
					<filename>bpftool-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/bpftool-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/kernel-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-tools-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/kernel-tools-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="307.0.0.210.u195" version="5.10.0">
					<filename>python3-perf-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/python3-perf-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-devel-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.1/kernel-devel-5.10.0-307.0.0.210.u195.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-tools-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/kernel-tools-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="307.0.0.210.u195" version="5.10.0">
					<filename>python3-perf-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/python3-perf-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-headers-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/kernel-headers-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/kernel-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="307.0.0.210.u195" version="5.10.0">
					<filename>perf-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/perf-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-devel-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/kernel-devel-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="307.0.0.210.u195" version="5.10.0">
					<filename>bpftool-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/bpftool-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="307.0.0.210.u195" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.1/kernel-tools-devel-5.10.0-307.0.0.210.u195.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3119</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43284&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43284" id="CVE-2026-43284" title="CVE-2026-43284" type="cve"></reference>
		</references>
		<description>CVE-2026-43284:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xfrm: esp: avoid in-place decrypt on shared skb frags&#xA;&#xA;MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP&#xA;marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),&#xA;so later paths that may modify packet data can first make a private&#xA;copy. The IPv4/IPv6 datagram append paths did not set this flag when&#xA;splicing pages into UDP skbs.&#xA;&#xA;That leaves an ESP-in-UDP packet made from shared pipe pages looking&#xA;like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW&#xA;fast path for uncloned skbs without a frag_list and decrypts in place&#xA;over data that is not owned privately by the skb.&#xA;&#xA;Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching&#xA;TCP. Also make ESP input fall back to skb_cow_data() when the flag is&#xA;present, so ESP does not decrypt externally backed frags in place.&#xA;Private nonlinear skb frags still use the existing fast path.&#xA;&#xA;This intentionally does not change ESP output. In esp_output_head(),&#xA;the path that appends the ESP trailer to existing skb tailroom without&#xA;calling skb_cow_data() is not reachable for nonlinear skbs:&#xA;skb_tailroom() returns zero when skb-&gt;data_len is nonzero, while ESP&#xA;tailen is positive. Thus ESP output will either use the separate&#xA;destination-frag path or fall back to skb_cow_data().&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.2</name>
				<package arch="aarch64" epoch="0" name="bpftool" release="307.0.0.210.u196" version="5.10.0">
					<filename>bpftool-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/bpftool-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/kernel-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="307.0.0.210.u196" version="5.10.0">
					<filename>perf-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/perf-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="307.0.0.210.u196" version="5.10.0">
					<filename>python3-perf-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/python3-perf-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-devel-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/kernel-devel-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-headers-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/kernel-headers-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/kernel-tools-devel-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-tools-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.2/kernel-tools-5.10.0-307.0.0.210.u196.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/kernel-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-devel-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/kernel-devel-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="307.0.0.210.u196" version="5.10.0">
					<filename>perf-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/perf-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-tools-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/kernel-tools-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/kernel-tools-devel-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="307.0.0.210.u196" version="5.10.0">
					<filename>bpftool-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/bpftool-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="307.0.0.210.u196" version="5.10.0">
					<filename>kernel-headers-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/kernel-headers-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="307.0.0.210.u196" version="5.10.0">
					<filename>python3-perf-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.2/python3-perf-5.10.0-307.0.0.210.u196.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3120</id>
		<title>An update for PackageKit is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-05-22"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41651&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41651" id="CVE-2026-41651" title="CVE-2026-41651" type="cve"></reference>
		</references>
		<description>CVE-2026-41651:PackageKit is a a D-Bus abstraction layer that allows the user to manage packages in a secure way using a cross-distro, cross-architecture API. PackageKit between and including versions 1.0.2 and 1.3.4 is vulnerable to a time-of-check time-of-use (TOCTOU) race condition on transaction flags that allows unprivileged users to install packages as root and thus leads to a local privilege escalation. This is patched in version 1.3.5.&#xA;&#xA;A local unprivileged user can install arbitrary RPM packages as root, including executing RPM scriptlets, without authentication. The vulnerability is a TOCTOU race condition on `transaction-&gt;cached_transaction_flags`  combined with a silent state-machine guard that discards illegal backward transitions while leaving corrupted flags in place. Three bugs exist in `src/pk-transaction.c`:&#xA;1. Unconditional flag overwrite (line 4036): `InstallFiles()` writes caller-supplied flags to `transaction-&gt;cached_transaction_flags` without checking whether the transaction has already been  authorized/started. A second call blindly overwrites the flags even while the transaction is RUNNING.&#xA;2. Silent state-transition rejection (lines 873–882): `pk_transaction_set_state()` silently discards backward state transitions (e.g. `RUNNING` → `WAITING_FOR_AUTH`) but the flag overwrite at step 1 already happened. The transaction continues running with corrupted flags.&#xA;3. Late flag read at execution time (lines 2273–2277): The scheduler&#39;s idle callback reads cached_transaction_flags at dispatch time, not at authorization time. If flags were overwritten between authorization and execution, the backend sees the attacker&#39;s flags.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.2.40.3</name>
				<package arch="aarch64" epoch="0" name="PackageKit-devel" release="11.u1" version="1.1.12">
					<filename>PackageKit-devel-1.1.12-11.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.3/PackageKit-devel-1.1.12-11.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="PackageKit" release="11.u1" version="1.1.12">
					<filename>PackageKit-1.1.12-11.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.3/PackageKit-1.1.12-11.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="PackageKit-command-not-found" release="11.u1" version="1.1.12">
					<filename>PackageKit-command-not-found-1.1.12-11.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.2.40.3/PackageKit-command-not-found-1.1.12-11.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="PackageKit-help" release="11.u1" version="1.1.12">
					<filename>PackageKit-help-1.1.12-11.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.3/PackageKit-help-1.1.12-11.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="PackageKit-devel" release="11.u1" version="1.1.12">
					<filename>PackageKit-devel-1.1.12-11.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.3/PackageKit-devel-1.1.12-11.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="PackageKit" release="11.u1" version="1.1.12">
					<filename>PackageKit-1.1.12-11.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.3/PackageKit-1.1.12-11.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="PackageKit-command-not-found" release="11.u1" version="1.1.12">
					<filename>PackageKit-command-not-found-1.1.12-11.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.2.40.3/PackageKit-command-not-found-1.1.12-11.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3121</id>
		<title>An update for audiofile is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13440&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-13440" id="CVE-2018-13440" title="CVE-2018-13440" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17095&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2018-17095" id="CVE-2018-17095" title="CVE-2018-17095" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24599&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-24599" id="CVE-2022-24599" title="CVE-2022-24599" type="cve"></reference>
		</references>
		<description>CVE-2018-13440:The audiofile Audio File Library 0.3.6 has a NULL pointer dereference bug in ModuleState::setup in modules/ModuleState.cpp, which allows an attacker to cause a denial of service via a crafted caf file, as demonstrated by sfconvert.&#xA;CVE-2018-17095:An issue has been discovered in mpruett Audio File Library (aka audiofile) 0.3.6, 0.3.5, 0.3.4, 0.3.3, 0.3.2, 0.3.1, 0.3.0. A heap-based buffer overflow in Expand3To4Module::run has occurred when running sfconvert.&#xA;CVE-2022-24599:In autofile Audio File Library 0.3.6, there exists one memory leak vulnerability in printfileinfo, in printinfo.c, which allows an attacker to leak sensitive information via a crafted file. The printfileinfo function calls the copyrightstring function to get data, however, it dosn&#39;t use zero bytes to truncate the data.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="audiofile" release="32.u3" version="0.3.6">
					<filename>audiofile-0.3.6-32.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/audiofile-0.3.6-32.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="audiofile-devel" release="32.u3" version="0.3.6">
					<filename>audiofile-devel-0.3.6-32.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/audiofile-devel-0.3.6-32.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="audiofile" release="32.u3" version="0.3.6">
					<filename>audiofile-0.3.6-32.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/audiofile-0.3.6-32.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="audiofile-devel" release="32.u3" version="0.3.6">
					<filename>audiofile-devel-0.3.6-32.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/audiofile-devel-0.3.6-32.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="audiofile-help" release="32.u3" version="0.3.6">
					<filename>audiofile-help-0.3.6-32.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/audiofile-help-0.3.6-32.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3122</id>
		<title>An update for libpq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2003&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2003" id="CVE-2026-2003" title="CVE-2026-2003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2004" id="CVE-2026-2004" title="CVE-2026-2004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2005" id="CVE-2026-2005" title="CVE-2026-2005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2006" id="CVE-2026-2006" title="CVE-2026-2006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2003&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2003" id="CVE-2026-2003" title="CVE-2026-2003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2004" id="CVE-2026-2004" title="CVE-2026-2004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2005" id="CVE-2026-2005" title="CVE-2026-2005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2006" id="CVE-2026-2006" title="CVE-2026-2006" type="cve"></reference>
		</references>
		<description>CVE-2026-2003:Improper validation of type &#34;oidvector&#34; in PostgreSQL allows a database user to disclose a few bytes of server memory.  We have not ruled out viability of attacks that arrange for presence of confidential information in disclosed bytes, but they seem unlikely.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2004:Missing validation of type of input in PostgreSQL intarray extension selectivity estimator function allows an object creator to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2005:Heap buffer overflow in PostgreSQL pgcrypto allows a ciphertext provider to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2006:Missing validation of multibyte character length in PostgreSQL text manipulation allows a database user to issue crafted queries that achieve a buffer overrun.  That suffices to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2003:Improper validation of type &#34;oidvector&#34; in PostgreSQL allows a database user to disclose a few bytes of server memory.  We have not ruled out viability of attacks that arrange for presence of confidential information in disclosed bytes, but they seem unlikely.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2004:Missing validation of type of input in PostgreSQL intarray extension selectivity estimator function allows an object creator to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2005:Heap buffer overflow in PostgreSQL pgcrypto allows a ciphertext provider to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2006:Missing validation of multibyte character length in PostgreSQL text manipulation allows a database user to issue crafted queries that achieve a buffer overrun.  That suffices to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libpq" release="1.u3" version="13.23">
					<filename>libpq-13.23-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libpq-13.23-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libpq-devel" release="1.u3" version="13.23">
					<filename>libpq-devel-13.23-1.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libpq-devel-13.23-1.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libpq" release="1.u3" version="13.23">
					<filename>libpq-13.23-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libpq-13.23-1.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libpq-devel" release="1.u3" version="13.23">
					<filename>libpq-devel-13.23-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libpq-devel-13.23-1.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3123</id>
		<title>An update for libgcrypt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41989&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41989" id="CVE-2026-41989" title="CVE-2026-41989" type="cve"></reference>
		</references>
		<description>CVE-2026-41989:Libgcrypt before 1.12.2 sometimes allows a heap-based buffer overflow and denial of service via crafted ECDH ciphertext to gcry_pk_decrypt.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libgcrypt" release="3.u1" version="1.10.2">
					<filename>libgcrypt-1.10.2-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libgcrypt-1.10.2-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgcrypt-devel" release="3.u1" version="1.10.2">
					<filename>libgcrypt-devel-1.10.2-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libgcrypt-devel-1.10.2-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgcrypt" release="3.u1" version="1.10.2">
					<filename>libgcrypt-1.10.2-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgcrypt-1.10.2-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgcrypt-devel" release="3.u1" version="1.10.2">
					<filename>libgcrypt-devel-1.10.2-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgcrypt-devel-1.10.2-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libgcrypt-help" release="3.u1" version="1.10.2">
					<filename>libgcrypt-help-1.10.2-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgcrypt-help-1.10.2-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3124</id>
		<title>An update for sqlite is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-70873&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-70873" id="CVE-2025-70873" title="CVE-2025-70873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-6965&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-6965" id="CVE-2025-6965" title="CVE-2025-6965" type="cve"></reference>
		</references>
		<description>CVE-2025-70873:An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.&#xA;CVE-2025-6965:There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="sqlite" release="8.u6" version="3.37.2">
					<filename>sqlite-3.37.2-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sqlite-3.37.2-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sqlite-devel" release="8.u6" version="3.37.2">
					<filename>sqlite-devel-3.37.2-8.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sqlite-devel-3.37.2-8.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite" release="8.u6" version="3.37.2">
					<filename>sqlite-3.37.2-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sqlite-3.37.2-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sqlite-devel" release="8.u6" version="3.37.2">
					<filename>sqlite-devel-3.37.2-8.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sqlite-devel-3.37.2-8.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sqlite-help" release="8.u6" version="3.37.2">
					<filename>sqlite-help-3.37.2-8.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sqlite-help-3.37.2-8.u6.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3125</id>
		<title>An update for gdk-pixbuf2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5201&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5201" id="CVE-2026-5201" title="CVE-2026-5201" type="cve"></reference>
		</references>
		<description>CVE-2026-5201:A flaw was found in the gdk-pixbuf library. This heap-based buffer overflow vulnerability occurs in the JPEG image loader due to improper validation of color component counts when processing a specially crafted JPEG image. A remote attacker can exploit this flaw without user interaction, for example, via thumbnail generation. Successful exploitation leads to application crashes and denial of service (DoS) conditions.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="gdk-pixbuf2-help" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-help-2.42.6-10.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gdk-pixbuf2-help-2.42.6-10.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-devel" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gdk-pixbuf2-devel-2.42.6-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-tests" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gdk-pixbuf2-tests-2.42.6-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gdk-pixbuf2-2.42.6-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gdk-pixbuf2-modules" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-10.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gdk-pixbuf2-modules-2.42.6-10.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-devel" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-devel-2.42.6-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gdk-pixbuf2-devel-2.42.6-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-modules" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-modules-2.42.6-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gdk-pixbuf2-modules-2.42.6-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-2.42.6-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gdk-pixbuf2-2.42.6-10.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gdk-pixbuf2-tests" release="10.u5" version="2.42.6">
					<filename>gdk-pixbuf2-tests-2.42.6-10.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gdk-pixbuf2-tests-2.42.6-10.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3126</id>
		<title>An update for libcap is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4878&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4878" id="CVE-2026-4878" title="CVE-2026-4878" type="cve"></reference>
		</references>
		<description>CVE-2026-4878:A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="libcap-devel" release="11.u7" version="2.61">
					<filename>libcap-devel-2.61-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libcap-devel-2.61-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcap" release="11.u7" version="2.61">
					<filename>libcap-2.61-11.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libcap-2.61-11.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcap" release="11.u7" version="2.61">
					<filename>libcap-2.61-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libcap-2.61-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcap-devel" release="11.u7" version="2.61">
					<filename>libcap-devel-2.61-11.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libcap-devel-2.61-11.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libcap-help" release="11.u7" version="2.61">
					<filename>libcap-help-2.61-11.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libcap-help-2.61-11.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3127</id>
		<title>An update for rsync is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41035" id="CVE-2026-41035" title="CVE-2026-41035" type="cve"></reference>
		</references>
		<description>CVE-2026-41035:In rsync 3.0.1 through 3.4.1, receive_xattr relies on an untrusted length value during a qsort call, leading to a receiver use-after-free. The victim must run rsync with -X (aka --xattrs). On Linux, many (but not all) common configurations are vulnerable. Non-Linux platforms are more widely vulnerable.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="rsync-help" release="6.u5" version="3.2.5">
					<filename>rsync-help-3.2.5-6.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/rsync-help-3.2.5-6.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="rsync" release="6.u5" version="3.2.5">
					<filename>rsync-3.2.5-6.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/rsync-3.2.5-6.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rsync" release="6.u5" version="3.2.5">
					<filename>rsync-3.2.5-6.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/rsync-3.2.5-6.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3128</id>
		<title>An update for OpenEXR is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27622&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27622" id="CVE-2026-27622" title="CVE-2026-27622" type="cve"></reference>
		</references>
		<description>CVE-2026-27622:OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&lt;unsigned int&gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32.  overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="OpenEXR" release="5.u4" version="3.1.5">
					<filename>OpenEXR-3.1.5-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/OpenEXR-3.1.5-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-devel" release="5.u4" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/OpenEXR-devel-3.1.5-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="OpenEXR-libs" release="5.u4" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/OpenEXR-libs-3.1.5-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-devel" release="5.u4" version="3.1.5">
					<filename>OpenEXR-devel-3.1.5-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/OpenEXR-devel-3.1.5-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR-libs" release="5.u4" version="3.1.5">
					<filename>OpenEXR-libs-3.1.5-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/OpenEXR-libs-3.1.5-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="OpenEXR" release="5.u4" version="3.1.5">
					<filename>OpenEXR-3.1.5-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/OpenEXR-3.1.5-5.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3129</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31648&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-31648" id="CVE-2025-31648" title="CVE-2025-31648" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-35979&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-35979" id="CVE-2025-35979" title="CVE-2025-35979" type="cve"></reference>
		</references>
		<description>CVE-2025-31648:Improper handling of values in the microcode flow for some Intel(R) Processor Family may allow an escalation of privilege. Startup code and smm adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (low), integrity (low) and availability (none) impacts.&#xA;CVE-2025-35979:Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel(R) Processors within VMX non-root (guest) operation may allow an information disclosure. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable data exposure. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (none) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (high), integrity (none) and availability (none) impacts.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="microcode_ctl" release="1.u3" version="20260512">
					<filename>microcode_ctl-20260512-1.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/microcode_ctl-20260512-1.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3130</id>
		<title>An update for jtidy is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34623&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-34623" id="CVE-2023-34623" title="CVE-2023-34623" type="cve"></reference>
		</references>
		<description>CVE-2023-34623:An issue was discovered jtidy thru r938 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="2" name="jtidy" release="0.30.20100930svn1125.u1" version="1.0">
					<filename>jtidy-1.0-0.30.20100930svn1125.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/jtidy-1.0-0.30.20100930svn1125.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="jtidy-help" release="0.30.20100930svn1125.u1" version="1.0">
					<filename>jtidy-help-1.0-0.30.20100930svn1125.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/jtidy-help-1.0-0.30.20100930svn1125.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3131</id>
		<title>An update for cups-filters is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-64524&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-64524" id="CVE-2025-64524" title="CVE-2025-64524" type="cve"></reference>
		</references>
		<description>CVE-2025-64524:cups-filters contains backends, filters, and other software required to get the cups printing service working on operating systems other than macos. In versions 2.0.1 and prior, a heap-buffer-overflow vulnerability in the rastertopclx filter causes the program to crash with a segmentation fault when processing maliciously crafted input data. This issue can be exploited to trigger memory corruption, potentially leading to arbitrary code execution. This issue has been patched via commit 956283c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="cups-filters-devel" release="7.u5" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-filters-devel-1.28.9-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters" release="7.u5" version="1.28.9">
					<filename>cups-filters-1.28.9-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-filters-1.28.9-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="cups-filters-help" release="7.u5" version="1.28.9">
					<filename>cups-filters-help-1.28.9-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-filters-help-1.28.9-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters" release="7.u5" version="1.28.9">
					<filename>cups-filters-1.28.9-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-filters-1.28.9-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters-devel" release="7.u5" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-filters-devel-1.28.9-7.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3132</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-7462&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-7462" id="CVE-2025-7462" title="CVE-2025-7462" type="cve"></reference>
		</references>
		<description>CVE-2025-7462:A vulnerability was found in Artifex GhostPDL up to 3989415a5b8e99b9d1b87cc9902bde9b7cdea145. It has been classified as problematic. This affects the function pdf_ferror of the file devices/vector/gdevpdf.c of the component New Output File Open Error Handler. The manipulation leads to null pointer dereference. It is possible to initiate the attack remotely. The identifier of the patch is 619a106ba4c4abed95110f84d5efcd7aee38c7cb. It is recommended to apply a patch to fix this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="23.u18" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-23.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ghostscript-devel-9.55.0-23.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="23.u18" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-23.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ghostscript-tools-dvipdf-9.55.0-23.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="23.u18" version="9.55.0">
					<filename>ghostscript-9.55.0-23.u18.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ghostscript-9.55.0-23.u18.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="23.u18" version="9.55.0">
					<filename>ghostscript-help-9.55.0-23.u18.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ghostscript-help-9.55.0-23.u18.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="23.u18" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-23.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ghostscript-devel-9.55.0-23.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="23.u18" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-23.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ghostscript-tools-dvipdf-9.55.0-23.u18.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript" release="23.u18" version="9.55.0">
					<filename>ghostscript-9.55.0-23.u18.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ghostscript-9.55.0-23.u18.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3133</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31466&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31466" id="CVE-2026-31466" title="CVE-2026-31466" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23290&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23290" id="CVE-2026-23290" title="CVE-2026-23290" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23401&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23401" id="CVE-2026-23401" title="CVE-2026-23401" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23318&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23318" id="CVE-2026-23318" title="CVE-2026-23318" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23364&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23364" id="CVE-2026-23364" title="CVE-2026-23364" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23268&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23268" id="CVE-2026-23268" title="CVE-2026-23268" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23405&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23405" id="CVE-2026-23405" title="CVE-2026-23405" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23208&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23208" id="CVE-2026-23208" title="CVE-2026-23208" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23404&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23404" id="CVE-2026-23404" title="CVE-2026-23404" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23408&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23408" id="CVE-2026-23408" title="CVE-2026-23408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31788&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31788" id="CVE-2026-31788" title="CVE-2026-31788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50300&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50300" id="CVE-2022-50300" title="CVE-2022-50300" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23406&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23406" id="CVE-2026-23406" title="CVE-2026-23406" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23452&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23452" id="CVE-2026-23452" title="CVE-2026-23452" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23407&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23407" id="CVE-2026-23407" title="CVE-2026-23407" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23410&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23410" id="CVE-2026-23410" title="CVE-2026-23410" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23171" id="CVE-2026-23171" title="CVE-2026-23171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23389&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23389" id="CVE-2026-23389" title="CVE-2026-23389" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23411&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23411" id="CVE-2026-23411" title="CVE-2026-23411" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31393&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31393" id="CVE-2026-31393" title="CVE-2026-31393" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31408&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31408" id="CVE-2026-31408" title="CVE-2026-31408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23269&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23269" id="CVE-2026-23269" title="CVE-2026-23269" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23253&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23253" id="CVE-2026-23253" title="CVE-2026-23253" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22980&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22980" id="CVE-2026-22980" title="CVE-2026-22980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50518&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50518" id="CVE-2022-50518" title="CVE-2022-50518" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39794&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39794" id="CVE-2025-39794" title="CVE-2025-39794" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40205&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40205" id="CVE-2025-40205" title="CVE-2025-40205" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39738&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39738" id="CVE-2025-39738" title="CVE-2025-39738" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39788&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39788" id="CVE-2025-39788" title="CVE-2025-39788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23271&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23271" id="CVE-2026-23271" title="CVE-2026-23271" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31402&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31402" id="CVE-2026-31402" title="CVE-2026-31402" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71078&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71078" id="CVE-2025-71078" title="CVE-2025-71078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23450&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23450" id="CVE-2026-23450" title="CVE-2026-23450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31426&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31426" id="CVE-2026-31426" title="CVE-2026-31426" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31392&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31392" id="CVE-2026-31392" title="CVE-2026-31392" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31473&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31473" id="CVE-2026-31473" title="CVE-2026-31473" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23383&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23383" id="CVE-2026-23383" title="CVE-2026-23383" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23099&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23099" id="CVE-2026-23099" title="CVE-2026-23099" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23351&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23351" id="CVE-2026-23351" title="CVE-2026-23351" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23274&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23274" id="CVE-2026-23274" title="CVE-2026-23274" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23391&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23391" id="CVE-2026-23391" title="CVE-2026-23391" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23340&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23340" id="CVE-2026-23340" title="CVE-2026-23340" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23272&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23272" id="CVE-2026-23272" title="CVE-2026-23272" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43033&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43033" id="CVE-2026-43033" title="CVE-2026-43033" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31677&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31677" id="CVE-2026-31677" title="CVE-2026-31677" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31515&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31515" id="CVE-2026-31515" title="CVE-2026-31515" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31504&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31504" id="CVE-2026-31504" title="CVE-2026-31504" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31431&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31431" id="CVE-2026-31431" title="CVE-2026-31431" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31570&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31570" id="CVE-2026-31570" title="CVE-2026-31570" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31682&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31682" id="CVE-2026-31682" title="CVE-2026-31682" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31680&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31680" id="CVE-2026-31680" title="CVE-2026-31680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31674&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31674" id="CVE-2026-31674" title="CVE-2026-31674" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31673&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31673" id="CVE-2026-31673" title="CVE-2026-31673" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31678" id="CVE-2026-31678" title="CVE-2026-31678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31405&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31405" id="CVE-2026-31405" title="CVE-2026-31405" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31588&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31588" id="CVE-2026-31588" title="CVE-2026-31588" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31602&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31602" id="CVE-2026-31602" title="CVE-2026-31602" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31449&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31449" id="CVE-2026-31449" title="CVE-2026-31449" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31450&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31450" id="CVE-2026-31450" title="CVE-2026-31450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31590&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31590" id="CVE-2026-31590" title="CVE-2026-31590" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43030&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43030" id="CVE-2026-43030" title="CVE-2026-43030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31560&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31560" id="CVE-2026-31560" title="CVE-2026-31560" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31787&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31787" id="CVE-2026-31787" title="CVE-2026-31787" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31448&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31448" id="CVE-2026-31448" title="CVE-2026-31448" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31523&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31523" id="CVE-2026-31523" title="CVE-2026-31523" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31476&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31476" id="CVE-2026-31476" title="CVE-2026-31476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31403&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31403" id="CVE-2026-31403" title="CVE-2026-31403" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31404&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31404" id="CVE-2026-31404" title="CVE-2026-31404" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31592&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31592" id="CVE-2026-31592" title="CVE-2026-31592" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31679&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31679" id="CVE-2026-31679" title="CVE-2026-31679" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31628&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31628" id="CVE-2026-31628" title="CVE-2026-31628" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31754&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31754" id="CVE-2026-31754" title="CVE-2026-31754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43079&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43079" id="CVE-2026-43079" title="CVE-2026-43079" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43124&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43124" id="CVE-2026-43124" title="CVE-2026-43124" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31555&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31555" id="CVE-2026-31555" title="CVE-2026-31555" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43284&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43284" id="CVE-2026-43284" title="CVE-2026-43284" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31697&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31697" id="CVE-2026-31697" title="CVE-2026-31697" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31419" id="CVE-2026-31419" title="CVE-2026-31419" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43407&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43407" id="CVE-2026-43407" title="CVE-2026-43407" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31781&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31781" id="CVE-2026-31781" title="CVE-2026-31781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31521&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31521" id="CVE-2026-31521" title="CVE-2026-31521" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23317&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23317" id="CVE-2026-23317" title="CVE-2026-23317" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31698&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31698" id="CVE-2026-31698" title="CVE-2026-31698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31699" id="CVE-2026-31699" title="CVE-2026-31699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31778" id="CVE-2026-31778" title="CVE-2026-31778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31441&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31441" id="CVE-2026-31441" title="CVE-2026-31441" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31630&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31630" id="CVE-2026-31630" title="CVE-2026-31630" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31667&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31667" id="CVE-2026-31667" title="CVE-2026-31667" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43171" id="CVE-2026-43171" title="CVE-2026-43171" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43049&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43049" id="CVE-2026-43049" title="CVE-2026-43049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31773&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31773" id="CVE-2026-31773" title="CVE-2026-31773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31619&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31619" id="CVE-2026-31619" title="CVE-2026-31619" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38685&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38685" id="CVE-2025-38685" title="CVE-2025-38685" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38680&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38680" id="CVE-2025-38680" title="CVE-2025-38680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43064" id="CVE-2026-43064" title="CVE-2026-43064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31777&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31777" id="CVE-2026-31777" title="CVE-2026-31777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31527&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31527" id="CVE-2026-31527" title="CVE-2026-31527" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43020" id="CVE-2026-43020" title="CVE-2026-43020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43047&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43047" id="CVE-2026-43047" title="CVE-2026-43047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43048&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43048" id="CVE-2026-43048" title="CVE-2026-43048" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31447&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31447" id="CVE-2026-31447" title="CVE-2026-31447" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31771&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31771" id="CVE-2026-31771" title="CVE-2026-31771" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31708&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31708" id="CVE-2026-31708" title="CVE-2026-31708" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31704&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31704" id="CVE-2026-31704" title="CVE-2026-31704" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31712&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31712" id="CVE-2026-31712" title="CVE-2026-31712" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46333&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46333" id="CVE-2026-46333" title="CVE-2026-46333" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31611" id="CVE-2026-31611" title="CVE-2026-31611" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31612&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31612" id="CVE-2026-31612" title="CVE-2026-31612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31477&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31477" id="CVE-2026-31477" title="CVE-2026-31477" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31755&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31755" id="CVE-2026-31755" title="CVE-2026-31755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43261&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43261" id="CVE-2026-43261" title="CVE-2026-43261" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43212" id="CVE-2026-43212" title="CVE-2026-43212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43488&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43488" id="CVE-2026-43488" title="CVE-2026-43488" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43427&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43427" id="CVE-2026-43427" title="CVE-2026-43427" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43428&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43428" id="CVE-2026-43428" title="CVE-2026-43428" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23395&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23395" id="CVE-2026-23395" title="CVE-2026-23395" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31668&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31668" id="CVE-2026-31668" title="CVE-2026-31668" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43134&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43134" id="CVE-2026-43134" title="CVE-2026-43134" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43281&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43281" id="CVE-2026-43281" title="CVE-2026-43281" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43117&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43117" id="CVE-2026-43117" title="CVE-2026-43117" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43493&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43493" id="CVE-2026-43493" title="CVE-2026-43493" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43040&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43040" id="CVE-2026-43040" title="CVE-2026-43040" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43038&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43038" id="CVE-2026-43038" title="CVE-2026-43038" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43037&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43037" id="CVE-2026-43037" title="CVE-2026-43037" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31729" id="CVE-2026-31729" title="CVE-2026-31729" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47452&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-47452" id="CVE-2021-47452" title="CVE-2021-47452" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47508&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2021-47508" id="CVE-2021-47508" title="CVE-2021-47508" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49046&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49046" id="CVE-2022-49046" title="CVE-2022-49046" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49063&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49063" id="CVE-2022-49063" title="CVE-2022-49063" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49106&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49106" id="CVE-2022-49106" title="CVE-2022-49106" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49110&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49110" id="CVE-2022-49110" title="CVE-2022-49110" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49112&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49112" id="CVE-2022-49112" title="CVE-2022-49112" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49123&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49123" id="CVE-2022-49123" title="CVE-2022-49123" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49134&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49134" id="CVE-2022-49134" title="CVE-2022-49134" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49161" id="CVE-2022-49161" title="CVE-2022-49161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49173&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49173" id="CVE-2022-49173" title="CVE-2022-49173" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49177" id="CVE-2022-49177" title="CVE-2022-49177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49178&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49178" id="CVE-2022-49178" title="CVE-2022-49178" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49201&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49201" id="CVE-2022-49201" title="CVE-2022-49201" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49226&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49226" id="CVE-2022-49226" title="CVE-2022-49226" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49311&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49311" id="CVE-2022-49311" title="CVE-2022-49311" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49398&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49398" id="CVE-2022-49398" title="CVE-2022-49398" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49509&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49509" id="CVE-2022-49509" title="CVE-2022-49509" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49533&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49533" id="CVE-2022-49533" title="CVE-2022-49533" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49546&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49546" id="CVE-2022-49546" title="CVE-2022-49546" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49557&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49557" id="CVE-2022-49557" title="CVE-2022-49557" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49563&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49563" id="CVE-2022-49563" title="CVE-2022-49563" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49566&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49566" id="CVE-2022-49566" title="CVE-2022-49566" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49616&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49616" id="CVE-2022-49616" title="CVE-2022-49616" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49617&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49617" id="CVE-2022-49617" title="CVE-2022-49617" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49654&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49654" id="CVE-2022-49654" title="CVE-2022-49654" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49743&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49743" id="CVE-2022-49743" title="CVE-2022-49743" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49758&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49758" id="CVE-2022-49758" title="CVE-2022-49758" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49828&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49828" id="CVE-2022-49828" title="CVE-2022-49828" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49938&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-49938" id="CVE-2022-49938" title="CVE-2022-49938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50011&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50011" id="CVE-2022-50011" title="CVE-2022-50011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50056&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50056" id="CVE-2022-50056" title="CVE-2022-50056" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50073&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50073" id="CVE-2022-50073" title="CVE-2022-50073" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50111&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50111" id="CVE-2022-50111" title="CVE-2022-50111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50262&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50262" id="CVE-2022-50262" title="CVE-2022-50262" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50336&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50336" id="CVE-2022-50336" title="CVE-2022-50336" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50451&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50451" id="CVE-2022-50451" title="CVE-2022-50451" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50516" id="CVE-2022-50516" title="CVE-2022-50516" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50720&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50720" id="CVE-2022-50720" title="CVE-2022-50720" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-50764&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2022-50764" id="CVE-2022-50764" title="CVE-2022-50764" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-0160" id="CVE-2023-0160" title="CVE-2023-0160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24023&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-24023" id="CVE-2023-24023" title="CVE-2023-24023" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53002&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53002" id="CVE-2023-53002" title="CVE-2023-53002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53008&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53008" id="CVE-2023-53008" title="CVE-2023-53008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53110&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53110" id="CVE-2023-53110" title="CVE-2023-53110" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53125" id="CVE-2023-53125" title="CVE-2023-53125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53163&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53163" id="CVE-2023-53163" title="CVE-2023-53163" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53188&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53188" id="CVE-2023-53188" title="CVE-2023-53188" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53194&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53194" id="CVE-2023-53194" title="CVE-2023-53194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53265&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53265" id="CVE-2023-53265" title="CVE-2023-53265" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53294&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53294" id="CVE-2023-53294" title="CVE-2023-53294" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53328&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53328" id="CVE-2023-53328" title="CVE-2023-53328" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53335&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53335" id="CVE-2023-53335" title="CVE-2023-53335" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53476&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53476" id="CVE-2023-53476" title="CVE-2023-53476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53482&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53482" id="CVE-2023-53482" title="CVE-2023-53482" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53682&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53682" id="CVE-2023-53682" title="CVE-2023-53682" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53732&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53732" id="CVE-2023-53732" title="CVE-2023-53732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53998&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-53998" id="CVE-2023-53998" title="CVE-2023-53998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54020" id="CVE-2023-54020" title="CVE-2023-54020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54177" id="CVE-2023-54177" title="CVE-2023-54177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54181" id="CVE-2023-54181" title="CVE-2023-54181" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-54207&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-54207" id="CVE-2023-54207" title="CVE-2023-54207" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23848&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-23848" id="CVE-2024-23848" title="CVE-2024-23848" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25741&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-25741" id="CVE-2024-25741" title="CVE-2024-25741" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26861&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-26861" id="CVE-2024-26861" title="CVE-2024-26861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27078&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-27078" id="CVE-2024-27078" title="CVE-2024-27078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39493&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-39493" id="CVE-2024-39493" title="CVE-2024-39493" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43098&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43098" id="CVE-2024-43098" title="CVE-2024-43098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43835&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-43835" id="CVE-2024-43835" title="CVE-2024-43835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46763&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46763" id="CVE-2024-46763" title="CVE-2024-46763" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46783&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46783" id="CVE-2024-46783" title="CVE-2024-46783" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46810&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46810" id="CVE-2024-46810" title="CVE-2024-46810" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46832&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-46832" id="CVE-2024-46832" title="CVE-2024-46832" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47143&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47143" id="CVE-2024-47143" title="CVE-2024-47143" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47706&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-47706" id="CVE-2024-47706" title="CVE-2024-47706" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-48881&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-48881" id="CVE-2024-48881" title="CVE-2024-48881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49851&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49851" id="CVE-2024-49851" title="CVE-2024-49851" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49890&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49890" id="CVE-2024-49890" title="CVE-2024-49890" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49935" id="CVE-2024-49935" title="CVE-2024-49935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49962&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-49962" id="CVE-2024-49962" title="CVE-2024-49962" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50096" id="CVE-2024-50096" title="CVE-2024-50096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50117&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50117" id="CVE-2024-50117" title="CVE-2024-50117" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50167&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50167" id="CVE-2024-50167" title="CVE-2024-50167" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50168" id="CVE-2024-50168" title="CVE-2024-50168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50295&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50295" id="CVE-2024-50295" title="CVE-2024-50295" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50304&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-50304" id="CVE-2024-50304" title="CVE-2024-50304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52332&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-52332" id="CVE-2024-52332" title="CVE-2024-52332" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53103&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53103" id="CVE-2024-53103" title="CVE-2024-53103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53119&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53119" id="CVE-2024-53119" title="CVE-2024-53119" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53121&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53121" id="CVE-2024-53121" title="CVE-2024-53121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53124&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53124" id="CVE-2024-53124" title="CVE-2024-53124" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53138&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53138" id="CVE-2024-53138" title="CVE-2024-53138" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53140&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53140" id="CVE-2024-53140" title="CVE-2024-53140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53145&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53145" id="CVE-2024-53145" title="CVE-2024-53145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53157" id="CVE-2024-53157" title="CVE-2024-53157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53164&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53164" id="CVE-2024-53164" title="CVE-2024-53164" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53174&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53174" id="CVE-2024-53174" title="CVE-2024-53174" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53181&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53181" id="CVE-2024-53181" title="CVE-2024-53181" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53184&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53184" id="CVE-2024-53184" title="CVE-2024-53184" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53680&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-53680" id="CVE-2024-53680" title="CVE-2024-53680" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-55916&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-55916" id="CVE-2024-55916" title="CVE-2024-55916" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56369&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56369" id="CVE-2024-56369" title="CVE-2024-56369" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56531&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56531" id="CVE-2024-56531" title="CVE-2024-56531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56532&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56532" id="CVE-2024-56532" title="CVE-2024-56532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56568&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56568" id="CVE-2024-56568" title="CVE-2024-56568" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56574&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56574" id="CVE-2024-56574" title="CVE-2024-56574" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56576&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56576" id="CVE-2024-56576" title="CVE-2024-56576" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56587&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56587" id="CVE-2024-56587" title="CVE-2024-56587" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56593&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56593" id="CVE-2024-56593" title="CVE-2024-56593" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56603&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56603" id="CVE-2024-56603" title="CVE-2024-56603" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56636&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56636" id="CVE-2024-56636" title="CVE-2024-56636" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56637&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56637" id="CVE-2024-56637" title="CVE-2024-56637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56643&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56643" id="CVE-2024-56643" title="CVE-2024-56643" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56644&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56644" id="CVE-2024-56644" title="CVE-2024-56644" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56645&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56645" id="CVE-2024-56645" title="CVE-2024-56645" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56659&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56659" id="CVE-2024-56659" title="CVE-2024-56659" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56670&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56670" id="CVE-2024-56670" title="CVE-2024-56670" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56694&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56694" id="CVE-2024-56694" title="CVE-2024-56694" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56698&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56698" id="CVE-2024-56698" title="CVE-2024-56698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56720&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56720" id="CVE-2024-56720" title="CVE-2024-56720" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56724" id="CVE-2024-56724" title="CVE-2024-56724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56767&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56767" id="CVE-2024-56767" title="CVE-2024-56767" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56769&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56769" id="CVE-2024-56769" title="CVE-2024-56769" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56770&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56770" id="CVE-2024-56770" title="CVE-2024-56770" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56785&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-56785" id="CVE-2024-56785" title="CVE-2024-56785" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57802&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57802" id="CVE-2024-57802" title="CVE-2024-57802" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57807&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57807" id="CVE-2024-57807" title="CVE-2024-57807" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57834&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57834" id="CVE-2024-57834" title="CVE-2024-57834" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57874&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57874" id="CVE-2024-57874" title="CVE-2024-57874" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57884&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57884" id="CVE-2024-57884" title="CVE-2024-57884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57889&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57889" id="CVE-2024-57889" title="CVE-2024-57889" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57922&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57922" id="CVE-2024-57922" title="CVE-2024-57922" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57938&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57938" id="CVE-2024-57938" title="CVE-2024-57938" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57940&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57940" id="CVE-2024-57940" title="CVE-2024-57940" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57946&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57946" id="CVE-2024-57946" title="CVE-2024-57946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57948&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57948" id="CVE-2024-57948" title="CVE-2024-57948" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57973&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57973" id="CVE-2024-57973" title="CVE-2024-57973" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57981&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57981" id="CVE-2024-57981" title="CVE-2024-57981" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57986&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-57986" id="CVE-2024-57986" title="CVE-2024-57986" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58005" id="CVE-2024-58005" title="CVE-2024-58005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58010&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58010" id="CVE-2024-58010" title="CVE-2024-58010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58014" id="CVE-2024-58014" title="CVE-2024-58014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58016&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58016" id="CVE-2024-58016" title="CVE-2024-58016" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58017&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58017" id="CVE-2024-58017" title="CVE-2024-58017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58020" id="CVE-2024-58020" title="CVE-2024-58020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58051&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58051" id="CVE-2024-58051" title="CVE-2024-58051" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58071&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58071" id="CVE-2024-58071" title="CVE-2024-58071" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58085" id="CVE-2024-58085" title="CVE-2024-58085" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58090&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58090" id="CVE-2024-58090" title="CVE-2024-58090" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58239&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-58239" id="CVE-2024-58239" title="CVE-2024-58239" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21638&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21638" id="CVE-2025-21638" title="CVE-2025-21638" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21639&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21639" id="CVE-2025-21639" title="CVE-2025-21639" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21640&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21640" id="CVE-2025-21640" title="CVE-2025-21640" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21646&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21646" id="CVE-2025-21646" title="CVE-2025-21646" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21653&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21653" id="CVE-2025-21653" title="CVE-2025-21653" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21664&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21664" id="CVE-2025-21664" title="CVE-2025-21664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21681&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21681" id="CVE-2025-21681" title="CVE-2025-21681" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21683&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21683" id="CVE-2025-21683" title="CVE-2025-21683" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21689&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21689" id="CVE-2025-21689" title="CVE-2025-21689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21699" id="CVE-2025-21699" title="CVE-2025-21699" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21708&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21708" id="CVE-2025-21708" title="CVE-2025-21708" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21711&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21711" id="CVE-2025-21711" title="CVE-2025-21711" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21734&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21734" id="CVE-2025-21734" title="CVE-2025-21734" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21736&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21736" id="CVE-2025-21736" title="CVE-2025-21736" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21744&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21744" id="CVE-2025-21744" title="CVE-2025-21744" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21745&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21745" id="CVE-2025-21745" title="CVE-2025-21745" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21749&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21749" id="CVE-2025-21749" title="CVE-2025-21749" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21753&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21753" id="CVE-2025-21753" title="CVE-2025-21753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21765&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21765" id="CVE-2025-21765" title="CVE-2025-21765" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21776&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21776" id="CVE-2025-21776" title="CVE-2025-21776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21796&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21796" id="CVE-2025-21796" title="CVE-2025-21796" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21799&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21799" id="CVE-2025-21799" title="CVE-2025-21799" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21806&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21806" id="CVE-2025-21806" title="CVE-2025-21806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21814&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21814" id="CVE-2025-21814" title="CVE-2025-21814" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21826&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21826" id="CVE-2025-21826" title="CVE-2025-21826" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21835&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21835" id="CVE-2025-21835" title="CVE-2025-21835" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21844&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21844" id="CVE-2025-21844" title="CVE-2025-21844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21846&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21846" id="CVE-2025-21846" title="CVE-2025-21846" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21848&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21848" id="CVE-2025-21848" title="CVE-2025-21848" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21853&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21853" id="CVE-2025-21853" title="CVE-2025-21853" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21859" id="CVE-2025-21859" title="CVE-2025-21859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21862&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21862" id="CVE-2025-21862" title="CVE-2025-21862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21871&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21871" id="CVE-2025-21871" title="CVE-2025-21871" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21872&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21872" id="CVE-2025-21872" title="CVE-2025-21872" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21878&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21878" id="CVE-2025-21878" title="CVE-2025-21878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21904&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21904" id="CVE-2025-21904" title="CVE-2025-21904" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21909&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21909" id="CVE-2025-21909" title="CVE-2025-21909" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21910&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21910" id="CVE-2025-21910" title="CVE-2025-21910" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21917&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21917" id="CVE-2025-21917" title="CVE-2025-21917" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21925&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21925" id="CVE-2025-21925" title="CVE-2025-21925" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21948&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21948" id="CVE-2025-21948" title="CVE-2025-21948" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21956&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21956" id="CVE-2025-21956" title="CVE-2025-21956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21957&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21957" id="CVE-2025-21957" title="CVE-2025-21957" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21959&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21959" id="CVE-2025-21959" title="CVE-2025-21959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21971&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21971" id="CVE-2025-21971" title="CVE-2025-21971" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21975&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21975" id="CVE-2025-21975" title="CVE-2025-21975" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21992&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21992" id="CVE-2025-21992" title="CVE-2025-21992" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21996&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21996" id="CVE-2025-21996" title="CVE-2025-21996" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22005" id="CVE-2025-22005" title="CVE-2025-22005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22007&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22007" id="CVE-2025-22007" title="CVE-2025-22007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22008&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22008" id="CVE-2025-22008" title="CVE-2025-22008" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22014" id="CVE-2025-22014" title="CVE-2025-22014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22021&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22021" id="CVE-2025-22021" title="CVE-2025-22021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22027&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22027" id="CVE-2025-22027" title="CVE-2025-22027" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22028&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22028" id="CVE-2025-22028" title="CVE-2025-22028" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22044&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22044" id="CVE-2025-22044" title="CVE-2025-22044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22045&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22045" id="CVE-2025-22045" title="CVE-2025-22045" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22054&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22054" id="CVE-2025-22054" title="CVE-2025-22054" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22055&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22055" id="CVE-2025-22055" title="CVE-2025-22055" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22086&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22086" id="CVE-2025-22086" title="CVE-2025-22086" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22103&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22103" id="CVE-2025-22103" title="CVE-2025-22103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22104&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-22104" id="CVE-2025-22104" title="CVE-2025-22104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23131&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23131" id="CVE-2025-23131" title="CVE-2025-23131" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23136&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23136" id="CVE-2025-23136" title="CVE-2025-23136" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23140&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23140" id="CVE-2025-23140" title="CVE-2025-23140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23143&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23143" id="CVE-2025-23143" title="CVE-2025-23143" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23147&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23147" id="CVE-2025-23147" title="CVE-2025-23147" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23157&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23157" id="CVE-2025-23157" title="CVE-2025-23157" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23159&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23159" id="CVE-2025-23159" title="CVE-2025-23159" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-23161" id="CVE-2025-23161" title="CVE-2025-23161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37739&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37739" id="CVE-2025-37739" title="CVE-2025-37739" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37756&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37756" id="CVE-2025-37756" title="CVE-2025-37756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37757&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37757" id="CVE-2025-37757" title="CVE-2025-37757" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37758&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37758" id="CVE-2025-37758" title="CVE-2025-37758" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37765&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37765" id="CVE-2025-37765" title="CVE-2025-37765" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37781&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37781" id="CVE-2025-37781" title="CVE-2025-37781" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37788&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37788" id="CVE-2025-37788" title="CVE-2025-37788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37792&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37792" id="CVE-2025-37792" title="CVE-2025-37792" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37794&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37794" id="CVE-2025-37794" title="CVE-2025-37794" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37803&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37803" id="CVE-2025-37803" title="CVE-2025-37803" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37808&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37808" id="CVE-2025-37808" title="CVE-2025-37808" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37817&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37817" id="CVE-2025-37817" title="CVE-2025-37817" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37830&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37830" id="CVE-2025-37830" title="CVE-2025-37830" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37833&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37833" id="CVE-2025-37833" title="CVE-2025-37833" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37836&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37836" id="CVE-2025-37836" title="CVE-2025-37836" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37838&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37838" id="CVE-2025-37838" title="CVE-2025-37838" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37840&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37840" id="CVE-2025-37840" title="CVE-2025-37840" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37842&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37842" id="CVE-2025-37842" title="CVE-2025-37842" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37844&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37844" id="CVE-2025-37844" title="CVE-2025-37844" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37850&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37850" id="CVE-2025-37850" title="CVE-2025-37850" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37851&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37851" id="CVE-2025-37851" title="CVE-2025-37851" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37857" id="CVE-2025-37857" title="CVE-2025-37857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37859" id="CVE-2025-37859" title="CVE-2025-37859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37862&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37862" id="CVE-2025-37862" title="CVE-2025-37862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37867&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37867" id="CVE-2025-37867" title="CVE-2025-37867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37878&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37878" id="CVE-2025-37878" title="CVE-2025-37878" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37892&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37892" id="CVE-2025-37892" title="CVE-2025-37892" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37909&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37909" id="CVE-2025-37909" title="CVE-2025-37909" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37914&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37914" id="CVE-2025-37914" title="CVE-2025-37914" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37930&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37930" id="CVE-2025-37930" title="CVE-2025-37930" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37932&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37932" id="CVE-2025-37932" title="CVE-2025-37932" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37959&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37959" id="CVE-2025-37959" title="CVE-2025-37959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37961&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37961" id="CVE-2025-37961" title="CVE-2025-37961" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37967&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37967" id="CVE-2025-37967" title="CVE-2025-37967" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37969&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37969" id="CVE-2025-37969" title="CVE-2025-37969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37970&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37970" id="CVE-2025-37970" title="CVE-2025-37970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37983&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37983" id="CVE-2025-37983" title="CVE-2025-37983" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37989&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37989" id="CVE-2025-37989" title="CVE-2025-37989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37990&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37990" id="CVE-2025-37990" title="CVE-2025-37990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37991&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37991" id="CVE-2025-37991" title="CVE-2025-37991" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37998&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-37998" id="CVE-2025-37998" title="CVE-2025-37998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38003&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38003" id="CVE-2025-38003" title="CVE-2025-38003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38034" id="CVE-2025-38034" title="CVE-2025-38034" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38037&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38037" id="CVE-2025-38037" title="CVE-2025-38037" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38040&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38040" id="CVE-2025-38040" title="CVE-2025-38040" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38044&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38044" id="CVE-2025-38044" title="CVE-2025-38044" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38057&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38057" id="CVE-2025-38057" title="CVE-2025-38057" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38058" id="CVE-2025-38058" title="CVE-2025-38058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38061&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38061" id="CVE-2025-38061" title="CVE-2025-38061" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38066&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38066" id="CVE-2025-38066" title="CVE-2025-38066" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38075&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38075" id="CVE-2025-38075" title="CVE-2025-38075" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38083" id="CVE-2025-38083" title="CVE-2025-38083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38094&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38094" id="CVE-2025-38094" title="CVE-2025-38094" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38100&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38100" id="CVE-2025-38100" title="CVE-2025-38100" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38107&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38107" id="CVE-2025-38107" title="CVE-2025-38107" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38120&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38120" id="CVE-2025-38120" title="CVE-2025-38120" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38147&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38147" id="CVE-2025-38147" title="CVE-2025-38147" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38153&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38153" id="CVE-2025-38153" title="CVE-2025-38153" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38161" id="CVE-2025-38161" title="CVE-2025-38161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38163&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38163" id="CVE-2025-38163" title="CVE-2025-38163" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38166&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38166" id="CVE-2025-38166" title="CVE-2025-38166" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38167&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38167" id="CVE-2025-38167" title="CVE-2025-38167" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38190&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38190" id="CVE-2025-38190" title="CVE-2025-38190" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38197&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38197" id="CVE-2025-38197" title="CVE-2025-38197" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38200&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38200" id="CVE-2025-38200" title="CVE-2025-38200" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38206&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38206" id="CVE-2025-38206" title="CVE-2025-38206" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38214&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38214" id="CVE-2025-38214" title="CVE-2025-38214" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38237" id="CVE-2025-38237" title="CVE-2025-38237" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38249&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38249" id="CVE-2025-38249" title="CVE-2025-38249" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38251&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38251" id="CVE-2025-38251" title="CVE-2025-38251" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38312&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38312" id="CVE-2025-38312" title="CVE-2025-38312" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38326&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38326" id="CVE-2025-38326" title="CVE-2025-38326" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38334&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38334" id="CVE-2025-38334" title="CVE-2025-38334" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38344&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38344" id="CVE-2025-38344" title="CVE-2025-38344" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38348&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38348" id="CVE-2025-38348" title="CVE-2025-38348" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38363&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38363" id="CVE-2025-38363" title="CVE-2025-38363" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38377&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38377" id="CVE-2025-38377" title="CVE-2025-38377" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38393&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38393" id="CVE-2025-38393" title="CVE-2025-38393" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38401&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38401" id="CVE-2025-38401" title="CVE-2025-38401" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38403&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38403" id="CVE-2025-38403" title="CVE-2025-38403" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38430&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38430" id="CVE-2025-38430" title="CVE-2025-38430" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38458&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38458" id="CVE-2025-38458" title="CVE-2025-38458" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38460&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38460" id="CVE-2025-38460" title="CVE-2025-38460" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38462&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38462" id="CVE-2025-38462" title="CVE-2025-38462" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38468&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38468" id="CVE-2025-38468" title="CVE-2025-38468" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38473&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38473" id="CVE-2025-38473" title="CVE-2025-38473" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38476&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38476" id="CVE-2025-38476" title="CVE-2025-38476" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38482&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38482" id="CVE-2025-38482" title="CVE-2025-38482" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38483&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38483" id="CVE-2025-38483" title="CVE-2025-38483" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38515&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38515" id="CVE-2025-38515" title="CVE-2025-38515" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38516&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38516" id="CVE-2025-38516" title="CVE-2025-38516" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38530&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38530" id="CVE-2025-38530" title="CVE-2025-38530" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38540&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38540" id="CVE-2025-38540" title="CVE-2025-38540" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38553&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38553" id="CVE-2025-38553" title="CVE-2025-38553" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38581&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38581" id="CVE-2025-38581" title="CVE-2025-38581" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38591&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38591" id="CVE-2025-38591" title="CVE-2025-38591" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38608&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38608" id="CVE-2025-38608" title="CVE-2025-38608" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38622&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38622" id="CVE-2025-38622" title="CVE-2025-38622" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38623&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38623" id="CVE-2025-38623" title="CVE-2025-38623" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38635&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38635" id="CVE-2025-38635" title="CVE-2025-38635" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38637&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38637" id="CVE-2025-38637" title="CVE-2025-38637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38639&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38639" id="CVE-2025-38639" title="CVE-2025-38639" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38668&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38668" id="CVE-2025-38668" title="CVE-2025-38668" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38678&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38678" id="CVE-2025-38678" title="CVE-2025-38678" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38691" id="CVE-2025-38691" title="CVE-2025-38691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38694&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38694" id="CVE-2025-38694" title="CVE-2025-38694" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38696&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38696" id="CVE-2025-38696" title="CVE-2025-38696" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38701&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38701" id="CVE-2025-38701" title="CVE-2025-38701" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38708&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38708" id="CVE-2025-38708" title="CVE-2025-38708" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-38721&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-38721" id="CVE-2025-38721" title="CVE-2025-38721" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39703&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39703" id="CVE-2025-39703" title="CVE-2025-39703" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39713&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39713" id="CVE-2025-39713" title="CVE-2025-39713" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39714&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39714" id="CVE-2025-39714" title="CVE-2025-39714" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39724" id="CVE-2025-39724" title="CVE-2025-39724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39726&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39726" id="CVE-2025-39726" title="CVE-2025-39726" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39728" id="CVE-2025-39728" title="CVE-2025-39728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39730&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39730" id="CVE-2025-39730" title="CVE-2025-39730" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39742&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39742" id="CVE-2025-39742" title="CVE-2025-39742" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39760&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39760" id="CVE-2025-39760" title="CVE-2025-39760" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39764&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39764" id="CVE-2025-39764" title="CVE-2025-39764" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39782" id="CVE-2025-39782" title="CVE-2025-39782" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39787&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39787" id="CVE-2025-39787" title="CVE-2025-39787" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39808&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39808" id="CVE-2025-39808" title="CVE-2025-39808" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39812&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39812" id="CVE-2025-39812" title="CVE-2025-39812" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39824&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39824" id="CVE-2025-39824" title="CVE-2025-39824" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39833&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39833" id="CVE-2025-39833" title="CVE-2025-39833" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39846&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39846" id="CVE-2025-39846" title="CVE-2025-39846" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39847&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39847" id="CVE-2025-39847" title="CVE-2025-39847" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39885&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39885" id="CVE-2025-39885" title="CVE-2025-39885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39891&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39891" id="CVE-2025-39891" title="CVE-2025-39891" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39894&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39894" id="CVE-2025-39894" title="CVE-2025-39894" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39920&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39920" id="CVE-2025-39920" title="CVE-2025-39920" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39923&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39923" id="CVE-2025-39923" title="CVE-2025-39923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39937&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39937" id="CVE-2025-39937" title="CVE-2025-39937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39953&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39953" id="CVE-2025-39953" title="CVE-2025-39953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39955&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39955" id="CVE-2025-39955" title="CVE-2025-39955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39964" id="CVE-2025-39964" title="CVE-2025-39964" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39972&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39972" id="CVE-2025-39972" title="CVE-2025-39972" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39980&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39980" id="CVE-2025-39980" title="CVE-2025-39980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-39996&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-39996" id="CVE-2025-39996" title="CVE-2025-39996" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40006" id="CVE-2025-40006" title="CVE-2025-40006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40011&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40011" id="CVE-2025-40011" title="CVE-2025-40011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40020&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40020" id="CVE-2025-40020" title="CVE-2025-40020" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40030&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40030" id="CVE-2025-40030" title="CVE-2025-40030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40035&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40035" id="CVE-2025-40035" title="CVE-2025-40035" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40053&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40053" id="CVE-2025-40053" title="CVE-2025-40053" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40064&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40064" id="CVE-2025-40064" title="CVE-2025-40064" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40078&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40078" id="CVE-2025-40078" title="CVE-2025-40078" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40083" id="CVE-2025-40083" title="CVE-2025-40083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40109&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40109" id="CVE-2025-40109" title="CVE-2025-40109" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40121&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40121" id="CVE-2025-40121" title="CVE-2025-40121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40125" id="CVE-2025-40125" title="CVE-2025-40125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40134&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40134" id="CVE-2025-40134" title="CVE-2025-40134" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40140&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40140" id="CVE-2025-40140" title="CVE-2025-40140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40153&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40153" id="CVE-2025-40153" title="CVE-2025-40153" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40154&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40154" id="CVE-2025-40154" title="CVE-2025-40154" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40167&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40167" id="CVE-2025-40167" title="CVE-2025-40167" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40173&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40173" id="CVE-2025-40173" title="CVE-2025-40173" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40187&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40187" id="CVE-2025-40187" title="CVE-2025-40187" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40198&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40198" id="CVE-2025-40198" title="CVE-2025-40198" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40219&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40219" id="CVE-2025-40219" title="CVE-2025-40219" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40220&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40220" id="CVE-2025-40220" title="CVE-2025-40220" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40233&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40233" id="CVE-2025-40233" title="CVE-2025-40233" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40240&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40240" id="CVE-2025-40240" title="CVE-2025-40240" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40248&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40248" id="CVE-2025-40248" title="CVE-2025-40248" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40253&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40253" id="CVE-2025-40253" title="CVE-2025-40253" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40254&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40254" id="CVE-2025-40254" title="CVE-2025-40254" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40262&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40262" id="CVE-2025-40262" title="CVE-2025-40262" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40263&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40263" id="CVE-2025-40263" title="CVE-2025-40263" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40264&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40264" id="CVE-2025-40264" title="CVE-2025-40264" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40275&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40275" id="CVE-2025-40275" title="CVE-2025-40275" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40277&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40277" id="CVE-2025-40277" title="CVE-2025-40277" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40281&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40281" id="CVE-2025-40281" title="CVE-2025-40281" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40283&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40283" id="CVE-2025-40283" title="CVE-2025-40283" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40308&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40308" id="CVE-2025-40308" title="CVE-2025-40308" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40317&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40317" id="CVE-2025-40317" title="CVE-2025-40317" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40331&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40331" id="CVE-2025-40331" title="CVE-2025-40331" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40345&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40345" id="CVE-2025-40345" title="CVE-2025-40345" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40349&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40349" id="CVE-2025-40349" title="CVE-2025-40349" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40351&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40351" id="CVE-2025-40351" title="CVE-2025-40351" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40363&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40363" id="CVE-2025-40363" title="CVE-2025-40363" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68168" id="CVE-2025-68168" title="CVE-2025-68168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68176&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68176" id="CVE-2025-68176" title="CVE-2025-68176" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68191&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68191" id="CVE-2025-68191" title="CVE-2025-68191" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68194&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68194" id="CVE-2025-68194" title="CVE-2025-68194" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68204" id="CVE-2025-68204" title="CVE-2025-68204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68206&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68206" id="CVE-2025-68206" title="CVE-2025-68206" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68220&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68220" id="CVE-2025-68220" title="CVE-2025-68220" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68261&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68261" id="CVE-2025-68261" title="CVE-2025-68261" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68264&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68264" id="CVE-2025-68264" title="CVE-2025-68264" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68295&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68295" id="CVE-2025-68295" title="CVE-2025-68295" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68302&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68302" id="CVE-2025-68302" title="CVE-2025-68302" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68303&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68303" id="CVE-2025-68303" title="CVE-2025-68303" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68308&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68308" id="CVE-2025-68308" title="CVE-2025-68308" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68312&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68312" id="CVE-2025-68312" title="CVE-2025-68312" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68321&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68321" id="CVE-2025-68321" title="CVE-2025-68321" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68324&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68324" id="CVE-2025-68324" title="CVE-2025-68324" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68328&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68328" id="CVE-2025-68328" title="CVE-2025-68328" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68330&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68330" id="CVE-2025-68330" title="CVE-2025-68330" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68331&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68331" id="CVE-2025-68331" title="CVE-2025-68331" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68337&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68337" id="CVE-2025-68337" title="CVE-2025-68337" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68340&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68340" id="CVE-2025-68340" title="CVE-2025-68340" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68346&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68346" id="CVE-2025-68346" title="CVE-2025-68346" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68362&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68362" id="CVE-2025-68362" title="CVE-2025-68362" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68364&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68364" id="CVE-2025-68364" title="CVE-2025-68364" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68367&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68367" id="CVE-2025-68367" title="CVE-2025-68367" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68372&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68372" id="CVE-2025-68372" title="CVE-2025-68372" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68724&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68724" id="CVE-2025-68724" title="CVE-2025-68724" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68725&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68725" id="CVE-2025-68725" title="CVE-2025-68725" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68771&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68771" id="CVE-2025-68771" title="CVE-2025-68771" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68783&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68783" id="CVE-2025-68783" title="CVE-2025-68783" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68788&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68788" id="CVE-2025-68788" title="CVE-2025-68788" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68813&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68813" id="CVE-2025-68813" title="CVE-2025-68813" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68818&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68818" id="CVE-2025-68818" title="CVE-2025-68818" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71089&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71089" id="CVE-2025-71089" title="CVE-2025-71089" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71096" id="CVE-2025-71096" title="CVE-2025-71096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71097&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71097" id="CVE-2025-71097" title="CVE-2025-71097" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71098&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71098" id="CVE-2025-71098" title="CVE-2025-71098" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71109&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71109" id="CVE-2025-71109" title="CVE-2025-71109" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71111&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71111" id="CVE-2025-71111" title="CVE-2025-71111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71114&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71114" id="CVE-2025-71114" title="CVE-2025-71114" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71116&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71116" id="CVE-2025-71116" title="CVE-2025-71116" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71118&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71118" id="CVE-2025-71118" title="CVE-2025-71118" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71145&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71145" id="CVE-2025-71145" title="CVE-2025-71145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71154&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71154" id="CVE-2025-71154" title="CVE-2025-71154" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71161&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71161" id="CVE-2025-71161" title="CVE-2025-71161" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71186&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71186" id="CVE-2025-71186" title="CVE-2025-71186" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71224&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71224" id="CVE-2025-71224" title="CVE-2025-71224" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-71235&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-71235" id="CVE-2025-71235" title="CVE-2025-71235" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22976&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22976" id="CVE-2026-22976" title="CVE-2026-22976" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22977&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22977" id="CVE-2026-22977" title="CVE-2026-22977" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22978&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22978" id="CVE-2026-22978" title="CVE-2026-22978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22991&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22991" id="CVE-2026-22991" title="CVE-2026-22991" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23011&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23011" id="CVE-2026-23011" title="CVE-2026-23011" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23021&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23021" id="CVE-2026-23021" title="CVE-2026-23021" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23047&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23047" id="CVE-2026-23047" title="CVE-2026-23047" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23058&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23058" id="CVE-2026-23058" title="CVE-2026-23058" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23071&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23071" id="CVE-2026-23071" title="CVE-2026-23071" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23076&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23076" id="CVE-2026-23076" title="CVE-2026-23076" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23080&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23080" id="CVE-2026-23080" title="CVE-2026-23080" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23083" id="CVE-2026-23083" title="CVE-2026-23083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23084&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23084" id="CVE-2026-23084" title="CVE-2026-23084" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23089&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23089" id="CVE-2026-23089" title="CVE-2026-23089" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23093&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23093" id="CVE-2026-23093" title="CVE-2026-23093" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23095&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23095" id="CVE-2026-23095" title="CVE-2026-23095" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23096&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23096" id="CVE-2026-23096" title="CVE-2026-23096" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23101&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23101" id="CVE-2026-23101" title="CVE-2026-23101" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23103&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23103" id="CVE-2026-23103" title="CVE-2026-23103" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23105&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23105" id="CVE-2026-23105" title="CVE-2026-23105" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23108&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23108" id="CVE-2026-23108" title="CVE-2026-23108" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23110&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23110" id="CVE-2026-23110" title="CVE-2026-23110" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23113&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23113" id="CVE-2026-23113" title="CVE-2026-23113" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23119&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23119" id="CVE-2026-23119" title="CVE-2026-23119" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23120&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23120" id="CVE-2026-23120" title="CVE-2026-23120" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23121&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23121" id="CVE-2026-23121" title="CVE-2026-23121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23125&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23125" id="CVE-2026-23125" title="CVE-2026-23125" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23133&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23133" id="CVE-2026-23133" title="CVE-2026-23133" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23137&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23137" id="CVE-2026-23137" title="CVE-2026-23137" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23141&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23141" id="CVE-2026-23141" title="CVE-2026-23141" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23144&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23144" id="CVE-2026-23144" title="CVE-2026-23144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23164&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23164" id="CVE-2026-23164" title="CVE-2026-23164" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23190&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23190" id="CVE-2026-23190" title="CVE-2026-23190" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23193&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23193" id="CVE-2026-23193" title="CVE-2026-23193" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23221&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23221" id="CVE-2026-23221" title="CVE-2026-23221" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23222&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23222" id="CVE-2026-23222" title="CVE-2026-23222" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23229&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23229" id="CVE-2026-23229" title="CVE-2026-23229" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23236&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23236" id="CVE-2026-23236" title="CVE-2026-23236" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-23237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-23237" id="CVE-2026-23237" title="CVE-2026-23237" type="cve"></reference>
		</references>
		<description>CVE-2026-31466:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/huge_memory: fix folio isn&#39;t locked in softleaf_to_folio()&#xA;&#xA;On arm64 server, we found folio that get from migration entry isn&#39;t locked&#xA;in softleaf_to_folio().  This issue triggers when mTHP splitting and&#xA;zap_nonpresent_ptes() races, and the root cause is lack of memory barrier&#xA;in softleaf_to_folio().  The race is as follows:&#xA;&#xA;&#x9;CPU0                                             CPU1&#xA;&#xA;deferred_split_scan()                              zap_nonpresent_ptes()&#xA;  lock folio&#xA;  split_folio()&#xA;    unmap_folio()&#xA;      change ptes to migration entries&#xA;    __split_folio_to_order()                         softleaf_to_folio()&#xA;      set flags(including PG_locked) for tail pages    folio = pfn_folio(softleaf_to_pfn(entry))&#xA;      smp_wmb()                                        VM_WARN_ON_ONCE(!folio_test_locked(folio))&#xA;      prep_compound_page() for tail pages&#xA;&#xA;In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages&#xA;are visible before the tail page becomes non-compound.  smp_wmb() should&#xA;be paired with smp_rmb() in softleaf_to_folio(), which is missed.  As a&#xA;result, if zap_nonpresent_ptes() accesses migration entry that stores tail&#xA;pfn, softleaf_to_folio() may see the updated compound_head of tail page&#xA;before page-&gt;flags.&#xA;&#xA;This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()&#xA;because of the race between folio split and zap_nonpresent_ptes()&#xA;leading to a folio incorrectly undergoing modification without a folio&#xA;lock being held.&#xA;&#xA;This is a BUG_ON() before commit 93976a20345b (&#34;mm: eliminate further&#xA;swapops predicates&#34;), which in merged in v6.19-rc1.&#xA;&#xA;To fix it, add missing smp_rmb() if the softleaf entry is migration entry&#xA;in softleaf_to_folio() and softleaf_to_page().&#xA;&#xA;[[email protected]: update function name and comments]&#xA;CVE-2026-23290:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: pegasus: validate USB endpoints&#xA;&#xA;The pegasus driver should validate that the device it is probing has the&#xA;proper number and types of USB endpoints it is expecting before it binds&#xA;to it.  If a malicious device were to not have the same urbs the driver&#xA;will crash later on when it blindly accesses these endpoints.&#xA;CVE-2026-23401:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE&#xA;&#xA;When installing an emulated MMIO SPTE, do so *after* dropping/zapping the&#xA;existing SPTE (if it&#39;s shadow-present).  While commit a54aa15c6bda3 was&#xA;right about it being impossible to convert a shadow-present SPTE to an&#xA;MMIO SPTE due to a _guest_ write, it failed to account for writes to guest&#xA;memory that are outside the scope of KVM.&#xA;&#xA;E.g. if host userspace modifies a shadowed gPTE to switch from a memslot&#xA;to emulted MMIO and then the guest hits a relevant page fault, KVM will&#xA;install the MMIO SPTE without first zapping the shadow-present SPTE.&#xA;&#xA;  ------------[ cut here ]------------&#xA;  is_shadow_present_pte(*sptep)&#xA;  WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292&#xA;  Modules linked in: kvm_intel kvm irqbypass&#xA;  CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT&#xA;  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015&#xA;  RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   mmu_set_spte+0x237/0x440 [kvm]&#xA;   ept_page_fault+0x535/0x7f0 [kvm]&#xA;   kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]&#xA;   kvm_mmu_page_fault+0x8d/0x620 [kvm]&#xA;   vmx_handle_exit+0x18c/0x5a0 [kvm_intel]&#xA;   kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm]&#xA;   kvm_vcpu_ioctl+0x2d5/0x980 [kvm]&#xA;   __x64_sys_ioctl+0x8a/0xd0&#xA;   do_syscall_64+0xb5/0x730&#xA;   entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;  RIP: 0033:0x47fa3f&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;CVE-2026-23318:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Use correct version for UAC3 header validation&#xA;&#xA;The entry of the validators table for UAC3 AC header descriptor is&#xA;defined with the wrong protocol version UAC_VERSION_2, while it should&#xA;have been UAC_VERSION_3.  This results in the validator never matching&#xA;for actual UAC3 devices (protocol == UAC_VERSION_3), causing their&#xA;header descriptors to bypass validation entirely.  A malicious USB&#xA;device presenting a truncated UAC3 header could exploit this to cause&#xA;out-of-bounds reads when the driver later accesses unvalidated&#xA;descriptor fields.&#xA;&#xA;The bug was introduced in the same commit as the recently fixed UAC3&#xA;feature unit sub-type typo, and appears to be from the same copy-paste&#xA;error when the UAC3 section was created from the UAC2 section.&#xA;CVE-2026-23364:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: Compare MACs in constant time&#xA;&#xA;To prevent timing attacks, MAC comparisons need to be constant-time.&#xA;Replace the memcmp() with the correct function, crypto_memneq().&#xA;CVE-2026-23268:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: fix unprivileged local user can do privileged policy management&#xA;&#xA;An unprivileged local user can load, replace, and remove profiles by&#xA;opening the apparmorfs interfaces, via a confused deputy attack, by&#xA;passing the opened fd to a privileged process, and getting the&#xA;privileged process to write to the interface.&#xA;&#xA;This does require a privileged target that can be manipulated to do&#xA;the write for the unprivileged process, but once such access is&#xA;achieved full policy management is possible and all the possible&#xA;implications that implies: removing confinement, DoS of system or&#xA;target applications by denying all execution, by-passing the&#xA;unprivileged user namespace restriction, to exploiting kernel bugs for&#xA;a local privilege escalation.&#xA;&#xA;The policy management interface can not have its permissions simply&#xA;changed from 0666 to 0600 because non-root processes need to be able&#xA;to load policy to different policy namespaces.&#xA;&#xA;Instead ensure the task writing the interface has privileges that&#xA;are a subset of the task that opened the interface. This is already&#xA;done via policy for confined processes, but unconfined can delegate&#xA;access to the opened fd, by-passing the usual policy check.&#xA;CVE-2026-23405:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: fix: limit the number of levels of policy namespaces&#xA;&#xA;Currently the number of policy namespaces is not bounded relying on&#xA;the user namespace limit. However policy namespaces aren&#39;t strictly&#xA;tied to user namespaces and it is possible to create them and nest&#xA;them arbitrarily deep which can be used to exhaust system resource.&#xA;&#xA;Hard cap policy namespaces to the same depth as user namespaces.&#xA;CVE-2026-23208:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Prevent excessive number of frames&#xA;&#xA;In this case, the user constructed the parameters with maxpacksize 40&#xA;for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer&#xA;size for each data URB is maxpacksize * packets, which in this example&#xA;is 40 * 6 = 240; When the user performs a write operation to send audio&#xA;data into the ALSA PCM playback stream, the calculated number of frames&#xA;is packsize[0] * packets = 264, which exceeds the allocated URB buffer&#xA;size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].&#xA;&#xA;Added a check for the number of single data URB frames when calculating&#xA;the number of frames to prevent [1].&#xA;&#xA;[1]&#xA;BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487&#xA;Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506&#xA;Call Trace:&#xA; copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487&#xA; prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611&#xA; prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333&#xA;CVE-2026-23404:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: replace recursive profile removal with iterative approach&#xA;&#xA;The profile removal code uses recursion when removing nested profiles,&#xA;which can lead to kernel stack exhaustion and system crashes.&#xA;&#xA;Reproducer:&#xA;  $ pf=&#39;a&#39;; for ((i=0; i&lt;1024; i++)); do&#xA;      echo -e &#34;profile $pf { \n }&#34; | apparmor_parser -K -a;&#xA;      pf=&#34;$pf//x&#34;;&#xA;  done&#xA;  $ echo -n a &gt; /sys/kernel/security/apparmor/.remove&#xA;&#xA;Replace the recursive __aa_profile_list_release() approach with an&#xA;iterative approach in __remove_profile(). The function repeatedly&#xA;finds and removes leaf profiles until the entire subtree is removed,&#xA;maintaining the same removal semantic without recursion.&#xA;CVE-2026-23408:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: Fix double free of ns_name in aa_replace_profiles()&#xA;&#xA;if ns_name is NULL after&#xA;1071         error = aa_unpack(udata, &amp;lh, &amp;ns_name);&#xA;&#xA;and if ent-&gt;ns_name contains an ns_name in&#xA;1089                 } else if (ent-&gt;ns_name) {&#xA;&#xA;then ns_name is assigned the ent-&gt;ns_name&#xA;1095                         ns_name = ent-&gt;ns_name;&#xA;&#xA;however ent-&gt;ns_name is freed at&#xA;1262                 aa_load_ent_free(ent);&#xA;&#xA;and then again when freeing ns_name at&#xA;1270         kfree(ns_name);&#xA;&#xA;Fix this by NULLing out ent-&gt;ns_name after it is transferred to ns_name&#xA;&#xA;&#34;)&#xA;CVE-2026-31788:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xen/privcmd: restrict usage in unprivileged domU&#xA;&#xA;The Xen privcmd driver allows to issue arbitrary hypercalls from&#xA;user space processes. This is normally no problem, as access is&#xA;usually limited to root and the hypervisor will deny any hypercalls&#xA;affecting other domains.&#xA;&#xA;In case the guest is booted using secure boot, however, the privcmd&#xA;driver would be enabling a root user process to modify e.g. kernel&#xA;memory contents, thus breaking the secure boot feature.&#xA;&#xA;The only known case where an unprivileged domU is really needing to&#xA;use the privcmd driver is the case when it is acting as the device&#xA;model for another guest. In this case all hypercalls issued via the&#xA;privcmd driver will target that other guest.&#xA;&#xA;Fortunately the privcmd driver can already be locked down to allow&#xA;only hypercalls targeting a specific domain, but this mode can be&#xA;activated from user land only today.&#xA;&#xA;The target domain can be obtained from Xenstore, so when not running&#xA;in dom0 restrict the privcmd driver to that target domain from the&#xA;beginning, resolving the potential problem of breaking secure boot.&#xA;&#xA;This is XSA-482&#xA;&#xA;---&#xA;V2:&#xA;- defer reading from Xenstore if Xenstore isn&#39;t ready yet (Jan Beulich)&#xA;- wait in open() if target domain isn&#39;t known yet&#xA;- issue message in case no target domain found (Jan Beulich)&#xA;CVE-2022-50300:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: fix extent map use-after-free when handling missing device in read_one_chunk&#xA;&#xA;Store the error code before freeing the extent_map. Though it&#39;s&#xA;reference counted structure, in that function it&#39;s the first and last&#xA;allocation so this would lead to a potential use-after-free.&#xA;&#xA;The error can happen eg. when chunk is stored on a missing device and&#xA;the degraded mount option is missing.&#xA;&#xA;Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721&#xA;CVE-2026-23406:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: fix side-effect bug in match_char() macro usage&#xA;&#xA;The match_char() macro evaluates its character parameter multiple&#xA;times when traversing differential encoding chains. When invoked&#xA;with *str++, the string pointer advances on each iteration of the&#xA;inner do-while loop, causing the DFA to check different characters&#xA;at each iteration and therefore skip input characters.&#xA;This results in out-of-bounds reads when the pointer advances past&#xA;the input buffer boundary.&#xA;&#xA;[   94.984676] ==================================================================&#xA;[   94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760&#xA;[   94.985655] Read of size 1 at addr ffff888100342000 by task file/976&#xA;&#xA;[   94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)&#xA;[   94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   94.986329] Call Trace:&#xA;[   94.986341]  &lt;TASK&gt;&#xA;[   94.986347]  dump_stack_lvl+0x5e/0x80&#xA;[   94.986374]  print_report+0xc8/0x270&#xA;[   94.986384]  ? aa_dfa_match+0x5ae/0x760&#xA;[   94.986388]  kasan_report+0x118/0x150&#xA;[   94.986401]  ? aa_dfa_match+0x5ae/0x760&#xA;[   94.986405]  aa_dfa_match+0x5ae/0x760&#xA;[   94.986408]  __aa_path_perm+0x131/0x400&#xA;[   94.986418]  aa_path_perm+0x219/0x2f0&#xA;[   94.986424]  apparmor_file_open+0x345/0x570&#xA;[   94.986431]  security_file_open+0x5c/0x140&#xA;[   94.986442]  do_dentry_open+0x2f6/0x1120&#xA;[   94.986450]  vfs_open+0x38/0x2b0&#xA;[   94.986453]  ? may_open+0x1e2/0x2b0&#xA;[   94.986466]  path_openat+0x231b/0x2b30&#xA;[   94.986469]  ? __x64_sys_openat+0xf8/0x130&#xA;[   94.986477]  do_file_open+0x19d/0x360&#xA;[   94.986487]  do_sys_openat2+0x98/0x100&#xA;[   94.986491]  __x64_sys_openat+0xf8/0x130&#xA;[   94.986499]  do_syscall_64+0x8e/0x660&#xA;[   94.986515]  ? count_memcg_events+0x15f/0x3c0&#xA;[   94.986526]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   94.986540]  ? handle_mm_fault+0x1639/0x1ef0&#xA;[   94.986551]  ? vma_start_read+0xf0/0x320&#xA;[   94.986558]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   94.986561]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   94.986563]  ? fpregs_assert_state_consistent+0x50/0xe0&#xA;[   94.986572]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   94.986574]  ? arch_exit_to_user_mode_prepare+0x9/0xb0&#xA;[   94.986587]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   94.986588]  ? irqentry_exit+0x3c/0x590&#xA;[   94.986595]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[   94.986597] RIP: 0033:0x7fda4a79c3ea&#xA;&#xA;Fix by extracting the character value before invoking match_char,&#xA;ensuring single evaluation per outer loop.&#xA;CVE-2026-23452:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PM: runtime: Fix a race condition related to device removal&#xA;&#xA;The following code in pm_runtime_work() may dereference the dev-&gt;parent&#xA;pointer after the parent device has been freed:&#xA;&#xA;&#x9;/* Maybe the parent is now able to suspend. */&#xA;&#x9;if (parent &amp;&amp; !parent-&gt;power.ignore_children) {&#xA;&#x9;&#x9;spin_unlock(&amp;dev-&gt;power.lock);&#xA;&#xA;&#x9;&#x9;spin_lock(&amp;parent-&gt;power.lock);&#xA;&#x9;&#x9;rpm_idle(parent, RPM_ASYNC);&#xA;&#x9;&#x9;spin_unlock(&amp;parent-&gt;power.lock);&#xA;&#xA;&#x9;&#x9;spin_lock(&amp;dev-&gt;power.lock);&#xA;&#x9;}&#xA;&#xA;Fix this by inserting a flush_work() call in pm_runtime_remove().&#xA;&#xA;Without this patch blktest block/001 triggers the following complaint&#xA;sporadically:&#xA;&#xA;BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160&#xA;Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081&#xA;Workqueue: pm pm_runtime_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x61/0x80&#xA; print_address_description.constprop.0+0x8b/0x310&#xA; print_report+0xfd/0x1d7&#xA; kasan_report+0xd8/0x1d0&#xA; __kasan_check_byte+0x42/0x60&#xA; lock_acquire.part.0+0x38/0x230&#xA; lock_acquire+0x70/0x160&#xA; _raw_spin_lock+0x36/0x50&#xA; rpm_suspend+0xc6a/0xfe0&#xA; rpm_idle+0x578/0x770&#xA; pm_runtime_work+0xee/0x120&#xA; process_one_work+0xde3/0x1410&#xA; worker_thread+0x5eb/0xfe0&#xA; kthread+0x37b/0x480&#xA; ret_from_fork+0x6cb/0x920&#xA; ret_from_fork_asm+0x11/0x20&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 4314:&#xA; kasan_save_stack+0x2a/0x50&#xA; kasan_save_track+0x18/0x40&#xA; kasan_save_alloc_info+0x3d/0x50&#xA; __kasan_kmalloc+0xa0/0xb0&#xA; __kmalloc_noprof+0x311/0x990&#xA; scsi_alloc_target+0x122/0xb60 [scsi_mod]&#xA; __scsi_scan_target+0x101/0x460 [scsi_mod]&#xA; scsi_scan_channel+0x179/0x1c0 [scsi_mod]&#xA; scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]&#xA; store_scan+0x2d2/0x390 [scsi_mod]&#xA; dev_attr_store+0x43/0x80&#xA; sysfs_kf_write+0xde/0x140&#xA; kernfs_fop_write_iter+0x3ef/0x670&#xA; vfs_write+0x506/0x1470&#xA; ksys_write+0xfd/0x230&#xA; __x64_sys_write+0x76/0xc0&#xA; x64_sys_call+0x213/0x1810&#xA; do_syscall_64+0xee/0xfc0&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;Freed by task 4314:&#xA; kasan_save_stack+0x2a/0x50&#xA; kasan_save_track+0x18/0x40&#xA; kasan_save_free_info+0x3f/0x50&#xA; __kasan_slab_free+0x67/0x80&#xA; kfree+0x225/0x6c0&#xA; scsi_target_dev_release+0x3d/0x60 [scsi_mod]&#xA; device_release+0xa3/0x220&#xA; kobject_cleanup+0x105/0x3a0&#xA; kobject_put+0x72/0xd0&#xA; put_device+0x17/0x20&#xA; scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]&#xA; device_release+0xa3/0x220&#xA; kobject_cleanup+0x105/0x3a0&#xA; kobject_put+0x72/0xd0&#xA; put_device+0x17/0x20&#xA; scsi_device_put+0x7f/0xc0 [scsi_mod]&#xA; sdev_store_delete+0xa5/0x120 [scsi_mod]&#xA; dev_attr_store+0x43/0x80&#xA; sysfs_kf_write+0xde/0x140&#xA; kernfs_fop_write_iter+0x3ef/0x670&#xA; vfs_write+0x506/0x1470&#xA; ksys_write+0xfd/0x230&#xA; __x64_sys_write+0x76/0xc0&#xA; x64_sys_call+0x213/0x1810&#xA;CVE-2026-23407:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: fix missing bounds check on DEFAULT table in verify_dfa()&#xA;&#xA;The verify_dfa() function only checks DEFAULT_TABLE bounds when the state&#xA;is not differentially encoded.&#xA;&#xA;When the verification loop traverses the differential encoding chain,&#xA;it reads k = DEFAULT_TABLE[j] and uses k as an array index without&#xA;validation. A malformed DFA with DEFAULT_TABLE[j] &gt;= state_count,&#xA;therefore, causes both out-of-bounds reads and writes.&#xA;&#xA;[   57.179855] ==================================================================&#xA;[   57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660&#xA;[   57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993&#xA;&#xA;[   57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)&#xA;[   57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   57.181563] Call Trace:&#xA;[   57.181572]  &lt;TASK&gt;&#xA;[   57.181577]  dump_stack_lvl+0x5e/0x80&#xA;[   57.181596]  print_report+0xc8/0x270&#xA;[   57.181605]  ? verify_dfa+0x59a/0x660&#xA;[   57.181608]  kasan_report+0x118/0x150&#xA;[   57.181620]  ? verify_dfa+0x59a/0x660&#xA;[   57.181623]  verify_dfa+0x59a/0x660&#xA;[   57.181627]  aa_dfa_unpack+0x1610/0x1740&#xA;[   57.181629]  ? __kmalloc_cache_noprof+0x1d0/0x470&#xA;[   57.181640]  unpack_pdb+0x86d/0x46b0&#xA;[   57.181647]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   57.181653]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   57.181656]  ? aa_unpack_nameX+0x1a8/0x300&#xA;[   57.181659]  aa_unpack+0x20b0/0x4c30&#xA;[   57.181662]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   57.181664]  ? stack_depot_save_flags+0x33/0x700&#xA;[   57.181681]  ? kasan_save_track+0x4f/0x80&#xA;[   57.181683]  ? kasan_save_track+0x3e/0x80&#xA;[   57.181686]  ? __kasan_kmalloc+0x93/0xb0&#xA;[   57.181688]  ? __kvmalloc_node_noprof+0x44a/0x780&#xA;[   57.181693]  ? aa_simple_write_to_buffer+0x54/0x130&#xA;[   57.181697]  ? policy_update+0x154/0x330&#xA;[   57.181704]  aa_replace_profiles+0x15a/0x1dd0&#xA;[   57.181707]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   57.181710]  ? __kvmalloc_node_noprof+0x44a/0x780&#xA;[   57.181712]  ? aa_loaddata_alloc+0x77/0x140&#xA;[   57.181715]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[   57.181717]  ? _copy_from_user+0x2a/0x70&#xA;[   57.181730]  policy_update+0x17a/0x330&#xA;[   57.181733]  profile_replace+0x153/0x1a0&#xA;[   57.181735]  ? rw_verify_area+0x93/0x2d0&#xA;[   57.181740]  vfs_write+0x235/0xab0&#xA;[   57.181745]  ksys_write+0xb0/0x170&#xA;[   57.181748]  do_syscall_64+0x8e/0x660&#xA;[   57.181762]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[   57.181765] RIP: 0033:0x7f6192792eb2&#xA;&#xA;Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE&#xA;entries unconditionally.&#xA;CVE-2026-23410:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: fix race on rawdata dereference&#xA;&#xA;There is a race condition that leads to a use-after-free situation:&#xA;because the rawdata inodes are not refcounted, an attacker can start&#xA;open()ing one of the rawdata files, and at the same time remove the&#xA;last reference to this rawdata (by removing the corresponding profile,&#xA;for example), which frees its struct aa_loaddata; as a result, when&#xA;seq_rawdata_open() is reached, i_private is a dangling pointer and&#xA;freed memory is accessed.&#xA;&#xA;The rawdata inodes weren&#39;t refcounted to avoid a circular refcount and&#xA;were supposed to be held by the profile rawdata reference.  However&#xA;during profile removal there is a window where the vfs and profile&#xA;destruction race, resulting in the use after free.&#xA;&#xA;Fix this by moving to a double refcount scheme. Where the profile&#xA;refcount on rawdata is used to break the circular dependency. Allowing&#xA;for freeing of the rawdata once all inode references to the rawdata&#xA;are put.&#xA;CVE-2026-23171:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bonding: fix use-after-free due to enslave fail after slave array update&#xA;&#xA;Fix a use-after-free which happens due to enslave failure after the new&#xA;slave has been added to the array. Since the new slave can be used for Tx&#xA;immediately, we can use it after it has been freed by the enslave error&#xA;cleanup path which frees the allocated slave memory. Slave update array is&#xA;supposed to be called last when further enslave failures are not expected.&#xA;Move it after xdp setup to avoid any problems.&#xA;&#xA;It is very easy to reproduce the problem with a simple xdp_pass prog:&#xA; ip l add bond1 type bond mode balance-xor&#xA; ip l set bond1 up&#xA; ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass&#xA; ip l add dumdum type dummy&#xA;&#xA;Then run in parallel:&#xA; while :; do ip l set dumdum master bond1 1&gt;/dev/null 2&gt;&amp;1; done;&#xA; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp &#34;dp=1-1023, flags=syn&#34;&#xA;&#xA;The crash happens almost immediately:&#xA; [  605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI&#xA; [  605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]&#xA; [  605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G    B               6.19.0-rc6+ #21 PREEMPT(voluntary)&#xA; [  605.602979] Tainted: [B]=BAD_PAGE&#xA; [  605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA; [  605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210&#xA; [  605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89&#xA; [  605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213&#xA; [  605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000&#xA; [  605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be&#xA; [  605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c&#xA; [  605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000&#xA; [  605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84&#xA; [  605.603286] FS:  00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000&#xA; [  605.603319] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; [  605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0&#xA; [  605.603373] Call Trace:&#xA; [  605.603392]  &lt;TASK&gt;&#xA; [  605.603410]  __dev_queue_xmit+0x448/0x32a0&#xA; [  605.603434]  ? __pfx_vprintk_emit+0x10/0x10&#xA; [  605.603461]  ? __pfx_vprintk_emit+0x10/0x10&#xA; [  605.603484]  ? __pfx___dev_queue_xmit+0x10/0x10&#xA; [  605.603507]  ? bond_start_xmit+0xbfb/0xc20 [bonding]&#xA; [  605.603546]  ? _printk+0xcb/0x100&#xA; [  605.603566]  ? __pfx__printk+0x10/0x10&#xA; [  605.603589]  ? bond_start_xmit+0xbfb/0xc20 [bonding]&#xA; [  605.603627]  ? add_taint+0x5e/0x70&#xA; [  605.603648]  ? add_taint+0x2a/0x70&#xA; [  605.603670]  ? end_report.cold+0x51/0x75&#xA; [  605.603693]  ? bond_start_xmit+0xbfb/0xc20 [bonding]&#xA; [  605.603731]  bond_start_xmit+0x623/0xc20 [bonding]&#xA;CVE-2026-23389:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ice: Fix memory leak in ice_set_ringparam()&#xA;&#xA;In ice_set_ringparam, tx_rings and xdp_rings are allocated before&#xA;rx_rings. If the allocation of rx_rings fails, the code jumps to&#xA;the done label leaking both tx_rings and xdp_rings. Furthermore, if&#xA;the setup of an individual Rx ring fails during the loop, the code jumps&#xA;to the free_tx label which releases tx_rings but leaks xdp_rings.&#xA;&#xA;Fix this by introducing a free_xdp label and updating the error paths to&#xA;ensure both xdp_rings and tx_rings are properly freed if rx_rings&#xA;allocation or setup fails.&#xA;&#xA;Compile tested only. Issue found using a prototype static analysis tool&#xA;and code review.&#xA;CVE-2026-23411:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: fix race between freeing data and fs accessing it&#xA;&#xA;AppArmor was putting the reference to i_private data on its end after&#xA;removing the original entry from the file system. However the inode&#xA;can aand does live beyond that point and it is possible that some of&#xA;the fs call back functions will be invoked after the reference has&#xA;been put, which results in a race between freeing the data and&#xA;accessing it through the fs.&#xA;&#xA;While the rawdata/loaddata is the most likely candidate to fail the&#xA;race, as it has the fewest references. If properly crafted it might be&#xA;possible to trigger a race for the other types stored in i_private.&#xA;&#xA;Fix this by moving the put of i_private referenced data to the correct&#xA;place which is during inode eviction.&#xA;CVE-2026-31393:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access&#xA;&#xA;l2cap_information_rsp() checks that cmd_len covers the fixed&#xA;l2cap_info_rsp header (type + result, 4 bytes) but then reads&#xA;rsp-&gt;data without verifying that the payload is present:&#xA;&#xA; - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-&gt;data), which reads&#xA;   4 bytes past the header (needs cmd_len &gt;= 8).&#xA;&#xA; - L2CAP_IT_FIXED_CHAN reads rsp-&gt;data[0], 1 byte past the header&#xA;   (needs cmd_len &gt;= 5).&#xA;&#xA;A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an&#xA;out-of-bounds read of adjacent skb data.&#xA;&#xA;Guard each data access with the required payload length check.  If the&#xA;payload is too short, skip the read and let the state machine complete&#xA;with safe defaults (feat_mask and remote_fixed_chan remain zero from&#xA;kzalloc), so the info timer cleanup and l2cap_conn_start() still run&#xA;and the connection is not stalled.&#xA;CVE-2026-31408:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold&#xA;&#xA;sco_recv_frame() reads conn-&gt;sk under sco_conn_lock() but immediately&#xA;releases the lock without holding a reference to the socket. A concurrent&#xA;close() can free the socket between the lock release and the subsequent&#xA;sk-&gt;sk_state access, resulting in a use-after-free.&#xA;&#xA;Other functions in the same file (sco_sock_timeout(), sco_conn_del())&#xA;correctly use sco_sock_hold() to safely hold a reference under the lock.&#xA;&#xA;Fix by using sco_sock_hold() to take a reference before releasing the&#xA;lock, and adding sock_put() on all exit paths.&#xA;CVE-2026-23269:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;apparmor: validate DFA start states are in bounds in unpack_pdb&#xA;&#xA;Start states are read from untrusted data and used as indexes into the&#xA;DFA state tables. The aa_dfa_next() function call in unpack_pdb() will&#xA;access dfa-&gt;tables[YYTD_ID_BASE][start], and if the start state exceeds&#xA;the number of states in the DFA, this results in an out-of-bound read.&#xA;&#xA;==================================================================&#xA; BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360&#xA; Read of size 4 at addr ffff88811956fb90 by task su/1097&#xA; ...&#xA;&#xA;Reject policies with out-of-bounds start states during unpacking&#xA;to prevent the issue.&#xA;CVE-2026-23253:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: dvb-core: fix wrong reinitialization of ringbuffer on reopen&#xA;&#xA;dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the&#xA;DVR device.  dvb_ringbuffer_init() calls init_waitqueue_head(), which&#xA;reinitializes the waitqueue list head to empty.&#xA;&#xA;Since dmxdev-&gt;dvr_buffer.queue is a shared waitqueue (all opens of the&#xA;same DVR device share it), this orphans any existing waitqueue entries&#xA;from io_uring poll or epoll, leaving them with stale prev/next pointers&#xA;while the list head is reset to {self, self}.&#xA;&#xA;The waitqueue and spinlock in dvr_buffer are already properly&#xA;initialized once in dvb_dmxdev_init().  The open path only needs to&#xA;reset the buffer data pointer, size, and read/write positions.&#xA;&#xA;Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct&#xA;assignment of data/size and a call to dvb_ringbuffer_reset(), which&#xA;properly resets pread, pwrite, and error with correct memory ordering&#xA;without touching the waitqueue or spinlock.&#xA;CVE-2026-22980:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: provide locking for v4_end_grace&#xA;&#xA;Writing to v4_end_grace can race with server shutdown and result in&#xA;memory being accessed after it was freed - reclaim_str_hashtbl in&#xA;particularly.&#xA;&#xA;We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is&#xA;held while client_tracking_op-&gt;init() is called and that can wait for&#xA;an upcall to nfsdcltrack which can write to v4_end_grace, resulting in a&#xA;deadlock.&#xA;&#xA;nfsd4_end_grace() is also called by the landromat work queue and this&#xA;doesn&#39;t require locking as server shutdown will stop the work and wait&#xA;for it before freeing anything that nfsd4_end_grace() might access.&#xA;&#xA;However, we must be sure that writing to v4_end_grace doesn&#39;t restart&#xA;the work item after shutdown has already waited for it.  For this we&#xA;add a new flag protected with nn-&gt;client_lock.  It is set only while it&#xA;is safe to make client tracking calls, and v4_end_grace only schedules&#xA;work while the flag is set with the spinlock held.&#xA;&#xA;So this patch adds a nfsd_net field &#34;client_tracking_active&#34; which is&#xA;set as described.  Another field &#34;grace_end_forced&#34;, is set when&#xA;v4_end_grace is written.  After this is set, and providing&#xA;client_tracking_active is set, the laundromat is scheduled.&#xA;This &#34;grace_end_forced&#34; field bypasses other checks for whether the&#xA;grace period has finished.&#xA;&#xA;This resolves a race which can result in use-after-free.&#xA;CVE-2022-50518:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;parisc: Fix locking in pdc_iodc_print() firmware call&#xA;&#xA;Utilize pdc_lock spinlock to protect parallel modifications of the&#xA;iodc_dbuf[] buffer, check length to prevent buffer overflow of&#xA;iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong&#xA;indentings.&#xA;CVE-2025-39794:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ARM: tegra: Use I/O memcpy to write to IRAM&#xA;&#xA;Kasan crashes the kernel trying to check boundaries when using the&#xA;normal memcpy.&#xA;CVE-2025-40205:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: avoid potential out-of-bounds in btrfs_encode_fh()&#xA;&#xA;The function btrfs_encode_fh() does not properly account for the three&#xA;cases it handles.&#xA;&#xA;Before writing to the file handle (fh), the function only returns to the&#xA;user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or&#xA;BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).&#xA;&#xA;However, when a parent exists and the root ID of the parent and the&#xA;inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT&#xA;(10 dwords, 40 bytes).&#xA;&#xA;If *max_len is not large enough, this write goes out of bounds because&#xA;BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than&#xA;BTRFS_FID_SIZE_CONNECTABLE originally returned.&#xA;&#xA;This results in an 8-byte out-of-bounds write at&#xA;fid-&gt;parent_root_objectid = parent_root_id.&#xA;&#xA;A previous attempt to fix this issue was made but was lost.&#xA;&#xA;https://lore.kernel.org/all/[email protected]/&#xA;&#xA;Although this issue does not seem to be easily triggerable, it is a&#xA;potential memory corruption bug that should be fixed. This patch&#xA;resolves the issue by ensuring the function returns the appropriate size&#xA;for all three cases and validates that *max_len is large enough before&#xA;writing any data.&#xA;CVE-2025-39738:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: do not allow relocation of partially dropped subvolumes&#xA;&#xA;[BUG]&#xA;There is an internal report that balance triggered transaction abort,&#xA;with the following call trace:&#xA;&#xA;  item 85 key (594509824 169 0) itemoff 12599 itemsize 33&#xA;          extent refs 1 gen 197740 flags 2&#xA;          ref#0: tree block backref root 7&#xA;  item 86 key (594558976 169 0) itemoff 12566 itemsize 33&#xA;          extent refs 1 gen 197522 flags 2&#xA;          ref#0: tree block backref root 7&#xA; ...&#xA; BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0&#xA; BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117&#xA; ------------[ cut here ]------------&#xA; BTRFS: Transaction aborted (error -117)&#xA; WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]&#xA;&#xA;And btrfs check doesn&#39;t report anything wrong related to the extent&#xA;tree.&#xA;&#xA;[CAUSE]&#xA;The cause is a little complex, firstly the extent tree indeed doesn&#39;t&#xA;have the backref for 594526208.&#xA;&#xA;The extent tree only have the following two backrefs around that bytenr&#xA;on-disk:&#xA;&#xA;        item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33&#xA;                refs 1 gen 197740 flags TREE_BLOCK&#xA;                tree block skinny level 0&#xA;                (176 0x7) tree block backref root CSUM_TREE&#xA;        item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33&#xA;                refs 1 gen 197522 flags TREE_BLOCK&#xA;                tree block skinny level 0&#xA;                (176 0x7) tree block backref root CSUM_TREE&#xA;&#xA;But the such missing backref item is not an corruption on disk, as the&#xA;offending delayed ref belongs to subvolume 934, and that subvolume is&#xA;being dropped:&#xA;&#xA;        item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439&#xA;                generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328&#xA;                last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0&#xA;                drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2&#xA;                level 2 generation_v2 198229&#xA;&#xA;And that offending tree block 594526208 is inside the dropped range of&#xA;that subvolume.  That explains why there is no backref item for that&#xA;bytenr and why btrfs check is not reporting anything wrong.&#xA;&#xA;But this also shows another problem, as btrfs will do all the orphan&#xA;subvolume cleanup at a read-write mount.&#xA;&#xA;So half-dropped subvolume should not exist after an RW mount, and&#xA;balance itself is also exclusive to subvolume cleanup, meaning we&#xA;shouldn&#39;t hit a subvolume half-dropped during relocation.&#xA;&#xA;The root cause is, there is no orphan item for this subvolume.&#xA;In fact there are 5 subvolumes from around 2021 that have the same&#xA;problem.&#xA;&#xA;It looks like the original report has some older kernels running, and&#xA;caused those zombie subvolumes.&#xA;&#xA;Thankfully upstream commit 8d488a8c7ba2 (&#34;btrfs: fix subvolume/snapshot&#xA;deletion not triggered on mount&#34;) has long fixed the bug.&#xA;&#xA;[ENHANCEMENT]&#xA;For repairing such old fs, btrfs-progs will be enhanced.&#xA;&#xA;Considering how delayed the problem will show up (at run delayed ref&#xA;time) and at that time we have to abort transaction already, it is too&#xA;late.&#xA;&#xA;Instead here we reject any half-dropped subvolume for reloc tree at the&#xA;earliest time, preventing confusion and extra time wasted on debugging&#xA;similar bugs.&#xA;CVE-2025-39788:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE&#xA;&#xA;On Google gs101, the number of UTP transfer request slots (nutrs) is 32,&#xA;and in this case the driver ends up programming the UTRL_NEXUS_TYPE&#xA;incorrectly as 0.&#xA;&#xA;This is because the left hand side of the shift is 1, which is of type&#xA;int, i.e. 31 bits wide. Shifting by more than that width results in&#xA;undefined behaviour.&#xA;&#xA;Fix this by switching to the BIT() macro, which applies correct type&#xA;casting as required. This ensures the correct value is written to&#xA;UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift&#xA;warning:&#xA;&#xA;    UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21&#xA;    shift exponent 32 is too large for 32-bit type &#39;int&#39;&#xA;&#xA;For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE&#xA;write.&#xA;CVE-2026-23271:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf: Fix __perf_event_overflow() vs perf_remove_from_context() race&#xA;&#xA;Make sure that __perf_event_overflow() runs with IRQs disabled for all&#xA;possible callchains. Specifically the software events can end up running&#xA;it with only preemption disabled.&#xA;&#xA;This opens up a race vs perf_event_exit_event() and friends that will go&#xA;and free various things the overflow path expects to be present, like&#xA;the BPF program.&#xA;CVE-2026-31402:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: fix heap overflow in NFSv4.0 LOCK replay cache&#xA;&#xA;The NFSv4.0 replay cache uses a fixed 112-byte inline buffer&#xA;(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.&#xA;This size was calculated based on OPEN responses and does not account&#xA;for LOCK denied responses, which include the conflicting lock owner as&#xA;a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).&#xA;&#xA;When a LOCK operation is denied due to a conflict with an existing lock&#xA;that has a large owner, nfsd4_encode_operation() copies the full encoded&#xA;response into the undersized replay buffer via read_bytes_from_xdr_buf()&#xA;with no bounds check. This results in a slab-out-of-bounds write of up&#xA;to 944 bytes past the end of the buffer, corrupting adjacent heap memory.&#xA;&#xA;This can be triggered remotely by an unauthenticated attacker with two&#xA;cooperating NFSv4.0 clients: one sets a lock with a large owner string,&#xA;then the other requests a conflicting lock to provoke the denial.&#xA;&#xA;We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full&#xA;opaque, but that would increase the size of every stateowner, when most&#xA;lockowners are not that large.&#xA;&#xA;Instead, fix this by checking the encoded response length against&#xA;NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the&#xA;response is too large, set rp_buflen to 0 to skip caching the replay&#xA;payload. The status is still cached, and the client already received the&#xA;correct response on the original request.&#xA;CVE-2025-71078:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;powerpc/64s/slb: Fix SLB multihit issue during SLB preload&#xA;&#xA;On systems using the hash MMU, there is a software SLB preload cache that&#xA;mirrors the entries loaded into the hardware SLB buffer. This preload&#xA;cache is subject to periodic eviction — typically after every 256 context&#xA;switches — to remove old entry.&#xA;&#xA;To optimize performance, the kernel skips switch_mmu_context() in&#xA;switch_mm_irqs_off() when the prev and next mm_struct are the same.&#xA;However, on hash MMU systems, this can lead to inconsistencies between&#xA;the hardware SLB and the software preload cache.&#xA;&#xA;If an SLB entry for a process is evicted from the software cache on one&#xA;CPU, and the same process later runs on another CPU without executing&#xA;switch_mmu_context(), the hardware SLB may retain stale entries. If the&#xA;kernel then attempts to reload that entry, it can trigger an SLB&#xA;multi-hit error.&#xA;&#xA;The following timeline shows how stale SLB entries are created and can&#xA;cause a multi-hit error when a process moves between CPUs without a&#xA;MMU context switch.&#xA;&#xA;CPU 0                                   CPU 1&#xA;-----                                    -----&#xA;Process P&#xA;exec                                    swapper/1&#xA; load_elf_binary&#xA;  begin_new_exc&#xA;    activate_mm&#xA;     switch_mm_irqs_off&#xA;      switch_mmu_context&#xA;       switch_slb&#xA;       /*&#xA;        * This invalidates all&#xA;        * the entries in the HW&#xA;        * and setup the new HW&#xA;        * SLB entries as per the&#xA;        * preload cache.&#xA;        */&#xA;context_switch&#xA;sched_migrate_task migrates process P to cpu-1&#xA;&#xA;Process swapper/0                       context switch (to process P)&#xA;(uses mm_struct of Process P)           switch_mm_irqs_off()&#xA;                                         switch_slb&#xA;                                           load_slb++&#xA;                                            /*&#xA;                                            * load_slb becomes 0 here&#xA;                                            * and we evict an entry from&#xA;                                            * the preload cache with&#xA;                                            * preload_age(). We still&#xA;                                            * keep HW SLB and preload&#xA;                                            * cache in sync, that is&#xA;                                            * because all HW SLB entries&#xA;                                            * anyways gets evicted in&#xA;                                            * switch_slb during SLBIA.&#xA;                                            * We then only add those&#xA;                                            * entries back in HW SLB,&#xA;                                            * which are currently&#xA;                                            * present in preload_cache&#xA;                                            * (after eviction).&#xA;                                            */&#xA;                                        load_elf_binary continues...&#xA;                                         setup_new_exec()&#xA;                                          slb_setup_new_exec()&#xA;&#xA;                                        sched_switch event&#xA;                                        sched_migrate_task migrates&#xA;                                        process P to cpu-0&#xA;&#xA;context_switch from swapper/0 to Process P&#xA; switch_mm_irqs_off()&#xA;  /*&#xA;   * Since both prev and next mm struct are same we don&#39;t call&#xA;   * switch_mmu_context(). This will cause the HW SLB and SW preload&#xA;   * cache to go out of sync in preload_new_slb_context. Because there&#xA;   * was an SLB entry which was evicted from both HW and preload cache&#xA;   * on cpu-1. Now later in preload_new_slb_context(), when we will try&#xA;   * to add the same preload entry again, we will add this to the SW&#xA;   * preload cache and then will add it to the HW SLB. Since on cpu-0&#xA;   * this entry was never invalidated, hence adding this entry to the HW&#xA;   * SLB will cause a SLB multi-hit error.&#xA;   */&#xA;load_elf_binary cont&#xA;---truncated---&#xA;CVE-2026-23450:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()&#xA;&#xA;Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].&#xA;&#xA;smc_tcp_syn_recv_sock() is called in the TCP receive path&#xA;(softirq) via icsk_af_ops-&gt;syn_recv_sock on the clcsock (TCP&#xA;listening socket). It reads sk_user_data to get the smc_sock&#xA;pointer. However, when the SMC listen socket is being closed&#xA;concurrently, smc_close_active() sets clcsock-&gt;sk_user_data&#xA;to NULL under sk_callback_lock, and then the smc_sock itself&#xA;can be freed via sock_put() in smc_release().&#xA;&#xA;This leads to two issues:&#xA;&#xA;1) NULL pointer dereference: sk_user_data is NULL when&#xA;   accessed.&#xA;2) Use-after-free: sk_user_data is read as non-NULL, but the&#xA;   smc_sock is freed before its fields (e.g., queued_smc_hs,&#xA;   ori_af_ops) are accessed.&#xA;&#xA;The race window looks like this (the syzkaller crash [1]&#xA;triggers via the SYN cookie path: tcp_get_cookie_sock() -&gt;&#xA;smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path&#xA;has the same race):&#xA;&#xA;  CPU A (softirq)              CPU B (process ctx)&#xA;&#xA;  tcp_v4_rcv()&#xA;    TCP_NEW_SYN_RECV:&#xA;    sk = req-&gt;rsk_listener&#xA;    sock_hold(sk)&#xA;    /* No lock on listener */&#xA;                               smc_close_active():&#xA;                                 write_lock_bh(cb_lock)&#xA;                                 sk_user_data = NULL&#xA;                                 write_unlock_bh(cb_lock)&#xA;                                 ...&#xA;                                 smc_clcsock_release()&#xA;                                 sock_put(smc-&gt;sk) x2&#xA;                                   -&gt; smc_sock freed!&#xA;    tcp_check_req()&#xA;      smc_tcp_syn_recv_sock():&#xA;        smc = user_data(sk)&#xA;          -&gt; NULL or dangling&#xA;        smc-&gt;queued_smc_hs&#xA;          -&gt; crash!&#xA;&#xA;Note that the clcsock and smc_sock are two independent objects&#xA;with separate refcounts. TCP stack holds a reference on the&#xA;clcsock, which keeps it alive, but this does NOT prevent the&#xA;smc_sock from being freed.&#xA;&#xA;Fix this by using RCU and refcount_inc_not_zero() to safely&#xA;access smc_sock. Since smc_tcp_syn_recv_sock() is called in&#xA;the TCP three-way handshake path, taking read_lock_bh on&#xA;sk_callback_lock is too heavy and would not survive a SYN&#xA;flood attack. Using rcu_read_lock() is much more lightweight.&#xA;&#xA;- Set SOCK_RCU_FREE on the SMC listen socket so that&#xA;  smc_sock freeing is deferred until after the RCU grace&#xA;  period. This guarantees the memory is still valid when&#xA;  accessed inside rcu_read_lock().&#xA;- Use rcu_read_lock() to protect reading sk_user_data.&#xA;- Use refcount_inc_not_zero(&amp;smc-&gt;sk.sk_refcnt) to pin the&#xA;  smc_sock. If the refcount has already reached zero (close&#xA;  path completed), it returns false and we bail out safely.&#xA;&#xA;Note: smc_hs_congested() has a similar lockless read of&#xA;sk_user_data without rcu_read_lock(), but it only checks for&#xA;NULL and accesses the global smc_hs_wq, never dereferencing&#xA;any smc_sock field, so it is not affected.&#xA;&#xA;Reproducer was verified with mdelay injection and smc_run,&#xA;the issue no longer occurs with this patch applied.&#xA;&#xA;[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9&#xA;CVE-2026-31426:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()&#xA;&#xA;When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware&#xA;platforms, it has already started the EC and installed the address&#xA;space handler with the struct acpi_ec pointer as handler context.&#xA;However, acpi_ec_setup() propagates the error without any cleanup.&#xA;&#xA;The caller acpi_ec_add() then frees the struct acpi_ec for non-boot&#xA;instances, leaving a dangling handler context in ACPICA.&#xA;&#xA;Any subsequent AML evaluation that accesses an EC OpRegion field&#xA;dispatches into acpi_ec_space_handler() with the freed pointer,&#xA;causing a use-after-free:&#xA;&#xA; BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)&#xA; Write of size 8 at addr ffff88800721de38 by task init/1&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  mutex_lock (kernel/locking/mutex.c:289)&#xA;  acpi_ec_space_handler (drivers/acpi/ec.c:1362)&#xA;  acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)&#xA;  acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)&#xA;  acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)&#xA;  acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)&#xA;  acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)&#xA;  acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)&#xA;  &lt;/TASK&gt;&#xA;&#xA; Allocated by task 1:&#xA;  acpi_ec_alloc (drivers/acpi/ec.c:1424)&#xA;  acpi_ec_add (drivers/acpi/ec.c:1692)&#xA;&#xA; Freed by task 1:&#xA;  kfree (mm/slub.c:6876)&#xA;  acpi_ec_add (drivers/acpi/ec.c:1751)&#xA;&#xA;The bug triggers on reduced-hardware EC platforms (ec-&gt;gpe &lt; 0)&#xA;when the GPIO IRQ provider defers probing. Once the stale handler&#xA;exists, any unprivileged sysfs read that causes AML to touch an&#xA;EC OpRegion (battery, thermal, backlight) exercises the dangling&#xA;pointer.&#xA;&#xA;Fix this by calling ec_remove_handlers() in the error path of&#xA;acpi_ec_setup() before clearing first_ec. ec_remove_handlers()&#xA;checks each EC_FLAGS_* bit before acting, so it is safe to call&#xA;regardless of how far ec_install_handlers() progressed:&#xA;&#xA;  -ENODEV  (handler not installed): only calls acpi_ec_stop()&#xA;  -EPROBE_DEFER (handler installed): removes handler, stops EC&#xA;CVE-2026-31392:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: fix krb5 mount with username option&#xA;&#xA;Customer reported that some of their krb5 mounts were failing against&#xA;a single server as the client was trying to mount the shares with&#xA;wrong credentials.  It turned out the client was reusing SMB session&#xA;from first mount to try mounting the other shares, even though a&#xA;different username= option had been specified to the other mounts.&#xA;&#xA;By using username mount option along with sec=krb5 to search for&#xA;principals from keytab is supported by cifs.upcall(8) since&#xA;cifs-utils-4.8.  So fix this by matching username mount option in&#xA;match_session() even with Kerberos.&#xA;&#xA;For example, the second mount below should fail with -ENOKEY as there&#xA;is no &#39;foobar&#39; principal in keytab (/etc/krb5.keytab).  The client&#xA;ends up reusing SMB session from first mount to perform the second&#xA;one, which is wrong.&#xA;&#xA;```&#xA;$ ktutil&#xA;ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts&#xA;Password for [email protected]:&#xA;ktutil:  write_kt /etc/krb5.keytab&#xA;ktutil:  quit&#xA;$ klist -ke&#xA;Keytab name: FILE:/etc/krb5.keytab&#xA;KVNO Principal&#xA; ---- ----------------------------------------------------------------&#xA;   1 [email protected] (aes256-cts-hmac-sha1-96)&#xA;$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser&#xA;$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar&#xA;$ mount -t cifs | grep -Po &#39;username=\K\w+&#39;&#xA;testuser&#xA;testuser&#xA;```&#xA;CVE-2026-31473:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex&#xA;&#xA;MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0)&#xA;queue teardown paths. This can race request object cleanup against vb2&#xA;queue cancellation and lead to use-after-free reports.&#xA;&#xA;We already serialize request queueing against STREAMON/OFF with&#xA;req_queue_mutex. Extend that serialization to REQBUFS, and also take&#xA;the same mutex in media_request_ioctl_reinit() so REINIT is in the&#xA;same exclusion domain.&#xA;&#xA;This keeps request cleanup and queue cancellation from running in&#xA;parallel for request-capable devices.&#xA;CVE-2026-23383:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing&#xA;&#xA;struct bpf_plt contains a u64 target field. Currently, the BPF JIT&#xA;allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT&#xA;buffer.&#xA;&#xA;Because the base address of the JIT buffer can be 4-byte aligned (e.g.,&#xA;ending in 0x4 or 0xc), the relative padding logic in build_plt() fails&#xA;to ensure that target lands on an 8-byte boundary.&#xA;&#xA;This leads to two issues:&#xA;1. UBSAN reports misaligned-access warnings when dereferencing the&#xA;   structure.&#xA;2. More critically, target is updated concurrently via WRITE_ONCE() in&#xA;   bpf_arch_text_poke() while the JIT&#39;d code executes ldr. On arm64,&#xA;   64-bit loads/stores are only guaranteed to be single-copy atomic if&#xA;   they are 64-bit aligned. A misaligned target risks a torn read,&#xA;   causing the JIT to jump to a corrupted address.&#xA;&#xA;Fix this by increasing the allocation alignment requirement to 8 bytes&#xA;(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of&#xA;the JIT buffer to an 8-byte boundary, allowing the relative padding math&#xA;in build_plt() to correctly align the target field.&#xA;CVE-2026-23099:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bonding: limit BOND_MODE_8023AD to Ethernet devices&#xA;&#xA;BOND_MODE_8023AD makes sense for ARPHRD_ETHER only.&#xA;&#xA;syzbot reported:&#xA;&#xA; BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]&#xA; BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118&#xA;Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497&#xA;&#xA;CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G             L      syzkaller #0 PREEMPT(full)&#xA;Tainted: [L]=SOFTLOCKUP&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120&#xA;  print_address_description mm/kasan/report.c:378 [inline]&#xA;  print_report+0xca/0x240 mm/kasan/report.c:482&#xA;  kasan_report+0x118/0x150 mm/kasan/report.c:595&#xA; check_region_inline mm/kasan/generic.c:-1 [inline]&#xA;  kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200&#xA;  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105&#xA;  __hw_addr_create net/core/dev_addr_lists.c:63 [inline]&#xA;  __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118&#xA;  __dev_mc_add net/core/dev_addr_lists.c:868 [inline]&#xA;  dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886&#xA;  bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180&#xA;  do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963&#xA;  do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165&#xA;  rtnl_changelink net/core/rtnetlink.c:3776 [inline]&#xA;  __rtnl_newlink net/core/rtnetlink.c:3935 [inline]&#xA;  rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072&#xA;  rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958&#xA;  netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550&#xA;  netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]&#xA;  netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344&#xA;  netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894&#xA;  sock_sendmsg_nosec net/socket.c:727 [inline]&#xA;  __sock_sendmsg+0x21c/0x270 net/socket.c:742&#xA;  ____sys_sendmsg+0x505/0x820 net/socket.c:2592&#xA;  ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646&#xA;  __sys_sendmsg+0x164/0x220 net/socket.c:2678&#xA;  do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]&#xA;  __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307&#xA;  do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332&#xA; entry_SYSENTER_compat_after_hwframe+0x84/0x8e&#xA; &lt;/TASK&gt;&#xA;&#xA;The buggy address belongs to the variable:&#xA; lacpdu_mcast_addr+0x0/0x40&#xA;CVE-2026-23351:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nft_set_pipapo: split gc into unlink and reclaim phase&#xA;&#xA;Yiming Qian reports Use-after-free in the pipapo set type:&#xA;  Under a large number of expired elements, commit-time GC can run for a very&#xA;  long time in a non-preemptible context, triggering soft lockup warnings and&#xA;  RCU stall reports (local denial of service).&#xA;&#xA;We must split GC in an unlink and a reclaim phase.&#xA;&#xA;We cannot queue elements for freeing until pointers have been swapped.&#xA;Expired elements are still exposed to both the packet path and userspace&#xA;dumpers via the live copy of the data structure.&#xA;&#xA;call_rcu() does not protect us: dump operations or element lookups starting&#xA;after call_rcu has fired can still observe the free&#39;d element, unless the&#xA;commit phase has made enough progress to swap the clone and live pointers&#xA;before any new reader has picked up the old version.&#xA;&#xA;This a similar approach as done recently for the rbtree backend in commit&#xA;35f83a75529a (&#34;netfilter: nft_set_rbtree: don&#39;t gc elements on insert&#34;).&#xA;CVE-2026-23274:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels&#xA;&#xA;IDLETIMER revision 0 rules reuse existing timers by label and always call&#xA;mod_timer() on timer-&gt;timer.&#xA;&#xA;If the label was created first by revision 1 with XT_IDLETIMER_ALARM,&#xA;the object uses alarm timer semantics and timer-&gt;timer is never initialized.&#xA;Reusing that object from revision 0 causes mod_timer() on an uninitialized&#xA;timer_list, triggering debugobjects warnings and possible panic when&#xA;panic_on_warn=1.&#xA;&#xA;Fix this by rejecting revision 0 rule insertion when an existing timer with&#xA;the same label is of ALARM type.&#xA;CVE-2026-23391:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: xt_CT: drop pending enqueued packets on template removal&#xA;&#xA;Templates refer to objects that can go away while packets are sitting in&#xA;nfqueue refer to:&#xA;&#xA;- helper, this can be an issue on module removal.&#xA;- timeout policy, nfnetlink_cttimeout might remove it.&#xA;&#xA;The use of templates with zone and event cache filter are safe, since&#xA;this just copies values.&#xA;&#xA;Flush these enqueued packets in case the template rule gets removed.&#xA;CVE-2026-23340:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs&#xA;&#xA;When shrinking the number of real tx queues,&#xA;netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush&#xA;qdiscs for queues which will no longer be used.&#xA;&#xA;qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with&#xA;qdisc_lock(). However, for lockless qdiscs, the dequeue path is&#xA;serialized by qdisc_run_begin/end() using qdisc-&gt;seqlock instead, so&#xA;qdisc_reset() can run concurrently with __qdisc_run() and free skbs&#xA;while they are still being dequeued, leading to UAF.&#xA;&#xA;This can easily be reproduced on e.g. virtio-net by imposing heavy&#xA;traffic while frequently changing the number of queue pairs:&#xA;&#xA;  iperf3 -ub0 -c $peer -t 0 &amp;&#xA;  while :; do&#xA;    ethtool -L eth0 combined 1&#xA;    ethtool -L eth0 combined 2&#xA;  done&#xA;&#xA;With KASAN enabled, this leads to reports like:&#xA;&#xA;  BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760&#xA;  ...&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ...&#xA;   __qdisc_run+0x133f/0x1760&#xA;   __dev_queue_xmit+0x248f/0x3550&#xA;   ip_finish_output2+0xa42/0x2110&#xA;   ip_output+0x1a7/0x410&#xA;   ip_send_skb+0x2e6/0x480&#xA;   udp_send_skb+0xb0a/0x1590&#xA;   udp_sendmsg+0x13c9/0x1fc0&#xA;   ...&#xA;   &lt;/TASK&gt;&#xA;&#xA;  Allocated by task 1270 on cpu 5 at 44.558414s:&#xA;   ...&#xA;   alloc_skb_with_frags+0x84/0x7c0&#xA;   sock_alloc_send_pskb+0x69a/0x830&#xA;   __ip_append_data+0x1b86/0x48c0&#xA;   ip_make_skb+0x1e8/0x2b0&#xA;   udp_sendmsg+0x13a6/0x1fc0&#xA;   ...&#xA;&#xA;  Freed by task 1306 on cpu 3 at 44.558445s:&#xA;   ...&#xA;   kmem_cache_free+0x117/0x5e0&#xA;   pfifo_fast_reset+0x14d/0x580&#xA;   qdisc_reset+0x9e/0x5f0&#xA;   netif_set_real_num_tx_queues+0x303/0x840&#xA;   virtnet_set_channels+0x1bf/0x260 [virtio_net]&#xA;   ethnl_set_channels+0x684/0xae0&#xA;   ethnl_default_set_doit+0x31a/0x890&#xA;   ...&#xA;&#xA;Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by&#xA;taking qdisc-&gt;seqlock for TCQ_F_NOLOCK qdiscs, matching the&#xA;serialization model already used by dev_reset_queue().&#xA;&#xA;Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state&#xA;reflects an empty queue, avoiding needless re-scheduling.&#xA;CVE-2026-23272:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: unconditionally bump set-&gt;nelems before insertion&#xA;&#xA;In case that the set is full, a new element gets published then removed&#xA;without waiting for the RCU grace period, while RCU reader can be&#xA;walking over it already.&#xA;&#xA;To address this issue, add the element transaction even if set is full,&#xA;but toggle the set_full flag to report -ENFILE so the abort path safely&#xA;unwinds the set to its previous state.&#xA;&#xA;As for element updates, decrement set-&gt;nelems to restore it.&#xA;&#xA;A simpler fix is to call synchronize_rcu() in the error path.&#xA;However, with a large batch adding elements to already maxed-out set,&#xA;this could cause noticeable slowdown of such batches.&#xA;CVE-2026-43033:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption&#xA;&#xA;When decrypting data that is not in-place (src != dst), there is&#xA;no need to save the high-order sequence bits in dst as it could&#xA;simply be re-copied from the source.&#xA;&#xA;However, the data to be hashed need to be rearranged accordingly.&#xA;&#xA;&#xA;Thanks,&#xA;CVE-2026-31677:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: af_alg - limit RX SG extraction by receive buffer budget&#xA;&#xA;Make af_alg_get_rsgl() limit each RX scatterlist extraction to the&#xA;remaining receive buffer budget.&#xA;&#xA;af_alg_get_rsgl() currently uses af_alg_readable() only as a gate&#xA;before extracting data into the RX scatterlist. Limit each extraction&#xA;to the remaining af_alg_rcvbuf(sk) budget so that receive-side&#xA;accounting matches the amount of data attached to the request.&#xA;&#xA;If skcipher cannot obtain enough RX space for at least one chunk while&#xA;more data remains to be processed, reject the recvmsg call instead of&#xA;rounding the request length down to zero.&#xA;CVE-2026-31515:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;af_key: validate families in pfkey_send_migrate()&#xA;&#xA;syzbot was able to trigger a crash in skb_put() [1]&#xA;&#xA;Issue is that pfkey_send_migrate() does not check old/new families,&#xA;and that set_ipsecrequest() @family argument was truncated,&#xA;thus possibly overfilling the skb.&#xA;&#xA;Validate families early, do not wait set_ipsecrequest().&#xA;&#xA;[1]&#xA;&#xA;skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:&lt;NULL&gt;&#xA; kernel BUG at net/core/skbuff.c:214 !&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  skb_over_panic net/core/skbuff.c:219 [inline]&#xA;  skb_put+0x159/0x210 net/core/skbuff.c:2655&#xA;  skb_put_zero include/linux/skbuff.h:2788 [inline]&#xA;  set_ipsecrequest net/key/af_key.c:3532 [inline]&#xA;  pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636&#xA;  km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848&#xA;  xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705&#xA;  xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150&#xA;CVE-2026-31504:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: fix fanout UAF in packet_release() via NETDEV_UP race&#xA;&#xA;`packet_release()` has a race window where `NETDEV_UP` can re-register a&#xA;socket into a fanout group&#39;s `arr[]` array. The re-registration is not&#xA;cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout&#xA;array.&#xA;`packet_release()` does NOT zero `po-&gt;num` in its `bind_lock` section.&#xA;After releasing `bind_lock`, `po-&gt;num` is still non-zero and `po-&gt;ifindex`&#xA;still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`&#xA;that already found the socket in `sklist` can re-register the hook.&#xA;For fanout sockets, this re-registration calls `__fanout_link(sk, po)`&#xA;which adds the socket back into `f-&gt;arr[]` and increments `f-&gt;num_members`,&#xA;but does NOT increment `f-&gt;sk_ref`.&#xA;&#xA;The fix sets `po-&gt;num` to zero in `packet_release` while `bind_lock` is&#xA;held to prevent NETDEV_UP from linking, preventing the race window.&#xA;&#xA;This bug was found following an additional audit with Claude Code based&#xA;on CVE-2025-38617.&#xA;CVE-2026-31431:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: algif_aead - Revert to operating out-of-place&#xA;&#xA;This mostly reverts commit 72548b093ee3 except for the copying of&#xA;the associated data.&#xA;&#xA;There is no benefit in operating in-place in algif_aead since the&#xA;source and destination come from different mappings.  Get rid of&#xA;all the complexity added for in-place operation and just copy the&#xA;AD directly.&#xA;CVE-2026-31570:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: gw: fix OOB heap access in cgw_csum_crc8_rel()&#xA;&#xA;cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():&#xA;&#xA;    int from = calc_idx(crc8-&gt;from_idx, cf-&gt;len);&#xA;    int to   = calc_idx(crc8-&gt;to_idx,   cf-&gt;len);&#xA;    int res  = calc_idx(crc8-&gt;result_idx, cf-&gt;len);&#xA;&#xA;    if (from &lt; 0 || to &lt; 0 || res &lt; 0)&#xA;        return;&#xA;&#xA;However, the loop and the result write then use the raw s8 fields directly&#xA;instead of the computed variables:&#xA;&#xA;    for (i = crc8-&gt;from_idx; ...)        /* BUG: raw negative index */&#xA;    cf-&gt;data[crc8-&gt;result_idx] = ...;    /* BUG: raw negative index */&#xA;&#xA;With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,&#xA;calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with&#xA;i = -64, reading cf-&gt;data[-64], and the write goes to cf-&gt;data[-64].&#xA;This write might end up to 56 (7.0-rc) or 40 (&lt;= 6.19) bytes before the&#xA;start of the canfd_frame on the heap.&#xA;&#xA;The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`&#xA;correctly throughout; fix cgw_csum_crc8_rel() to match.&#xA;&#xA;Confirmed with KASAN on linux-7.0-rc2:&#xA;  BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0&#xA;  Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62&#xA;&#xA;To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.&#xA;CVE-2026-31682:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bridge: br_nd_send: linearize skb before parsing ND options&#xA;&#xA;br_nd_send() parses neighbour discovery options from ns-&gt;opt[] and&#xA;assumes that these options are in the linear part of request.&#xA;&#xA;Its callers only guarantee that the ICMPv6 header and target address&#xA;are available, so the option area can still be non-linear. Parsing&#xA;ns-&gt;opt[] in that case can access data past the linear buffer.&#xA;&#xA;Linearize request before option parsing and derive ns from the linear&#xA;network header.&#xA;CVE-2026-31680:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ipv6: flowlabel: defer exclusive option free until RCU teardown&#xA;&#xA;`ip6fl_seq_show()` walks the global flowlabel hash under the seq-file&#xA;RCU read-side lock and prints `fl-&gt;opt-&gt;opt_nflen` when an option block&#xA;is present.&#xA;&#xA;Exclusive flowlabels currently free `fl-&gt;opt` as soon as `fl-&gt;users`&#xA;drops to zero in `fl_release()`. However, the surrounding&#xA;`struct ip6_flowlabel` remains visible in the global hash table until&#xA;later garbage collection removes it and `fl_free_rcu()` finally tears it&#xA;down.&#xA;&#xA;A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that&#xA;early `kfree()` and dereference freed option state, triggering a crash&#xA;in `ip6fl_seq_show()`.&#xA;&#xA;Fix this by keeping `fl-&gt;opt` alive until `fl_free_rcu()`. That matches&#xA;the lifetime already required for the enclosing flowlabel while readers&#xA;can still reach it under RCU.&#xA;CVE-2026-31674:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()&#xA;&#xA;Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS.&#xA;&#xA;rt_mt6() expects addrnr to stay within the bounds of rtinfo-&gt;addrs[].&#xA;Validate addrnr during rule installation so malformed rules are rejected&#xA;before the match logic can use an out-of-range value.&#xA;CVE-2026-31673:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;af_unix: read UNIX_DIAG_VFS data under unix_state_lock&#xA;&#xA;Exact UNIX diag lookups hold a reference to the socket, but not to&#xA;u-&gt;path. Meanwhile, unix_release_sock() clears u-&gt;path under&#xA;unix_state_lock() and drops the path reference after unlocking.&#xA;&#xA;Read the inode and device numbers for UNIX_DIAG_VFS while holding&#xA;unix_state_lock(), then emit the netlink attribute after dropping the&#xA;lock.&#xA;&#xA;This keeps the VFS data stable while the reply is being built.&#xA;CVE-2026-31678:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;openvswitch: defer tunnel netdev_put to RCU release&#xA;&#xA;ovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already&#xA;detached the device. Dropping the netdev reference in destroy can race&#xA;with concurrent readers that still observe vport-&gt;dev.&#xA;&#xA;Do not release vport-&gt;dev in ovs_netdev_tunnel_destroy(). Instead, let&#xA;vport_netdev_free() drop the reference from the RCU callback, matching&#xA;the non-tunnel destroy path and avoiding additional synchronization&#xA;under RTNL.&#xA;CVE-2026-31405:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: dvb-net: fix OOB access in ULE extension header tables&#xA;&#xA;The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables&#xA;in handle_one_ule_extension() are declared with 255 elements (valid&#xA;indices 0-254), but the index htype is derived from network-controlled&#xA;data as (ule_sndu_type &amp; 0x00FF), giving a range of 0-255. When&#xA;htype equals 255, an out-of-bounds read occurs on the function pointer&#xA;table, and the OOB value may be called as a function pointer.&#xA;&#xA;Add a bounds check on htype against the array size before either table&#xA;is accessed. Out-of-range values now cause the SNDU to be discarded.&#xA;CVE-2026-31588:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: x86: Use scratch field in MMIO fragment to hold small write values&#xA;&#xA;When exiting to userspace to service an emulated MMIO write, copy the&#xA;to-be-written value to a scratch field in the MMIO fragment if the size&#xA;of the data payload is 8 bytes or less, i.e. can fit in a single chunk,&#xA;instead of pointing the fragment directly at the source value.&#xA;&#xA;This fixes a class of use-after-free bugs that occur when the emulator&#xA;initiates a write using an on-stack, local variable as the source, the&#xA;write splits a page boundary, *and* both pages are MMIO pages.  Because&#xA;KVM&#39;s ABI only allows for physically contiguous MMIO requests, accesses&#xA;that split MMIO pages are separated into two fragments, and are sent to&#xA;userspace one at a time.  When KVM attempts to complete userspace MMIO in&#xA;response to KVM_RUN after the first fragment, KVM will detect the second&#xA;fragment and generate a second userspace exit, and reference the on-stack&#xA;variable.&#xA;&#xA;The issue is most visible if the second KVM_RUN is performed by a separate&#xA;task, in which case the stack of the initiating task can show up as truly&#xA;freed data.&#xA;&#xA;  ==================================================================&#xA;  BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420&#xA;  Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984&#xA;&#xA;  CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace:&#xA;  dump_stack+0xbe/0xfd&#xA;  print_address_description.constprop.0+0x19/0x170&#xA;  __kasan_report.cold+0x6c/0x84&#xA;  kasan_report+0x3a/0x50&#xA;  check_memory_region+0xfd/0x1f0&#xA;  memcpy+0x20/0x60&#xA;  complete_emulated_mmio+0x305/0x420&#xA;  kvm_arch_vcpu_ioctl_run+0x63f/0x6d0&#xA;  kvm_vcpu_ioctl+0x413/0xb20&#xA;  __se_sys_ioctl+0x111/0x160&#xA;  do_syscall_64+0x30/0x40&#xA;  entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;  RIP: 0033:0x42477d&#xA;  Code: &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;  RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;  RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d&#xA;  RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005&#xA;  RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000&#xA;  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c&#xA;  R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720&#xA;&#xA;  The buggy address belongs to the page:&#xA;  page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37&#xA;  flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)&#xA;  raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000&#xA;  raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected&#xA;&#xA;  Memory state around the buggy address:&#xA;  ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;  ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;  &gt;ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;                                                   ^&#xA;  ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;  ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff&#xA;  ==================================================================&#xA;&#xA;The bug can also be reproduced with a targeted KVM-Unit-Test by hacking&#xA;KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by&#xA;overwrite the data value with garbage.&#xA;&#xA;Limit the use of the scratch fields to 8-byte or smaller accesses, and to&#xA;just writes, as larger accesses and reads are not affected thanks to&#xA;implementation details in the emulator, but add a sanity check to ensure&#xA;those details don&#39;t change in the future.  Specifically, KVM never uses&#xA;on-stack variables for accesses larger that 8 bytes, e.g. uses an operand&#xA;in the emulator context, and *al&#xA;---truncated---&#xA;CVE-2026-31602:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: ctxfi: Limit PTP to a single page&#xA;&#xA;Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256&#xA;playback streams, but the additional pages are not used by the card&#xA;correctly. The CT20K2 hardware already has multiple VMEM_PTPAL&#xA;registers, but using them separately would require refactoring the&#xA;entire virtual memory allocation logic.&#xA;&#xA;ct_vm_map() always uses PTEs in vm-&gt;ptp[0].area regardless of&#xA;CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When&#xA;aggregate memory allocations exceed this limit, ct_vm_map() tries to&#xA;access beyond the allocated space and causes a page fault:&#xA;&#xA;  BUG: unable to handle page fault for address: ffffd4ae8a10a000&#xA;  Oops: Oops: 0002 [#1] SMP PTI&#xA;  RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]&#xA;  Call Trace:&#xA;  atc_pcm_playback_prepare+0x225/0x3b0&#xA;  ct_pcm_playback_prepare+0x38/0x60&#xA;  snd_pcm_do_prepare+0x2f/0x50&#xA;  snd_pcm_action_single+0x36/0x90&#xA;  snd_pcm_action_nonatomic+0xbf/0xd0&#xA;  snd_pcm_ioctl+0x28/0x40&#xA;  __x64_sys_ioctl+0x97/0xe0&#xA;  do_syscall_64+0x81/0x610&#xA;  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count&#xA;remain unchanged.&#xA;CVE-2026-31449:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: validate p_idx bounds in ext4_ext_correct_indexes&#xA;&#xA;ext4_ext_correct_indexes() walks up the extent tree correcting&#xA;index entries when the first extent in a leaf is modified. Before&#xA;accessing path[k].p_idx-&gt;ei_block, there is no validation that&#xA;p_idx falls within the valid range of index entries for that&#xA;level.&#xA;&#xA;If the on-disk extent header contains a corrupted or crafted&#xA;eh_entries value, p_idx can point past the end of the allocated&#xA;buffer, causing a slab-out-of-bounds read.&#xA;&#xA;Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at&#xA;both access sites: before the while loop and inside it. Return&#xA;-EFSCORRUPTED if the index pointer is out of range, consistent&#xA;with how other bounds violations are handled in the ext4 extent&#xA;tree code.&#xA;CVE-2026-31450:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: publish jinode after initialization&#xA;&#xA;ext4_inode_attach_jinode() publishes ei-&gt;jinode to concurrent users.&#xA;It used to set ei-&gt;jinode before jbd2_journal_init_jbd_inode(),&#xA;allowing a reader to observe a non-NULL jinode with i_vfs_inode&#xA;still unset.&#xA;&#xA;The fast commit flush path can then pass this jinode to&#xA;jbd2_wait_inode_data(), which dereferences i_vfs_inode-&gt;i_mapping and&#xA;may crash.&#xA;&#xA;Below is the crash I observe:&#xA;```&#xA;BUG: unable to handle page fault for address: 000000010beb47f4&#xA;PGD 110e51067 P4D 110e51067 PUD 0&#xA;Oops: Oops: 0000 [#1] SMP NOPTI&#xA;CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014&#xA;RIP: 0010:xas_find_marked+0x3d/0x2e0&#xA;Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f &lt;49&gt; 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02&#xA;RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246&#xA;RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003&#xA;RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10&#xA;RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec&#xA;R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000&#xA;R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88&#xA;FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000&#xA;CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;filemap_get_folios_tag+0x87/0x2a0&#xA;__filemap_fdatawait_range+0x5f/0xd0&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? __schedule+0x3e7/0x10c0&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? preempt_count_sub+0x5f/0x80&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? cap_safe_nice+0x37/0x70&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? preempt_count_sub+0x5f/0x80&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;filemap_fdatawait_range_keep_errors+0x12/0x40&#xA;ext4_fc_commit+0x697/0x8b0&#xA;? ext4_file_write_iter+0x64b/0x950&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? preempt_count_sub+0x5f/0x80&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? vfs_write+0x356/0x480&#xA;? srso_alias_return_thunk+0x5/0xfbef5&#xA;? preempt_count_sub+0x5f/0x80&#xA;ext4_sync_file+0xf7/0x370&#xA;do_fsync+0x3b/0x80&#xA;? syscall_trace_enter+0x108/0x1d0&#xA;__x64_sys_fdatasync+0x16/0x20&#xA;do_syscall_64+0x62/0x2c0&#xA;entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;...&#xA;```&#xA;&#xA;Fix this by initializing the jbd2_inode first.&#xA;Use smp_wmb() and WRITE_ONCE() to publish ei-&gt;jinode after&#xA;initialization. Readers use READ_ONCE() to fetch the pointer.&#xA;CVE-2026-31590:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION&#xA;&#xA;Drop the WARN in sev_pin_memory() on npages overflowing an int, as the&#xA;WARN is comically trivially to trigger from userspace, e.g. by doing:&#xA;&#xA;  struct kvm_enc_region range = {&#xA;          .addr = 0,&#xA;          .size = -1ul,&#xA;  };&#xA;&#xA;  __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &amp;range);&#xA;&#xA;Note, the checks in sev_mem_enc_register_region() that presumably exist to&#xA;verify the incoming address+size are completely worthless, as both &#34;addr&#34;&#xA;and &#34;size&#34; are u64s and SEV is 64-bit only, i.e. they _can&#39;t_ be greater&#xA;than ULONG_MAX.  That wart will be cleaned up in the near future.&#xA;&#xA;&#x9;if (range-&gt;addr &gt; ULONG_MAX || range-&gt;size &gt; ULONG_MAX)&#xA;&#x9;&#x9;return -EINVAL;&#xA;&#xA;Opportunistically add a comment to explain why the code calculates the&#xA;number of pages the &#34;hard&#34; way, e.g. instead of just shifting @ulen.&#xA;CVE-2026-43030:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Fix regsafe() for pointers to packet&#xA;&#xA;In case rold-&gt;reg-&gt;range == BEYOND_PKT_END &amp;&amp; rcur-&gt;reg-&gt;range == N&#xA;regsafe() may return true which may lead to current state with&#xA;valid packet range not being explored. Fix the bug.&#xA;CVE-2026-31560:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;spi: spi-dw-dma: fix print error log when wait finish transaction&#xA;&#xA;If an error occurs, the device may not have a current message. In this&#xA;case, the system will crash.&#xA;&#xA;In this case, it&#39;s better to use dev from the struct ctlr (struct spi_controller*).&#xA;CVE-2026-31787:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xen/privcmd: fix double free via VMA splitting&#xA;&#xA;privcmd_vm_ops defines .close (privcmd_close), but neither .may_split&#xA;nor .open. When userspace does a partial munmap() on a privcmd mapping,&#xA;the kernel splits the VMA via __split_vma(). Since may_split is NULL,&#xA;the split is allowed. vm_area_dup() copies vm_private_data (a pages&#xA;array allocated in alloc_empty_pages()) into the new VMA without any&#xA;fixup, because there is no .open callback.&#xA;&#xA;Both VMAs now point to the same pages array. When the unmapped portion&#xA;is closed, privcmd_close() calls:&#xA;    - xen_unmap_domain_gfn_range()&#xA;    - xen_free_unpopulated_pages()&#xA;    - kvfree(pages)&#xA;&#xA;The surviving VMA still holds the dangling pointer. When it is later&#xA;destroyed, the same sequence runs again, which leads to a double free.&#xA;&#xA;Fix this issue by adding a .may_split callback denying the VMA split.&#xA;&#xA;This is XSA-487 / CVE-2026-31787&#xA;CVE-2026-31448:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: avoid infinite loops caused by residual data&#xA;&#xA;On the mkdir/mknod path, when mapping logical blocks to physical blocks,&#xA;if inserting a new extent into the extent tree fails (in this example,&#xA;because the file system disabled the huge file feature when marking the&#xA;inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to&#xA;reclaim the physical block without deleting the corresponding data in&#xA;the extent tree. This causes subsequent mkdir operations to reference&#xA;the previously reclaimed physical block number again, even though this&#xA;physical block is already being used by the xattr block. Therefore, a&#xA;situation arises where both the directory and xattr are using the same&#xA;buffer head block in memory simultaneously.&#xA;&#xA;The above causes ext4_xattr_block_set() to enter an infinite loop about&#xA;&#34;inserted&#34; and cannot release the inode lock, ultimately leading to the&#xA;143s blocking problem mentioned in [1].&#xA;&#xA;If the metadata is corrupted, then trying to remove some extent space&#xA;can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE&#xA;was passed, remove space wrongly update quota information.&#xA;Jan Kara suggests distinguishing between two cases:&#xA;&#xA;1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully&#xA;consistent and we must maintain its consistency including all the&#xA;accounting. However these errors can happen only early before we&#39;ve&#xA;inserted the extent into the extent tree. So current code works correctly&#xA;for this case.&#xA;&#xA;2) Some other error - this means metadata is corrupted. We should strive to&#xA;do as few modifications as possible to limit damage. So I&#39;d just skip&#xA;freeing of allocated blocks.&#xA;&#xA;[1]&#xA;INFO: task syz.0.17:5995 blocked for more than 143 seconds.&#xA;Call Trace:&#xA; inode_lock_nested include/linux/fs.h:1073 [inline]&#xA; __start_dirop fs/namei.c:2923 [inline]&#xA; start_dirop fs/namei.c:2934 [inline]&#xA;CVE-2026-31523:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nvme-pci: ensure we&#39;re polling a polled queue&#xA;&#xA;A user can change the polled queue count at run time. There&#39;s a brief&#xA;window during a reset where a hipri task may try to poll that queue&#xA;before the block layer has updated the queue maps, which would race with&#xA;the now interrupt driven queue and may cause double completions.&#xA;CVE-2026-31476:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: do not expire session on binding failure&#xA;&#xA;When a multichannel session binding request fails (e.g. wrong password),&#xA;the error path unconditionally sets sess-&gt;state = SMB2_SESSION_EXPIRED.&#xA;However, during binding, sess points to the target session looked up via&#xA;ksmbd_session_lookup_slowpath() -- which belongs to another connection&#39;s&#xA;user. This allows a remote attacker to invalidate any active session by&#xA;simply sending a binding request with a wrong password (DoS).&#xA;&#xA;Fix this by skipping session expiration when the failed request was&#xA;a binding attempt, since the session does not belong to the current&#xA;connection. The reference taken by ksmbd_session_lookup_slowpath() is&#xA;still correctly released via ksmbd_user_session_put().&#xA;CVE-2026-31403:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd&#xA;&#xA;The /proc/fs/nfs/exports proc entry is created at module init&#xA;and persists for the module&#39;s lifetime. exports_proc_open()&#xA;captures the caller&#39;s current network namespace and stores&#xA;its svc_export_cache in seq-&gt;private, but takes no reference&#xA;on the namespace. If the namespace is subsequently torn down&#xA;(e.g. container destruction after the opener does setns() to a&#xA;different namespace), nfsd_net_exit() calls nfsd_export_shutdown()&#xA;which frees the cache. Subsequent reads on the still-open fd&#xA;dereference the freed cache_detail, walking a freed hash table.&#xA;&#xA;Hold a reference on the struct net for the lifetime of the open&#xA;file descriptor. This prevents nfsd_net_exit() from running --&#xA;and thus prevents nfsd_export_shutdown() from freeing the cache&#xA;-- while any exports fd is open. cache_detail already stores&#xA;its net pointer (cd-&gt;net, set by cache_create_net()), so&#xA;exports_release() can retrieve it without additional per-file&#xA;storage.&#xA;CVE-2026-31404:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSD: Defer sub-object cleanup in export put callbacks&#xA;&#xA;svc_export_put() calls path_put() and auth_domain_put() immediately&#xA;when the last reference drops, before the RCU grace period. RCU&#xA;readers in e_show() and c_show() access both ex_path (via&#xA;seq_path/d_path) and ex_client-&gt;name (via seq_escape) without&#xA;holding a reference. If cache_clean removes the entry and drops the&#xA;last reference concurrently, the sub-objects are freed while still&#xA;in use, producing a NULL pointer dereference in d_path.&#xA;&#xA;Commit 2530766492ec (&#34;nfsd: fix UAF when access ex_uuid or&#xA;ex_stats&#34;) moved kfree of ex_uuid and ex_stats into the&#xA;call_rcu callback, but left path_put() and auth_domain_put() running&#xA;before the grace period because both may sleep and call_rcu&#xA;callbacks execute in softirq context.&#xA;&#xA;Replace call_rcu/kfree_rcu with queue_rcu_work(), which defers the&#xA;callback until after the RCU grace period and executes it in process&#xA;context where sleeping is permitted. This allows path_put() and&#xA;auth_domain_put() to be moved into the deferred callback alongside&#xA;the other resource releases. Apply the same fix to expkey_put(),&#xA;which has the identical pattern with ek_path and ek_client.&#xA;&#xA;A dedicated workqueue scopes the shutdown drain to only NFSD&#xA;export release work items; flushing the shared&#xA;system_unbound_wq would stall on unrelated work from other&#xA;subsystems. nfsd_export_shutdown() uses rcu_barrier() followed&#xA;by flush_workqueue() to ensure all deferred release callbacks&#xA;complete before the export caches are destroyed.&#xA;&#xA;Reviwed-by: Jeff Layton &lt;[email protected]&gt;&#xA;CVE-2026-31592:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm-&gt;lock&#xA;&#xA;Take and hold kvm-&gt;lock for before checking sev_guest() in&#xA;sev_mem_enc_register_region(), as sev_guest() isn&#39;t stable unless kvm-&gt;lock&#xA;is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can&#39;t&#xA;rollack state).  If KVM_SEV_INIT{2} fails, KVM can end up trying to add to&#xA;a not-yet-initialized sev-&gt;regions_list, e.g. triggering a #GP&#xA;&#xA;  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI&#xA;  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]&#xA;  CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G     U  W  O        6.16.0-smp-DEV #1 NONE&#xA;  Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE&#xA;  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024&#xA;  RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83&#xA;  Code: &lt;41&gt; 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00&#xA;  RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256&#xA;  RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000&#xA;  RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000&#xA;  RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000&#xA;  R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000&#xA;  R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000&#xA;  FS:  00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371&#xA;   kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363&#xA;   __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51&#xA;   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]&#xA;   do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;  RIP: 0033:0x7f34e9f7e9a9&#xA;  Code: &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;  RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;  RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9&#xA;  RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007&#xA;  RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000&#xA;  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;  R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8&#xA;   &lt;/TASK&gt;&#xA;&#xA;with a syzlang reproducer that looks like:&#xA;&#xA;  syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000040)={0x0, &amp;(0x7f0000000180)=ANY=[], 0x70}) (async)&#xA;  syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000080)={0x0, &amp;(0x7f0000000180)=ANY=[@ANYBLOB=&#34;...&#34;], 0x4f}) (async)&#xA;  r0 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000200), 0x0, 0x0)&#xA;  r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)&#xA;  r2 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000240), 0x0, 0x0)&#xA;  r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0)&#xA;  ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &amp;(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async)&#xA;  ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &amp;(0x7f0000000280)={[...], 0x5}) (async)&#xA;  ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async)&#xA;  r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0)&#xA;  openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async)&#xA;  ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &amp;(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &amp;(0x7f0000001000/0x2000)=nil}) (async)&#xA;  r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2)&#xA;  close(r0) (async)&#xA;  openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000000), 0x8000, 0x0) (async)&#xA;  ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &amp;(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async)&#xA;  ioctl$KVM_RUN(r5, 0xae80, 0x0)&#xA;&#xA;Opportunistically use guard() to avoid having to define a new error label&#xA;and goto usage.&#xA;CVE-2026-31679:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;openvswitch: validate MPLS set/set_masked payload length&#xA;&#xA;validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for&#xA;SET/SET_MASKED actions. In action handling, OVS expects fixed-size&#xA;MPLS key data (struct ovs_key_mpls).&#xA;&#xA;Use the already normalized key_len (masked case included) and reject&#xA;non-matching MPLS action key sizes.&#xA;&#xA;Reject invalid MPLS action payload lengths early.&#xA;CVE-2026-31628:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/CPU: Fix FPDSS on Zen1&#xA;&#xA;Zen1&#39;s hardware divider can leave, under certain circumstances, partial&#xA;results from previous operations.  Those results can be leaked by&#xA;another, attacker thread.&#xA;&#xA;Fix that with a chicken bit.&#xA;CVE-2026-31754:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: cdns3: gadget: fix state inconsistency on gadget init failure&#xA;&#xA;When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode&#xA;while software state remains INACTIVE, creating hardware/software state&#xA;inconsistency.&#xA;&#xA;When switching to host mode via sysfs:&#xA;  echo host &gt; /sys/class/usb_role/13180000.usb-role-switch/role&#xA;&#xA;The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error,&#xA;so cdns_role_stop() skips cleanup because state is still INACTIVE.&#xA;This violates the DRD controller design specification (Figure22),&#xA;which requires returning to idle state before switching roles.&#xA;&#xA;This leads to a synchronous external abort in xhci_gen_setup() when&#xA;setting up the host controller:&#xA;&#xA;[  516.440698] configfs-gadget 13180000.usb: failed to start g1: -19&#xA;[  516.442035] cdns-usb3 13180000.usb: Failed to add gadget&#xA;[  516.443278] cdns-usb3 13180000.usb: set role 2 has failed&#xA;...&#xA;[ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller&#xA;[ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP&#xA;[ 1301.382485] pc : xhci_gen_setup+0xa4/0x408&#xA;[ 1301.393391] backtrace:&#xA;    ...&#xA;    xhci_gen_setup+0xa4/0x408    &lt;-- CRASH&#xA;    xhci_plat_setup+0x44/0x58&#xA;    usb_add_hcd+0x284/0x678&#xA;    ...&#xA;    cdns_role_set+0x9c/0xbc        &lt;-- Role switch&#xA;&#xA;Fix by calling cdns_drd_gadget_off() in the error path to properly&#xA;clean up the DRD gadget state.&#xA;CVE-2026-43079:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf/x86/intel/uncore: Skip discovery table for offline dies&#xA;&#xA;This warning can be triggered if NUMA is disabled and the system&#xA;boots with fewer CPUs than the number of CPUs in die 0.&#xA;&#xA;WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]&#xA;&#xA;Currently, the discovery table continues to be parsed even if all CPUs&#xA;in the associated die are offline.  This can lead to an array overflow&#xA;at &#34;pmu-&gt;boxes[die] = box&#34; in uncore_pci_pmu_register(), which may&#xA;trigger the warning above or cause other issues.&#xA;CVE-2026-43124:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pstore: ram_core: fix incorrect success return when vmap() fails&#xA;&#xA;In persistent_ram_vmap(), vmap() may return NULL on failure.&#xA;&#xA;If offset is non-zero, adding offset_in_page(start) causes the function&#xA;to return a non-NULL pointer even though the mapping failed.&#xA;persistent_ram_buffer_map() therefore incorrectly returns success.&#xA;&#xA;Subsequent access to prz-&gt;buffer may dereference an invalid address&#xA;and cause crashes.&#xA;&#xA;Add proper NULL checking for vmap() failures.&#xA;CVE-2026-31555:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;futex: Clear stale exiting pointer in futex_lock_pi() retry path&#xA;&#xA;Fuzzying/stressing futexes triggered:&#xA;&#xA;    WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524&#xA;&#xA;When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY&#xA;and stores a refcounted task pointer in &#39;exiting&#39;.&#xA;&#xA;After wait_for_owner_exiting() consumes that reference, the local pointer&#xA;is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a&#xA;different error, the bogus pointer is passed to wait_for_owner_exiting().&#xA;&#xA;  CPU0&#x9;&#x9;&#x9;     CPU1&#x9;&#x9;       CPU2&#xA;  futex_lock_pi(uaddr)&#xA;  // acquires the PI futex&#xA;  exit()&#xA;    futex_cleanup_begin()&#xA;      futex_state = EXITING;&#xA;&#x9;&#x9;&#x9;     futex_lock_pi(uaddr)&#xA;&#x9;&#x9;&#x9;       futex_lock_pi_atomic()&#xA;&#x9;&#x9;&#x9;&#x9; attach_to_pi_owner()&#xA;&#x9;&#x9;&#x9;&#x9;   // observes EXITING&#xA;&#x9;&#x9;&#x9;&#x9;   *exiting = owner;  // takes ref&#xA;&#x9;&#x9;&#x9;&#x9;   return -EBUSY&#xA;&#x9;&#x9;&#x9;       wait_for_owner_exiting(-EBUSY, owner)&#xA;&#x9;&#x9;&#x9;&#x9; put_task_struct();   // drops ref&#xA;&#x9;&#x9;&#x9;       // exiting still points to owner&#xA;&#x9;&#x9;&#x9;       goto retry;&#xA;&#x9;&#x9;&#x9;       futex_lock_pi_atomic()&#xA;&#x9;&#x9;&#x9;&#x9; lock_pi_update_atomic()&#xA;&#x9;&#x9;&#x9;&#x9;   cmpxchg(uaddr)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;*uaddr ^= WAITERS // whatever&#xA;&#x9;&#x9;&#x9;&#x9;   // value changed&#xA;&#x9;&#x9;&#x9;&#x9; return -EAGAIN;&#xA;&#x9;&#x9;&#x9;       wait_for_owner_exiting(-EAGAIN, exiting) // stale&#xA;&#x9;&#x9;&#x9;&#x9; WARN_ON_ONCE(exiting)&#xA;&#xA;Fix this by resetting upon retry, essentially aligning it with requeue_pi.&#xA;CVE-2026-43284:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;xfrm: esp: avoid in-place decrypt on shared skb frags&#xA;&#xA;MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP&#xA;marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),&#xA;so later paths that may modify packet data can first make a private&#xA;copy. The IPv4/IPv6 datagram append paths did not set this flag when&#xA;splicing pages into UDP skbs.&#xA;&#xA;That leaves an ESP-in-UDP packet made from shared pipe pages looking&#xA;like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW&#xA;fast path for uncloned skbs without a frag_list and decrypts in place&#xA;over data that is not owned privately by the skb.&#xA;&#xA;Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching&#xA;TCP. Also make ESP input fall back to skb_cow_data() when the flag is&#xA;present, so ESP does not decrypt externally backed frags in place.&#xA;Private nonlinear skb frags still use the existing fast path.&#xA;&#xA;This intentionally does not change ESP output. In esp_output_head(),&#xA;the path that appends the ESP trailer to existing skb tailroom without&#xA;calling skb_cow_data() is not reachable for nonlinear skbs:&#xA;skb_tailroom() returns zero when skb-&gt;data_len is nonzero, while ESP&#xA;tailen is positive. Thus ESP output will either use the separate&#xA;destination-frag path or fall back to skb_cow_data().&#xA;CVE-2026-31697:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: ccp: Don&#39;t attempt to copy ID to userspace if PSP command failed&#xA;&#xA;When retrieving the ID for the CPU, don&#39;t attempt to copy the ID blob to&#xA;userspace if the firmware command failed.  If the failure was due to an&#xA;invalid length, i.e. the userspace buffer+length was too small, copying&#xA;the number of bytes _firmware_ requires will overflow the kernel-allocated&#xA;buffer and leak data to userspace.&#xA;&#xA;  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]&#xA;  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]&#xA;  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26&#xA;  Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388&#xA;&#xA;  CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY&#xA;  Tainted: [U]=USER, [O]=OOT_MODULE&#xA;  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120&#xA;   print_address_description ../mm/kasan/report.c:378 [inline]&#xA;   print_report+0xbc/0x260 ../mm/kasan/report.c:482&#xA;   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595&#xA;   check_region_inline ../mm/kasan/generic.c:-1 [inline]&#xA;   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200&#xA;   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]&#xA;   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]&#xA;   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26&#xA;   copy_to_user ../include/linux/uaccess.h:236 [inline]&#xA;   sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222&#xA;   sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575&#xA;   vfs_ioctl ../fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl ../fs/ioctl.c:597 [inline]&#xA;   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583&#xA;   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]&#xA;   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;   &lt;/TASK&gt;&#xA;&#xA;WARN if the driver says the command succeeded, but the firmware error code&#xA;says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any&#xA;firwmware error.&#xA;CVE-2026-31419:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: bonding: fix use-after-free in bond_xmit_broadcast()&#xA;&#xA;bond_xmit_broadcast() reuses the original skb for the last slave&#xA;(determined by bond_is_last_slave()) and clones it for others.&#xA;Concurrent slave enslave/release can mutate the slave list during&#xA;RCU-protected iteration, changing which slave is &#34;last&#34; mid-loop.&#xA;This causes the original skb to be double-consumed (double-freed).&#xA;&#xA;Replace the racy bond_is_last_slave() check with a simple index&#xA;comparison (i + 1 == slaves_count) against the pre-snapshot slave&#xA;count taken via READ_ONCE() before the loop.  This preserves the&#xA;zero-copy optimization for the last slave while making the &#34;last&#34;&#xA;determination stable against concurrent list mutations.&#xA;&#xA;The UAF can trigger the following crash:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in skb_clone&#xA;Read of size 8 at addr ffff888100ef8d40 by task exploit/147&#xA;&#xA;CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl (lib/dump_stack.c:123)&#xA; print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)&#xA; kasan_report (mm/kasan/report.c:597)&#xA; skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108)&#xA; bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334)&#xA; bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593)&#xA; dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887)&#xA; __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838)&#xA; ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136)&#xA; ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219)&#xA; ip6_output (net/ipv6/ip6_output.c:250)&#xA; ip6_send_skb (net/ipv6/ip6_output.c:1985)&#xA; udp_v6_send_skb (net/ipv6/udp.c:1442)&#xA; udpv6_sendmsg (net/ipv6/udp.c:1733)&#xA; __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206)&#xA; __x64_sys_sendto (net/socket.c:2209)&#xA; do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)&#xA; entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 147:&#xA;&#xA;Freed by task 147:&#xA;&#xA;The buggy address belongs to the object at ffff888100ef8c80&#xA; which belongs to the cache skbuff_head_cache of size 224&#xA;The buggy address is located 192 bytes inside of&#xA; freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)&#xA;&#xA;Memory state around the buggy address:&#xA; ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc&#xA; ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;&gt;ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc&#xA;                                                    ^&#xA; ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb&#xA; ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb&#xA;==================================================================&#xA;CVE-2026-43407:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()&#xA;&#xA;This patch fixes an out-of-bounds access in ceph_handle_auth_reply()&#xA;that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In&#xA;ceph_handle_auth_reply(), the value of the payload_len field of such a&#xA;message is stored in a variable of type int. A value greater than&#xA;INT_MAX leads to an integer overflow and is interpreted as a negative&#xA;value. This leads to decrementing the pointer address by this value and&#xA;subsequently accessing it because ceph_decode_need() only checks that&#xA;the memory access does not exceed the end address of the allocation.&#xA;&#xA;This patch fixes the issue by changing the data type of payload_len to&#xA;u32. Additionally, the data type of result_msg_len is changed to u32,&#xA;as it is also a variable holding a non-negative length.&#xA;&#xA;Also, an additional layer of sanity checks is introduced, ensuring that&#xA;directly after reading it from the message, payload_len and&#xA;result_msg_len are not greater than the overall segment length.&#xA;&#xA;BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]&#xA;Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262&#xA;&#xA;CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;Workqueue: ceph-msgr ceph_con_workfn [libceph]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x76/0xa0&#xA; print_report+0xd1/0x620&#xA; ? __pfx__raw_spin_lock_irqsave+0x10/0x10&#xA; ? kasan_complete_mode_report_info+0x72/0x210&#xA; kasan_report+0xe7/0x130&#xA; ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]&#xA; ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]&#xA; __asan_report_load_n_noabort+0xf/0x20&#xA; ceph_handle_auth_reply+0x642/0x7a0 [libceph]&#xA; mon_dispatch+0x973/0x23d0 [libceph]&#xA; ? apparmor_socket_recvmsg+0x6b/0xa0&#xA; ? __pfx_mon_dispatch+0x10/0x10 [libceph]&#xA; ? __kasan_check_write+0x14/0x30i&#xA; ? mutex_unlock+0x7f/0xd0&#xA; ? __pfx_mutex_unlock+0x10/0x10&#xA; ? __pfx_do_recvmsg+0x10/0x10 [libceph]&#xA; ceph_con_process_message+0x1f1/0x650 [libceph]&#xA; process_message+0x1e/0x450 [libceph]&#xA; ceph_con_v2_try_read+0x2e48/0x6c80 [libceph]&#xA; ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph]&#xA; ? save_fpregs_to_fpstate+0xb0/0x230&#xA; ? raw_spin_rq_unlock+0x17/0xa0&#xA; ? finish_task_switch.isra.0+0x13b/0x760&#xA; ? __switch_to+0x385/0xda0&#xA; ? __kasan_check_write+0x14/0x30&#xA; ? mutex_lock+0x8d/0xe0&#xA; ? __pfx_mutex_lock+0x10/0x10&#xA; ceph_con_workfn+0x248/0x10c0 [libceph]&#xA; process_one_work+0x629/0xf80&#xA; ? __kasan_check_write+0x14/0x30&#xA; worker_thread+0x87f/0x1570&#xA; ? __pfx__raw_spin_lock_irqsave+0x10/0x10&#xA; ? __pfx_try_to_wake_up+0x10/0x10&#xA; ? kasan_print_address_stack_frame+0x1f7/0x280&#xA; ? __pfx_worker_thread+0x10/0x10&#xA; kthread+0x396/0x830&#xA; ? __pfx__raw_spin_lock_irq+0x10/0x10&#xA; ? __pfx_kthread+0x10/0x10&#xA; ? __kasan_check_write+0x14/0x30&#xA; ? recalc_sigpending+0x180/0x210&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x3f7/0x610&#xA; ? __pfx_ret_from_fork+0x10/0x10&#xA; ? __switch_to+0x385/0xda0&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;&#xA;[ idryomov: replace if statements with ceph_decode_need() for&#xA;  payload_len and result_msg_len ]&#xA;CVE-2026-31781:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/ioc32: stop speculation on the drm_compat_ioctl path&#xA;&#xA;The drm compat ioctl path takes a user controlled pointer, and then&#xA;dereferences it into a table of function pointers, the signature method&#xA;of spectre problems.  Fix this up by calling array_index_nospec() on the&#xA;index to the function pointer list.&#xA;CVE-2026-31521:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;module: Fix kernel panic when a symbol st_shndx is out of bounds&#xA;&#xA;The module loader doesn&#39;t check for bounds of the ELF section index in&#xA;simplify_symbols():&#xA;&#xA;       for (i = 1; i &lt; symsec-&gt;sh_size / sizeof(Elf_Sym); i++) {&#xA;&#x9;&#x9;const char *name = info-&gt;strtab + sym[i].st_name;&#xA;&#xA;&#x9;&#x9;switch (sym[i].st_shndx) {&#xA;&#x9;&#x9;case SHN_COMMON:&#xA;&#xA;&#x9;&#x9;[...]&#xA;&#xA;&#x9;&#x9;default:&#xA;&#x9;&#x9;&#x9;/* Divert to percpu allocation if a percpu var. */&#xA;&#x9;&#x9;&#x9;if (sym[i].st_shndx == info-&gt;index.pcpu)&#xA;&#x9;&#x9;&#x9;&#x9;secbase = (unsigned long)mod_percpu(mod);&#xA;&#x9;&#x9;&#x9;else&#xA;  /** HERE --&gt; **/&#x9;&#x9;secbase = info-&gt;sechdrs[sym[i].st_shndx].sh_addr;&#xA;&#x9;&#x9;&#x9;sym[i].st_value += secbase;&#xA;&#x9;&#x9;&#x9;break;&#xA;&#x9;&#x9;}&#xA;&#x9;}&#xA;&#xA;A symbol with an out-of-bounds st_shndx value, for example 0xffff&#xA;(known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic:&#xA;&#xA;  BUG: unable to handle page fault for address: ...&#xA;  RIP: 0010:simplify_symbols+0x2b2/0x480&#xA;  ...&#xA;  Kernel panic - not syncing: Fatal exception&#xA;&#xA;This can happen when module ELF is legitimately using SHN_XINDEX or&#xA;when it is corrupted.&#xA;&#xA;Add a bounds check in simplify_symbols() to validate that st_shndx is&#xA;within the valid range before using it.&#xA;&#xA;This issue was discovered due to a bug in llvm-objcopy, see relevant&#xA;discussion for details [1].&#xA;&#xA;[1] https://lore.kernel.org/linux-modules/[email protected]/&#xA;CVE-2026-23317:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/vmwgfx: Return the correct value in vmw_translate_ptr functions&#xA;&#xA;Before the referenced fixes these functions used a lookup function that&#xA;returned a pointer. This was changed to another lookup function that&#xA;returned an error code with the pointer becoming an out parameter.&#xA;&#xA;The error path when the lookup failed was not changed to reflect this&#xA;change and the code continued to return the PTR_ERR of the now&#xA;uninitialized pointer. This could cause the vmw_translate_ptr functions&#xA;to return success when they actually failed causing further uninitialized&#xA;and OOB accesses.&#xA;CVE-2026-31698:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: ccp: Don&#39;t attempt to copy PDH cert to userspace if PSP command failed&#xA;&#xA;When retrieving the PDH cert, don&#39;t attempt to copy the blobs to userspace&#xA;if the firmware command failed.  If the failure was due to an invalid&#xA;length, i.e. the userspace buffer+length was too small, copying the number&#xA;of bytes _firmware_ requires will overflow the kernel-allocated buffer and&#xA;leak data to userspace.&#xA;&#xA;  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]&#xA;  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]&#xA;  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26&#xA;  Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033&#xA;&#xA;  CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY&#xA;  Tainted: [U]=USER, [O]=OOT_MODULE&#xA;  Hardware name: Google, Inc.                                                       Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120&#xA;   print_address_description ../mm/kasan/report.c:378 [inline]&#xA;   print_report+0xbc/0x260 ../mm/kasan/report.c:482&#xA;   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595&#xA;   check_region_inline ../mm/kasan/generic.c:-1 [inline]&#xA;   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200&#xA;   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]&#xA;   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]&#xA;   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26&#xA;   copy_to_user ../include/linux/uaccess.h:236 [inline]&#xA;   sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347&#xA;   sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568&#xA;   vfs_ioctl ../fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl ../fs/ioctl.c:597 [inline]&#xA;   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583&#xA;   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]&#xA;   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;   &lt;/TASK&gt;&#xA;&#xA;WARN if the driver says the command succeeded, but the firmware error code&#xA;says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any&#xA;firwmware error.&#xA;CVE-2026-31699:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: ccp: Don&#39;t attempt to copy CSR to userspace if PSP command failed&#xA;&#xA;When retrieving the PEK CSR, don&#39;t attempt to copy the blob to userspace&#xA;if the firmware command failed.  If the failure was due to an invalid&#xA;length, i.e. the userspace buffer+length was too small, copying the number&#xA;of bytes _firmware_ requires will overflow the kernel-allocated buffer and&#xA;leak data to userspace.&#xA;&#xA;  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]&#xA;  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]&#xA;  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26&#xA;  Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405&#xA;&#xA;  CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY&#xA;  Tainted: [U]=USER, [O]=OOT_MODULE&#xA;  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120&#xA;   print_address_description ../mm/kasan/report.c:378 [inline]&#xA;   print_report+0xbc/0x260 ../mm/kasan/report.c:482&#xA;   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595&#xA;   check_region_inline ../mm/kasan/generic.c:-1 [inline]&#xA;   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200&#xA;   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]&#xA;   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]&#xA;   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26&#xA;   copy_to_user ../include/linux/uaccess.h:236 [inline]&#xA;   sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872&#xA;   sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562&#xA;   vfs_ioctl ../fs/ioctl.c:51 [inline]&#xA;   __do_sys_ioctl ../fs/ioctl.c:597 [inline]&#xA;   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583&#xA;   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]&#xA;   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;   &lt;/TASK&gt;&#xA;&#xA;WARN if the driver says the command succeeded, but the firmware error code&#xA;says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any&#xA;firwmware error.&#xA;CVE-2026-31778:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: caiaq: fix stack out-of-bounds read in init_card&#xA;&#xA;The loop creates a whitespace-stripped copy of the card shortname&#xA;where `len &lt; sizeof(card-&gt;id)` is used for the bounds check. Since&#xA;sizeof(card-&gt;id) is 16 and the local id buffer is also 16 bytes,&#xA;writing 16 non-space characters fills the entire buffer,&#xA;overwriting the terminating nullbyte.&#xA;&#xA;When this non-null-terminated string is later passed to&#xA;snd_card_set_id() -&gt; copy_valid_id_string(), the function scans&#xA;forward with `while (*nid &amp;&amp; ...)` and reads past the end of the&#xA;stack buffer, reading the contents of the stack.&#xA;&#xA;A USB device with a product name containing many non-ASCII, non-space&#xA;characters (e.g. multibyte UTF-8) will reliably trigger this as follows:&#xA;&#xA;  BUG: KASAN: stack-out-of-bounds in copy_valid_id_string&#xA;       sound/core/init.c:696 [inline]&#xA;  BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c&#xA;       sound/core/init.c:718&#xA;&#xA;The off-by-one has been present since commit bafeee5b1f8d (&#34;ALSA:&#xA;snd_usb_caiaq: give better shortname&#34;) from June 2009 (v2.6.31-rc1),&#xA;which first introduced this whitespace-stripping loop. The original&#xA;code never accounted for the null terminator when bounding the copy.&#xA;&#xA;Fix this by changing the loop bound to `sizeof(card-&gt;id) - 1`,&#xA;ensuring at least one byte remains as the null terminator.&#xA;CVE-2026-31441:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: idxd: Fix memory leak when a wq is reset&#xA;&#xA;idxd_wq_disable_cleanup() which is called from the reset path for a&#xA;workqueue, sets the wq type to NONE, which for other parts of the&#xA;driver mean that the wq is empty (all its resources were released).&#xA;&#xA;Only set the wq type to NONE after its resources are released.&#xA;CVE-2026-31630:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rxrpc: proc: size address buffers for %pISpc output&#xA;&#xA;The AF_RXRPC procfs helpers format local and remote socket addresses into&#xA;fixed 50-byte stack buffers with &#34;%pISpc&#34;.&#xA;&#xA;That is too small for the longest current-tree IPv6-with-port form the&#xA;formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a&#xA;dotted-quad tail not only for v4mapped addresses, but also for ISATAP&#xA;addresses via ipv6_addr_is_isatap().&#xA;&#xA;As a result, a case such as&#xA;&#xA;  [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535&#xA;&#xA;is possible with the current formatter. That is 50 visible characters, so&#xA;51 bytes including the trailing NUL, which does not fit in the existing&#xA;char[50] buffers used by net/rxrpc/proc.c.&#xA;&#xA;Size the buffers from the formatter&#39;s maximum textual form and switch the&#xA;call sites to scnprintf().&#xA;&#xA;Changes since v1:&#xA;- correct the changelog to cite the actual maximum current-tree case&#xA;  explicitly&#xA;- frame the proof around the ISATAP formatting path instead of the earlier&#xA;  mapped-v4 example&#xA;CVE-2026-31667:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Input: uinput - fix circular locking dependency with ff-core&#xA;&#xA;A lockdep circular locking dependency warning can be triggered&#xA;reproducibly when using a force-feedback gamepad with uinput (for&#xA;example, playing ELDEN RING under Wine with a Flydigi Vader 5&#xA;controller):&#xA;&#xA;  ff-&gt;mutex -&gt; udev-&gt;mutex -&gt; input_mutex -&gt; dev-&gt;mutex -&gt; ff-&gt;mutex&#xA;&#xA;The cycle is caused by four lock acquisition paths:&#xA;&#xA;1. ff upload: input_ff_upload() holds ff-&gt;mutex and calls&#xA;   uinput_dev_upload_effect() -&gt; uinput_request_submit() -&gt;&#xA;   uinput_request_send(), which acquires udev-&gt;mutex.&#xA;&#xA;2. device create: uinput_ioctl_handler() holds udev-&gt;mutex and calls&#xA;   uinput_create_device() -&gt; input_register_device(), which acquires&#xA;   input_mutex.&#xA;&#xA;3. device register: input_register_device() holds input_mutex and&#xA;   calls kbd_connect() -&gt; input_register_handle(), which acquires&#xA;   dev-&gt;mutex.&#xA;&#xA;4. evdev release: evdev_release() calls input_flush_device() under&#xA;   dev-&gt;mutex, which calls input_ff_flush() acquiring ff-&gt;mutex.&#xA;&#xA;Fix this by introducing a new state_lock spinlock to protect&#xA;udev-&gt;state and udev-&gt;dev access in uinput_request_send() instead of&#xA;acquiring udev-&gt;mutex.  The function only needs to atomically check&#xA;device state and queue an input event into the ring buffer via&#xA;uinput_dev_event() -- both operations are safe under a spinlock&#xA;(ktime_get_ts64() and wake_up_interruptible() do not sleep).  This&#xA;breaks the ff-&gt;mutex -&gt; udev-&gt;mutex link since a spinlock is a leaf in&#xA;the lock ordering and cannot form cycles with mutexes.&#xA;&#xA;To keep state transitions visible to uinput_request_send(), protect&#xA;writes to udev-&gt;state in uinput_create_device() and&#xA;uinput_destroy_device() with the same state_lock spinlock.&#xA;&#xA;Additionally, move init_completion(&amp;request-&gt;done) from&#xA;uinput_request_send() to uinput_request_submit() before&#xA;uinput_request_reserve_slot().  Once the slot is allocated,&#xA;uinput_flush_requests() may call complete() on it at any time from&#xA;the destroy path, so the completion must be initialised before the&#xA;request becomes visible.&#xA;&#xA;Lock ordering after the fix:&#xA;&#xA;  ff-&gt;mutex -&gt; state_lock (spinlock, leaf)&#xA;  udev-&gt;mutex -&gt; state_lock (spinlock, leaf)&#xA;  udev-&gt;mutex -&gt; input_mutex -&gt; dev-&gt;mutex -&gt; ff-&gt;mutex (no back-edge)&#xA;CVE-2026-43171:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;EFI/CPER: don&#39;t dump the entire memory region&#xA;&#xA;The current logic at cper_print_fw_err() doesn&#39;t check if the&#xA;error record length is big enough to handle offset. On a bad firmware,&#xA;if the ofset is above the actual record, length -= offset will&#xA;underflow, making it dump the entire memory.&#xA;&#xA;The end result can be:&#xA;&#xA; - the logic taking a lot of time dumping large regions of memory;&#xA; - data disclosure due to the memory dumps;&#xA; - an OOPS, if it tries to dump an unmapped memory region.&#xA;&#xA;Fix it by checking if the section length is too small before doing&#xA;a hex dump.&#xA;&#xA;[ rjw: Subject tweaks ]&#xA;CVE-2026-43049:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure&#xA;&#xA;Presently, if the force feedback initialisation fails when probing the&#xA;Logitech G920 Driving Force Racing Wheel for Xbox One, an error number&#xA;will be returned and propagated before the userspace infrastructure&#xA;(sysfs and /dev/input) has been torn down.  If userspace ignores the&#xA;errors and continues to use its references to these dangling entities, a&#xA;UAF will promptly follow.&#xA;&#xA;We have 2 options; continue to return the error, but ensure that all of&#xA;the infrastructure is torn down accordingly or continue to treat this&#xA;condition as a warning by emitting the message but returning success.&#xA;It is thought that the original author&#39;s intention was to emit the&#xA;warning but keep the device functional, less the force feedback feature,&#xA;so let&#39;s go with that.&#xA;CVE-2026-31773:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: SMP: derive legacy responder STK authentication from MITM state&#xA;&#xA;The legacy responder path in smp_random() currently labels the stored&#xA;STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.&#xA;That reflects what the local service requested, not what the pairing&#xA;flow actually achieved.&#xA;&#xA;For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear&#xA;and the resulting STK should remain unauthenticated even if the local&#xA;side requested HIGH security. Use the established MITM state when&#xA;storing the responder STK so the key metadata matches the pairing result.&#xA;&#xA;This also keeps the legacy path aligned with the Secure Connections code,&#xA;which already treats JUST_WORKS/JUST_CFM as unauthenticated.&#xA;CVE-2026-31619:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: fireworks: bound device-supplied status before string array lookup&#xA;&#xA;The status field in an EFW response is a 32-bit value supplied by the&#xA;firewire device.  efr_status_names[] has 17 entries so a status value&#xA;outside that range goes off into the weeds when looking at the %s value.&#xA;&#xA;Even worse, the status could return EFR_STATUS_INCOMPLETE which is&#xA;0x80000000, and is obviously not in that array of potential strings.&#xA;&#xA;Fix this up by properly bounding the index against the array size and&#xA;printing &#34;unknown&#34; if it&#39;s not recognized.&#xA;CVE-2025-38685:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: Fix vmalloc out-of-bounds write in fast_imageblit&#xA;&#xA;This issue triggers when a userspace program does an ioctl&#xA;FBIOPUT_CON2FBMAP by passing console number and frame buffer number.&#xA;Ideally this maps console to frame buffer and updates the screen if&#xA;console is visible.&#xA;&#xA;As part of mapping it has to do resize of console according to frame&#xA;buffer info. if this resize fails and returns from vc_do_resize() and&#xA;continues further. At this point console and new frame buffer are mapped&#xA;and sets display vars. Despite failure still it continue to proceed&#xA;updating the screen at later stages where vc_data is related to previous&#xA;frame buffer and frame buffer info and display vars are mapped to new&#xA;frame buffer and eventully leading to out-of-bounds write in&#xA;fast_imageblit(). This bheviour is excepted only when fg_console is&#xA;equal to requested console which is a visible console and updates screen&#xA;with invalid struct references in fbcon_putcs().&#xA;CVE-2025-38680:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()&#xA;&#xA;The buffer length check before calling uvc_parse_format() only ensured&#xA;that the buffer has at least 3 bytes (buflen &gt; 2), buf the function&#xA;accesses buffer[3], requiring at least 4 bytes.&#xA;&#xA;This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.&#xA;&#xA;Fix it by checking that the buffer has at least 4 bytes in&#xA;uvc_parse_format().&#xA;CVE-2026-43064:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: idxd: Fix not releasing workqueue on .release()&#xA;&#xA;The workqueue associated with an DSA/IAA device is not released when&#xA;the object is freed.&#xA;CVE-2026-31777:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: ctxfi: Check the error for index mapping&#xA;&#xA;The ctxfi driver blindly assumed a proper value returned from&#xA;daio_device_index(), but it&#39;s not always true.  Add a proper error&#xA;check to deal with the error from the function.&#xA;CVE-2026-31527:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;driver core: platform: use generic driver_override infrastructure&#xA;&#xA;When a driver is probed through __driver_attach(), the bus&#39; match()&#xA;callback is called without the device lock held, thus accessing the&#xA;driver_override field without a lock, which can cause a UAF.&#xA;&#xA;Fix this by using the driver-core driver_override infrastructure taking&#xA;care of proper locking internally.&#xA;&#xA;Note that calling match() from __driver_attach() without the device lock&#xA;held is intentional. [1]&#xA;CVE-2026-43020:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: MGMT: validate LTK enc_size on load&#xA;&#xA;Load Long Term Keys stores the user-provided enc_size and later uses&#xA;it to size fixed-size stack operations when replying to LE LTK&#xA;requests. An enc_size larger than the 16-byte key buffer can therefore&#xA;overflow the reply stack buffer.&#xA;&#xA;Reject oversized enc_size values while validating the management LTK&#xA;record so invalid keys never reach the stored key state.&#xA;CVE-2026-43047:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: multitouch: Check to ensure report responses match the request&#xA;&#xA;It is possible for a malicious (or clumsy) device to respond to a&#xA;specific report&#39;s feature request using a completely different report&#xA;ID.  This can cause confusion in the HID core resulting in nasty&#xA;side-effects such as OOB writes.&#xA;&#xA;Add a check to ensure that the report ID in the response, matches the&#xA;one that was requested.  If it doesn&#39;t, omit reporting the raw event and&#xA;return early.&#xA;CVE-2026-43048:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: core: Mitigate potential OOB by removing bogus memset()&#xA;&#xA;The memset() in hid_report_raw_event() has the good intention of&#xA;clearing out bogus data by zeroing the area from the end of the incoming&#xA;data string to the assumed end of the buffer.  However, as we have&#xA;previously seen, doing so can easily result in OOB reads and writes in&#xA;the subsequent thread of execution.&#xA;&#xA;The current suggestion from one of the HID maintainers is to remove the&#xA;memset() and simply return if the incoming event buffer size is not&#xA;large enough to fill the associated report.&#xA;&#xA;Suggested-by Benjamin Tissoires &lt;[email protected]&gt;&#xA;&#xA;[bentiss: changed the return value]&#xA;CVE-2026-31447:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: reject mount if bigalloc with s_first_data_block != 0&#xA;&#xA;bigalloc with s_first_data_block != 0 is not supported, reject mounting&#xA;it.&#xA;CVE-2026-31771:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: hci_event: move wake reason storage into validated event handlers&#xA;&#xA;hci_store_wake_reason() is called from hci_event_packet() immediately&#xA;after stripping the HCI event header but before hci_event_func()&#xA;enforces the per-event minimum payload length from hci_ev_table.&#xA;This means a short HCI event frame can reach bacpy() before any bounds&#xA;check runs.&#xA;&#xA;Rather than duplicating skb parsing and per-event length checks inside&#xA;hci_store_wake_reason(), move wake-address storage into the individual&#xA;event handlers after their existing event-length validation has&#xA;succeeded. Convert hci_store_wake_reason() into a small helper that only&#xA;stores an already-validated bdaddr while the caller holds hci_dev_lock().&#xA;Use the same helper after hci_event_func() with a NULL address to&#xA;preserve the existing unexpected-wake fallback semantics when no&#xA;validated event handler records a wake address.&#xA;&#xA;Annotate the helper with __must_hold(&amp;hdev-&gt;lock) and add&#xA;lockdep_assert_held(&amp;hdev-&gt;lock) so future call paths keep the lock&#xA;contract explicit.&#xA;&#xA;Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(),&#xA;hci_sync_conn_complete_evt(), le_conn_complete_evt(),&#xA;hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),&#xA;hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and&#xA;hci_le_past_received_evt().&#xA;CVE-2026-31708:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path&#xA;&#xA;smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL&#xA;and the default QUERY_INFO path.  The QUERY_INFO branch clamps&#xA;qi.input_buffer_length to the server-reported OutputBufferLength and then&#xA;copies qi.input_buffer_length bytes from qi_rsp-&gt;Buffer to userspace, but&#xA;it never verifies that the flexible-array payload actually fits within&#xA;rsp_iov[1].iov_len.&#xA;&#xA;A malicious server can return OutputBufferLength larger than the actual&#xA;QUERY_INFO response, causing copy_to_user() to walk past the response&#xA;buffer and expose adjacent kernel heap to userspace.&#xA;&#xA;Guard the QUERY_INFO copy with a bounds check on the actual Buffer&#xA;payload.  Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)&#xA;rather than an open-coded addition so the guard cannot overflow on&#xA;32-bit builds.&#xA;CVE-2026-31704:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: use check_add_overflow() to prevent u16 DACL size overflow&#xA;&#xA;set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes&#xA;in u16 variables. When a file has many POSIX ACL entries, the&#xA;accumulated size can wrap past 65535, causing the pointer arithmetic&#xA;(char *)pndace + *size to land within already-written ACEs. Subsequent&#xA;writes then overwrite earlier entries, and pndacl-&gt;size gets a&#xA;truncated value.&#xA;&#xA;Use check_add_overflow() at each accumulation point to detect the&#xA;wrap before it corrupts the buffer, consistent with existing&#xA;check_mul_overflow() usage elsewhere in smbacl.c.&#xA;CVE-2026-31712:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: require minimum ACE size in smb_check_perm_dacl()&#xA;&#xA;Both ACE-walk loops in smb_check_perm_dacl() only guard against an&#xA;under-sized remaining buffer, not against an ACE whose declared&#xA;`ace-&gt;size` is smaller than the struct it claims to describe:&#xA;&#xA;  if (offsetof(struct smb_ace, access_req) &gt; aces_size)&#xA;      break;&#xA;  ace_size = le16_to_cpu(ace-&gt;size);&#xA;  if (ace_size &gt; aces_size)&#xA;      break;&#xA;&#xA;The first check only requires the 4-byte ACE header to be in bounds;&#xA;it does not require access_req (4 bytes at offset 4) to be readable.&#xA;An attacker who has set a crafted DACL on a file they own can declare&#xA;ace-&gt;size == 4 with aces_size == 4, pass both checks, and then&#xA;&#xA;  granted |= le32_to_cpu(ace-&gt;access_req);               /* upper loop */&#xA;  compare_sids(&amp;sid, &amp;ace-&gt;sid);                         /* lower loop */&#xA;&#xA;reads access_req at offset 4 (OOB by up to 4 bytes) and ace-&gt;sid at&#xA;offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES&#xA;* 4 bytes).&#xA;&#xA;Tighten both loops to require&#xA;&#xA;  ace_size &gt;= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE&#xA;&#xA;which is the smallest valid on-wire ACE layout (4-byte header +&#xA;4-byte access_req + 8-byte sid base with zero sub-auths).  Also&#xA;reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES&#xA;before letting compare_sids() dereference sub_auth[] entries.&#xA;&#xA;parse_sec_desc() already enforces an equivalent check (lines 441-448);&#xA;smb_check_perm_dacl() simply grew weaker validation over time.&#xA;&#xA;Reachability: authenticated SMB client with permission to set an ACL&#xA;on a file.  On a subsequent CREATE against that file, the kernel&#xA;walks the stored DACL via smb_check_perm_dacl() and triggers the&#xA;OOB read.  Not pre-auth, and the OOB read is not reflected to the&#xA;attacker, but KASAN reports and kernel state corruption are&#xA;possible.&#xA;CVE-2026-46333:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ptrace: slightly saner &#39;get_dumpable()&#39; logic&#xA;&#xA;The &#39;dumpability&#39; of a task is fundamentally about the memory image of&#xA;the task - the concept comes from whether it can core dump or not - and&#xA;makes no sense when you don&#39;t have an associated mm.&#xA;&#xA;And almost all users do in fact use it only for the case where the task&#xA;has a mm pointer.&#xA;&#xA;But we have one odd special case: ptrace_may_access() uses &#39;dumpable&#39; to&#xA;check various other things entirely independently of the MM (typically&#xA;explicitly using flags like PTRACE_MODE_READ_FSCREDS).  Including for&#xA;threads that no longer have a VM (and maybe never did, like most kernel&#xA;threads).&#xA;&#xA;It&#39;s not what this flag was designed for, but it is what it is.&#xA;&#xA;The ptrace code does check that the uid/gid matches, so you do have to&#xA;be uid-0 to see kernel thread details, but this means that the&#xA;traditional &#34;drop capabilities&#34; model doesn&#39;t make any difference for&#xA;this all.&#xA;&#xA;Make it all make a *bit* more sense by saying that if you don&#39;t have a&#xA;MM pointer, we&#39;ll use a cached &#34;last dumpability&#34; flag if the thread&#xA;ever had a MM (it will be zero for kernel threads since it is never&#xA;set), and require a proper CAP_SYS_PTRACE capability to override.&#xA;CVE-2026-31611:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: require 3 sub-authorities before reading sub_auth[2]&#xA;&#xA;parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on&#xA;match reads sid.sub_auth[2] as the file mode.  If sid_unix_NFS_mode is&#xA;the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares&#xA;only min(num_subauth, 2) sub-authorities so a client SID with&#xA;num_subauth = 2 and sub_auth = {88, 3} will match.&#xA;&#xA;If num_subauth = 2 and the ACE is placed at the very end of the security&#xA;descriptor, sub_auth[2] will be  4 bytes past end_of_acl.  The&#xA;out-of-band bytes will then be masked to the low 9 bits and applied as&#xA;the file&#39;s POSIX mode, probably not something that is good to have&#xA;happen.&#xA;&#xA;Fix this up by forcing the SID to actually carry a third sub-authority&#xA;before reading it at all.&#xA;CVE-2026-31612:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: validate EaNameLength in smb2_get_ea()&#xA;&#xA;smb2_get_ea() reads ea_req-&gt;EaNameLength from the client request and&#xA;passes it directly to strncmp() as the comparison length without&#xA;verifying that the length of the name really is the size of the input&#xA;buffer received.&#xA;&#xA;Fix this up by properly checking the size of the name based on the value&#xA;received and the overall size of the request, to prevent a later&#xA;strncmp() call to use the length as a &#34;trusted&#34; size of the buffer.&#xA;Without this check, uninitialized heap values might be slowly leaked to&#xA;the client.&#xA;CVE-2026-31477:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: fix memory leaks and NULL deref in smb2_lock()&#xA;&#xA;smb2_lock() has three error handling issues after list_del() detaches&#xA;smb_lock from lock_list at no_check_cl:&#xA;&#xA;1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK&#xA;   path, goto out leaks smb_lock and its flock because the out:&#xA;   handler only iterates lock_list and rollback_list, neither of&#xA;   which contains the detached smb_lock.&#xA;&#xA;2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out&#xA;   leaks smb_lock and flock for the same reason.  The error code&#xA;   returned to the dispatcher is also stale.&#xA;&#xA;3) In the rollback path, smb_flock_init() can return NULL on&#xA;   allocation failure.  The result is dereferenced unconditionally,&#xA;   causing a kernel NULL pointer dereference.  Add a NULL check to&#xA;   prevent the crash and clean up the bookkeeping; the VFS lock&#xA;   itself cannot be rolled back without the allocation and will be&#xA;   released at file or connection teardown.&#xA;&#xA;Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before&#xA;the if(!rc) check in the UNLOCK branch so all exit paths share one&#xA;free site, and by freeing smb_lock and flock before goto out in the&#xA;non-UNLOCK branch.  Propagate the correct error code in both cases.&#xA;Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding&#xA;a NULL check for locks_free_lock(rlock) in the shared cleanup.&#xA;&#xA;Found via call-graph analysis using sqry.&#xA;CVE-2026-31755:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: cdns3: gadget: fix NULL pointer dereference in ep_queue&#xA;&#xA;When the gadget endpoint is disabled or not yet configured, the ep-&gt;desc&#xA;pointer can be NULL. This leads to a NULL pointer dereference when&#xA;__cdns3_gadget_ep_queue() is called, causing a kernel crash.&#xA;&#xA;Add a check to return -ESHUTDOWN if ep-&gt;desc is NULL, which is the&#xA;standard return code for unconfigured endpoints.&#xA;&#xA;This prevents potential crashes when ep_queue is called on endpoints&#xA;that are not ready.&#xA;CVE-2026-43261:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64: Add support for TSV110 Spectre-BHB mitigation&#xA;&#xA;The TSV110 processor is vulnerable to the Spectre-BHB (Branch History&#xA;Buffer) attack, which can be exploited to leak information through&#xA;branch prediction side channels. This commit adds the MIDR of TSV110&#xA;to the list for software mitigation.&#xA;CVE-2026-43212:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE&#xA;&#xA;The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -&#xA;which is a valid index - so add a check for this.&#xA;CVE-2026-43488:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: xhci: Prevent interrupt storm on host controller error (HCE)&#xA;&#xA;The xHCI controller reports a Host Controller Error (HCE) in UAS Storage&#xA;Device plug/unplug scenarios on Android devices. HCE is checked in&#xA;xhci_irq() function and causes an interrupt storm (since the interrupt&#xA;isn’t cleared), leading to severe system-level faults.&#xA;&#xA;When the xHC controller reports HCE in the interrupt handler, the driver&#xA;only logs a warning and assumes xHC activity will stop as stated in xHCI&#xA;specification. An interrupt storm does however continue on some hosts&#xA;even after HCE, and only ceases after manually disabling xHC interrupt&#xA;and stopping the controller by calling xhci_halt().&#xA;&#xA;Add xhci_halt() to xhci_irq() function where STS_HCE status is checked,&#xA;mirroring the existing error handling pattern used for STS_FATAL errors.&#xA;&#xA;This only fixes the interrupt storm. Proper HCE recovery requires resetting&#xA;and re-initializing the xHC.&#xA;CVE-2026-43427:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: class: cdc-wdm: fix reordering issue in read code path&#xA;&#xA;Quoting the bug report:&#xA;&#xA;Due to compiler optimization or CPU out-of-order execution, the&#xA;desc-&gt;length update can be reordered before the memmove. If this&#xA;happens, wdm_read() can see the new length and call copy_to_user() on&#xA;uninitialized memory. This also violates LKMM data race rules [1].&#xA;&#xA;Fix it by using WRITE_ONCE and memory barriers.&#xA;CVE-2026-43428:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;USB: core: Limit the length of unkillable synchronous timeouts&#xA;&#xA;The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in&#xA;usbcore allow unlimited timeout durations.  And since they use&#xA;uninterruptible waits, this leaves open the possibility of hanging a&#xA;task for an indefinitely long time, with no way to kill it short of&#xA;unplugging the target device.&#xA;&#xA;To prevent this sort of problem, enforce a maximum limit on the length&#xA;of these unkillable timeouts.  The limit chosen here, somewhat&#xA;arbitrarily, is 60 seconds.  On many systems (although not all) this&#xA;is short enough to avoid triggering the kernel&#39;s hung-task detector.&#xA;&#xA;In addition, clear up the ambiguity of negative timeout values by&#xA;treating them the same as 0, i.e., using the maximum allowed timeout.&#xA;CVE-2026-23395:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ&#xA;&#xA;Currently the code attempts to accept requests regardless of the&#xA;command identifier which may cause multiple requests to be marked&#xA;as pending (FLAG_DEFER_SETUP) which can cause more than&#xA;L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer&#xA;causing an overflow.&#xA;&#xA;The spec is quite clear that the same identifier shall not be used on&#xA;subsequent requests:&#xA;&#xA;&#39;Within each signaling channel a different Identifier shall be used&#xA;for each successive request or indication.&#39;&#xA;https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d&#xA;&#xA;So this attempts to check if there are any channels pending with the&#xA;same identifier and rejects if any are found.&#xA;CVE-2026-31668:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;seg6: separate dst_cache for input and output paths in seg6 lwtunnel&#xA;&#xA;The seg6 lwtunnel uses a single dst_cache per encap route, shared&#xA;between seg6_input_core() and seg6_output_core(). These two paths&#xA;can perform the post-encap SID lookup in different routing contexts&#xA;(e.g., ip rules matching on the ingress interface, or VRF table&#xA;separation). Whichever path runs first populates the cache, and the&#xA;other reuses it blindly, bypassing its own lookup.&#xA;&#xA;Fix this by splitting the cache into cache_input and cache_output,&#xA;so each path maintains its own cached dst independently.&#xA;CVE-2026-43134:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ&#xA;&#xA;This adds a check for encryption key size upon receiving&#xA;L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which&#xA;expects L2CAP_CR_LE_BAD_KEY_SIZE.&#xA;CVE-2026-43281:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()&#xA;&#xA;Although it is guided that `#mbox-cells` must be at least 1, there are&#xA;many instances of `#mbox-cells = &lt;0&gt;;` in the device tree. If that is&#xA;the case and the corresponding mailbox controller does not provide&#xA;`fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will&#xA;be used by default and out-of-bounds accesses could occur due to lack of&#xA;bounds check in that function.&#xA;CVE-2026-43117:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()&#xA;&#xA;If overlay is used on top of btrfs, dentry-&gt;d_sb translates to overlay&#39;s&#xA;super block and fsid assignment will lead to a crash.&#xA;&#xA;Use file_inode(file)-&gt;i_sb to always get btrfs_sb.&#xA;CVE-2026-43493:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: pcrypt - Fix handling of MAY_BACKLOG requests&#xA;&#xA;MAY_BACKLOG requests can return EBUSY.  Handle them by checking&#xA;for that value and filtering out EINPROGRESS notifications.&#xA;CVE-2026-43040:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak&#xA;&#xA;When processing Router Advertisements with user options the kernel&#xA;builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct&#xA;has three padding fields that are never zeroed and can leak kernel data&#xA;&#xA;The fix is simple, just zeroes the padding fields.&#xA;CVE-2026-43038:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: icmp: clear skb2-&gt;cb[] in ip6_err_gen_icmpv6_unreach()&#xA;&#xA;Sashiko AI-review observed:&#xA;&#xA;  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet&#xA;  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2&#xA;  and passed to icmp6_send(), it uses IP6CB(skb2).&#xA;&#xA;  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso&#xA;  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm&#xA;  at offset 18.&#xA;&#xA;  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao&#xA;  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called&#xA;  and uses ipv6_find_tlv(skb, opt-&gt;dsthao, IPV6_TLV_HAO).&#xA;&#xA;  This would scan the inner, attacker-controlled IPv6 packet starting at that&#xA;  offset, potentially returning a fake TLV without checking if the remaining&#xA;  packet length can hold the full 18-byte struct ipv6_destopt_hao.&#xA;&#xA;  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end&#xA;  of the packet data into skb_shared_info?&#xA;&#xA;  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and&#xA;  ip6ip6_err() to prevent this?&#xA;&#xA;This patch implements the first suggestion.&#xA;&#xA;I am not sure if ip6ip6_err() needs to be changed.&#xA;A separate patch would be better anyway.&#xA;CVE-2026-43037:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ip6_tunnel: clear skb2-&gt;cb[] in ip4ip6_err()&#xA;&#xA;Oskar Kjos reported the following problem.&#xA;&#xA;ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written&#xA;by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes&#xA;IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region&#xA;as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff&#xA;at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr&#xA;value. __ip_options_echo() then reads optlen from attacker-controlled&#xA;packet data at sptr[rr+1] and copies that many bytes into dopt-&gt;__data,&#xA;a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).&#xA;&#xA;To fix this we clear skb2-&gt;cb[], as suggested by Oskar Kjos.&#xA;&#xA;Also add minimal IPv4 header validation (version == 4, ihl &gt;= 5).&#xA;CVE-2026-31729:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: ucsi: validate connector number in ucsi_notify_common()&#xA;&#xA;The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a&#xA;7-bit field (0-127) that is used to index into the connector array in&#xA;ucsi_connector_change(). However, the array is only allocated for the&#xA;number of connectors reported by the device (typically 2-4 entries).&#xA;&#xA;A malicious or malfunctioning device could report an out-of-range&#xA;connector number in the CCI, causing an out-of-bounds array access in&#xA;ucsi_connector_change().&#xA;&#xA;Add a bounds check in ucsi_notify_common(), the central point where CCI&#xA;is parsed after arriving from hardware, so that bogus connector numbers&#xA;are rejected before they propagate further.&#xA;CVE-2021-47452:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: skip netdev events generated on netns removal&#xA;&#xA;syzbot reported following (harmless) WARN:&#xA;&#xA; WARNING: CPU: 1 PID: 2648 at net/netfilter/core.c:468&#xA;  nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [inline]&#xA;  nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [inline]&#xA;  __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524&#xA;  nft_netdev_event net/netfilter/nft_chain_filter.c:351 [inline]&#xA;  nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382&#xA;&#xA;reproducer:&#xA;unshare -n bash -c &#39;ip link add br0 type bridge; nft add table netdev t ; \&#xA; nft add chain netdev t ingress \{ type filter hook ingress device &#34;br0&#34; \&#xA; priority 0\; policy drop\; \}&#39;&#xA;&#xA;Problem is that when netns device exit hooks create the UNREGISTER&#xA;event, the .pre_exit hook for nf_tables core has already removed the&#xA;base hook.  Notifier attempts to do this again.&#xA;&#xA;The need to do base hook unregister unconditionally was needed in the past,&#xA;because notifier was last stage where reg-&gt;dev dereference was safe.&#xA;&#xA;Now that nf_tables does the hook removal in .pre_exit, this isn&#39;t&#xA;needed anymore.&#xA;CVE-2021-47508:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: free exchange changeset on failures&#xA;&#xA;Fstests runs on my VMs have show several kmemleak reports like the following.&#xA;&#xA;  unreferenced object 0xffff88811ae59080 (size 64):&#xA;    comm &#34;xfs_io&#34;, pid 12124, jiffies 4294987392 (age 6.368s)&#xA;    hex dump (first 32 bytes):&#xA;      00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00 00  ................&#xA;      90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff  ................&#xA;    backtrace:&#xA;      [&lt;00000000ac0176d2&gt;] ulist_add_merge+0x60/0x150 [btrfs]&#xA;      [&lt;0000000076e9f312&gt;] set_state_bits+0x86/0xc0 [btrfs]&#xA;      [&lt;0000000014fe73d6&gt;] set_extent_bit+0x270/0x690 [btrfs]&#xA;      [&lt;000000004f675208&gt;] set_record_extent_bits+0x19/0x20 [btrfs]&#xA;      [&lt;00000000b96137b1&gt;] qgroup_reserve_data+0x274/0x310 [btrfs]&#xA;      [&lt;0000000057e9dcbb&gt;] btrfs_check_data_free_space+0x5c/0xa0 [btrfs]&#xA;      [&lt;0000000019c4511d&gt;] btrfs_delalloc_reserve_space+0x1b/0xa0 [btrfs]&#xA;      [&lt;000000006d37e007&gt;] btrfs_dio_iomap_begin+0x415/0x970 [btrfs]&#xA;      [&lt;00000000fb8a74b8&gt;] iomap_iter+0x161/0x1e0&#xA;      [&lt;0000000071dff6ff&gt;] __iomap_dio_rw+0x1df/0x700&#xA;      [&lt;000000002567ba53&gt;] iomap_dio_rw+0x5/0x20&#xA;      [&lt;0000000072e555f8&gt;] btrfs_file_write_iter+0x290/0x530 [btrfs]&#xA;      [&lt;000000005eb3d845&gt;] new_sync_write+0x106/0x180&#xA;      [&lt;000000003fb505bf&gt;] vfs_write+0x24d/0x2f0&#xA;      [&lt;000000009bb57d37&gt;] __x64_sys_pwrite64+0x69/0xa0&#xA;      [&lt;000000003eba3fdf&gt;] do_syscall_64+0x43/0x90&#xA;&#xA;In case brtfs_qgroup_reserve_data() or btrfs_delalloc_reserve_metadata()&#xA;fail the allocated extent_changeset will not be freed.&#xA;&#xA;So in btrfs_check_data_free_space() and btrfs_delalloc_reserve_space()&#xA;free the allocated extent_changeset to get rid of the allocated memory.&#xA;&#xA;The issue currently only happens in the direct IO write path, but only&#xA;after 65b3c08606e5 (&#34;btrfs: fix ENOSPC failure when attempting direct IO&#xA;write into NOCOW range&#34;), and also at defrag_one_locked_target(). Every&#xA;other place is always calling extent_changeset_free() even if its call&#xA;to btrfs_delalloc_reserve_space() or btrfs_check_data_free_space() has&#xA;failed.&#xA;CVE-2022-49046:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i2c: dev: check return value when calling dev_set_name()&#xA;&#xA;If dev_set_name() fails, the dev_name() is null, check the return&#xA;value of dev_set_name() to avoid the null-ptr-deref.&#xA;CVE-2022-49063:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ice: arfs: fix use-after-free when freeing @rx_cpu_rmap&#xA;&#xA;The CI testing bots triggered the following splat:&#xA;&#xA;[  718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80&#xA;[  718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834&#xA;[  718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S      W IOE     5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1&#xA;[  718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020&#xA;[  718.223418] Call Trace:&#xA;[  718.227139]&#xA;[  718.230783]  dump_stack_lvl+0x33/0x42&#xA;[  718.234431]  print_address_description.constprop.9+0x21/0x170&#xA;[  718.238177]  ? free_irq_cpu_rmap+0x53/0x80&#xA;[  718.241885]  ? free_irq_cpu_rmap+0x53/0x80&#xA;[  718.245539]  kasan_report.cold.18+0x7f/0x11b&#xA;[  718.249197]  ? free_irq_cpu_rmap+0x53/0x80&#xA;[  718.252852]  free_irq_cpu_rmap+0x53/0x80&#xA;[  718.256471]  ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice]&#xA;[  718.260174]  ice_remove_arfs+0x5f/0x70 [ice]&#xA;[  718.263810]  ice_rebuild_arfs+0x3b/0x70 [ice]&#xA;[  718.267419]  ice_rebuild+0x39c/0xb60 [ice]&#xA;[  718.270974]  ? asm_sysvec_apic_timer_interrupt+0x12/0x20&#xA;[  718.274472]  ? ice_init_phy_user_cfg+0x360/0x360 [ice]&#xA;[  718.278033]  ? delay_tsc+0x4a/0xb0&#xA;[  718.281513]  ? preempt_count_sub+0x14/0xc0&#xA;[  718.284984]  ? delay_tsc+0x8f/0xb0&#xA;[  718.288463]  ice_do_reset+0x92/0xf0 [ice]&#xA;[  718.292014]  ice_pci_err_resume+0x91/0xf0 [ice]&#xA;[  718.295561]  pci_reset_function+0x53/0x80&#xA;&lt;...&gt;&#xA;[  718.393035] Allocated by task 690:&#xA;[  718.433497] Freed by task 20834:&#xA;[  718.495688] Last potentially related work creation:&#xA;[  718.568966] The buggy address belongs to the object at ffff8881bd127e00&#xA;                which belongs to the cache kmalloc-96 of size 96&#xA;[  718.574085] The buggy address is located 0 bytes inside of&#xA;                96-byte region [ffff8881bd127e00, ffff8881bd127e60)&#xA;[  718.579265] The buggy address belongs to the page:&#xA;[  718.598905] Memory state around the buggy address:&#xA;[  718.601809]  ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc&#xA;[  718.604796]  ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc&#xA;[  718.607794] &gt;ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc&#xA;[  718.610811]                    ^&#xA;[  718.613819]  ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc&#xA;[  718.617107]  ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc&#xA;&#xA;This is due to that free_irq_cpu_rmap() is always being called&#xA;*after* (devm_)free_irq() and thus it tries to work with IRQ descs&#xA;already freed. For example, on device reset the driver frees the&#xA;rmap right before allocating a new one (the splat above).&#xA;Make rmap creation and freeing function symmetrical with&#xA;{request,free}_irq() calls i.e. do that on ifup/ifdown instead&#xA;of device probe/remove/resume. These operations can be performed&#xA;independently from the actual device aRFS configuration.&#xA;Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers&#xA;only when aRFS is disabled -- otherwise, CPU rmap sets and clears&#xA;its own and they must not be touched manually.&#xA;CVE-2022-49106:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances&#xA;&#xA;vchiq_get_state() can return a NULL pointer. So handle this cases and&#xA;avoid a NULL pointer derefence in vchiq_dump_platform_instances.&#xA;CVE-2022-49110:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: conntrack: revisit gc autotuning&#xA;&#xA;as of commit 4608fdfc07e1&#xA;(&#34;netfilter: conntrack: collect all entries in one cycle&#34;)&#xA;conntrack gc was changed to run every 2 minutes.&#xA;&#xA;On systems where conntrack hash table is set to large value, most evictions&#xA;happen from gc worker rather than the packet path due to hash table&#xA;distribution.&#xA;&#xA;This causes netlink event overflows when events are collected.&#xA;&#xA;This change collects average expiry of scanned entries and&#xA;reschedules to the average remaining value, within 1 to 60 second interval.&#xA;&#xA;To avoid event overflows, reschedule after each bucket and add a&#xA;limit for both run time and number of evictions per run.&#xA;&#xA;If more entries have to be evicted, reschedule and restart 1 jiffy&#xA;into the future.&#xA;CVE-2022-49112:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mt76: fix monitor mode crash with sdio driver&#xA;&#xA;mt7921s driver may receive frames with fragment buffers. If there is a&#xA;CTS packet received in monitor mode, the payload is 10 bytes only and&#xA;need 6 bytes header padding after RXD buffer. However, only RXD in the&#xA;first linear buffer, if we pull buffer size RXD-size+6 bytes with&#xA;skb_pull(), that would trigger &#34;BUG_ON(skb-&gt;len &lt; skb-&gt;data_len)&#34; in&#xA;__skb_pull().&#xA;&#xA;To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to&#xA;256 to make sure all MCU operation in linear buffer.&#xA;&#xA;[   52.007562] kernel BUG at include/linux/skbuff.h:2313!&#xA;[   52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP&#xA;[   52.007987] pc : skb_pull+0x48/0x4c&#xA;[   52.008015] lr : mt7921_queue_rx_skb+0x494/0x890 [mt7921_common]&#xA;[   52.008361] Call trace:&#xA;[   52.008377]  skb_pull+0x48/0x4c&#xA;[   52.008400]  mt76s_net_worker+0x134/0x1b0 [mt76_sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c]&#xA;[   52.008431]  __mt76_worker_fn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917]&#xA;[   52.008449]  kthread+0x148/0x3ac&#xA;[   52.008466]  ret_from_fork+0x10/0x30&#xA;CVE-2022-49123:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ath11k: Fix frames flush failure caused by deadlock&#xA;&#xA;We are seeing below warnings:&#xA;&#xA;kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0&#xA;kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0&#xA;kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0&#xA;&#xA;this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work&#xA;has no chance to run in 5 seconds.&#xA;&#xA;By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing&#xA;ATH11K_FLUSH_TIMEOUT to 50 we get below warnings:&#xA;&#xA;kernel: [  120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.&#xA;kernel: [  120.763169]       Not tainted 5.10.90 #12&#xA;kernel: [  120.763177] &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA;kernel: [  120.763186] task:wpa_supplicant  state:D stack:    0 pid:  924 ppid:     1 flags:0x000043a0&#xA;kernel: [  120.763201] Call Trace:&#xA;kernel: [  120.763214]  __schedule+0x785/0x12fa&#xA;kernel: [  120.763224]  ? lockdep_hardirqs_on_prepare+0xe2/0x1bb&#xA;kernel: [  120.763242]  schedule+0x7e/0xa1&#xA;kernel: [  120.763253]  schedule_timeout+0x98/0xfe&#xA;kernel: [  120.763266]  ? run_local_timers+0x4a/0x4a&#xA;kernel: [  120.763291]  ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]&#xA;kernel: [  120.763306]  ? init_wait_entry+0x2e/0x2e&#xA;kernel: [  120.763343]  __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763378]  __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763411]  ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763441]  ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763473]  __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763540]  ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763572]  ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763612]  ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]&#xA;kernel: [  120.763654]  cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]&#xA;kernel: [  120.763697]  nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]&#xA;kernel: [  120.763715]  genl_rcv_msg+0x392/0x3c2&#xA;kernel: [  120.763750]  ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]&#xA;kernel: [  120.763782]  ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]&#xA;kernel: [  120.763802]  ? genl_rcv+0x36/0x36&#xA;kernel: [  120.763814]  netlink_rcv_skb+0x89/0xf7&#xA;kernel: [  120.763829]  genl_rcv+0x28/0x36&#xA;kernel: [  120.763840]  netlink_unicast+0x179/0x24b&#xA;kernel: [  120.763854]  netlink_sendmsg+0x393/0x401&#xA;kernel: [  120.763872]  sock_sendmsg+0x72/0x76&#xA;kernel: [  120.763886]  ____sys_sendmsg+0x170/0x1e6&#xA;kernel: [  120.763897]  ? copy_msghdr_from_user+0x7a/0xa2&#xA;kernel: [  120.763914]  ___sys_sendmsg+0x95/0xd1&#xA;kernel: [  120.763940]  __sys_sendmsg+0x85/0xbf&#xA;kernel: [  120.763956]  do_syscall_64+0x43/0x55&#xA;kernel: [  120.763966]  entry_SYSCALL_64_after_hwframe+0x44/0xa9&#xA;kernel: [  120.763977] RIP: 0033:0x79089f3fcc83&#xA;kernel: [  120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;kernel: [  120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83&#xA;kernel: [  120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009&#xA;kernel: [  120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000&#xA;kernel: [  120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980&#xA;kernel: [  120.764032] R13: 00007ffe604&#xA;---truncated---&#xA;CVE-2022-49134:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mlxsw: spectrum: Guard against invalid local ports&#xA;&#xA;When processing events generated by the device&#39;s firmware, the driver&#xA;protects itself from events reported for non-existent local ports, but&#xA;not for the CPU port (local port 0), which exists, but does not have all&#xA;the fields as any local port.&#xA;&#xA;This can result in a NULL pointer dereference when trying access&#xA;&#39;struct mlxsw_sp_port&#39; fields which are not initialized for CPU port.&#xA;&#xA;Commit 63b08b1f6834 (&#34;mlxsw: spectrum: Protect driver from buggy firmware&#34;)&#xA;already handled such issue by bailing early when processing a PUDE event&#xA;reported for the CPU port.&#xA;&#xA;Generalize the approach by moving the check to a common function and&#xA;making use of it in all relevant places.&#xA;CVE-2022-49161:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probe&#xA;&#xA;The device_node pointer is returned by of_parse_phandle()  with refcount&#xA;incremented. We should use of_node_put() on it when done.&#xA;&#xA;This function only calls of_node_put() in the regular path.&#xA;And it will cause refcount leak in error paths.&#xA;Fix this by calling of_node_put() in error handling too.&#xA;CVE-2022-49173:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;spi: fsi: Implement a timeout for polling status&#xA;&#xA;The data transfer routines must poll the status register to&#xA;determine when more data can be shifted in or out. If the hardware&#xA;gets into a bad state, these polling loops may never exit. Prevent&#xA;this by returning an error if a timeout is exceeded.&#xA;CVE-2022-49177:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hwrng: cavium - fix NULL but dereferenced coccicheck error&#xA;&#xA;Fix following coccicheck warning:&#xA;./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR:&#xA;pdev is NULL but dereferenced.&#xA;CVE-2022-49178:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;memstick/mspro_block: fix handling of read-only devices&#xA;&#xA;Use set_disk_ro to propagate the read-only state to the block layer&#xA;instead of checking for it in -&gt;open and leaking a reference in case&#xA;of a read-only device.&#xA;CVE-2022-49201:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ibmvnic: fix race between xmit and reset&#xA;&#xA;There is a race between reset and the transmit paths that can lead to&#xA;ibmvnic_xmit() accessing an scrq after it has been freed in the reset&#xA;path. It can result in a crash like:&#xA;&#xA;&#x9;Kernel attempted to read user page (0) - exploit attempt? (uid: 0)&#xA;&#x9;BUG: Kernel NULL pointer dereference on read at 0x00000000&#xA;&#x9;Faulting instruction address: 0xc0080000016189f8&#xA;&#x9;Oops: Kernel access of bad area, sig: 11 [#1]&#xA;&#x9;...&#xA;&#x9;NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]&#xA;&#x9;LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280&#xA;&#x9;Call Trace:&#xA;&#x9;[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)&#xA;&#x9;[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280&#xA;&#x9;[c000000000c9cfcc] sch_direct_xmit+0xec/0x330&#xA;&#x9;[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0&#xA;&#x9;[c000000000c00ad4] __dev_queue_xmit+0x394/0x730&#xA;&#x9;[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]&#xA;&#x9;[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]&#xA;&#x9;[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280&#xA;&#x9;[c000000000c00ca4] __dev_queue_xmit+0x564/0x730&#xA;&#x9;[c000000000cf97e0] neigh_hh_output+0xd0/0x180&#xA;&#x9;[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0&#xA;&#x9;[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0&#xA;&#x9;[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0&#xA;&#x9;[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0&#xA;&#x9;[c000000000d2d984] tcp_retransmit_skb+0x34/0x130&#xA;&#x9;[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0&#xA;&#x9;[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330&#xA;&#x9;[c000000000d317bc] tcp_write_timer+0x5c/0x200&#xA;&#x9;[c000000000243270] call_timer_fn+0x50/0x1c0&#xA;&#x9;[c000000000243704] __run_timers.part.0+0x324/0x460&#xA;&#x9;[c000000000243894] run_timer_softirq+0x54/0xa0&#xA;&#x9;[c000000000ea713c] __do_softirq+0x15c/0x3e0&#xA;&#x9;[c000000000166258] __irq_exit_rcu+0x158/0x190&#xA;&#x9;[c000000000166420] irq_exit+0x20/0x40&#xA;&#x9;[c00000000002853c] timer_interrupt+0x14c/0x2b0&#xA;&#x9;[c000000000009a00] decrementer_common_virt+0x210/0x220&#xA;&#x9;--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c&#xA;&#xA;The immediate cause of the crash is the access of tx_scrq in the following&#xA;snippet during a reset, where the tx_scrq can be either NULL or an address&#xA;that will soon be invalid:&#xA;&#xA;&#x9;ibmvnic_xmit()&#xA;&#x9;{&#xA;&#x9;&#x9;...&#xA;&#x9;&#x9;tx_scrq = adapter-&gt;tx_scrq[queue_num];&#xA;&#x9;&#x9;txq = netdev_get_tx_queue(netdev, queue_num);&#xA;&#x9;&#x9;ind_bufp = &amp;tx_scrq-&gt;ind_buf;&#xA;&#xA;&#x9;&#x9;if (test_bit(0, &amp;adapter-&gt;resetting)) {&#xA;&#x9;&#x9;...&#xA;&#x9;}&#xA;&#xA;But beyond that, the call to ibmvnic_xmit() itself is not safe during a&#xA;reset and the reset path attempts to avoid this by stopping the queue in&#xA;ibmvnic_cleanup(). However just after the queue was stopped, an in-flight&#xA;ibmvnic_complete_tx() could have restarted the queue even as the reset is&#xA;progressing.&#xA;&#xA;Since the queue was restarted we could get a call to ibmvnic_xmit() which&#xA;can then access the bad tx_scrq (or other fields).&#xA;&#xA;We cannot however simply have ibmvnic_complete_tx() check the -&gt;resetting&#xA;bit and skip starting the queue. This can race at the &#34;back-end&#34; of a good&#xA;reset which just restarted the queue but has not cleared the -&gt;resetting&#xA;bit yet. If we skip restarting the queue due to -&gt;resetting being true,&#xA;the queue would remain stopped indefinitely potentially leading to transmit&#xA;timeouts.&#xA;&#xA;IOW -&gt;resetting is too broad for this purpose. Instead use a new flag&#xA;that indicates whether or not the queues are active. Only the open/&#xA;reset paths control when the queues are active. ibmvnic_complete_tx()&#xA;and others wake up the queue only if the queue is marked active.&#xA;&#xA;So we will have:&#xA;&#x9;A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()&#xA;&#xA;&#x9;&#x9;-&gt;resetting = true&#xA;&#x9;&#x9;-&gt;tx_queues_active = false&#xA;&#x9;&#x9;disable tx queues&#xA;&#x9;&#x9;...&#xA;&#x9;&#x9;-&gt;tx_queues_active = true&#xA;&#x9;&#x9;start tx queues&#xA;&#xA;&#x9;B. Tx interrupt in ibmvnic_complete_tx():&#xA;&#xA;&#x9;&#x9;if (-&gt;tx_queues_active)&#xA;&#x9;&#x9;&#x9;netif_wake_subqueue();&#xA;&#xA;To ensure that -&gt;tx_queues_active and state of the queues are consistent,&#xA;we need a lock which:&#xA;&#xA;&#x9;- must also be taken in the interrupt path (ibmvnic_complete_tx())&#xA;&#x9;- shared across the multiple&#xA;---truncated---&#xA;CVE-2022-49226:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: asix: add proper error handling of usb read errors&#xA;&#xA;Syzbot once again hit uninit value in asix driver. The problem still the&#xA;same -- asix_read_cmd() reads less bytes, than was requested by caller.&#xA;&#xA;Since all read requests are performed via asix_read_cmd() let&#39;s catch&#xA;usb related error there and add __must_check notation to be sure all&#xA;callers actually check return value.&#xA;&#xA;So, this patch adds sanity check inside asix_read_cmd(), that simply&#xA;checks if bytes read are not less, than was requested and adds missing&#xA;error handling of asix_read_cmd() all across the driver code.&#xA;CVE-2022-49311:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()&#xA;&#xA;There is a deadlock in rtw_joinbss_event_prehandle(), which is shown&#xA;below:&#xA;&#xA;   (Thread 1)                |      (Thread 2)&#xA;                             | _set_timer()&#xA;rtw_joinbss_event_prehandle()|  mod_timer()&#xA; spin_lock_bh() //(1)        |  (wait a time)&#xA; ...                         | _rtw_join_timeout_handler()&#xA; del_timer_sync()            |  spin_lock_bh() //(2)&#xA; (wait timer to stop)        |  ...&#xA;&#xA;We hold pmlmepriv-&gt;lock in position (1) of thread 1 and&#xA;use del_timer_sync() to wait timer to stop, but timer handler&#xA;also need pmlmepriv-&gt;lock in position (2) of thread 2.&#xA;As a result, rtw_joinbss_event_prehandle() will block forever.&#xA;&#xA;This patch extracts del_timer_sync() from the protection of&#xA;spin_lock_bh(), which could let timer handler to obtain&#xA;the needed lock. What`s more, we change spin_lock_bh() to&#xA;spin_lock_irq() in _rtw_join_timeout_handler() in order to&#xA;prevent deadlock.&#xA;CVE-2022-49398:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback&#xA;&#xA;The list_for_each_entry_safe() macro saves the current item (n) and&#xA;the item after (n+1), so that n can be safely removed without&#xA;corrupting the list.  However, when traversing the list and removing&#xA;items using gadget giveback, the DWC3 lock is briefly released,&#xA;allowing other routines to execute.  There is a situation where, while&#xA;items are being removed from the cancelled_list using&#xA;dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable&#xA;routine is running in parallel (due to UDC unbind).  As the cleanup&#xA;routine removes n, and the pullup disable removes n+1, once the&#xA;cleanup retakes the DWC3 lock, it references a request who was already&#xA;removed/handled.  With list debug enabled, this leads to a panic.&#xA;Ensure all instances of the macro are replaced where gadget giveback&#xA;is used.&#xA;&#xA;Example call stack:&#xA;&#xA;Thread#1:&#xA;__dwc3_gadget_ep_set_halt() - CLEAR HALT&#xA;  -&gt; dwc3_gadget_ep_cleanup_cancelled_requests()&#xA;    -&gt;list_for_each_entry_safe()&#xA;    -&gt;dwc3_gadget_giveback(n)&#xA;      -&gt;dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]&#xA;      -&gt;spin_unlock&#xA;      -&gt;Thread#2 executes&#xA;      ...&#xA;    -&gt;dwc3_gadget_giveback(n+1)&#xA;      -&gt;Already removed!&#xA;&#xA;Thread#2:&#xA;dwc3_gadget_pullup()&#xA;  -&gt;waiting for dwc3 spin_lock&#xA;  ...&#xA;  -&gt;Thread#1 released lock&#xA;  -&gt;dwc3_stop_active_transfers()&#xA;    -&gt;dwc3_remove_requests()&#xA;      -&gt;fetches n+1 item from cancelled_list (n removed by Thread#1)&#xA;      -&gt;dwc3_gadget_giveback()&#xA;        -&gt;dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]&#xA;        -&gt;spin_unlock&#xA;CVE-2022-49509:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: i2c: max9286: fix kernel oops when removing module&#xA;&#xA;When removing the max9286 module we get a kernel oops:&#xA;&#xA;Unable to handle kernel paging request at virtual address 000000aa00000094&#xA;Mem abort info:&#xA;  ESR = 0x96000004&#xA;  EC = 0x25: DABT (current EL), IL = 32 bits&#xA;  SET = 0, FnV = 0&#xA;  EA = 0, S1PTW = 0&#xA;  FSC = 0x04: level 0 translation fault&#xA;Data abort info:&#xA;  ISV = 0, ISS = 0x00000004&#xA;  CM = 0, WnR = 0&#xA;user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000&#xA;[000000aa00000094] pgd=0000000000000000, p4d=0000000000000000&#xA;Internal error: Oops: 96000004 [#1] PREEMPT SMP&#xA;Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec&#xA;CPU: 2 PID: 713 Comm: rmmod Tainted: G         C        5.15.5-00057-gaebcd29c8ed7-dirty #5&#xA;Hardware name: Freescale i.MX8QXP MEK (DT)&#xA;pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : i2c_mux_del_adapters+0x24/0xf0&#xA;lr : max9286_remove+0x28/0xd0 [max9286]&#xA;sp : ffff800013a9bbf0&#xA;x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000&#xA;x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000&#xA;x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000&#xA;x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000&#xA;x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8&#xA;x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098&#xA;x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d&#xA;x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000&#xA;x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000&#xA;Call trace:&#xA; i2c_mux_del_adapters+0x24/0xf0&#xA; max9286_remove+0x28/0xd0 [max9286]&#xA; i2c_device_remove+0x40/0x110&#xA; __device_release_driver+0x188/0x234&#xA; driver_detach+0xc4/0x150&#xA; bus_remove_driver+0x60/0xe0&#xA; driver_unregister+0x34/0x64&#xA; i2c_del_driver+0x58/0xa0&#xA; max9286_i2c_driver_exit+0x1c/0x490 [max9286]&#xA; __arm64_sys_delete_module+0x194/0x260&#xA; invoke_syscall+0x48/0x114&#xA; el0_svc_common.constprop.0+0xd4/0xfc&#xA; do_el0_svc+0x2c/0x94&#xA; el0_svc+0x28/0x80&#xA; el0t_64_sync_handler+0xa8/0x130&#xA; el0t_64_sync+0x1a0/0x1a4&#xA;&#xA;The Oops happens because the I2C client data does not point to&#xA;max9286_priv anymore but to v4l2_subdev. The change happened in&#xA;max9286_init() which calls v4l2_i2c_subdev_init() later on...&#xA;&#xA;Besides fixing the max9286_remove() function, remove the call to&#xA;i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make&#xA;the necessary changes to max9286_init() so that it doesn&#39;t have to use&#xA;i2c_get_clientdata() in order to fetch the pointer to priv.&#xA;CVE-2022-49533:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ath11k: Change max no of active probe SSID and BSSID to fw capability&#xA;&#xA;The maximum number of SSIDs in a for active probe requests is currently&#xA;reported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver.&#xA;The scan_req_params structure only has the capacity to hold 10 SSIDs.&#xA;This leads to a buffer overflow which can be triggered from&#xA;wpa_supplicant in userspace. When copying the SSIDs into the&#xA;scan_req_params structure in the ath11k_mac_op_hw_scan route, it can&#xA;overwrite the extraie pointer.&#xA;&#xA;Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo probe&#xA;request will be sent, so totally 64 probe requests supported. So&#xA;set both max ssid and bssid to 16 and 4 respectively. Remove the&#xA;redundant macros of ssid and bssid.&#xA;&#xA;Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1&#xA;CVE-2022-49546:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/kexec: fix memory leak of elf header buffer&#xA;&#xA;This is reported by kmemleak detector:&#xA;&#xA;unreferenced object 0xffffc900002a9000 (size 4096):&#xA;  comm &#34;kexec&#34;, pid 14950, jiffies 4295110793 (age 373.951s)&#xA;  hex dump (first 32 bytes):&#xA;    7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............&#xA;    04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00  ..&gt;.............&#xA;  backtrace:&#xA;    [&lt;0000000016a8ef9f&gt;] __vmalloc_node_range+0x101/0x170&#xA;    [&lt;000000002b66b6c0&gt;] __vmalloc_node+0xb4/0x160&#xA;    [&lt;00000000ad40107d&gt;] crash_prepare_elf64_headers+0x8e/0xcd0&#xA;    [&lt;0000000019afff23&gt;] crash_load_segments+0x260/0x470&#xA;    [&lt;0000000019ebe95c&gt;] bzImage64_load+0x814/0xad0&#xA;    [&lt;0000000093e16b05&gt;] arch_kexec_kernel_image_load+0x1be/0x2a0&#xA;    [&lt;000000009ef2fc88&gt;] kimage_file_alloc_init+0x2ec/0x5a0&#xA;    [&lt;0000000038f5a97a&gt;] __do_sys_kexec_file_load+0x28d/0x530&#xA;    [&lt;0000000087c19992&gt;] do_syscall_64+0x3b/0x90&#xA;    [&lt;0000000066e063a4&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;&#xA;In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to&#xA;store elf headers.  While it&#39;s not freed back to system correctly when&#xA;kdump kernel is reloaded or unloaded.  Then memory leak is caused.  Fix it&#xA;by introducing x86 specific function arch_kimage_file_post_load_cleanup(),&#xA;and freeing the buffer there.&#xA;&#xA;And also remove the incorrect elf header buffer freeing code.  Before&#xA;calling arch specific kexec_file loading function, the image instance has&#xA;been initialized.  So &#39;image-&gt;elf_headers&#39; must be NULL.  It doesn&#39;t make&#xA;sense to free the elf header buffer in the place.&#xA;&#xA;Three different people have reported three bugs about the memory leak on&#xA;x86_64 inside Redhat.&#xA;CVE-2022-49557:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvm_xsave)&#xA;&#xA;Set the starting uABI size of KVM&#39;s guest FPU to &#39;struct kvm_xsave&#39;,&#xA;i.e. to KVM&#39;s historical uABI size.  When saving FPU state for usersapce,&#xA;KVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if&#xA;the host doesn&#39;t support XSAVE.  Setting the XSAVE header allows the VM&#xA;to be migrated to a host that does support XSAVE without the new host&#xA;having to handle FPU state that may or may not be compatible with XSAVE.&#xA;&#xA;Setting the uABI size to the host&#39;s default size results in out-of-bounds&#xA;writes (setting the FP+SSE bits) and data corruption (that is thankfully&#xA;caught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs.&#xA;&#xA;WARN if the default size is larger than KVM&#39;s historical uABI size; all&#xA;features that can push the FPU size beyond the historical size must be&#xA;opt-in.&#xA;&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x130&#xA;  Read of size 8 at addr ffff888011e33a00 by task qemu-build/681&#xA;  CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1&#xA;  Hardware name:  /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   dump_stack_lvl+0x34/0x45&#xA;   print_report.cold+0x45/0x575&#xA;   kasan_report+0x9b/0xd0&#xA;   fpu_copy_uabi_to_guest_fpstate+0x86/0x130&#xA;   kvm_arch_vcpu_ioctl+0x72a/0x1c50 [kvm]&#xA;   kvm_vcpu_ioctl+0x47f/0x7b0 [kvm]&#xA;   __x64_sys_ioctl+0x5de/0xc90&#xA;   do_syscall_64+0x31/0x50&#xA;   entry_SYSCALL_64_after_hwframe+0x44/0xae&#xA;   &lt;/TASK&gt;&#xA;  Allocated by task 0:&#xA;  (stack is not available)&#xA;  The buggy address belongs to the object at ffff888011e33800&#xA;   which belongs to the cache kmalloc-512 of size 512&#xA;  The buggy address is located 0 bytes to the right of&#xA;   512-byte region [ffff888011e33800, ffff888011e33a00)&#xA;  The buggy address belongs to the physical page:&#xA;  page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e30&#xA;  head:0000000089cd4adb order:2 compound_mapcount:0 compound_pincount:0&#xA;  flags: 0x4000000000010200(slab|head|zone=1)&#xA;  raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80&#xA;  raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000&#xA;  page dumped because: kasan: bad access detected&#xA;  Memory state around the buggy address:&#xA;   ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;   ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&#xA;  &gt;ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;                     ^&#xA;   ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;   ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc&#xA;  ==================================================================&#xA;  Disabling lock debugging due to kernel taint&#xA;CVE-2022-49563:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: qat - add param check for RSA&#xA;&#xA;Reject requests with a source buffer that is bigger than the size of the&#xA;key. This is to prevent a possible integer underflow that might happen&#xA;when copying the source scatterlist into a linear buffer.&#xA;CVE-2022-49566:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: qat - fix memory leak in RSA&#xA;&#xA;When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is&#xA;used, some components of the private key persist even after the TFM is&#xA;released.&#xA;Replace the explicit calls to free the buffers in qat_rsa_exit_tfm()&#xA;with a call to qat_rsa_clear_ctx() which frees all buffers referenced in&#xA;the TFM context.&#xA;CVE-2022-49616:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: rt7*-sdw: harden jack_detect_handler&#xA;&#xA;Realtek headset codec drivers typically check if the card is&#xA;instantiated before proceeding with the jack detection.&#xA;&#xA;The rt700, rt711 and rt711-sdca are however missing a check on the&#xA;card pointer, which can lead to NULL dereferences encountered in&#xA;driver bind/unbind tests.&#xA;CVE-2022-49617:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: Intel: sof_sdw: handle errors on card registration&#xA;&#xA;If the card registration fails, typically because of deferred probes,&#xA;the device properties added for headset codecs are not removed, which&#xA;leads to kernel oopses in driver bind/unbind tests.&#xA;&#xA;We already clean-up the device properties when the card is removed,&#xA;this code can be moved as a helper and called upon card registration&#xA;errors.&#xA;CVE-2022-49654:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: dsa: qca8k: reset cpu port on MTU change&#xA;&#xA;It was discovered that the Documentation lacks of a fundamental detail&#xA;on how to correctly change the MAX_FRAME_SIZE of the switch.&#xA;&#xA;In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the&#xA;switch panics and cease to send any packet. This cause the mgmt ethernet&#xA;system to not receive any packet (the slow fallback still works) and&#xA;makes the device not reachable. To recover from this a switch reset is&#xA;required.&#xA;&#xA;To correctly handle this, turn off the cpu ports before changing the&#xA;MAX_FRAME_SIZE and turn on again after the value is applied.&#xA;CVE-2022-49743:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ovl: Use &#34;buf&#34; flexible array for memcpy() destination&#xA;&#xA;The &#34;buf&#34; flexible array needs to be the memcpy() destination to avoid&#xA;false positive run-time warning from the recent FORTIFY_SOURCE&#xA;hardening:&#xA;&#xA;  memcpy: detected field-spanning write (size 93) of single field &#34;&amp;fh-&gt;fb&#34;&#xA;  at fs/overlayfs/export.c:799 (size 21)&#xA;CVE-2022-49758:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;reset: uniphier-glue: Fix possible null-ptr-deref&#xA;&#xA;It will cause null-ptr-deref when resource_size(res) invoked,&#xA;if platform_get_resource() returns NULL.&#xA;CVE-2022-49828:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hugetlbfs: don&#39;t delete error page from pagecache&#xA;&#xA;This change is very similar to the change that was made for shmem [1], and&#xA;it solves the same problem but for HugeTLBFS instead.&#xA;&#xA;Currently, when poison is found in a HugeTLB page, the page is removed&#xA;from the page cache.  That means that attempting to map or read that&#xA;hugepage in the future will result in a new hugepage being allocated&#xA;instead of notifying the user that the page was poisoned.  As [1] states,&#xA;this is effectively memory corruption.&#xA;&#xA;The fix is to leave the page in the page cache.  If the user attempts to&#xA;use a poisoned HugeTLB page with a syscall, the syscall will fail with&#xA;EIO, the same error code that shmem uses.  For attempts to map the page,&#xA;the thread will get a BUS_MCEERR_AR SIGBUS.&#xA;&#xA;[1]: commit a76054266661 (&#34;mm: shmem: don&#39;t truncate page if memory failure happens&#34;)&#xA;CVE-2022-49938:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cifs: fix small mempool leak in SMB2_negotiate()&#xA;&#xA;In some cases of failure (dialect mismatches) in SMB2_negotiate(), after&#xA;the request is sent, the checks would return -EIO when they should be&#xA;rather setting rc = -EIO and jumping to neg_exit to free the response&#xA;buffer from mempool.&#xA;CVE-2022-50011:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;venus: pm_helpers: Fix warning in OPP during probe&#xA;&#xA;Fix the following WARN triggered during Venus driver probe on&#xA;5.19.0-rc8-next-20220728:&#xA;&#xA; WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610&#xA; Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor&#xA;  qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)&#xA;  videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched&#xA;  snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats&#xA;  drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5&#xA;  phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro&#xA;  lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers&#xA;  qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector&#xA;  drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6&#xA; CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4&#xA; Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)&#xA; pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA; pc : dev_pm_opp_set_config+0x49c/0x610&#xA; lr : dev_pm_opp_set_config+0x58/0x610&#xA; sp : ffff8000093c3710&#xA; x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00&#xA; x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810&#xA; x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810&#xA; x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000&#xA; x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858&#xA; x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000&#xA; x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0&#xA; x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640&#xA; x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008&#xA; x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860&#xA; Call trace:&#xA;  dev_pm_opp_set_config+0x49c/0x610&#xA;  devm_pm_opp_set_config+0x18/0x70&#xA;  vcodec_domains_get+0xb8/0x1638 [venus_core]&#xA;  core_get_v4+0x1d8/0x218 [venus_core]&#xA;  venus_probe+0xf4/0x468 [venus_core]&#xA;  platform_probe+0x68/0xd8&#xA;  really_probe+0xbc/0x2a8&#xA;  __driver_probe_device+0x78/0xe0&#xA;  driver_probe_device+0x3c/0xf0&#xA;  __driver_attach+0x70/0x120&#xA;  bus_for_each_dev+0x70/0xc0&#xA;  driver_attach+0x24/0x30&#xA;  bus_add_driver+0x150/0x200&#xA;  driver_register+0x64/0x120&#xA;  __platform_driver_register+0x28/0x38&#xA;  qcom_venus_driver_init+0x24/0x1000 [venus_core]&#xA;  do_one_initcall+0x54/0x1c8&#xA;  do_init_module+0x44/0x1d0&#xA;  load_module+0x16c8/0x1aa0&#xA;  __do_sys_finit_module+0xbc/0x110&#xA;  __arm64_sys_finit_module+0x20/0x30&#xA;  invoke_syscall+0x44/0x108&#xA;  el0_svc_common.constprop.0+0xcc/0xf0&#xA;  do_el0_svc+0x2c/0xb8&#xA;  el0_svc+0x2c/0x88&#xA;  el0t_64_sync_handler+0xb8/0xc0&#xA;  el0t_64_sync+0x18c/0x190&#xA;  qcom-venus: probe of aa00000.video-codec failed with error -16&#xA;&#xA;The fix is re-ordering the code related to OPP core. The OPP core&#xA;expects all configuration options to be provided before the OPP&#xA;table is added.&#xA;CVE-2022-50056:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix missing i_op in ntfs_read_mft&#xA;&#xA;There is null pointer dereference because i_op == NULL.&#xA;The bug happens because we don&#39;t initialize i_op for records in $Extend.&#xA;CVE-2022-50073:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: tap: NULL pointer derefence in dev_parse_header_protocol when skb-&gt;dev is null&#xA;&#xA;Fixes a NULL pointer derefence bug triggered from tap driver.&#xA;When tap_get_user calls virtio_net_hdr_to_skb the skb-&gt;dev is null&#xA;(in tap.c skb-&gt;dev is set after the call to virtio_net_hdr_to_skb)&#xA;virtio_net_hdr_to_skb calls dev_parse_header_protocol which&#xA;needs skb-&gt;dev field to be valid.&#xA;&#xA;The line that trigers the bug is in dev_parse_header_protocol&#xA;(dev is at offset 0x10 from skb and is stored in RAX register)&#xA;  if (!dev-&gt;header_ops || !dev-&gt;header_ops-&gt;parse_protocol)&#xA;  22e1:   mov    0x10(%rbx),%rax&#xA;  22e5:&#x9;  mov    0x230(%rax),%rax&#xA;&#xA;Setting skb-&gt;dev before the call in tap.c fixes the issue.&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000230&#xA;RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]&#xA;Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 &lt;48&gt; 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48&#xA;RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010&#xA;RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300&#xA;RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8&#xA;R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001&#xA;R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6&#xA;FS:  0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0&#xA;Call Trace:&#xA; tap_get_user+0x3f1/0x540 [tap]&#xA; tap_sendmsg+0x56/0x362 [tap]&#xA; ? get_tx_bufs+0xc2/0x1e0 [vhost_net]&#xA; handle_tx_copy+0x114/0x670 [vhost_net]&#xA; handle_tx+0xb0/0xe0 [vhost_net]&#xA; handle_tx_kick+0x15/0x20 [vhost_net]&#xA; vhost_worker+0x7b/0xc0 [vhost]&#xA; ? vhost_vring_call_reset+0x40/0x40 [vhost]&#xA; kthread+0xfa/0x120&#xA; ? kthread_complete_and_exit+0x20/0x20&#xA; ret_from_fork+0x1f/0x30&#xA;CVE-2022-50111:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: mt6359: Fix refcount leak bug&#xA;&#xA;In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call&#xA;of_node_put() for the reference returned by of_get_child_by_name()&#xA;which has increased the refcount.&#xA;CVE-2022-50262:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Validate BOOT record_size&#xA;&#xA;When the NTFS BOOT record_size field &lt; 0, it represents a&#xA;shift value. However, there is no sanity check on the shift result&#xA;and the sbi-&gt;record_bits calculation through blksize_bits() assumes&#xA;the size always &gt; 256, which could lead to NPD while mounting a&#xA;malformed NTFS image.&#xA;&#xA;[  318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158&#xA;[  318.675682] #PF: supervisor read access in kernel mode&#xA;[  318.675869] #PF: error_code(0x0000) - not-present page&#xA;[  318.676246] PGD 0 P4D 0&#xA;[  318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;[  318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5&#xA;[  318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;[  318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0&#xA;[  318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180&#xA;[  318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246&#xA;[  318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080&#xA;[  318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;[  318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;[  318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080&#xA;[  318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000&#xA;[  318.683618] FS:  00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000&#xA;[  318.684280] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0&#xA;[  318.685623] Call Trace:&#xA;[  318.686607]  &lt;TASK&gt;&#xA;[  318.686872]  ? ntfs_alloc_inode+0x1a/0x60&#xA;[  318.687235]  attr_load_runs_vcn+0x2b/0xa0&#xA;[  318.687468]  mi_read+0xbb/0x250&#xA;[  318.687576]  ntfs_iget5+0x114/0xd90&#xA;[  318.687750]  ntfs_fill_super+0x588/0x11b0&#xA;[  318.687953]  ? put_ntfs+0x130/0x130&#xA;[  318.688065]  ? snprintf+0x49/0x70&#xA;[  318.688164]  ? put_ntfs+0x130/0x130&#xA;[  318.688256]  get_tree_bdev+0x16a/0x260&#xA;[  318.688407]  vfs_get_tree+0x20/0xb0&#xA;[  318.688519]  path_mount+0x2dc/0x9b0&#xA;[  318.688877]  do_mount+0x74/0x90&#xA;[  318.689142]  __x64_sys_mount+0x89/0xd0&#xA;[  318.689636]  do_syscall_64+0x3b/0x90&#xA;[  318.689998]  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[  318.690318] RIP: 0033:0x7fd9e133c48a&#xA;[  318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008&#xA;[  318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5&#xA;[  318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a&#xA;[  318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0&#xA;[  318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020&#xA;[  318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0&#xA;[  318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff&#xA;[  318.693007]  &lt;/TASK&gt;&#xA;[  318.693271] Modules linked in:&#xA;[  318.693614] CR2: 0000000000000158&#xA;[  318.694446] ---[ end trace 0000000000000000 ]---&#xA;[  318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0&#xA;[  318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180&#xA;[  318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246&#xA;[  318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080&#xA;[  318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;[  318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000&#xA;[  318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080&#xA;[  318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000&#xA;[  318.700973] FS:  00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000&#xA;[&#xA;---truncated---&#xA;CVE-2022-50336:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Add null pointer check to attr_load_runs_vcn&#xA;&#xA;Some metadata files are handled before MFT. This adds a null pointer&#xA;check for some corner cases that could lead to NPD while reading these&#xA;metadata files for a malformed NTFS image.&#xA;&#xA;[  240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158&#xA;[  240.191583] #PF: supervisor read access in kernel mode&#xA;[  240.191956] #PF: error_code(0x0000) - not-present page&#xA;[  240.192391] PGD 0 P4D 0&#xA;[  240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;[  240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G    B             5.19.0+ #17&#xA;[  240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;[  240.195152] RIP: 0010:ni_find_attr+0xae/0x300&#xA;[  240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f&#xA;[  240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286&#xA;[  240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a&#xA;[  240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60&#xA;[  240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed&#xA;[  240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000&#xA;[  240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000&#xA;[  240.199410] FS:  00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000&#xA;[  240.199895] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0&#xA;[  240.200839] Call Trace:&#xA;[  240.201104]  &lt;TASK&gt;&#xA;[  240.201502]  ? ni_load_mi+0x80/0x80&#xA;[  240.202297]  ? ___slab_alloc+0x465/0x830&#xA;[  240.202614]  attr_load_runs_vcn+0x8c/0x1a0&#xA;[  240.202886]  ? __kasan_slab_alloc+0x32/0x90&#xA;[  240.203157]  ? attr_data_write_resident+0x250/0x250&#xA;[  240.203543]  mi_read+0x133/0x2c0&#xA;[  240.203785]  mi_get+0x70/0x140&#xA;[  240.204012]  ni_load_mi_ex+0xfa/0x190&#xA;[  240.204346]  ? ni_std5+0x90/0x90&#xA;[  240.204588]  ? __kasan_kmalloc+0x88/0xb0&#xA;[  240.204859]  ni_enum_attr_ex+0xf1/0x1c0&#xA;[  240.205107]  ? ni_fname_type.part.0+0xd0/0xd0&#xA;[  240.205600]  ? ntfs_load_attr_list+0xbe/0x300&#xA;[  240.205864]  ? ntfs_cmp_names_cpu+0x125/0x180&#xA;[  240.206157]  ntfs_iget5+0x56c/0x1870&#xA;[  240.206510]  ? ntfs_get_block_bmap+0x70/0x70&#xA;[  240.206776]  ? __kasan_kmalloc+0x88/0xb0&#xA;[  240.207030]  ? set_blocksize+0x95/0x150&#xA;[  240.207545]  ntfs_fill_super+0xb8f/0x1e20&#xA;[  240.207839]  ? put_ntfs+0x1d0/0x1d0&#xA;[  240.208069]  ? vsprintf+0x20/0x20&#xA;[  240.208467]  ? mutex_unlock+0x81/0xd0&#xA;[  240.208846]  ? set_blocksize+0x95/0x150&#xA;[  240.209221]  get_tree_bdev+0x232/0x370&#xA;[  240.209804]  ? put_ntfs+0x1d0/0x1d0&#xA;[  240.210519]  ntfs_fs_get_tree+0x15/0x20&#xA;[  240.210991]  vfs_get_tree+0x4c/0x130&#xA;[  240.211455]  path_mount+0x645/0xfd0&#xA;[  240.211806]  ? putname+0x80/0xa0&#xA;[  240.212112]  ? finish_automount+0x2e0/0x2e0&#xA;[  240.212559]  ? kmem_cache_free+0x110/0x390&#xA;[  240.212906]  ? putname+0x80/0xa0&#xA;[  240.213329]  do_mount+0xd6/0xf0&#xA;[  240.213829]  ? path_mount+0xfd0/0xfd0&#xA;[  240.214246]  ? __kasan_check_write+0x14/0x20&#xA;[  240.214774]  __x64_sys_mount+0xca/0x110&#xA;[  240.215080]  do_syscall_64+0x3b/0x90&#xA;[  240.215442]  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[  240.215811] RIP: 0033:0x7f233b4e948a&#xA;[  240.216104] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008&#xA;[  240.217615] RSP: 002b:00007fff02211ec8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5&#xA;[  240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX: 00007f233b4e948a&#xA;[  240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0&#xA;[  240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020&#xA;[  240.220403] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000561cdc363af0&#xA;[  240.220803] R13: 000&#xA;---truncated---&#xA;CVE-2022-50451:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix memory leak on ntfs_fill_super() error path&#xA;&#xA;syzbot reported kmemleak as below:&#xA;&#xA;BUG: memory leak&#xA;unreferenced object 0xffff8880122f1540 (size 32):&#xA;  comm &#34;a.out&#34;, pid 6664, jiffies 4294939771 (age 25.500s)&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00  ................&#xA;  backtrace:&#xA;    [&lt;ffffffff81b16052&gt;] ntfs_init_fs_context+0x22/0x1c0&#xA;    [&lt;ffffffff8164aaa7&gt;] alloc_fs_context+0x217/0x430&#xA;    [&lt;ffffffff81626dd4&gt;] path_mount+0x704/0x1080&#xA;    [&lt;ffffffff81627e7c&gt;] __x64_sys_mount+0x18c/0x1d0&#xA;    [&lt;ffffffff84593e14&gt;] do_syscall_64+0x34/0xb0&#xA;    [&lt;ffffffff84600087&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;This patch fixes this issue by freeing mount options on error path of&#xA;ntfs_fill_super().&#xA;CVE-2022-50516:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs: dlm: fix invalid derefence of sb_lvbptr&#xA;&#xA;I experience issues when putting a lkbsb on the stack and have sb_lvbptr&#xA;field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash&#xA;with the following kernel message, the dangled pointer is here&#xA;0xdeadbeef as example:&#xA;&#xA;[  102.749317] BUG: unable to handle page fault for address: 00000000deadbeef&#xA;[  102.749320] #PF: supervisor read access in kernel mode&#xA;[  102.749323] #PF: error_code(0x0000) - not-present page&#xA;[  102.749325] PGD 0 P4D 0&#xA;[  102.749332] Oops: 0000 [#1] PREEMPT SMP PTI&#xA;[  102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G        W         5.19.0-rc3+ #1565&#xA;[  102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014&#xA;[  102.749344] RIP: 0010:memcpy_erms+0x6/0x10&#xA;[  102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 &lt;f3&gt; a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe&#xA;[  102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202&#xA;[  102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040&#xA;[  102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070&#xA;[  102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001&#xA;[  102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70&#xA;[  102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001&#xA;[  102.749368] FS:  0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000&#xA;[  102.749372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0&#xA;[  102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  102.749379] PKRU: 55555554&#xA;[  102.749381] Call Trace:&#xA;[  102.749382]  &lt;TASK&gt;&#xA;[  102.749383]  ? send_args+0xb2/0xd0&#xA;[  102.749389]  send_common+0xb7/0xd0&#xA;[  102.749395]  _unlock_lock+0x2c/0x90&#xA;[  102.749400]  unlock_lock.isra.56+0x62/0xa0&#xA;[  102.749405]  dlm_unlock+0x21e/0x330&#xA;[  102.749411]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]&#xA;[  102.749416]  torture_unlock+0x5a/0x90 [dlm_locktorture]&#xA;[  102.749419]  ? preempt_count_sub+0xba/0x100&#xA;[  102.749427]  lock_torture_writer+0xbd/0x150 [dlm_locktorture]&#xA;[  102.786186]  kthread+0x10a/0x130&#xA;[  102.786581]  ? kthread_complete_and_exit+0x20/0x20&#xA;[  102.787156]  ret_from_fork+0x22/0x30&#xA;[  102.787588]  &lt;/TASK&gt;&#xA;[  102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw&#xA;[  102.792536] CR2: 00000000deadbeef&#xA;[  102.792930] ---[ end trace 0000000000000000 ]---&#xA;&#xA;This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags&#xA;is set when copying the lvbptr array instead of if it&#39;s just null which&#xA;fixes for me the issue.&#xA;&#xA;I think this patch can fix other dlm users as well, depending how they&#xA;handle the init, freeing memory handling of sb_lvbptr and don&#39;t set&#xA;DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a&#xA;hidden issue all the time. However with checking on DLM_LKF_VALBLK the&#xA;user always need to provide a sb_lvbptr non-null value. There might be&#xA;more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and&#xA;non-null to report the user the way how DLM API is used is wrong but can&#xA;be added for later, this will only fix the current behaviour.&#xA;CVE-2022-50720:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/apic: Don&#39;t disable x2APIC if locked&#xA;&#xA;The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC&#xA;(or x2APIC).  X2APIC mode is mostly compatible with legacy APIC, but&#xA;it disables the memory-mapped APIC interface in favor of one that uses&#xA;MSRs.  The APIC mode is controlled by the EXT bit in the APIC MSR.&#xA;&#xA;The MMIO/xAPIC interface has some problems, most notably the APIC LEAK&#xA;[1].  This bug allows an attacker to use the APIC MMIO interface to&#xA;extract data from the SGX enclave.&#xA;&#xA;Introduce support for a new feature that will allow the BIOS to lock&#xA;the APIC in x2APIC mode.  If the APIC is locked in x2APIC mode and the&#xA;kernel tries to disable the APIC or revert to legacy APIC mode a GP&#xA;fault will occur.&#xA;&#xA;Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle&#xA;the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by&#xA;preventing the kernel from trying to disable the x2APIC.&#xA;&#xA;On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are&#xA;enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS.  If&#xA;legacy APIC is required, then it SGX and TDX need to be disabled in the&#xA;BIOS.&#xA;&#xA;[1]: https://aepicleak.com/aepicleak.pdf&#xA;CVE-2022-50764:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6/sit: use DEV_STATS_INC() to avoid data-races&#xA;&#xA;syzbot/KCSAN reported that multiple cpus are updating dev-&gt;stats.tx_error&#xA;concurrently.&#xA;&#xA;This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()&#xA;is not protected by a spinlock.&#xA;&#xA;While original KCSAN report was about tx path, rx path has the same issue.&#xA;CVE-2023-0160:A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system.&#xA;CVE-2023-24023:Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.&#xA;CVE-2023-53002:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/i915: Fix a memory leak with reused mmap_offset&#xA;&#xA;drm_vma_node_allow() and drm_vma_node_revoke() should be called in&#xA;balanced pairs. We call drm_vma_node_allow() once per-file everytime a&#xA;user calls mmap_offset, but only call drm_vma_node_revoke once per-file&#xA;on each mmap_offset. As the mmap_offset is reused by the client, the&#xA;per-file vm_count may remain non-zero and the rbtree leaked.&#xA;&#xA;Call drm_vma_node_allow_once() instead to prevent that memory leak.&#xA;CVE-2023-53008:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cifs: fix potential memory leaks in session setup&#xA;&#xA;Make sure to free cifs_ses::auth_key.response before allocating it as&#xA;we might end up leaking memory in reconnect or mounting.&#xA;CVE-2023-53110:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()&#xA;&#xA;When performing a stress test on SMC-R by rmmod mlx5_ib driver&#xA;during the wrk/nginx test, we found that there is a probability&#xA;of triggering a panic while terminating all link groups.&#xA;&#xA;This issue dues to the race between smc_smcr_terminate_all()&#xA;and smc_buf_create().&#xA;&#xA;&#x9;&#x9;&#x9;smc_smcr_terminate_all&#xA;&#xA;smc_buf_create&#xA;/* init */&#xA;conn-&gt;sndbuf_desc = NULL;&#xA;...&#xA;&#xA;&#x9;&#x9;&#x9;__smc_lgr_terminate&#xA;&#x9;&#x9;&#x9;&#x9;smc_conn_kill&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;smc_close_abort&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;smc_cdc_get_slot_and_msg_send&#xA;&#xA;&#x9;&#x9;&#x9;__softirqentry_text_start&#xA;&#x9;&#x9;&#x9;&#x9;smc_wr_tx_process_cqe&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;smc_cdc_tx_handler&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;READ(conn-&gt;sndbuf_desc-&gt;len);&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;/* panic dues to NULL sndbuf_desc */&#xA;&#xA;conn-&gt;sndbuf_desc = xxx;&#xA;&#xA;This patch tries to fix the issue by always to check the sndbuf_desc&#xA;before send any cdc msg, to make sure that no null pointer is&#xA;seen during cqe processing.&#xA;CVE-2023-53125:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: smsc75xx: Limit packet length to skb-&gt;len&#xA;&#xA;Packet length retrieved from skb data may be larger than&#xA;the actual socket buffer length (up to 9026 bytes). In such&#xA;case the cloned skb passed up the network stack will leak&#xA;kernel memory contents.&#xA;CVE-2023-53163:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: don&#39;t hold ni_lock when calling truncate_setsize()&#xA;&#xA;syzbot is reporting hung task at do_user_addr_fault() [1], for there is&#xA;a silent deadlock between PG_locked bit and ni_lock lock.&#xA;&#xA;Since filemap_update_page() calls filemap_read_folio() after calling&#xA;folio_trylock() which will set PG_locked bit, ntfs_truncate() must not&#xA;call truncate_setsize() which will wait for PG_locked bit to be cleared&#xA;when holding ni_lock lock.&#xA;CVE-2023-53188:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: openvswitch: fix race on port output&#xA;&#xA;assume the following setup on a single machine:&#xA;1. An openvswitch instance with one bridge and default flows&#xA;2. two network namespaces &#34;server&#34; and &#34;client&#34;&#xA;3. two ovs interfaces &#34;server&#34; and &#34;client&#34; on the bridge&#xA;4. for each ovs interface a veth pair with a matching name and 32 rx and&#xA;   tx queues&#xA;5. move the ends of the veth pairs to the respective network namespaces&#xA;6. assign ip addresses to each of the veth ends in the namespaces (needs&#xA;   to be the same subnet)&#xA;7. start some http server on the server network namespace&#xA;8. test if a client in the client namespace can reach the http server&#xA;&#xA;when following the actions below the host has a chance of getting a cpu&#xA;stuck in a infinite loop:&#xA;1. send a large amount of parallel requests to the http server (around&#xA;   3000 curls should work)&#xA;2. in parallel delete the network namespace (do not delete interfaces or&#xA;   stop the server, just kill the namespace)&#xA;&#xA;there is a low chance that this will cause the below kernel cpu stuck&#xA;message. If this does not happen just retry.&#xA;Below there is also the output of bpftrace for the functions mentioned&#xA;in the output.&#xA;&#xA;The series of events happening here is:&#xA;1. the network namespace is deleted calling&#xA;   `unregister_netdevice_many_notify` somewhere in the process&#xA;2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and&#xA;   then runs `synchronize_net`&#xA;3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`&#xA;4. this is then handled by `dp_device_event` which calls&#xA;   `ovs_netdev_detach_dev` (if a vport is found, which is the case for&#xA;   the veth interface attached to ovs)&#xA;5. this removes the rx_handlers of the device but does not prevent&#xA;   packages to be sent to the device&#xA;6. `dp_device_event` then queues the vport deletion to work in&#xA;   background as a ovs_lock is needed that we do not hold in the&#xA;   unregistration path&#xA;7. `unregister_netdevice_many_notify` continues to call&#xA;   `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0&#xA;8. port deletion continues (but details are not relevant for this issue)&#xA;9. at some future point the background task deletes the vport&#xA;&#xA;If after 7. but before 9. a packet is send to the ovs vport (which is&#xA;not deleted at this point in time) which forwards it to the&#xA;`dev_queue_xmit` flow even though the device is unregistering.&#xA;In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is&#xA;a while loop (if the packet has a rx_queue recorded) that is infinite if&#xA;`dev-&gt;real_num_tx_queues` is zero.&#xA;&#xA;To prevent this from happening we update `do_output` to handle devices&#xA;without carrier the same as if the device is not found (which would&#xA;be the code path after 9. is done).&#xA;&#xA;Additionally we now produce a warning in `skb_tx_hash` if we will hit&#xA;the infinite loop.&#xA;&#xA;bpftrace (first word is function name):&#xA;&#xA;__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1&#xA;netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1&#xA;dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1&#xA;synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024&#xA;synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024&#xA;synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024&#xA;synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024&#xA;dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2&#xA;ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2&#xA;netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2&#xA;synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024&#xA;netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2&#xA;dp_&#xA;---truncated---&#xA;CVE-2023-53194:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Add length check in indx_get_root&#xA;&#xA;This adds a length check to guarantee the retrieved index root is legit.&#xA;&#xA;[  162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243&#xA;[  162.460851]&#xA;[  162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42&#xA;[  162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;[  162.462609] Call Trace:&#xA;[  162.462954]  &lt;TASK&gt;&#xA;[  162.463276]  dump_stack_lvl+0x49/0x63&#xA;[  162.463822]  print_report.cold+0xf5/0x689&#xA;[  162.464608]  ? unwind_get_return_address+0x3a/0x60&#xA;[  162.465766]  ? hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.466975]  kasan_report+0xa7/0x130&#xA;[  162.467506]  ? _raw_spin_lock_irq+0xc0/0xf0&#xA;[  162.467998]  ? hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.468536]  __asan_load2+0x68/0x90&#xA;[  162.468923]  hdr_find_e.isra.0+0x10c/0x320&#xA;[  162.469282]  ? cmp_uints+0xe0/0xe0&#xA;[  162.469557]  ? cmp_sdh+0x90/0x90&#xA;[  162.469864]  ? ni_find_attr+0x214/0x300&#xA;[  162.470217]  ? ni_load_mi+0x80/0x80&#xA;[  162.470479]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[  162.470931]  ? ntfs_bread_run+0x190/0x190&#xA;[  162.471307]  ? indx_get_root+0xe4/0x190&#xA;[  162.471556]  ? indx_get_root+0x140/0x190&#xA;[  162.471833]  ? indx_init+0x1e0/0x1e0&#xA;[  162.472069]  ? fnd_clear+0x115/0x140&#xA;[  162.472363]  ? _raw_spin_lock_irqsave+0x100/0x100&#xA;[  162.472731]  indx_find+0x184/0x470&#xA;[  162.473461]  ? sysvec_apic_timer_interrupt+0x57/0xc0&#xA;[  162.474429]  ? indx_find_buffer+0x2d0/0x2d0&#xA;[  162.474704]  ? do_syscall_64+0x3b/0x90&#xA;[  162.474962]  dir_search_u+0x196/0x2f0&#xA;[  162.475381]  ? ntfs_nls_to_utf16+0x450/0x450&#xA;[  162.475661]  ? ntfs_security_init+0x3d6/0x440&#xA;[  162.475906]  ? is_sd_valid+0x180/0x180&#xA;[  162.476191]  ntfs_extend_init+0x13f/0x2c0&#xA;[  162.476496]  ? ntfs_fix_post_read+0x130/0x130&#xA;[  162.476861]  ? iput.part.0+0x286/0x320&#xA;[  162.477325]  ntfs_fill_super+0x11e0/0x1b50&#xA;[  162.477709]  ? put_ntfs+0x1d0/0x1d0&#xA;[  162.477970]  ? vsprintf+0x20/0x20&#xA;[  162.478258]  ? set_blocksize+0x95/0x150&#xA;[  162.478538]  get_tree_bdev+0x232/0x370&#xA;[  162.478789]  ? put_ntfs+0x1d0/0x1d0&#xA;[  162.479038]  ntfs_fs_get_tree+0x15/0x20&#xA;[  162.479374]  vfs_get_tree+0x4c/0x130&#xA;[  162.479729]  path_mount+0x654/0xfe0&#xA;[  162.480124]  ? putname+0x80/0xa0&#xA;[  162.480484]  ? finish_automount+0x2e0/0x2e0&#xA;[  162.480894]  ? putname+0x80/0xa0&#xA;[  162.481467]  ? kmem_cache_free+0x1c4/0x440&#xA;[  162.482280]  ? putname+0x80/0xa0&#xA;[  162.482714]  do_mount+0xd6/0xf0&#xA;[  162.483264]  ? path_mount+0xfe0/0xfe0&#xA;[  162.484782]  ? __kasan_check_write+0x14/0x20&#xA;[  162.485593]  __x64_sys_mount+0xca/0x110&#xA;[  162.486024]  do_syscall_64+0x3b/0x90&#xA;[  162.486543]  entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;[  162.487141] RIP: 0033:0x7f9d374e948a&#xA;[  162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008&#xA;[  162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5&#xA;[  162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a&#xA;[  162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0&#xA;[  162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020&#xA;[  162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0&#xA;[  162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff&#xA;[  162.493644]  &lt;/TASK&gt;&#xA;[  162.493908]&#xA;[  162.494214] The buggy address belongs to the physical page:&#xA;[  162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc&#xA;[  162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)&#xA;[  162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000&#xA;[  162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000&#xA;[  162.500542] page dumped becau&#xA;---truncated---&#xA;CVE-2023-53265:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ubi: ensure that VID header offset + VID header size &lt;= alloc, size&#xA;&#xA;Ensure that the VID header offset + VID header size does not exceed&#xA;the allocated area to avoid slab OOB.&#xA;&#xA;BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]&#xA;BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197&#xA;Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555&#xA;&#xA;CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G        W&#xA;6.0.0-1868 #1&#xA;Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29&#xA;04/01/2014&#xA;Call Trace:&#xA;  &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:88 [inline]&#xA;  dump_stack_lvl+0x85/0xad lib/dump_stack.c:106&#xA;  print_address_description mm/kasan/report.c:317 [inline]&#xA;  print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433&#xA;  kasan_report+0xa7/0x11b mm/kasan/report.c:495&#xA;  crc32_body lib/crc32.c:111 [inline]&#xA;  crc32_le_generic lib/crc32.c:179 [inline]&#xA;  crc32_le_base+0x58c/0x626 lib/crc32.c:197&#xA;  ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067&#xA;  create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317&#xA;  create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]&#xA;  ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812&#xA;  ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601&#xA;  ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965&#xA;  ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:870 [inline]&#xA;  __se_sys_ioctl fs/ioctl.c:856 [inline]&#xA;  __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856&#xA;  do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;  do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80&#xA;  entry_SYSCALL_64_after_hwframe+0x63/0x0&#xA;RIP: 0033:0x7f96d5cf753d&#xA;Code:&#xA;RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d&#xA;RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003&#xA;RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0&#xA;R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000&#xA;  &lt;/TASK&gt;&#xA;&#xA;Allocated by task 1555:&#xA;  kasan_save_stack+0x20/0x3d mm/kasan/common.c:38&#xA;  kasan_set_track mm/kasan/common.c:45 [inline]&#xA;  set_alloc_info mm/kasan/common.c:437 [inline]&#xA;  ____kasan_kmalloc mm/kasan/common.c:516 [inline]&#xA;  __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525&#xA;  kasan_kmalloc include/linux/kasan.h:234 [inline]&#xA;  __kmalloc+0x138/0x257 mm/slub.c:4429&#xA;  kmalloc include/linux/slab.h:605 [inline]&#xA;  ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]&#xA;  create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295&#xA;  create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]&#xA;  ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812&#xA;  ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601&#xA;  ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965&#xA;  ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:870 [inline]&#xA;  __se_sys_ioctl fs/ioctl.c:856 [inline]&#xA;  __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856&#xA;  do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA;  do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80&#xA;  entry_SYSCALL_64_after_hwframe+0x63/0x0&#xA;&#xA;The buggy address belongs to the object at ffff88802bb36e00&#xA;  which belongs to the cache kmalloc-256 of size 256&#xA;The buggy address is located 0 bytes to the right of&#xA;  256-byte region [ffff88802bb36e00, ffff88802bb36f00)&#xA;&#xA;The buggy address belongs to the physical page:&#xA;page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000&#xA;index:0x0 pfn:0x2bb36&#xA;head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0&#xA;flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)&#xA;raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40&#xA;raw: 0000000000000000 00000000001&#xA;---truncated---&#xA;CVE-2023-53294:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix null-ptr-deref on inode-&gt;i_op in ntfs_lookup()&#xA;&#xA;Syzbot reported a null-ptr-deref bug:&#xA;&#xA;ntfs3: loop0: Different NTFS&#39; sector size (1024) and media sector size&#xA;(512)&#xA;ntfs3: loop0: Mark volume as dirty due to NTFS errors&#xA;general protection fault, probably for non-canonical address&#xA;0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN&#xA;KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline]&#xA;RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; d_splice_alias+0x122/0x3b0 fs/dcache.c:3191&#xA; lookup_open fs/namei.c:3391 [inline]&#xA; open_last_lookups fs/namei.c:3481 [inline]&#xA; path_openat+0x10e6/0x2df0 fs/namei.c:3688&#xA; do_filp_open+0x264/0x4f0 fs/namei.c:3718&#xA; do_sys_openat2+0x124/0x4e0 fs/open.c:1310&#xA; do_sys_open fs/open.c:1326 [inline]&#xA; __do_sys_open fs/open.c:1334 [inline]&#xA; __se_sys_open fs/open.c:1330 [inline]&#xA; __x64_sys_open+0x221/0x270 fs/open.c:1330&#xA; do_syscall_x64 arch/x86/entry/common.c:50 [inline]&#xA; do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;If the MFT record of ntfs inode is not a base record, inode-&gt;i_op can be&#xA;NULL. And a null-ptr-deref may happen:&#xA;&#xA;ntfs_lookup()&#xA;    dir_search_u() # inode-&gt;i_op is set to NULL&#xA;    d_splice_alias()&#xA;        __d_add()&#xA;            d_flags_for_inode() # inode-&gt;i_op-&gt;get_link null-ptr-deref&#xA;&#xA;Fix this by adding a Check on inode-&gt;i_op before calling the&#xA;d_splice_alias() function.&#xA;CVE-2023-53328:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Enhance sanity check while generating attr_list&#xA;&#xA;ni_create_attr_list uses WARN_ON to catch error cases while generating&#xA;attribute list, which only prints out stack trace and may not be enough.&#xA;This repalces them with more proper error handling flow.&#xA;&#xA;[   59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e&#xA;[   59.673268] #PF: supervisor read access in kernel mode&#xA;[   59.678354] #PF: error_code(0x0000) - not-present page&#xA;[   59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0&#xA;[   59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;[   59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G    B   W          6.2.0-rc1+ #4&#xA;[   59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;[   59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860&#xA;[   59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8&#xA;[   59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282&#xA;[   59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe&#xA;[   59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0&#xA;[   59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9&#xA;[   59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180&#xA;[   59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050&#xA;[   59.768323] FS:  00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000&#xA;[   59.776027] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[   59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0&#xA;[   59.787607] Call Trace:&#xA;[   59.790271]  &lt;TASK&gt;&#xA;[   59.792488]  ? __pfx_ni_create_attr_list+0x10/0x10&#xA;[   59.797235]  ? kernel_text_address+0xd3/0xe0&#xA;[   59.800856]  ? unwind_get_return_address+0x3e/0x60&#xA;[   59.805101]  ? __kasan_check_write+0x18/0x20&#xA;[   59.809296]  ? preempt_count_sub+0x1c/0xd0&#xA;[   59.813421]  ni_ins_attr_ext+0x52c/0x5c0&#xA;[   59.817034]  ? __pfx_ni_ins_attr_ext+0x10/0x10&#xA;[   59.821926]  ? __vfs_setxattr+0x121/0x170&#xA;[   59.825718]  ? __vfs_setxattr_noperm+0x97/0x300&#xA;[   59.829562]  ? __vfs_setxattr_locked+0x145/0x170&#xA;[   59.833987]  ? vfs_setxattr+0x137/0x2a0&#xA;[   59.836732]  ? do_setxattr+0xce/0x150&#xA;[   59.839807]  ? setxattr+0x126/0x140&#xA;[   59.842353]  ? path_setxattr+0x164/0x180&#xA;[   59.845275]  ? __x64_sys_setxattr+0x71/0x90&#xA;[   59.848838]  ? do_syscall_64+0x3f/0x90&#xA;[   59.851898]  ? entry_SYSCALL_64_after_hwframe+0x72/0xdc&#xA;[   59.857046]  ? stack_depot_save+0x17/0x20&#xA;[   59.860299]  ni_insert_attr+0x1ba/0x420&#xA;[   59.863104]  ? __pfx_ni_insert_attr+0x10/0x10&#xA;[   59.867069]  ? preempt_count_sub+0x1c/0xd0&#xA;[   59.869897]  ? _raw_spin_unlock_irqrestore+0x2b/0x50&#xA;[   59.874088]  ? __create_object+0x3ae/0x5d0&#xA;[   59.877865]  ni_insert_resident+0xc4/0x1c0&#xA;[   59.881430]  ? __pfx_ni_insert_resident+0x10/0x10&#xA;[   59.886355]  ? kasan_save_alloc_info+0x1f/0x30&#xA;[   59.891117]  ? __kasan_kmalloc+0x8b/0xa0&#xA;[   59.894383]  ntfs_set_ea+0x90d/0xbf0&#xA;[   59.897703]  ? __pfx_ntfs_set_ea+0x10/0x10&#xA;[   59.901011]  ? kernel_text_address+0xd3/0xe0&#xA;[   59.905308]  ? __kernel_text_address+0x16/0x50&#xA;[   59.909811]  ? unwind_get_return_address+0x3e/0x60&#xA;[   59.914898]  ? __pfx_stack_trace_consume_entry+0x10/0x10&#xA;[   59.920250]  ? arch_stack_walk+0xa2/0x100&#xA;[   59.924560]  ? filter_irq_stacks+0x27/0x80&#xA;[   59.928722]  ntfs_setxattr+0x405/0x440&#xA;[   59.932512]  ? __pfx_ntfs_setxattr+0x10/0x10&#xA;[   59.936634]  ? kvmalloc_node+0x2d/0x120&#xA;[   59.940378]  ? kasan_save_stack+0x41/0x60&#xA;[   59.943870]  ? kasan_save_stack+0x2a/0x60&#xA;[   59.947719]  ? kasan_set_track+0x29/0x40&#xA;[   59.951417]  ? kasan_save_alloc_info+0x1f/0x30&#xA;[   59.955733]  ? __kasan_kmalloc+0x8b/0xa0&#xA;[   59.959598]  ? __kmalloc_node+0x68/0x150&#xA;[   59.963163]  ? kvmalloc_node+0x2d/0x120&#xA;[   59.966490]  ? vmemdup_user+0x2b/0xa0&#xA;---truncated---&#xA;CVE-2023-53335:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()&#xA;&#xA;If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is&#xA;dereferenced later regardless of whether it is empty.&#xA;This patch adds a simple sanity check to fix the issue.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2023-53476:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()&#xA;&#xA;This condition needs to match the previous &#34;if (epcp-&gt;state == LISTEN) {&#34;&#xA;exactly to avoid a NULL dereference of either &#34;listen_ep&#34; or &#34;ep&#34;. The&#xA;problem is that &#34;epcp&#34; has been re-assigned so just testing&#xA;&#34;if (epcp-&gt;state == LISTEN) {&#34; a second time is not sufficient.&#xA;CVE-2023-53482:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu: Fix error unwind in iommu_group_alloc()&#xA;&#xA;If either iommu_group_grate_file() fails then the&#xA;iommu_group is leaked.&#xA;&#xA;Destroy it on these error paths.&#xA;&#xA;Found by kselftest/iommu/iommufd_fail_nth&#xA;CVE-2023-53682:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hwmon: (xgene) Fix ioremap and memremap leak&#xA;&#xA;Smatch reports:&#xA;&#xA;drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:&#xA;&#39;ctx-&gt;pcc_comm_addr&#39; from ioremap() not released on line: 757.&#xA;&#xA;This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),&#xA;ioremap and memremap is not released, which may cause a leak.&#xA;&#xA;To fix this, ioremap and memremap is modified to devm_ioremap and&#xA;devm_memremap.&#xA;&#xA;[groeck: Fixed formatting and subject]&#xA;CVE-2023-53732:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: Fix NULL dereference in ni_write_inode&#xA;&#xA;Syzbot reports a NULL dereference in ni_write_inode.&#xA;When creating a new inode, if allocation fails in mi_init function&#xA;(called in mi_format_new function), mi-&gt;mrec is set to NULL.&#xA;In the error path of this inode creation, mi-&gt;mrec is later&#xA;dereferenced in ni_write_inode.&#xA;&#xA;Add a NULL check to prevent NULL dereference.&#xA;CVE-2023-53998:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hwrng: virtio - Fix race on data_avail and actual data&#xA;&#xA;The virtio rng device kicks off a new entropy request whenever the&#xA;data available reaches zero.  When a new request occurs at the end&#xA;of a read operation, that is, when the result of that request is&#xA;only needed by the next reader, then there is a race between the&#xA;writing of the new data and the next reader.&#xA;&#xA;This is because there is no synchronisation whatsoever between the&#xA;writer and the reader.&#xA;&#xA;Fix this by writing data_avail with smp_store_release and reading&#xA;it with smp_load_acquire when we first enter read.  The subsequent&#xA;reads are safe because they&#39;re either protected by the first load&#xA;acquire, or by the completion mechanism.&#xA;&#xA;Also remove the redundant zeroing of data_idx in random_recv_done&#xA;(data_idx must already be zero at this point) and data_avail in&#xA;request_entropy (ditto).&#xA;CVE-2023-54020:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: sf-pdma: pdma_desc memory leak fix&#xA;&#xA;Commit b2cc5c465c2c (&#34;dmaengine: sf-pdma: Add multithread support for a&#xA;DMA channel&#34;) changed sf_pdma_prep_dma_memcpy() to unconditionally&#xA;allocate a new sf_pdma_desc each time it is called.&#xA;&#xA;The driver previously recycled descs, by checking the in_use flag, only&#xA;allocating additional descs if the existing one was in use. This logic&#xA;was removed in commit b2cc5c465c2c (&#34;dmaengine: sf-pdma: Add multithread&#xA;support for a DMA channel&#34;), but sf_pdma_free_desc() was not changed to&#xA;handle the new behaviour.&#xA;&#xA;As a result, each time sf_pdma_prep_dma_memcpy() is called, the previous&#xA;descriptor is leaked, over time leading to memory starvation:&#xA;&#xA;  unreferenced object 0xffffffe008447300 (size 192):&#xA;  comm &#34;irq/39-mchp_dsc&#34;, pid 343, jiffies 4294906910 (age 981.200s)&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 ff 00 00 00 00 b8 c1 00 00 00 00 00 00  ................&#xA;    00 00 70 08 10 00 00 00 00 00 00 c0 00 00 00 00  ..p.............&#xA;  backtrace:&#xA;    [&lt;00000000064a04f4&gt;] kmemleak_alloc+0x1e/0x28&#xA;    [&lt;00000000018927a7&gt;] kmem_cache_alloc+0x11e/0x178&#xA;    [&lt;000000002aea8d16&gt;] sf_pdma_prep_dma_memcpy+0x40/0x112&#xA;&#xA;Add the missing kfree() to sf_pdma_free_desc(), and remove the redundant&#xA;in_use flag.&#xA;CVE-2023-54177:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;quota: fix warning in dqgrab()&#xA;&#xA;There&#39;s issue as follows when do fault injection:&#xA;WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0&#xA;Modules linked in:&#xA;CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541&#xA;RIP: 0010:dquot_disable+0x13b7/0x18c0&#xA;RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980&#xA;RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002&#xA;RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000&#xA;R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130&#xA;R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118&#xA;FS:  00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dquot_load_quota_sb+0xd53/0x1060&#xA; dquot_resume+0x172/0x230&#xA; ext4_reconfigure+0x1dc6/0x27b0&#xA; reconfigure_super+0x515/0xa90&#xA; __x64_sys_fsconfig+0xb19/0xd20&#xA; do_syscall_64+0x39/0xb0&#xA; entry_SYSCALL_64_after_hwframe+0x63/0xcd&#xA;&#xA;Above issue may happens as follows:&#xA;ProcessA              ProcessB                    ProcessC&#xA;sys_fsconfig&#xA;  vfs_fsconfig_locked&#xA;   reconfigure_super&#xA;     ext4_remount&#xA;      dquot_suspend -&gt; suspend all type quota&#xA;&#xA;                 sys_fsconfig&#xA;                  vfs_fsconfig_locked&#xA;                    reconfigure_super&#xA;                     ext4_remount&#xA;                      dquot_resume&#xA;                       ret = dquot_load_quota_sb&#xA;                        add_dquot_ref&#xA;                                           do_open  -&gt; open file O_RDWR&#xA;                                            vfs_open&#xA;                                             do_dentry_open&#xA;                                              get_write_access&#xA;                                               atomic_inc_unless_negative(&amp;inode-&gt;i_writecount)&#xA;                                              ext4_file_open&#xA;                                               dquot_file_open&#xA;                                                dquot_initialize&#xA;                                                  __dquot_initialize&#xA;                                                   dqget&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;    atomic_inc(&amp;dquot-&gt;dq_count);&#xA;&#xA;                          __dquot_initialize&#xA;                           __dquot_initialize&#xA;                            dqget&#xA;                             if (!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))&#xA;                               ext4_acquire_dquot&#xA;&#x9;&#x9;&#x9;        -&gt; Return error DQ_ACTIVE_B flag isn&#39;t set&#xA;                         dquot_disable&#xA;&#x9;&#x9;&#x9;  invalidate_dquots&#xA;&#x9;&#x9;&#x9;   if (atomic_read(&amp;dquot-&gt;dq_count))&#xA;&#x9;                    dqgrab&#xA;&#x9;&#x9;&#x9;     WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))&#xA;&#x9;                      -&gt; Trigger warning&#xA;&#xA;In the above scenario, &#39;dquot-&gt;dq_flags&#39; has no DQ_ACTIVE_B is normal when&#xA;dqgrab().&#xA;To solve above issue just replace the dqgrab() use in invalidate_dquots() with&#xA;atomic_inc(&amp;dquot-&gt;dq_count).&#xA;CVE-2023-54181:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Fix issue in verifying allow_ptr_leaks&#xA;&#xA;After we converted the capabilities of our networking-bpf program from&#xA;cap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf program&#xA;failed to start. Because it failed the bpf verifier, and the error log&#xA;is &#34;R3 pointer comparison prohibited&#34;.&#xA;&#xA;A simple reproducer as follows,&#xA;&#xA;SEC(&#34;cls-ingress&#34;)&#xA;int ingress(struct __sk_buff *skb)&#xA;{&#xA;&#x9;struct iphdr *iph = (void *)(long)skb-&gt;data + sizeof(struct ethhdr);&#xA;&#xA;&#x9;if ((long)(iph + 1) &gt; (long)skb-&gt;data_end)&#xA;&#x9;&#x9;return TC_ACT_STOLEN;&#xA;&#x9;return TC_ACT_OK;&#xA;}&#xA;&#xA;Per discussion with Yonghong and Alexei [1], comparison of two packet&#xA;pointers is not a pointer leak. This patch fixes it.&#xA;&#xA;Our local kernel is 6.1.y and we expect this fix to be backported to&#xA;6.1.y, so stable is CCed.&#xA;&#xA;[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/&#xA;CVE-2023-54207:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: uclogic: Correct devm device reference for hidinput input_dev name&#xA;&#xA;Reference the HID device rather than the input device for the devm&#xA;allocation of the input_dev name. Referencing the input_dev would lead to a&#xA;use-after-free when the input_dev was unregistered and subsequently fires a&#xA;uevent that depends on the name. At the point of firing the uevent, the&#xA;name would be freed by devres management.&#xA;&#xA;Use devm_kasprintf to simplify the logic for allocating memory and&#xA;formatting the input_dev name string.&#xA;CVE-2024-23848:In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.&#xA;CVE-2024-25741:printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.&#xA;CVE-2024-26861:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wireguard: receive: annotate data-race around receiving_counter.counter&#xA;&#xA;Syzkaller with KCSAN identified a data-race issue when accessing&#xA;keypair-&gt;receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()&#xA;annotations to mark the data race as intentional.&#xA;&#xA;    BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll&#xA;&#xA;    write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0:&#xA;     counter_validate drivers/net/wireguard/receive.c:321 [inline]&#xA;     wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461&#xA;     __napi_poll+0x60/0x3b0 net/core/dev.c:6536&#xA;     napi_poll net/core/dev.c:6605 [inline]&#xA;     net_rx_action+0x32b/0x750 net/core/dev.c:6738&#xA;     __do_softirq+0xc4/0x279 kernel/softirq.c:553&#xA;     do_softirq+0x5e/0x90 kernel/softirq.c:454&#xA;     __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381&#xA;     __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]&#xA;     _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210&#xA;     spin_unlock_bh include/linux/spinlock.h:396 [inline]&#xA;     ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]&#xA;     wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499&#xA;     process_one_work kernel/workqueue.c:2633 [inline]&#xA;     ...&#xA;&#xA;    read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1:&#xA;     decrypt_packet drivers/net/wireguard/receive.c:252 [inline]&#xA;     wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501&#xA;     process_one_work kernel/workqueue.c:2633 [inline]&#xA;     process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706&#xA;     worker_thread+0x525/0x730 kernel/workqueue.c:2787&#xA;     ...&#xA;CVE-2024-27078:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: v4l2-tpg: fix some memleaks in tpg_alloc&#xA;&#xA;In tpg_alloc, resources should be deallocated in each and every&#xA;error-handling paths, since they are allocated in for statements.&#xA;Otherwise there would be memleaks because tpg_free is called only when&#xA;tpg_alloc return 0.&#xA;CVE-2024-39493:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak&#xA;&#xA;Using completion_done to determine whether the caller has gone&#xA;away only works after a complete call.  Furthermore it&#39;s still&#xA;possible that the caller has not yet called wait_for_completion,&#xA;resulting in another potential UAF.&#xA;&#xA;Fix this by making the caller use cancel_work_sync and then freeing&#xA;the memory safely.&#xA;CVE-2024-43098:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i3c: Use i3cdev-&gt;desc-&gt;info instead of calling i3c_device_get_info() to avoid deadlock&#xA;&#xA;A deadlock may happen since the i3c_master_register() acquires&#xA;&amp;i3cbus-&gt;lock twice. See the log below.&#xA;Use i3cdev-&gt;desc-&gt;info instead of calling i3c_device_info() to&#xA;avoid acquiring the lock twice.&#xA;&#xA;v2:&#xA;  - Modified the title and commit message&#xA;&#xA;============================================&#xA;WARNING: possible recursive locking detected&#xA;6.11.0-mainline&#xA;--------------------------------------------&#xA;init/1 is trying to acquire lock:&#xA;f1ffff80a6a40dc0 (&amp;i3cbus-&gt;lock){++++}-{3:3}, at: i3c_bus_normaluse_lock&#xA;&#xA;but task is already holding lock:&#xA;f1ffff80a6a40dc0 (&amp;i3cbus-&gt;lock){++++}-{3:3}, at: i3c_master_register&#xA;&#xA;other info that might help us debug this:&#xA; Possible unsafe locking scenario:&#xA;&#xA;       CPU0&#xA;       ----&#xA;  lock(&amp;i3cbus-&gt;lock);&#xA;  lock(&amp;i3cbus-&gt;lock);&#xA;&#xA; *** DEADLOCK ***&#xA;&#xA; May be due to missing lock nesting notation&#xA;&#xA;2 locks held by init/1:&#xA; #0: fcffff809b6798f8 (&amp;dev-&gt;mutex){....}-{3:3}, at: __driver_attach&#xA; #1: f1ffff80a6a40dc0 (&amp;i3cbus-&gt;lock){++++}-{3:3}, at: i3c_master_register&#xA;&#xA;stack backtrace:&#xA;CPU: 6 UID: 0 PID: 1 Comm: init&#xA;Call trace:&#xA; dump_backtrace+0xfc/0x17c&#xA; show_stack+0x18/0x28&#xA; dump_stack_lvl+0x40/0xc0&#xA; dump_stack+0x18/0x24&#xA; print_deadlock_bug+0x388/0x390&#xA; __lock_acquire+0x18bc/0x32ec&#xA; lock_acquire+0x134/0x2b0&#xA; down_read+0x50/0x19c&#xA; i3c_bus_normaluse_lock+0x14/0x24&#xA; i3c_device_get_info+0x24/0x58&#xA; i3c_device_uevent+0x34/0xa4&#xA; dev_uevent+0x310/0x384&#xA; kobject_uevent_env+0x244/0x414&#xA; kobject_uevent+0x14/0x20&#xA; device_add+0x278/0x460&#xA; device_register+0x20/0x34&#xA; i3c_master_register_new_i3c_devs+0x78/0x154&#xA; i3c_master_register+0x6a0/0x6d4&#xA; mtk_i3c_master_probe+0x3b8/0x4d8&#xA; platform_probe+0xa0/0xe0&#xA; really_probe+0x114/0x454&#xA; __driver_probe_device+0xa0/0x15c&#xA; driver_probe_device+0x3c/0x1ac&#xA; __driver_attach+0xc4/0x1f0&#xA; bus_for_each_dev+0x104/0x160&#xA; driver_attach+0x24/0x34&#xA; bus_add_driver+0x14c/0x294&#xA; driver_register+0x68/0x104&#xA; __platform_driver_register+0x20/0x30&#xA; init_module+0x20/0xfe4&#xA; do_one_initcall+0x184/0x464&#xA; do_init_module+0x58/0x1ec&#xA; load_module+0xefc/0x10c8&#xA; __arm64_sys_finit_module+0x238/0x33c&#xA; invoke_syscall+0x58/0x10c&#xA; el0_svc_common+0xa8/0xdc&#xA; do_el0_svc+0x1c/0x28&#xA; el0_svc+0x50/0xac&#xA; el0t_64_sync_handler+0x70/0xbc&#xA; el0t_64_sync+0x1a8/0x1ac&#xA;CVE-2024-43835:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;virtio_net: Fix napi_skb_cache_put warning&#xA;&#xA;After the commit bdacf3e34945 (&#34;net: Use nested-BH locking for&#xA;napi_alloc_cache.&#34;) was merged, the following warning began to appear:&#xA;&#xA;&#x9; WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0&#xA;&#xA;&#x9;  __warn+0x12f/0x340&#xA;&#x9;  napi_skb_cache_put+0x82/0x4b0&#xA;&#x9;  napi_skb_cache_put+0x82/0x4b0&#xA;&#x9;  report_bug+0x165/0x370&#xA;&#x9;  handle_bug+0x3d/0x80&#xA;&#x9;  exc_invalid_op+0x1a/0x50&#xA;&#x9;  asm_exc_invalid_op+0x1a/0x20&#xA;&#x9;  __free_old_xmit+0x1c8/0x510&#xA;&#x9;  napi_skb_cache_put+0x82/0x4b0&#xA;&#x9;  __free_old_xmit+0x1c8/0x510&#xA;&#x9;  __free_old_xmit+0x1c8/0x510&#xA;&#x9;  __pfx___free_old_xmit+0x10/0x10&#xA;&#xA;The issue arises because virtio is assuming it&#39;s running in NAPI context&#xA;even when it&#39;s not, such as in the netpoll case.&#xA;&#xA;To resolve this, modify virtnet_poll_tx() to only set NAPI when budget&#xA;is available. Same for virtnet_poll_cleantx(), which always assumed that&#xA;it was in a NAPI context.&#xA;CVE-2024-46763:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fou: Fix null-ptr-deref in GRO.&#xA;&#xA;We observed a null-ptr-deref in fou_gro_receive() while shutting down&#xA;a host.  [0]&#xA;&#xA;The NULL pointer is sk-&gt;sk_user_data, and the offset 8 is of protocol&#xA;in struct fou.&#xA;&#xA;When fou_release() is called due to netns dismantle or explicit tunnel&#xA;teardown, udp_tunnel_sock_release() sets NULL to sk-&gt;sk_user_data.&#xA;Then, the tunnel socket is destroyed after a single RCU grace period.&#xA;&#xA;So, in-flight udp4_gro_receive() could find the socket and execute the&#xA;FOU GRO handler, where sk-&gt;sk_user_data could be NULL.&#xA;&#xA;Let&#39;s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL&#xA;checks in FOU GRO handlers.&#xA;&#xA;[0]:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000008&#xA; PF: supervisor read access in kernel mode&#xA; PF: error_code(0x0000) - not-present page&#xA;PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0&#xA;SMP PTI&#xA;CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1&#xA;Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017&#xA;RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]&#xA;Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 &lt;0f&gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42&#xA;RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297&#xA;RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010&#xA;RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08&#xA;RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002&#xA;R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400&#xA;R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0&#xA;FS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)&#xA; ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)&#xA; ? no_context (arch/x86/mm/fault.c:752)&#xA; ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)&#xA; ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)&#xA; ? fou_gro_receive (net/ipv4/fou.c:233) [fou]&#xA; udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)&#xA; udp4_gro_receive (net/ipv4/udp_offload.c:604)&#xA; inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))&#xA; dev_gro_receive (net/core/dev.c:6035 (discriminator 4))&#xA; napi_gro_receive (net/core/dev.c:6170)&#xA; ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]&#xA; ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]&#xA; napi_poll (net/core/dev.c:6847)&#xA; net_rx_action (net/core/dev.c:6917)&#xA; __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)&#xA; asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)&#xA;&lt;/IRQ&gt;&#xA; do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)&#xA; irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)&#xA; common_interrupt (arch/x86/kernel/irq.c:239)&#xA; asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)&#xA;RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)&#xA;Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 &lt;fa&gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00&#xA;RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246&#xA;RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900&#xA;RDX: ffff93daee800000 RSI: ffff93d&#xA;---truncated---&#xA;CVE-2024-46783:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tcp_bpf: fix return value of tcp_bpf_sendmsg()&#xA;&#xA;When we cork messages in psock-&gt;cork, the last message triggers the&#xA;flushing will result in sending a sk_msg larger than the current&#xA;message size. In this case, in tcp_bpf_send_verdict(), &#39;copied&#39; becomes&#xA;negative at least in the following case:&#xA;&#xA;468         case __SK_DROP:&#xA;469         default:&#xA;470                 sk_msg_free_partial(sk, msg, tosend);&#xA;471                 sk_msg_apply_bytes(psock, tosend);&#xA;472                 *copied -= (tosend + delta); // &lt;==== HERE&#xA;473                 return -EACCES;&#xA;&#xA;Therefore, it could lead to the following BUG with a proper value of&#xA;&#39;copied&#39; (thanks to syzbot). We should not use negative &#39;copied&#39; as a&#xA;return value here.&#xA;&#xA;  ------------[ cut here ]------------&#xA;  kernel BUG at net/socket.c:733!&#xA;  Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP&#xA;  Modules linked in:&#xA;  CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0&#xA;  Hardware name: linux,dummy-virt (DT)&#xA;  pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)&#xA;  pc : sock_sendmsg_nosec net/socket.c:733 [inline]&#xA;  pc : sock_sendmsg_nosec net/socket.c:728 [inline]&#xA;  pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745&#xA;  lr : sock_sendmsg_nosec net/socket.c:730 [inline]&#xA;  lr : __sock_sendmsg+0x54/0x60 net/socket.c:745&#xA;  sp : ffff800088ea3b30&#xA;  x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000&#xA;  x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000&#xA;  x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90&#xA;  x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001&#xA;  x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf&#xA;  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000&#xA;  x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0&#xA;  x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000&#xA;  x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900&#xA;  x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef&#xA;  Call trace:&#xA;   sock_sendmsg_nosec net/socket.c:733 [inline]&#xA;   __sock_sendmsg+0x5c/0x60 net/socket.c:745&#xA;   ____sys_sendmsg+0x274/0x2ac net/socket.c:2597&#xA;   ___sys_sendmsg+0xac/0x100 net/socket.c:2651&#xA;   __sys_sendmsg+0x84/0xe0 net/socket.c:2680&#xA;   __do_sys_sendmsg net/socket.c:2689 [inline]&#xA;   __se_sys_sendmsg net/socket.c:2687 [inline]&#xA;   __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687&#xA;   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]&#xA;   invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49&#xA;   el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132&#xA;   do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151&#xA;   el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712&#xA;   el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730&#xA;   el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598&#xA;  Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)&#xA;  ---[ end trace 0000000000000000 ]---&#xA;CVE-2024-46810:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ&#xA;&#xA;Make sure the connector is fully initialized before signalling any&#xA;HPD events via drm_kms_helper_hotplug_event(), otherwise this may&#xA;lead to NULL pointer dereference.&#xA;CVE-2024-46832:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;MIPS: cevt-r4k: Don&#39;t call get_c0_compare_int if timer irq is installed&#xA;&#xA;This avoids warning:&#xA;&#xA;[    0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283&#xA;&#xA;Caused by get_c0_compare_int on secondary CPU.&#xA;&#xA;We also skipped saving IRQ number to struct clock_event_device *cd as&#xA;it&#39;s never used by clockevent core, as per comments it&#39;s only meant&#xA;for &#34;non CPU local devices&#34;.&#xA;CVE-2024-47143:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dma-debug: fix a possible deadlock on radix_lock&#xA;&#xA;radix_lock() shouldn&#39;t be held while holding dma_hash_entry[idx].lock&#xA;otherwise, there&#39;s a possible deadlock scenario when&#xA;dma debug API is called holding rq_lock():&#xA;&#xA;CPU0                   CPU1                       CPU2&#xA;dma_free_attrs()&#xA;check_unmap()          add_dma_entry()            __schedule() //out&#xA;                                                  (A) rq_lock()&#xA;get_hash_bucket()&#xA;(A) dma_entry_hash&#xA;                                                  check_sync()&#xA;                       (A) radix_lock()           (W) dma_entry_hash&#xA;dma_entry_free()&#xA;(W) radix_lock()&#xA;                       // CPU2&#39;s one&#xA;                       (W) rq_lock()&#xA;&#xA;CPU1 situation can happen when it extending radix tree and&#xA;it tries to wake up kswapd via wake_all_kswapd().&#xA;&#xA;CPU2 situation can happen while perf_event_task_sched_out()&#xA;(i.e. dma sync operation is called while deleting perf_event using&#xA; etm and etr tmc which are Arm Coresight hwtracing driver backends).&#xA;&#xA;To remove this possible situation, call dma_entry_free() after&#xA;put_hash_bucket() in check_unmap().&#xA;CVE-2024-47706:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;block, bfq: fix possible UAF for bfqq-&gt;bic with merge chain&#xA;&#xA;1) initial state, three tasks:&#xA;&#xA;&#x9;&#x9;Process 1       Process 2&#x9;Process 3&#xA;&#x9;&#x9; (BIC1)          (BIC2)&#x9;&#x9; (BIC3)&#xA;&#x9;&#x9;  |  Λ            |  Λ&#x9;&#x9;  |  Λ&#xA;&#x9;&#x9;  |  |            |  |&#x9;&#x9;  |  |&#xA;&#x9;&#x9;  V  |            V  |&#x9;&#x9;  V  |&#xA;&#x9;&#x9;  bfqq1           bfqq2&#x9;&#x9;  bfqq3&#xA;process ref:&#x9;   1&#x9;&#x9;    1&#x9;&#x9;    1&#xA;&#xA;2) bfqq1 merged to bfqq2:&#xA;&#xA;&#x9;&#x9;Process 1       Process 2&#x9;Process 3&#xA;&#x9;&#x9; (BIC1)          (BIC2)&#x9;&#x9; (BIC3)&#xA;&#x9;&#x9;  |               |&#x9;&#x9;  |  Λ&#xA;&#x9;&#x9;  \--------------\|&#x9;&#x9;  |  |&#xA;&#x9;&#x9;                  V&#x9;&#x9;  V  |&#xA;&#x9;&#x9;  bfqq1---------&gt;bfqq2&#x9;&#x9;  bfqq3&#xA;process ref:&#x9;   0&#x9;&#x9;    2&#x9;&#x9;    1&#xA;&#xA;3) bfqq2 merged to bfqq3:&#xA;&#xA;&#x9;&#x9;Process 1       Process 2&#x9;Process 3&#xA;&#x9;&#x9; (BIC1)          (BIC2)&#x9;&#x9; (BIC3)&#xA;&#x9; here -&gt; Λ                |&#x9;&#x9;  |&#xA;&#x9;&#x9;  \--------------\ \-------------\|&#xA;&#x9;&#x9;                  V&#x9;&#x9;  V&#xA;&#x9;&#x9;  bfqq1---------&gt;bfqq2----------&gt;bfqq3&#xA;process ref:&#x9;   0&#x9;&#x9;    1&#x9;&#x9;    3&#xA;&#xA;In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then&#xA;get bfqq3 through merge chain, and finially handle IO by bfqq3.&#xA;Howerver, current code will think bfqq2 is owned by BIC1, like initial&#xA;state, and set bfqq2-&gt;bic to BIC1.&#xA;&#xA;bfq_insert_request&#xA;-&gt; by Process 1&#xA; bfqq = bfq_init_rq(rq)&#xA;  bfqq = bfq_get_bfqq_handle_split&#xA;   bfqq = bic_to_bfqq&#xA;   -&gt; get bfqq2 from BIC1&#xA; bfqq-&gt;ref++&#xA; rq-&gt;elv.priv[0] = bic&#xA; rq-&gt;elv.priv[1] = bfqq&#xA; if (bfqq_process_refs(bfqq) == 1)&#xA;  bfqq-&gt;bic = bic&#xA;  -&gt; record BIC1 to bfqq2&#xA;&#xA;  __bfq_insert_request&#xA;   new_bfqq = bfq_setup_cooperator&#xA;   -&gt; get bfqq3 from bfqq2-&gt;new_bfqq&#xA;   bfqq_request_freed(bfqq)&#xA;   new_bfqq-&gt;ref++&#xA;   rq-&gt;elv.priv[1] = new_bfqq&#xA;   -&gt; handle IO by bfqq3&#xA;&#xA;Fix the problem by checking bfqq is from merge chain fist. And this&#xA;might fix a following problem reported by our syzkaller(unreproducible):&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]&#xA;BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]&#xA;BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889&#xA;Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595&#xA;&#xA;CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G             L     6.6.0-07439-gba2303cacfda #6&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014&#xA;Workqueue: kblockd blk_mq_requeue_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:88 [inline]&#xA; dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106&#xA; print_address_description mm/kasan/report.c:364 [inline]&#xA; print_report+0x10d/0x610 mm/kasan/report.c:475&#xA; kasan_report+0x8e/0xc0 mm/kasan/report.c:588&#xA; bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]&#xA; bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]&#xA; bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889&#xA; bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757&#xA; bfq_init_rq block/bfq-iosched.c:6876 [inline]&#xA; bfq_insert_request block/bfq-iosched.c:6254 [inline]&#xA; bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304&#xA; blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593&#xA; blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502&#xA; process_one_work kernel/workqueue.c:2627 [inline]&#xA; process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700&#xA; worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781&#xA; kthread+0x33c/0x440 kernel/kthread.c:388&#xA; ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 20776:&#xA; kasan_save_stack+0x20/0x40 mm/kasan/common.c:45&#xA; kasan_set_track+0x25/0x30 mm/kasan/common.c:52&#xA; __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328&#xA; kasan_slab_alloc include/linux/kasan.h:188 [inline]&#xA; slab_post_alloc_hook mm/slab.h:763 [inline]&#xA; slab_alloc_node mm/slub.c:3458 [inline]&#xA; kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503&#xA; ioc_create_icq block/blk-ioc.c:370 [inline]&#xA;---truncated---&#xA;CVE-2024-48881:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again&#xA;&#xA;Commit 028ddcac477b (&#34;bcache: Remove unnecessary NULL point check in&#xA;node allocations&#34;) leads a NULL pointer deference in cache_set_flush().&#xA;&#xA;1721         if (!IS_ERR_OR_NULL(c-&gt;root))&#xA;1722                 list_add(&amp;c-&gt;root-&gt;list, &amp;c-&gt;btree_cache);&#xA;&#xA;&gt;From the above code in cache_set_flush(), if previous registration code&#xA;fails before allocating c-&gt;root, it is possible c-&gt;root is NULL as what&#xA;it is initialized. __bch_btree_node_alloc() never returns NULL but&#xA;c-&gt;root is possible to be NULL at above line 1721.&#xA;&#xA;This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.&#xA;CVE-2024-49851:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tpm: Clean up TPM space after command failure&#xA;&#xA;tpm_dev_transmit prepares the TPM space before attempting command&#xA;transmission. However if the command fails no rollback of this&#xA;preparation is done. This can result in transient handles being leaked&#xA;if the device is subsequently closed with no further commands performed.&#xA;&#xA;Fix this by flushing the space in the event of command transmission&#xA;failure.&#xA;CVE-2024-49890:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/pm: ensure the fw_info is not null before using it&#xA;&#xA;This resolves the dereference null return value warning&#xA;reported by Coverity.&#xA;CVE-2024-49935:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPI: PAD: fix crash in exit_round_robin()&#xA;&#xA;The kernel occasionally crashes in cpumask_clear_cpu(), which is called&#xA;within exit_round_robin(), because when executing clear_bit(nr, addr) with&#xA;nr set to 0xffffffff, the address calculation may cause misalignment within&#xA;the memory, leading to access to an invalid memory address.&#xA;&#xA;----------&#xA;BUG: unable to handle kernel paging request at ffffffffe0740618&#xA;        ...&#xA;CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G           OE  X --------- -  - 4.18.0-425.19.2.el8_7.x86_64 #1&#xA;        ...&#xA;RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]&#xA;Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 &lt;f0&gt; 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31&#xA;RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202&#xA;RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246&#xA;RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8&#xA;R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e&#xA;R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e&#xA;FS:  0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; ? acpi_pad_add+0x120/0x120 [acpi_pad]&#xA; kthread+0x10b/0x130&#xA; ? set_kthread_struct+0x50/0x50&#xA; ret_from_fork+0x1f/0x40&#xA;        ...&#xA;CR2: ffffffffe0740618&#xA;&#xA;crash&gt; dis -lr ffffffffc0726923&#xA;        ...&#xA;/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114&#xA;0xffffffffc0726918 &lt;power_saving_thread+776&gt;:&#x9;mov    %r12d,%r12d&#xA;/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325&#xA;0xffffffffc072691b &lt;power_saving_thread+779&gt;:&#x9;mov    -0x3f8d7de0(,%r12,4),%eax&#xA;/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80&#xA;0xffffffffc0726923 &lt;power_saving_thread+787&gt;:&#x9;lock btr %rax,0x19cf4(%rip)        # 0xffffffffc0740620 &lt;pad_busy_cpus_bits&gt;&#xA;&#xA;crash&gt; px tsk_in_cpu[14]&#xA;$66 = 0xffffffff&#xA;&#xA;crash&gt; px 0xffffffffc072692c+0x19cf4&#xA;$99 = 0xffffffffc0740620&#xA;&#xA;crash&gt; sym 0xffffffffc0740620&#xA;ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]&#xA;&#xA;crash&gt; px pad_busy_cpus_bits[0]&#xA;$42 = 0xfffc0&#xA;----------&#xA;&#xA;To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling&#xA;cpumask_clear_cpu() in exit_round_robin(), just as it is done in&#xA;round_robin_cpu().&#xA;&#xA;[ rjw: Subject edit, avoid updates to the same value ]&#xA;CVE-2024-49962:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()&#xA;&#xA;ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0&#xA;&#xA;ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause&#xA;NULL pointer dereference later.&#xA;&#xA;[ rjw: Subject and changelog edits ]&#xA;CVE-2024-50096:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error&#xA;&#xA;The `nouveau_dmem_copy_one` function ensures that the copy push command is&#xA;sent to the device firmware but does not track whether it was executed&#xA;successfully.&#xA;&#xA;In the case of a copy error (e.g., firmware or hardware failure), the&#xA;copy push command will be sent via the firmware channel, and&#xA;`nouveau_dmem_copy_one` will likely report success, leading to the&#xA;`migrate_to_ram` function returning a dirty HIGH_USER page to the user.&#xA;&#xA;This can result in a security vulnerability, as a HIGH_USER page that may&#xA;contain sensitive or corrupted data could be returned to the user.&#xA;&#xA;To prevent this vulnerability, we allocate a zero page. Thus, in case of&#xA;an error, a non-dirty (zero) page will be returned to the user.&#xA;CVE-2024-50117:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd: Guard against bad data for ATIF ACPI method&#xA;&#xA;If a BIOS provides bad data in response to an ATIF method call&#xA;this causes a NULL pointer dereference in the caller.&#xA;&#xA;```&#xA;? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))&#xA;? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)&#xA;? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))&#xA;? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))&#xA;? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)&#xA;? exc_page_fault (arch/x86/mm/fault.c:1542)&#xA;? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)&#xA;? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu&#xA;? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu&#xA;```&#xA;&#xA;It has been encountered on at least one system, so guard for it.&#xA;&#xA;(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)&#xA;CVE-2024-50167:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;be2net: fix potential memory leak in be_xmit()&#xA;&#xA;The be_xmit() returns NETDEV_TX_OK without freeing skb&#xA;in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.&#xA;CVE-2024-50168:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()&#xA;&#xA;The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb&#xA;in case of skb-&gt;len being too long, add dev_kfree_skb() to fix it.&#xA;CVE-2024-50295:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: arc: fix the device for dma_map_single/dma_unmap_single&#xA;&#xA;The ndev-&gt;dev and pdev-&gt;dev aren&#39;t the same device, use ndev-&gt;dev.parent&#xA;which has dma_mask, ndev-&gt;dev.parent is just pdev-&gt;dev.&#xA;Or it would cause the following issue:&#xA;&#xA;[   39.933526] ------------[ cut here ]------------&#xA;[   39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8&#xA;CVE-2024-50304:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()&#xA;&#xA;The per-netns IP tunnel hash table is protected by the RTNL mutex and&#xA;ip_tunnel_find() is only called from the control path where the mutex is&#xA;taken.&#xA;&#xA;Add a lockdep expression to hlist_for_each_entry_rcu() in&#xA;ip_tunnel_find() in order to validate that the mutex is held and to&#xA;silence the suspicious RCU usage warning [1].&#xA;&#xA;[1]&#xA;WARNING: suspicious RCU usage&#xA;6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted&#xA;-----------------------------&#xA;net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!&#xA;&#xA;other info that might help us debug this:&#xA;&#xA;rcu_scheduler_active = 2, debug_locks = 1&#xA;1 lock held by ip/362:&#xA; #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60&#xA;&#xA;stack backtrace:&#xA;CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139&#xA;Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0xba/0x110&#xA; lockdep_rcu_suspicious.cold+0x4f/0xd6&#xA; ip_tunnel_find+0x435/0x4d0&#xA; ip_tunnel_newlink+0x517/0x7a0&#xA; ipgre_newlink+0x14c/0x170&#xA; __rtnl_newlink+0x1173/0x19c0&#xA; rtnl_newlink+0x6c/0xa0&#xA; rtnetlink_rcv_msg+0x3cc/0xf60&#xA; netlink_rcv_skb+0x171/0x450&#xA; netlink_unicast+0x539/0x7f0&#xA; netlink_sendmsg+0x8c1/0xd80&#xA; ____sys_sendmsg+0x8f9/0xc20&#xA; ___sys_sendmsg+0x197/0x1e0&#xA; __sys_sendmsg+0x122/0x1f0&#xA; do_syscall_64+0xbb/0x1d0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-52332:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;igb: Fix potential invalid memory access in igb_init_module()&#xA;&#xA;The pci_register_driver() can fail and when this happened, the dca_notifier&#xA;needs to be unregistered, otherwise the dca_notifier can be called when&#xA;igb fails to install, resulting to invalid memory access.&#xA;CVE-2024-53103:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hv_sock: Initializing vsk-&gt;trans to NULL to prevent a dangling pointer&#xA;&#xA;When hvs is released, there is a possibility that vsk-&gt;trans may not&#xA;be initialized to NULL, which could lead to a dangling pointer.&#xA;This issue is resolved by initializing vsk-&gt;trans to NULL.&#xA;CVE-2024-53119:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;virtio/vsock: Fix accept_queue memory leak&#xA;&#xA;As the final stages of socket destruction may be delayed, it is possible&#xA;that virtio_transport_recv_listen() will be called after the accept_queue&#xA;has been flushed, but before the SOCK_DONE flag has been set. As a result,&#xA;sockets enqueued after the flush would remain unremoved, leading to a&#xA;memory leak.&#xA;&#xA;vsock_release&#xA;  __vsock_release&#xA;    lock&#xA;    virtio_transport_release&#xA;      virtio_transport_close&#xA;        schedule_delayed_work(close_work)&#xA;    sk_shutdown = SHUTDOWN_MASK&#xA;(!) flush accept_queue&#xA;    release&#xA;                                        virtio_transport_recv_pkt&#xA;                                          vsock_find_bound_socket&#xA;                                          lock&#xA;                                          if flag(SOCK_DONE) return&#xA;                                          virtio_transport_recv_listen&#xA;                                            child = vsock_create_connected&#xA;                                      (!)   vsock_enqueue_accept(child)&#xA;                                          release&#xA;close_work&#xA;  lock&#xA;  virtio_transport_do_close&#xA;    set_flag(SOCK_DONE)&#xA;    virtio_transport_remove_sock&#xA;      vsock_remove_sock&#xA;        vsock_remove_bound&#xA;  release&#xA;&#xA;Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during&#xA;socket destruction.&#xA;&#xA;unreferenced object 0xffff888109e3f800 (size 2040):&#xA;  comm &#34;kworker/5:2&#34;, pid 371, jiffies 4294940105&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............&#xA;  backtrace (crc 9e5f4e84):&#xA;    [&lt;ffffffff81418ff1&gt;] kmem_cache_alloc_noprof+0x2c1/0x360&#xA;    [&lt;ffffffff81d27aa0&gt;] sk_prot_alloc+0x30/0x120&#xA;    [&lt;ffffffff81d2b54c&gt;] sk_alloc+0x2c/0x4b0&#xA;    [&lt;ffffffff81fe049a&gt;] __vsock_create.constprop.0+0x2a/0x310&#xA;    [&lt;ffffffff81fe6d6c&gt;] virtio_transport_recv_pkt+0x4dc/0x9a0&#xA;    [&lt;ffffffff81fe745d&gt;] vsock_loopback_work+0xfd/0x140&#xA;    [&lt;ffffffff810fc6ac&gt;] process_one_work+0x20c/0x570&#xA;    [&lt;ffffffff810fce3f&gt;] worker_thread+0x1bf/0x3a0&#xA;    [&lt;ffffffff811070dd&gt;] kthread+0xdd/0x110&#xA;    [&lt;ffffffff81044fdd&gt;] ret_from_fork+0x2d/0x50&#xA;    [&lt;ffffffff8100785a&gt;] ret_from_fork_asm+0x1a/0x30&#xA;CVE-2024-53121:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mlx5: fs, lock FTE when checking if active&#xA;&#xA;The referenced commits introduced a two-step process for deleting FTEs:&#xA;&#xA;- Lock the FTE, delete it from hardware, set the hardware deletion function&#xA;  to NULL and unlock the FTE.&#xA;- Lock the parent flow group, delete the software copy of the FTE, and&#xA;  remove it from the xarray.&#xA;&#xA;However, this approach encounters a race condition if a rule with the same&#xA;match value is added simultaneously. In this scenario, fs_core may set the&#xA;hardware deletion function to NULL prematurely, causing a panic during&#xA;subsequent rule deletions.&#xA;&#xA;To prevent this, ensure the active flag of the FTE is checked under a lock,&#xA;which will prevent the fs_core layer from attaching a new steering rule to&#xA;an FTE that is in the process of deletion.&#xA;&#xA;[  438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func&#xA;[  438.968205] ------------[ cut here ]------------&#xA;[  438.968654] refcount_t: decrement hit 0; leaking memory.&#xA;[  438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110&#xA;[  438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]&#xA;[  438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8&#xA;[  438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA;[  438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110&#xA;[  438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff &lt;0f&gt; 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90&#xA;[  438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286&#xA;[  438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000&#xA;[  438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0&#xA;[  438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0&#xA;[  438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0&#xA;[  438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0&#xA;[  438.980607] FS:  00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000&#xA;[  438.983984] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0&#xA;[  438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;[  438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;[  438.986507] Call Trace:&#xA;[  438.986799]  &lt;TASK&gt;&#xA;[  438.987070]  ? __warn+0x7d/0x110&#xA;[  438.987426]  ? refcount_warn_saturate+0xfb/0x110&#xA;[  438.987877]  ? report_bug+0x17d/0x190&#xA;[  438.988261]  ? prb_read_valid+0x17/0x20&#xA;[  438.988659]  ? handle_bug+0x53/0x90&#xA;[  438.989054]  ? exc_invalid_op+0x14/0x70&#xA;[  438.989458]  ? asm_exc_invalid_op+0x16/0x20&#xA;[  438.989883]  ? refcount_warn_saturate+0xfb/0x110&#xA;[  438.990348]  mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]&#xA;[  438.990932]  __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]&#xA;[  438.991519]  ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]&#xA;[  438.992054]  ? xas_load+0x9/0xb0&#xA;[  438.992407]  mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]&#xA;[  438.993037]  mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]&#xA;[  438.993623]  mlx5e_flow_put+0x29/0x60 [mlx5_core]&#xA;[  438.994161]  mlx5e_delete_flower+0x261/0x390 [mlx5_core]&#xA;[  438.994728]  tc_setup_cb_destroy+0xb9/0x190&#xA;[  438.995150]  fl_hw_destroy_filter+0x94/0xc0 [cls_flower]&#xA;[  438.995650]  fl_change+0x11a4/0x13c0 [cls_flower]&#xA;[  438.996105]  tc_new_tfilter+0x347/0xbc0&#xA;[  438.996503]  ? __&#xA;---truncated---&#xA;CVE-2024-53124:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: fix data-races around sk-&gt;sk_forward_alloc&#xA;&#xA;Syzkaller reported this warning:&#xA; ------------[ cut here ]------------&#xA; WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0&#xA; Modules linked in:&#xA; CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26&#xA; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA; RIP: 0010:inet_sock_destruct+0x1c5/0x1e0&#xA; Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 &lt;0f&gt; 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00&#xA; RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206&#xA; RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007&#xA; RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00&#xA; RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007&#xA; R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00&#xA; R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78&#xA; FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? __warn+0x88/0x130&#xA;  ? inet_sock_destruct+0x1c5/0x1e0&#xA;  ? report_bug+0x18e/0x1a0&#xA;  ? handle_bug+0x53/0x90&#xA;  ? exc_invalid_op+0x18/0x70&#xA;  ? asm_exc_invalid_op+0x1a/0x20&#xA;  ? inet_sock_destruct+0x1c5/0x1e0&#xA;  __sk_destruct+0x2a/0x200&#xA;  rcu_do_batch+0x1aa/0x530&#xA;  ? rcu_do_batch+0x13b/0x530&#xA;  rcu_core+0x159/0x2f0&#xA;  handle_softirqs+0xd3/0x2b0&#xA;  ? __pfx_smpboot_thread_fn+0x10/0x10&#xA;  run_ksoftirqd+0x25/0x30&#xA;  smpboot_thread_fn+0xdd/0x1d0&#xA;  kthread+0xd3/0x100&#xA;  ? __pfx_kthread+0x10/0x10&#xA;  ret_from_fork+0x34/0x50&#xA;  ? __pfx_kthread+0x10/0x10&#xA;  ret_from_fork_asm+0x1a/0x30&#xA;  &lt;/TASK&gt;&#xA; ---[ end trace 0000000000000000 ]---&#xA;&#xA;Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()&#xA;concurrently when sk-&gt;sk_state == TCP_LISTEN with sk-&gt;sk_lock unlocked,&#xA;which triggers a data-race around sk-&gt;sk_forward_alloc:&#xA;tcp_v6_rcv&#xA;    tcp_v6_do_rcv&#xA;        skb_clone_and_charge_r&#xA;            sk_rmem_schedule&#xA;                __sk_mem_schedule&#xA;                    sk_forward_alloc_add()&#xA;            skb_set_owner_r&#xA;                sk_mem_charge&#xA;                    sk_forward_alloc_add()&#xA;        __kfree_skb&#xA;            skb_release_all&#xA;                skb_release_head_state&#xA;                    sock_rfree&#xA;                        sk_mem_uncharge&#xA;                            sk_forward_alloc_add()&#xA;                            sk_mem_reclaim&#xA;                                // set local var reclaimable&#xA;                                __sk_mem_reclaim&#xA;                                    sk_forward_alloc_add()&#xA;&#xA;In this syzkaller testcase, two threads call&#xA;tcp_v6_do_rcv() with skb-&gt;truesize=768, the sk_forward_alloc changes like&#xA;this:&#xA; (cpu 1)             | (cpu 2)             | sk_forward_alloc&#xA; ...                 | ...                 | 0&#xA; __sk_mem_schedule() |                     | +4096 = 4096&#xA;                     | __sk_mem_schedule() | +4096 = 8192&#xA; sk_mem_charge()     |                     | -768  = 7424&#xA;                     | sk_mem_charge()     | -768  = 6656&#xA; ...                 |    ...              |&#xA; sk_mem_uncharge()   |                     | +768  = 7424&#xA; reclaimable=7424    |                     |&#xA;                     | sk_mem_uncharge()   | +768  = 8192&#xA;                     | reclaimable=8192    |&#xA; __sk_mem_reclaim()  |                     | -4096 = 4096&#xA;                     | __sk_mem_reclaim()  | -8192 = -4096 != 0&#xA;&#xA;The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when&#xA;sk-&gt;sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().&#xA;Fix the same issue in dccp_v6_do_rcv().&#xA;CVE-2024-53138:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mlx5e: kTLS, Fix incorrect page refcounting&#xA;&#xA;The kTLS tx handling code is using a mix of get_page() and&#xA;page_ref_inc() APIs to increment the page reference. But on the release&#xA;path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.&#xA;&#xA;This is an issue when using pages from large folios: the get_page()&#xA;references are stored on the folio page while the page_ref_inc()&#xA;references are stored directly in the given page. On release the folio&#xA;page will be dereferenced too many times.&#xA;&#xA;This was found while doing kTLS testing with sendfile() + ZC when the&#xA;served file was read from NFS on a kernel with NFS large folios support&#xA;(commit 49b29a573da8 (&#34;nfs: add support for large folios&#34;)).&#xA;CVE-2024-53140:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netlink: terminate outstanding dump on socket close&#xA;&#xA;Netlink supports iterative dumping of data. It provides the families&#xA;the following ops:&#xA; - start - (optional) kicks off the dumping process&#xA; - dump  - actual dump helper, keeps getting called until it returns 0&#xA; - done  - (optional) pairs with .start, can be used for cleanup&#xA;The whole process is asynchronous and the repeated calls to .dump&#xA;don&#39;t actually happen in a tight loop, but rather are triggered&#xA;in response to recvmsg() on the socket.&#xA;&#xA;This gives the user full control over the dump, but also means that&#xA;the user can close the socket without getting to the end of the dump.&#xA;To make sure .start is always paired with .done we check if there&#xA;is an ongoing dump before freeing the socket, and if so call .done.&#xA;&#xA;The complication is that sockets can get freed from BH and .done&#xA;is allowed to sleep. So we use a workqueue to defer the call, when&#xA;needed.&#xA;&#xA;Unfortunately this does not work correctly. What we defer is not&#xA;the cleanup but rather releasing a reference on the socket.&#xA;We have no guarantee that we own the last reference, if someone&#xA;else holds the socket they may release it in BH and we&#39;re back&#xA;to square one.&#xA;&#xA;The whole dance, however, appears to be unnecessary. Only the user&#xA;can interact with dumps, so we can clean up when socket is closed.&#xA;And close always happens in process context. Some async code may&#xA;still access the socket after close, queue notification skbs to it etc.&#xA;but no dumps can start, end or otherwise make progress.&#xA;&#xA;Delete the workqueue and flush the dump state directly from the release&#xA;handler. Note that further cleanup is possible in -next, for instance&#xA;we now always call .done before releasing the main module reference,&#xA;so dump doesn&#39;t have to take a reference of its own.&#xA;CVE-2024-53145:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;um: Fix potential integer overflow during physmem setup&#xA;&#xA;This issue happens when the real map size is greater than LONG_MAX,&#xA;which can be easily triggered on UML/i386.&#xA;CVE-2024-53157:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;firmware: arm_scpi: Check the DVFS OPP count returned by the firmware&#xA;&#xA;Fix a kernel crash with the below call trace when the SCPI firmware&#xA;returns OPP count of zero.&#xA;&#xA;dvfs_info.opp_count may be zero on some platforms during the reboot&#xA;test, and the kernel will crash after dereferencing the pointer to&#xA;kcalloc(info-&gt;count, sizeof(*opp), GFP_KERNEL).&#xA;&#xA;  |  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028&#xA;  |  Mem abort info:&#xA;  |    ESR = 0x96000004&#xA;  |    Exception class = DABT (current EL), IL = 32 bits&#xA;  |    SET = 0, FnV = 0&#xA;  |    EA = 0, S1PTW = 0&#xA;  |  Data abort info:&#xA;  |    ISV = 0, ISS = 0x00000004&#xA;  |    CM = 0, WnR = 0&#xA;  |  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c&#xA;  |  [0000000000000028] pgd=0000000000000000&#xA;  |  Internal error: Oops: 96000004 [#1] SMP&#xA;  |  scpi-hwmon: probe of PHYT000D:00 failed with error -110&#xA;  |  Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)&#xA;  |  CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1&#xA;  |  Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS&#xA;  |  pstate: 60000005 (nZCv daif -PAN -UAO)&#xA;  |  pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]&#xA;  |  lr : clk_register+0x438/0x720&#xA;  |  Call trace:&#xA;  |   scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]&#xA;  |   devm_clk_hw_register+0x50/0xa0&#xA;  |   scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]&#xA;  |   scpi_clocks_probe+0x528/0x70c [clk_scpi]&#xA;  |   platform_drv_probe+0x58/0xa8&#xA;  |   really_probe+0x260/0x3d0&#xA;  |   driver_probe_device+0x12c/0x148&#xA;  |   device_driver_attach+0x74/0x98&#xA;  |   __driver_attach+0xb4/0xe8&#xA;  |   bus_for_each_dev+0x88/0xe0&#xA;  |   driver_attach+0x30/0x40&#xA;  |   bus_add_driver+0x178/0x2b0&#xA;  |   driver_register+0x64/0x118&#xA;  |   __platform_driver_register+0x54/0x60&#xA;  |   scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]&#xA;  |   do_one_initcall+0x54/0x220&#xA;  |   do_init_module+0x54/0x1c8&#xA;  |   load_module+0x14a4/0x1668&#xA;  |   __se_sys_finit_module+0xf8/0x110&#xA;  |   __arm64_sys_finit_module+0x24/0x30&#xA;  |   el0_svc_common+0x78/0x170&#xA;  |   el0_svc_handler+0x38/0x78&#xA;  |   el0_svc+0x8/0x340&#xA;  |  Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)&#xA;  |  ---[ end trace 06feb22469d89fa8 ]---&#xA;  |  Kernel panic - not syncing: Fatal exception&#xA;  |  SMP: stopping secondary CPUs&#xA;  |  Kernel Offset: disabled&#xA;  |  CPU features: 0x10,a0002008&#xA;  |  Memory Limit: none&#xA;CVE-2024-53164:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sched: fix ordering of qlen adjustment&#xA;&#xA;Changes to sch-&gt;q.qlen around qdisc_tree_reduce_backlog() need to happen&#xA;_before_ a call to said function because otherwise it may fail to notify&#xA;parent qdiscs when the child is about to become empty.&#xA;CVE-2024-53174:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;SUNRPC: make sure cache entry active before cache_show&#xA;&#xA;The function `c_show` was called with protection from RCU. This only&#xA;ensures that `cp` will not be freed. Therefore, the reference count for&#xA;`cp` can drop to zero, which will trigger a refcount use-after-free&#xA;warning when `cache_get` is called. To resolve this issue, use&#xA;`cache_get_rcu` to ensure that `cp` remains active.&#xA;&#xA;------------[ cut here ]------------&#xA;refcount_t: addition on 0; use-after-free.&#xA;WARNING: CPU: 7 PID: 822 at lib/refcount.c:25&#xA;refcount_warn_saturate+0xb1/0x120&#xA;CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;1.16.1-2.fc37 04/01/2014&#xA;RIP: 0010:refcount_warn_saturate+0xb1/0x120&#xA;&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; c_show+0x2fc/0x380 [sunrpc]&#xA; seq_read_iter+0x589/0x770&#xA; seq_read+0x1e5/0x270&#xA; proc_reg_read+0xe1/0x140&#xA; vfs_read+0x125/0x530&#xA; ksys_read+0xc1/0x160&#xA; do_syscall_64+0x5f/0x170&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2024-53181:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;um: vector: Do not use drvdata in release&#xA;&#xA;The drvdata is not available in release. Let&#39;s just use container_of()&#xA;to get the vector_device instance. Otherwise, removing a vector device&#xA;will result in a crash:&#xA;&#xA;RIP: 0033:vector_device_release+0xf/0x50&#xA;RSP: 00000000e187bc40  EFLAGS: 00010202&#xA;RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0&#xA;RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000&#xA;RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70&#xA;R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028&#xA;R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6&#xA;Kernel panic - not syncing: Segfault with no mm&#xA;CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1&#xA;Workqueue: events mc_work_proc&#xA;Stack:&#xA; 60028f61 623ae028 e187bc80 60276fcd&#xA; 6220b9c0 603f5820 623ae028 00000000&#xA; e187bcb0 603a2bcd 623ae000 62370010&#xA;Call Trace:&#xA; [&lt;60028f61&gt;] ? vector_device_release+0x0/0x50&#xA; [&lt;60276fcd&gt;] device_release+0x70/0xba&#xA; [&lt;603a2bcd&gt;] kobject_put+0xba/0xe7&#xA; [&lt;60277265&gt;] put_device+0x19/0x1c&#xA; [&lt;60281266&gt;] platform_device_put+0x26/0x29&#xA; [&lt;60281e5f&gt;] platform_device_unregister+0x2c/0x2e&#xA; [&lt;60029422&gt;] vector_remove+0x52/0x58&#xA; [&lt;60031316&gt;] ? mconsole_reply+0x0/0x50&#xA; [&lt;600310c8&gt;] mconsole_remove+0x160/0x1cc&#xA; [&lt;603b19f4&gt;] ? strlen+0x0/0x15&#xA; [&lt;60066611&gt;] ? __dequeue_entity+0x1a9/0x206&#xA; [&lt;600666a7&gt;] ? set_next_entity+0x39/0x63&#xA; [&lt;6006666e&gt;] ? set_next_entity+0x0/0x63&#xA; [&lt;60038fa6&gt;] ? um_set_signals+0x0/0x43&#xA; [&lt;6003070c&gt;] mc_work_proc+0x77/0x91&#xA; [&lt;60057664&gt;] process_scheduled_works+0x1b3/0x2dd&#xA; [&lt;60055f32&gt;] ? assign_work+0x0/0x58&#xA; [&lt;60057f0a&gt;] worker_thread+0x1e9/0x293&#xA; [&lt;6005406f&gt;] ? set_pf_worker+0x0/0x64&#xA; [&lt;6005d65d&gt;] ? arch_local_irq_save+0x0/0x2d&#xA; [&lt;6005d748&gt;] ? kthread_exit+0x0/0x3a&#xA; [&lt;60057d21&gt;] ? worker_thread+0x0/0x293&#xA; [&lt;6005dbf1&gt;] kthread+0x126/0x12b&#xA; [&lt;600219c5&gt;] new_thread_handler+0x85/0xb6&#xA;CVE-2024-53184:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;um: ubd: Do not use drvdata in release&#xA;&#xA;The drvdata is not available in release. Let&#39;s just use container_of()&#xA;to get the ubd instance. Otherwise, removing a ubd device will result&#xA;in a crash:&#xA;&#xA;RIP: 0033:blk_mq_free_tag_set+0x1f/0xba&#xA;RSP: 00000000e2083bf0  EFLAGS: 00010246&#xA;RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00&#xA;RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348&#xA;RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7&#xA;R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000&#xA;R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0&#xA;Kernel panic - not syncing: Segfault with no mm&#xA;CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1&#xA;Workqueue: events mc_work_proc&#xA;Stack:&#xA; 00000000 604f7ef0 62c5d000 62405d20&#xA; e2083c30 6002c776 6002c755 600e47ff&#xA; e2083c60 6025ffe3 04208060 603d36e0&#xA;Call Trace:&#xA; [&lt;6002c776&gt;] ubd_device_release+0x21/0x55&#xA; [&lt;6002c755&gt;] ? ubd_device_release+0x0/0x55&#xA; [&lt;600e47ff&gt;] ? kfree+0x0/0x100&#xA; [&lt;6025ffe3&gt;] device_release+0x70/0xba&#xA; [&lt;60381d6a&gt;] kobject_put+0xb5/0xe2&#xA; [&lt;6026027b&gt;] put_device+0x19/0x1c&#xA; [&lt;6026a036&gt;] platform_device_put+0x26/0x29&#xA; [&lt;6026ac5a&gt;] platform_device_unregister+0x2c/0x2e&#xA; [&lt;6002c52e&gt;] ubd_remove+0xb8/0xd6&#xA; [&lt;6002bb74&gt;] ? mconsole_reply+0x0/0x50&#xA; [&lt;6002b926&gt;] mconsole_remove+0x160/0x1cc&#xA; [&lt;6002bbbc&gt;] ? mconsole_reply+0x48/0x50&#xA; [&lt;6003379c&gt;] ? um_set_signals+0x3b/0x43&#xA; [&lt;60061c55&gt;] ? update_min_vruntime+0x14/0x70&#xA; [&lt;6006251f&gt;] ? dequeue_task_fair+0x164/0x235&#xA; [&lt;600620aa&gt;] ? update_cfs_group+0x0/0x40&#xA; [&lt;603a0e77&gt;] ? __schedule+0x0/0x3ed&#xA; [&lt;60033761&gt;] ? um_set_signals+0x0/0x43&#xA; [&lt;6002af6a&gt;] mc_work_proc+0x77/0x91&#xA; [&lt;600520b4&gt;] process_scheduled_works+0x1af/0x2c3&#xA; [&lt;6004ede3&gt;] ? assign_work+0x0/0x58&#xA; [&lt;600527a1&gt;] worker_thread+0x2f7/0x37a&#xA; [&lt;6004ee3b&gt;] ? set_pf_worker+0x0/0x64&#xA; [&lt;6005765d&gt;] ? arch_local_irq_save+0x0/0x2d&#xA; [&lt;60058e07&gt;] ? kthread_exit+0x0/0x3a&#xA; [&lt;600524aa&gt;] ? worker_thread+0x0/0x37a&#xA; [&lt;60058f9f&gt;] kthread+0x130/0x135&#xA; [&lt;6002068e&gt;] new_thread_handler+0x85/0xb6&#xA;CVE-2024-53680:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()&#xA;&#xA;Under certain kernel configurations when building with Clang/LLVM, the&#xA;compiler does not generate a return or jump as the terminator&#xA;instruction for ip_vs_protocol_init(), triggering the following objtool&#xA;warning during build time:&#xA;&#xA;  vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()&#xA;&#xA;At runtime, this either causes an oops when trying to load the ipvs&#xA;module or a boot-time panic if ipvs is built-in. This same issue has&#xA;been reported by the Intel kernel test robot previously.&#xA;&#xA;Digging deeper into both LLVM and the kernel code reveals this to be a&#xA;undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer&#xA;of 64 chars to store the registered protocol names and leaves it&#xA;uninitialized after definition. The function calls strnlen() when&#xA;concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE&#xA;strnlen() performs an extra step to check whether the last byte of the&#xA;input char buffer is a null character (commit 3009f891bb9f (&#34;fortify:&#xA;Allow strlen() and strnlen() to pass compile-time known lengths&#34;)).&#xA;This, together with possibly other configurations, cause the following&#xA;IR to be generated:&#xA;&#xA;  define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section &#34;.init.text&#34; align 16 !kcfi_type !29 {&#xA;    %1 = alloca [64 x i8], align 16&#xA;    ...&#xA;&#xA;  14:                                               ; preds = %11&#xA;    %15 = getelementptr inbounds i8, ptr %1, i64 63&#xA;    %16 = load i8, ptr %15, align 1&#xA;    %17 = tail call i1 @llvm.is.constant.i8(i8 %16)&#xA;    %18 = icmp eq i8 %16, 0&#xA;    %19 = select i1 %17, i1 %18, i1 false&#xA;    br i1 %19, label %20, label %23&#xA;&#xA;  20:                                               ; preds = %14&#xA;    %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23&#xA;    ...&#xA;&#xA;  23:                                               ; preds = %14, %11, %20&#xA;    %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24&#xA;    ...&#xA;  }&#xA;&#xA;The above code calculates the address of the last char in the buffer&#xA;(value %15) and then loads from it (value %16). Because the buffer is&#xA;never initialized, the LLVM GVN pass marks value %16 as undefined:&#xA;&#xA;  %13 = getelementptr inbounds i8, ptr %1, i64 63&#xA;  br i1 undef, label %14, label %17&#xA;&#xA;This gives later passes (SCCP, in particular) more DCE opportunities by&#xA;propagating the undef value further, and eventually removes everything&#xA;after the load on the uninitialized stack location:&#xA;&#xA;  define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section &#34;.init.text&#34; align 16 !kcfi_type !11 {&#xA;    %1 = alloca [64 x i8], align 16&#xA;    ...&#xA;&#xA;  12:                                               ; preds = %11&#xA;    %13 = getelementptr inbounds i8, ptr %1, i64 63&#xA;    unreachable&#xA;  }&#xA;&#xA;In this way, the generated native code will just fall through to the&#xA;next function, as LLVM does not generate any code for the unreachable IR&#xA;instruction and leaves the function without a terminator.&#xA;&#xA;Zero the on-stack buffer to avoid this possible UB.&#xA;CVE-2024-55916:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet&#xA;&#xA;If the KVP (or VSS) daemon starts before the VMBus channel&#39;s ringbuffer is&#xA;fully initialized, we can hit the panic below:&#xA;&#xA;hv_utils: Registering HyperV Utility Driver&#xA;hv_vmbus: registering driver hv_utils&#xA;...&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1&#xA;RIP: 0010:hv_pkt_iter_first+0x12/0xd0&#xA;Call Trace:&#xA;...&#xA; vmbus_recvpacket&#xA; hv_kvp_onchannelcallback&#xA; vmbus_on_event&#xA; tasklet_action_common&#xA; tasklet_action&#xA; handle_softirqs&#xA; irq_exit_rcu&#xA; sysvec_hyperv_stimer0&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; asm_sysvec_hyperv_stimer0&#xA;...&#xA; kvp_register_done&#xA; hvt_op_read&#xA; vfs_read&#xA; ksys_read&#xA; __x64_sys_read&#xA;&#xA;This can happen because the KVP/VSS channel callback can be invoked&#xA;even before the channel is fully opened:&#xA;1) as soon as hv_kvp_init() -&gt; hvutil_transport_init() creates&#xA;/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and&#xA;register itself to the driver by writing a message KVP_OP_REGISTER1 to the&#xA;file (which is handled by kvp_on_msg() -&gt;kvp_handle_handshake()) and&#xA;reading the file for the driver&#39;s response, which is handled by&#xA;hvt_op_read(), which calls hvt-&gt;on_read(), i.e. kvp_register_done().&#xA;&#xA;2) the problem with kvp_register_done() is that it can cause the&#xA;channel callback to be called even before the channel is fully opened,&#xA;and when the channel callback is starting to run, util_probe()-&gt;&#xA;vmbus_open() may have not initialized the ringbuffer yet, so the&#xA;callback can hit the panic of NULL pointer dereference.&#xA;&#xA;To reproduce the panic consistently, we can add a &#34;ssleep(10)&#34; for KVP in&#xA;__vmbus_open(), just before the first hv_ringbuffer_init(), and then we&#xA;unload and reload the driver hv_utils, and run the daemon manually within&#xA;the 10 seconds.&#xA;&#xA;Fix the panic by reordering the steps in util_probe() so the char dev&#xA;entry used by the KVP or VSS daemon is not created until after&#xA;vmbus_open() has completed. This reordering prevents the race condition&#xA;from happening.&#xA;CVE-2024-56369:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()&#xA;&#xA;drm_mode_vrefresh() is trying to avoid divide by zero&#xA;by checking whether htotal or vtotal are zero. But we may&#xA;still end up with a div-by-zero of vtotal*htotal*...&#xA;CVE-2024-56531:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: caiaq: Use snd_card_free_when_closed() at disconnection&#xA;&#xA;The USB disconnect callback is supposed to be short and not too-long&#xA;waiting.  OTOH, the current code uses snd_card_free() at&#xA;disconnection, but this waits for the close of all used fds, hence it&#xA;can take long.  It eventually blocks the upper layer USB ioctls, which&#xA;may trigger a soft lockup.&#xA;&#xA;An easy workaround is to replace snd_card_free() with&#xA;snd_card_free_when_closed().  This variant returns immediately while&#xA;the release of resources is done asynchronously by the card device&#xA;release at the last close.&#xA;&#xA;This patch also splits the code to the disconnect and the free phases;&#xA;the former is called immediately at the USB disconnect callback while&#xA;the latter is called from the card destructor.&#xA;CVE-2024-56532:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: us122l: Use snd_card_free_when_closed() at disconnection&#xA;&#xA;The USB disconnect callback is supposed to be short and not too-long&#xA;waiting.  OTOH, the current code uses snd_card_free() at&#xA;disconnection, but this waits for the close of all used fds, hence it&#xA;can take long.  It eventually blocks the upper layer USB ioctls, which&#xA;may trigger a soft lockup.&#xA;&#xA;An easy workaround is to replace snd_card_free() with&#xA;snd_card_free_when_closed().  This variant returns immediately while&#xA;the release of resources is done asynchronously by the card device&#xA;release at the last close.&#xA;&#xA;The loop of us122l-&gt;mmap_count check is dropped as well.  The check is&#xA;useless for the asynchronous operation with *_when_closed().&#xA;CVE-2024-56568:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu/arm-smmu: Defer probe of clients after smmu device bound&#xA;&#xA;Null pointer dereference occurs due to a race between smmu&#xA;driver probe and client driver probe, when of_dma_configure()&#xA;for client is called after the iommu_device_register() for smmu driver&#xA;probe has executed but before the driver_bound() for smmu driver&#xA;has been called.&#xA;&#xA;Following is how the race occurs:&#xA;&#xA;T1:Smmu device probe&#x9;&#x9;T2: Client device probe&#xA;&#xA;really_probe()&#xA;arm_smmu_device_probe()&#xA;iommu_device_register()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;really_probe()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;platform_dma_configure()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;of_dma_configure()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;of_dma_configure_id()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;of_iommu_configure()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;iommu_probe_device()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;iommu_init_device()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;arm_smmu_probe_device()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;arm_smmu_get_by_fwnode()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;driver_find_device_by_fwnode()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;driver_find_device()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;next_device()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;klist_next()&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;    /* null ptr&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;       assigned to smmu */&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;/* null ptr dereference&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;   while smmu-&gt;streamid_mask */&#xA;driver_bound()&#xA;&#x9;klist_add_tail()&#xA;&#xA;When this null smmu pointer is dereferenced later in&#xA;arm_smmu_probe_device, the device crashes.&#xA;&#xA;Fix this by deferring the probe of the client device&#xA;until the smmu device has bound to the arm smmu driver.&#xA;&#xA;[will: Add comment]&#xA;CVE-2024-56574:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: ts2020: fix null-ptr-deref in ts2020_probe()&#xA;&#xA;KASAN reported a null-ptr-deref issue when executing the following&#xA;command:&#xA;&#xA;  # echo ts2020 0x20 &gt; /sys/bus/i2c/devices/i2c-0/new_device&#xA;    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]&#xA;    CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24&#xA;    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)&#xA;    RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]&#xA;    RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202&#xA;    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809&#xA;    RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010&#xA;    RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6&#xA;    R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790&#xA;    R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001&#xA;    FS:  00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000&#xA;    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;    CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0&#xA;    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;    Call Trace:&#xA;     &lt;TASK&gt;&#xA;     ts2020_probe+0xad/0xe10 [ts2020]&#xA;     i2c_device_probe+0x421/0xb40&#xA;     really_probe+0x266/0x850&#xA;    ...&#xA;&#xA;The cause of the problem is that when using sysfs to dynamically register&#xA;an i2c device, there is no platform data, but the probe process of ts2020&#xA;needs to use platform data, resulting in a null pointer being accessed.&#xA;&#xA;Solve this problem by adding checks to platform data.&#xA;CVE-2024-56576:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: i2c: tc358743: Fix crash in the probe error path when using polling&#xA;&#xA;If an error occurs in the probe() function, we should remove the polling&#xA;timer that was alarmed earlier, otherwise the timer is called with&#xA;arguments that are already freed, which results in a crash.&#xA;&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268&#xA;Modules linked in:&#xA;CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226&#xA;Hardware name: Diasom DS-RK3568-SOM-EVB (DT)&#xA;pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : __run_timers+0x244/0x268&#xA;lr : __run_timers+0x1d4/0x268&#xA;sp : ffffff80eff2baf0&#xA;x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00&#xA;x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00&#xA;x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000&#xA;x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff&#xA;x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e&#xA;x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000&#xA;x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009&#xA;x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480&#xA;x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240&#xA;x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0&#xA;Call trace:&#xA; __run_timers+0x244/0x268&#xA; timer_expire_remote+0x50/0x68&#xA; tmigr_handle_remote+0x388/0x39c&#xA; run_timer_softirq+0x38/0x44&#xA; handle_softirqs+0x138/0x298&#xA; __do_softirq+0x14/0x20&#xA; ____do_softirq+0x10/0x1c&#xA; call_on_irq_stack+0x24/0x4c&#xA; do_softirq_own_stack+0x1c/0x2c&#xA; irq_exit_rcu+0x9c/0xcc&#xA; el1_interrupt+0x48/0xc0&#xA; el1h_64_irq_handler+0x18/0x24&#xA; el1h_64_irq+0x7c/0x80&#xA; default_idle_call+0x34/0x68&#xA; do_idle+0x23c/0x294&#xA; cpu_startup_entry+0x38/0x3c&#xA; secondary_start_kernel+0x128/0x160&#xA; __secondary_switched+0xb8/0xbc&#xA;---[ end trace 0000000000000000 ]---&#xA;CVE-2024-56587:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;leds: class: Protect brightness_show() with led_cdev-&gt;led_access mutex&#xA;&#xA;There is NULL pointer issue observed if from Process A where hid device&#xA;being added which results in adding a led_cdev addition and later a&#xA;another call to access of led_cdev attribute from Process B can result&#xA;in NULL pointer issue.&#xA;&#xA;Use mutex led_cdev-&gt;led_access to protect access to led-&gt;cdev and its&#xA;attribute inside brightness_show() and max_brightness_show() and also&#xA;update the comment for mutex that it should be used to protect the led&#xA;class device fields.&#xA;&#xA;&#x9;Process A &#x9;&#x9;&#x9;&#x9;Process B&#xA;&#xA; kthread+0x114&#xA; worker_thread+0x244&#xA; process_scheduled_works+0x248&#xA; uhid_device_add_worker+0x24&#xA; hid_add_device+0x120&#xA; device_add+0x268&#xA; bus_probe_device+0x94&#xA; device_initial_probe+0x14&#xA; __device_attach+0xfc&#xA; bus_for_each_drv+0x10c&#xA; __device_attach_driver+0x14c&#xA; driver_probe_device+0x3c&#xA; __driver_probe_device+0xa0&#xA; really_probe+0x190&#xA; hid_device_probe+0x130&#xA; ps_probe+0x990&#xA; ps_led_register+0x94&#xA; devm_led_classdev_register_ext+0x58&#xA; led_classdev_register_ext+0x1f8&#xA; device_create_with_groups+0x48&#xA; device_create_groups_vargs+0xc8&#xA; device_add+0x244&#xA; kobject_uevent+0x14&#xA; kobject_uevent_env[jt]+0x224&#xA; mutex_unlock[jt]+0xc4&#xA; __mutex_unlock_slowpath+0xd4&#xA; wake_up_q+0x70&#xA; try_to_wake_up[jt]+0x48c&#xA; preempt_schedule_common+0x28&#xA; __schedule+0x628&#xA; __switch_to+0x174&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;el0t_64_sync+0x1a8/0x1ac&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;el0t_64_sync_handler+0x68/0xbc&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;el0_svc+0x38/0x68&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;do_el0_svc+0x1c/0x28&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;el0_svc_common+0x80/0xe0&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;invoke_syscall+0x58/0x114&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;__arm64_sys_read+0x1c/0x2c&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;ksys_read+0x78/0xe8&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;vfs_read+0x1e0/0x2c8&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;kernfs_fop_read_iter+0x68/0x1b4&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;seq_read_iter+0x158/0x4ec&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;kernfs_seq_show+0x44/0x54&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;sysfs_kf_seq_show+0xb4/0x130&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;dev_attr_show+0x38/0x74&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;brightness_show+0x20/0x4c&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;dualshock4_led_get_brightness+0xc/0x74&#xA;&#xA;[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060&#xA;[ 3313.874301][ T4013] Mem abort info:&#xA;[ 3313.874303][ T4013]   ESR = 0x0000000096000006&#xA;[ 3313.874305][ T4013]   EC = 0x25: DABT (current EL), IL = 32 bits&#xA;[ 3313.874307][ T4013]   SET = 0, FnV = 0&#xA;[ 3313.874309][ T4013]   EA = 0, S1PTW = 0&#xA;[ 3313.874311][ T4013]   FSC = 0x06: level 2 translation fault&#xA;[ 3313.874313][ T4013] Data abort info:&#xA;[ 3313.874314][ T4013]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000&#xA;[ 3313.874316][ T4013]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;[ 3313.874318][ T4013]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000&#xA;..&#xA;&#xA;[ 3313.874332][ T4013] Dumping ftrace buffer:&#xA;[ 3313.874334][ T4013]    (ftrace buffer empty)&#xA;..&#xA;..&#xA;[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader&#xA;[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74&#xA;[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60&#xA;[ 3313.874656][ T4013] sp : ffffffc0b910bbd0&#xA;..&#xA;..&#xA;[ 3313.874685][ T4013] Call trace:&#xA;[ 3313.874687][ T4013]  dualshock4_led_get_brightness+0xc/0x74&#xA;[ 3313.874690][ T4013]  brightness_show+0x20/0x4c&#xA;[ 3313.874692][ T4013]  dev_attr_show+0x38/0x74&#xA;[ 3313.874696][ T4013]  sysfs_kf_seq_show+0xb4/0x130&#xA;[ 3313.874700][ T4013]  kernfs_seq_show+0x44/0x54&#xA;[ 3313.874703][ T4013]  seq_read_iter+0x158/0x4ec&#xA;[ 3313.874705][ T4013]  kernfs_fop_read_iter+0x68/0x1b4&#xA;[ 3313.874708][ T4013]  vfs_read+0x1e0/0x2c8&#xA;[ 3313.874711][ T4013]  ksys_read+0x78/0xe8&#xA;[ 3313.874714][ T4013]  __arm64_sys_read+0x1c/0x2c&#xA;[ 3313.874718][ T4013]  invoke_syscall+0x58/0x114&#xA;[ 3313.874721][ T4013]  el0_svc_common+0x80/0xe0&#xA;[ 3313.874724][ T4013]  do_el0_svc+0x1c/0x28&#xA;[ 3313.874727][ T4013]  el0_svc+0x38/0x68&#xA;[ 3313.874730][ T4013]  el0t_64_sync_handler+0x68/0xbc&#xA;[ 3313.874732][ T4013]  el0t_64_sync+0x1a8/0x1ac&#xA;CVE-2024-56593:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()&#xA;&#xA;This patch fixes a NULL pointer dereference bug in brcmfmac that occurs&#xA;when a high &#39;sd_sgentry_align&#39; value applies (e.g. 512) and a lot of queued SKBs&#xA;are sent from the pkt queue.&#xA;&#xA;The problem is the number of entries in the pre-allocated sgtable, it is&#xA;nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) &gt;&gt; 4 + 1.&#xA;Given the default [rt]xglom_size=32 it&#39;s actually 35 which is too small.&#xA;Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB&#xA;is added for each original SKB if tailroom isn&#39;t enough to hold tail_pad.&#xA;At least one sg entry is needed for each SKB. So, eventually the &#34;skb_queue_walk loop&#34;&#xA;in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return&#xA;NULL and this causes the oops.&#xA;&#xA;The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle&#xA;the worst-case.&#xA;Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464&#xA;additional bytes of memory.&#xA;CVE-2024-56603:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: af_can: do not leave a dangling sk pointer in can_create()&#xA;&#xA;On error can_create() frees the allocated sk object, but sock_init_data()&#xA;has already attached it to the provided sock object. This will leave a&#xA;dangling sk pointer in the sock object and may cause use-after-free later.&#xA;CVE-2024-56636:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;geneve: do not assume mac header is set in geneve_xmit_skb()&#xA;&#xA;We should not assume mac header is set in output path.&#xA;&#xA;Use skb_eth_hdr() instead of eth_hdr() to fix the issue.&#xA;&#xA;sysbot reported the following :&#xA;&#xA; WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]&#xA; WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]&#xA; WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]&#xA; WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA; RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]&#xA; RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]&#xA; RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]&#xA; RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039&#xA;Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 &lt;0f&gt; 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff&#xA;RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283&#xA;RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000&#xA;RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003&#xA;RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff&#xA;R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000&#xA;R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23&#xA;FS:  00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:5011 [inline]&#xA;  __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490&#xA;  dev_direct_xmit include/linux/netdevice.h:3181 [inline]&#xA;  packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285&#xA;  packet_snd net/packet/af_packet.c:3146 [inline]&#xA;  packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178&#xA;  sock_sendmsg_nosec net/socket.c:711 [inline]&#xA;  __sock_sendmsg net/socket.c:726 [inline]&#xA;  __sys_sendto+0x488/0x4f0 net/socket.c:2197&#xA;  __do_sys_sendto net/socket.c:2204 [inline]&#xA;  __se_sys_sendto net/socket.c:2200 [inline]&#xA;  __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-56637:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: ipset: Hold module reference while requesting a module&#xA;&#xA;User space may unload ip_set.ko while it is itself requesting a set type&#xA;backend module, leading to a kernel crash. The race condition may be&#xA;provoked by inserting an mdelay() right after the nfnl_unlock() call.&#xA;CVE-2024-56643:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dccp: Fix memory leak in dccp_feat_change_recv&#xA;&#xA;If dccp_feat_push_confirm() fails after new value for SP feature was accepted&#xA;without reconciliation (&#39;entry == NULL&#39; branch), memory allocated for that value&#xA;with dccp_feat_clone_sp_val() is never freed.&#xA;&#xA;Here is the kmemleak stack for this:&#xA;&#xA;unreferenced object 0xffff88801d4ab488 (size 8):&#xA;  comm &#34;syz-executor310&#34;, pid 1127, jiffies 4295085598 (age 41.666s)&#xA;  hex dump (first 8 bytes):&#xA;    01 b4 4a 1d 80 88 ff ff                          ..J.....&#xA;  backtrace:&#xA;    [&lt;00000000db7cabfe&gt;] kmemdup+0x23/0x50 mm/util.c:128&#xA;    [&lt;0000000019b38405&gt;] kmemdup include/linux/string.h:465 [inline]&#xA;    [&lt;0000000019b38405&gt;] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]&#xA;    [&lt;0000000019b38405&gt;] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]&#xA;    [&lt;0000000019b38405&gt;] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]&#xA;    [&lt;0000000019b38405&gt;] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416&#xA;    [&lt;00000000b1f6d94a&gt;] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125&#xA;    [&lt;0000000030d7b621&gt;] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650&#xA;    [&lt;000000001f74c72e&gt;] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688&#xA;    [&lt;00000000a6c24128&gt;] sk_backlog_rcv include/net/sock.h:1041 [inline]&#xA;    [&lt;00000000a6c24128&gt;] __release_sock+0x139/0x3b0 net/core/sock.c:2570&#xA;    [&lt;00000000cf1f3a53&gt;] release_sock+0x54/0x1b0 net/core/sock.c:3111&#xA;    [&lt;000000008422fa23&gt;] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]&#xA;    [&lt;000000008422fa23&gt;] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696&#xA;    [&lt;0000000015b6f64d&gt;] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735&#xA;    [&lt;0000000010122488&gt;] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865&#xA;    [&lt;00000000b4b70023&gt;] __sys_connect+0x165/0x1a0 net/socket.c:1882&#xA;    [&lt;00000000f4cb3815&gt;] __do_sys_connect net/socket.c:1892 [inline]&#xA;    [&lt;00000000f4cb3815&gt;] __se_sys_connect net/socket.c:1889 [inline]&#xA;    [&lt;00000000f4cb3815&gt;] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889&#xA;    [&lt;00000000e7b1e839&gt;] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46&#xA;    [&lt;0000000055e91434&gt;] entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;&#xA;Clean up the allocated memory in case of dccp_feat_push_confirm() failure&#xA;and bail out with an error reset code.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2024-56644:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/ipv6: release expired exception dst cached in socket&#xA;&#xA;Dst objects get leaked in ip6_negative_advice() when this function is&#xA;executed for an expired IPv6 route located in the exception table. There&#xA;are several conditions that must be fulfilled for the leak to occur:&#xA;* an ICMPv6 packet indicating a change of the MTU for the path is received,&#xA;  resulting in an exception dst being created&#xA;* a TCP connection that uses the exception dst for routing packets must&#xA;  start timing out so that TCP begins retransmissions&#xA;* after the exception dst expires, the FIB6 garbage collector must not run&#xA;  before TCP executes ip6_negative_advice() for the expired exception dst&#xA;&#xA;When TCP executes ip6_negative_advice() for an exception dst that has&#xA;expired and if no other socket holds a reference to the exception dst, the&#xA;refcount of the exception dst is 2, which corresponds to the increment&#xA;made by dst_init() and the increment made by the TCP socket for which the&#xA;connection is timing out. The refcount made by the socket is never&#xA;released. The refcount of the dst is decremented in sk_dst_reset() but&#xA;that decrement is counteracted by a dst_hold() intentionally placed just&#xA;before the sk_dst_reset() in ip6_negative_advice(). After&#xA;ip6_negative_advice() has finished, there is no other object tied to the&#xA;dst. The socket lost its reference stored in sk_dst_cache and the dst is&#xA;no longer in the exception table. The exception dst becomes a leaked&#xA;object.&#xA;&#xA;As a result of this dst leak, an unbalanced refcount is reported for the&#xA;loopback device of a net namespace being destroyed under kernels that do&#xA;not contain e5f80fcf869a (&#34;ipv6: give an IPv6 dev to blackhole_netdev&#34;):&#xA;unregister_netdevice: waiting for lo to become free. Usage count = 2&#xA;&#xA;Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The&#xA;patch that introduced the dst_hold() in ip6_negative_advice() was&#xA;92f1655aa2b22 (&#34;net: fix __dst_negative_advice() race&#34;). But 92f1655aa2b22&#xA;merely refactored the code with regards to the dst refcount so the issue&#xA;was present even before 92f1655aa2b22. The bug was introduced in&#xA;54c1a859efd9f (&#34;ipv6: Don&#39;t drop cache route entry unless timer actually&#xA;expired.&#34;) where the expired cached route is deleted and the sk_dst_cache&#xA;member of the socket is set to NULL by calling dst_negative_advice() but&#xA;the refcount belonging to the socket is left unbalanced.&#xA;&#xA;The IPv4 version - ipv4_negative_advice() - is not affected by this bug.&#xA;When the TCP connection times out ipv4_negative_advice() merely resets the&#xA;sk_dst_cache of the socket while decrementing the refcount of the&#xA;exception dst.&#xA;CVE-2024-56645:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: j1939: j1939_session_new(): fix skb reference counting&#xA;&#xA;Since j1939_session_skb_queue() does an extra skb_get() for each new&#xA;skb, do the same for the initial one in j1939_session_new() to avoid&#xA;refcount underflow.&#xA;&#xA;[mkl: clean up commit message]&#xA;CVE-2024-56659:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: lapb: increase LAPB_HEADER_LEN&#xA;&#xA;It is unclear if net/lapb code is supposed to be ready for 8021q.&#xA;&#xA;We can at least avoid crashes like the following :&#xA;&#xA;skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2&#xA;------------[ cut here ]------------&#xA; kernel BUG at net/core/skbuff.c:206 !&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024&#xA; RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]&#xA; RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216&#xA;Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 &lt;0f&gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3&#xA;RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282&#xA;RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600&#xA;RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000&#xA;RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60&#xA;R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140&#xA;R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016&#xA;FS:  00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  skb_push+0xe5/0x100 net/core/skbuff.c:2636&#xA;  nr_header+0x36/0x320 net/netrom/nr_dev.c:69&#xA;  dev_hard_header include/linux/netdevice.h:3148 [inline]&#xA;  vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83&#xA;  dev_hard_header include/linux/netdevice.h:3148 [inline]&#xA;  lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257&#xA;  lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447&#xA;  lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149&#xA; lapb_establish_data_link+0x84/0xd0&#xA; lapb_device_event+0x4e0/0x670&#xA;  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93&#xA; __dev_notify_flags+0x207/0x400&#xA;  dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922&#xA;  devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188&#xA;  inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003&#xA;  sock_do_ioctl+0x158/0x460 net/socket.c:1227&#xA;  sock_ioctl+0x626/0x8e0 net/socket.c:1346&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;  __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893&#xA;  do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA;CVE-2024-56670:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer&#xA;&#xA;Considering that in some extreme cases,&#xA;when u_serial driver is accessed by multiple threads,&#xA;Thread A is executing the open operation and calling the gs_open,&#xA;Thread B is executing the disconnect operation and calling the&#xA;gserial_disconnect function,The port-&gt;port_usb pointer will be set to NULL.&#xA;&#xA;E.g.&#xA;    Thread A                                 Thread B&#xA;    gs_open()                                gadget_unbind_driver()&#xA;    gs_start_io()                            composite_disconnect()&#xA;    gs_start_rx()                            gserial_disconnect()&#xA;    ...                                      ...&#xA;    spin_unlock(&amp;port-&gt;port_lock)&#xA;    status = usb_ep_queue()                  spin_lock(&amp;port-&gt;port_lock)&#xA;    spin_lock(&amp;port-&gt;port_lock)              port-&gt;port_usb = NULL&#xA;    gs_free_requests(port-&gt;port_usb-&gt;in)     spin_unlock(&amp;port-&gt;port_lock)&#xA;    Crash&#xA;&#xA;This causes thread A to access a null pointer (port-&gt;port_usb is null)&#xA;when calling the gs_free_requests function, causing a crash.&#xA;&#xA;If port_usb is NULL, the release request will be skipped as it&#xA;will be done by gserial_disconnect.&#xA;&#xA;So add a null pointer check to gs_start_io before attempting&#xA;to access the value of the pointer port-&gt;port_usb.&#xA;&#xA;Call trace:&#xA; gs_start_io+0x164/0x25c&#xA; gs_open+0x108/0x13c&#xA; tty_open+0x314/0x638&#xA; chrdev_open+0x1b8/0x258&#xA; do_dentry_open+0x2c4/0x700&#xA; vfs_open+0x2c/0x3c&#xA; path_openat+0xa64/0xc60&#xA; do_filp_open+0xb8/0x164&#xA; do_sys_openat2+0x84/0xf0&#xA; __arm64_sys_openat+0x70/0x9c&#xA; invoke_syscall+0x58/0x114&#xA; el0_svc_common+0x80/0xe0&#xA; do_el0_svc+0x1c/0x28&#xA; el0_svc+0x38/0x68&#xA;CVE-2024-56694:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: fix recursive lock when verdict program return SK_PASS&#xA;&#xA;When the stream_verdict program returns SK_PASS, it places the received skb&#xA;into its own receive queue, but a recursive lock eventually occurs, leading&#xA;to an operating system deadlock. This issue has been present since v6.9.&#xA;&#xA;&#39;&#39;&#39;&#xA;sk_psock_strp_data_ready&#xA;    write_lock_bh(&amp;sk-&gt;sk_callback_lock)&#xA;    strp_data_ready&#xA;      strp_read_sock&#xA;        read_sock -&gt; tcp_read_sock&#xA;          strp_recv&#xA;            cb.rcv_msg -&gt; sk_psock_strp_read&#xA;              # now stream_verdict return SK_PASS without peer sock assign&#xA;              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)&#xA;              sk_psock_verdict_apply&#xA;                sk_psock_skb_ingress_self&#xA;                  sk_psock_skb_ingress_enqueue&#xA;                    sk_psock_data_ready&#xA;                      read_lock_bh(&amp;sk-&gt;sk_callback_lock) &lt;= dead lock&#xA;&#xA;&#39;&#39;&#39;&#xA;&#xA;This topic has been discussed before, but it has not been fixed.&#xA;Previous discussion:&#xA;https://lore.kernel.org/all/[email protected]&#xA;CVE-2024-56698:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: dwc3: gadget: Fix looping of queued SG entries&#xA;&#xA;The dwc3_request-&gt;num_queued_sgs is decremented on completion. If a&#xA;partially completed request is handled, then the&#xA;dwc3_request-&gt;num_queued_sgs no longer reflects the total number of&#xA;num_queued_sgs (it would be cleared).&#xA;&#xA;Correctly check the number of request SG entries remained to be prepare&#xA;and queued. Failure to do this may cause null pointer dereference when&#xA;accessing non-existent SG entry.&#xA;CVE-2024-56720:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, sockmap: Several fixes to bpf_msg_pop_data&#xA;&#xA;Several fixes to bpf_msg_pop_data,&#xA;1. In sk_msg_shift_left, we should put_page&#xA;2. if (len == 0), return early is better&#xA;3. pop the entire sk_msg (last == msg-&gt;sg.size) should be supported&#xA;4. Fix for the value of variable &#34;a&#34;&#xA;5. In sk_msg_shift_left, after shifting, i has already pointed to the next&#xA;element. Addtional sk_msg_iter_var_next may result in BUG.&#xA;CVE-2024-56724:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device&#xA;&#xA;While design wise the idea of converting the driver to use&#xA;the hierarchy of the IRQ chips is correct, the implementation&#xA;has (inherited) flaws. This was unveiled when platform_get_irq()&#xA;had started WARN() on IRQ 0 that is supposed to be a Linux&#xA;IRQ number (also known as vIRQ).&#xA;&#xA;Rework the driver to respect IRQ domain when creating each MFD&#xA;device separately, as the domain is not the same for all of them.&#xA;CVE-2024-56767:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset&#xA;&#xA;The at_xdmac_memset_create_desc may return NULL, which will lead to a&#xA;null pointer dereference. For example, the len input is error, or the&#xA;atchan-&gt;free_descs_list is empty and memory is exhausted. Therefore, add&#xA;check to avoid this.&#xA;CVE-2024-56769:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg&#xA;&#xA;Syzbot reports [1] an uninitialized value issue found by KMSAN in&#xA;dib3000_read_reg().&#xA;&#xA;Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case&#xA;that call fails, the buffer may end up with some undefined values.&#xA;&#xA;Since no elaborate error handling is expected in dib3000_write_reg(),&#xA;simply zero out rb buffer to mitigate the problem.&#xA;&#xA;[1] Syzkaller report&#xA;dvb-usb: bulk message failed: -22 (6/0)&#xA;=====================================================&#xA;BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758&#xA; dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758&#xA; dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31&#xA; dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290&#xA; dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]&#xA; dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]&#xA; dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310&#xA; dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110&#xA;...&#xA;Local variable rb created at:&#xA; dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54&#xA; dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758&#xA;...&#xA;CVE-2024-56770:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: netem: account for backlog updates from child qdisc&#xA;&#xA;In general, &#39;qlen&#39; of any classful qdisc should keep track of the&#xA;number of packets that the qdisc itself and all of its children holds.&#xA;In case of netem, &#39;qlen&#39; only accounts for the packets in its internal&#xA;tfifo. When netem is used with a child qdisc, the child qdisc can use&#xA;&#39;qdisc_tree_reduce_backlog&#39; to inform its parent, netem, about created&#xA;or dropped SKBs. This function updates &#39;qlen&#39; and the backlog statistics&#xA;of netem, but netem does not account for changes made by a child qdisc.&#xA;&#39;qlen&#39; then indicates the wrong number of packets in the tfifo.&#xA;If a child qdisc creates new SKBs during enqueue and informs its parent&#xA;about this, netem&#39;s &#39;qlen&#39; value is increased. When netem dequeues the&#xA;newly created SKBs from the child, the &#39;qlen&#39; in netem is not updated.&#xA;If &#39;qlen&#39; reaches the configured sch-&gt;limit, the enqueue function stops&#xA;working, even though the tfifo is not full.&#xA;&#xA;Reproduce the bug:&#xA;Ensure that the sender machine has GSO enabled. Configure netem as root&#xA;qdisc and tbf as its child on the outgoing interface of the machine&#xA;as follows:&#xA;$ tc qdisc add dev &lt;oif&gt; root handle 1: netem delay 100ms limit 100&#xA;$ tc qdisc add dev &lt;oif&gt; parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms&#xA;&#xA;Send bulk TCP traffic out via this interface, e.g., by running an iPerf3&#xA;client on the machine. Check the qdisc statistics:&#xA;$ tc -s qdisc show dev &lt;oif&gt;&#xA;&#xA;Statistics after 10s of iPerf3 TCP test before the fix (note that&#xA;netem&#39;s backlog &gt; limit, netem stopped accepting packets):&#xA;qdisc netem 1: root refcnt 2 limit 1000 delay 100ms&#xA; Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)&#xA; backlog 4294528236b 1155p requeues 0&#xA;qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms&#xA; Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)&#xA; backlog 0b 0p requeues 0&#xA;&#xA;Statistics after the fix:&#xA;qdisc netem 1: root refcnt 2 limit 1000 delay 100ms&#xA; Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)&#xA; backlog 0b 0p requeues 0&#xA;qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms&#xA; Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)&#xA; backlog 0b 0p requeues 0&#xA;&#xA;tbf segments the GSO SKBs (tbf_segment) and updates the netem&#39;s &#39;qlen&#39;.&#xA;The interface fully stops transferring packets and &#34;locks&#34;. In this case,&#xA;the child qdisc and tfifo are empty, but &#39;qlen&#39; indicates the tfifo is at&#xA;its limit and no more packets are accepted.&#xA;&#xA;This patch adds a counter for the entries in the tfifo. Netem&#39;s &#39;qlen&#39; is&#xA;only decreased when a packet is returned by its dequeue function, and not&#xA;during enqueuing into the child qdisc. External updates to &#39;qlen&#39; are thus&#xA;accounted for and only the behavior of the backlog statistics changes. As&#xA;in other qdiscs, &#39;qlen&#39; then keeps track of  how many packets are held in&#xA;netem and all of its children. As before, sch-&gt;limit remains as the&#xA;maximum number of packets in the tfifo. The same applies to netem&#39;s&#xA;backlog statistics.&#xA;CVE-2024-56785:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a&#xA;&#xA;Fix the dtc warnings:&#xA;&#xA;    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: &#39;#interrupt-cells&#39; found, but node is not an interrupt provider&#xA;    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: &#39;#interrupt-cells&#39; found, but node is not an interrupt provider&#xA;    arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite &#39;interrupt_provider&#39;&#xA;&#xA;And a runtime warning introduced in commit 045b14ca5c36 (&#34;of: WARN on&#xA;deprecated #address-cells/#size-cells handling&#34;):&#xA;&#xA;    WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0&#xA;    Missing &#39;#address-cells&#39; in /bus@10000000/pci@1a000000/pci_bridge@9,0&#xA;&#xA;The fix is similar to commit d89a415ff8d5 (&#34;MIPS: Loongson64: DTS: Fix PCIe&#xA;port nodes for ls7a&#34;), which has fixed the issue for ls2k (despite its&#xA;subject mentions ls7a).&#xA;CVE-2024-57802:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netrom: check buffer length before accessing it&#xA;&#xA;Syzkaller reports an uninit value read from ax25cmp when sending raw message&#xA;through ieee802154 implementation.&#xA;&#xA;=====================================================&#xA;BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119&#xA; ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119&#xA; nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601&#xA; nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774&#xA; nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144&#xA; __netdev_start_xmit include/linux/netdevice.h:4940 [inline]&#xA; netdev_start_xmit include/linux/netdevice.h:4954 [inline]&#xA; xmit_one net/core/dev.c:3548 [inline]&#xA; dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564&#xA; __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349&#xA; dev_queue_xmit include/linux/netdevice.h:3134 [inline]&#xA; raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299&#xA; ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA; __sys_sendmsg net/socket.c:2667 [inline]&#xA; __do_sys_sendmsg net/socket.c:2676 [inline]&#xA; __se_sys_sendmsg net/socket.c:2674 [inline]&#xA; __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;&#xA;Uninit was created at:&#xA; slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768&#xA; slab_alloc_node mm/slub.c:3478 [inline]&#xA; kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523&#xA; kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560&#xA; __alloc_skb+0x318/0x740 net/core/skbuff.c:651&#xA; alloc_skb include/linux/skbuff.h:1286 [inline]&#xA; alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334&#xA; sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780&#xA; sock_alloc_send_skb include/net/sock.h:1884 [inline]&#xA; raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282&#xA; ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96&#xA; sock_sendmsg_nosec net/socket.c:730 [inline]&#xA; __sock_sendmsg net/socket.c:745 [inline]&#xA; ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638&#xA; __sys_sendmsg net/socket.c:2667 [inline]&#xA; __do_sys_sendmsg net/socket.c:2676 [inline]&#xA; __se_sys_sendmsg net/socket.c:2674 [inline]&#xA; __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x63/0x6b&#xA;&#xA;CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023&#xA;=====================================================&#xA;&#xA;This issue occurs because the skb buffer is too small, and it&#39;s actual&#xA;allocation is aligned. This hides an actual issue, which is that nr_route_frame&#xA;does not validate the buffer size before using it.&#xA;&#xA;Fix this issue by checking skb-&gt;len before accessing any fields in skb-&gt;data.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2024-57807:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: megaraid_sas: Fix for a potential deadlock&#xA;&#xA;This fixes a &#39;possible circular locking dependency detected&#39; warning&#xA;      CPU0                    CPU1&#xA;      ----                    ----&#xA; lock(&amp;instance-&gt;reset_mutex);&#xA;                              lock(&amp;shost-&gt;scan_mutex);&#xA;                              lock(&amp;instance-&gt;reset_mutex);&#xA; lock(&amp;shost-&gt;scan_mutex);&#xA;&#xA;Fix this by temporarily releasing the reset_mutex.&#xA;CVE-2024-57834:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread&#xA;&#xA;syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]&#xA;&#xA;If dvb-&gt;mux is not initialized successfully by vidtv_mux_init() in the&#xA;vidtv_start_streaming(), it will trigger null pointer dereference about mux&#xA;in vidtv_mux_stop_thread().&#xA;&#xA;Adjust the timing of streaming initialization and check it before&#xA;stopping it.&#xA;&#xA;[1]&#xA;KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]&#xA;CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471&#xA;Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8&#xA;RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202&#xA;RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125&#xA;RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128&#xA;RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188&#xA;R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710&#xA;FS:  00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]&#xA; vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252&#xA; dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000&#xA; dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486&#xA; dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559&#xA; dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]&#xA; dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246&#xA; __fput+0x3f8/0xb60 fs/file_table.c:450&#xA; task_work_run+0x14e/0x250 kernel/task_work.c:239&#xA; get_signal+0x1d3/0x2610 kernel/signal.c:2790&#xA; arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337&#xA; exit_to_user_mode_loop kernel/entry/common.c:111 [inline]&#xA; exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]&#xA; __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]&#xA; syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218&#xA; do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-57874:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL&#xA;&#xA;Currently tagged_addr_ctrl_set() doesn&#39;t initialize the temporary &#39;ctrl&#39;&#xA;variable, and a SETREGSET call with a length of zero will leave this&#xA;uninitialized. Consequently tagged_addr_ctrl_set() will consume an&#xA;arbitrary value, potentially leaking up to 64 bits of memory from the&#xA;kernel stack. The read is limited to a specific slot on the stack, and&#xA;the issue does not provide a write mechanism.&#xA;&#xA;As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and&#xA;rejects other values, a partial SETREGSET attempt will randomly succeed&#xA;or fail depending on the value of the uninitialized value, and the&#xA;exposure is significantly limited.&#xA;&#xA;Fix this by initializing the temporary value before copying the regset&#xA;from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,&#xA;NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing&#xA;value of the tagged address ctrl will be retained.&#xA;&#xA;The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the&#xA;user_aarch64_view used by a native AArch64 task to manipulate another&#xA;native AArch64 task. As get_tagged_addr_ctrl() only returns an error&#xA;value when called for a compat task, tagged_addr_ctrl_get() and&#xA;tagged_addr_ctrl_set() should never observe an error value from&#xA;get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that&#xA;such an error would be unexpected, and error handlnig is not missing in&#xA;either case.&#xA;CVE-2024-57884:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()&#xA;&#xA;The task sometimes continues looping in throttle_direct_reclaim() because&#xA;allow_direct_reclaim(pgdat) keeps returning false.  &#xA;&#xA; #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac&#xA; #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c&#xA; #2 [ffff80002cb6f990] schedule at ffff800008abc50c&#xA; #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550&#xA; #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68&#xA; #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660&#xA; #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98&#xA; #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8&#xA; #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974&#xA; #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4&#xA;&#xA;At this point, the pgdat contains the following two zones:&#xA;&#xA;        NODE: 4  ZONE: 0  ADDR: ffff00817fffe540  NAME: &#34;DMA32&#34;&#xA;          SIZE: 20480  MIN/LOW/HIGH: 11/28/45&#xA;          VM_STAT:&#xA;                NR_FREE_PAGES: 359&#xA;        NR_ZONE_INACTIVE_ANON: 18813&#xA;          NR_ZONE_ACTIVE_ANON: 0&#xA;        NR_ZONE_INACTIVE_FILE: 50&#xA;          NR_ZONE_ACTIVE_FILE: 0&#xA;          NR_ZONE_UNEVICTABLE: 0&#xA;        NR_ZONE_WRITE_PENDING: 0&#xA;                     NR_MLOCK: 0&#xA;                    NR_BOUNCE: 0&#xA;                   NR_ZSPAGES: 0&#xA;            NR_FREE_CMA_PAGES: 0&#xA;&#xA;        NODE: 4  ZONE: 1  ADDR: ffff00817fffec00  NAME: &#34;Normal&#34;&#xA;          SIZE: 8454144  PRESENT: 98304  MIN/LOW/HIGH: 68/166/264&#xA;          VM_STAT:&#xA;                NR_FREE_PAGES: 146&#xA;        NR_ZONE_INACTIVE_ANON: 94668&#xA;          NR_ZONE_ACTIVE_ANON: 3&#xA;        NR_ZONE_INACTIVE_FILE: 735&#xA;          NR_ZONE_ACTIVE_FILE: 78&#xA;          NR_ZONE_UNEVICTABLE: 0&#xA;        NR_ZONE_WRITE_PENDING: 0&#xA;                     NR_MLOCK: 0&#xA;                    NR_BOUNCE: 0&#xA;                   NR_ZSPAGES: 0&#xA;            NR_FREE_CMA_PAGES: 0&#xA;&#xA;In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of&#xA;inactive/active file-backed pages calculated in zone_reclaimable_pages()&#xA;based on the result of zone_page_state_snapshot() is zero.  &#xA;&#xA;Additionally, since this system lacks swap, the calculation of inactive/&#xA;active anonymous pages is skipped.&#xA;&#xA;        crash&gt; p nr_swap_pages&#xA;        nr_swap_pages = $1937 = {&#xA;          counter = 0&#xA;        }&#xA;&#xA;As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to&#xA;the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having&#xA;free pages significantly exceeding the high watermark.&#xA;&#xA;The problem is that the pgdat-&gt;kswapd_failures hasn&#39;t been incremented.&#xA;&#xA;        crash&gt; px ((struct pglist_data *) 0xffff00817fffe540)-&gt;kswapd_failures&#xA;        $1935 = 0x0&#xA;&#xA;This is because the node deemed balanced.  The node balancing logic in&#xA;balance_pgdat() evaluates all zones collectively.  If one or more zones&#xA;(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the&#xA;entire node is deemed balanced.  This causes balance_pgdat() to exit early&#xA;before incrementing the kswapd_failures, as it considers the overall&#xA;memory state acceptable, even though some zones (like ZONE_NORMAL) remain&#xA;under significant pressure.&#xA;&#xA;&#xA;The patch ensures that zone_reclaimable_pages() includes free pages&#xA;(NR_FREE_PAGES) in its calculation when no other reclaimable pages are&#xA;available (e.g., file-backed or anonymous pages).  This change prevents&#xA;zones like ZONE_DMA32, which have sufficient free pages, from being&#xA;mistakenly deemed unreclaimable.  By doing so, the patch ensures proper&#xA;node balancing, avoids masking pressure on other zones like ZONE_NORMAL,&#xA;and prevents infinite loops in throttle_direct_reclaim() caused by&#xA;allow_direct_reclaim(pgdat) repeatedly returning false.&#xA;&#xA;&#xA;The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused&#xA;by a node being incorrectly deemed balanced despite pressure in certain&#xA;zones, such as ZONE_NORMAL.  This issue arises from&#xA;zone_reclaimable_pages&#xA;---truncated---&#xA;CVE-2024-57889:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking&#xA;&#xA;If a device uses MCP23xxx IO expander to receive IRQs, the following&#xA;bug can happen:&#xA;&#xA;  BUG: sleeping function called from invalid context&#xA;    at kernel/locking/mutex.c:283&#xA;  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...&#xA;  preempt_count: 1, expected: 0&#xA;  ...&#xA;  Call Trace:&#xA;  ...&#xA;  __might_resched+0x104/0x10e&#xA;  __might_sleep+0x3e/0x62&#xA;  mutex_lock+0x20/0x4c&#xA;  regmap_lock_mutex+0x10/0x18&#xA;  regmap_update_bits_base+0x2c/0x66&#xA;  mcp23s08_irq_set_type+0x1ae/0x1d6&#xA;  __irq_set_trigger+0x56/0x172&#xA;  __setup_irq+0x1e6/0x646&#xA;  request_threaded_irq+0xb6/0x160&#xA;  ...&#xA;&#xA;We observed the problem while experimenting with a touchscreen driver which&#xA;used MCP23017 IO expander (I2C).&#xA;&#xA;The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from&#xA;concurrent accesses, which is the default for regmaps without .fast_io,&#xA;.disable_locking, etc.&#xA;&#xA;mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter&#xA;locks the mutex.&#xA;&#xA;However, __setup_irq() locks desc-&gt;lock spinlock before calling these&#xA;functions. As a result, the system tries to lock the mutex whole holding&#xA;the spinlock.&#xA;&#xA;It seems, the internal regmap locks are not needed in this driver at all.&#xA;mcp-&gt;lock seems to protect the regmap from concurrent accesses already,&#xA;except, probably, in mcp_pinconf_get/set.&#xA;&#xA;mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under&#xA;chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes&#xA;mcp-&gt;lock and enables regmap caching, so that the potentially slow I2C&#xA;accesses are deferred until chip_bus_unlock().&#xA;&#xA;The accesses to the regmap from mcp23s08_probe_one() do not need additional&#xA;locking.&#xA;&#xA;In all remaining places where the regmap is accessed, except&#xA;mcp_pinconf_get/set(), the driver already takes mcp-&gt;lock.&#xA;&#xA;This patch adds locking in mcp_pinconf_get/set() and disables internal&#xA;locking in the regmap config. Among other things, it fixes the sleeping&#xA;in atomic context described above.&#xA;CVE-2024-57922:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Add check for granularity in dml ceil/floor helpers&#xA;&#xA;[Why]&#xA;Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()&#xA;should check for granularity is non zero to avoid assert and&#xA;divide-by-zero error in dcn_bw_ functions.&#xA;&#xA;[How]&#xA;Add check for granularity 0.&#xA;&#xA;(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)&#xA;CVE-2024-57938:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sctp: Prevent autoclose integer overflow in sctp_association_init()&#xA;&#xA;While by default max_autoclose equals to INT_MAX / HZ, one may set&#xA;net.sctp.max_autoclose to UINT_MAX. There is code in&#xA;sctp_association_init() that can consequently trigger overflow.&#xA;CVE-2024-57940:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;exfat: fix the infinite loop in exfat_readdir()&#xA;&#xA;If the file system is corrupted so that a cluster is linked to&#xA;itself in the cluster chain, and there is an unused directory&#xA;entry in the cluster, &#39;dentry&#39; will not be incremented, causing&#xA;condition &#39;dentry &lt; max_dentries&#39; unable to prevent an infinite&#xA;loop.&#xA;&#xA;This infinite loop causes s_lock not to be released, and other&#xA;tasks will hang, such as exfat_sync_fs().&#xA;&#xA;This commit stops traversing the cluster chain when there is unused&#xA;directory entry in the cluster to avoid this infinite loop.&#xA;CVE-2024-57946:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;virtio-blk: don&#39;t keep queue frozen during system suspend&#xA;&#xA;Commit 4ce6e2db00de (&#34;virtio-blk: Ensure no requests in virtqueues before&#xA;deleting vqs.&#34;) replaces queue quiesce with queue freeze in virtio-blk&#39;s&#xA;PM callbacks. And the motivation is to drain inflight IOs before suspending.&#xA;&#xA;block layer&#39;s queue freeze looks very handy, but it is also easy to cause&#xA;deadlock, such as, any attempt to call into bio_queue_enter() may run into&#xA;deadlock if the queue is frozen in current context. There are all kinds&#xA;of -&gt;suspend() called in suspend context, so keeping queue frozen in the&#xA;whole suspend context isn&#39;t one good idea. And Marek reported lockdep&#xA;warning[1] caused by virtio-blk&#39;s freeze queue in virtblk_freeze().&#xA;&#xA;[1] https://lore.kernel.org/linux-block/[email protected]/&#xA;&#xA;Given the motivation is to drain in-flight IOs, it can be done by calling&#xA;freeze &amp; unfreeze, meantime restore to previous behavior by keeping queue&#xA;quiesced during suspend.&#xA;CVE-2024-57948:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mac802154: check local interfaces before deleting sdata list&#xA;&#xA;syzkaller reported a corrupted list in ieee802154_if_remove. [1]&#xA;&#xA;Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4&#xA;hardware device from the system.&#xA;&#xA;CPU0&#x9;&#x9;&#x9;&#x9;&#x9;CPU1&#xA;====&#x9;&#x9;&#x9;&#x9;&#x9;====&#xA;genl_family_rcv_msg_doit&#x9;&#x9;ieee802154_unregister_hw&#xA;ieee802154_del_iface&#x9;&#x9;&#x9;ieee802154_remove_interfaces&#xA;rdev_del_virtual_intf_deprecated&#x9;list_del(&amp;sdata-&gt;list)&#xA;ieee802154_if_remove&#xA;list_del_rcu&#xA;&#xA;The net device has been unregistered, since the rcu grace period,&#xA;unregistration must be run before ieee802154_if_remove.&#xA;&#xA;To avoid this issue, add a check for local-&gt;interfaces before deleting&#xA;sdata list.&#xA;&#xA;[1]&#xA;kernel BUG at lib/list_debug.c:58!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI&#xA;CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56&#xA;Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 &lt;0f&gt; 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7&#xA;RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246&#xA;RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00&#xA;RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000&#xA;RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d&#xA;R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000&#xA;R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0&#xA;FS:  0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __list_del_entry_valid include/linux/list.h:124 [inline]&#xA; __list_del_entry include/linux/list.h:215 [inline]&#xA; list_del_rcu include/linux/rculist.h:157 [inline]&#xA; ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687&#xA; rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline]&#xA; ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323&#xA; genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]&#xA; genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]&#xA; genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210&#xA; netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551&#xA; genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]&#xA; netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357&#xA; netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901&#xA; sock_sendmsg_nosec net/socket.c:729 [inline]&#xA; __sock_sendmsg+0x221/0x270 net/socket.c:744&#xA; ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2607&#xA; ___sys_sendmsg net/socket.c:2661 [inline]&#xA; __sys_sendmsg+0x292/0x380 net/socket.c:2690&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2024-57973:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rdma/cxgb4: Prevent potential integer overflow on 32bit&#xA;&#xA;The &#34;gl-&gt;tot_len&#34; variable is controlled by the user.  It comes from&#xA;process_responses().  On 32bit systems, the &#34;gl-&gt;tot_len + sizeof(struct&#xA;cpl_pass_accept_req) + sizeof(struct rss_header)&#34; addition could have an&#xA;integer wrapping bug.  Use size_add() to prevent this.&#xA;CVE-2024-57981:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: xhci: Fix NULL pointer dereference on certain command aborts&#xA;&#xA;If a command is queued to the final usable TRB of a ring segment, the&#xA;enqueue pointer is advanced to the subsequent link TRB and no further.&#xA;If the command is later aborted, when the abort completion is handled&#xA;the dequeue pointer is advanced to the first TRB of the next segment.&#xA;&#xA;If no further commands are queued, xhci_handle_stopped_cmd_ring() sees&#xA;the ring pointers unequal and assumes that there is a pending command,&#xA;so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.&#xA;&#xA;Don&#39;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell&#xA;ring likely is unnecessary too, but it&#39;s harmless. Leave it alone.&#xA;&#xA;This is probably Bug 219532, but no confirmation has been received.&#xA;&#xA;The issue has been independently reproduced and confirmed fixed using&#xA;a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.&#xA;Everything continued working normally after several prevented crashes.&#xA;CVE-2024-57986:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections&#xA;&#xA;A report in 2019 by the syzbot fuzzer was found to be connected to two&#xA;errors in the HID core associated with Resolution Multipliers.  One of&#xA;the errors was fixed by commit ea427a222d8b (&#34;HID: core: Fix deadloop&#xA;in hid_apply_multiplier.&#34;), but the other has not been fixed.&#xA;&#xA;This error arises because hid_apply_multipler() assumes that every&#xA;Resolution Multiplier control is contained in a Logical Collection,&#xA;i.e., there&#39;s no way the routine can ever set multiplier_collection to&#xA;NULL.  This is in spite of the fact that the function starts with a&#xA;big comment saying:&#xA;&#xA;&#x9; * &#34;The Resolution Multiplier control must be contained in the same&#xA;&#x9; * Logical Collection as the control(s) to which it is to be applied.&#xA;&#x9;   ...&#xA;&#x9; *  If no Logical Collection is&#xA;&#x9; * defined, the Resolution Multiplier is associated with all&#xA;&#x9; * controls in the report.&#34;&#xA;&#x9; * HID Usage Table, v1.12, Section 4.3.1, p30&#xA;&#x9; *&#xA;&#x9; * Thus, search from the current collection upwards until we find a&#xA;&#x9; * logical collection...&#xA;&#xA;The comment and the code overlook the possibility that none of the&#xA;collections found may be a Logical Collection.&#xA;&#xA;The fix is to set the multiplier_collection pointer to NULL if the&#xA;collection found isn&#39;t a Logical Collection.&#xA;CVE-2024-58005:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tpm: Change to kvalloc() in eventlog/acpi.c&#xA;&#xA;The following failure was reported on HPE ProLiant D320:&#xA;&#xA;[   10.693310][    T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)&#xA;[   10.848132][    T1] ------------[ cut here ]------------&#xA;[   10.853559][    T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330&#xA;[   10.862827][    T1] Modules linked in:&#xA;[   10.866671][    T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375&#xA;[   10.882741][    T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024&#xA;[   10.892170][    T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330&#xA;[   10.898103][    T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 &lt;0f&gt; 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1&#xA;[   10.917750][    T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246&#xA;[   10.923777][    T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000&#xA;[   10.931727][    T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0&#xA;&#xA;The above transcript shows that ACPI pointed a 16 MiB buffer for the log&#xA;events because RSI maps to the &#39;order&#39; parameter of __alloc_pages_noprof().&#xA;Address the bug by moving from devm_kmalloc() to devm_add_action() and&#xA;kvmalloc() and devm_add_action().&#xA;CVE-2024-58010:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;binfmt_flat: Fix integer overflow bug on 32 bit systems&#xA;&#xA;Most of these sizes and counts are capped at 256MB so the math doesn&#39;t&#xA;result in an integer overflow.  The &#34;relocs&#34; count needs to be checked&#xA;as well.  Otherwise on 32bit systems the calculation of &#34;full_data&#34;&#xA;could be wrong.&#xA;&#xA;&#x9;full_data = data_len + relocs * sizeof(unsigned long);&#xA;CVE-2024-58014:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()&#xA;&#xA;In &#39;wlc_phy_iqcal_gainparams_nphy()&#39;, add gain range check to WARN()&#xA;instead of possible out-of-bounds &#39;tbl_iqcal_gainparams_nphy&#39; access.&#xA;Compile tested only.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2024-58016:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;safesetid: check size of policy writes&#xA;&#xA;syzbot attempts to write a buffer with a large size to a sysfs entry&#xA;with writes handled by handle_policy_update(), triggering a warning&#xA;in kmalloc.&#xA;&#xA;Check the size specified for write buffers before allocating.&#xA;&#xA;[PM: subject tweak]&#xA;CVE-2024-58017:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX&#xA;&#xA;Shifting 1 &lt;&lt; 31 on a 32-bit int causes signed integer overflow, which&#xA;leads to undefined behavior. To prevent this, cast 1 to u32 before&#xA;performing the shift, ensuring well-defined behavior.&#xA;&#xA;This change explicitly avoids any potential overflow by ensuring that&#xA;the shift occurs on an unsigned 32-bit integer.&#xA;CVE-2024-58020:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: multitouch: Add NULL check in mt_input_configured&#xA;&#xA;devm_kasprintf() can return a NULL pointer on failure,but this&#xA;returned value in mt_input_configured() is not checked.&#xA;Add NULL check in mt_input_configured(), to handle kernel NULL&#xA;pointer dereference error.&#xA;CVE-2024-58051:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipmi: ipmb: Add check devm_kasprintf() returned value&#xA;&#xA;devm_kasprintf() can return a NULL pointer on failure but this&#xA;returned value is not checked.&#xA;CVE-2024-58071:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;team: prevent adding a device which is already a team device lower&#xA;&#xA;Prevent adding a device which is already a team device lower,&#xA;e.g. adding veth0 if vlan1 was already added and veth0 is a lower of&#xA;vlan1.&#xA;&#xA;This is not useful in practice and can lead to recursive locking:&#xA;&#xA;$ ip link add veth0 type veth peer name veth1&#xA;$ ip link set veth0 up&#xA;$ ip link set veth1 up&#xA;$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1&#xA;$ ip link add team0 type team&#xA;$ ip link set veth0.1 down&#xA;$ ip link set veth0.1 master team0&#xA;team0: Port device veth0.1 added&#xA;$ ip link set veth0 down&#xA;$ ip link set veth0 master team0&#xA;&#xA;============================================&#xA;WARNING: possible recursive locking detected&#xA;6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted&#xA;--------------------------------------------&#xA;ip/7684 is trying to acquire lock:&#xA;ffff888016848e00 (team-&gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;&#xA;but task is already holding lock:&#xA;ffff888016848e00 (team-&gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)&#xA;&#xA;other info that might help us debug this:&#xA;Possible unsafe locking scenario:&#xA;&#xA;CPU0&#xA;----&#xA;lock(team-&gt;team_lock_key);&#xA;lock(team-&gt;team_lock_key);&#xA;&#xA;*** DEADLOCK ***&#xA;&#xA;May be due to missing lock nesting notation&#xA;&#xA;2 locks held by ip/7684:&#xA;&#xA;stack backtrace:&#xA;CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;Call Trace:&#xA;&lt;TASK&gt;&#xA;dump_stack_lvl (lib/dump_stack.c:122)&#xA;print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)&#xA;__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)&#xA;? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)&#xA;lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)&#xA;? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))&#xA;? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;? lock_acquire (kernel/locking/lockdep.c:5822)&#xA;? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)&#xA;? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;? fib_sync_up (net/ipv4/fib_semantics.c:2167)&#xA;? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)&#xA;notifier_call_chain (kernel/notifier.c:85)&#xA;call_netdevice_notifiers_info (net/core/dev.c:1996)&#xA;__dev_notify_flags (net/core/dev.c:8993)&#xA;? __dev_change_flags (net/core/dev.c:8975)&#xA;dev_change_flags (net/core/dev.c:9027)&#xA;vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)&#xA;? br_device_event (net/bridge/br.c:143)&#xA;notifier_call_chain (kernel/notifier.c:85)&#xA;call_netdevice_notifiers_info (net/core/dev.c:1996)&#xA;dev_open (net/core/dev.c:1519 net/core/dev.c:1505)&#xA;team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)&#xA;? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)&#xA;do_set_master (net/core/rtnetlink.c:2917)&#xA;do_setlink.isra.0 (net/core/rtnetlink.c:3117)&#xA;CVE-2024-58085:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tomoyo: don&#39;t emit warning in tomoyo_write_control()&#xA;&#xA;syzbot is reporting too large allocation warning at tomoyo_write_control(),&#xA;for one can write a very very long line without new line character. To fix&#xA;this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,&#xA;for practically a valid line should be always shorter than 32KB where the&#xA;&#34;too small to fail&#34; memory-allocation rule applies.&#xA;&#xA;One might try to write a valid line that is longer than 32KB, but such&#xA;request will likely fail with -ENOMEM. Therefore, I feel that separately&#xA;returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.&#xA;There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.&#xA;CVE-2024-58090:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sched/core: Prevent rescheduling when interrupts are disabled&#xA;&#xA;David reported a warning observed while loop testing kexec jump:&#xA;&#xA;  Interrupts enabled after irqrouter_resume+0x0/0x50&#xA;  WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220&#xA;   kernel_kexec+0xf6/0x180&#xA;   __do_sys_reboot+0x206/0x250&#xA;   do_syscall_64+0x95/0x180&#xA;&#xA;The corresponding interrupt flag trace:&#xA;&#xA;  hardirqs last  enabled at (15573): [&lt;ffffffffa8281b8e&gt;] __up_console_sem+0x7e/0x90&#xA;  hardirqs last disabled at (15580): [&lt;ffffffffa8281b73&gt;] __up_console_sem+0x63/0x90&#xA;&#xA;That means __up_console_sem() was invoked with interrupts enabled. Further&#xA;instrumentation revealed that in the interrupt disabled section of kexec&#xA;jump one of the syscore_suspend() callbacks woke up a task, which set the&#xA;NEED_RESCHED flag. A later callback in the resume path invoked&#xA;cond_resched() which in turn led to the invocation of the scheduler:&#xA;&#xA;  __cond_resched+0x21/0x60&#xA;  down_timeout+0x18/0x60&#xA;  acpi_os_wait_semaphore+0x4c/0x80&#xA;  acpi_ut_acquire_mutex+0x3d/0x100&#xA;  acpi_ns_get_node+0x27/0x60&#xA;  acpi_ns_evaluate+0x1cb/0x2d0&#xA;  acpi_rs_set_srs_method_data+0x156/0x190&#xA;  acpi_pci_link_set+0x11c/0x290&#xA;  irqrouter_resume+0x54/0x60&#xA;  syscore_resume+0x6a/0x200&#xA;  kernel_kexec+0x145/0x1c0&#xA;  __do_sys_reboot+0xeb/0x240&#xA;  do_syscall_64+0x95/0x180&#xA;&#xA;This is a long standing problem, which probably got more visible with&#xA;the recent printk changes. Something does a task wakeup and the&#xA;scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and&#xA;invokes schedule() from a completely bogus context. The scheduler&#xA;enables interrupts after context switching, which causes the above&#xA;warning at the end.&#xA;&#xA;Quite some of the code paths in syscore_suspend()/resume() can result in&#xA;triggering a wakeup with the exactly same consequences. They might not&#xA;have done so yet, but as they share a lot of code with normal operations&#xA;it&#39;s just a question of time.&#xA;&#xA;The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling&#xA;models. Full preemption is not affected as cond_resched() is disabled and&#xA;the preemption check preemptible() takes the interrupt disabled flag into&#xA;account.&#xA;&#xA;Cure the problem by adding a corresponding check into cond_resched().&#xA;CVE-2024-58239:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tls: stop recv() if initial process_rx_list gave us non-DATA&#xA;&#xA;If we have a non-DATA record on the rx_list and another record of the&#xA;same type still on the queue, we will end up merging them:&#xA; - process_rx_list copies the non-DATA record&#xA; - we start the loop and process the first available record since it&#39;s&#xA;   of the same type&#xA; - we break out of the loop since the record was not DATA&#xA;&#xA;Just check the record type and jump to the end in case process_rx_list&#xA;did some work.&#xA;CVE-2025-21638:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: sysctl: auth_enable: avoid using current-&gt;nsproxy&#xA;&#xA;As mentioned in a previous commit of this series, using the &#39;net&#39;&#xA;structure via &#39;current&#39; is not recommended for different reasons:&#xA;&#xA;- Inconsistency: getting info from the reader&#39;s/writer&#39;s netns vs only&#xA;  from the opener&#39;s netns.&#xA;&#xA;- current-&gt;nsproxy can be NULL in some cases, resulting in an &#39;Oops&#39;&#xA;  (null-ptr-deref), e.g. when the current task is exiting, as spotted by&#xA;  syzbot [1] using acct(2).&#xA;&#xA;The &#39;net&#39; structure can be obtained from the table-&gt;data using&#xA;container_of().&#xA;&#xA;Note that table-&gt;data could also be used directly, but that would&#xA;increase the size of this fix, while &#39;sctp.ctl_sock&#39; still needs to be&#xA;retrieved from &#39;net&#39; structure.&#xA;CVE-2025-21639:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: sysctl: rto_min/max: avoid using current-&gt;nsproxy&#xA;&#xA;As mentioned in a previous commit of this series, using the &#39;net&#39;&#xA;structure via &#39;current&#39; is not recommended for different reasons:&#xA;&#xA;- Inconsistency: getting info from the reader&#39;s/writer&#39;s netns vs only&#xA;  from the opener&#39;s netns.&#xA;&#xA;- current-&gt;nsproxy can be NULL in some cases, resulting in an &#39;Oops&#39;&#xA;  (null-ptr-deref), e.g. when the current task is exiting, as spotted by&#xA;  syzbot [1] using acct(2).&#xA;&#xA;The &#39;net&#39; structure can be obtained from the table-&gt;data using&#xA;container_of().&#xA;&#xA;Note that table-&gt;data could also be used directly, as this is the only&#xA;member needed from the &#39;net&#39; structure, but that would increase the size&#xA;of this fix, to use &#39;*data&#39; everywhere &#39;net-&gt;sctp.rto_min/max&#39; is used.&#xA;CVE-2025-21640:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: sysctl: cookie_hmac_alg: avoid using current-&gt;nsproxy&#xA;&#xA;As mentioned in a previous commit of this series, using the &#39;net&#39;&#xA;structure via &#39;current&#39; is not recommended for different reasons:&#xA;&#xA;- Inconsistency: getting info from the reader&#39;s/writer&#39;s netns vs only&#xA;  from the opener&#39;s netns.&#xA;&#xA;- current-&gt;nsproxy can be NULL in some cases, resulting in an &#39;Oops&#39;&#xA;  (null-ptr-deref), e.g. when the current task is exiting, as spotted by&#xA;  syzbot [1] using acct(2).&#xA;&#xA;The &#39;net&#39; structure can be obtained from the table-&gt;data using&#xA;container_of().&#xA;&#xA;Note that table-&gt;data could also be used directly, as this is the only&#xA;member needed from the &#39;net&#39; structure, but that would increase the size&#xA;of this fix, to use &#39;*data&#39; everywhere &#39;net-&gt;sctp.sctp_hmac_alg&#39; is&#xA;used.&#xA;CVE-2025-21646:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;afs: Fix the maximum cell name length&#xA;&#xA;The kafs filesystem limits the maximum length of a cell to 256 bytes, but a&#xA;problem occurs if someone actually does that: kafs tries to create a&#xA;directory under /proc/net/afs/ with the name of the cell, but that fails&#xA;with a warning:&#xA;&#xA;        WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405&#xA;&#xA;because procfs limits the maximum filename length to 255.&#xA;&#xA;However, the DNS limits the maximum lookup length and, by extension, the&#xA;maximum cell name, to 255 less two (length count and trailing NUL).&#xA;&#xA;Fix this by limiting the maximum acceptable cellname length to 253.  This&#xA;also allows us to be sure we can create the &#34;/afs/.&lt;cell&gt;/&#34; mountpoint too.&#xA;&#xA;Further, split the YFS VL record cell name maximum to be the 256 allowed by&#xA;the protocol and ignore the record retrieved by YFSVL.GetCellName if it&#xA;exceeds 253.&#xA;CVE-2025-21653:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute&#xA;&#xA;syzbot found that TCA_FLOW_RSHIFT attribute was not validated.&#xA;Right shitfing a 32bit integer is undefined for large shift values.&#xA;&#xA;UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23&#xA;shift exponent 9445 is too large for 32-bit type &#39;u32&#39; (aka &#39;unsigned int&#39;)&#xA;CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;Workqueue: ipv6_addrconf addrconf_dad_work&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:94 [inline]&#xA;  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA;  ubsan_epilogue lib/ubsan.c:231 [inline]&#xA;  __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468&#xA;  flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329&#xA;  tc_classify include/net/tc_wrapper.h:197 [inline]&#xA;  __tcf_classify net/sched/cls_api.c:1771 [inline]&#xA;  tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867&#xA;  sfb_classify net/sched/sch_sfb.c:260 [inline]&#xA;  sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318&#xA;  dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793&#xA;  __dev_xmit_skb net/core/dev.c:3889 [inline]&#xA;  __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400&#xA;  dev_queue_xmit include/linux/netdevice.h:3168 [inline]&#xA;  neigh_hh_output include/net/neighbour.h:523 [inline]&#xA;  neigh_output include/net/neighbour.h:537 [inline]&#xA;  ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236&#xA;  iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82&#xA;  udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173&#xA;  geneve_xmit_skb drivers/net/geneve.c:916 [inline]&#xA;  geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039&#xA;  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:5011 [inline]&#xA;  xmit_one net/core/dev.c:3590 [inline]&#xA;  dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606&#xA;  __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434&#xA;CVE-2025-21664:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm thin: make get_first_thin use rcu-safe list first function&#xA;&#xA;The documentation in rculist.h explains the absence of list_empty_rcu()&#xA;and cautions programmers against relying on a list_empty() -&gt;&#xA;list_first() sequence in RCU safe code.  This is because each of these&#xA;functions performs its own READ_ONCE() of the list head.  This can lead&#xA;to a situation where the list_empty() sees a valid list entry, but the&#xA;subsequent list_first() sees a different view of list head state after a&#xA;modification.&#xA;&#xA;In the case of dm-thin, this author had a production box crash from a GP&#xA;fault in the process_deferred_bios path.  This function saw a valid list&#xA;head in get_first_thin() but when it subsequently dereferenced that and&#xA;turned it into a thin_c, it got the inside of the struct pool, since the&#xA;list was now empty and referring to itself.  The kernel on which this&#xA;occurred printed both a warning about a refcount_t being saturated, and&#xA;a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,&#xA;prior to the fault itself.  When the resulting kdump was examined, it&#xA;was possible to see another thread patiently waiting in thin_dtr&#39;s&#xA;synchronize_rcu.&#xA;&#xA;The thin_dtr call managed to pull the thin_c out of the active thins&#xA;list (and have it be the last entry in the active_thins list) at just&#xA;the wrong moment which lead to this crash.&#xA;&#xA;Fortunately, the fix here is straight forward.  Switch get_first_thin()&#xA;function to use list_first_or_null_rcu() which performs just a single&#xA;READ_ONCE() and returns NULL if the list is already empty.&#xA;&#xA;This was run against the devicemapper test suite&#39;s thin-provisioning&#xA;suites for delete and suspend and no regressions were observed.&#xA;CVE-2025-21681:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;openvswitch: fix lockup on tx to unregistering netdev with carrier&#xA;&#xA;Commit in a fixes tag attempted to fix the issue in the following&#xA;sequence of calls:&#xA;&#xA;    do_output&#xA;    -&gt; ovs_vport_send&#xA;       -&gt; dev_queue_xmit&#xA;          -&gt; __dev_queue_xmit&#xA;             -&gt; netdev_core_pick_tx&#xA;                -&gt; skb_tx_hash&#xA;&#xA;When device is unregistering, the &#39;dev-&gt;real_num_tx_queues&#39; goes to&#xA;zero and the &#39;while (unlikely(hash &gt;= qcount))&#39; loop inside the&#xA;&#39;skb_tx_hash&#39; becomes infinite, locking up the core forever.&#xA;&#xA;But unfortunately, checking just the carrier status is not enough to&#xA;fix the issue, because some devices may still be in unregistering&#xA;state while reporting carrier status OK.&#xA;&#xA;One example of such device is a net/dummy.  It sets carrier ON&#xA;on start, but it doesn&#39;t implement .ndo_stop to set the carrier off.&#xA;And it makes sense, because dummy doesn&#39;t really have a carrier.&#xA;Therefore, while this device is unregistering, it&#39;s still easy to hit&#xA;the infinite loop in the skb_tx_hash() from the OVS datapath.  There&#xA;might be other drivers that do the same, but dummy by itself is&#xA;important for the OVS ecosystem, because it is frequently used as a&#xA;packet sink for tcpdump while debugging OVS deployments.  And when the&#xA;issue is hit, the only way to recover is to reboot.&#xA;&#xA;Fix that by also checking if the device is running.  The running&#xA;state is handled by the net core during unregistering, so it covers&#xA;unregistering case better, and we don&#39;t really need to send packets&#xA;to devices that are not running anyway.&#xA;&#xA;While only checking the running state might be enough, the carrier&#xA;check is preserved.  The running and the carrier states seem disjoined&#xA;throughout the code and different drivers.  And other core functions&#xA;like __dev_direct_xmit() check both before attempting to transmit&#xA;a packet.  So, it seems safer to check both flags in OVS as well.&#xA;CVE-2025-21683:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Fix bpf_sk_select_reuseport() memory leak&#xA;&#xA;As pointed out in the original comment, lookup in sockmap can return a TCP&#xA;ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF&#xA;set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb&#xA;does not imply a non-refcounted socket.&#xA;&#xA;Drop sk&#39;s reference in both error paths.&#xA;&#xA;unreferenced object 0xffff888101911800 (size 2048):&#xA;  comm &#34;test_progs&#34;, pid 44109, jiffies 4297131437&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;  backtrace (crc 9336483b):&#xA;    __kmalloc_noprof+0x3bf/0x560&#xA;    __reuseport_alloc+0x1d/0x40&#xA;    reuseport_alloc+0xca/0x150&#xA;    reuseport_attach_prog+0x87/0x140&#xA;    sk_reuseport_attach_bpf+0xc8/0x100&#xA;    sk_setsockopt+0x1181/0x1990&#xA;    do_sock_setsockopt+0x12b/0x160&#xA;    __sys_setsockopt+0x7b/0xc0&#xA;    __x64_sys_setsockopt+0x1b/0x30&#xA;    do_syscall_64+0x93/0x180&#xA;    entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2025-21689:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()&#xA;&#xA;This patch addresses a null-ptr-deref in qt2_process_read_urb() due to&#xA;an incorrect bounds check in the following:&#xA;&#xA;       if (newport &gt; serial-&gt;num_ports) {&#xA;               dev_err(&amp;port-&gt;dev,&#xA;                       &#34;%s - port change to invalid port: %i\n&#34;,&#xA;                       __func__, newport);&#xA;               break;&#xA;       }&#xA;&#xA;The condition doesn&#39;t account for the valid range of the serial-&gt;port&#xA;buffer, which is from 0 to serial-&gt;num_ports - 1. When newport is equal&#xA;to serial-&gt;num_ports, the assignment of &#34;port&#34; in the&#xA;following code is out-of-bounds and NULL:&#xA;&#xA;       serial_priv-&gt;current_port = newport;&#xA;       port = serial-&gt;port[serial_priv-&gt;current_port];&#xA;&#xA;The fix checks if newport is greater than or equal to serial-&gt;num_ports&#xA;indicating it is out-of-bounds.&#xA;CVE-2025-21699:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag&#xA;&#xA;Truncate an inode&#39;s address space when flipping the GFS2_DIF_JDATA flag:&#xA;depending on that flag, the pages in the address space will either use&#xA;buffer heads or iomap_folio_state structs, and we cannot mix the two.&#xA;CVE-2025-21708:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: rtl8150: enable basic endpoint checking&#xA;&#xA;Syzkaller reports [1] encountering a common issue of utilizing a wrong&#xA;usb endpoint type during URB submitting stage. This, in turn, triggers&#xA;a warning shown below.&#xA;&#xA;For now, enable simple endpoint checking (specifically, bulk and&#xA;interrupt eps, testing control one is not essential) to mitigate&#xA;the issue with a view to do other related cosmetic changes later,&#xA;if they are necessary.&#xA;&#xA;[1] Syzkaller report:&#xA;usb 1-1: BOGUS urb xfer, pipe 3 != type 1&#xA;WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv&gt;&#xA;Modules linked in:&#xA;CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617&gt;&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024&#xA;RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503&#xA;Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8&gt;&#xA;RSP: 0018:ffffc9000441f740 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9&#xA;RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001&#xA;RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001&#xA;R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c&#xA;FS:  00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733&#xA; __dev_open+0x2d4/0x4e0 net/core/dev.c:1474&#xA; __dev_change_flags+0x561/0x720 net/core/dev.c:8838&#xA; dev_change_flags+0x8f/0x160 net/core/dev.c:8910&#xA; devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177&#xA; inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003&#xA; sock_do_ioctl+0x116/0x280 net/socket.c:1222&#xA; sock_ioctl+0x22e/0x6c0 net/socket.c:1341&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:893 [inline]&#xA; __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7fc04ef73d49&#xA;...&#xA;&#xA;This change has not been tested on real hardware.&#xA;CVE-2025-21711:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/rose: prevent integer overflows in rose_setsockopt()&#xA;&#xA;In case of possible unpredictably large arguments passed to&#xA;rose_setsockopt() and multiplied by extra values on top of that,&#xA;integer overflows may occur.&#xA;&#xA;Do the safest minimum and fix these issues by checking the&#xA;contents of &#39;opt&#39; and returning -EINVAL if they are too large. Also,&#xA;switch to unsigned int and remove useless check for negative &#39;opt&#39;&#xA;in ROSE_IDLE case.&#xA;CVE-2025-21734:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;misc: fastrpc: Fix copy buffer page size&#xA;&#xA;For non-registered buffer, fastrpc driver copies the buffer and&#xA;pass it to the remote subsystem. There is a problem with current&#xA;implementation of page size calculation which is not considering&#xA;the offset in the calculation. This might lead to passing of&#xA;improper and out-of-bounds page size which could result in&#xA;memory issue. Calculate page start and page end using the offset&#xA;adjusted address instead of absolute address.&#xA;CVE-2025-21736:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nilfs2: fix possible int overflows in nilfs_fiemap()&#xA;&#xA;Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result&#xA;by being prepared to go through potentially maxblocks == INT_MAX blocks,&#xA;the value in n may experience an overflow caused by left shift of blkbits.&#xA;&#xA;While it is extremely unlikely to occur, play it safe and cast right hand&#xA;expression to wider type to mitigate the issue.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with static analysis&#xA;tool SVACE.&#xA;CVE-2025-21744:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()&#xA;&#xA;On removal of the device or unloading of the kernel module a potential NULL&#xA;pointer dereference occurs.&#xA;&#xA;The following sequence deletes the interface:&#xA;&#xA;  brcmf_detach()&#xA;    brcmf_remove_interface()&#xA;      brcmf_del_if()&#xA;&#xA;Inside the brcmf_del_if() function the drvr-&gt;if2bss[ifidx] is updated to&#xA;BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.&#xA;&#xA;After brcmf_remove_interface() call the brcmf_proto_detach() function is&#xA;called providing the following sequence:&#xA;&#xA;  brcmf_detach()&#xA;    brcmf_proto_detach()&#xA;      brcmf_proto_msgbuf_detach()&#xA;        brcmf_flowring_detach()&#xA;          brcmf_msgbuf_delete_flowring()&#xA;            brcmf_msgbuf_remove_flowring()&#xA;              brcmf_flowring_delete()&#xA;                brcmf_get_ifp()&#xA;                brcmf_txfinalize()&#xA;&#xA;Since brcmf_get_ip() can and actually will return NULL in this case the&#xA;call to brcmf_txfinalize() will result in a NULL pointer dereference inside&#xA;brcmf_txfinalize() when trying to update ifp-&gt;ndev-&gt;stats.tx_errors.&#xA;&#xA;This will only happen if a flowring still has an skb.&#xA;&#xA;Although the NULL pointer dereference has only been seen when trying to&#xA;update the tx statistic, all other uses of the ifp pointer have been&#xA;guarded as well with an early return if ifp is NULL.&#xA;CVE-2025-21745:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;blk-cgroup: Fix class @block_class&#39;s subsystem refcount leakage&#xA;&#xA;blkcg_fill_root_iostats() iterates over @block_class&#39;s devices by&#xA;class_dev_iter_(init|next)(), but does not end iterating with&#xA;class_dev_iter_exit(), so causes the class&#39;s subsystem refcount leakage.&#xA;&#xA;Fix by ending the iterating with class_dev_iter_exit().&#xA;CVE-2025-21749:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: rose: lock the socket in rose_bind()&#xA;&#xA;syzbot reported a soft lockup in rose_loopback_timer(),&#xA;with a repro calling bind() from multiple threads.&#xA;&#xA;rose_bind() must lock the socket to avoid this issue.&#xA;CVE-2025-21753:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: fix use-after-free when attempting to join an aborted transaction&#xA;&#xA;When we are trying to join the current transaction and if it&#39;s aborted,&#xA;we read its &#39;aborted&#39; field after unlocking fs_info-&gt;trans_lock and&#xA;without holding any extra reference count on it. This means that a&#xA;concurrent task that is aborting the transaction may free the transaction&#xA;before we read its &#39;aborted&#39; field, leading to a use-after-free.&#xA;&#xA;Fix this by reading the &#39;aborted&#39; field while holding fs_info-&gt;trans_lock&#xA;since any freeing task must first acquire that lock and set&#xA;fs_info-&gt;running_transaction to NULL before freeing the transaction.&#xA;&#xA;This was reported by syzbot and Dmitry with the following stack traces&#xA;from KASAN:&#xA;&#xA;   ==================================================================&#xA;   BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278&#xA;   Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128&#xA;&#xA;   CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0&#xA;   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;   Workqueue: events_unbound btrfs_async_reclaim_data_space&#xA;   Call Trace:&#xA;    &lt;TASK&gt;&#xA;    __dump_stack lib/dump_stack.c:94 [inline]&#xA;    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA;    print_address_description mm/kasan/report.c:378 [inline]&#xA;    print_report+0x169/0x550 mm/kasan/report.c:489&#xA;    kasan_report+0x143/0x180 mm/kasan/report.c:602&#xA;    join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278&#xA;    start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697&#xA;    flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803&#xA;    btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321&#xA;    process_one_work kernel/workqueue.c:3236 [inline]&#xA;    process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317&#xA;    worker_thread+0x870/0xd30 kernel/workqueue.c:3398&#xA;    kthread+0x2f0/0x390 kernel/kthread.c:389&#xA;    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147&#xA;    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA;    &lt;/TASK&gt;&#xA;&#xA;   Allocated by task 5315:&#xA;    kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;    poison_kmalloc_redzone mm/kasan/common.c:377 [inline]&#xA;    __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394&#xA;    kasan_kmalloc include/linux/kasan.h:260 [inline]&#xA;    __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329&#xA;    kmalloc_noprof include/linux/slab.h:901 [inline]&#xA;    join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308&#xA;    start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697&#xA;    btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572&#xA;    lookup_open fs/namei.c:3649 [inline]&#xA;    open_last_lookups fs/namei.c:3748 [inline]&#xA;    path_openat+0x1c03/0x3590 fs/namei.c:3984&#xA;    do_filp_open+0x27f/0x4e0 fs/namei.c:4014&#xA;    do_sys_openat2+0x13e/0x1d0 fs/open.c:1402&#xA;    do_sys_open fs/open.c:1417 [inline]&#xA;    __do_sys_creat fs/open.c:1495 [inline]&#xA;    __se_sys_creat fs/open.c:1489 [inline]&#xA;    __x64_sys_creat+0x123/0x170 fs/open.c:1489&#xA;    do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA;    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA;    entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;   Freed by task 5336:&#xA;    kasan_save_stack mm/kasan/common.c:47 [inline]&#xA;    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68&#xA;    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582&#xA;    poison_slab_object mm/kasan/common.c:247 [inline]&#xA;    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264&#xA;    kasan_slab_free include/linux/kasan.h:233 [inline]&#xA;    slab_free_hook mm/slub.c:2353 [inline]&#xA;    slab_free mm/slub.c:4613 [inline]&#xA;    kfree+0x196/0x430 mm/slub.c:4761&#xA;    cleanup_transaction fs/btrfs/transaction.c:2063 [inline]&#xA;    btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598&#xA;    insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757&#xA;    btrfs_balance+0x992/&#xA;---truncated---&#xA;CVE-2025-21765:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: use RCU protection in ip6_default_advmss()&#xA;&#xA;ip6_default_advmss() needs rcu protection to make&#xA;sure the net structure it reads does not disappear.&#xA;CVE-2025-21776:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;USB: hub: Ignore non-compliant devices with too many configs or interfaces&#xA;&#xA;Robert Morris created a test program which can cause&#xA;usb_hub_to_struct_hub() to dereference a NULL or inappropriate&#xA;pointer:&#xA;&#xA;Oops: general protection fault, probably for non-canonical address&#xA;0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI&#xA;CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14&#xA;Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021&#xA;Workqueue: usb_hub_wq hub_event&#xA;RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? die_addr+0x31/0x80&#xA; ? exc_general_protection+0x1b4/0x3c0&#xA; ? asm_exc_general_protection+0x26/0x30&#xA; ? usb_hub_adjust_deviceremovable+0x78/0x110&#xA; hub_probe+0x7c7/0xab0&#xA; usb_probe_interface+0x14b/0x350&#xA; really_probe+0xd0/0x2d0&#xA; ? __pfx___device_attach_driver+0x10/0x10&#xA; __driver_probe_device+0x6e/0x110&#xA; driver_probe_device+0x1a/0x90&#xA; __device_attach_driver+0x7e/0xc0&#xA; bus_for_each_drv+0x7f/0xd0&#xA; __device_attach+0xaa/0x1a0&#xA; bus_probe_device+0x8b/0xa0&#xA; device_add+0x62e/0x810&#xA; usb_set_configuration+0x65d/0x990&#xA; usb_generic_driver_probe+0x4b/0x70&#xA; usb_probe_device+0x36/0xd0&#xA;&#xA;The cause of this error is that the device has two interfaces, and the&#xA;hub driver binds to interface 1 instead of interface 0, which is where&#xA;usb_hub_to_struct_hub() looks.&#xA;&#xA;We can prevent the problem from occurring by refusing to accept hub&#xA;devices that violate the USB spec by having more than one&#xA;configuration or interface.&#xA;CVE-2025-21796:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: clear acl_access/acl_default after releasing them&#xA;&#xA;If getting acl_default fails, acl_access and acl_default will be released&#xA;simultaneously. However, acl_access will still retain a pointer pointing&#xA;to the released posix_acl, which will trigger a WARNING in&#xA;nfs3svc_release_getacl like this:&#xA;&#xA;------------[ cut here ]------------&#xA;refcount_t: underflow; use-after-free.&#xA;WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28&#xA;refcount_warn_saturate+0xb5/0x170&#xA;Modules linked in:&#xA;CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted&#xA;6.12.0-rc6-00079-g04ae226af01f-dirty #8&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS&#xA;1.16.1-2.fc37 04/01/2014&#xA;RIP: 0010:refcount_warn_saturate+0xb5/0x170&#xA;Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75&#xA;e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff &lt;0f&gt; 0b eb&#xA;cd 0f b6 1d 8a3&#xA;RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282&#xA;RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde&#xA;RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380&#xA;RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56&#xA;R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001&#xA;R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0&#xA;FS:  0000000000000000(0000) GS:ffff88871ed00000(0000)&#xA;knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? refcount_warn_saturate+0xb5/0x170&#xA; ? __warn+0xa5/0x140&#xA; ? refcount_warn_saturate+0xb5/0x170&#xA; ? report_bug+0x1b1/0x1e0&#xA; ? handle_bug+0x53/0xa0&#xA; ? exc_invalid_op+0x17/0x40&#xA; ? asm_exc_invalid_op+0x1a/0x20&#xA; ? tick_nohz_tick_stopped+0x1e/0x40&#xA; ? refcount_warn_saturate+0xb5/0x170&#xA; ? refcount_warn_saturate+0xb5/0x170&#xA; nfs3svc_release_getacl+0xc9/0xe0&#xA; svc_process_common+0x5db/0xb60&#xA; ? __pfx_svc_process_common+0x10/0x10&#xA; ? __rcu_read_unlock+0x69/0xa0&#xA; ? __pfx_nfsd_dispatch+0x10/0x10&#xA; ? svc_xprt_received+0xa1/0x120&#xA; ? xdr_init_decode+0x11d/0x190&#xA; svc_process+0x2a7/0x330&#xA; svc_handle_xprt+0x69d/0x940&#xA; svc_recv+0x180/0x2d0&#xA; nfsd+0x168/0x200&#xA; ? __pfx_nfsd+0x10/0x10&#xA; kthread+0x1a2/0x1e0&#xA; ? kthread+0xf4/0x1e0&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork+0x34/0x60&#xA; ? __pfx_kthread+0x10/0x10&#xA; ret_from_fork_asm+0x1a/0x30&#xA; &lt;/TASK&gt;&#xA;Kernel panic - not syncing: kernel: panic_on_warn set ...&#xA;&#xA;Clear acl_access/acl_default after posix_acl_release is called to prevent&#xA;UAF from being triggered.&#xA;CVE-2025-21799:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()&#xA;&#xA;When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns&#xA;negative error value on error. So not NULL check is not sufficient&#xA;to deteremine if IRQ is valid. Check that IRQ is greater then zero&#xA;to ensure it is valid.&#xA;&#xA;There is no issue at probe time but at runtime user can invoke&#xA;.set_channels which results in the following call chain.&#xA;am65_cpsw_set_channels()&#xA; am65_cpsw_nuss_update_tx_rx_chns()&#xA;  am65_cpsw_nuss_remove_tx_chns()&#xA;  am65_cpsw_nuss_init_tx_chns()&#xA;&#xA;At this point if am65_cpsw_nuss_init_tx_chns() fails due to&#xA;k3_udma_glue_tx_get_irq() then tx_chn-&gt;irq will be set to a&#xA;negative value.&#xA;&#xA;Then, at subsequent .set_channels with higher channel count we&#xA;will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()&#xA;leading to a kernel warning.&#xA;&#xA;The issue is present in the original commit that introduced this driver,&#xA;although there, am65_cpsw_nuss_update_tx_rx_chns() existed as&#xA;am65_cpsw_nuss_update_tx_chns().&#xA;CVE-2025-21806:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: let net.core.dev_weight always be non-zero&#xA;&#xA;The following problem was encountered during stability test:&#xA;&#xA;(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \&#xA;&#x9;returned 1, exceeding its budget of 0.&#xA;------------[ cut here ]------------&#xA;list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \&#xA;&#x9;next=ffff88905f746e40.&#xA;WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \&#xA;&#x9;__list_add_valid_or_report+0xf3/0x130&#xA;CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+&#xA;RIP: 0010:__list_add_valid_or_report+0xf3/0x130&#xA;Call Trace:&#xA;? __warn+0xcd/0x250&#xA;? __list_add_valid_or_report+0xf3/0x130&#xA;enqueue_to_backlog+0x923/0x1070&#xA;netif_rx_internal+0x92/0x2b0&#xA;__netif_rx+0x15/0x170&#xA;loopback_xmit+0x2ef/0x450&#xA;dev_hard_start_xmit+0x103/0x490&#xA;__dev_queue_xmit+0xeac/0x1950&#xA;ip_finish_output2+0x6cc/0x1620&#xA;ip_output+0x161/0x270&#xA;ip_push_pending_frames+0x155/0x1a0&#xA;raw_sendmsg+0xe13/0x1550&#xA;__sys_sendto+0x3bf/0x4e0&#xA;__x64_sys_sendto+0xdc/0x1b0&#xA;do_syscall_64+0x5b/0x170&#xA;entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;The reproduction command is as follows:&#xA;  sysctl -w net.core.dev_weight=0&#xA;  ping 127.0.0.1&#xA;&#xA;This is because when the napi&#39;s weight is set to 0, process_backlog() may&#xA;return 0 and clear the NAPI_STATE_SCHED bit of napi-&gt;state, causing this&#xA;napi to be re-polled in net_rx_action() until __do_softirq() times out.&#xA;Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can&#xA;be retriggered in enqueue_to_backlog(), causing this issue.&#xA;&#xA;Making the napi&#39;s weight always non-zero solves this problem.&#xA;&#xA;Triggering this issue requires system-wide admin (setting is&#xA;not namespaced).&#xA;CVE-2025-21814:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ptp: Ensure info-&gt;enable callback is always set&#xA;&#xA;The ioctl and sysfs handlers unconditionally call the -&gt;enable callback.&#xA;Not all drivers implement that callback, leading to NULL dereferences.&#xA;Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.&#xA;&#xA;Instead use a dummy callback if no better was specified by the driver.&#xA;CVE-2025-21826:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: reject mismatching sum of field_len with set key length&#xA;&#xA;The field length description provides the length of each separated key&#xA;field in the concatenation, each field gets rounded up to 32-bits to&#xA;calculate the pipapo rule width from pipapo_init(). The set key length&#xA;provides the total size of the key aligned to 32-bits.&#xA;&#xA;Register-based arithmetics still allows for combining mismatching set&#xA;key length and field length description, eg. set key length 10 and field&#xA;description [ 5, 4 ] leading to pipapo width of 12.&#xA;CVE-2025-21835:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: gadget: f_midi: fix MIDI Streaming descriptor lengths&#xA;&#xA;While the MIDI jacks are configured correctly, and the MIDIStreaming&#xA;endpoint descriptors are filled with the correct information,&#xA;bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.&#xA;&#xA;This does not matter when the numbers of in and out ports are equal, but&#xA;when they differ the host will receive broken descriptors with&#xA;uninitialized stack memory leaking into the descriptor for whichever&#xA;value is smaller.&#xA;&#xA;The precise meaning of &#34;in&#34; and &#34;out&#34; in the port counts is not clearly&#xA;defined and can be confusing.  But elsewhere the driver consistently&#xA;uses this to match the USB meaning of IN and OUT viewed from the host,&#xA;so that &#34;in&#34; ports send data to the host and &#34;out&#34; ports receive data&#xA;from it.&#xA;CVE-2025-21844:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: Add check for next_buffer in receive_encrypted_standard()&#xA;&#xA;Add check for the return value of cifs_buf_get() and cifs_small_buf_get()&#xA;in receive_encrypted_standard() to prevent null pointer dereference.&#xA;CVE-2025-21846:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;acct: perform last write from workqueue&#xA;&#xA;In [1] it was reported that the acct(2) system call can be used to&#xA;trigger NULL deref in cases where it is set to write to a file that&#xA;triggers an internal lookup. This can e.g., happen when pointing acc(2)&#xA;to /sys/power/resume. At the point the where the write to this file&#xA;happens the calling task has already exited and called exit_fs(). A&#xA;lookup will thus trigger a NULL-deref when accessing current-&gt;fs.&#xA;&#xA;Reorganize the code so that the the final write happens from the&#xA;workqueue but with the caller&#39;s credentials. This preserves the&#xA;(strange) permission model and has almost no regression risk.&#xA;&#xA;This api should stop to exist though.&#xA;CVE-2025-21848:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()&#xA;&#xA;Add check for the return value of nfp_app_ctrl_msg_alloc() in&#xA;nfp_bpf_cmsg_alloc() to prevent null pointer dereference.&#xA;CVE-2025-21853:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: avoid holding freeze_mutex during mmap operation&#xA;&#xA;We use map-&gt;freeze_mutex to prevent races between map_freeze() and&#xA;memory mapping BPF map contents with writable permissions. The way we&#xA;naively do this means we&#39;ll hold freeze_mutex for entire duration of all&#xA;the mm and VMA manipulations, which is completely unnecessary. This can&#xA;potentially also lead to deadlocks, as reported by syzbot in [0].&#xA;&#xA;So, instead, hold freeze_mutex only during writeability checks, bump&#xA;(proactively) &#34;write active&#34; count for the map, unlock the mutex and&#xA;proceed with mmap logic. And only if something went wrong during mmap&#xA;logic, then undo that &#34;write active&#34; counter increment.&#xA;&#xA;  [0] https://lore.kernel.org/bpf/[email protected]/&#xA;CVE-2025-21859:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;USB: gadget: f_midi: f_midi_complete to call queue_work&#xA;&#xA;When using USB MIDI, a lock is attempted to be acquired twice through a&#xA;re-entrant call to f_midi_transmit, causing a deadlock.&#xA;&#xA;Fix it by using queue_work() to schedule the inner f_midi_transmit() via&#xA;a high priority work queue from the completion handler.&#xA;CVE-2025-21862:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drop_monitor: fix incorrect initialization order&#xA;&#xA;Syzkaller reports the following bug:&#xA;&#xA;BUG: spinlock bad magic on CPU#1, syz-executor.0/7995&#xA; lock: 0xffff88805303f3e0, .magic: 00000000, .owner: &lt;none&gt;/-1, .owner_cpu: 0&#xA;CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G            E     5.10.209+ #1&#xA;Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020&#xA;Call Trace:&#xA; __dump_stack lib/dump_stack.c:77 [inline]&#xA; dump_stack+0x119/0x179 lib/dump_stack.c:118&#xA; debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]&#xA; do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112&#xA; __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]&#xA; _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159&#xA; reset_per_cpu_data+0xe6/0x240 [drop_monitor]&#xA; net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor]&#xA; genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739&#xA; genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]&#xA; genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800&#xA; netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497&#xA; genl_rcv+0x29/0x40 net/netlink/genetlink.c:811&#xA; netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]&#xA; netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348&#xA; netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916&#xA; sock_sendmsg_nosec net/socket.c:651 [inline]&#xA; __sock_sendmsg+0x157/0x190 net/socket.c:663&#xA; ____sys_sendmsg+0x712/0x870 net/socket.c:2378&#xA; ___sys_sendmsg+0xf8/0x170 net/socket.c:2432&#xA; __sys_sendmsg+0xea/0x1b0 net/socket.c:2461&#xA; do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46&#xA; entry_SYSCALL_64_after_hwframe+0x62/0xc7&#xA;RIP: 0033:0x7f3f9815aee9&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e&#xA;RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9&#xA;RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007&#xA;RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768&#xA;&#xA;If drop_monitor is built as a kernel module, syzkaller may have time&#xA;to send a netlink NET_DM_CMD_START message during the module loading.&#xA;This will call the net_dm_monitor_start() function that uses&#xA;a spinlock that has not yet been initialized.&#xA;&#xA;To fix this, let&#39;s place resource initialization above the registration&#xA;of a generic netlink family.&#xA;&#xA;Found by InfoTeCS on behalf of Linux Verification Center&#xA;(linuxtesting.org) with Syzkaller.&#xA;CVE-2025-21871:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tee: optee: Fix supplicant wait loop&#xA;&#xA;OP-TEE supplicant is a user-space daemon and it&#39;s possible for it&#xA;be hung or crashed or killed in the middle of processing an OP-TEE&#xA;RPC call. It becomes more complicated when there is incorrect shutdown&#xA;ordering of the supplicant process vs the OP-TEE client application which&#xA;can eventually lead to system hang-up waiting for the closure of the&#xA;client application.&#xA;&#xA;Allow the client process waiting in kernel for supplicant response to&#xA;be killed rather than indefinitely waiting in an unkillable state. Also,&#xA;a normal uninterruptible wait should not have resulted in the hung-task&#xA;watchdog getting triggered, but the endless loop would.&#xA;&#xA;This fixes issues observed during system reboot/shutdown when supplicant&#xA;got hung for some reason or gets crashed/killed which lead to client&#xA;getting hung in an unkillable state. It in turn lead to system being in&#xA;hung up state requiring hard power off/on to recover.&#xA;CVE-2025-21872:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;efi: Don&#39;t map the entire mokvar table to determine its size&#xA;&#xA;Currently, when validating the mokvar table, we (re)map the entire table&#xA;on each iteration of the loop, adding space as we discover new entries.&#xA;If the table grows over a certain size, this fails due to limitations of&#xA;early_memmap(), and we get a failure and traceback:&#xA;&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220&#xA;  ...&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   ? __early_ioremap+0xef/0x220&#xA;   ? __warn.cold+0x93/0xfa&#xA;   ? __early_ioremap+0xef/0x220&#xA;   ? report_bug+0xff/0x140&#xA;   ? early_fixup_exception+0x5d/0xb0&#xA;   ? early_idt_handler_common+0x2f/0x3a&#xA;   ? __early_ioremap+0xef/0x220&#xA;   ? efi_mokvar_table_init+0xce/0x1d0&#xA;   ? setup_arch+0x864/0xc10&#xA;   ? start_kernel+0x6b/0xa10&#xA;   ? x86_64_start_reservations+0x24/0x30&#xA;   ? x86_64_start_kernel+0xed/0xf0&#xA;   ? common_startup_64+0x13e/0x141&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.&#xA;&#xA;Mapping the entire structure isn&#39;t actually necessary, as we don&#39;t ever&#xA;need more than one entry header mapped at once.&#xA;&#xA;Changes efi_mokvar_table_init() to only map each entry header, not the&#xA;entire table, when determining the table size.  Since we&#39;re not mapping&#xA;any data past the variable name, it also changes the code to enforce&#xA;that each variable name is NUL terminated, rather than attempting to&#xA;verify it in place.&#xA;CVE-2025-21878:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i2c: npcm: disable interrupt enable bit before devm_request_irq&#xA;&#xA;The customer reports that there is a soft lockup issue related to&#xA;the i2c driver. After checking, the i2c module was doing a tx transfer&#xA;and the bmc machine reboots in the middle of the i2c transaction, the i2c&#xA;module keeps the status without being reset.&#xA;&#xA;Due to such an i2c module status, the i2c irq handler keeps getting&#xA;triggered since the i2c irq handler is registered in the kernel booting&#xA;process after the bmc machine is doing a warm rebooting.&#xA;The continuous triggering is stopped by the soft lockup watchdog timer.&#xA;&#xA;Disable the interrupt enable bit in the i2c module before calling&#xA;devm_request_irq to fix this issue since the i2c relative status bit&#xA;is read-only.&#xA;&#xA;Here is the soft lockup log.&#xA;[   28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]&#xA;[   28.183351] Modules linked in:&#xA;[   28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1&#xA;[   28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;[   28.208128] pc : __do_softirq+0xb0/0x368&#xA;[   28.212055] lr : __do_softirq+0x70/0x368&#xA;[   28.215972] sp : ffffff8035ebca00&#xA;[   28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780&#xA;[   28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0&#xA;[   28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b&#xA;[   28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff&#xA;[   28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000&#xA;[   28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2&#xA;[   28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250&#xA;[   28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434&#xA;[   28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198&#xA;[   28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40&#xA;[   28.290611] Call trace:&#xA;[   28.293052]  __do_softirq+0xb0/0x368&#xA;[   28.296625]  __irq_exit_rcu+0xe0/0x100&#xA;[   28.300374]  irq_exit+0x14/0x20&#xA;[   28.303513]  handle_domain_irq+0x68/0x90&#xA;[   28.307440]  gic_handle_irq+0x78/0xb0&#xA;[   28.311098]  call_on_irq_stack+0x20/0x38&#xA;[   28.315019]  do_interrupt_handler+0x54/0x5c&#xA;[   28.319199]  el1_interrupt+0x2c/0x4c&#xA;[   28.322777]  el1h_64_irq_handler+0x14/0x20&#xA;[   28.326872]  el1h_64_irq+0x74/0x78&#xA;[   28.330269]  __setup_irq+0x454/0x780&#xA;[   28.333841]  request_threaded_irq+0xd0/0x1b4&#xA;[   28.338107]  devm_request_threaded_irq+0x84/0x100&#xA;[   28.342809]  npcm_i2c_probe_bus+0x188/0x3d0&#xA;[   28.346990]  platform_probe+0x6c/0xc4&#xA;[   28.350653]  really_probe+0xcc/0x45c&#xA;[   28.354227]  __driver_probe_device+0x8c/0x160&#xA;[   28.358578]  driver_probe_device+0x44/0xe0&#xA;[   28.362670]  __driver_attach+0x124/0x1d0&#xA;[   28.366589]  bus_for_each_dev+0x7c/0xe0&#xA;[   28.370426]  driver_attach+0x28/0x30&#xA;[   28.373997]  bus_add_driver+0x124/0x240&#xA;[   28.377830]  driver_register+0x7c/0x124&#xA;[   28.381662]  __platform_driver_register+0x2c/0x34&#xA;[   28.386362]  npcm_i2c_init+0x3c/0x5c&#xA;[   28.389937]  do_one_initcall+0x74/0x230&#xA;[   28.393768]  kernel_init_freeable+0x24c/0x2b4&#xA;[   28.398126]  kernel_init+0x28/0x130&#xA;[   28.401614]  ret_from_fork+0x10/0x20&#xA;[   28.405189] Kernel panic - not syncing: softlockup: hung tasks&#xA;[   28.411011] SMP: stopping secondary CPUs&#xA;[   28.414933] Kernel Offset: disabled&#xA;[   28.418412] CPU features: 0x00000000,00000802&#xA;[   28.427644] Rebooting in 20 seconds..&#xA;CVE-2025-21904:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;caif_virtio: fix wrong pointer check in cfv_probe()&#xA;&#xA;del_vqs() frees virtqueues, therefore cfv-&gt;vq_tx pointer should be checked&#xA;for NULL before calling it, not cfv-&gt;vdev. Also the current implementation&#xA;is redundant because the pointer cfv-&gt;vdev is dereferenced before it is&#xA;checked for NULL.&#xA;&#xA;Fix this by checking cfv-&gt;vq_tx for NULL instead of cfv-&gt;vdev before&#xA;calling del_vqs().&#xA;CVE-2025-21909:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: nl80211: reject cooked mode if it is set along with other flags&#xA;&#xA;It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE&#xA;flags simultaneously on the same monitor interface from the userspace. This&#xA;causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit&#xA;set because the monitor interface is in the cooked state and it takes&#xA;precedence over all other states. When the interface is then being deleted&#xA;the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing&#xA;that bit.&#xA;&#xA;Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with&#xA;other flags.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2025-21910:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: cfg80211: regulatory: improve invalid hints checking&#xA;&#xA;Syzbot keeps reporting an issue [1] that occurs when erroneous symbols&#xA;sent from userspace get through into user_alpha2[] via&#xA;regulatory_hint_user() call. Such invalid regulatory hints should be&#xA;rejected.&#xA;&#xA;While a sanity check from commit 47caf685a685 (&#34;cfg80211: regulatory:&#xA;reject invalid hints&#34;) looks to be enough to deter these very cases,&#xA;there is a way to get around it due to 2 reasons.&#xA;&#xA;1) The way isalpha() works, symbols other than latin lower and&#xA;upper letters may be used to determine a country/domain.&#xA;For instance, greek letters will also be considered upper/lower&#xA;letters and for such characters isalpha() will return true as well.&#xA;However, ISO-3166-1 alpha2 codes should only hold latin&#xA;characters.&#xA;&#xA;2) While processing a user regulatory request, between&#xA;reg_process_hint_user() and regulatory_hint_user() there happens to&#xA;be a call to queue_regulatory_request() which modifies letters in&#xA;request-&gt;alpha2[] with toupper(). This works fine for latin symbols,&#xA;less so for weird letter characters from the second part of _ctype[].&#xA;&#xA;Syzbot triggers a warning in is_user_regdom_saved() by first sending&#xA;over an unexpected non-latin letter that gets malformed by toupper()&#xA;into a character that ends up failing isalpha() check.&#xA;&#xA;Prevent this by enhancing is_an_alpha2() to ensure that incoming&#xA;symbols are latin letters and nothing else.&#xA;&#xA;[1] Syzbot report:&#xA;------------[ cut here ]------------&#xA;Unexpected user alpha2: A�&#xA;WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]&#xA;WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]&#xA;WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516&#xA;Modules linked in:&#xA;CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;Workqueue: events_power_efficient crda_timeout_work&#xA;RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]&#xA;RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]&#xA;RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; crda_timeout_work+0x27/0x50 net/wireless/reg.c:542&#xA; process_one_work kernel/workqueue.c:3229 [inline]&#xA; process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310&#xA; worker_thread+0x870/0xd30 kernel/workqueue.c:3391&#xA; kthread+0x2f2/0x390 kernel/kthread.c:389&#xA; ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147&#xA; ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&#xA; &lt;/TASK&gt;&#xA;CVE-2025-21917:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: renesas_usbhs: Flush the notify_hotplug_work&#xA;&#xA;When performing continuous unbind/bind operations on the USB drivers&#xA;available on the Renesas RZ/G2L SoC, a kernel crash with the message&#xA;&#34;Unable to handle kernel NULL pointer dereference at virtual address&#34;&#xA;may occur. This issue points to the usbhsc_notify_hotplug() function.&#xA;&#xA;Flush the delayed work to avoid its execution when driver resources are&#xA;unavailable.&#xA;CVE-2025-21925:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;llc: do not use skb_get() before dev_queue_xmit()&#xA;&#xA;syzbot is able to crash hosts [1], using llc and devices&#xA;not supporting IFF_TX_SKB_SHARING.&#xA;&#xA;In this case, e1000 driver calls eth_skb_pad(), while&#xA;the skb is shared.&#xA;&#xA;Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c&#xA;&#xA;Note that e1000 driver might have an issue with pktgen,&#xA;because it does not clear IFF_TX_SKB_SHARING, this is an&#xA;orthogonal change.&#xA;&#xA;We need to audit other skb_get() uses in net/llc.&#xA;&#xA;[1]&#xA;&#xA;kernel BUG at net/core/skbuff.c:2178 !&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA; RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __skb_pad+0x18a/0x610 net/core/skbuff.c:2466&#xA;  __skb_put_padto include/linux/skbuff.h:3843 [inline]&#xA;  skb_put_padto include/linux/skbuff.h:3862 [inline]&#xA;  eth_skb_pad include/linux/etherdevice.h:656 [inline]&#xA;  e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128&#xA;  __netdev_start_xmit include/linux/netdevice.h:5151 [inline]&#xA;  netdev_start_xmit include/linux/netdevice.h:5160 [inline]&#xA;  xmit_one net/core/dev.c:3806 [inline]&#xA;  dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822&#xA;  sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343&#xA;  __dev_xmit_skb net/core/dev.c:4045 [inline]&#xA;  __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621&#xA;  dev_queue_xmit include/linux/netdevice.h:3313 [inline]&#xA;  llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144&#xA;  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]&#xA;  llc_sap_next_state net/llc/llc_sap.c:182 [inline]&#xA;  llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209&#xA;  llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993&#xA;  sock_sendmsg_nosec net/socket.c:718 [inline]&#xA;CVE-2025-21948:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: appleir: Fix potential NULL dereference at raw event handle&#xA;&#xA;Syzkaller reports a NULL pointer dereference issue in input_event().&#xA;&#xA;BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]&#xA;BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]&#xA;BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]&#xA;BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395&#xA;Read of size 8 at addr 0000000000000028 by task syz-executor199/2949&#xA;&#xA;CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120&#xA; kasan_report+0xd9/0x110 mm/kasan/report.c:602&#xA; check_region_inline mm/kasan/generic.c:183 [inline]&#xA; kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189&#xA; instrument_atomic_read include/linux/instrumented.h:68 [inline]&#xA; _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]&#xA; is_event_supported drivers/input/input.c:67 [inline]&#xA; input_event+0x42/0xa0 drivers/input/input.c:395&#xA; input_report_key include/linux/input.h:439 [inline]&#xA; key_down drivers/hid/hid-appleir.c:159 [inline]&#xA; appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232&#xA; __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111&#xA; hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484&#xA; __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650&#xA; usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734&#xA; dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993&#xA; __run_hrtimer kernel/time/hrtimer.c:1739 [inline]&#xA; __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803&#xA; hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820&#xA; handle_softirqs+0x206/0x8d0 kernel/softirq.c:561&#xA; __do_softirq kernel/softirq.c:595 [inline]&#xA; invoke_softirq kernel/softirq.c:435 [inline]&#xA; __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662&#xA; irq_exit_rcu+0x9/0x30 kernel/softirq.c:678&#xA; instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]&#xA; sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702&#xA; __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185&#xA; add_timer+0x62/0x90 kernel/time/timer.c:1295&#xA; schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98&#xA; usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645&#xA; usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784&#xA; hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:906 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:892 [inline]&#xA; __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA; &lt;/TASK&gt;&#xA;&#xA;This happens due to the malformed report items sent by the emulated device&#xA;which results in a report, that has no fields, being added to the report list.&#xA;Due to this appleir_input_configured() is never called, hidinput_connect()&#xA;fails which results in the HID_CLAIMED_INPUT flag is not being set. However,&#xA;it  does not make appleir_probe() fail and lets the event callback to be&#xA;called without the associated input device.&#xA;&#xA;Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook&#xA;early if the driver didn&#39;t claim any input_dev for some reason. Moreover,&#xA;some other hid drivers accessing input_dev in their event callbacks do have&#xA;similar checks, too.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2025-21956:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/amd/display: Assign normalized_pix_clk when color depth = 14&#xA;&#xA;[WHY &amp; HOW]&#xA;A warning message &#34;WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397&#xA;calculate_phy_pix_clks+0xef/0x100 [amdgpu]&#34; occurs because the&#xA;display_color_depth == COLOR_DEPTH_141414 is not handled. This is&#xA;observed in Radeon RX 6600 XT.&#xA;&#xA;It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.&#xA;&#xA;Also fixes the indentation in get_norm_pix_clk.&#xA;&#xA;(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)&#xA;CVE-2025-21957:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla1280: Fix kernel oops when debug level &gt; 2&#xA;&#xA;A null dereference or oops exception will eventually occur when qla1280.c&#xA;driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level &gt; 2.  I&#xA;think its clear from the code that the intention here is sg_dma_len(s) not&#xA;length of sg_next(s) when printing the debug info.&#xA;CVE-2025-21959:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()&#xA;&#xA;Since commit b36e4523d4d5 (&#34;netfilter: nf_conncount: fix garbage&#xA;collection confirm race&#34;), `cpu` and `jiffies32` were introduced to&#xA;the struct nf_conncount_tuple.&#xA;&#xA;The commit made nf_conncount_add() initialize `conn-&gt;cpu` and&#xA;`conn-&gt;jiffies32` when allocating the struct.&#xA;In contrast, count_tree() was not changed to initialize them.&#xA;&#xA;By commit 34848d5c896e (&#34;netfilter: nf_conncount: Split insert and&#xA;traversal&#34;), count_tree() was split and the relevant allocation&#xA;code now resides in insert_tree().&#xA;Initialize `conn-&gt;cpu` and `conn-&gt;jiffies32` in insert_tree().&#xA;&#xA;BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]&#xA;BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143&#xA; find_or_evict net/netfilter/nf_conncount.c:117 [inline]&#xA; __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143&#xA; count_tree net/netfilter/nf_conncount.c:438 [inline]&#xA; nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521&#xA; connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72&#xA; __nft_match_eval net/netfilter/nft_compat.c:403 [inline]&#xA; nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433&#xA; expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]&#xA; nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288&#xA; nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23&#xA; nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA; nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626&#xA; nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663&#xA; NF_HOOK_LIST include/linux/netfilter.h:350 [inline]&#xA; ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633&#xA; ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669&#xA; __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline]&#xA; __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983&#xA; __netif_receive_skb_list net/core/dev.c:6035 [inline]&#xA; netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126&#xA; netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178&#xA; xdp_recv_frames net/bpf/test_run.c:280 [inline]&#xA; xdp_test_run_batch net/bpf/test_run.c:361 [inline]&#xA; bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390&#xA; bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316&#xA; bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407&#xA; __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813&#xA; __do_sys_bpf kernel/bpf/syscall.c:5902 [inline]&#xA; __se_sys_bpf kernel/bpf/syscall.c:5900 [inline]&#xA; __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900&#xA; ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358&#xA; do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]&#xA; __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387&#xA; do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412&#xA; do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450&#xA; entry_SYSENTER_compat_after_hwframe+0x84/0x8e&#xA;&#xA;Uninit was created at:&#xA; slab_post_alloc_hook mm/slub.c:4121 [inline]&#xA; slab_alloc_node mm/slub.c:4164 [inline]&#xA; kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171&#xA; insert_tree net/netfilter/nf_conncount.c:372 [inline]&#xA; count_tree net/netfilter/nf_conncount.c:450 [inline]&#xA; nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521&#xA; connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72&#xA; __nft_match_eval net/netfilter/nft_compat.c:403 [inline]&#xA; nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433&#xA; expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]&#xA; nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288&#xA; nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23&#xA; nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA; nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626&#xA; nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663&#xA; NF_HOOK_LIST include/linux/netfilter.h:350 [inline]&#xA; ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633&#xA; ip_list_rcv+0x9ef/0xa40 net/ip&#xA;---truncated---&#xA;CVE-2025-21971:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: Prevent creation of classes with TC_H_ROOT&#xA;&#xA;The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination&#xA;condition when traversing up the qdisc tree to update parent backlog&#xA;counters. However, if a class is created with classid TC_H_ROOT, the&#xA;traversal terminates prematurely at this class instead of reaching the&#xA;actual root qdisc, causing parent statistics to be incorrectly maintained.&#xA;In case of DRR, this could lead to a crash as reported by Mingi Cho.&#xA;&#xA;Prevent the creation of any Qdisc class with classid TC_H_ROOT&#xA;(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.&#xA;CVE-2025-21975:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/mlx5: handle errors in mlx5_chains_create_table()&#xA;&#xA;In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()&#xA;and mlx5_get_flow_namespace() must be checked to prevent NULL pointer&#xA;dereferences. If either function fails, the function should log error&#xA;message with mlx5_core_warn() and return error pointer.&#xA;CVE-2025-21992:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: ignore non-functional sensor in HP 5MP Camera&#xA;&#xA;The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that&#xA;is not actually implemented. Attempting to access this non-functional&#xA;sensor via iio_info causes system hangs as runtime PM tries to wake up&#xA;an unresponsive sensor.&#xA;&#xA;  [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff&#xA;  [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff&#xA;&#xA;Add this device to the HID ignore list since the sensor interface is&#xA;non-functional by design and should not be exposed to userspace.&#xA;CVE-2025-21996:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()&#xA;&#xA;On the off chance that command stream passed from userspace via&#xA;ioctl() call to radeon_vce_cs_parse() is weirdly crafted and&#xA;first command to execute is to encode (case 0x03000001), the function&#xA;in question will attempt to call radeon_vce_cs_reloc() with size&#xA;argument that has not been properly initialized. Specifically, &#39;size&#39;&#xA;will point to &#39;tmp&#39; variable before the latter had a chance to be&#xA;assigned any value.&#xA;&#xA;Play it safe and init &#39;tmp&#39; with 0, thus ensuring that&#xA;radeon_vce_cs_reloc() will catch an early error in cases like these.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with static&#xA;analysis tool SVACE.&#xA;&#xA;(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)&#xA;CVE-2025-22005:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().&#xA;&#xA;fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything&#xA;when it fails.&#xA;&#xA;Commit 7dd73168e273 (&#34;ipv6: Always allocate pcpu memory in a fib6_nh&#34;)&#xA;moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()&#xA;but forgot to add cleanup for fib6_nh-&gt;nh_common.nhc_pcpu_rth_output in&#xA;case it fails to allocate fib6_nh-&gt;rt6i_pcpu, resulting in memleak.&#xA;&#xA;Let&#39;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the&#xA;error path.&#xA;&#xA;Note that we can remove the fib6_nh_release() call in nh_create_ipv6()&#xA;later in net-next.git.&#xA;CVE-2025-22007:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: Fix error code in chan_alloc_skb_cb()&#xA;&#xA;The chan_alloc_skb_cb() function is supposed to return error pointers on&#xA;error.  Returning NULL will lead to a NULL dereference.&#xA;CVE-2025-22008:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;regulator: check that dummy regulator has been probed before using it&#xA;&#xA;Due to asynchronous driver probing there is a chance that the dummy&#xA;regulator hasn&#39;t already been probed when first accessing it.&#xA;CVE-2025-22014:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;soc: qcom: pdr: Fix the potential deadlock&#xA;&#xA;When some client process A call pdr_add_lookup() to add the look up for&#xA;the service and does schedule locator work, later a process B got a new&#xA;server packet indicating locator is up and call pdr_locator_new_server()&#xA;which eventually sets pdr-&gt;locator_init_complete to true which process A&#xA;sees and takes list lock and queries domain list but it will timeout due&#xA;to deadlock as the response will queued to the same qmi-&gt;wq and it is&#xA;ordered workqueue and process B is not able to complete new server&#xA;request work due to deadlock on list lock.&#xA;&#xA;Fix it by removing the unnecessary list iteration as the list iteration&#xA;is already being done inside locator work, so avoid it here and just&#xA;call schedule_work() here.&#xA;&#xA;       Process A                        Process B&#xA;&#xA;                                     process_scheduled_works()&#xA;pdr_add_lookup()                      qmi_data_ready_work()&#xA; process_scheduled_works()             pdr_locator_new_server()&#xA;                                         pdr-&gt;locator_init_complete=true;&#xA;   pdr_locator_work()&#xA;    mutex_lock(&amp;pdr-&gt;list_lock);&#xA;&#xA;     pdr_locate_service()                  mutex_lock(&amp;pdr-&gt;list_lock);&#xA;&#xA;      pdr_get_domain_list()&#xA;       pr_err(&#34;PDR: %s get domain list&#xA;               txn wait failed: %d\n&#34;,&#xA;               req-&gt;service_name,&#xA;               ret);&#xA;&#xA;Timeout error log due to deadlock:&#xA;&#xA;&#34;&#xA; PDR: tms/servreg get domain list txn wait failed: -110&#xA; PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110&#xA;&#34;&#xA;&#xA;Thanks to Bjorn and Johan for letting me know that this commit also fixes&#xA;an audio regression when using the in-kernel pd-mapper as that makes it&#xA;easier to hit this race. [1]&#xA;CVE-2025-22021:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: socket: Lookup orig tuple for IPv6 SNAT&#xA;&#xA;nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to&#xA;restore the original 5-tuple in case of SNAT, to be able to find the&#xA;right socket (if any). Then socket_match() can correctly check whether&#xA;the socket was transparent.&#xA;&#xA;However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this&#xA;conntrack lookup, making xt_socket fail to match on the socket when the&#xA;packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.&#xA;&#xA;IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as&#xA;pods&#39; addresses are in the fd00::/8 ULA subnet and need to be replaced&#xA;with the node&#39;s external address. Cilium leverages Envoy to enforce L7&#xA;policies, and Envoy uses transparent sockets. Cilium inserts an iptables&#xA;prerouting rule that matches on `-m socket --transparent` and redirects&#xA;the packets to localhost, but it fails to match SNATed IPv6 packets due&#xA;to that missing conntrack lookup.&#xA;CVE-2025-22027:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: streamzap: fix race between device disconnection and urb callback&#xA;&#xA;Syzkaller has reported a general protection fault at function&#xA;ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer&#xA;dereference of dev-&gt;raw pointer, even though it is checked for NULL in&#xA;the same function, which means there is a race condition. It occurs due&#xA;to the incorrect order of actions in the streamzap_disconnect() function:&#xA;rc_unregister_device() is called before usb_kill_urb(). The dev-&gt;raw&#xA;pointer is freed and set to NULL in rc_unregister_device(), and only&#xA;after that usb_kill_urb() waits for in-progress requests to finish.&#xA;&#xA;If rc_unregister_device() is called while streamzap_callback() handler is&#xA;not finished, this can lead to accessing freed resources. Thus&#xA;rc_unregister_device() should be called after usb_kill_urb().&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2025-22028:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: vimc: skip .s_stream() for stopped entities&#xA;&#xA;Syzbot reported [1] a warning prompted by a check in call_s_stream()&#xA;that checks whether .s_stream() operation is warranted for unstarted&#xA;or stopped subdevs.&#xA;&#xA;Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that&#xA;entities skip a call to .s_stream() unless they have been previously&#xA;properly started.&#xA;&#xA;[1] Syzbot report:&#xA;------------[ cut here ]------------&#xA;WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0&#xA;...&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62&#xA; vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]&#xA; vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203&#xA; vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256&#xA; vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789&#xA; vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348&#xA; vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]&#xA; vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118&#xA; __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122&#xA; video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463&#xA; v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366&#xA; vfs_ioctl fs/ioctl.c:51 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:906 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:892 [inline]&#xA; __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f2b85c01b19&#xA;...&#xA;CVE-2025-22044:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;acpi: nfit: fix narrowing conversion in acpi_nfit_ctl&#xA;&#xA;Syzkaller has reported a warning in to_nfit_bus_uuid(): &#34;only secondary&#xA;bus families can be translated&#34;. This warning is emited if the argument&#xA;is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first&#xA;verifies that a user-provided value call_pkg-&gt;nd_family of type u64 is&#xA;not equal to 0. Then the value is converted to int, and only after that&#xA;is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid&#xA;argument to acpi_nfit_ctl(), if call_pkg-&gt;nd_family is non-zero, while&#xA;the lower 32 bits are zero.&#xA;&#xA;Furthermore, it is best to return EINVAL immediately upon seeing the&#xA;invalid user input.  The WARNING is insufficient to prevent further&#xA;undefined behavior based on other invalid user input.&#xA;&#xA;All checks of the input value should be applied to the original variable&#xA;call_pkg-&gt;nd_family.&#xA;&#xA;[iweiny: update commit message]&#xA;CVE-2025-22045:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs&#xA;&#xA;On the following path, flush_tlb_range() can be used for zapping normal&#xA;PMD entries (PMD entries that point to page tables) together with the PTE&#xA;entries in the pointed-to page table:&#xA;&#xA;    collapse_pte_mapped_thp&#xA;      pmdp_collapse_flush&#xA;        flush_tlb_range&#xA;&#xA;The arm64 version of flush_tlb_range() has a comment describing that it can&#xA;be used for page table removal, and does not use any last-level&#xA;invalidation optimizations. Fix the X86 version by making it behave the&#xA;same way.&#xA;&#xA;Currently, X86 only uses this information for the following two purposes,&#xA;which I think means the issue doesn&#39;t have much impact:&#xA;&#xA; - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be&#xA;   IPI&#39;d to avoid issues with speculative page table walks.&#xA; - In Hyper-V TLB paravirtualization, again for lazy TLB stuff.&#xA;&#xA;The patch &#34;x86/mm: only invalidate final translations with INVLPGB&#34; which&#xA;is currently under review (see&#xA;&lt;https://lore.kernel.org/all/[email protected]/&gt;)&#xA;would probably be making the impact of this a lot worse.&#xA;CVE-2025-22054:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;arcnet: Add NULL check in com20020pci_probe()&#xA;&#xA;devm_kasprintf() returns NULL when memory allocation fails. Currently,&#xA;com20020pci_probe() does not check for this case, which results in a&#xA;NULL pointer dereference.&#xA;&#xA;Add NULL check after devm_kasprintf() to prevent this issue and ensure&#xA;no resources are left allocated.&#xA;CVE-2025-22055:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: fix geneve_opt length integer overflow&#xA;&#xA;struct geneve_opt uses 5 bit length for each single option, which&#xA;means every vary size option should be smaller than 128 bytes.&#xA;&#xA;However, all current related Netlink policies cannot promise this&#xA;length condition and the attacker can exploit a exact 128-byte size&#xA;option to *fake* a zero length option and confuse the parsing logic,&#xA;further achieve heap out-of-bounds read.&#xA;&#xA;One example crash log is like below:&#xA;&#xA;[    3.905425] ==================================================================&#xA;[    3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0&#xA;[    3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177&#xA;[    3.906646]&#xA;[    3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1&#xA;[    3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;[    3.907784] Call Trace:&#xA;[    3.907925]  &lt;TASK&gt;&#xA;[    3.908048]  dump_stack_lvl+0x44/0x5c&#xA;[    3.908258]  print_report+0x184/0x4be&#xA;[    3.909151]  kasan_report+0xc5/0x100&#xA;[    3.909539]  kasan_check_range+0xf3/0x1a0&#xA;[    3.909794]  memcpy+0x1f/0x60&#xA;[    3.909968]  nla_put+0xa9/0xe0&#xA;[    3.910147]  tunnel_key_dump+0x945/0xba0&#xA;[    3.911536]  tcf_action_dump_1+0x1c1/0x340&#xA;[    3.912436]  tcf_action_dump+0x101/0x180&#xA;[    3.912689]  tcf_exts_dump+0x164/0x1e0&#xA;[    3.912905]  fw_dump+0x18b/0x2d0&#xA;[    3.913483]  tcf_fill_node+0x2ee/0x460&#xA;[    3.914778]  tfilter_notify+0xf4/0x180&#xA;[    3.915208]  tc_new_tfilter+0xd51/0x10d0&#xA;[    3.918615]  rtnetlink_rcv_msg+0x4a2/0x560&#xA;[    3.919118]  netlink_rcv_skb+0xcd/0x200&#xA;[    3.919787]  netlink_unicast+0x395/0x530&#xA;[    3.921032]  netlink_sendmsg+0x3d0/0x6d0&#xA;[    3.921987]  __sock_sendmsg+0x99/0xa0&#xA;[    3.922220]  __sys_sendto+0x1b7/0x240&#xA;[    3.922682]  __x64_sys_sendto+0x72/0x90&#xA;[    3.922906]  do_syscall_64+0x5e/0x90&#xA;[    3.923814]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;[    3.924122] RIP: 0033:0x7e83eab84407&#xA;[    3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 &lt;5b&gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf&#xA;[    3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c&#xA;[    3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407&#xA;[    3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003&#xA;[    3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c&#xA;[    3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0&#xA;[    3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8&#xA;&#xA;Fix these issues by enforing correct length condition in related&#xA;policies.&#xA;CVE-2025-22086:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow&#xA;&#xA;When cur_qp isn&#39;t NULL, in order to avoid fetching the QP from&#xA;the radix tree again we check if the next cqe QP is identical to&#xA;the one we already have.&#xA;&#xA;The bug however is that we are checking if the QP is identical by&#xA;checking the QP number inside the CQE against the QP number inside the&#xA;mlx5_ib_qp, but that&#39;s wrong since the QP number from the CQE is from&#xA;FW so it should be matched against mlx5_core_qp which is our FW QP&#xA;number.&#xA;&#xA;Otherwise we could use the wrong QP when handling a CQE which could&#xA;cause the kernel trace below.&#xA;&#xA;This issue is mainly noticeable over QPs 0 &amp; 1, since for now they are&#xA;the only QPs in our driver whereas the QP number inside mlx5_ib_qp&#xA;doesn&#39;t match the QP number inside mlx5_core_qp.&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000012&#xA; #PF: supervisor read access in kernel mode&#xA; #PF: error_code(0x0000) - not-present page&#xA; PGD 0 P4D 0&#xA; Oops: Oops: 0000 [#1] SMP&#xA; CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA; Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]&#xA; RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]&#xA; Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 &lt;0f&gt; b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21&#xA; RSP: 0018:ffff88810511bd60 EFLAGS: 00010046&#xA; RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000&#xA; RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a&#xA; RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10&#xA; R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000&#xA; R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0&#xA; FS:  0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ? __die+0x20/0x60&#xA;  ? page_fault_oops+0x150/0x3e0&#xA;  ? exc_page_fault+0x74/0x130&#xA;  ? asm_exc_page_fault+0x22/0x30&#xA;  ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]&#xA;  __ib_process_cq+0x5a/0x150 [ib_core]&#xA;  ib_cq_poll_work+0x31/0x90 [ib_core]&#xA;  process_one_work+0x169/0x320&#xA;  worker_thread+0x288/0x3a0&#xA;  ? work_busy+0xb0/0xb0&#xA;  kthread+0xd7/0x1f0&#xA;  ? kthreads_online_cpu+0x130/0x130&#xA;  ? kthreads_online_cpu+0x130/0x130&#xA;  ret_from_fork+0x2d/0x50&#xA;  ? kthreads_online_cpu+0x130/0x130&#xA;  ret_from_fork_asm+0x11/0x20&#xA;  &lt;/TASK&gt;&#xA;CVE-2025-22103:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: fix NULL pointer dereference in l3mdev_l3_rcv&#xA;&#xA;When delete l3s ipvlan:&#xA;&#xA;    ip link del link eth0 ipvlan1 type ipvlan mode l3s&#xA;&#xA;This may cause a null pointer dereference:&#xA;&#xA;    Call trace:&#xA;     ip_rcv_finish+0x48/0xd0&#xA;     ip_rcv+0x5c/0x100&#xA;     __netif_receive_skb_one_core+0x64/0xb0&#xA;     __netif_receive_skb+0x20/0x80&#xA;     process_backlog+0xb4/0x204&#xA;     napi_poll+0xe8/0x294&#xA;     net_rx_action+0xd8/0x22c&#xA;     __do_softirq+0x12c/0x354&#xA;&#xA;This is because l3mdev_l3_rcv() visit dev-&gt;l3mdev_ops after&#xA;ipvlan_l3s_unregister() assign the dev-&gt;l3mdev_ops to NULL. The process&#xA;like this:&#xA;&#xA;    (CPU1)                     | (CPU2)&#xA;    l3mdev_l3_rcv()            |&#xA;      check dev-&gt;priv_flags:   |&#xA;        master = skb-&gt;dev;     |&#xA;                               |&#xA;                               | ipvlan_l3s_unregister()&#xA;                               |   set dev-&gt;priv_flags&#xA;                               |   dev-&gt;l3mdev_ops = NULL;&#xA;                               |&#xA;      visit master-&gt;l3mdev_ops |&#xA;&#xA;To avoid this by do not set dev-&gt;l3mdev_ops when unregister l3s ipvlan.&#xA;CVE-2025-22104:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ibmvnic: Use kernel helpers for hex dumps&#xA;&#xA;Previously, when the driver was printing hex dumps, the buffer was cast&#xA;to an 8 byte long and printed using string formatters. If the buffer&#xA;size was not a multiple of 8 then a read buffer overflow was possible.&#xA;&#xA;Therefore, create a new ibmvnic function that loops over a buffer and&#xA;calls hex_dump_to_buffer instead.&#xA;&#xA;This patch address KASAN reports like the one below:&#xA;  ibmvnic 30000003 env3: Login Buffer:&#xA;  ibmvnic 30000003 env3: 01000000af000000&#xA;  &lt;...&gt;&#xA;  ibmvnic 30000003 env3: 2e6d62692e736261&#xA;  ibmvnic 30000003 env3: 65050003006d6f63&#xA;  ==================================================================&#xA;  BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]&#xA;  Read of size 8 at addr c0000001331a9aa8 by task ip/17681&#xA;  &lt;...&gt;&#xA;  Allocated by task 17681:&#xA;  &lt;...&gt;&#xA;  ibmvnic_login+0x2f0/0xffc [ibmvnic]&#xA;  ibmvnic_open+0x148/0x308 [ibmvnic]&#xA;  __dev_open+0x1ac/0x304&#xA;  &lt;...&gt;&#xA;  The buggy address is located 168 bytes inside of&#xA;                allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)&#xA;  &lt;...&gt;&#xA;  =================================================================&#xA;  ibmvnic 30000003 env3: 000000000033766e&#xA;CVE-2025-23131:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dlm: prevent NPD when writing a positive value to event_done&#xA;&#xA;do_uevent returns the value written to event_done. In case it is a&#xA;positive value, new_lockspace would undo all the work, and lockspace&#xA;would not be set. __dlm_new_lockspace, however, would treat that&#xA;positive value as a success due to commit 8511a2728ab8 (&#34;dlm: fix use&#xA;count with multiple joins&#34;).&#xA;&#xA;Down the line, device_create_lockspace would pass that NULL lockspace to&#xA;dlm_find_lockspace_local, leading to a NULL pointer dereference.&#xA;&#xA;Treating such positive values as successes prevents the problem. Given&#xA;this has been broken for so long, this is unlikely to break userspace&#xA;expectations.&#xA;CVE-2025-23136:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;thermal: int340x: Add NULL check for adev&#xA;&#xA;Not all devices have an ACPI companion fwnode, so adev might be NULL.&#xA;This is similar to the commit cd2fd6eab480&#xA;(&#34;platform/x86: int3472: Check for adev == NULL&#34;).&#xA;&#xA;Add a check for adev not being set and return -ENODEV in that case to&#xA;avoid a possible NULL pointer deref in int3402_thermal_probe().&#xA;&#xA;Note, under the same directory, int3400_thermal_probe() has such a&#xA;check.&#xA;&#xA;[ rjw: Subject edit, added Fixes: ]&#xA;CVE-2025-23140:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error&#xA;&#xA;After devm_request_irq() fails with error in pci_endpoint_test_request_irq(),&#xA;the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs&#xA;have been released.&#xA;&#xA;However, some requested IRQs remain unreleased, so there are still&#xA;/proc/irq/* entries remaining, and this results in WARN() with the&#xA;following message:&#xA;&#xA;  remove_proc_entry: removing non-empty directory &#39;irq/30&#39;, leaking at least &#39;pci-endpoint-test.0&#39;&#xA;  WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c&#xA;&#xA;To solve this issue, set the number of remaining IRQs to test-&gt;num_irqs,&#xA;and release IRQs in advance by calling pci_endpoint_test_release_irq().&#xA;&#xA;[kwilczynski: commit log]&#xA;CVE-2025-23143:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.&#xA;&#xA;When I ran the repro [0] and waited a few seconds, I observed two&#xA;LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]&#xA;&#xA;Reproduction Steps:&#xA;&#xA;  1) Mount CIFS&#xA;  2) Add an iptables rule to drop incoming FIN packets for CIFS&#xA;  3) Unmount CIFS&#xA;  4) Unload the CIFS module&#xA;  5) Remove the iptables rule&#xA;&#xA;At step 3), the CIFS module calls sock_release() for the underlying&#xA;TCP socket, and it returns quickly.  However, the socket remains in&#xA;FIN_WAIT_1 because incoming FIN packets are dropped.&#xA;&#xA;At this point, the module&#39;s refcnt is 0 while the socket is still&#xA;alive, so the following rmmod command succeeds.&#xA;&#xA;  # ss -tan&#xA;  State      Recv-Q Send-Q Local Address:Port  Peer Address:Port&#xA;  FIN-WAIT-1 0      477        10.0.2.15:51062   10.0.0.137:445&#xA;&#xA;  # lsmod | grep cifs&#xA;  cifs                 1159168  0&#xA;&#xA;This highlights a discrepancy between the lifetime of the CIFS module&#xA;and the underlying TCP socket.  Even after CIFS calls sock_release()&#xA;and it returns, the TCP socket does not die immediately in order to&#xA;close the connection gracefully.&#xA;&#xA;While this is generally fine, it causes an issue with LOCKDEP because&#xA;CIFS assigns a different lock class to the TCP socket&#39;s sk-&gt;sk_lock&#xA;using sock_lock_init_class_and_name().&#xA;&#xA;Once an incoming packet is processed for the socket or a timer fires,&#xA;sk-&gt;sk_lock is acquired.&#xA;&#xA;Then, LOCKDEP checks the lock context in check_wait_context(), where&#xA;hlock_class() is called to retrieve the lock class.  However, since&#xA;the module has already been unloaded, hlock_class() logs a warning&#xA;and returns NULL, triggering the null-ptr-deref.&#xA;&#xA;If LOCKDEP is enabled, we must ensure that a module calling&#xA;sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded&#xA;while such a socket is still alive to prevent this issue.&#xA;&#xA;Let&#39;s hold the module reference in sock_lock_init_class_and_name()&#xA;and release it when the socket is freed in sk_prot_free().&#xA;&#xA;Note that sock_lock_init() clears sk-&gt;sk_owner for svc_create_socket()&#xA;that calls sock_lock_init_class_and_name() for a listening socket,&#xA;which clones a socket by sk_clone_lock() without GFP_ZERO.&#xA;&#xA;[0]:&#xA;CIFS_SERVER=&#34;10.0.0.137&#34;&#xA;CIFS_PATH=&#34;//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST&#34;&#xA;DEV=&#34;enp0s3&#34;&#xA;CRED=&#34;/root/WindowsCredential.txt&#34;&#xA;&#xA;MNT=$(mktemp -d /tmp/XXXXXX)&#xA;mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1&#xA;&#xA;iptables -A INPUT -s ${CIFS_SERVER} -j DROP&#xA;&#xA;for i in $(seq 10);&#xA;do&#xA;    umount ${MNT}&#xA;    rmmod cifs&#xA;    sleep 1&#xA;done&#xA;&#xA;rm -r ${MNT}&#xA;&#xA;iptables -D INPUT -s ${CIFS_SERVER} -j DROP&#xA;&#xA;[1]:&#xA;DEBUG_LOCKS_WARN_ON(1)&#xA;WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)&#xA;Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]&#xA;CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)&#xA;...&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178)&#xA; lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816)&#xA; _raw_spin_lock_nested (kernel/locking/spinlock.c:379)&#xA; tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)&#xA;...&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 00000000000000c4&#xA; PF: supervisor read access in kernel mode&#xA; PF: error_code(0x0000) - not-present page&#xA;PGD 0&#xA;Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI&#xA;CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G        W          6.14.0 #36&#xA;Tainted: [W]=WARN&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA;RIP: 0010:__lock_acquire (kernel/&#xA;---truncated---&#xA;CVE-2025-23147:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i3c: Add NULL pointer check in i3c_master_queue_ibi()&#xA;&#xA;The I3C master driver may receive an IBI from a target device that has not&#xA;been probed yet. In such cases, the master calls `i3c_master_queue_ibi()`&#xA;to queue an IBI work task, leading to &#34;Unable to handle kernel read from&#xA;unreadable memory&#34; and resulting in a kernel panic.&#xA;&#xA;Typical IBI handling flow:&#xA;1. The I3C master scans target devices and probes their respective drivers.&#xA;2. The target device driver calls `i3c_device_request_ibi()` to enable IBI&#xA;   and assigns `dev-&gt;ibi = ibi`.&#xA;3. The I3C master receives an IBI from the target device and calls&#xA;   `i3c_master_queue_ibi()` to queue the target device driver’s IBI&#xA;   handler task.&#xA;&#xA;However, since target device events are asynchronous to the I3C probe&#xA;sequence, step 3 may occur before step 2, causing `dev-&gt;ibi` to be `NULL`,&#xA;leading to a kernel panic.&#xA;&#xA;Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing&#xA;an uninitialized `dev-&gt;ibi`, ensuring stability.&#xA;CVE-2025-23157:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: venus: hfi_parser: add check to avoid out of bound access&#xA;&#xA;There is a possibility that init_codecs is invoked multiple times during&#xA;manipulated payload from video firmware. In such case, if codecs_count&#xA;can get incremented to value more than MAX_CODEC_NUM, there can be OOB&#xA;access. Reset the count so that it always starts from beginning.&#xA;CVE-2025-23159:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: venus: hfi: add a check to handle OOB in sfr region&#xA;&#xA;sfr-&gt;buf_size is in shared memory and can be modified by malicious user.&#xA;OOB write is possible when the size is made higher than actual sfr data&#xA;buffer. Cap the size to allocated size for such cases.&#xA;CVE-2025-23161:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type&#xA;&#xA;The access to the PCI config space via pci_ops::read and pci_ops::write is&#xA;a low-level hardware access. The functions can be accessed with disabled&#xA;interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this&#xA;purpose.&#xA;&#xA;A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be&#xA;acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in&#xA;the same context as the pci_lock.&#xA;&#xA;Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with&#xA;interrupts disabled.&#xA;&#xA;This was reported as:&#xA;&#xA;  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48&#xA;  Call Trace:&#xA;   rt_spin_lock+0x4e/0x130&#xA;   vmd_pci_read+0x8d/0x100 [vmd]&#xA;   pci_user_read_config_byte+0x6f/0xe0&#xA;   pci_read_config+0xfe/0x290&#xA;   sysfs_kf_bin_read+0x68/0x90&#xA;&#xA;[bigeasy: reword commit message]&#xA;Tested-off-by: Luis Claudio R. Goncalves &lt;[email protected]&gt;&#xA;[kwilczynski: commit log]&#xA;[bhelgaas: add back report info from&#xA;https://lore.kernel.org/lkml/[email protected]/]&#xA;CVE-2025-37739:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()&#xA;&#xA;syzbot reports an UBSAN issue as below:&#xA;&#xA;------------[ cut here ]------------&#xA;UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10&#xA;index 18446744073709550692 is out of range for type &#39;__le32[5]&#39; (aka &#39;unsigned int[5]&#39;)&#xA;CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __dump_stack lib/dump_stack.c:94 [inline]&#xA; dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120&#xA; ubsan_epilogue lib/ubsan.c:231 [inline]&#xA; __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429&#xA; get_nid fs/f2fs/node.h:381 [inline]&#xA; f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181&#xA; f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808&#xA; f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836&#xA; f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886&#xA; f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093&#xA; aio_write+0x56b/0x7c0 fs/aio.c:1633&#xA; io_submit_one+0x8a7/0x18a0 fs/aio.c:2052&#xA; __do_sys_io_submit fs/aio.c:2111 [inline]&#xA; __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f238798cde9&#xA;&#xA;index 18446744073709550692 (decimal, unsigned long long)&#xA;= 0xfffffffffffffc64 (hexadecimal, unsigned long long)&#xA;= -924 (decimal, long long)&#xA;&#xA;In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to&#xA;access .i_nid[-924], it means both offset[0] and level should zero.&#xA;&#xA;The possible case should be in f2fs_do_truncate_blocks(), we try to&#xA;truncate inode size to zero, however, dn.ofs_in_node is zero and&#xA;dn.node_page is not an inode page, so it fails to truncate inode page,&#xA;and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result&#xA;in this issue.&#xA;&#xA;&#x9;if (dn.ofs_in_node || IS_INODE(dn.node_page)) {&#xA;&#x9;&#x9;f2fs_truncate_data_blocks_range(&amp;dn, count);&#xA;&#x9;&#x9;free_from += count;&#xA;&#x9;}&#xA;&#xA;I guess the reason why dn.node_page is not an inode page could be: there&#xA;are multiple nat entries share the same node block address, once the node&#xA;block address was reused, f2fs_get_node_page() may load a non-inode block.&#xA;&#xA;Let&#39;s add a sanity check for such condition to avoid out-of-bounds access&#xA;issue.&#xA;CVE-2025-37756:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: tls: explicitly disallow disconnect&#xA;&#xA;syzbot discovered that it can disconnect a TLS socket and then&#xA;run into all sort of unexpected corner cases. I have a vague&#xA;recollection of Eric pointing this out to us a long time ago.&#xA;Supporting disconnect is really hard, for one thing if offload&#xA;is enabled we&#39;d need to wait for all packets to be _acked_.&#xA;Disconnect is not commonly used, disallow it.&#xA;&#xA;The immediate problem syzbot run into is the warning in the strp,&#xA;but that&#39;s just the easiest bug to trigger:&#xA;&#xA;  WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486&#xA;  RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363&#xA;   tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043&#xA;   inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678&#xA;   sock_recvmsg_nosec net/socket.c:1023 [inline]&#xA;   sock_recvmsg+0x109/0x280 net/socket.c:1045&#xA;   __sys_recvfrom+0x202/0x380 net/socket.c:2237&#xA;CVE-2025-37757:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tipc: fix memory leak in tipc_link_xmit&#xA;&#xA;In case the backlog transmit queue for system-importance messages is overloaded,&#xA;tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to&#xA;memory leak and failure when a skb is allocated.&#xA;&#xA;This commit fixes this issue by purging the skb list before tipc_link_xmit()&#xA;returns.&#xA;CVE-2025-37758:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()&#xA;&#xA;devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does&#xA;not check for this case, which can result in a NULL pointer dereference.&#xA;&#xA;Add NULL check after devm_ioremap() to prevent this issue.&#xA;CVE-2025-37765:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/nouveau: prime: fix ttm_bo_delayed_delete oops&#xA;&#xA;Fix an oops in ttm_bo_delayed_delete which results from dererencing a&#xA;dangling pointer:&#xA;&#xA;Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP&#xA;CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216&#xA;Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024&#xA;Workqueue: ttm ttm_bo_delayed_delete [ttm]&#xA;RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290&#xA;Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 &lt;41&gt; 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b&#xA;RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202&#xA;RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000&#xA;RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b&#xA;R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc&#xA;FS:  0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0&#xA;PKRU: 55555554&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die_body.cold+0x19/0x26&#xA; ? die_addr+0x3d/0x70&#xA; ? exc_general_protection+0x159/0x460&#xA; ? asm_exc_general_protection+0x27/0x30&#xA; ? dma_resv_iter_first_unlocked+0x55/0x290&#xA; dma_resv_wait_timeout+0x56/0x100&#xA; ttm_bo_delayed_delete+0x69/0xb0 [ttm]&#xA; process_one_work+0x217/0x5c0&#xA; worker_thread+0x1c8/0x3d0&#xA; ? apply_wqattrs_cleanup.part.0+0xc0/0xc0&#xA; kthread+0x10b/0x240&#xA; ? kthreads_online_cpu+0x140/0x140&#xA; ret_from_fork+0x40/0x70&#xA; ? kthreads_online_cpu+0x140/0x140&#xA; ret_from_fork_asm+0x11/0x20&#xA; &lt;/TASK&gt;&#xA;&#xA;The cause of this is:&#xA;&#xA;- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the&#xA;  reference to the shared dma_buf. The reference count is 0, so the&#xA;  dma_buf is destroyed, which in turn decrements the corresponding&#xA;  amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -&#xA;  calling drm_gem_object_release then dma_resv_fini (which destroys the&#xA;  reservation object), then finally freeing the amdgpu_bo.&#xA;&#xA;- nouveau_bo obj-&gt;bo.base.resv is now a dangling pointer to the memory&#xA;  formerly allocated to the amdgpu_bo.&#xA;&#xA;- nouveau_gem_object_del calls ttm_bo_put(&amp;nvbo-&gt;bo) which calls&#xA;  ttm_bo_release, which schedules ttm_bo_delayed_delete.&#xA;&#xA;- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,&#xA;  resulting in a general protection fault.&#xA;&#xA;Fix this by moving the drm_prime_gem_destroy call from&#xA;nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will&#xA;be run after ttm_bo_delayed_delete.&#xA;CVE-2025-37781:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i2c: cros-ec-tunnel: defer probe if parent EC is not present&#xA;&#xA;When i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent&#xA;device will not be found, leading to NULL pointer dereference.&#xA;&#xA;That can also be reproduced by unbinding the controller driver and then&#xA;loading i2c-cros-ec-tunnel module (or binding the device).&#xA;&#xA;[  271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058&#xA;[  271.998215] #PF: supervisor read access in kernel mode&#xA;[  272.003351] #PF: error_code(0x0000) - not-present page&#xA;[  272.008485] PGD 0 P4D 0&#xA;[  272.011022] Oops: Oops: 0000 [#1] SMP NOPTI&#xA;[  272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S                  6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full)  3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5&#xA;[  272.030312] Tainted: [S]=CPU_OUT_OF_SPEC&#xA;[  272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021&#xA;[  272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel]&#xA;[  272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 &lt;49&gt; 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9&#xA;[  272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282&#xA;[  272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000&#xA;[  272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00&#xA;[  272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000&#xA;[  272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000&#xA;[  272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10&#xA;[  272.108198] FS:  00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000&#xA;[  272.116282] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0&#xA;[  272.129155] Call Trace:&#xA;[  272.131606]  &lt;TASK&gt;&#xA;[  272.133709]  ? acpi_dev_pm_attach+0xdd/0x110&#xA;[  272.137985]  platform_probe+0x69/0xa0&#xA;[  272.141652]  really_probe+0x152/0x310&#xA;[  272.145318]  __driver_probe_device+0x77/0x110&#xA;[  272.149678]  driver_probe_device+0x1e/0x190&#xA;[  272.153864]  __driver_attach+0x10b/0x1e0&#xA;[  272.157790]  ? driver_attach+0x20/0x20&#xA;[  272.161542]  bus_for_each_dev+0x107/0x150&#xA;[  272.165553]  bus_add_driver+0x15d/0x270&#xA;[  272.169392]  driver_register+0x65/0x110&#xA;[  272.173232]  ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698]&#xA;[  272.182617]  do_one_initcall+0x110/0x350&#xA;[  272.186543]  ? security_kernfs_init_security+0x49/0xd0&#xA;[  272.191682]  ? __kernfs_new_node+0x1b9/0x240&#xA;[  272.195954]  ? security_kernfs_init_security+0x49/0xd0&#xA;[  272.201093]  ? __kernfs_new_node+0x1b9/0x240&#xA;[  272.205365]  ? kernfs_link_sibling+0x105/0x130&#xA;[  272.209810]  ? kernfs_next_descendant_post+0x1c/0xa0&#xA;[  272.214773]  ? kernfs_activate+0x57/0x70&#xA;[  272.218699]  ? kernfs_add_one+0x118/0x160&#xA;[  272.222710]  ? __kernfs_create_file+0x71/0xa0&#xA;[  272.227069]  ? sysfs_add_bin_file_mode_ns+0xd6/0x110&#xA;[  272.232033]  ? internal_create_group+0x453/0x4a0&#xA;[  272.236651]  ? __vunmap_range_noflush+0x214/0x2d0&#xA;[  272.241355]  ? __free_frozen_pages+0x1dc/0x420&#xA;[  272.245799]  ? free_vmap_area_noflush+0x10a/0x1c0&#xA;[  272.250505]  ? load_module+0x1509/0x16f0&#xA;[  272.254431]  do_init_module+0x60/0x230&#xA;[  272.258181]  __se_sys_finit_module+0x27a/0x370&#xA;[  272.262627]  do_syscall_64+0x6a/0xf0&#xA;[  272.266206]  ? do_syscall_64+0x76/0xf0&#xA;[  272.269956]  ? irqentry_exit_to_user_mode+0x79/0x90&#xA;[  272.274836]  entry_SYSCALL_64_after_hwframe+0x55/0x5d&#xA;[  272.279887] RIP: 0033:0x7b9309168d39&#xA;[  272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8&#xA;[  272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000&#xA;---truncated---&#xA;CVE-2025-37788:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path&#xA;&#xA;In the for loop used to allocate the loc_array and bmap for each port, a&#xA;memory leak is possible when the allocation for loc_array succeeds,&#xA;but the allocation for bmap fails. This is because when the control flow&#xA;goes to the label free_eth_finfo, only the allocations starting from&#xA;(i-1)th iteration are freed.&#xA;&#xA;Fix that by freeing the loc_array in the bmap allocation error path.&#xA;CVE-2025-37792:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: btrtl: Prevent potential NULL dereference&#xA;&#xA;The btrtl_initialize() function checks that rtl_load_file() either&#xA;had an error or it loaded a zero length file.  However, if it loaded&#xA;a zero length file then the error code is not set correctly.  It&#xA;results in an error pointer vs NULL bug, followed by a NULL pointer&#xA;dereference.  This was detected by Smatch:&#xA;&#xA;drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to &#39;ERR_PTR&#39;&#xA;CVE-2025-37794:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mac80211: Purge vif txq in ieee80211_do_stop()&#xA;&#xA;After ieee80211_do_stop() SKB from vif&#39;s txq could still be processed.&#xA;Indeed another concurrent vif schedule_and_wake_txq call could cause&#xA;those packets to be dequeued (see ieee80211_handle_wake_tx_queue())&#xA;without checking the sdata current state.&#xA;&#xA;Because vif.drv_priv is now cleared in this function, this could lead to&#xA;driver crash.&#xA;&#xA;For example in ath12k, ahvif is store in vif.drv_priv. Thus if&#xA;ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif-&gt;ah can be&#xA;NULL, leading the ath12k_warn(ahvif-&gt;ah,...) call in this function to&#xA;trigger the NULL deref below.&#xA;&#xA;  Unable to handle kernel paging request at virtual address dfffffc000000001&#xA;  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;  batman_adv: bat0: Interface deactivated: brbh1337&#xA;  Mem abort info:&#xA;    ESR = 0x0000000096000004&#xA;    EC = 0x25: DABT (current EL), IL = 32 bits&#xA;    SET = 0, FnV = 0&#xA;    EA = 0, S1PTW = 0&#xA;    FSC = 0x04: level 0 translation fault&#xA;  Data abort info:&#xA;    ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000&#xA;    CM = 0, WnR = 0, TnD = 0, TagAccess = 0&#xA;    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0&#xA;  [dfffffc000000001] address between user and kernel address ranges&#xA;  Internal error: Oops: 0000000096000004 [#1] SMP&#xA;  CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114&#xA;  Hardware name: HW (DT)&#xA;  pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;  pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]&#xA;  lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]&#xA;  sp : ffffffc086ace450&#xA;  x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4&#xA;  x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e&#xA;  x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0&#xA;  x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958&#xA;  x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8&#xA;  x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03&#xA;  x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40&#xA;  x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0&#xA;  x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001&#xA;  x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008&#xA;  Call trace:&#xA;   ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)&#xA;   ieee80211_handle_wake_tx_queue+0x16c/0x260&#xA;   ieee80211_queue_skb+0xeec/0x1d20&#xA;   ieee80211_tx+0x200/0x2c8&#xA;   ieee80211_xmit+0x22c/0x338&#xA;   __ieee80211_subif_start_xmit+0x7e8/0xc60&#xA;   ieee80211_subif_start_xmit+0xc4/0xee0&#xA;   __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0&#xA;   ieee80211_subif_start_xmit_8023+0x124/0x488&#xA;   dev_hard_start_xmit+0x160/0x5a8&#xA;   __dev_queue_xmit+0x6f8/0x3120&#xA;   br_dev_queue_push_xmit+0x120/0x4a8&#xA;   __br_forward+0xe4/0x2b0&#xA;   deliver_clone+0x5c/0xd0&#xA;   br_flood+0x398/0x580&#xA;   br_dev_xmit+0x454/0x9f8&#xA;   dev_hard_start_xmit+0x160/0x5a8&#xA;   __dev_queue_xmit+0x6f8/0x3120&#xA;   ip6_finish_output2+0xc28/0x1b60&#xA;   __ip6_finish_output+0x38c/0x638&#xA;   ip6_output+0x1b4/0x338&#xA;   ip6_local_out+0x7c/0xa8&#xA;   ip6_send_skb+0x7c/0x1b0&#xA;   ip6_push_pending_frames+0x94/0xd0&#xA;   rawv6_sendmsg+0x1a98/0x2898&#xA;   inet_sendmsg+0x94/0xe0&#xA;   __sys_sendto+0x1e4/0x308&#xA;   __arm64_sys_sendto+0xc4/0x140&#xA;   do_el0_svc+0x110/0x280&#xA;   el0_svc+0x20/0x60&#xA;   el0t_64_sync_handler+0x104/0x138&#xA;   el0t_64_sync+0x154/0x158&#xA;&#xA;To avoid that, empty vif&#39;s txq at ieee80211_do_stop() so no packet could&#xA;be dequeued after ieee80211_do_stop() (new packets cannot be queued&#xA;because SDATA_STATE_RUNNING is cleared at this point).&#xA;CVE-2025-37803:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;udmabuf: fix a buf size overflow issue during udmabuf creation&#xA;&#xA;by casting size_limit_mb to u64  when calculate pglimit.&#xA;CVE-2025-37808:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: null - Use spin lock instead of mutex&#xA;&#xA;As the null algorithm may be freed in softirq context through&#xA;af_alg, use spin locks instead of mutexes to protect the default&#xA;null algorithm.&#xA;CVE-2025-37817:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mcb: fix a double free bug in chameleon_parse_gdd()&#xA;&#xA;In chameleon_parse_gdd(), if mcb_device_register() fails, &#39;mdev&#39;&#xA;would be released in mcb_device_register() via put_device().&#xA;Thus, goto &#39;err&#39; label and free &#39;mdev&#39; again causes a double free.&#xA;Just return if mcb_device_register() fails.&#xA;CVE-2025-37830:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()&#xA;&#xA;cpufreq_cpu_get_raw() can return NULL when the target CPU is not present&#xA;in the policy-&gt;cpus mask. scmi_cpufreq_get_rate() does not check for&#xA;this case, which results in a NULL pointer dereference.&#xA;&#xA;Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.&#xA;CVE-2025-37833:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads&#xA;&#xA;Fix niu_try_msix() to not cause a fatal trap on sparc systems.&#xA;&#xA;Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to&#xA;work around a bug in the hardware or firmware.&#xA;&#xA;For each vector entry in the msix table, niu chips will cause a fatal&#xA;trap if any registers in that entry are read before that entries&#39;&#xA;ENTRY_DATA register is written to. Testing indicates writes to other&#xA;registers are not sufficient to prevent the fatal trap, however the value&#xA;does not appear to matter. This only needs to happen once after power up,&#xA;so simply rebooting into a kernel lacking this fix will NOT cause the&#xA;trap.&#xA;&#xA;NON-RESUMABLE ERROR: Reporting on cpu 64&#xA;NON-RESUMABLE ERROR: TPC [0x00000000005f6900] &lt;msix_prepare_msi_desc+0x90/0xa0&gt;&#xA;NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff&#xA;NON-RESUMABLE ERROR:      0000000800000000:0000000000000000:0000000000000000:0000000000000000]&#xA;NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]&#xA;NON-RESUMABLE ERROR: type [precise nonresumable]&#xA;NON-RESUMABLE ERROR: attrs [0x02000080] &lt; ASI sp-faulted priv &gt;&#xA;NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]&#xA;NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]&#xA;NON-RESUMABLE ERROR: size [0x8]&#xA;NON-RESUMABLE ERROR: asi [0x00]&#xA;CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63&#xA;Workqueue: events work_for_cpu_fn&#xA;TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000    Not tainted&#xA;TPC: &lt;msix_prepare_msi_desc+0x90/0xa0&gt;&#xA;g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100&#xA;g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000&#xA;o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620&#xA;o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128&#xA;RPC: &lt;__pci_enable_msix_range+0x3cc/0x460&gt;&#xA;l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020&#xA;l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734&#xA;i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d&#xA;i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0&#xA;I7: &lt;niu_try_msix.constprop.0+0xc0/0x130 [niu]&gt;&#xA;Call Trace:&#xA;[&lt;00000000101888b0&gt;] niu_try_msix.constprop.0+0xc0/0x130 [niu]&#xA;[&lt;000000001018f840&gt;] niu_get_invariants+0x183c/0x207c [niu]&#xA;[&lt;00000000101902fc&gt;] niu_pci_init_one+0x27c/0x2fc [niu]&#xA;[&lt;00000000005ef3e4&gt;] local_pci_probe+0x28/0x74&#xA;[&lt;0000000000469240&gt;] work_for_cpu_fn+0x8/0x1c&#xA;[&lt;000000000046b008&gt;] process_scheduled_works+0x144/0x210&#xA;[&lt;000000000046b518&gt;] worker_thread+0x13c/0x1c0&#xA;[&lt;00000000004710e0&gt;] kthread+0xb8/0xc8&#xA;[&lt;00000000004060c8&gt;] ret_from_fork+0x1c/0x2c&#xA;[&lt;0000000000000000&gt;] 0x0&#xA;Kernel panic - not syncing: Non-resumable error.&#xA;CVE-2025-37836:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI: Fix reference leak in pci_register_host_bridge()&#xA;&#xA;If device_register() fails, call put_device() to give up the reference to&#xA;avoid a memory leak, per the comment at device_register().&#xA;&#xA;Found by code review.&#xA;&#xA;[bhelgaas: squash Dan Carpenter&#39;s double free fix from&#xA;https://lore.kernel.org/r/[email protected]]&#xA;CVE-2025-37838:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition&#xA;&#xA;In the ssi_protocol_probe() function, &amp;ssi-&gt;work is bound with&#xA;ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function&#xA;within the ssip_pn_ops structure is capable of starting the&#xA;work.&#xA;&#xA;If we remove the module which will call ssi_protocol_remove()&#xA;to make a cleanup, it will free ssi through kfree(ssi),&#xA;while the work mentioned above will be used. The sequence&#xA;of operations that may lead to a UAF bug is as follows:&#xA;&#xA;CPU0                                    CPU1&#xA;&#xA;                        | ssip_xmit_work&#xA;ssi_protocol_remove     |&#xA;kfree(ssi);             |&#xA;                        | struct hsi_client *cl = ssi-&gt;cl;&#xA;                        | // use ssi&#xA;&#xA;Fix it by ensuring that the work is canceled before proceeding&#xA;with the cleanup in ssi_protocol_remove().&#xA;CVE-2025-37840:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mtd: rawnand: brcmnand: fix PM resume warning&#xA;&#xA;Fixed warning on PM resume as shown below caused due to uninitialized&#xA;struct nand_operation that checks chip select field :&#xA;WARN_ON(op-&gt;cs &gt;= nanddev_ntargets(&amp;chip-&gt;base)&#xA;&#xA;[   14.588522] ------------[ cut here ]------------&#xA;[   14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8&#xA;[   14.588553] Modules linked in: bdc udc_core&#xA;[   14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G        W          6.14.0-rc4-g5394eea10651 #16&#xA;[   14.588590] Tainted: [W]=WARN&#xA;[   14.588593] Hardware name: Broadcom STB (Flattened Device Tree)&#xA;[   14.588598] Call trace:&#xA;[   14.588604]  dump_backtrace from show_stack+0x18/0x1c&#xA;[   14.588622]  r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c&#xA;[   14.588625]  show_stack from dump_stack_lvl+0x70/0x7c&#xA;[   14.588639]  dump_stack_lvl from dump_stack+0x18/0x1c&#xA;[   14.588653]  r5:c08d40b0 r4:c1003cb0&#xA;[   14.588656]  dump_stack from __warn+0x84/0xe4&#xA;[   14.588668]  __warn from warn_slowpath_fmt+0x18c/0x194&#xA;[   14.588678]  r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000&#xA;[   14.588681]  warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8&#xA;[   14.588695]  r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048&#xA;[   14.588697]  nand_reset_op from brcmnand_resume+0x13c/0x150&#xA;[   14.588714]  r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040&#xA;[   14.588717]  brcmnand_resume from platform_pm_resume+0x34/0x54&#xA;[   14.588735]  r5:00000010 r4:c0840a50&#xA;[   14.588738]  platform_pm_resume from dpm_run_callback+0x5c/0x14c&#xA;[   14.588757]  dpm_run_callback from device_resume+0xc0/0x324&#xA;[   14.588776]  r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010&#xA;[   14.588779]  device_resume from dpm_resume+0x130/0x160&#xA;[   14.588799]  r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0&#xA;[   14.588802]  dpm_resume from dpm_resume_end+0x14/0x20&#xA;[   14.588822]  r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414&#xA;[   14.588826]  r4:00000010&#xA;[   14.588828]  dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8&#xA;[   14.588848]  r5:c228a414 r4:00000000&#xA;[   14.588851]  suspend_devices_and_enter from pm_suspend+0x228/0x2bc&#xA;[   14.588868]  r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000&#xA;[   14.588871]  r4:00000003&#xA;[   14.588874]  pm_suspend from state_store+0x74/0xd0&#xA;[   14.588889]  r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003&#xA;[   14.588892]  state_store from kobj_attr_store+0x1c/0x28&#xA;[   14.588913]  r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250&#xA;[   14.588916]  kobj_attr_store from sysfs_kf_write+0x40/0x4c&#xA;[   14.588936]  r5:c3502900 r4:c0d92a48&#xA;[   14.588939]  sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0&#xA;[   14.588956]  r5:c3502900 r4:c3501f40&#xA;[   14.588960]  kernfs_fop_write_iter from vfs_write+0x250/0x420&#xA;[   14.588980]  r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00&#xA;[   14.588983]  r4:c042a88c&#xA;[   14.588987]  vfs_write from ksys_write+0x74/0xe4&#xA;[   14.589005]  r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00&#xA;[   14.589008]  r4:c34f7f00&#xA;[   14.589011]  ksys_write from sys_write+0x10/0x14&#xA;[   14.589029]  r7:00000004 r6:004421c0 r5:00443398 r4:00000004&#xA;[   14.589032]  sys_write from ret_fast_syscall+0x0/0x5c&#xA;[   14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)&#xA;[   14.589050] 9fa0:                   00000004 00443398 00000004 00443398 00000004 00000001&#xA;[   14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78&#xA;[   14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8&#xA;[   14.589065] ---[ end trace 0000000000000000 ]---&#xA;&#xA;The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when&#xA;doing PM resume operation in compliance with the controller support for single&#xA;die nand chip. Switching from nand_reset_op() to nan&#xA;---truncated---&#xA;CVE-2025-37842:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;spi: fsl-qspi: use devm function instead of driver remove&#xA;&#xA;Driver use devm APIs to manage clk/irq/resources and register the spi&#xA;controller, but the legacy remove function will be called first during&#xA;device detach and trigger kernel panic. Drop the remove function and use&#xA;devm_add_action_or_reset() for driver cleanup to ensure the release&#xA;sequence.&#xA;&#xA;Trigger kernel panic on i.MX8MQ by&#xA;echo 30bb0000.spi &gt;/sys/bus/platform/drivers/fsl-quadspi/unbind&#xA;CVE-2025-37844:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cifs: avoid NULL pointer dereference in dbg call&#xA;&#xA;cifs_server_dbg() implies server to be non-NULL so&#xA;move call under condition to avoid NULL pointer dereference.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2025-37850:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()&#xA;&#xA;With CONFIG_COMPILE_TEST &amp;&amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a&#xA;divide-by-zero in the following line:&#xA;&#xA;&#x9;do_div(resolution, clk_get_rate(pc-&gt;clk_pwms[pwm-&gt;hwpwm]));&#xA;&#xA;due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()&#xA;returns zero.&#xA;&#xA;This is presumably just a theoretical problem: COMPILE_TEST overrides&#xA;the dependency on RALINK which would select COMMON_CLK.  Regardless it&#39;s&#xA;a good idea to check for the error explicitly to avoid divide-by-zero.&#xA;&#xA;Fixes the following warning:&#xA;&#xA;  drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section&#xA;&#xA;[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]&#xA;CVE-2025-37851:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: omapfb: Add &#39;plane&#39; value check&#xA;&#xA;Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB&#xA;of the enum parameter plane.&#xA;&#xA;The value of this parameter is initialized in dss_init_overlays and in the&#xA;current state of the code it cannot take this value so it&#39;s not a real&#xA;problem.&#xA;&#xA;For the purposes of defensive coding it wouldn&#39;t be superfluous to check&#xA;the parameter value, because some functions down the call stack process&#xA;this value correctly and some not.&#xA;&#xA;For example, in dispc_ovl_setup_global_alpha it may lead to buffer&#xA;overflow.&#xA;&#xA;Add check for this value.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE static&#xA;analysis tool.&#xA;CVE-2025-37857:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: st: Fix array overflow in st_setup()&#xA;&#xA;Change the array size to follow parms size instead of a fixed value.&#xA;CVE-2025-37859:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;page_pool: avoid infinite loop to schedule delayed worker&#xA;&#xA;We noticed the kworker in page_pool_release_retry() was waken&#xA;up repeatedly and infinitely in production because of the&#xA;buggy driver causing the inflight less than 0 and warning&#xA;us in page_pool_inflight()[1].&#xA;&#xA;Since the inflight value goes negative, it means we should&#xA;not expect the whole page_pool to get back to work normally.&#xA;&#xA;This patch mitigates the adverse effect by not rescheduling&#xA;the kworker when detecting the inflight negative in&#xA;page_pool_release_retry().&#xA;&#xA;[1]&#xA;[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------&#xA;[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages&#xA;...&#xA;[Mon Feb 10 20:36:11 2025] Call Trace:&#xA;[Mon Feb 10 20:36:11 2025]  page_pool_release_retry+0x23/0x70&#xA;[Mon Feb 10 20:36:11 2025]  process_one_work+0x1b1/0x370&#xA;[Mon Feb 10 20:36:11 2025]  worker_thread+0x37/0x3a0&#xA;[Mon Feb 10 20:36:11 2025]  kthread+0x11a/0x140&#xA;[Mon Feb 10 20:36:11 2025]  ? process_one_work+0x370/0x370&#xA;[Mon Feb 10 20:36:11 2025]  ? __kthread_cancel_work+0x40/0x40&#xA;[Mon Feb 10 20:36:11 2025]  ret_from_fork+0x35/0x40&#xA;[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---&#xA;Note: before this patch, the above calltrace would flood the&#xA;dmesg due to repeated reschedule of release_dw kworker.&#xA;CVE-2025-37862:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: pidff: Fix null pointer dereference in pidff_find_fields&#xA;&#xA;This function triggered a null pointer dereference if used to search for&#xA;a report that isn&#39;t implemented on the device. This happened both for&#xA;optional and required reports alike.&#xA;&#xA;The same logic was applied to pidff_find_special_field and although&#xA;pidff_init_fields should return an error earlier if one of the required&#xA;reports is missing, future modifications could change this logic and&#xA;resurface this possible null pointer dereference again.&#xA;&#xA;LKML bug report:&#xA;https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com&#xA;CVE-2025-37867:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/core: Silence oversized kvmalloc() warning&#xA;&#xA;syzkaller triggered an oversized kvmalloc() warning.&#xA;Silence it by adding __GFP_NOWARN.&#xA;&#xA;syzkaller log:&#xA; WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180&#xA; CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6&#xA; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014&#xA; RIP: 0010:__kvmalloc_node_noprof+0x175/0x180&#xA; RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246&#xA; RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b&#xA; RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002&#xA; RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000&#xA; R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000&#xA; R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000&#xA; FS:  00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  ib_umem_odp_get+0x1f6/0x390&#xA;  mlx5_ib_reg_user_mr+0x1e8/0x450&#xA;  ib_uverbs_reg_mr+0x28b/0x440&#xA;  ib_uverbs_write+0x7d3/0xa30&#xA;  vfs_write+0x1ac/0x6c0&#xA;  ksys_write+0x134/0x170&#xA;  ? __sanitizer_cov_trace_pc+0x1c/0x50&#xA;  do_syscall_64+0x50/0x110&#xA;  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;CVE-2025-37878:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init&#xA;&#xA;Move the get_ctx(child_ctx) call and the child_event-&gt;ctx assignment to&#xA;occur immediately after the child event is allocated. Ensure that&#xA;child_event-&gt;ctx is non-NULL before any subsequent error path within&#xA;inherit_event calls free_event(), satisfying the assumptions of the&#xA;cleanup code.&#xA;&#xA;Details:&#xA;&#xA;There&#39;s no clear Fixes tag, because this bug is a side-effect of&#xA;multiple interacting commits over time (up to 15 years old), not&#xA;a single regression.&#xA;&#xA;The code initially incremented refcount then assigned context&#xA;immediately after the child_event was created. Later, an early&#xA;validity check for child_event was added before the&#xA;refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was&#xA;added, assuming event-&gt;ctx is valid if the pmu_ctx is valid.&#xA;The problem is that the WARN_ON_ONCE() could trigger after the initial&#xA;check passed but before child_event-&gt;ctx was assigned, violating its&#xA;precondition. The solution is to assign child_event-&gt;ctx right after&#xA;its initial validation. This ensures the context exists for any&#xA;subsequent checks or cleanup routines, resolving the WARN_ON_ONCE().&#xA;&#xA;To resolve it, defer the refcount update and child_event-&gt;ctx assignment&#xA;directly after child_event-&gt;pmu_ctx is set but before checking if the&#xA;parent event is orphaned. The cleanup routine depends on&#xA;event-&gt;pmu_ctx being non-NULL before it verifies event-&gt;ctx is&#xA;non-NULL. This also maintains the author&#39;s original intent of passing&#xA;in child_ctx to find_get_pmu_context before its refcount/assignment.&#xA;&#xA;[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]&#xA;CVE-2025-37892:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mtd: inftlcore: Add error check for inftl_read_oob()&#xA;&#xA;In INFTL_findwriteunit(), the return value of inftl_read_oob()&#xA;need to be checked. A proper implementation can be&#xA;found in INFTL_deleteblock(). The status will be set as&#xA;SECTOR_IGNORE to break from the while-loop correctly&#xA;if the inftl_read_oob() fails.&#xA;CVE-2025-37909:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: lan743x: Fix memleak issue when GSO enabled&#xA;&#xA;Always map the `skb` to the LS descriptor. Previously skb was&#xA;mapped to EXT descriptor when the number of fragments is zero with&#xA;GSO enabled. Mapping the skb to EXT descriptor prevents it from&#xA;being freed, leading to a memory leak&#xA;CVE-2025-37914:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: ets: Fix double list add in class with netem as child qdisc&#xA;&#xA;As described in Gerrard&#39;s report [1], there are use cases where a netem&#xA;child qdisc will make the parent qdisc&#39;s enqueue callback reentrant.&#xA;In the case of ets, there won&#39;t be a UAF, but the code will add the same&#xA;classifier to the list twice, which will cause memory corruption.&#xA;&#xA;In addition to checking for qlen being zero, this patch checks whether&#xA;the class was already added to the active_list (cl_is_active) before&#xA;doing the addition to cater for the reentrant case.&#xA;&#xA;[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/&#xA;CVE-2025-37930:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()&#xA;&#xA;Nouveau is mostly designed in a way that it&#39;s expected that fences only&#xA;ever get signaled through nouveau_fence_signal(). However, in at least&#xA;one other place, nouveau_fence_done(), can signal fences, too. If that&#xA;happens (race) a signaled fence remains in the pending list for a while,&#xA;until it gets removed by nouveau_fence_update().&#xA;&#xA;Should nouveau_fence_context_kill() run in the meantime, this would be&#xA;a bug because the function would attempt to set an error code on an&#xA;already signaled fence.&#xA;&#xA;Have nouveau_fence_context_kill() check for a fence being signaled.&#xA;CVE-2025-37932:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sch_htb: make htb_qlen_notify() idempotent&#xA;&#xA;htb_qlen_notify() always deactivates the HTB class and in fact could&#xA;trigger a warning if it is already deactivated. Therefore, it is not&#xA;idempotent and not friendly to its callers, like fq_codel_dequeue().&#xA;&#xA;Let&#39;s make it idempotent to ease qdisc_tree_reduce_backlog() callers&#39;&#xA;life.&#xA;CVE-2025-37959:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Scrub packet on bpf_redirect_peer&#xA;&#xA;When bpf_redirect_peer is used to redirect packets to a device in&#xA;another network namespace, the skb isn&#39;t scrubbed. That can lead skb&#xA;information from one namespace to be &#34;misused&#34; in another namespace.&#xA;&#xA;As one example, this is causing Cilium to drop traffic when using&#xA;bpf_redirect_peer to redirect packets that just went through IPsec&#xA;decryption to a container namespace. The following pwru trace shows (1)&#xA;the packet path from the host&#39;s XFRM layer to the container&#39;s XFRM&#xA;layer where it&#39;s dropped and (2) the number of active skb extensions at&#xA;each function.&#xA;&#xA;    NETNS       MARK  IFACE  TUPLE                                FUNC&#xA;    4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  xfrm_rcv_cb&#xA;                             .active_extensions = (__u8)2,&#xA;    4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  xfrm4_rcv_cb&#xA;                             .active_extensions = (__u8)2,&#xA;    4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  gro_cells_receive&#xA;                             .active_extensions = (__u8)2,&#xA;    [...]&#xA;    4026533547  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  skb_do_redirect&#xA;                             .active_extensions = (__u8)2,&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  ip_rcv&#xA;                             .active_extensions = (__u8)2,&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  ip_rcv_core&#xA;                             .active_extensions = (__u8)2,&#xA;    [...]&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  udp_queue_rcv_one_skb&#xA;                             .active_extensions = (__u8)2,&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  __xfrm_policy_check&#xA;                             .active_extensions = (__u8)2,&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  __xfrm_decode_session&#xA;                             .active_extensions = (__u8)2,&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  security_xfrm_decode_session&#xA;                             .active_extensions = (__u8)2,&#xA;    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)&#xA;                             .active_extensions = (__u8)2,&#xA;&#xA;In this case, there are no XFRM policies in the container&#39;s network&#xA;namespace so the drop is unexpected. When we decrypt the IPsec packet,&#xA;the XFRM state used for decryption is set in the skb extensions. This&#xA;information is preserved across the netns switch. When we reach the&#xA;XFRM policy check in the container&#39;s netns, __xfrm_policy_check drops&#xA;the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM&#xA;policy can&#39;t be found that matches the (host-side) XFRM state used for&#xA;decryption.&#xA;&#xA;This patch fixes this by scrubbing the packet when using&#xA;bpf_redirect_peer, as is done on typical netns switches via veth&#xA;devices except skb-&gt;mark and skb-&gt;tstamp are not zeroed.&#xA;CVE-2025-37961:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvs: fix uninit-value for saddr in do_output_route4&#xA;&#xA;syzbot reports for uninit-value for the saddr argument [1].&#xA;commit 4754957f04f5 (&#34;ipvs: do not use random local source address for&#xA;tunnels&#34;) already implies that the input value of saddr&#xA;should be ignored but the code is still reading it which can prevent&#xA;to connect the route. Fix it by changing the argument to ret_saddr.&#xA;&#xA;[1]&#xA;BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147&#xA; do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147&#xA; __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330&#xA; ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136&#xA; ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063&#xA; nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA; nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626&#xA; nf_hook include/linux/netfilter.h:269 [inline]&#xA; __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118&#xA; ip_local_out net/ipv4/ip_output.c:127 [inline]&#xA; ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501&#xA; udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195&#xA; udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483&#xA; inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg+0x267/0x380 net/socket.c:727&#xA; ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620&#xA; __sys_sendmmsg+0x41d/0x880 net/socket.c:2702&#xA; __compat_sys_sendmmsg net/compat.c:360 [inline]&#xA; __do_compat_sys_sendmmsg net/compat.c:367 [inline]&#xA; __se_compat_sys_sendmmsg net/compat.c:364 [inline]&#xA; __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364&#xA; ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346&#xA; do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]&#xA; __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306&#xA; do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331&#xA; do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369&#xA; entry_SYSENTER_compat_after_hwframe+0x84/0x8e&#xA;&#xA;Uninit was created at:&#xA; slab_post_alloc_hook mm/slub.c:4167 [inline]&#xA; slab_alloc_node mm/slub.c:4210 [inline]&#xA; __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367&#xA; kmalloc_noprof include/linux/slab.h:905 [inline]&#xA; ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]&#xA; __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323&#xA; ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136&#xA; ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063&#xA; nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]&#xA; nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626&#xA; nf_hook include/linux/netfilter.h:269 [inline]&#xA; __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118&#xA; ip_local_out net/ipv4/ip_output.c:127 [inline]&#xA; ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501&#xA; udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195&#xA; udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483&#xA; inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg+0x267/0x380 net/socket.c:727&#xA; ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566&#xA; ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620&#xA; __sys_sendmmsg+0x41d/0x880 net/socket.c:2702&#xA; __compat_sys_sendmmsg net/compat.c:360 [inline]&#xA; __do_compat_sys_sendmmsg net/compat.c:367 [inline]&#xA; __se_compat_sys_sendmmsg net/compat.c:364 [inline]&#xA; __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364&#xA; ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346&#xA; do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]&#xA; __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306&#xA; do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331&#xA; do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369&#xA; entry_SYSENTER_compat_after_hwframe+0x84/0x8e&#xA;&#xA;CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)&#xA;Hardware name: Google Google Compute Engi&#xA;---truncated---&#xA;CVE-2025-37967:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: typec: ucsi: displayport: Fix deadlock&#xA;&#xA;This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock&#xA;functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector&#xA;mutex is only locked if a connection is established and the partner pointer&#xA;is valid. This resolves a deadlock scenario where&#xA;ucsi_displayport_remove_partner holds con-&gt;mutex waiting for&#xA;dp_altmode_work to complete while dp_altmode_work attempts to acquire it.&#xA;CVE-2025-37969:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo&#xA;&#xA;Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in&#xA;case pattern_len is equal to zero and the device FIFO is not empty.&#xA;CVE-2025-37970:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo&#xA;&#xA;Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case&#xA;pattern_len is equal to zero and the device FIFO is not empty.&#xA;CVE-2025-37983:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;qibfs: fix _another_ leak&#xA;&#xA;failure to allocate inode =&gt; leaked dentry...&#xA;&#xA;this one had been there since the initial merge; to be fair,&#xA;if we are that far OOM, the odds of failing at that particular&#xA;allocation are low...&#xA;CVE-2025-37989:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: phy: leds: fix memory leak&#xA;&#xA;A network restart test on a router led to an out-of-memory condition,&#xA;which was traced to a memory leak in the PHY LED trigger code.&#xA;&#xA;The root cause is misuse of the devm API. The registration function&#xA;(phy_led_triggers_register) is called from phy_attach_direct, not&#xA;phy_probe, and the unregister function (phy_led_triggers_unregister)&#xA;is called from phy_detach, not phy_remove. This means the register and&#xA;unregister functions can be called multiple times for the same PHY&#xA;device, but devm-allocated memory is not freed until the driver is&#xA;unbound.&#xA;&#xA;This also prevents kmemleak from detecting the leak, as the devm API&#xA;internally stores the allocated pointer.&#xA;&#xA;Fix this by replacing devm_kzalloc/devm_kcalloc with standard&#xA;kzalloc/kcalloc, and add the corresponding kfree calls in the unregister&#xA;path.&#xA;CVE-2025-37990:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()&#xA;&#xA;The function brcmf_usb_dl_writeimage() calls the function&#xA;brcmf_usb_dl_cmd() but dose not check its return value. The&#xA;&#39;state.state&#39; and the &#39;state.bytes&#39; are uninitialized if the&#xA;function brcmf_usb_dl_cmd() fails. It is dangerous to use&#xA;uninitialized variables in the conditions.&#xA;&#xA;Add error handling for brcmf_usb_dl_cmd() to jump to error&#xA;handling path if the brcmf_usb_dl_cmd() fails and the&#xA;&#39;state.state&#39; and the &#39;state.bytes&#39; are uninitialized.&#xA;&#xA;Improve the error message to report more detailed error&#xA;information.&#xA;CVE-2025-37991:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;parisc: Fix double SIGFPE crash&#xA;&#xA;Camm noticed that on parisc a SIGFPE exception will crash an application with&#xA;a second SIGFPE in the signal handler.  Dave analyzed it, and it happens&#xA;because glibc uses a double-word floating-point store to atomically update&#xA;function descriptors. As a result of lazy binding, we hit a floating-point&#xA;store in fpe_func almost immediately.&#xA;&#xA;When the T bit is set, an assist exception trap occurs when when the&#xA;co-processor encounters *any* floating-point instruction except for a double&#xA;store of register %fr0.  The latter cancels all pending traps.  Let&#39;s fix this&#xA;by clearing the Trap (T) bit in the FP status register before returning to the&#xA;signal handler in userspace.&#xA;&#xA;The issue can be reproduced with this test program:&#xA;&#xA;root@parisc:~# cat fpe.c&#xA;&#xA;static void fpe_func(int sig, siginfo_t *i, void *v) {&#xA;        sigset_t set;&#xA;        sigemptyset(&amp;set);&#xA;        sigaddset(&amp;set, SIGFPE);&#xA;        sigprocmask(SIG_UNBLOCK, &amp;set, NULL);&#xA;        printf(&#34;GOT signal %d with si_code %ld\n&#34;, sig, i-&gt;si_code);&#xA;}&#xA;&#xA;int main() {&#xA;        struct sigaction action = {&#xA;                .sa_sigaction = fpe_func,&#xA;                .sa_flags = SA_RESTART|SA_SIGINFO };&#xA;        sigaction(SIGFPE, &amp;action, 0);&#xA;        feenableexcept(FE_OVERFLOW);&#xA;        return printf(&#34;%lf\n&#34;,1.7976931348623158E308*1.7976931348623158E308);&#xA;}&#xA;&#xA;root@parisc:~# gcc fpe.c -lm&#xA;root@parisc:~# ./a.out&#xA; Floating point exception&#xA;&#xA;root@parisc:~# strace -f ./a.out&#xA; execve(&#34;./a.out&#34;, [&#34;./a.out&#34;], 0xf9ac7034 /* 20 vars */) = 0&#xA; getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0&#xA; ...&#xA; rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0&#xA; --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---&#xA; --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---&#xA; +++ killed by SIGFPE +++&#xA; Floating point exception&#xA;CVE-2025-37998:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;openvswitch: Fix unsafe attribute parsing in output_userspace()&#xA;&#xA;This patch replaces the manual Netlink attribute iteration in&#xA;output_userspace() with nla_for_each_nested(), which ensures that only&#xA;well-formed attributes are processed.&#xA;CVE-2025-38003:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: bcm: add missing rcu read protection for procfs content&#xA;&#xA;When the procfs content is generated for a bcm_op which is in the process&#xA;to be removed the procfs output might show unreliable data (UAF).&#xA;&#xA;As the removal of bcm_op&#39;s is already implemented with rcu handling this&#xA;patch adds the missing rcu_read_lock() and makes sure the list entries&#xA;are properly removed under rcu protection.&#xA;CVE-2025-38034:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref&#xA;&#xA;btrfs_prelim_ref() calls the old and new reference variables in the&#xA;incorrect order. This causes a NULL pointer dereference because oldref&#xA;is passed as NULL to trace_btrfs_prelim_ref_insert().&#xA;&#xA;Note, trace_btrfs_prelim_ref_insert() is being called with newref as&#xA;oldref (and oldref as NULL) on purpose in order to print out&#xA;the values of newref.&#xA;&#xA;To reproduce:&#xA;echo 1 &gt; /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable&#xA;&#xA;Perform some writeback operations.&#xA;&#xA;Backtrace:&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000018&#xA; #PF: supervisor read access in kernel mode&#xA; #PF: error_code(0x0000) - not-present page&#xA; PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0&#xA; Oops: Oops: 0000 [#1] SMP NOPTI&#xA; CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary)  7ca2cef72d5e9c600f0c7718adb6462de8149622&#xA; Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014&#xA; RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130&#xA; Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 &lt;49&gt; 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88&#xA; RSP: 0018:ffffce44820077a0 EFLAGS: 00010286&#xA; RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b&#xA; RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010&#xA; RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010&#xA; R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000&#xA; R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540&#xA; FS:  00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0&#xA; PKRU: 55555554&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  prelim_ref_insert+0x1c1/0x270&#xA;  find_parent_nodes+0x12a6/0x1ee0&#xA;  ? __entry_text_end+0x101f06/0x101f09&#xA;  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;  btrfs_is_data_extent_shared+0x167/0x640&#xA;  ? fiemap_process_hole+0xd0/0x2c0&#xA;  extent_fiemap+0xa5c/0xbc0&#xA;  ? __entry_text_end+0x101f05/0x101f09&#xA;  btrfs_fiemap+0x7e/0xd0&#xA;  do_vfs_ioctl+0x425/0x9d0&#xA;  __x64_sys_ioctl+0x75/0xc0&#xA;CVE-2025-38037:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vxlan: Annotate FDB data races&#xA;&#xA;The &#39;used&#39; and &#39;updated&#39; fields in the FDB entry structure can be&#xA;accessed concurrently by multiple threads, leading to reports such as&#xA;[1]. Can be reproduced using [2].&#xA;&#xA;Suppress these reports by annotating these accesses using&#xA;READ_ONCE() / WRITE_ONCE().&#xA;&#xA;[1]&#xA;BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit&#xA;&#xA;write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:&#xA; vxlan_xmit+0xb29/0x2380&#xA; dev_hard_start_xmit+0x84/0x2f0&#xA; __dev_queue_xmit+0x45a/0x1650&#xA; packet_xmit+0x100/0x150&#xA; packet_sendmsg+0x2114/0x2ac0&#xA; __sys_sendto+0x318/0x330&#xA; __x64_sys_sendto+0x76/0x90&#xA; x64_sys_call+0x14e8/0x1c00&#xA; do_syscall_64+0x9e/0x1a0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:&#xA; vxlan_xmit+0xadf/0x2380&#xA; dev_hard_start_xmit+0x84/0x2f0&#xA; __dev_queue_xmit+0x45a/0x1650&#xA; packet_xmit+0x100/0x150&#xA; packet_sendmsg+0x2114/0x2ac0&#xA; __sys_sendto+0x318/0x330&#xA; __x64_sys_sendto+0x76/0x90&#xA; x64_sys_call+0x14e8/0x1c00&#xA; do_syscall_64+0x9e/0x1a0&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;value changed: 0x00000000fffbac6e -&gt; 0x00000000fffbac6f&#xA;&#xA;Reported by Kernel Concurrency Sanitizer on:&#xA;CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014&#xA;&#xA;[2]&#xA; #!/bin/bash&#xA;&#xA; set +H&#xA; echo whitelist &gt; /sys/kernel/debug/kcsan&#xA; echo !vxlan_xmit &gt; /sys/kernel/debug/kcsan&#xA;&#xA; ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1&#xA; bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1&#xA; taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &amp;&#xA; taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &amp;&#xA;CVE-2025-38040:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;serial: mctrl_gpio: split disable_ms into sync and no_sync APIs&#xA;&#xA;The following splat has been observed on a SAMA5D27 platform using&#xA;atmel_serial:&#xA;&#xA;BUG: sleeping function called from invalid context at kernel/irq/manage.c:738&#xA;in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0&#xA;preempt_count: 1, expected: 0&#xA;INFO: lockdep is turned off.&#xA;irq event stamp: 0&#xA;hardirqs last  enabled at (0): [&lt;00000000&gt;] 0x0&#xA;hardirqs last disabled at (0): [&lt;c01588f0&gt;] copy_process+0x1c4c/0x7bec&#xA;softirqs last  enabled at (0): [&lt;c0158944&gt;] copy_process+0x1ca0/0x7bec&#xA;softirqs last disabled at (0): [&lt;00000000&gt;] 0x0&#xA;CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74&#xA;Hardware name: Atmel SAMA5&#xA;Workqueue: hci0 hci_power_on [bluetooth]&#xA;Call trace:&#xA;  unwind_backtrace from show_stack+0x18/0x1c&#xA;  show_stack from dump_stack_lvl+0x44/0x70&#xA;  dump_stack_lvl from __might_resched+0x38c/0x598&#xA;  __might_resched from disable_irq+0x1c/0x48&#xA;  disable_irq from mctrl_gpio_disable_ms+0x74/0xc0&#xA;  mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4&#xA;  atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8&#xA;  atmel_set_termios from uart_change_line_settings+0x15c/0x994&#xA;  uart_change_line_settings from uart_set_termios+0x2b0/0x668&#xA;  uart_set_termios from tty_set_termios+0x600/0x8ec&#xA;  tty_set_termios from ttyport_set_flow_control+0x188/0x1e0&#xA;  ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]&#xA;  wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]&#xA;  hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]&#xA;  hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]&#xA;  hci_power_on [bluetooth] from process_one_work+0x998/0x1a38&#xA;  process_one_work from worker_thread+0x6e0/0xfb4&#xA;  worker_thread from kthread+0x3d4/0x484&#xA;  kthread from ret_from_fork+0x14/0x28&#xA;&#xA;This warning is emitted when trying to toggle, at the highest level,&#xA;some flow control (with serdev_device_set_flow_control) in a device&#xA;driver. At the lowest level, the atmel_serial driver is using&#xA;serial_mctrl_gpio lib to enable/disable the corresponding IRQs&#xA;accordingly.  The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to&#xA;disable_irq (called in mctrl_gpio_disable_ms) being possibly called in&#xA;some atomic context (some tty drivers perform modem lines configuration&#xA;in regions protected by port lock).&#xA;&#xA;Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one&#xA;and a blocking one. Replace mctrl_gpio_disable_ms calls with the&#xA;relevant version depending on whether the call is protected by some port&#xA;lock.&#xA;CVE-2025-38044:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: cx231xx: set device_caps for 417&#xA;&#xA;The video_device for the MPEG encoder did not set device_caps.&#xA;&#xA;Add this, otherwise the video device can&#39;t be registered (you get a&#xA;WARN_ON instead).&#xA;&#xA;Not seen before since currently 417 support is disabled, but I found&#xA;this while experimenting with it.&#xA;CVE-2025-38057:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;espintcp: fix skb leaks&#xA;&#xA;A few error paths are missing a kfree_skb.&#xA;CVE-2025-38058:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock&#xA;&#xA;... or we risk stealing final mntput from sync umount - raising mnt_count&#xA;after umount(2) has verified that victim is not busy, but before it&#xA;has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn&#39;t see&#xA;that it&#39;s safe to quietly undo mnt_count increment and leaves dropping&#xA;the reference to caller, where it&#39;ll be a full-blown mntput().&#xA;&#xA;Check under mount_lock is needed; leaving the current one done before&#xA;taking that makes no sense - it&#39;s nowhere near common enough to bother&#xA;with.&#xA;CVE-2025-38061:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: pktgen: fix access outside of user given buffer in pktgen_thread_write()&#xA;&#xA;Honour the user given buffer size for the strn_len() calls (otherwise&#xA;strn_len() will access memory outside of the user given buffer).&#xA;CVE-2025-38066:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm cache: prevent BUG_ON by blocking retries on failed device resumes&#xA;&#xA;A cache device failing to resume due to mapping errors should not be&#xA;retried, as the failure leaves a partially initialized policy object.&#xA;Repeating the resume operation risks triggering BUG_ON when reloading&#xA;cache mappings into the incomplete policy object.&#xA;&#xA;Reproduce steps:&#xA;&#xA;1. create a cache metadata consisting of 512 or more cache blocks,&#xA;   with some mappings stored in the first array block of the mapping&#xA;   array. Here we use cache_restore v1.0 to build the metadata.&#xA;&#xA;cat &lt;&lt;EOF &gt;&gt; cmeta.xml&#xA;&lt;superblock uuid=&#34;&#34; block_size=&#34;128&#34; nr_cache_blocks=&#34;512&#34; \&#xA;policy=&#34;smq&#34; hint_width=&#34;4&#34;&gt;&#xA;  &lt;mappings&gt;&#xA;    &lt;mapping cache_block=&#34;0&#34; origin_block=&#34;0&#34; dirty=&#34;false&#34;/&gt;&#xA;  &lt;/mappings&gt;&#xA;&lt;/superblock&gt;&#xA;EOF&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2&#xA;dmsetup remove cmeta&#xA;&#xA;2. wipe the second array block of the mapping array to simulate&#xA;   data degradations.&#xA;&#xA;mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \&#xA;2&gt;/dev/null | hexdump -e &#39;1/8 &#34;%u\n&#34;&#39;)&#xA;ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \&#xA;2&gt;/dev/null | hexdump -e &#39;1/8 &#34;%u\n&#34;&#39;)&#xA;dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock&#xA;&#xA;3. try bringing up the cache device. The resume is expected to fail&#xA;   due to the broken array block.&#xA;&#xA;dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;&#xA;dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;&#xA;dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34;&#xA;dmsetup create cache --notable&#xA;dmsetup load cache --table &#34;0 524288 cache /dev/mapper/cmeta \&#xA;/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;&#xA;dmsetup resume cache&#xA;&#xA;4. try resuming the cache again. An unexpected BUG_ON is triggered&#xA;   while loading cache mappings.&#xA;&#xA;dmsetup resume cache&#xA;&#xA;Kernel logs:&#xA;&#xA;(snip)&#xA;------------[ cut here ]------------&#xA;kernel BUG at drivers/md/dm-cache-policy-smq.c:752!&#xA;Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3&#xA;RIP: 0010:smq_load_mapping+0x3e5/0x570&#xA;&#xA;Fix by disallowing resume operations for devices that failed the&#xA;initial attempt.&#xA;CVE-2025-38075:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: iscsi: Fix timeout on deleted connection&#xA;&#xA;NOPIN response timer may expire on a deleted connection and crash with&#xA;such logs:&#xA;&#xA;Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d&#xA;&#xA;BUG: Kernel NULL pointer dereference on read at 0x00000000&#xA;NIP  strlcpy+0x8/0xb0&#xA;LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]&#xA;Call Trace:&#xA; iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod]&#xA; call_timer_fn+0x58/0x1f0&#xA; run_timer_softirq+0x740/0x860&#xA; __do_softirq+0x16c/0x420&#xA; irq_exit+0x188/0x1c0&#xA; timer_interrupt+0x184/0x410&#xA;&#xA;That is because nopin response timer may be re-started on nopin timer&#xA;expiration.&#xA;&#xA;Stop nopin timer before stopping the nopin response timer to be sure&#xA;that no one of them will be re-started.&#xA;CVE-2025-38083:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: prio: fix a race in prio_tune()&#xA;&#xA;Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer&#xA;fires at the wrong time.&#xA;&#xA;The race is as follows:&#xA;&#xA;CPU 0                                 CPU 1&#xA;[1]: lock root&#xA;[2]: qdisc_tree_flush_backlog()&#xA;[3]: unlock root&#xA; |&#xA; |                                    [5]: lock root&#xA; |                                    [6]: rehash&#xA; |                                    [7]: qdisc_tree_reduce_backlog()&#xA; |&#xA;[4]: qdisc_put()&#xA;&#xA;This can be abused to underflow a parent&#39;s qlen.&#xA;&#xA;Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()&#xA;should fix the race, because all packets will be purged from the qdisc&#xA;before releasing the lock.&#xA;CVE-2025-38094:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: cadence: macb: Fix a possible deadlock in macb_halt_tx.&#xA;&#xA;There is a situation where after THALT is set high, TGO stays high as&#xA;well. Because jiffies are never updated, as we are in a context with&#xA;interrupts disabled, we never exit that loop and have a deadlock.&#xA;&#xA;That deadlock was noticed on a sama5d4 device that stayed locked for days.&#xA;&#xA;Use retries instead of jiffies so that the timeout really works and we do&#xA;not have a deadlock anymore.&#xA;CVE-2025-38100:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/iopl: Cure TIF_IO_BITMAP inconsistencies&#xA;&#xA;io_bitmap_exit() is invoked from exit_thread() when a task exists or&#xA;when a fork fails. In the latter case the exit_thread() cleans up&#xA;resources which were allocated during fork().&#xA;&#xA;io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up&#xA;in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the&#xA;current task. If current has TIF_IO_BITMAP set, but no bitmap installed,&#xA;tss_update_io_bitmap() crashes with a NULL pointer dereference.&#xA;&#xA;There are two issues, which lead to that problem:&#xA;&#xA;  1) io_bitmap_exit() should not invoke task_update_io_bitmap() when&#xA;     the task, which is cleaned up, is not the current task. That&#39;s a&#xA;     clear indicator for a cleanup after a failed fork().&#xA;&#xA;  2) A task should not have TIF_IO_BITMAP set and neither a bitmap&#xA;     installed nor IOPL emulation level 3 activated.&#xA;&#xA;     This happens when a kernel thread is created in the context of&#xA;     a user space thread, which has TIF_IO_BITMAP set as the thread&#xA;     flags are copied and the IO bitmap pointer is cleared.&#xA;&#xA;     Other than in the failed fork() case this has no impact because&#xA;     kernel threads including IO workers never return to user space and&#xA;     therefore never invoke tss_update_io_bitmap().&#xA;&#xA;Cure this by adding the missing cleanups and checks:&#xA;&#xA;  1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if&#xA;     the to be cleaned up task is not the current task.&#xA;&#xA;  2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user&#xA;     space forks it is set later, when the IO bitmap is inherited in&#xA;     io_bitmap_share().&#xA;&#xA;For paranoia sake, add a warning into tss_update_io_bitmap() to catch&#xA;the case, when that code is invoked with inconsistent state.&#xA;CVE-2025-38107:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: ets: fix a race in ets_qdisc_change()&#xA;&#xA;Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer&#xA;fires at the wrong time.&#xA;&#xA;The race is as follows:&#xA;&#xA;CPU 0                                 CPU 1&#xA;[1]: lock root&#xA;[2]: qdisc_tree_flush_backlog()&#xA;[3]: unlock root&#xA; |&#xA; |                                    [5]: lock root&#xA; |                                    [6]: rehash&#xA; |                                    [7]: qdisc_tree_reduce_backlog()&#xA; |&#xA;[4]: qdisc_put()&#xA;&#xA;This can be abused to underflow a parent&#39;s qlen.&#xA;&#xA;Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()&#xA;should fix the race, because all packets will be purged from the qdisc&#xA;before releasing the lock.&#xA;CVE-2025-38120:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_set_pipapo_avx2: fix initial map fill&#xA;&#xA;If the first field doesn&#39;t cover the entire start map, then we must zero&#xA;out the remainder, else we leak those bits into the next match round map.&#xA;&#xA;The early fix was incomplete and did only fix up the generic C&#xA;implementation.&#xA;&#xA;A followup patch adds a test case to nft_concat_range.sh.&#xA;CVE-2025-38147:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;calipso: Don&#39;t call calipso functions for AF_INET sk.&#xA;&#xA;syzkaller reported a null-ptr-deref in txopt_get(). [0]&#xA;&#xA;The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,&#xA;so struct ipv6_pinfo was NULL there.&#xA;&#xA;However, this never happens for IPv6 sockets as inet_sk(sk)-&gt;pinet6&#xA;is always set in inet6_create(), meaning the socket was not IPv6 one.&#xA;&#xA;The root cause is missing validation in netlbl_conn_setattr().&#xA;&#xA;netlbl_conn_setattr() switches branches based on struct&#xA;sockaddr.sa_family, which is passed from userspace.  However,&#xA;netlbl_conn_setattr() does not check if the address family matches&#xA;the socket.&#xA;&#xA;The syzkaller must have called connect() for an IPv6 address on&#xA;an IPv4 socket.&#xA;&#xA;We have a proper validation in tcp_v[46]_connect(), but&#xA;security_socket_connect() is called in the earlier stage.&#xA;&#xA;Let&#39;s copy the validation to netlbl_conn_setattr().&#xA;&#xA;[0]:&#xA;Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]&#xA;CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]&#xA;RIP: 0010:&#xA;Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00&#xA;RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212&#xA;RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c&#xA;RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070&#xA;RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e&#xA;R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00&#xA;R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80&#xA;FS:  00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0&#xA;PKRU: 80000000&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557&#xA; netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177&#xA; selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569&#xA; selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline]&#xA; selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615&#xA; selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931&#xA; security_socket_connect+0x50/0xa0 security/security.c:4598&#xA; __sys_connect_file+0xa4/0x190 net/socket.c:2067&#xA; __sys_connect+0x12c/0x170 net/socket.c:2088&#xA; __do_sys_connect net/socket.c:2098 [inline]&#xA; __se_sys_connect net/socket.c:2095 [inline]&#xA; __x64_sys_connect+0x73/0xb0 net/socket.c:2095&#xA; do_syscall_x64 arch/x86/entry/common.c:52 [inline]&#xA; do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f901b61a12d&#xA;Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a&#xA;RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d&#xA;RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003&#xA;RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000&#xA; &lt;/TASK&gt;&#xA;Modules linked in:&#xA;CVE-2025-38153:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: aqc111: fix error handling of usbnet read calls&#xA;&#xA;Syzkaller, courtesy of syzbot, identified an error (see report [1]) in&#xA;aqc111 driver, caused by incomplete sanitation of usb read calls&#39;&#xA;results. This problem is quite similar to the one fixed in commit&#xA;920a9fa27e78 (&#34;net: asix: add proper error handling of usb read errors&#34;).&#xA;&#xA;For instance, usbnet_read_cmd() may read fewer than &#39;size&#39; bytes,&#xA;even if the caller expected the full amount, and aqc111_read_cmd()&#xA;will not check its result properly. As [1] shows, this may lead&#xA;to MAC address in aqc111_bind() being only partly initialized,&#xA;triggering KMSAN warnings.&#xA;&#xA;Fix the issue by verifying that the number of bytes read is&#xA;as expected and not less.&#xA;&#xA;[1] Partial syzbot report:&#xA;BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline]&#xA;BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830&#xA; is_valid_ether_addr include/linux/etherdevice.h:208 [inline]&#xA; usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830&#xA; usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396&#xA; call_driver_probe drivers/base/dd.c:-1 [inline]&#xA; really_probe+0x4d1/0xd90 drivers/base/dd.c:658&#xA; __driver_probe_device+0x268/0x380 drivers/base/dd.c:800&#xA;...&#xA;&#xA;Uninit was stored to memory at:&#xA; dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582&#xA; __dev_addr_set include/linux/netdevice.h:4874 [inline]&#xA; eth_hw_addr_set include/linux/etherdevice.h:325 [inline]&#xA; aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717&#xA; usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772&#xA; usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396&#xA;...&#xA;&#xA;Uninit was stored to memory at:&#xA; ether_addr_copy include/linux/etherdevice.h:305 [inline]&#xA; aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline]&#xA; aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713&#xA; usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772&#xA; usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396&#xA; call_driver_probe drivers/base/dd.c:-1 [inline]&#xA;...&#xA;&#xA;Local variable buf.i created at:&#xA; aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline]&#xA; aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713&#xA; usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772&#xA;CVE-2025-38161:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction&#xA;&#xA;Upon RQ destruction if the firmware command fails which is the&#xA;last resource to be destroyed some SW resources were already cleaned&#xA;regardless of the failure.&#xA;&#xA;Now properly rollback the object to its original state upon such failure.&#xA;&#xA;In order to avoid a use-after free in case someone tries to destroy the&#xA;object again, which results in the following kernel trace:&#xA;refcount_t: underflow; use-after-free.&#xA;WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148&#xA;Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)&#xA;CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G           OE     -------  ---  6.12.0-54.el10.aarch64 #1&#xA;Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE&#xA;Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015&#xA;pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : refcount_warn_saturate+0xf4/0x148&#xA;lr : refcount_warn_saturate+0xf4/0x148&#xA;sp : ffff80008b81b7e0&#xA;x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001&#xA;x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00&#xA;x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000&#xA;x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006&#xA;x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f&#xA;x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78&#xA;x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90&#xA;x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff&#xA;x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000&#xA;x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600&#xA;Call trace:&#xA; refcount_warn_saturate+0xf4/0x148&#xA; mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib]&#xA; mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib]&#xA; mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib]&#xA; ib_destroy_wq_user+0x30/0xc0 [ib_core]&#xA; uverbs_free_wq+0x28/0x58 [ib_uverbs]&#xA; destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs]&#xA; uverbs_destroy_uobject+0x48/0x240 [ib_uverbs]&#xA; __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs]&#xA; uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs]&#xA; ib_uverbs_close+0x2c/0x100 [ib_uverbs]&#xA; __fput+0xd8/0x2f0&#xA; __fput_sync+0x50/0x70&#xA; __arm64_sys_close+0x40/0x90&#xA; invoke_syscall.constprop.0+0x74/0xd0&#xA; do_el0_svc+0x48/0xe8&#xA; el0_svc+0x44/0x1d0&#xA; el0t_64_sync_handler+0x120/0x130&#xA; el0t_64_sync+0x1a4/0x1a8&#xA;CVE-2025-38163:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;f2fs: fix to do sanity check on sbi-&gt;total_valid_block_count&#xA;&#xA;syzbot reported a f2fs bug as below:&#xA;&#xA;------------[ cut here ]------------&#xA;kernel BUG at fs/f2fs/f2fs.h:2521!&#xA;RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521&#xA;Call Trace:&#xA; f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695&#xA; truncate_dnode+0x417/0x740 fs/f2fs/node.c:973&#xA; truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014&#xA; f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197&#xA; f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810&#xA; f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838&#xA; f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888&#xA; f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112&#xA; notify_change+0xbca/0xe90 fs/attr.c:552&#xA; do_truncate+0x222/0x310 fs/open.c:65&#xA; handle_truncate fs/namei.c:3466 [inline]&#xA; do_open fs/namei.c:3849 [inline]&#xA; path_openat+0x2e4f/0x35d0 fs/namei.c:4004&#xA; do_filp_open+0x284/0x4e0 fs/namei.c:4031&#xA; do_sys_openat2+0x12b/0x1d0 fs/open.c:1429&#xA; do_sys_open fs/open.c:1444 [inline]&#xA; __do_sys_creat fs/open.c:1522 [inline]&#xA; __se_sys_creat fs/open.c:1516 [inline]&#xA; __x64_sys_creat+0x124/0x170 fs/open.c:1516&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94&#xA;&#xA;The reason is: in fuzzed image, sbi-&gt;total_valid_block_count is&#xA;inconsistent w/ mapped blocks indexed by inode, so, we should&#xA;not trigger panic for such case, instead, let&#39;s print log and&#xA;set fsck flag.&#xA;CVE-2025-38166:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: fix ktls panic with sockmap&#xA;&#xA;[ 2172.936997] ------------[ cut here ]------------&#xA;[ 2172.936999] kernel BUG at lib/iov_iter.c:629!&#xA;......&#xA;[ 2172.944996] PKRU: 55555554&#xA;[ 2172.945155] Call Trace:&#xA;[ 2172.945299]  &lt;TASK&gt;&#xA;[ 2172.945428]  ? die+0x36/0x90&#xA;[ 2172.945601]  ? do_trap+0xdd/0x100&#xA;[ 2172.945795]  ? iov_iter_revert+0x178/0x180&#xA;[ 2172.946031]  ? iov_iter_revert+0x178/0x180&#xA;[ 2172.946267]  ? do_error_trap+0x7d/0x110&#xA;[ 2172.946499]  ? iov_iter_revert+0x178/0x180&#xA;[ 2172.946736]  ? exc_invalid_op+0x50/0x70&#xA;[ 2172.946961]  ? iov_iter_revert+0x178/0x180&#xA;[ 2172.947197]  ? asm_exc_invalid_op+0x1a/0x20&#xA;[ 2172.947446]  ? iov_iter_revert+0x178/0x180&#xA;[ 2172.947683]  ? iov_iter_revert+0x5c/0x180&#xA;[ 2172.947913]  tls_sw_sendmsg_locked.isra.0+0x794/0x840&#xA;[ 2172.948206]  tls_sw_sendmsg+0x52/0x80&#xA;[ 2172.948420]  ? inet_sendmsg+0x1f/0x70&#xA;[ 2172.948634]  __sys_sendto+0x1cd/0x200&#xA;[ 2172.948848]  ? find_held_lock+0x2b/0x80&#xA;[ 2172.949072]  ? syscall_trace_enter+0x140/0x270&#xA;[ 2172.949330]  ? __lock_release.isra.0+0x5e/0x170&#xA;[ 2172.949595]  ? find_held_lock+0x2b/0x80&#xA;[ 2172.949817]  ? syscall_trace_enter+0x140/0x270&#xA;[ 2172.950211]  ? lockdep_hardirqs_on_prepare+0xda/0x190&#xA;[ 2172.950632]  ? ktime_get_coarse_real_ts64+0xc2/0xd0&#xA;[ 2172.951036]  __x64_sys_sendto+0x24/0x30&#xA;[ 2172.951382]  do_syscall_64+0x90/0x170&#xA;......&#xA;&#xA;After calling bpf_exec_tx_verdict(), the size of msg_pl-&gt;sg may increase,&#xA;e.g., when the BPF program executes bpf_msg_push_data().&#xA;&#xA;If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,&#xA;it will return -ENOSPC and attempt to roll back to the non-zero copy&#xA;logic. However, during rollback, msg-&gt;msg_iter is reset, but since&#xA;msg_pl-&gt;sg.size has been increased, subsequent executions will exceed the&#xA;actual size of msg_iter.&#xA;&#39;&#39;&#39;&#xA;iov_iter_revert(&amp;msg-&gt;msg_iter, msg_pl-&gt;sg.size - orig_size);&#xA;&#39;&#39;&#39;&#xA;&#xA;The changes in this commit are based on the following considerations:&#xA;&#xA;1. When cork_bytes is set, rolling back to non-zero copy logic is&#xA;pointless and can directly go to zero-copy logic.&#xA;&#xA;2. We can not calculate the correct number of bytes to revert msg_iter.&#xA;&#xA;Assume the original data is &#34;abcdefgh&#34; (8 bytes), and after 3 pushes&#xA;by the BPF program, it becomes 11-byte data: &#34;abc?de?fgh?&#34;.&#xA;Then, we set cork_bytes to 6, which means the first 6 bytes have been&#xA;processed, and the remaining 5 bytes &#34;?fgh?&#34; will be cached until the&#xA;length meets the cork_bytes requirement.&#xA;&#xA;However, some data in &#34;?fgh?&#34; is not within &#39;sg-&gt;msg_iter&#39;&#xA;(but in msg_pl instead), especially the data &#34;?&#34; we pushed.&#xA;&#xA;So it doesn&#39;t seem as simple as just reverting through an offset of&#xA;msg_iter.&#xA;&#xA;3. For non-TLS sockets in tcp_bpf_sendmsg, when a &#34;cork&#34; situation occurs,&#xA;the user-space send() doesn&#39;t return an error, and the returned length is&#xA;the same as the input length parameter, even if some data is cached.&#xA;&#xA;Additionally, I saw that the current non-zero-copy logic for handling&#xA;corking is written as:&#xA;&#39;&#39;&#39;&#xA;line 1177&#xA;else if (ret != -EAGAIN) {&#xA;&#x9;if (ret == -ENOSPC)&#xA;&#x9;&#x9;ret = 0;&#xA;&#x9;goto send_end;&#xA;&#39;&#39;&#39;&#xA;&#xA;So it&#39;s ok to just return &#39;copied&#39; without error when a &#34;cork&#34; situation&#xA;occurs.&#xA;CVE-2025-38167:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fs/ntfs3: handle hdr_first_de() return value&#xA;&#xA;The hdr_first_de() function returns a pointer to a struct NTFS_DE. This&#xA;pointer may be NULL. To handle the NULL error effectively, it is important&#xA;to implement an error handler. This will help manage potential errors&#xA;consistently.&#xA;&#xA;Additionally, error handling for the return value already exists at other&#xA;points where this function is called.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with SVACE.&#xA;CVE-2025-38190:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: Revert atm_account_tx() if copy_from_iter_full() fails.&#xA;&#xA;In vcc_sendmsg(), we account skb-&gt;truesize to sk-&gt;sk_wmem_alloc by&#xA;atm_account_tx().&#xA;&#xA;It is expected to be reverted by atm_pop_raw() later called by&#xA;vcc-&gt;dev-&gt;ops-&gt;send(vcc, skb).&#xA;&#xA;However, vcc_sendmsg() misses the same revert when copy_from_iter_full()&#xA;fails, and then we will leak a socket.&#xA;&#xA;Let&#39;s factorise the revert part as atm_return_tx() and call it in&#xA;the failure path.&#xA;&#xA;Note that the corresponding sk_wmem_alloc operation can be found in&#xA;alloc_tx() as of the blamed commit.&#xA;&#xA;  $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~&#xA;CVE-2025-38197:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;platform/x86: dell_rbu: Fix list usage&#xA;&#xA;Pass the correct list head to list_for_each_entry*() when looping through&#xA;the packet list.&#xA;&#xA;Without this patch, reading the packet data via sysfs will show the data&#xA;incorrectly (because it starts at the wrong packet), and clearing the&#xA;packet list will result in a NULL pointer dereference.&#xA;CVE-2025-38200:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: fix MMIO write access to an invalid page in i40e_clear_hw&#xA;&#xA;When the device sends a specific input, an integer underflow can occur, leading&#xA;to MMIO write access to an invalid page.&#xA;&#xA;Prevent the integer underflow by changing the type of related variables.&#xA;CVE-2025-38206:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;exfat: fix double free in delayed_free&#xA;&#xA;The double free could happen in the following path.&#xA;&#xA;exfat_create_upcase_table()&#xA;        exfat_create_upcase_table() : return error&#xA;        exfat_free_upcase_table() : free -&gt;vol_utbl&#xA;        exfat_load_default_upcase_table : return error&#xA;     exfat_kill_sb()&#xA;           delayed_free()&#xA;                  exfat_free_upcase_table() &lt;--------- double free&#xA;This patch set -&gt;vol_util as NULL after freeing it.&#xA;CVE-2025-38214:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var&#xA;&#xA;If fb_add_videomode() in fb_set_var() fails to allocate memory for&#xA;fb_videomode, later it may lead to a null-ptr dereference in&#xA;fb_videomode_to_var(), as the fb_info is registered while not having the&#xA;mode in modelist that is expected to be there, i.e. the one that is&#xA;described in fb_info-&gt;var.&#xA;&#xA;================================================================&#xA;general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]&#xA;CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014&#xA;RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901&#xA;Call Trace:&#xA; display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929&#xA; fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071&#xA; resize_screen drivers/tty/vt/vt.c:1176 [inline]&#xA; vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263&#xA; fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720&#xA; fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776&#xA; do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128&#xA; fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203&#xA; vfs_ioctl fs/ioctl.c:48 [inline]&#xA; __do_sys_ioctl fs/ioctl.c:753 [inline]&#xA; __se_sys_ioctl fs/ioctl.c:739 [inline]&#xA; __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739&#xA; do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46&#xA; entry_SYSCALL_64_after_hwframe+0x67/0xd1&#xA;================================================================&#xA;&#xA;The reason is that fb_info-&gt;var is being modified in fb_set_var(), and&#xA;then fb_videomode_to_var() is called. If it fails to add the mode to&#xA;fb_info-&gt;modelist, fb_set_var() returns error, but does not restore the&#xA;old value of fb_info-&gt;var. Restore fb_info-&gt;var on failure the same way&#xA;it is done earlier in the function.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Syzkaller.&#xA;CVE-2025-38237:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode()&#xA;&#xA;In fimc_is_hw_change_mode(), the function changes camera modes without&#xA;waiting for hardware completion, risking corrupted data or system hangs&#xA;if subsequent operations proceed before the hardware is ready.&#xA;&#xA;Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuring&#xA;hardware state synchronization and stable interrupt handling.&#xA;CVE-2025-38249:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()&#xA;&#xA;In snd_usb_get_audioformat_uac3(), the length value returned from&#xA;snd_usb_ctl_msg() is used directly for memory allocation without&#xA;validation. This length is controlled by the USB device.&#xA;&#xA;The allocated buffer is cast to a uac3_cluster_header_descriptor&#xA;and its fields are accessed without verifying that the buffer&#xA;is large enough. If the device returns a smaller than expected&#xA;length, this leads to an out-of-bounds read.&#xA;&#xA;Add a length check to ensure the buffer is large enough for&#xA;uac3_cluster_header_descriptor.&#xA;CVE-2025-38251:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: clip: prevent NULL deref in clip_push()&#xA;&#xA;Blamed commit missed that vcc_destroy_socket() calls&#xA;clip_push() with a NULL skb.&#xA;&#xA;If clip_devs is NULL, clip_push() then crashes when reading&#xA;skb-&gt;truesize.&#xA;CVE-2025-38312:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()&#xA;&#xA;In fb_find_mode_cvt(), iff mode-&gt;refresh somehow happens to be 0x80000000,&#xA;cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It&#39;s&#xA;then passed to fb_cvt_hperiod(), where it&#39;s used as a divider -- division&#xA;by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to&#xA;avoid such overflow...&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with the Svace static&#xA;analysis tool.&#xA;CVE-2025-38326:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;aoe: clean device rq_list in aoedev_downdev()&#xA;&#xA;An aoe device&#39;s rq_list contains accepted block requests that are&#xA;waiting to be transmitted to the aoe target. This queue was added as&#xA;part of the conversion to blk_mq. However, the queue was not cleaned out&#xA;when an aoe device is downed which caused blk_mq_freeze_queue() to sleep&#xA;indefinitely waiting for those requests to complete, causing a hang. This&#xA;fix cleans out the queue before calling blk_mq_freeze_queue().&#xA;CVE-2025-38334:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;x86/sgx: Prevent attempts to reclaim poisoned pages&#xA;&#xA;TL;DR: SGX page reclaim touches the page to copy its contents to&#xA;secondary storage. SGX instructions do not gracefully handle machine&#xA;checks. Despite this, the existing SGX code will try to reclaim pages&#xA;that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.&#xA;&#xA;The longer story:&#xA;&#xA;Pages used by an enclave only get epc_page-&gt;poison set in&#xA;arch_memory_failure() but they currently stay on sgx_active_page_list until&#xA;sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.&#xA;&#xA;epc_page-&gt;poison is not checked in the reclaimer logic meaning that, if other&#xA;conditions are met, an attempt will be made to reclaim an EPC page that was&#xA;poisoned.  This is bad because 1. we don&#39;t want that page to end up added&#xA;to another enclave and 2. it is likely to cause one core to shut down&#xA;and the kernel to panic.&#xA;&#xA;Specifically, reclaiming uses microcode operations including &#34;EWB&#34; which&#xA;accesses the EPC page contents to encrypt and write them out to non-SGX&#xA;memory.  Those operations cannot handle MCEs in their accesses other than&#xA;by putting the executing core into a special shutdown state (affecting&#xA;both threads with HT.)  The kernel will subsequently panic on the&#xA;remaining cores seeing the core didn&#39;t enter MCE handler(s) in time.&#xA;&#xA;Call sgx_unmark_page_reclaimable() to remove the affected EPC page from&#xA;sgx_active_page_list on memory error to stop it being considered for&#xA;reclaiming.&#xA;&#xA;Testing epc_page-&gt;poison in sgx_reclaim_pages() would also work but I assume&#xA;it&#39;s better to add code in the less likely paths.&#xA;&#xA;The affected EPC page is not added to &amp;node-&gt;sgx_poison_page_list until&#xA;later in sgx_encl_release()-&gt;sgx_free_epc_page() when it is EREMOVEd.&#xA;Membership on other lists doesn&#39;t change to avoid changing any of the&#xA;lists&#39; semantics except for sgx_active_page_list.  There&#39;s a &#34;TBD&#34; comment&#xA;in arch_memory_failure() about pre-emptive actions, the goal here is not&#xA;to address everything that it may imply.&#xA;&#xA;This also doesn&#39;t completely close the time window when a memory error&#xA;notification will be fatal (for a not previously poisoned EPC page) --&#xA;the MCE can happen after sgx_reclaim_pages() has selected its candidates&#xA;or even *inside* a microcode operation (actually easy to trigger due to&#xA;the amount of time spent in them.)&#xA;&#xA;The spinlock in sgx_unmark_page_reclaimable() is safe because&#xA;memory_failure() runs in process context and no spinlocks are held,&#xA;explicitly noted in a mm/memory-failure.c comment.&#xA;CVE-2025-38344:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPICA: fix acpi parse and parseext cache leaks&#xA;&#xA;ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5&#xA;&#xA;I&#39;m Seunghun Han, and I work for National Security Research Institute of&#xA;South Korea.&#xA;&#xA;I have been doing a research on ACPI and found an ACPI cache leak in ACPI&#xA;early abort cases.&#xA;&#xA;Boot log of ACPI cache leak is as follows:&#xA;[    0.352414] ACPI: Added _OSI(Module Device)&#xA;[    0.353182] ACPI: Added _OSI(Processor Device)&#xA;[    0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)&#xA;[    0.353182] ACPI: Added _OSI(Processor Aggregator Device)&#xA;[    0.356028] ACPI: Unable to start the ACPI Interpreter&#xA;[    0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)&#xA;[    0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects&#xA;[    0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W&#xA;4.12.0-rc4-next-20170608+ #10&#xA;[    0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS&#xA;virtual_box 12/01/2006&#xA;[    0.361873] Call Trace:&#xA;[    0.362243]  ? dump_stack+0x5c/0x81&#xA;[    0.362591]  ? kmem_cache_destroy+0x1aa/0x1c0&#xA;[    0.362944]  ? acpi_sleep_proc_init+0x27/0x27&#xA;[    0.363296]  ? acpi_os_delete_cache+0xa/0x10&#xA;[    0.363646]  ? acpi_ut_delete_caches+0x6d/0x7b&#xA;[    0.364000]  ? acpi_terminate+0xa/0x14&#xA;[    0.364000]  ? acpi_init+0x2af/0x34f&#xA;[    0.364000]  ? __class_create+0x4c/0x80&#xA;[    0.364000]  ? video_setup+0x7f/0x7f&#xA;[    0.364000]  ? acpi_sleep_proc_init+0x27/0x27&#xA;[    0.364000]  ? do_one_initcall+0x4e/0x1a0&#xA;[    0.364000]  ? kernel_init_freeable+0x189/0x20a&#xA;[    0.364000]  ? rest_init+0xc0/0xc0&#xA;[    0.364000]  ? kernel_init+0xa/0x100&#xA;[    0.364000]  ? ret_from_fork+0x25/0x30&#xA;&#xA;I analyzed this memory leak in detail. I found that “Acpi-State” cache and&#xA;“Acpi-Parse” cache were merged because the size of cache objects was same&#xA;slab cache size.&#xA;&#xA;I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked&#xA;using SLAB_NEVER_MERGE flag in kmem_cache_create() function.&#xA;&#xA;Real ACPI cache leak point is as follows:&#xA;[    0.360101] ACPI: Added _OSI(Module Device)&#xA;[    0.360101] ACPI: Added _OSI(Processor Device)&#xA;[    0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)&#xA;[    0.361043] ACPI: Added _OSI(Processor Aggregator Device)&#xA;[    0.364016] ACPI: Unable to start the ACPI Interpreter&#xA;[    0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)&#xA;[    0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects&#xA;[    0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W&#xA;4.12.0-rc4-next-20170608+ #8&#xA;[    0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS&#xA;virtual_box 12/01/2006&#xA;[    0.372000] Call Trace:&#xA;[    0.372000]  ? dump_stack+0x5c/0x81&#xA;[    0.372000]  ? kmem_cache_destroy+0x1aa/0x1c0&#xA;[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27&#xA;[    0.372000]  ? acpi_os_delete_cache+0xa/0x10&#xA;[    0.372000]  ? acpi_ut_delete_caches+0x56/0x7b&#xA;[    0.372000]  ? acpi_terminate+0xa/0x14&#xA;[    0.372000]  ? acpi_init+0x2af/0x34f&#xA;[    0.372000]  ? __class_create+0x4c/0x80&#xA;[    0.372000]  ? video_setup+0x7f/0x7f&#xA;[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27&#xA;[    0.372000]  ? do_one_initcall+0x4e/0x1a0&#xA;[    0.372000]  ? kernel_init_freeable+0x189/0x20a&#xA;[    0.372000]  ? rest_init+0xc0/0xc0&#xA;[    0.372000]  ? kernel_init+0xa/0x100&#xA;[    0.372000]  ? ret_from_fork+0x25/0x30&#xA;[    0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects&#xA;[    0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W&#xA;4.12.0-rc4-next-20170608+ #8&#xA;[    0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS&#xA;virtual_box 12/01/2006&#xA;[    0.392000] Call Trace:&#xA;[    0.392000]  ? dump_stack+0x5c/0x81&#xA;[    0.392000]  ? kmem_cache_destroy+0x1aa/0x1c0&#xA;[    0.392000]  ? acpi_sleep_proc_init+0x27/0x27&#xA;[    0.392000]  ? acpi_os_delete_cache+0xa/0x10&#xA;[    0.392000]  ? acpi_ut_delete_caches+0x6d/0x7b&#xA;[    0.392000]  ? acpi_terminate+0xa/0x14&#xA;[    0.392000]  ? acpi_init+0x2af/0x3&#xA;---truncated---&#xA;CVE-2025-38348:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()&#xA;&#xA;Robert Morris reported:&#xA;&#xA;|If a malicious USB device pretends to be an Intersil p54 wifi&#xA;|interface and generates an eeprom_readback message with a large&#xA;|eeprom-&gt;v1.len, p54_rx_eeprom_readback() will copy data from the&#xA;|message beyond the end of priv-&gt;eeprom.&#xA;|&#xA;|static void p54_rx_eeprom_readback(struct p54_common *priv,&#xA;|                                   struct sk_buff *skb)&#xA;|{&#xA;|        struct p54_hdr *hdr = (struct p54_hdr *) skb-&gt;data;&#xA;|        struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-&gt;data;&#xA;|&#xA;|        if (priv-&gt;fw_var &gt;= 0x509) {&#xA;|                memcpy(priv-&gt;eeprom, eeprom-&gt;v2.data,&#xA;|                       le16_to_cpu(eeprom-&gt;v2.len));&#xA;|        } else {&#xA;|                memcpy(priv-&gt;eeprom, eeprom-&gt;v1.data,&#xA;|                       le16_to_cpu(eeprom-&gt;v1.len));&#xA;|        }&#xA;| [...]&#xA;&#xA;The eeprom-&gt;v{1,2}.len is set by the driver in p54_download_eeprom().&#xA;The device is supposed to provide the same length back to the driver.&#xA;But yes, it&#39;s possible (like shown in the report) to alter the value&#xA;to something that causes a crash/panic due to overrun.&#xA;&#xA;This patch addresses the issue by adding the size to the common device&#xA;context, so p54_rx_eeprom_readback no longer relies on possibly tampered&#xA;values... That said, it also checks if the &#34;firmware&#34; altered the value&#xA;and no longer copies them.&#xA;&#xA;The one, small saving grace is: Before the driver tries to read the eeprom,&#xA;it needs to upload &gt;a&lt; firmware. the vendor firmware has a proprietary&#xA;license and as a reason, it is not present on most distributions by&#xA;default.&#xA;CVE-2025-38363:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/tegra: Fix a possible null pointer dereference&#xA;&#xA;In tegra_crtc_reset(), new memory is allocated with kzalloc(), but&#xA;no check is performed. Before calling __drm_atomic_helper_crtc_reset,&#xA;state should be checked to prevent possible null pointer dereference.&#xA;CVE-2025-38377:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rose: fix dangling neighbour pointers in rose_rt_device_down()&#xA;&#xA;There are two bugs in rose_rt_device_down() that can cause&#xA;use-after-free:&#xA;&#xA;1. The loop bound `t-&gt;count` is modified within the loop, which can&#xA;   cause the loop to terminate early and miss some entries.&#xA;&#xA;2. When removing an entry from the neighbour array, the subsequent entries&#xA;   are moved up to fill the gap, but the loop index `i` is still&#xA;   incremented, causing the next entry to be skipped.&#xA;&#xA;For example, if a node has three neighbours (A, A, B) with count=3 and A&#xA;is being removed, the second A is not checked.&#xA;&#xA;    i=0: (A, A, B) -&gt; (A, B) with count=2&#xA;          ^ checked&#xA;    i=1: (A, B)    -&gt; (A, B) with count=2&#xA;             ^ checked (B, not A!)&#xA;    i=2: (doesn&#39;t occur because i &lt; count is false)&#xA;&#xA;This leaves the second A in the array with count=2, but the rose_neigh&#xA;structure has been freed. Code that accesses these entries assumes that&#xA;the first `count` entries are valid pointers, causing a use-after-free&#xA;when it accesses the dangling pointer.&#xA;&#xA;Fix both issues by iterating over the array in reverse order with a fixed&#xA;loop bound. This ensures that all entries are examined and that the removal&#xA;of an entry doesn&#39;t affect subsequent iterations.&#xA;CVE-2025-38393:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN&#xA;&#xA;We found a few different systems hung up in writeback waiting on the same&#xA;page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in&#xA;pnfs_update_layout(), however the pnfs_layout_hdr&#39;s plh_outstanding count&#xA;was zero.&#xA;&#xA;It seems most likely that this is another race between the waiter and waker&#xA;similar to commit ed0172af5d6f (&#34;SUNRPC: Fix a race to wake a sync task&#34;).&#xA;Fix it up by applying the advised barrier.&#xA;CVE-2025-38401:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mtk-sd: Prevent memory corruption from DMA map failure&#xA;&#xA;If msdc_prepare_data() fails to map the DMA region, the request is&#xA;not prepared for data receiving, but msdc_start_data() proceeds&#xA;the DMA with previous setting.&#xA;Since this will lead a memory corruption, we have to stop the&#xA;request operation soon after the msdc_prepare_data() fails to&#xA;prepare it.&#xA;CVE-2025-38403:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vsock/vmci: Clear the vmci transport packet properly when initializing it&#xA;&#xA;In vmci_transport_packet_init memset the vmci_transport_packet before&#xA;populating the fields to avoid any uninitialised data being left in the&#xA;structure.&#xA;CVE-2025-38430:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request&#xA;&#xA;If the request being processed is not a v4 compound request, then&#xA;examining the cstate can have undefined results.&#xA;&#xA;This patch adds a check that the rpc procedure being executed&#xA;(rq_procinfo) is the NFSPROC4_COMPOUND procedure.&#xA;CVE-2025-38458:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: clip: Fix NULL pointer dereference in vcc_sendmsg()&#xA;&#xA;atmarpd_dev_ops does not implement the send method, which may cause crash&#xA;as bellow.&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;PGD 0 P4D 0&#xA;Oops: Oops: 0010 [#1] SMP KASAN NOPTI&#xA;CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)&#xA;Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014&#xA;RIP: 0010:0x0&#xA;Code: Unable to access opcode bytes at 0xffffffffffffffd6.&#xA;RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246&#xA;RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000&#xA;RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000&#xA;RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287&#xA;R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00&#xA;R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88&#xA;FS:  00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644&#xA; sock_sendmsg_nosec net/socket.c:712 [inline]&#xA; __sock_sendmsg+0x219/0x270 net/socket.c:727&#xA; ____sys_sendmsg+0x52d/0x830 net/socket.c:2566&#xA; ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620&#xA; __sys_sendmmsg+0x227/0x430 net/socket.c:2709&#xA; __do_sys_sendmmsg net/socket.c:2736 [inline]&#xA; __se_sys_sendmmsg net/socket.c:2733 [inline]&#xA; __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2025-38460:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;atm: clip: Fix potential null-ptr-deref in to_atmarpd().&#xA;&#xA;atmarpd is protected by RTNL since commit f3a0592b37b8 (&#34;[ATM]: clip&#xA;causes unregister hang&#34;).&#xA;&#xA;However, it is not enough because to_atmarpd() is called without RTNL,&#xA;especially clip_neigh_solicit() / neigh_ops-&gt;solicit() is unsleepable.&#xA;&#xA;Also, there is no RTNL dependency around atmarpd.&#xA;&#xA;Let&#39;s use a private mutex and RCU to protect access to atmarpd in&#xA;to_atmarpd().&#xA;CVE-2025-38462:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vsock: Fix transport_{g2h,h2g} TOCTOU&#xA;&#xA;vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.&#xA;transport_{g2h,h2g} may become NULL after the NULL check.&#xA;&#xA;Introduce vsock_transport_local_cid() to protect from a potential&#xA;null-ptr-deref.&#xA;&#xA;KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]&#xA;RIP: 0010:vsock_find_cid+0x47/0x90&#xA;Call Trace:&#xA; __vsock_bind+0x4b2/0x720&#xA; vsock_bind+0x90/0xe0&#xA; __sys_bind+0x14d/0x1e0&#xA; __x64_sys_bind+0x6e/0xc0&#xA; do_syscall_64+0x92/0x1c0&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]&#xA;RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0&#xA;Call Trace:&#xA; __x64_sys_ioctl+0x12d/0x190&#xA; do_syscall_64+0x92/0x1c0&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;CVE-2025-38468:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree&#xA;&#xA;htb_lookup_leaf has a BUG_ON that can trigger with the following:&#xA;&#xA;tc qdisc del dev lo root&#xA;tc qdisc add dev lo root handle 1: htb default 1&#xA;tc class add dev lo parent 1: classid 1:1 htb rate 64bit&#xA;tc qdisc add dev lo parent 1:1 handle 2: netem&#xA;tc qdisc add dev lo parent 2:1 handle 3: blackhole&#xA;ping -I lo -c1 -W0.001 127.0.0.1&#xA;&#xA;The root cause is the following:&#xA;&#xA;1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on&#xA;   the selected leaf qdisc&#xA;2. netem_dequeue calls enqueue on the child qdisc&#xA;3. blackhole_enqueue drops the packet and returns a value that is not&#xA;   just NET_XMIT_SUCCESS&#xA;4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and&#xA;   since qlen is now 0, it calls htb_qlen_notify -&gt; htb_deactivate -&gt;&#xA;   htb_deactiviate_prios -&gt; htb_remove_class_from_row -&gt; htb_safe_rb_erase&#xA;5. As this is the only class in the selected hprio rbtree,&#xA;   __rb_change_child in __rb_erase_augmented sets the rb_root pointer to&#xA;   NULL&#xA;6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,&#xA;   which causes htb_dequeue_tree to call htb_lookup_leaf with the same&#xA;   hprio rbtree, and fail the BUG_ON&#xA;&#xA;The function graph for this scenario is shown here:&#xA; 0)               |  htb_enqueue() {&#xA; 0) + 13.635 us   |    netem_enqueue();&#xA; 0)   4.719 us    |    htb_activate_prios();&#xA; 0) # 2249.199 us |  }&#xA; 0)               |  htb_dequeue() {&#xA; 0)   2.355 us    |    htb_lookup_leaf();&#xA; 0)               |    netem_dequeue() {&#xA; 0) + 11.061 us   |      blackhole_enqueue();&#xA; 0)               |      qdisc_tree_reduce_backlog() {&#xA; 0)               |        qdisc_lookup_rcu() {&#xA; 0)   1.873 us    |          qdisc_match_from_root();&#xA; 0)   6.292 us    |        }&#xA; 0)   1.894 us    |        htb_search();&#xA; 0)               |        htb_qlen_notify() {&#xA; 0)   2.655 us    |          htb_deactivate_prios();&#xA; 0)   6.933 us    |        }&#xA; 0) + 25.227 us   |      }&#xA; 0)   1.983 us    |      blackhole_dequeue();&#xA; 0) + 86.553 us   |    }&#xA; 0) # 2932.761 us |    qdisc_warn_nonwc();&#xA; 0)               |    htb_lookup_leaf() {&#xA; 0)               |      BUG_ON();&#xA; ------------------------------------------&#xA;&#xA;The full original bug report can be seen here [1].&#xA;&#xA;We can fix this just by returning NULL instead of the BUG_ON,&#xA;as htb_dequeue_tree returns NULL when htb_lookup_leaf returns&#xA;NULL.&#xA;&#xA;[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/&#xA;CVE-2025-38473:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()&#xA;&#xA;syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]&#xA;&#xA;l2cap_sock_resume_cb() has a similar problem that was fixed by commit&#xA;1bff51ea59a9 (&#34;Bluetooth: fix use-after-free error in lock_sock_nested()&#34;).&#xA;&#xA;Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed&#xA;under l2cap_sock_resume_cb(), we can avoid the issue simply by checking&#xA;if chan-&gt;data is NULL.&#xA;&#xA;Let&#39;s not access to the killed socket in l2cap_sock_resume_cb().&#xA;&#xA;[0]:&#xA;BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]&#xA;BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]&#xA;BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711&#xA;Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52&#xA;&#xA;CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025&#xA;Workqueue: hci0 hci_rx_work&#xA;Call trace:&#xA; show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)&#xA; __dump_stack+0x30/0x40 lib/dump_stack.c:94&#xA; dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120&#xA; print_report+0x58/0x84 mm/kasan/report.c:524&#xA; kasan_report+0xb0/0x110 mm/kasan/report.c:634&#xA; check_region_inline mm/kasan/generic.c:-1 [inline]&#xA; kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189&#xA; __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37&#xA; instrument_atomic_write include/linux/instrumented.h:82 [inline]&#xA; clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]&#xA; l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711&#xA; l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357&#xA; hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]&#xA; hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514&#xA; hci_event_func net/bluetooth/hci_event.c:7511 [inline]&#xA; hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565&#xA; hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070&#xA; process_one_work+0x7e8/0x155c kernel/workqueue.c:3238&#xA; process_scheduled_works kernel/workqueue.c:3321 [inline]&#xA; worker_thread+0x958/0xed8 kernel/workqueue.c:3402&#xA; kthread+0x5fc/0x75c kernel/kthread.c:464&#xA; ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847&#xA;CVE-2025-38476:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rpl: Fix use-after-free in rpl_do_srh_inline().&#xA;&#xA;Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers&#xA;the splat below [0].&#xA;&#xA;rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after&#xA;skb_cow_head(), which is illegal as the header could be freed then.&#xA;&#xA;Let&#39;s fix it by making oldhdr to a local struct instead of a pointer.&#xA;&#xA;[0]:&#xA;[root@fedora net]# ./lwt_dst_cache_ref_loop.sh&#xA;...&#xA;TEST: rpl (input)&#xA;[   57.631529] ==================================================================&#xA;BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)&#xA;Read of size 40 at addr ffff888122bf96d8 by task ping6/1543&#xA;&#xA;CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl (lib/dump_stack.c:122)&#xA; print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)&#xA; kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)&#xA; kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))&#xA; __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))&#xA; rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)&#xA; rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)&#xA; lwtunnel_input (net/core/lwtunnel.c:459)&#xA; ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))&#xA; __netif_receive_skb_one_core (net/core/dev.c:5967)&#xA; process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)&#xA; __napi_poll.constprop.0 (net/core/dev.c:7452)&#xA; net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)&#xA; handle_softirqs (kernel/softirq.c:579)&#xA; do_softirq (kernel/softirq.c:480 (discriminator 20))&#xA; &lt;/IRQ&gt;&#xA; &lt;TASK&gt;&#xA; __local_bh_enable_ip (kernel/softirq.c:407)&#xA; __dev_queue_xmit (net/core/dev.c:4740)&#xA; ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)&#xA; ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)&#xA; ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)&#xA; ip6_send_skb (net/ipv6/ip6_output.c:1983)&#xA; rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)&#xA; __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))&#xA; __x64_sys_sendto (net/socket.c:2231)&#xA; do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))&#xA; entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#xA;RIP: 0033:0x7f68cffb2a06&#xA;Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 &lt;48&gt; 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08&#xA;RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c&#xA;RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06&#xA;RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003&#xA;RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c&#xA;R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4&#xA;R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0&#xA; &lt;/TASK&gt;&#xA;&#xA;Allocated by task 1543:&#xA; kasan_save_stack (mm/kasan/common.c:48)&#xA; kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))&#xA; __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)&#xA; kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)&#xA; kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))&#xA; __alloc_skb (net/core/skbuff.c:669)&#xA; __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))&#xA; ip6_&#xA;---truncated---&#xA;CVE-2025-38482:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;comedi: das6402: Fix bit shift out of bounds&#xA;&#xA;When checking for a supported IRQ number, the following test is used:&#xA;&#xA;&#x9;/* IRQs 2,3,5,6,7, 10,11,15 are valid for &#34;enhanced&#34; mode */&#xA;&#x9;if ((1 &lt;&lt; it-&gt;options[1]) &amp; 0x8cec) {&#xA;&#xA;However, `it-&gt;options[i]` is an unchecked `int` value from userspace, so&#xA;the shift amount could be negative or out of bounds.  Fix the test by&#xA;requiring `it-&gt;options[1]` to be within bounds before proceeding with&#xA;the original test.  Valid `it-&gt;options[1]` values that select the IRQ&#xA;will be in the range [1,15]. The value 0 explicitly disables the use of&#xA;interrupts.&#xA;CVE-2025-38483:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;comedi: das16m1: Fix bit shift out of bounds&#xA;&#xA;When checking for a supported IRQ number, the following test is used:&#xA;&#xA;&#x9;/* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */&#xA;&#x9;if ((1 &lt;&lt; it-&gt;options[1]) &amp; 0xdcfc) {&#xA;&#xA;However, `it-&gt;options[i]` is an unchecked `int` value from userspace, so&#xA;the shift amount could be negative or out of bounds.  Fix the test by&#xA;requiring `it-&gt;options[1]` to be within bounds before proceeding with&#xA;the original test.&#xA;CVE-2025-38515:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/sched: Increment job count before swapping tail spsc queue&#xA;&#xA;A small race exists between spsc_queue_push and the run-job worker, in&#xA;which spsc_queue_push may return not-first while the run-job worker has&#xA;already idled due to the job count being zero. If this race occurs, job&#xA;scheduling stops, leading to hangs while waiting on the job’s DMA&#xA;fences.&#xA;&#xA;Seal this race by incrementing the job count before appending to the&#xA;SPSC queue.&#xA;&#xA;This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in&#xA;an SVM test case.&#xA;CVE-2025-38516:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pinctrl: qcom: msm: mark certain pins as invalid for interrupts&#xA;&#xA;On some platforms, the UFS-reset pin has no interrupt logic in TLMM but&#xA;is nevertheless registered as a GPIO in the kernel. This enables the&#xA;user-space to trigger a BUG() in the pinctrl-msm driver by running, for&#xA;example: `gpiomon -c 0 113` on RB2.&#xA;&#xA;The exact culprit is requesting pins whose intr_detection_width setting&#xA;is not 1 or 2 for interrupts. This hits a BUG() in&#xA;msm_gpio_irq_set_type(). Potentially crashing the kernel due to an&#xA;invalid request from user-space is not optimal, so let&#39;s go through the&#xA;pins and mark those that would fail the check as invalid for the irq chip&#xA;as we should not even register them as available irqs.&#xA;&#xA;This function can be extended if we determine that there are more&#xA;corner-cases like this.&#xA;CVE-2025-38530:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;comedi: pcl812: Fix bit shift out of bounds&#xA;&#xA;When checking for a supported IRQ number, the following test is used:&#xA;&#xA;&#x9;if ((1 &lt;&lt; it-&gt;options[1]) &amp; board-&gt;irq_bits) {&#xA;&#xA;However, `it-&gt;options[i]` is an unchecked `int` value from userspace, so&#xA;the shift amount could be negative or out of bounds.  Fix the test by&#xA;requiring `it-&gt;options[1]` to be within bounds before proceeding with&#xA;the original test.  Valid `it-&gt;options[1]` values that select the IRQ&#xA;will be in the range [1,15]. The value 0 explicitly disables the use of&#xA;interrupts.&#xA;CVE-2025-38540:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras&#xA;&#xA;The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 &amp; 04F2:B82C)&#xA;report a HID sensor interface that is not actually implemented.&#xA;Attempting to access this non-functional sensor via iio_info causes&#xA;system hangs as runtime PM tries to wake up an unresponsive sensor.&#xA;&#xA;Add these 2 devices to the HID ignore list since the sensor interface is&#xA;non-functional by design and should not be exposed to userspace.&#xA;CVE-2025-38553:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: Restrict conditions for adding duplicating netems to qdisc tree&#xA;&#xA;netem_enqueue&#39;s duplication prevention logic breaks when a netem&#xA;resides in a qdisc tree with other netems - this can lead to a&#xA;soft lockup and OOM loop in netem_dequeue, as seen in [1].&#xA;Ensure that a duplicating netem cannot exist in a tree with other&#xA;netems.&#xA;&#xA;Previous approaches suggested in discussions in chronological order:&#xA;&#xA;1) Track duplication status or ttl in the sk_buff struct. Considered&#xA;too specific a use case to extend such a struct, though this would&#xA;be a resilient fix and address other previous and potential future&#xA;DOS bugs like the one described in loopy fun [2].&#xA;&#xA;2) Restrict netem_enqueue recursion depth like in act_mirred with a&#xA;per cpu variable. However, netem_dequeue can call enqueue on its&#xA;child, and the depth restriction could be bypassed if the child is a&#xA;netem.&#xA;&#xA;3) Use the same approach as in 2, but add metadata in netem_skb_cb&#xA;to handle the netem_dequeue case and track a packet&#39;s involvement&#xA;in duplication. This is an overly complex approach, and Jamal&#xA;notes that the skb cb can be overwritten to circumvent this&#xA;safeguard.&#xA;&#xA;4) Prevent the addition of a netem to a qdisc tree if its ancestral&#xA;path contains a netem. However, filters and actions can cause a&#xA;packet to change paths when re-enqueued to the root from netem&#xA;duplication, leading us to the current solution: prevent a&#xA;duplicating netem from inhabiting the same tree as other netems.&#xA;&#xA;[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/&#xA;[2] https://lwn.net/Articles/719297/&#xA;CVE-2025-38581:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: ccp - Fix crash when rebind ccp device for ccp.ko&#xA;&#xA;When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding&#xA;the ccp device causes the following crash:&#xA;&#xA;$ echo &#39;0000:0a:00.2&#39; &gt; /sys/bus/pci/drivers/ccp/unbind&#xA;$ echo &#39;0000:0a:00.2&#39; &gt; /sys/bus/pci/drivers/ccp/bind&#xA;&#xA;[  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098&#xA;[  204.978026] #PF: supervisor write access in kernel mode&#xA;[  204.979126] #PF: error_code(0x0002) - not-present page&#xA;[  204.980226] PGD 0 P4D 0&#xA;[  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI&#xA;...&#xA;[  204.997852] Call Trace:&#xA;[  204.999074]  &lt;TASK&gt;&#xA;[  205.000297]  start_creating+0x9f/0x1c0&#xA;[  205.001533]  debugfs_create_dir+0x1f/0x170&#xA;[  205.002769]  ? srso_return_thunk+0x5/0x5f&#xA;[  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]&#xA;[  205.005241]  ccp5_init+0x8b2/0x960 [ccp]&#xA;[  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]&#xA;[  205.007709]  sp_init+0x5f/0x80 [ccp]&#xA;[  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]&#xA;[  205.010165]  ? srso_return_thunk+0x5/0x5f&#xA;[  205.011376]  local_pci_probe+0x4f/0xb0&#xA;[  205.012584]  pci_device_probe+0xdb/0x230&#xA;[  205.013810]  really_probe+0xed/0x380&#xA;[  205.015024]  __driver_probe_device+0x7e/0x160&#xA;[  205.016240]  device_driver_attach+0x2f/0x60&#xA;[  205.017457]  bind_store+0x7c/0xb0&#xA;[  205.018663]  drv_attr_store+0x28/0x40&#xA;[  205.019868]  sysfs_kf_write+0x5f/0x70&#xA;[  205.021065]  kernfs_fop_write_iter+0x145/0x1d0&#xA;[  205.022267]  vfs_write+0x308/0x440&#xA;[  205.023453]  ksys_write+0x6d/0xe0&#xA;[  205.024616]  __x64_sys_write+0x1e/0x30&#xA;[  205.025778]  x64_sys_call+0x16ba/0x2150&#xA;[  205.026942]  do_syscall_64+0x56/0x1e0&#xA;[  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;[  205.029276] RIP: 0033:0x7fbc36f10104&#xA;[  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5&#xA;&#xA;This patch sets ccp_debugfs_dir to NULL after destroying it in&#xA;ccp5_debugfs_destroy, allowing the directory dentry to be&#xA;recreated when rebinding the ccp device.&#xA;&#xA;Tested on AMD Ryzen 7 1700X.&#xA;CVE-2025-38591:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Reject narrower access to pointer ctx fields&#xA;&#xA;The following BPF program, simplified from a syzkaller repro, causes a&#xA;kernel warning:&#xA;&#xA;    r0 = *(u8 *)(r1 + 169);&#xA;    exit;&#xA;&#xA;With pointer field sk being at offset 168 in __sk_buff. This access is&#xA;detected as a narrower read in bpf_skb_is_valid_access because it&#xA;doesn&#39;t match offsetof(struct __sk_buff, sk). It is therefore allowed&#xA;and later proceeds to bpf_convert_ctx_access. Note that for the&#xA;&#34;is_narrower_load&#34; case in the convert_ctx_accesses(), the insn-&gt;off&#xA;is aligned, so the cnt may not be 0 because it matches the&#xA;offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,&#xA;the target_size stays 0 and the verifier errors with a kernel warning:&#xA;&#xA;    verifier bug: error during ctx access conversion(1)&#xA;&#xA;This patch fixes that to return a proper &#34;invalid bpf_context access&#xA;off=X size=Y&#34; error on the load instruction.&#xA;&#xA;The same issue affects multiple other fields in context structures that&#xA;allow narrow access. Some other non-affected fields (for sk_msg,&#xA;sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for&#xA;consistency.&#xA;&#xA;Note this syzkaller crash was reported in the &#34;Closes&#34; link below, which&#xA;used to be about a different bug, fixed in&#xA;commit fce7bd8e385a (&#34;bpf/verifier: Handle BPF_LOAD_ACQ instructions&#xA;in insn_def_regno()&#34;). Because syzbot somehow confused the two bugs,&#xA;the new crash and repro didn&#39;t get reported to the mailing list.&#xA;CVE-2025-38608:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls&#xA;&#xA;When sending plaintext data, we initially calculated the corresponding&#xA;ciphertext length. However, if we later reduced the plaintext data length&#xA;via socket policy, we failed to recalculate the ciphertext length.&#xA;&#xA;This results in transmitting buffers containing uninitialized data during&#xA;ciphertext transmission.&#xA;&#xA;This causes uninitialized bytes to be appended after a complete&#xA;&#34;Application Data&#34; packet, leading to errors on the receiving end when&#xA;parsing TLS record.&#xA;CVE-2025-38622:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: drop UFO packets in udp_rcv_segment()&#xA;&#xA;When sending a packet with virtio_net_hdr to tun device, if the gso_type&#xA;in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr&#xA;size, below crash may happen.&#xA;&#xA;  ------------[ cut here ]------------&#xA;  kernel BUG at net/core/skbuff.c:4572!&#xA;  Oops: invalid opcode: 0000 [#1] SMP NOPTI&#xA;  CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)&#xA;  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014&#xA;  RIP: 0010:skb_pull_rcsum+0x8e/0xa0&#xA;  Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc &lt;0f&gt; 0b 0f 0b 66 66 2e 0f 1f 84 00 000&#xA;  RSP: 0018:ffffc900001fba38 EFLAGS: 00000297&#xA;  RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948&#xA;  RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062&#xA;  RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001&#xA;  R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000&#xA;  R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900&#xA;  FS:  000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000&#xA;  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;  CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445&#xA;   udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475&#xA;   udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626&#xA;   __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690&#xA;   ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205&#xA;   ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233&#xA;   ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579&#xA;   ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636&#xA;   ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670&#xA;   __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067&#xA;   netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210&#xA;   napi_complete_done+0x78/0x180 net/core/dev.c:6580&#xA;   tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909&#xA;   tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984&#xA;   vfs_write+0x300/0x420 fs/read_write.c:593&#xA;   ksys_write+0x60/0xd0 fs/read_write.c:686&#xA;   do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63&#xA;   &lt;/TASK&gt;&#xA;&#xA;To trigger gso segment in udp_queue_rcv_skb(), we should also set option&#xA;UDP_ENCAP_ESPINUDP to enable udp_sk(sk)-&gt;encap_rcv. When the encap_rcv&#xA;hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try&#xA;to pull udphdr, but the skb size has been segmented to gso size, which&#xA;leads to this crash.&#xA;&#xA;Previous commit cf329aa42b66 (&#34;udp: cope with UDP GRO packet misdirection&#34;)&#xA;introduces segmentation in UDP receive path only for GRO, which was never&#xA;intended to be used for UFO, so drop UFO packets in udp_rcv_segment().&#xA;CVE-2025-38623:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI: pnv_php: Fix surprise plug detection and recovery&#xA;&#xA;The existing PowerNV hotplug code did not handle surprise plug events&#xA;correctly, leading to a complete failure of the hotplug system after device&#xA;removal and a required reboot to detect new devices.&#xA;&#xA;This comes down to two issues:&#xA;&#xA; 1) When a device is surprise removed, often the bridge upstream&#xA;    port will cause a PE freeze on the PHB.  If this freeze is not&#xA;    cleared, the MSI interrupts from the bridge hotplug notification&#xA;    logic will not be received by the kernel, stalling all plug events&#xA;    on all slots associated with the PE.&#xA;&#xA; 2) When a device is removed from a slot, regardless of surprise or&#xA;    programmatic removal, the associated PHB/PE ls left frozen.&#xA;    If this freeze is not cleared via a fundamental reset, skiboot&#xA;    is unable to clear the freeze and cannot retrain / rescan the&#xA;    slot.  This also requires a reboot to clear the freeze and redetect&#xA;    the device in the slot.&#xA;&#xA;Issue the appropriate unfreeze and rescan commands on hotplug events,&#xA;and don&#39;t oops on hotplug if pci_bus_to_OF_node() returns NULL.&#xA;&#xA;[bhelgaas: tidy comments]&#xA;CVE-2025-38635:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;clk: davinci: Add NULL check in davinci_lpsc_clk_register()&#xA;&#xA;devm_kasprintf() returns NULL when memory allocation fails. Currently,&#xA;davinci_lpsc_clk_register() does not check for this case, which results&#xA;in a NULL pointer dereference.&#xA;&#xA;Add NULL check after devm_kasprintf() to prevent this issue and ensuring&#xA;no resources are left allocated.&#xA;CVE-2025-38637:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net_sched: skbprio: Remove overly strict queue assertions&#xA;&#xA;In the current implementation, skbprio enqueue/dequeue contains an assertion&#xA;that fails under certain conditions when SKBPRIO is used as a child qdisc under&#xA;TBF with specific parameters. The failure occurs because TBF sometimes peeks at&#xA;packets in the child qdisc without actually dequeuing them when tokens are&#xA;unavailable.&#xA;&#xA;This peek operation creates a discrepancy between the parent and child qdisc&#xA;queue length counters. When TBF later receives a high-priority packet,&#xA;SKBPRIO&#39;s queue length may show a different value than what&#39;s reflected in its&#xA;internal priority queue tracking, triggering the assertion.&#xA;&#xA;The fix removes this overly strict assertions in SKBPRIO, they are not&#xA;necessary at all.&#xA;CVE-2025-38639:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: xt_nfacct: don&#39;t assume acct name is null-terminated&#xA;&#xA;BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721&#xA;Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851&#xA;[..]&#xA; string+0x231/0x2b0 lib/vsprintf.c:721&#xA; vsnprintf+0x739/0xf00 lib/vsprintf.c:2874&#xA; [..]&#xA; nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41&#xA; xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523&#xA;&#xA;nfnl_acct_find_get() handles non-null input, but the error&#xA;printk relied on its presence.&#xA;CVE-2025-38668:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;regulator: core: fix NULL dereference on unbind due to stale coupling data&#xA;&#xA;Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can&#xA;lead to NULL pointer dereference when regulators are accessed post-unbind.&#xA;&#xA;This can happen during runtime PM or other regulator operations that rely&#xA;on coupling metadata.&#xA;&#xA;For example, on ridesx4, unbinding the &#39;reg-dummy&#39; platform device triggers&#xA;a panic in regulator_lock_recursive() due to stale coupling state.&#xA;&#xA;Ensure n_coupled is set to 0 to prevent access to invalid pointers.&#xA;CVE-2025-38678:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nf_tables: reject duplicate device on updates&#xA;&#xA;A chain/flowtable update with duplicated devices in the same batch is&#xA;possible. Unfortunately, netdev event path only removes the first&#xA;device that is found, leaving unregistered the hook of the duplicated&#xA;device.&#xA;&#xA;Check if a duplicated device exists in the transaction batch, bail out&#xA;with EEXIST in such case.&#xA;&#xA;WARNING is hit when unregistering the hook:&#xA;&#xA; [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150&#xA; [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S                  6.16.0+ #170 PREEMPT(full)&#xA; [...]&#xA; [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150&#xA;CVE-2025-38691:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pNFS: Fix uninited ptr deref in block/scsi layout&#xA;&#xA;The error occurs on the third attempt to encode extents. When function&#xA;ext_tree_prepare_commit() reallocates a larger buffer to retry encoding&#xA;extents, the &#34;layoutupdate_pages&#34; page array is initialized only after the&#xA;retry loop. But ext_tree_free_commitdata() is called on every iteration&#xA;and tries to put pages in the array, thus dereferencing uninitialized&#xA;pointers.&#xA;&#xA;An additional problem is that there is no limit on the maximum possible&#xA;buffer_size. When there are too many extents, the client may create a&#xA;layoutcommit that is larger than the maximum possible RPC size accepted&#xA;by the server.&#xA;&#xA;During testing, we observed two typical scenarios. First, one memory page&#xA;for extents is enough when we work with small files, append data to the&#xA;end of the file, or preallocate extents before writing. But when we fill&#xA;a new large file without preallocating, the number of extents can be huge,&#xA;and counting the number of written extents in ext_tree_encode_commit()&#xA;does not help much. Since this number increases even more between&#xA;unlocking and locking of ext_tree, the reallocated buffer may not be&#xA;large enough again and again.&#xA;CVE-2025-38694:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()&#xA;&#xA;In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and&#xA;msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing&#xA;msg[0].buf[2] without sanity check, null pointer deref would happen. We add&#xA;check on msg[0].len to prevent crash. Similar issue occurs when access&#xA;msg[1].buf[0] and msg[1].buf[1].&#xA;&#xA;Similar commit: commit 0ed554fd769a (&#34;media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()&#34;)&#xA;CVE-2025-38696:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;MIPS: Don&#39;t crash in stack_top() for tasks without ABI or vDSO&#xA;&#xA;Not all tasks have an ABI associated or vDSO mapped,&#xA;for example kthreads never do.&#xA;If such a task ever ends up calling stack_top(), it will derefence the&#xA;NULL ABI pointer and crash.&#xA;&#xA;This can for example happen when using kunit:&#xA;&#xA;    mips_stack_top+0x28/0xc0&#xA;    arch_pick_mmap_layout+0x190/0x220&#xA;    kunit_vm_mmap_init+0xf8/0x138&#xA;    __kunit_add_resource+0x40/0xa8&#xA;    kunit_vm_mmap+0x88/0xd8&#xA;    usercopy_test_init+0xb8/0x240&#xA;    kunit_try_run_case+0x5c/0x1a8&#xA;    kunit_generic_run_threadfn_adapter+0x28/0x50&#xA;    kthread+0x118/0x240&#xA;    ret_from_kernel_thread+0x14/0x1c&#xA;&#xA;Only dereference the ABI point if it is set.&#xA;&#xA;The GIC page is also included as it is specific to the vDSO.&#xA;Also move the randomization adjustment into the same conditional.&#xA;CVE-2025-38701:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr&#xA;&#xA;A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()&#xA;when an inode had the INLINE_DATA_FL flag set but was missing the&#xA;system.data extended attribute.&#xA;&#xA;Since this can happen due to a maiciouly fuzzed file system, we&#xA;shouldn&#39;t BUG, but rather, report it as a corrupted file system.&#xA;&#xA;Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii&#xA;ext4_create_inline_data() and ext4_inline_data_truncate().&#xA;CVE-2025-38708:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drbd: add missing kref_get in handle_write_conflicts&#xA;&#xA;With `two-primaries` enabled, DRBD tries to detect &#34;concurrent&#34; writes&#xA;and handle write conflicts, so that even if you write to the same sector&#xA;simultaneously on both nodes, they end up with the identical data once&#xA;the writes are completed.&#xA;&#xA;In handling &#34;superseeded&#34; writes, we forgot a kref_get,&#xA;resulting in a premature drbd_destroy_device and use after free,&#xA;and further to kernel crashes with symptoms.&#xA;&#xA;Relevance: No one should use DRBD as a random data generator, and apparently&#xA;all users of &#34;two-primaries&#34; handle concurrent writes correctly on layer up.&#xA;That is cluster file systems use some distributed lock manager,&#xA;and live migration in virtualization environments stops writes on one node&#xA;before starting writes on the other node.&#xA;&#xA;Which means that other than for &#34;test cases&#34;,&#xA;this code path is never taken in real life.&#xA;&#xA;FYI, in DRBD 9, things are handled differently nowadays.  We still detect&#xA;&#34;write conflicts&#34;, but no longer try to be smart about them.&#xA;We decided to disconnect hard instead: upper layers must not submit concurrent&#xA;writes. If they do, that&#39;s their fault.&#xA;CVE-2025-38721:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: ctnetlink: fix refcount leak on table dump&#xA;&#xA;There is a reference count leak in ctnetlink_dump_table():&#xA;      if (res &lt; 0) {&#xA;                nf_conntrack_get(&amp;ct-&gt;ct_general); // HERE&#xA;                cb-&gt;args[1] = (unsigned long)ct;&#xA;                ...&#xA;&#xA;While its very unlikely, its possible that ct == last.&#xA;If this happens, then the refcount of ct was already incremented.&#xA;This 2nd increment is never undone.&#xA;&#xA;This prevents the conntrack object from being released, which in turn&#xA;keeps prevents cnet-&gt;count from dropping back to 0.&#xA;&#xA;This will then block the netns dismantle (or conntrack rmmod) as&#xA;nf_conntrack_cleanup_net_list() will wait forever.&#xA;&#xA;This can be reproduced by running conntrack_resize.sh selftest in a loop.&#xA;It takes ~20 minutes for me on a preemptible kernel on average before&#xA;I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.&#xA;&#xA;One fix would to change this to:&#xA;        if (res &lt; 0) {&#xA;&#x9;&#x9;if (ct != last)&#xA;&#x9;                nf_conntrack_get(&amp;ct-&gt;ct_general);&#xA;&#xA;But this reference counting isn&#39;t needed in the first place.&#xA;We can just store a cookie value instead.&#xA;&#xA;A followup patch will do the same for ctnetlink_exp_dump_table,&#xA;it looks to me as if this has the same problem and like&#xA;ctnetlink_dump_table, we only need a &#39;skip hint&#39;, not the actual&#xA;object so we can apply the same cookie strategy there as well.&#xA;CVE-2025-39703:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net, hsr: reject HSR frame if skb can&#39;t hold tag&#xA;&#xA;Receiving HSR frame with insufficient space to hold HSR tag in the skb&#xA;can result in a crash (kernel BUG):&#xA;&#xA;[   45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1&#xA;[   45.392559] ------------[ cut here ]------------&#xA;[   45.392912] kernel BUG at net/core/skbuff.c:211!&#xA;[   45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI&#xA;[   45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)&#xA;[   45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;[   45.395273] RIP: 0010:skb_panic+0x15b/0x1d0&#xA;&#xA;&lt;snip registers, remove unreliable trace&gt;&#xA;&#xA;[   45.402911] Call Trace:&#xA;[   45.403105]  &lt;IRQ&gt;&#xA;[   45.404470]  skb_push+0xcd/0xf0&#xA;[   45.404726]  br_dev_queue_push_xmit+0x7c/0x6c0&#xA;[   45.406513]  br_forward_finish+0x128/0x260&#xA;[   45.408483]  __br_forward+0x42d/0x590&#xA;[   45.409464]  maybe_deliver+0x2eb/0x420&#xA;[   45.409763]  br_flood+0x174/0x4a0&#xA;[   45.410030]  br_handle_frame_finish+0xc7c/0x1bc0&#xA;[   45.411618]  br_handle_frame+0xac3/0x1230&#xA;[   45.413674]  __netif_receive_skb_core.constprop.0+0x808/0x3df0&#xA;[   45.422966]  __netif_receive_skb_one_core+0xb4/0x1f0&#xA;[   45.424478]  __netif_receive_skb+0x22/0x170&#xA;[   45.424806]  process_backlog+0x242/0x6d0&#xA;[   45.425116]  __napi_poll+0xbb/0x630&#xA;[   45.425394]  net_rx_action+0x4d1/0xcc0&#xA;[   45.427613]  handle_softirqs+0x1a4/0x580&#xA;[   45.427926]  do_softirq+0x74/0x90&#xA;[   45.428196]  &lt;/IRQ&gt;&#xA;&#xA;This issue was found by syzkaller.&#xA;&#xA;The panic happens in br_dev_queue_push_xmit() once it receives a&#xA;corrupted skb with ETH header already pushed in linear data. When it&#xA;attempts the skb_push() call, there&#39;s not enough headroom and&#xA;skb_push() panics.&#xA;&#xA;The corrupted skb is put on the queue by HSR layer, which makes a&#xA;sequence of unintended transformations when it receives a specific&#xA;corrupted HSR frame (with incomplete TAG).&#xA;&#xA;Fix it by dropping and consuming frames that are not long enough to&#xA;contain both ethernet and hsr headers.&#xA;&#xA;Alternative fix would be to check for enough headroom before skb_push()&#xA;in br_dev_queue_push_xmit().&#xA;&#xA;In the reproducer, this is injected via AF_PACKET, but I don&#39;t easily&#xA;see why it couldn&#39;t be sent over the wire from adjacent network.&#xA;&#xA;Further Details:&#xA;&#xA;In the reproducer, the following network interface chain is set up:&#xA;&#xA;┌────────────────┐   ┌────────────────┐&#xA;│ veth0_to_hsr   ├───┤  hsr_slave0    ┼───┐&#xA;└────────────────┘   └────────────────┘   │&#xA;                                          │ ┌──────┐&#xA;                                          ├─┤ hsr0 ├───┐&#xA;                                          │ └──────┘   │&#xA;┌────────────────┐   ┌────────────────┐   │            │┌────────┐&#xA;│ veth1_to_hsr   ┼───┤  hsr_slave1    ├───┘            └┤        │&#xA;└────────────────┘   └────────────────┘                ┌┼ bridge │&#xA;                                                       ││        │&#xA;                                                       │└────────┘&#xA;                                                       │&#xA;                                        ┌───────┐      │&#xA;                                        │  ...  ├──────┘&#xA;                                        └───────┘&#xA;&#xA;To trigger the events leading up to crash, reproducer sends a corrupted&#xA;HSR fr&#xA;---truncated---&#xA;CVE-2025-39713:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()&#xA;&#xA;In the interrupt handler rain_interrupt(), the buffer full check on&#xA;rain-&gt;buf_len is performed before acquiring rain-&gt;buf_lock. This&#xA;creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as&#xA;rain-&gt;buf_len is concurrently accessed and modified in the work&#xA;handler rain_irq_work_handler() under the same lock.&#xA;&#xA;Multiple interrupt invocations can race, with each reading buf_len&#xA;before it becomes full and then proceeding. This can lead to both&#xA;interrupts attempting to write to the buffer, incrementing buf_len&#xA;beyond its capacity (DATA_SIZE) and causing a buffer overflow.&#xA;&#xA;Fix this bug by moving the spin_lock() to before the buffer full&#xA;check. This ensures that the check and the subsequent buffer modification&#xA;are performed atomically, preventing the race condition. An corresponding&#xA;spin_unlock() is added to the overflow path to correctly release the&#xA;lock.&#xA;&#xA;This possible bug was found by an experimental static analysis tool&#xA;developed by our team.&#xA;CVE-2025-39714:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: usbtv: Lock resolution while streaming&#xA;&#xA;When an program is streaming (ffplay) and another program (qv4l2)&#xA;changes the TV standard from NTSC to PAL, the kernel crashes due to trying&#xA;to copy to unmapped memory.&#xA;&#xA;Changing from NTSC to PAL increases the resolution in the usbtv struct,&#xA;but the video plane buffer isn&#39;t adjusted, so it overflows.&#xA;&#xA;[hverkuil: call vb2_is_busy instead of vb2_is_streaming]&#xA;CVE-2025-39724:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;serial: 8250: fix panic due to PSLVERR&#xA;&#xA;When the PSLVERR_RESP_EN parameter is set to 1, the device generates&#xA;an error response if an attempt is made to read an empty RBR (Receive&#xA;Buffer Register) while the FIFO is enabled.&#xA;&#xA;In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,&#xA;UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes&#xA;dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter&#xA;function enables the FIFO via serial_out(p, UART_FCR, p-&gt;fcr).&#xA;Execution proceeds to the serial_port_in(port, UART_RX).&#xA;This satisfies the PSLVERR trigger condition.&#xA;&#xA;When another CPU (e.g., using printk()) is accessing the UART (UART&#xA;is busy), the current CPU fails the check (value &amp; ~UART_LCR_SPAR) ==&#xA;(lcr &amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter&#xA;dw8250_force_idle().&#xA;&#xA;Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-&gt;lock&#xA;to fix this issue.&#xA;&#xA;Panic backtrace:&#xA;[    0.442336] Oops - unknown exception [#1]&#xA;[    0.442343] epc : dw8250_serial_in32+0x1e/0x4a&#xA;[    0.442351]  ra : serial8250_do_startup+0x2c8/0x88e&#xA;...&#xA;[    0.442416] console_on_rootfs+0x26/0x70&#xA;CVE-2025-39726:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;s390/ism: fix concurrency management in ism_cmd()&#xA;&#xA;The s390x ISM device data sheet clearly states that only one&#xA;request-response sequence is allowable per ISM function at any point in&#xA;time.  Unfortunately as of today the s390/ism driver in Linux does not&#xA;honor that requirement. This patch aims to rectify that.&#xA;&#xA;This problem was discovered based on Aliaksei&#39;s bug report which states&#xA;that for certain workloads the ISM functions end up entering error state&#xA;(with PEC 2 as seen from the logs) after a while and as a consequence&#xA;connections handled by the respective function break, and for future&#xA;connection requests the ISM device is not considered -- given it is in a&#xA;dysfunctional state. During further debugging PEC 3A was observed as&#xA;well.&#xA;&#xA;A kernel message like&#xA;[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a&#xA;is a reliable indicator of the stated function entering error state&#xA;with PEC 2. Let me also point out that a kernel message like&#xA;[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery&#xA;is a reliable indicator that the ISM function won&#39;t be auto-recovered&#xA;because the ISM driver currently lacks support for it.&#xA;&#xA;On a technical level, without this synchronization, commands (inputs to&#xA;the FW) may be partially or fully overwritten (corrupted) by another CPU&#xA;trying to issue commands on the same function. There is hard evidence that&#xA;this can lead to DMB token values being used as DMB IOVAs, leading to&#xA;PEC 2 PCI events indicating invalid DMA. But this is only one of the&#xA;failure modes imaginable. In theory even completely losing one command&#xA;and executing another one twice and then trying to interpret the outputs&#xA;as if the command we intended to execute was actually executed and not&#xA;the other one is also possible.  Frankly, I don&#39;t feel confident about&#xA;providing an exhaustive list of possible consequences.&#xA;CVE-2025-39728:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;clk: samsung: Fix UBSAN panic in samsung_clk_init()&#xA;&#xA;With UBSAN_ARRAY_BOUNDS=y, I&#39;m hitting the below panic due to&#xA;dereferencing `ctx-&gt;clk_data.hws` before setting&#xA;`ctx-&gt;clk_data.num = nr_clks`. Move that up to fix the crash.&#xA;&#xA;  UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP&#xA;  &lt;snip&gt;&#xA;  Call trace:&#xA;   samsung_clk_init+0x110/0x124 (P)&#xA;   samsung_clk_init+0x48/0x124 (L)&#xA;   samsung_cmu_register_one+0x3c/0xa0&#xA;   exynos_arm64_register_cmu+0x54/0x64&#xA;   __gs101_cmu_top_of_clk_init_declare+0x28/0x60&#xA;   ...&#xA;CVE-2025-39730:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()&#xA;&#xA;The function needs to check the minimal filehandle length before it can&#xA;access the embedded filehandle.&#xA;CVE-2025-39742:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()&#xA;&#xA;The function divides number of online CPUs by num_core_siblings, and&#xA;later checks the divider by zero. This implies a possibility to get&#xA;and divide-by-zero runtime error. Fix it by moving the check prior to&#xA;division. This also helps to save one indentation level.&#xA;CVE-2025-39760:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: core: config: Prevent OOB read in SS endpoint companion parsing&#xA;&#xA;usb_parse_ss_endpoint_companion() checks descriptor type before length,&#xA;enabling a potentially odd read outside of the buffer size.&#xA;&#xA;Fix this up by checking the size first before looking at any of the&#xA;fields in the descriptor.&#xA;CVE-2025-39764:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: ctnetlink: remove refcounting in expectation dumpers&#xA;&#xA;Same pattern as previous patch: do not keep the expectation object&#xA;alive via refcount, only store a cookie value and then use that&#xA;as the skip hint for dump resumption.&#xA;&#xA;AFAICS this has the same issue as the one resolved in the conntrack&#xA;dumper, when we do&#xA;  if (!refcount_inc_not_zero(&amp;exp-&gt;use))&#xA;&#xA;to increment the refcount, there is a chance that exp == last, which&#xA;causes a double-increment of the refcount and subsequent memory leak.&#xA;CVE-2025-39782:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jbd2: prevent softlockup in jbd2_log_do_checkpoint()&#xA;&#xA;Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()&#xA;periodically release j_list_lock after processing a batch of buffers to&#xA;avoid long hold times on the j_list_lock. However, since both functions&#xA;contend for j_list_lock, the combined time spent waiting and processing&#xA;can be significant.&#xA;&#xA;jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when&#xA;need_resched() is true to avoid softlockups during prolonged operations.&#xA;But jbd2_log_do_checkpoint() only exits its loop when need_resched() is&#xA;true, relying on potentially sleeping functions like __flush_batch() or&#xA;wait_on_buffer() to trigger rescheduling. If those functions do not sleep,&#xA;the kernel may hit a softlockup.&#xA;&#xA;watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]&#xA;CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10&#xA;Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017&#xA;Workqueue: writeback wb_workfn (flush-7:2)&#xA;pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : native_queued_spin_lock_slowpath+0x358/0x418&#xA;lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]&#xA;Call trace:&#xA; native_queued_spin_lock_slowpath+0x358/0x418&#xA; jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]&#xA; __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]&#xA; add_transaction_credits+0x3bc/0x418 [jbd2]&#xA; start_this_handle+0xf8/0x560 [jbd2]&#xA; jbd2__journal_start+0x118/0x228 [jbd2]&#xA; __ext4_journal_start_sb+0x110/0x188 [ext4]&#xA; ext4_do_writepages+0x3dc/0x740 [ext4]&#xA; ext4_writepages+0xa4/0x190 [ext4]&#xA; do_writepages+0x94/0x228&#xA; __writeback_single_inode+0x48/0x318&#xA; writeback_sb_inodes+0x204/0x590&#xA; __writeback_inodes_wb+0x54/0xf8&#xA; wb_writeback+0x2cc/0x3d8&#xA; wb_do_writeback+0x2e0/0x2f8&#xA; wb_workfn+0x80/0x2a8&#xA; process_one_work+0x178/0x3e8&#xA; worker_thread+0x234/0x3b8&#xA; kthread+0xf0/0x108&#xA; ret_from_fork+0x10/0x20&#xA;&#xA;So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid&#xA;softlockup.&#xA;CVE-2025-39787:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;soc: qcom: mdt_loader: Ensure we don&#39;t read past the ELF header&#xA;&#xA;When the MDT loader is used in remoteproc, the ELF header is sanitized&#xA;beforehand, but that&#39;s not necessary the case for other clients.&#xA;&#xA;Validate the size of the firmware buffer to ensure that we don&#39;t read&#xA;past the end as we iterate over the header. e_phentsize and e_shentsize&#xA;are validated as well, to ensure that the assumptions about step size in&#xA;the traversal are valid.&#xA;CVE-2025-39808:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()&#xA;&#xA;in ntrig_report_version(), hdev parameter passed from hid_probe().&#xA;sending descriptor to /dev/uhid can make hdev-&gt;dev.parent-&gt;parent to null&#xA;if hdev-&gt;dev.parent-&gt;parent is null, usb_dev has&#xA;invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned&#xA;when usb_rcvctrlpipe() use usb_dev,it trigger&#xA;page fault error for address(0xffffffffffffff58)&#xA;&#xA;add null check logic to ntrig_report_version()&#xA;before calling hid_to_usb_dev()&#xA;CVE-2025-39812:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: initialize more fields in sctp_v6_from_sk()&#xA;&#xA;syzbot found that sin6_scope_id was not properly initialized,&#xA;leading to undefined behavior.&#xA;&#xA;Clear sin6_scope_id and sin6_flowinfo.&#xA;&#xA;BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649&#xA;  __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649&#xA;  sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983&#xA;  sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390&#xA;  sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452&#xA;  sctp_get_port net/sctp/socket.c:8523 [inline]&#xA;  sctp_listen_start net/sctp/socket.c:8567 [inline]&#xA;  sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636&#xA;  __sys_listen_socket net/socket.c:1912 [inline]&#xA;  __sys_listen net/socket.c:1927 [inline]&#xA;  __do_sys_listen net/socket.c:1932 [inline]&#xA;  __se_sys_listen net/socket.c:1930 [inline]&#xA;  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930&#xA;  x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51&#xA;  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Local variable addr.i.i created at:&#xA;  sctp_get_port net/sctp/socket.c:8515 [inline]&#xA;  sctp_listen_start net/sctp/socket.c:8567 [inline]&#xA;  sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636&#xA;  __sys_listen_socket net/socket.c:1912 [inline]&#xA;  __sys_listen net/socket.c:1927 [inline]&#xA;  __do_sys_listen net/socket.c:1932 [inline]&#xA;  __se_sys_listen net/socket.c:1930 [inline]&#xA;  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930&#xA;CVE-2025-39824:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;HID: asus: fix UAF via HID_CLAIMED_INPUT validation&#xA;&#xA;After hid_hw_start() is called hidinput_connect() will eventually be&#xA;called to set up the device with the input layer since the&#xA;HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()&#xA;all input and output reports are processed and corresponding hid_inputs&#xA;are allocated and configured via hidinput_configure_usages(). This&#xA;process involves slot tagging report fields and configuring usages&#xA;by setting relevant bits in the capability bitmaps. However it is possible&#xA;that the capability bitmaps are not set at all leading to the subsequent&#xA;hidinput_has_been_populated() check to fail leading to the freeing of the&#xA;hid_input and the underlying input device.&#xA;&#xA;This becomes problematic because a malicious HID device like a&#xA;ASUS ROG N-Key keyboard can trigger the above scenario via a&#xA;specially crafted descriptor which then leads to a user-after-free&#xA;when the name of the freed input device is written to later on after&#xA;hid_hw_start(). Below, report 93 intentionally utilises the&#xA;HID_UP_UNDEFINED Usage Page which is skipped during usage&#xA;configuration, leading to the frees.&#xA;&#xA;0x05, 0x0D,        // Usage Page (Digitizer)&#xA;0x09, 0x05,        // Usage (Touch Pad)&#xA;0xA1, 0x01,        // Collection (Application)&#xA;0x85, 0x0D,        //   Report ID (13)&#xA;0x06, 0x00, 0xFF,  //   Usage Page (Vendor Defined 0xFF00)&#xA;0x09, 0xC5,        //   Usage (0xC5)&#xA;0x15, 0x00,        //   Logical Minimum (0)&#xA;0x26, 0xFF, 0x00,  //   Logical Maximum (255)&#xA;0x75, 0x08,        //   Report Size (8)&#xA;0x95, 0x04,        //   Report Count (4)&#xA;0xB1, 0x02,        //   Feature (Data,Var,Abs)&#xA;0x85, 0x5D,        //   Report ID (93)&#xA;0x06, 0x00, 0x00,  //   Usage Page (Undefined)&#xA;0x09, 0x01,        //   Usage (0x01)&#xA;0x15, 0x00,        //   Logical Minimum (0)&#xA;0x26, 0xFF, 0x00,  //   Logical Maximum (255)&#xA;0x75, 0x08,        //   Report Size (8)&#xA;0x95, 0x1B,        //   Report Count (27)&#xA;0x81, 0x02,        //   Input (Data,Var,Abs)&#xA;0xC0,              // End Collection&#xA;&#xA;Below is the KASAN splat after triggering the UAF:&#xA;&#xA;[   21.672709] ==================================================================&#xA;[   21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80&#xA;[   21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54&#xA;[   21.673700]&#xA;[   21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)&#xA;[   21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014&#xA;[   21.673700] Call Trace:&#xA;[   21.673700]  &lt;TASK&gt;&#xA;[   21.673700]  dump_stack_lvl+0x5f/0x80&#xA;[   21.673700]  print_report+0xd1/0x660&#xA;[   21.673700]  kasan_report+0xe5/0x120&#xA;[   21.673700]  __asan_report_store8_noabort+0x1b/0x30&#xA;[   21.673700]  asus_probe+0xeeb/0xf80&#xA;[   21.673700]  hid_device_probe+0x2ee/0x700&#xA;[   21.673700]  really_probe+0x1c6/0x6b0&#xA;[   21.673700]  __driver_probe_device+0x24f/0x310&#xA;[   21.673700]  driver_probe_device+0x4e/0x220&#xA;[...]&#xA;[   21.673700]&#xA;[   21.673700] Allocated by task 54:&#xA;[   21.673700]  kasan_save_stack+0x3d/0x60&#xA;[   21.673700]  kasan_save_track+0x18/0x40&#xA;[   21.673700]  kasan_save_alloc_info+0x3b/0x50&#xA;[   21.673700]  __kasan_kmalloc+0x9c/0xa0&#xA;[   21.673700]  __kmalloc_cache_noprof+0x139/0x340&#xA;[   21.673700]  input_allocate_device+0x44/0x370&#xA;[   21.673700]  hidinput_connect+0xcb6/0x2630&#xA;[   21.673700]  hid_connect+0xf74/0x1d60&#xA;[   21.673700]  hid_hw_start+0x8c/0x110&#xA;[   21.673700]  asus_probe+0x5a3/0xf80&#xA;[   21.673700]  hid_device_probe+0x2ee/0x700&#xA;[   21.673700]  really_probe+0x1c6/0x6b0&#xA;[   21.673700]  __driver_probe_device+0x24f/0x310&#xA;[   21.673700]  driver_probe_device+0x4e/0x220&#xA;[...]&#xA;[   21.673700]&#xA;[   21.673700] Freed by task 54:&#xA;[   21.673700]  kasan_save_stack+0x3d/0x60&#xA;[   21.673700]  kasan_save_track+0x18/0x40&#xA;[   21.673700]  kasan_save_free_info+0x3f/0x60&#xA;[   21.673700]  __kasan_slab_free+0x3c/0x50&#xA;[   21.673700]  kfre&#xA;---truncated---&#xA;CVE-2025-39833:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mISDN: hfcpci: Fix warning when deleting uninitialized timer&#xA;&#xA;With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads&#xA;to the following splat:&#xA;&#xA;[  250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0&#xA;[  250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0&#xA;[  250.218775] Modules linked in: hfcpci(-) mISDN_core&#xA;[  250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)&#xA;[  250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[  250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0&#xA;[  250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d&#xA;[  250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286&#xA;[  250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95&#xA;[  250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0&#xA;[  250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39&#xA;[  250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001&#xA;[  250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8&#xA;[  250.232454] FS:  00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000&#xA;[  250.233851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[  250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0&#xA;[  250.236117] Call Trace:&#xA;[  250.236599]  &lt;TASK&gt;&#xA;[  250.236967]  ? trace_irq_enable.constprop.0+0xd4/0x130&#xA;[  250.237920]  debug_object_assert_init+0x1f6/0x310&#xA;[  250.238762]  ? __pfx_debug_object_assert_init+0x10/0x10&#xA;[  250.239658]  ? __lock_acquire+0xdea/0x1c70&#xA;[  250.240369]  __try_to_del_timer_sync+0x69/0x140&#xA;[  250.241172]  ? __pfx___try_to_del_timer_sync+0x10/0x10&#xA;[  250.242058]  ? __timer_delete_sync+0xc6/0x120&#xA;[  250.242842]  ? lock_acquire+0x30/0x80&#xA;[  250.243474]  ? __timer_delete_sync+0xc6/0x120&#xA;[  250.244262]  __timer_delete_sync+0x98/0x120&#xA;[  250.245015]  HFC_cleanup+0x10/0x20 [hfcpci]&#xA;[  250.245704]  __do_sys_delete_module+0x348/0x510&#xA;[  250.246461]  ? __pfx___do_sys_delete_module+0x10/0x10&#xA;[  250.247338]  do_syscall_64+0xc1/0x360&#xA;[  250.247924]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;Fix this by initializing hfc_tl timer with DEFINE_TIMER macro.&#xA;Also, use mod_timer instead of manual timeout update.&#xA;CVE-2025-39846:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()&#xA;&#xA;In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to&#xA;res and used in pci_bus_alloc_resource(). There is a dereference of res&#xA;in pci_bus_alloc_resource(), which could lead to a NULL pointer&#xA;dereference on failure of pcmcia_make_resource().&#xA;&#xA;Fix this bug by adding a check of res.&#xA;CVE-2025-39847:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ppp: fix memory leak in pad_compress_skb&#xA;&#xA;If alloc_skb() fails in pad_compress_skb(), it returns NULL without&#xA;releasing the old skb. The caller does:&#xA;&#xA;    skb = pad_compress_skb(ppp, skb);&#xA;    if (!skb)&#xA;        goto drop;&#xA;&#xA;drop:&#xA;    kfree_skb(skb);&#xA;&#xA;When pad_compress_skb() returns NULL, the reference to the old skb is&#xA;lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.&#xA;&#xA;Align pad_compress_skb() semantics with realloc(): only free the old&#xA;skb if allocation and compression succeed.  At the call site, use the&#xA;new_skb variable so the original skb is not lost when pad_compress_skb()&#xA;fails.&#xA;CVE-2025-39885:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: fix recursive semaphore deadlock in fiemap call&#xA;&#xA;syzbot detected a OCFS2 hang due to a recursive semaphore on a&#xA;FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.&#xA;&#xA;context_switch kernel/sched/core.c:5357 [inline]&#xA;   __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961&#xA;   __schedule_loop kernel/sched/core.c:7043 [inline]&#xA;   schedule+0x165/0x360 kernel/sched/core.c:7058&#xA;   schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115&#xA;   rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185&#xA;   __down_write_common kernel/locking/rwsem.c:1317 [inline]&#xA;   __down_write kernel/locking/rwsem.c:1326 [inline]&#xA;   down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591&#xA;   ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142&#xA;   do_page_mkwrite+0x14d/0x310 mm/memory.c:3361&#xA;   wp_page_shared mm/memory.c:3762 [inline]&#xA;   do_wp_page+0x268d/0x5800 mm/memory.c:3981&#xA;   handle_pte_fault mm/memory.c:6068 [inline]&#xA;   __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195&#xA;   handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364&#xA;   do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387&#xA;   handle_page_fault arch/x86/mm/fault.c:1476 [inline]&#xA;   exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532&#xA;   asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623&#xA;RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]&#xA;RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]&#xA;RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]&#xA;RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26&#xA;Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89&#xA;f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 &lt;f3&gt; a4 0f&#xA;1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41&#xA;RSP: 0018:ffffc9000403f950 EFLAGS: 00050256&#xA;RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038&#xA;RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060&#xA;RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42&#xA;R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098&#xA;R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060&#xA;   copy_to_user include/linux/uaccess.h:225 [inline]&#xA;   fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145&#xA;   ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806&#xA;   ioctl_fiemap fs/ioctl.c:220 [inline]&#xA;   do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532&#xA;   __do_sys_ioctl fs/ioctl.c:596 [inline]&#xA;   __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584&#xA;   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;   do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f5f13850fd9&#xA;RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010&#xA;RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9&#xA;RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004&#xA;RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0&#xA;R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b&#xA;&#xA;ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since&#xA;v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the&#xA;extent list of this running mmap executable.  The user supplied buffer to&#xA;hold the fiemap information page faults calling ocfs2_page_mkwrite() which&#xA;will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same&#xA;semaphore.  This recursive semaphore will hold filesystem locks and causes&#xA;a hang of the fileystem.&#xA;&#xA;The ip_alloc_sem protects the inode extent list and size.  Release the&#xA;read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()&#xA;and ocfs2_fiemap_inline().  This does an unnecessary semaphore lock/unlock&#xA;on the last extent but simplifies the error path.&#xA;CVE-2025-39891:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mwifiex: Initialize the chan_stats array to zero&#xA;&#xA;The adapter-&gt;chan_stats[] array is initialized in&#xA;mwifiex_init_channel_scan_gap() with vmalloc(), which doesn&#39;t zero out&#xA;memory.  The array is filled in mwifiex_update_chan_statistics()&#xA;and then the user can query the data in mwifiex_cfg80211_dump_survey().&#xA;&#xA;There are two potential issues here.  What if the user calls&#xA;mwifiex_cfg80211_dump_survey() before the data has been filled in.&#xA;Also the mwifiex_update_chan_statistics() function doesn&#39;t necessarily&#xA;initialize the whole array.  Since the array was not initialized at&#xA;the start that could result in an information leak.&#xA;&#xA;Also this array is pretty small.  It&#39;s a maximum of 900 bytes so it&#39;s&#xA;more appropriate to use kcalloc() instead vmalloc().&#xA;CVE-2025-39894:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm&#xA;&#xA;When send a broadcast packet to a tap device, which was added to a bridge,&#xA;br_nf_local_in() is called to confirm the conntrack. If another conntrack&#xA;with the same hash value is added to the hash table, which can be&#xA;triggered by a normal packet to a non-bridge device, the below warning&#xA;may happen.&#xA;&#xA;  ------------[ cut here ]------------&#xA;  WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200&#xA;  CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary)&#xA;  RIP: 0010:br_nf_local_in+0x168/0x200&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   nf_hook_slow+0x3e/0xf0&#xA;   br_pass_frame_up+0x103/0x180&#xA;   br_handle_frame_finish+0x2de/0x5b0&#xA;   br_nf_hook_thresh+0xc0/0x120&#xA;   br_nf_pre_routing_finish+0x168/0x3a0&#xA;   br_nf_pre_routing+0x237/0x5e0&#xA;   br_handle_frame+0x1ec/0x3c0&#xA;   __netif_receive_skb_core+0x225/0x1210&#xA;   __netif_receive_skb_one_core+0x37/0xa0&#xA;   netif_receive_skb+0x36/0x160&#xA;   tun_get_user+0xa54/0x10c0&#xA;   tun_chr_write_iter+0x65/0xb0&#xA;   vfs_write+0x305/0x410&#xA;   ksys_write+0x60/0xd0&#xA;   do_syscall_64+0xa4/0x260&#xA;   entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;   &lt;/TASK&gt;&#xA;  ---[ end trace 0000000000000000 ]---&#xA;&#xA;To solve the hash conflict, nf_ct_resolve_clash() try to merge the&#xA;conntracks, and update skb-&gt;_nfct. However, br_nf_local_in() still use the&#xA;old ct from local variable &#39;nfct&#39; after confirm(), which leads to this&#xA;warning.&#xA;&#xA;If confirm() does not insert the conntrack entry and return NF_DROP, the&#xA;warning may also occur. There is no need to reserve the WARN_ON_ONCE, just&#xA;remove it.&#xA;CVE-2025-39920:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pcmcia: Add error handling for add_interval() in do_validate_mem()&#xA;&#xA;In the do_validate_mem(), the call to add_interval() does not&#xA;handle errors. If kmalloc() fails in add_interval(), it could&#xA;result in a null pointer being inserted into the linked list,&#xA;leading to illegal memory access when sub_interval() is called&#xA;next.&#xA;&#xA;This patch adds an error handling for the add_interval(). If&#xA;add_interval() returns an error, the function will return early&#xA;with the error code.&#xA;CVE-2025-39923:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees&#xA;&#xA;When we don&#39;t have a clock specified in the device tree, we have no way to&#xA;ensure the BAM is on. This is often the case for remotely-controlled or&#xA;remotely-powered BAM instances. In this case, we need to read num-channels&#xA;from the DT to have all the necessary information to complete probing.&#xA;&#xA;However, at the moment invalid device trees without clock and without&#xA;num-channels still continue probing, because the error handling is missing&#xA;return statements. The driver will then later try to read the number of&#xA;channels from the registers. This is unsafe, because it relies on boot&#xA;firmware and lucky timing to succeed. Unfortunately, the lack of proper&#xA;error handling here has been abused for several Qualcomm SoCs upstream,&#xA;causing early boot crashes in several situations [1, 2].&#xA;&#xA;Avoid these early crashes by erroring out when any of the required DT&#xA;properties are missing. Note that this will break some of the existing DTs&#xA;upstream (mainly BAM instances related to the crypto engine). However,&#xA;clearly these DTs have never been tested properly, since the error in the&#xA;kernel log was just ignored. It&#39;s safer to disable the crypto engine for&#xA;these broken DTBs.&#xA;&#xA;[1]: https://lore.kernel.org/r/[email protected]/&#xA;[2]: https://lore.kernel.org/r/[email protected]/&#xA;CVE-2025-39937:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer&#xA;&#xA;Since commit 7d5e9737efda (&#34;net: rfkill: gpio: get the name and type from&#xA;device property&#34;) rfkill_find_type() gets called with the possibly&#xA;uninitialized &#34;const char *type_name;&#34; local variable.&#xA;&#xA;On x86 systems when rfkill-gpio binds to a &#34;BCM4752&#34; or &#34;LNV4752&#34;&#xA;acpi_device, the rfkill-&gt;type is set based on the ACPI acpi_device_id:&#xA;&#xA;        rfkill-&gt;type = (unsigned)id-&gt;driver_data;&#xA;&#xA;and there is no &#34;type&#34; property so device_property_read_string() will fail&#xA;and leave type_name uninitialized, leading to a potential crash.&#xA;&#xA;rfkill_find_type() does accept a NULL pointer, fix the potential crash&#xA;by initializing type_name to NULL.&#xA;&#xA;Note likely sofar this has not been caught because:&#xA;&#xA;1. Not many x86 machines actually have a &#34;BCM4752&#34;/&#34;LNV4752&#34; acpi_device&#xA;2. The stack happened to contain NULL where type_name is stored&#xA;CVE-2025-39953:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;cgroup: split cgroup_destroy_wq into 3 workqueues&#xA;&#xA;A hung task can occur during [1] LTP cgroup testing when repeatedly&#xA;mounting/unmounting perf_event and net_prio controllers with&#xA;systemd.unified_cgroup_hierarchy=1. The hang manifests in&#xA;cgroup_lock_and_drain_offline() during root destruction.&#xA;&#xA;Related case:&#xA;cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event&#xA;cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio&#xA;&#xA;Call Trace:&#xA;&#x9;cgroup_lock_and_drain_offline+0x14c/0x1e8&#xA;&#x9;cgroup_destroy_root+0x3c/0x2c0&#xA;&#x9;css_free_rwork_fn+0x248/0x338&#xA;&#x9;process_one_work+0x16c/0x3b8&#xA;&#x9;worker_thread+0x22c/0x3b0&#xA;&#x9;kthread+0xec/0x100&#xA;&#x9;ret_from_fork+0x10/0x20&#xA;&#xA;Root Cause:&#xA;&#xA;CPU0                            CPU1&#xA;mount perf_event                umount net_prio&#xA;cgroup1_get_tree                cgroup_kill_sb&#xA;rebind_subsystems               // root destruction enqueues&#xA;&#x9;&#x9;&#x9;&#x9;// cgroup_destroy_wq&#xA;// kill all perf_event css&#xA;                                // one perf_event css A is dying&#xA;                                // css A offline enqueues cgroup_destroy_wq&#xA;                                // root destruction will be executed first&#xA;                                css_free_rwork_fn&#xA;                                cgroup_destroy_root&#xA;                                cgroup_lock_and_drain_offline&#xA;                                // some perf descendants are dying&#xA;                                // cgroup_destroy_wq max_active = 1&#xA;                                // waiting for css A to die&#xA;&#xA;Problem scenario:&#xA;1. CPU0 mounts perf_event (rebind_subsystems)&#xA;2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work&#xA;3. A dying perf_event CSS gets queued for offline after root destruction&#xA;4. Root destruction waits for offline completion, but offline work is&#xA;   blocked behind root destruction in cgroup_destroy_wq (max_active=1)&#xA;&#xA;Solution:&#xA;Split cgroup_destroy_wq into three dedicated workqueues:&#xA;cgroup_offline_wq – Handles CSS offline operations&#xA;cgroup_release_wq – Manages resource release&#xA;cgroup_free_wq – Performs final memory deallocation&#xA;&#xA;This separation eliminates blocking in the CSS free path while waiting for&#xA;offline operations to complete.&#xA;&#xA;[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers&#xA;CVE-2025-39955:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;tcp: Clear tcp_sk(sk)-&gt;fastopen_rsk in tcp_disconnect().&#xA;&#xA;syzbot reported the splat below where a socket had tcp_sk(sk)-&gt;fastopen_rsk&#xA;in the TCP_ESTABLISHED state. [0]&#xA;&#xA;syzbot reused the server-side TCP Fast Open socket as a new client before&#xA;the TFO socket completes 3WHS:&#xA;&#xA;  1. accept()&#xA;  2. connect(AF_UNSPEC)&#xA;  3. connect() to another destination&#xA;&#xA;As of accept(), sk-&gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes&#xA;it to TCP_CLOSE and makes connect() possible, which restarts timers.&#xA;&#xA;Since tcp_disconnect() forgot to clear tcp_sk(sk)-&gt;fastopen_rsk, the&#xA;retransmit timer triggered the warning and the intended packet was not&#xA;retransmitted.&#xA;&#xA;Let&#39;s call reqsk_fastopen_remove() in tcp_disconnect().&#xA;&#xA;[0]:&#xA;WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))&#xA;Modules linked in:&#xA;CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))&#xA;Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 &lt;0f&gt; 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e&#xA;RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293&#xA;RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017&#xA;RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400&#xA;RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8&#xA;R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540&#xA;R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0&#xA;FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; tcp_write_timer (net/ipv4/tcp_timer.c:738)&#xA; call_timer_fn (kernel/time/timer.c:1747)&#xA; __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)&#xA; timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)&#xA; tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)&#xA; __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))&#xA; tmigr_handle_remote (kernel/time/timer_migration.c:1096)&#xA; handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)&#xA; irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)&#xA; sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))&#xA; &lt;/IRQ&gt;&#xA;CVE-2025-39964:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg&#xA;&#xA;Issuing two writes to the same af_alg socket is bogus as the&#xA;data will be interleaved in an unpredictable fashion.  Furthermore,&#xA;concurrent writes may create inconsistencies in the internal&#xA;socket state.&#xA;&#xA;Disallow this by adding a new ctx-&gt;write field that indiciates&#xA;exclusive ownership for writing.&#xA;CVE-2025-39972:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;i40e: fix idx validation in i40e_validate_queue_map&#xA;&#xA;Ensure idx is within range of active/initialized TCs when iterating over&#xA;vf-&gt;ch[idx] in i40e_validate_queue_map().&#xA;CVE-2025-39980:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nexthop: Forbid FDB status change while nexthop is in a group&#xA;&#xA;The kernel forbids the creation of non-FDB nexthop groups with FDB&#xA;nexthops:&#xA;&#xA; # ip nexthop add id 1 via 192.0.2.1 fdb&#xA; # ip nexthop add id 2 group 1&#xA; Error: Non FDB nexthop group cannot have fdb nexthops.&#xA;&#xA;And vice versa:&#xA;&#xA; # ip nexthop add id 3 via 192.0.2.2 dev dummy1&#xA; # ip nexthop add id 4 group 3 fdb&#xA; Error: FDB nexthop group can only have fdb nexthops.&#xA;&#xA;However, as long as no routes are pointing to a non-FDB nexthop group,&#xA;the kernel allows changing the type of a nexthop from FDB to non-FDB and&#xA;vice versa:&#xA;&#xA; # ip nexthop add id 5 via 192.0.2.2 dev dummy1&#xA; # ip nexthop add id 6 group 5&#xA; # ip nexthop replace id 5 via 192.0.2.2 fdb&#xA; # echo $?&#xA; 0&#xA;&#xA;This configuration is invalid and can result in a NPD [1] since FDB&#xA;nexthops are not associated with a nexthop device:&#xA;&#xA; # ip route add 198.51.100.1/32 nhid 6&#xA; # ping 198.51.100.1&#xA;&#xA;Fix by preventing nexthop FDB status change while the nexthop is in a&#xA;group:&#xA;&#xA; # ip nexthop add id 7 via 192.0.2.2 dev dummy1&#xA; # ip nexthop add id 8 group 7&#xA; # ip nexthop replace id 7 via 192.0.2.2 fdb&#xA; Error: Cannot change nexthop FDB status while in a group.&#xA;&#xA;[1]&#xA;BUG: kernel NULL pointer dereference, address: 00000000000003c0&#xA;[...]&#xA;Oops: Oops: 0000 [#1] SMP&#xA;CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014&#xA;RIP: 0010:fib_lookup_good_nhc+0x1e/0x80&#xA;[...]&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; fib_table_lookup+0x541/0x650&#xA; ip_route_output_key_hash_rcu+0x2ea/0x970&#xA; ip_route_output_key_hash+0x55/0x80&#xA; __ip4_datagram_connect+0x250/0x330&#xA; udp_connect+0x2b/0x60&#xA; __sys_connect+0x9c/0xd0&#xA; __x64_sys_connect+0x18/0x20&#xA; do_syscall_64+0xa4/0x2a0&#xA; entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;CVE-2025-39996:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove&#xA;&#xA;The original code uses cancel_delayed_work() in flexcop_pci_remove(), which&#xA;does not guarantee that the delayed work item irq_check_work has fully&#xA;completed if it was already running. This leads to use-after-free scenarios&#xA;where flexcop_pci_remove() may free the flexcop_device while irq_check_work&#xA;is still active and attempts to dereference the device.&#xA;&#xA;A typical race condition is illustrated below:&#xA;&#xA;CPU 0 (remove)                         | CPU 1 (delayed work callback)&#xA;flexcop_pci_remove()                   | flexcop_pci_irq_check_work()&#xA;  cancel_delayed_work()                |&#xA;  flexcop_device_kfree(fc_pci-&gt;fc_dev) |&#xA;                                       |   fc = fc_pci-&gt;fc_dev; // UAF&#xA;&#xA;This is confirmed by a KASAN report:&#xA;&#xA;==================================================================&#xA;BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0&#xA;Write of size 8 at addr ffff8880093aa8c8 by task bash/135&#xA;...&#xA;Call Trace:&#xA; &lt;IRQ&gt;&#xA; dump_stack_lvl+0x55/0x70&#xA; print_report+0xcf/0x610&#xA; ? __run_timer_base.part.0+0x7d7/0x8c0&#xA; kasan_report+0xb8/0xf0&#xA; ? __run_timer_base.part.0+0x7d7/0x8c0&#xA; __run_timer_base.part.0+0x7d7/0x8c0&#xA; ? __pfx___run_timer_base.part.0+0x10/0x10&#xA; ? __pfx_read_tsc+0x10/0x10&#xA; ? ktime_get+0x60/0x140&#xA; ? lapic_next_event+0x11/0x20&#xA; ? clockevents_program_event+0x1d4/0x2a0&#xA; run_timer_softirq+0xd1/0x190&#xA; handle_softirqs+0x16a/0x550&#xA; irq_exit_rcu+0xaf/0xe0&#xA; sysvec_apic_timer_interrupt+0x70/0x80&#xA; &lt;/IRQ&gt;&#xA;...&#xA;&#xA;Allocated by task 1:&#xA; kasan_save_stack+0x24/0x50&#xA; kasan_save_track+0x14/0x30&#xA; __kasan_kmalloc+0x7f/0x90&#xA; __kmalloc_noprof+0x1be/0x460&#xA; flexcop_device_kmalloc+0x54/0xe0&#xA; flexcop_pci_probe+0x1f/0x9d0&#xA; local_pci_probe+0xdc/0x190&#xA; pci_device_probe+0x2fe/0x470&#xA; really_probe+0x1ca/0x5c0&#xA; __driver_probe_device+0x248/0x310&#xA; driver_probe_device+0x44/0x120&#xA; __driver_attach+0xd2/0x310&#xA; bus_for_each_dev+0xed/0x170&#xA; bus_add_driver+0x208/0x500&#xA; driver_register+0x132/0x460&#xA; do_one_initcall+0x89/0x300&#xA; kernel_init_freeable+0x40d/0x720&#xA; kernel_init+0x1a/0x150&#xA; ret_from_fork+0x10c/0x1a0&#xA; ret_from_fork_asm+0x1a/0x30&#xA;&#xA;Freed by task 135:&#xA; kasan_save_stack+0x24/0x50&#xA; kasan_save_track+0x14/0x30&#xA; kasan_save_free_info+0x3a/0x60&#xA; __kasan_slab_free+0x3f/0x50&#xA; kfree+0x137/0x370&#xA; flexcop_device_kfree+0x32/0x50&#xA; pci_device_remove+0xa6/0x1d0&#xA; device_release_driver_internal+0xf8/0x210&#xA; pci_stop_bus_device+0x105/0x150&#xA; pci_stop_and_remove_bus_device_locked+0x15/0x30&#xA; remove_store+0xcc/0xe0&#xA; kernfs_fop_write_iter+0x2c3/0x440&#xA; vfs_write+0x871/0xd70&#xA; ksys_write+0xee/0x1c0&#xA; do_syscall_64+0xac/0x280&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;...&#xA;&#xA;Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure&#xA;that the delayed work item is properly canceled and any executing delayed&#xA;work has finished before the device memory is deallocated.&#xA;&#xA;This bug was initially identified through static analysis. To reproduce&#xA;and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced&#xA;artificial delays within the flexcop_pci_irq_check_work() function to&#xA;increase the likelihood of triggering the bug.&#xA;CVE-2025-40006:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/hugetlb: fix folio is still mapped when deleted&#xA;&#xA;Migration may be raced with fallocating hole.  remove_inode_single_folio&#xA;will unmap the folio if the folio is still mapped.  However, it&#39;s called&#xA;without folio lock.  If the folio is migrated and the mapped pte has been&#xA;converted to migration entry, folio_mapped() returns false, and won&#39;t&#xA;unmap it.  Due to extra refcount held by remove_inode_single_folio,&#xA;migration fails, restores migration entry to normal pte, and the folio is&#xA;mapped again.  As a result, we triggered BUG in filemap_unaccount_folio.&#xA;&#xA;The log is as follows:&#xA; BUG: Bad page cache in process hugetlb  pfn:156c00&#xA; page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00&#xA; head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0&#xA; aops:hugetlbfs_aops ino:dcc dentry name(?):&#34;my_hugepage_file&#34;&#xA; flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)&#xA; page_type: f4(hugetlb)&#xA; page dumped because: still mapped when deleted&#xA; CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE&#xA; Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  dump_stack_lvl+0x4f/0x70&#xA;  filemap_unaccount_folio+0xc4/0x1c0&#xA;  __filemap_remove_folio+0x38/0x1c0&#xA;  filemap_remove_folio+0x41/0xd0&#xA;  remove_inode_hugepages+0x142/0x250&#xA;  hugetlbfs_fallocate+0x471/0x5a0&#xA;  vfs_fallocate+0x149/0x380&#xA;&#xA;Hold folio lock before checking if the folio is mapped to avold race with&#xA;migration.&#xA;CVE-2025-40011:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/gma500: Fix null dereference in hdmi teardown&#xA;&#xA;pci_set_drvdata sets the value of pdev-&gt;driver_data to NULL,&#xA;after which the driver_data obtained from the same dev is&#xA;dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is&#xA;extracted from it. To prevent this, swap these calls.&#xA;&#xA;Found by Linux Verification Center (linuxtesting.org) with Svacer.&#xA;CVE-2025-40020:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: peak_usb: fix shift-out-of-bounds issue&#xA;&#xA;Explicitly uses a 64-bit constant when the number of bits used for its&#xA;shifting is 32 (which is the case for PC CAN FD interfaces supported by&#xA;this driver).&#xA;&#xA;[mkl: update subject, apply manually]&#xA;CVE-2025-40030:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pinctrl: check the return value of pinmux_ops::get_function_name()&#xA;&#xA;While the API contract in docs doesn&#39;t specify it explicitly, the&#xA;generic implementation of the get_function_name() callback from struct&#xA;pinmux_ops - pinmux_generic_get_function_name() - can fail and return&#xA;NULL. This is already checked in pinmux_check_ops() so add a similar&#xA;check in pinmux_func_name_to_selector() instead of passing the returned&#xA;pointer right down to strcmp() where the NULL can get dereferenced. This&#xA;is normal operation when adding new pinfunctions.&#xA;CVE-2025-40035:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak&#xA;&#xA;Struct ff_effect_compat is embedded twice inside&#xA;uinput_ff_upload_compat, contains internal padding. In particular, there&#xA;is a hole after struct ff_replay to satisfy alignment requirements for&#xA;the following union member. Without clearing the structure,&#xA;copy_to_user() may leak stack data to userspace.&#xA;&#xA;Initialize ff_up_compat to zero before filling valid fields.&#xA;CVE-2025-40053:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: dlink: handle copy_thresh allocation failure&#xA;&#xA;The driver did not handle failure of `netdev_alloc_skb_ip_align()`.&#xA;If the allocation failed, dereferencing `skb-&gt;protocol` could lead to&#xA;a NULL pointer dereference.&#xA;&#xA;This patch tries to allocate `skb`. If the allocation fails, it falls&#xA;back to the normal path.&#xA;&#xA;Tested-on: D-Link DGE-550T Rev-A3&#xA;CVE-2025-40064:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smc: Fix use-after-free in __pnet_find_base_ndev().&#xA;&#xA;syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),&#xA;which was called during connect(). [0]&#xA;&#xA;smc_pnet_find_ism_resource() fetches sk_dst_get(sk)-&gt;dev and passes&#xA;down to pnet_find_base_ndev(), where RTNL is held.  Then, UAF happened&#xA;at __pnet_find_base_ndev() when the dev is first used.&#xA;&#xA;This means dev had already been freed before acquiring RTNL in&#xA;pnet_find_base_ndev().&#xA;&#xA;While dev is going away, dst-&gt;dev could be swapped with blackhole_netdev,&#xA;and the dev&#39;s refcnt by dst will be released.&#xA;&#xA;We must hold dev&#39;s refcnt before calling smc_pnet_find_ism_resource().&#xA;&#xA;Also, smc_pnet_find_roce_resource() has the same problem.&#xA;&#xA;Let&#39;s use __sk_dst_get() and dst_dev_rcu() in the two functions.&#xA;&#xA;[0]:&#xA;BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926&#xA;Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609&#xA;&#xA;CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120&#xA; print_address_description mm/kasan/report.c:378 [inline]&#xA; print_report+0xca/0x240 mm/kasan/report.c:482&#xA; kasan_report+0x118/0x150 mm/kasan/report.c:595&#xA; __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926&#xA; pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline]&#xA; smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline]&#xA; smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154&#xA; smc_find_ism_device net/smc/af_smc.c:1030 [inline]&#xA; smc_find_proposal_devices net/smc/af_smc.c:1115 [inline]&#xA; __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545&#xA; smc_connect+0x877/0xd90 net/smc/af_smc.c:1715&#xA; __sys_connect_file net/socket.c:2086 [inline]&#xA; __sys_connect+0x313/0x440 net/socket.c:2105&#xA; __do_sys_connect net/socket.c:2111 [inline]&#xA; __se_sys_connect net/socket.c:2108 [inline]&#xA; __x64_sys_connect+0x7a/0x90 net/socket.c:2108&#xA; do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA; do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7f47cbf8eba9&#xA;Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48&#xA;RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a&#xA;RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9&#xA;RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b&#xA;RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8&#xA; &lt;/TASK&gt;&#xA;&#xA;The buggy address belongs to the physical page:&#xA;page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac&#xA;flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)&#xA;raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000&#xA;raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000&#xA;page dumped because: kasan: bad access detected&#xA;page_owner tracks the page as freed&#xA;page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466&#xA; set_page_owner include/linux/page_owner.h:32 [inline]&#xA; post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851&#xA; prep_new_page mm/page_alloc.c:1859 [inline]&#xA; get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858&#xA; __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148&#xA; alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416&#xA; ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317&#xA; __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348&#xA; __do_kmalloc_node mm/slub.c:4364 [inline]&#xA; __kvmalloc_node&#xA;---truncated---&#xA;CVE-2025-40078:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Explicitly check accesses to bpf_sock_addr&#xA;&#xA;Syzkaller found a kernel warning on the following sock_addr program:&#xA;&#xA;    0: r0 = 0&#xA;    1: r2 = *(u32 *)(r1 +60)&#xA;    2: exit&#xA;&#xA;which triggers:&#xA;&#xA;    verifier bug: error during ctx access conversion (0)&#xA;&#xA;This is happening because offset 60 in bpf_sock_addr corresponds to an&#xA;implicit padding of 4 bytes, right after msg_src_ip4. Access to this&#xA;padding isn&#39;t rejected in sock_addr_is_valid_access and it thus later&#xA;fails to convert the access.&#xA;&#xA;This patch fixes it by explicitly checking the various fields of&#xA;bpf_sock_addr in sock_addr_is_valid_access.&#xA;&#xA;I checked the other ctx structures and is_valid_access functions and&#xA;didn&#39;t find any other similar cases. Other cases of (properly handled)&#xA;padding are covered in new tests in a subsequent patch.&#xA;CVE-2025-40083:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: sch_qfq: Fix null-deref in agg_dequeue&#xA;&#xA;To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)&#xA;when cl-&gt;qdisc-&gt;ops-&gt;peek(cl-&gt;qdisc) returns NULL, we check the return&#xA;value before using it, similar to the existing approach in sch_hfsc.c.&#xA;&#xA;To avoid code duplication, the following changes are made:&#xA;&#xA;1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static&#xA;inline function.&#xA;&#xA;2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to&#xA;include/net/pkt_sched.h so that sch_qfq can reuse it.&#xA;&#xA;3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.&#xA;CVE-2025-40109:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: rng - Ensure set_ent is always present&#xA;&#xA;Ensure that set_ent is always set since only drbg provides it.&#xA;CVE-2025-40121:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping&#xA;&#xA;When an invalid value is passed via quirk option, currently&#xA;bytcr_rt5640 driver just ignores and leaves as is, which may lead to&#xA;unepxected results like OOB access.&#xA;&#xA;This patch adds the sanity check and corrects the input mapping to the&#xA;certain default value if an invalid value is passed.&#xA;CVE-2025-40125:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctx&#xA;&#xA;In __blk_mq_update_nr_hw_queues() the return value of&#xA;blk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctx&#xA;fails, later changing the number of hw_queues or removing disk will&#xA;trigger the following warning:&#xA;&#xA;  kernfs: can not remove &#39;nr_tags&#39;, no directory&#xA;  WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160&#xA;  Call Trace:&#xA;   remove_files.isra.1+0x38/0xb0&#xA;   sysfs_remove_group+0x4d/0x100&#xA;   sysfs_remove_groups+0x31/0x60&#xA;   __kobject_del+0x23/0xf0&#xA;   kobject_del+0x17/0x40&#xA;   blk_mq_unregister_hctx+0x5d/0x80&#xA;   blk_mq_sysfs_unregister_hctxs+0x94/0xd0&#xA;   blk_mq_update_nr_hw_queues+0x124/0x760&#xA;   nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]&#xA;   nullb_device_submit_queues_store+0x92/0x120 [null_blk]&#xA;&#xA;kobjct_del() was called unconditionally even if sysfs creation failed.&#xA;Fix it by checkig the kobject creation statusbefore deleting it.&#xA;CVE-2025-40134:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm: fix NULL pointer dereference in __dm_suspend()&#xA;&#xA;There is a race condition between dm device suspend and table load that&#xA;can lead to null pointer dereference. The issue occurs when suspend is&#xA;invoked before table load completes:&#xA;&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000054&#xA;Oops: 0000 [#1] PREEMPT SMP PTI&#xA;CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014&#xA;RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50&#xA;Call Trace:&#xA;  &lt;TASK&gt;&#xA;  blk_mq_quiesce_queue+0x2c/0x50&#xA;  dm_stop_queue+0xd/0x20&#xA;  __dm_suspend+0x130/0x330&#xA;  dm_suspend+0x11a/0x180&#xA;  dev_suspend+0x27e/0x560&#xA;  ctl_ioctl+0x4cf/0x850&#xA;  dm_ctl_ioctl+0xd/0x20&#xA;  vfs_ioctl+0x1d/0x50&#xA;  __se_sys_ioctl+0x9b/0xc0&#xA;  __x64_sys_ioctl+0x19/0x30&#xA;  x64_sys_call+0x2c4a/0x4620&#xA;  do_syscall_64+0x9e/0x1b0&#xA;&#xA;The issue can be triggered as below:&#xA;&#xA;T1 &#x9;&#x9;&#x9;&#x9;&#x9;&#x9;T2&#xA;dm_suspend&#x9;&#x9;&#x9;&#x9;&#x9;table_load&#xA;__dm_suspend&#x9;&#x9;&#x9;&#x9;&#x9;dm_setup_md_queue&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;dm_mq_init_request_queue&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;blk_mq_init_allocated_queue&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;=&gt; q-&gt;mq_ops = set-&gt;ops; (1)&#xA;dm_stop_queue / dm_wait_for_completion&#xA;=&gt; q-&gt;tag_set NULL pointer!&#x9;(2)&#xA;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;=&gt; q-&gt;tag_set = set; (3)&#xA;&#xA;Fix this by checking if a valid table (map) exists before performing&#xA;request-based suspend and waiting for target I/O. When map is NULL,&#xA;skip these table-dependent suspend steps.&#xA;&#xA;Even when map is NULL, no I/O can reach any target because there is&#xA;no table loaded; I/O submitted in this state will fail early in the&#xA;DM layer. Skipping the table-dependent suspend logic in this case&#xA;is safe and avoids NULL pointer dereferences.&#xA;CVE-2025-40140:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast&#xA;&#xA;syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.&#xA;This is the sequence of events that leads to the warning:&#xA;&#xA;rtl8150_start_xmit() {&#xA;&#x9;netif_stop_queue();&#xA;&#x9;usb_submit_urb(dev-&gt;tx_urb);&#xA;}&#xA;&#xA;rtl8150_set_multicast() {&#xA;&#x9;netif_stop_queue();&#xA;&#x9;netif_wake_queue();&#x9;&#x9;&lt;-- wakes up TX queue before URB is done&#xA;}&#xA;&#xA;rtl8150_start_xmit() {&#xA;&#x9;netif_stop_queue();&#xA;&#x9;usb_submit_urb(dev-&gt;tx_urb);&#x9;&lt;-- double submission&#xA;}&#xA;&#xA;rtl8150_set_multicast being the ndo_set_rx_mode callback should not be&#xA;calling netif_stop_queue and notif_start_queue as these handle&#xA;TX queue synchronization.&#xA;&#xA;The net core function dev_set_rx_mode handles the synchronization&#xA;for rtl8150_set_multicast making it safe to remove these locks.&#xA;CVE-2025-40153:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm: hugetlb: avoid soft lockup when mprotect to large memory area&#xA;&#xA;When calling mprotect() to a large hugetlb memory area in our customer&#39;s&#xA;workload (~300GB hugetlb memory), soft lockup was observed:&#xA;&#xA;watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]&#xA;&#xA;CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7&#xA;Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025&#xA;pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;pc : mte_clear_page_tags+0x14/0x24&#xA;lr : mte_sync_tags+0x1c0/0x240&#xA;sp : ffff80003150bb80&#xA;x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000&#xA;x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458&#xA;x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000&#xA;x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000&#xA;x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000&#xA;x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000&#xA;x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c&#xA;x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000&#xA;x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000&#xA;x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000&#xA;&#xA;Call trace:&#xA;  mte_clear_page_tags+0x14/0x24&#xA;  set_huge_pte_at+0x25c/0x280&#xA;  hugetlb_change_protection+0x220/0x430&#xA;  change_protection+0x5c/0x8c&#xA;  mprotect_fixup+0x10c/0x294&#xA;  do_mprotect_pkey.constprop.0+0x2e0/0x3d4&#xA;  __arm64_sys_mprotect+0x24/0x44&#xA;  invoke_syscall+0x50/0x160&#xA;  el0_svc_common+0x48/0x144&#xA;  do_el0_svc+0x30/0xe0&#xA;  el0_svc+0x30/0xf0&#xA;  el0t_64_sync_handler+0xc4/0x148&#xA;  el0t_64_sync+0x1a4/0x1a8&#xA;&#xA;Soft lockup is not triggered with THP or base page because there is&#xA;cond_resched() called for each PMD size.&#xA;&#xA;Although the soft lockup was triggered by MTE, it should be not MTE&#xA;specific.  The other processing which takes long time in the loop may&#xA;trigger soft lockup too.&#xA;&#xA;So add cond_resched() for hugetlb to avoid soft lockup.&#xA;CVE-2025-40154:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping&#xA;&#xA;When an invalid value is passed via quirk option, currently&#xA;bytcr_rt5640 driver only shows an error message but leaves as is.&#xA;This may lead to unepxected results like OOB access.&#xA;&#xA;This patch corrects the input mapping to the certain default value if&#xA;an invalid value is passed.&#xA;CVE-2025-40167:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: detect invalid INLINE_DATA + EXTENTS flag combination&#xA;&#xA;syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity&#xA;file on a corrupted ext4 filesystem mounted without a journal.&#xA;&#xA;The issue is that the filesystem has an inode with both the INLINE_DATA&#xA;and EXTENTS flags set:&#xA;&#xA;    EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15:&#xA;    comm syz.0.17: corrupted extent tree: lblk 0 &lt; prev 66&#xA;&#xA;Investigation revealed that the inode has both flags set:&#xA;    DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1&#xA;&#xA;This is an invalid combination since an inode should have either:&#xA;- INLINE_DATA: data stored directly in the inode&#xA;- EXTENTS: data stored in extent-mapped blocks&#xA;&#xA;Having both flags causes ext4_has_inline_data() to return true, skipping&#xA;extent tree validation in __ext4_iget(). The unvalidated out-of-order&#xA;extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer&#xA;underflow when calculating hole sizes.&#xA;&#xA;Fix this by detecting this invalid flag combination early in ext4_iget()&#xA;and rejecting the corrupted inode.&#xA;CVE-2025-40173:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/ip6_tunnel: Prevent perpetual tunnel growth&#xA;&#xA;Similarly to ipv4 tunnel, ipv6 version updates dev-&gt;needed_headroom, too.&#xA;While ipv4 tunnel headroom adjustment growth was limited in&#xA;commit 5ae1e9922bbd (&#34;net: ip_tunnel: prevent perpetual headroom growth&#34;),&#xA;ipv6 tunnel yet increases the headroom without any ceiling.&#xA;&#xA;Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.&#xA;&#xA;Credits to Francesco Ruggeri, who was originally debugging this issue&#xA;and wrote local Arista-specific patch and a reproducer.&#xA;CVE-2025-40187:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()&#xA;&#xA;If new_asoc-&gt;peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0&#xA;and sctp_ulpevent_make_authkey() returns 0, then the variable&#xA;ai_ev remains zero and the zero will be dereferenced&#xA;in the sctp_ulpevent_free() function.&#xA;CVE-2025-40198:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()&#xA;&#xA;Unlike other strings in the ext4 superblock, we rely on tune2fs to&#xA;make sure s_mount_opts is NUL terminated.  Harden&#xA;parse_apply_sb_mount_options() by treating s_mount_opts as a potential&#xA;__nonstring.&#xA;CVE-2025-40219:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI/IOV: Fix race between SR-IOV enable/disable and hotplug&#xA;&#xA;Commit 05703271c3cd (&#34;PCI/IOV: Add PCI rescan-remove locking when&#xA;enabling/disabling SR-IOV&#34;) tried to fix a race between the VF removal&#xA;inside sriov_del_vfs() and concurrent hot unplug by taking the PCI&#xA;rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock&#xA;was also taken in sriov_add_vfs() to protect addition of VFs.&#xA;&#xA;This approach however causes deadlock on trying to remove PFs with SR-IOV&#xA;enabled because PFs disable SR-IOV during removal and this removal happens&#xA;under the PCI rescan/remove lock. So the original fix had to be reverted.&#xA;&#xA;Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and&#xA;sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs&#xA;hotplug higher up in the callchain by taking the lock in&#xA;sriov_numvfs_store() before calling into the driver&#39;s sriov_configure()&#xA;callback.&#xA;CVE-2025-40220:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fuse: fix livelock in synchronous file put from fuseblk workers&#xA;&#xA;I observed a hang when running generic/323 against a fuseblk server.&#xA;This test opens a file, initiates a lot of AIO writes to that file&#xA;descriptor, and closes the file descriptor before the writes complete.&#xA;Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for&#xA;responses from the fuseblk server:&#xA;&#xA;# cat /proc/372265/task/372313/stack&#xA;[&lt;0&gt;] request_wait_answer+0x1fe/0x2a0 [fuse]&#xA;[&lt;0&gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]&#xA;[&lt;0&gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]&#xA;[&lt;0&gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]&#xA;[&lt;0&gt;] aio_read+0x130/0x1e0&#xA;[&lt;0&gt;] io_submit_one+0x542/0x860&#xA;[&lt;0&gt;] __x64_sys_io_submit+0x98/0x1a0&#xA;[&lt;0&gt;] do_syscall_64+0x37/0xf0&#xA;[&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;But the /weird/ part is that the fuseblk server threads are waiting for&#xA;responses from itself:&#xA;&#xA;# cat /proc/372210/task/372232/stack&#xA;[&lt;0&gt;] request_wait_answer+0x1fe/0x2a0 [fuse]&#xA;[&lt;0&gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]&#xA;[&lt;0&gt;] fuse_file_put+0x9a/0xd0 [fuse]&#xA;[&lt;0&gt;] fuse_release+0x36/0x50 [fuse]&#xA;[&lt;0&gt;] __fput+0xec/0x2b0&#xA;[&lt;0&gt;] task_work_run+0x55/0x90&#xA;[&lt;0&gt;] syscall_exit_to_user_mode+0xe9/0x100&#xA;[&lt;0&gt;] do_syscall_64+0x43/0xf0&#xA;[&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&#xA;&#xA;The fuseblk server is fuse2fs so there&#39;s nothing all that exciting in&#xA;the server itself.  So why is the fuse server calling fuse_file_put?&#xA;The commit message for the fstest sheds some light on that:&#xA;&#xA;&#34;By closing the file descriptor before calling io_destroy, you pretty&#xA;much guarantee that the last put on the ioctx will be done in interrupt&#xA;context (during I/O completion).&#xA;&#xA;Aha.  AIO fgets a new struct file from the fd when it queues the ioctx.&#xA;The completion of the FUSE_WRITE command from userspace causes the fuse&#xA;server to call the AIO completion function.  The completion puts the&#xA;struct file, queuing a delayed fput to the fuse server task.  When the&#xA;fuse server task returns to userspace, it has to run the delayed fput,&#xA;which in the case of a fuseblk server, it does synchronously.&#xA;&#xA;Sending the FUSE_RELEASE command sychronously from fuse server threads&#xA;is a bad idea because a client program can initiate enough simultaneous&#xA;AIOs such that all the fuse server threads end up in delayed_fput, and&#xA;now there aren&#39;t any threads left to handle the queued fuse commands.&#xA;&#xA;Fix this by only using asynchronous fputs when closing files, and leave&#xA;a comment explaining why.&#xA;CVE-2025-40233:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: clear extent cache after moving/defragmenting extents&#xA;&#xA;The extent map cache can become stale when extents are moved or&#xA;defragmented, causing subsequent operations to see outdated extent flags. &#xA;This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().&#xA;&#xA;The problem occurs when:&#xA;1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED&#xA;2. ioctl(FITRIM) triggers ocfs2_move_extents()&#xA;3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)&#xA;4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()&#xA;   which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)&#xA;5. The extent map cache is not invalidated after the move&#xA;6. Later write() operations read stale cached flags (0x2) but disk has&#xA;   updated flags (0x0), causing a mismatch&#xA;7. BUG_ON(!(rec-&gt;e_flags &amp; OCFS2_EXT_REFCOUNTED)) triggers&#xA;&#xA;Fix by clearing the extent map cache after each extent move/defrag&#xA;operation in __ocfs2_move_extents_range().  This ensures subsequent&#xA;operations read fresh extent data from disk.&#xA;CVE-2025-40240:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: avoid NULL dereference when chunk data buffer is missing&#xA;&#xA;chunk-&gt;skb pointer is dereferenced in the if-block where it&#39;s supposed&#xA;to be NULL only.&#xA;&#xA;chunk-&gt;skb can only be NULL if chunk-&gt;head_skb is not. Check for frag_list&#xA;instead and do it just before replacing chunk-&gt;skb. We&#39;re sure that&#xA;otherwise chunk-&gt;skb is non-NULL because of outer if() condition.&#xA;CVE-2025-40248:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;vsock: Ignore signal/timeout on connect() if already established&#xA;&#xA;During connect(), acting on a signal/timeout by disconnecting an already&#xA;established socket leads to several issues:&#xA;&#xA;1. connect() invoking vsock_transport_cancel_pkt() -&gt;&#xA;   virtio_transport_purge_skbs() may race with sendmsg() invoking&#xA;   virtio_transport_get_credit(). This results in a permanently elevated&#xA;   `vvs-&gt;bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.&#xA;&#xA;2. connect() resetting a connected socket&#39;s state may race with socket&#xA;   being placed in a sockmap. A disconnected socket remaining in a sockmap&#xA;   breaks sockmap&#39;s assumptions. And gives rise to WARNs.&#xA;&#xA;3. connect() transitioning SS_CONNECTED -&gt; SS_UNCONNECTED allows for a&#xA;   transport change/drop after TCP_ESTABLISHED. Which poses a problem for&#xA;   any simultaneous sendmsg() or connect() and may result in a&#xA;   use-after-free/null-ptr-deref.&#xA;&#xA;Do not disconnect socket on signal/timeout. Keep the logic for unconnected&#xA;sockets: they don&#39;t linger, can&#39;t be placed in a sockmap, are rejected by&#xA;sendmsg().&#xA;&#xA;[1]: https://lore.kernel.org/netdev/[email protected]/&#xA;[2]: https://lore.kernel.org/netdev/[email protected]/&#xA;[3]: https://lore.kernel.org/netdev/[email protected]/&#xA;CVE-2025-40253:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;s390/ctcm: Fix double-kfree&#xA;&#xA;The function &#39;mpc_rcvd_sweep_req(mpcginfo)&#39; is called conditionally&#xA;from function &#39;ctcmpc_unpack_skb&#39;. It frees passed mpcginfo.&#xA;After that a call to function &#39;kfree&#39; in function &#39;ctcmpc_unpack_skb&#39;&#xA;frees it again.&#xA;&#xA;Remove &#39;kfree&#39; call in function &#39;mpc_rcvd_sweep_req(mpcginfo)&#39;.&#xA;&#xA;Bug detected by the clang static analyzer.&#xA;CVE-2025-40254:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: openvswitch: remove never-working support for setting nsh fields&#xA;&#xA;The validation of the set(nsh(...)) action is completely wrong.&#xA;It runs through the nsh_key_put_from_nlattr() function that is the&#xA;same function that validates NSH keys for the flow match and the&#xA;push_nsh() action.  However, the set(nsh(...)) has a very different&#xA;memory layout.  Nested attributes in there are doubled in size in&#xA;case of the masked set().  That makes proper validation impossible.&#xA;&#xA;There is also confusion in the code between the &#39;masked&#39; flag, that&#xA;says that the nested attributes are doubled in size containing both&#xA;the value and the mask, and the &#39;is_mask&#39; that says that the value&#xA;we&#39;re parsing is the mask.  This is causing kernel crash on trying to&#xA;write into mask part of the match with SW_FLOW_KEY_PUT() during&#xA;validation, while validate_nsh() doesn&#39;t allocate any memory for it:&#xA;&#xA;  BUG: kernel NULL pointer dereference, address: 0000000000000018&#xA;  #PF: supervisor read access in kernel mode&#xA;  #PF: error_code(0x0000) - not-present page&#xA;  PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0&#xA;  Oops: Oops: 0000 [#1] SMP NOPTI&#xA;  CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)&#xA;  RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]&#xA;  Call Trace:&#xA;   &lt;TASK&gt;&#xA;   validate_nsh+0x60/0x90 [openvswitch]&#xA;   validate_set.constprop.0+0x270/0x3c0 [openvswitch]&#xA;   __ovs_nla_copy_actions+0x477/0x860 [openvswitch]&#xA;   ovs_nla_copy_actions+0x8d/0x100 [openvswitch]&#xA;   ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]&#xA;   genl_family_rcv_msg_doit+0xdb/0x130&#xA;   genl_family_rcv_msg+0x14b/0x220&#xA;   genl_rcv_msg+0x47/0xa0&#xA;   netlink_rcv_skb+0x53/0x100&#xA;   genl_rcv+0x24/0x40&#xA;   netlink_unicast+0x280/0x3b0&#xA;   netlink_sendmsg+0x1f7/0x430&#xA;   ____sys_sendmsg+0x36b/0x3a0&#xA;   ___sys_sendmsg+0x87/0xd0&#xA;   __sys_sendmsg+0x6d/0xd0&#xA;   do_syscall_64+0x7b/0x2c0&#xA;   entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;The third issue with this process is that while trying to convert&#xA;the non-masked set into masked one, validate_set() copies and doubles&#xA;the size of the OVS_KEY_ATTR_NSH as if it didn&#39;t have any nested&#xA;attributes.  It should be copying each nested attribute and doubling&#xA;them in size independently.  And the process must be properly reversed&#xA;during the conversion back from masked to a non-masked variant during&#xA;the flow dump.&#xA;&#xA;In the end, the only two outcomes of trying to use this action are&#xA;either validation failure or a kernel crash.  And if somehow someone&#xA;manages to install a flow with such an action, it will most definitely&#xA;not do what it is supposed to, since all the keys and the masks are&#xA;mixed up.&#xA;&#xA;Fixing all the issues is a complex task as it requires re-writing&#xA;most of the validation code.&#xA;&#xA;Given that and the fact that this functionality never worked since&#xA;introduction, let&#39;s just remove it altogether.  It&#39;s better to&#xA;re-introduce it later with a proper implementation instead of trying&#xA;to fix it in stable releases.&#xA;CVE-2025-40262:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Input: imx_sc_key - fix memory corruption on unload&#xA;&#xA;This is supposed to be &#34;priv&#34; but we accidentally pass &#34;&amp;priv&#34; which is&#xA;an address in the stack and so it will lead to memory corruption when&#xA;the imx_sc_key_action() function is called.  Remove the &amp;.&#xA;CVE-2025-40263:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Input: cros_ec_keyb - fix an invalid memory access&#xA;&#xA;If cros_ec_keyb_register_matrix() isn&#39;t called (due to&#xA;`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev-&gt;idev` remains&#xA;NULL.  An invalid memory access is observed in cros_ec_keyb_process()&#xA;when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()&#xA;in such case.&#xA;&#xA;  Unable to handle kernel read from unreadable memory at virtual address 0000000000000028&#xA;  ...&#xA;  x3 : 0000000000000000 x2 : 0000000000000000&#xA;  x1 : 0000000000000000 x0 : 0000000000000000&#xA;  Call trace:&#xA;  input_event&#xA;  cros_ec_keyb_work&#xA;  blocking_notifier_call_chain&#xA;  ec_irq_thread&#xA;&#xA;It&#39;s still unknown about why the kernel receives such malformed event,&#xA;in any cases, the kernel shouldn&#39;t access `ckdev-&gt;idev` and friends if&#xA;the driver doesn&#39;t intend to initialize them.&#xA;CVE-2025-40264:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;be2net: pass wrb_params in case of OS2BMC&#xA;&#xA;be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL&#xA;at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL&#xA;pointer when processing a workaround for specific packet, as commit&#xA;bc0c3405abbb (&#34;be2net: fix a Tx stall bug caused by a specific ipv6&#xA;packet&#34;) states.&#xA;&#xA;The correct way would be to pass the wrb_params from be_xmit().&#xA;CVE-2025-40275:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd&#xA;&#xA;In snd_usb_create_streams(), for UAC version 3 devices, the Interface&#xA;Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this&#xA;call fails, a fallback routine attempts to obtain the IAD from the next&#xA;interface and sets a BADD profile. However, snd_usb_mixer_controls_badd()&#xA;assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,&#xA;without performing a NULL check. This can lead to a NULL pointer&#xA;dereference when usb_ifnum_to_if() fails to find the interface descriptor.&#xA;&#xA;This patch adds a NULL pointer check after calling usb_ifnum_to_if() in&#xA;snd_usb_mixer_controls_badd() to prevent the dereference.&#xA;&#xA;This issue was discovered by syzkaller, which triggered the bug by sending&#xA;a crafted USB device descriptor.&#xA;CVE-2025-40277:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE&#xA;&#xA;This data originates from userspace and is used in buffer offset&#xA;calculations which could potentially overflow causing an out-of-bounds&#xA;access.&#xA;CVE-2025-40281:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto&#xA;&#xA;syzbot reported a possible shift-out-of-bounds [1]&#xA;&#xA;Blamed commit added rto_alpha_max and rto_beta_max set to 1000.&#xA;&#xA;It is unclear if some sctp users are setting very large rto_alpha&#xA;and/or rto_beta.&#xA;&#xA;In order to prevent user regression, perform the test at run time.&#xA;&#xA;Also add READ_ONCE() annotations as sysctl values can change under us.&#xA;&#xA;[1]&#xA;&#xA;UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41&#xA;shift exponent 64 is too large for 32-bit type &#39;unsigned int&#39;&#xA;CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  __dump_stack lib/dump_stack.c:94 [inline]&#xA;  dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120&#xA;  ubsan_epilogue lib/ubsan.c:233 [inline]&#xA;  __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494&#xA;  sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509&#xA;  sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502&#xA;  sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338&#xA;  sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]&#xA;  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]&#xA;CVE-2025-40283:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF&#xA;&#xA;There is a KASAN: slab-use-after-free read in btusb_disconnect().&#xA;Calling &#34;usb_driver_release_interface(&amp;btusb_driver, data-&gt;intf)&#34; will&#xA;free the btusb data associated with the interface. The same data is&#xA;then used later in the function, hence the UAF.&#xA;&#xA;Fix by moving the accesses to btusb data to before the data is free&#39;d.&#xA;CVE-2025-40308:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;Bluetooth: bcsp: receive data only if registered&#xA;&#xA;Currently, bcsp_recv() can be called even when the BCSP protocol has not&#xA;been registered. This leads to a NULL pointer dereference, as shown in&#xA;the following stack trace:&#xA;&#xA;    KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]&#xA;    RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590&#xA;    Call Trace:&#xA;     &lt;TASK&gt;&#xA;     hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627&#xA;     tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290&#xA;     tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706&#xA;     vfs_ioctl fs/ioctl.c:51 [inline]&#xA;     __do_sys_ioctl fs/ioctl.c:907 [inline]&#xA;     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893&#xA;     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94&#xA;     entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;To prevent this, ensure that the HCI_UART_REGISTERED flag is set before&#xA;processing received data. If the protocol is not registered, return&#xA;-EUNATCH.&#xA;CVE-2025-40317:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;regmap: slimbus: fix bus_context pointer in regmap init calls&#xA;&#xA;Commit 4e65bda8273c (&#34;ASoC: wcd934x: fix error handling in&#xA;wcd934x_codec_parse_data()&#34;) revealed the problem in the slimbus regmap.&#xA;That commit breaks audio playback, for instance, on sdm845 Thundercomm&#xA;Dragonboard 845c board:&#xA;&#xA; Unable to handle kernel paging request at virtual address ffff8000847cbad4&#xA; ...&#xA; CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT&#xA; Hardware name: Thundercomm Dragonboard 845c (DT)&#xA; ...&#xA; Call trace:&#xA;  slim_xfer_msg+0x24/0x1ac [slimbus] (P)&#xA;  slim_read+0x48/0x74 [slimbus]&#xA;  regmap_slimbus_read+0x18/0x24 [regmap_slimbus]&#xA;  _regmap_raw_read+0xe8/0x174&#xA;  _regmap_bus_read+0x44/0x80&#xA;  _regmap_read+0x60/0xd8&#xA;  _regmap_update_bits+0xf4/0x140&#xA;  _regmap_select_page+0xa8/0x124&#xA;  _regmap_raw_write_impl+0x3b8/0x65c&#xA;  _regmap_bus_raw_write+0x60/0x80&#xA;  _regmap_write+0x58/0xc0&#xA;  regmap_write+0x4c/0x80&#xA;  wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x]&#xA;  snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core]&#xA;  __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core]&#xA;  dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core]&#xA;  dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core]&#xA;  snd_pcm_hw_params+0x124/0x464 [snd_pcm]&#xA;  snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm]&#xA;  snd_pcm_ioctl+0x34/0x4c [snd_pcm]&#xA;  __arm64_sys_ioctl+0xac/0x104&#xA;  invoke_syscall+0x48/0x104&#xA;  el0_svc_common.constprop.0+0x40/0xe0&#xA;  do_el0_svc+0x1c/0x28&#xA;  el0_svc+0x34/0xec&#xA;  el0t_64_sync_handler+0xa0/0xf0&#xA;  el0t_64_sync+0x198/0x19c&#xA;&#xA;The __devm_regmap_init_slimbus() started to be used instead of&#xA;__regmap_init_slimbus() after the commit mentioned above and turns out&#xA;the incorrect bus_context pointer (3rd argument) was used in&#xA;__devm_regmap_init_slimbus(). It should be just &#34;slimbus&#34; (which is equal&#xA;to &amp;slimbus-&gt;dev). Correct it. The wcd934x codec seems to be the only or&#xA;the first user of devm_regmap_init_slimbus() but we should fix it till&#xA;the point where __devm_regmap_init_slimbus() was introduced therefore&#xA;two &#34;Fixes&#34; tags.&#xA;&#xA;While at this, also correct the same argument in __regmap_init_slimbus().&#xA;CVE-2025-40331:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: Prevent TOCTOU out-of-bounds write&#xA;&#xA;For the following path not holding the sock lock,&#xA;&#xA;  sctp_diag_dump() -&gt; sctp_for_each_endpoint() -&gt; sctp_ep_dump()&#xA;&#xA;make sure not to exceed bounds in case the address list has grown&#xA;between buffer allocation (time-of-check) and write (time-of-use).&#xA;CVE-2025-40345:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: storage: sddr55: Reject out-of-bound new_pba&#xA;&#xA;Discovered by Atuin - Automated Vulnerability Discovery Engine.&#xA;&#xA;new_pba comes from the status packet returned after each write.&#xA;A bogus device could report values beyond the block count derived&#xA;from info-&gt;capacity, letting the driver walk off the end of&#xA;pba_to_lba[] and corrupt heap memory.&#xA;&#xA;Reject PBAs that exceed the computed block count and fail the&#xA;transfer so we avoid touching out-of-range mapping entries.&#xA;CVE-2025-40349:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hfs: validate record offset in hfsplus_bmap_alloc&#xA;&#xA;hfsplus_bmap_alloc can trigger a crash if a&#xA;record offset or length is larger than node_size&#xA;&#xA;[   15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0&#xA;[   15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183&#xA;[   15.265949]&#xA;[   15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)&#xA;[   15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   15.266167] Call Trace:&#xA;[   15.266168]  &lt;TASK&gt;&#xA;[   15.266169]  dump_stack_lvl+0x53/0x70&#xA;[   15.266173]  print_report+0xd0/0x660&#xA;[   15.266181]  kasan_report+0xce/0x100&#xA;[   15.266185]  hfsplus_bmap_alloc+0x887/0x8b0&#xA;[   15.266208]  hfs_btree_inc_height.isra.0+0xd5/0x7c0&#xA;[   15.266217]  hfsplus_brec_insert+0x870/0xb00&#xA;[   15.266222]  __hfsplus_ext_write_extent+0x428/0x570&#xA;[   15.266225]  __hfsplus_ext_cache_extent+0x5e/0x910&#xA;[   15.266227]  hfsplus_ext_read_extent+0x1b2/0x200&#xA;[   15.266233]  hfsplus_file_extend+0x5a7/0x1000&#xA;[   15.266237]  hfsplus_get_block+0x12b/0x8c0&#xA;[   15.266238]  __block_write_begin_int+0x36b/0x12c0&#xA;[   15.266251]  block_write_begin+0x77/0x110&#xA;[   15.266252]  cont_write_begin+0x428/0x720&#xA;[   15.266259]  hfsplus_write_begin+0x51/0x100&#xA;[   15.266262]  cont_write_begin+0x272/0x720&#xA;[   15.266270]  hfsplus_write_begin+0x51/0x100&#xA;[   15.266274]  generic_perform_write+0x321/0x750&#xA;[   15.266285]  generic_file_write_iter+0xc3/0x310&#xA;[   15.266289]  __kernel_write_iter+0x2fd/0x800&#xA;[   15.266296]  dump_user_range+0x2ea/0x910&#xA;[   15.266301]  elf_core_dump+0x2a94/0x2ed0&#xA;[   15.266320]  vfs_coredump+0x1d85/0x45e0&#xA;[   15.266349]  get_signal+0x12e3/0x1990&#xA;[   15.266357]  arch_do_signal_or_restart+0x89/0x580&#xA;[   15.266362]  irqentry_exit_to_user_mode+0xab/0x110&#xA;[   15.266364]  asm_exc_page_fault+0x26/0x30&#xA;[   15.266366] RIP: 0033:0x41bd35&#xA;[   15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 &lt;f3&gt; 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f&#xA;[   15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283&#xA;[   15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000&#xA;[   15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100&#xA;[   15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000&#xA;[   15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;[   15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000&#xA;[   15.266376]  &lt;/TASK&gt;&#xA;&#xA;When calling hfsplus_bmap_alloc to allocate a free node, this function&#xA;first retrieves the bitmap from header node and map node using node-&gt;page&#xA;together with the offset and length from hfs_brec_lenoff&#xA;&#xA;```&#xA;len = hfs_brec_lenoff(node, 2, &amp;off16);&#xA;off = off16;&#xA;&#xA;off += node-&gt;page_offset;&#xA;pagep = node-&gt;page + (off &gt;&gt; PAGE_SHIFT);&#xA;data = kmap_local_page(*pagep);&#xA;```&#xA;&#xA;However, if the retrieved offset or length is invalid(i.e. exceeds&#xA;node_size), the code may end up accessing pages outside the allocated&#xA;range for this node.&#xA;&#xA;This patch adds proper validation of both offset and length before use,&#xA;preventing out-of-bounds page access. Move is_bnode_offset_valid and&#xA;check_and_correct_requested_length to hfsplus_fs.h, as they may be&#xA;required by other functions.&#xA;CVE-2025-40351:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()&#xA;&#xA;The syzbot reported issue in hfsplus_delete_cat():&#xA;&#xA;[   70.682285][ T9333] =====================================================&#xA;[   70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220&#xA;[   70.683640][ T9333]  hfsplus_subfolders_dec+0x1d7/0x220&#xA;[   70.684141][ T9333]  hfsplus_delete_cat+0x105d/0x12b0&#xA;[   70.684621][ T9333]  hfsplus_rmdir+0x13d/0x310&#xA;[   70.685048][ T9333]  vfs_rmdir+0x5ba/0x810&#xA;[   70.685447][ T9333]  do_rmdir+0x964/0xea0&#xA;[   70.685833][ T9333]  __x64_sys_rmdir+0x71/0xb0&#xA;[   70.686260][ T9333]  x64_sys_call+0xcd8/0x3cf0&#xA;[   70.686695][ T9333]  do_syscall_64+0xd9/0x1d0&#xA;[   70.687119][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[   70.687646][ T9333]&#xA;[   70.687856][ T9333] Uninit was stored to memory at:&#xA;[   70.688311][ T9333]  hfsplus_subfolders_inc+0x1c2/0x1d0&#xA;[   70.688779][ T9333]  hfsplus_create_cat+0x148e/0x1800&#xA;[   70.689231][ T9333]  hfsplus_mknod+0x27f/0x600&#xA;[   70.689730][ T9333]  hfsplus_mkdir+0x5a/0x70&#xA;[   70.690146][ T9333]  vfs_mkdir+0x483/0x7a0&#xA;[   70.690545][ T9333]  do_mkdirat+0x3f2/0xd30&#xA;[   70.690944][ T9333]  __x64_sys_mkdir+0x9a/0xf0&#xA;[   70.691380][ T9333]  x64_sys_call+0x2f89/0x3cf0&#xA;[   70.691816][ T9333]  do_syscall_64+0xd9/0x1d0&#xA;[   70.692229][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[   70.692773][ T9333]&#xA;[   70.692990][ T9333] Uninit was stored to memory at:&#xA;[   70.693469][ T9333]  hfsplus_subfolders_inc+0x1c2/0x1d0&#xA;[   70.693960][ T9333]  hfsplus_create_cat+0x148e/0x1800&#xA;[   70.694438][ T9333]  hfsplus_fill_super+0x21c1/0x2700&#xA;[   70.694911][ T9333]  mount_bdev+0x37b/0x530&#xA;[   70.695320][ T9333]  hfsplus_mount+0x4d/0x60&#xA;[   70.695729][ T9333]  legacy_get_tree+0x113/0x2c0&#xA;[   70.696167][ T9333]  vfs_get_tree+0xb3/0x5c0&#xA;[   70.696588][ T9333]  do_new_mount+0x73e/0x1630&#xA;[   70.697013][ T9333]  path_mount+0x6e3/0x1eb0&#xA;[   70.697425][ T9333]  __se_sys_mount+0x733/0x830&#xA;[   70.697857][ T9333]  __x64_sys_mount+0xe4/0x150&#xA;[   70.698269][ T9333]  x64_sys_call+0x2691/0x3cf0&#xA;[   70.698704][ T9333]  do_syscall_64+0xd9/0x1d0&#xA;[   70.699117][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[   70.699730][ T9333]&#xA;[   70.699946][ T9333] Uninit was created at:&#xA;[   70.700378][ T9333]  __alloc_pages_noprof+0x714/0xe60&#xA;[   70.700843][ T9333]  alloc_pages_mpol_noprof+0x2a2/0x9b0&#xA;[   70.701331][ T9333]  alloc_pages_noprof+0xf8/0x1f0&#xA;[   70.701774][ T9333]  allocate_slab+0x30e/0x1390&#xA;[   70.702194][ T9333]  ___slab_alloc+0x1049/0x33a0&#xA;[   70.702635][ T9333]  kmem_cache_alloc_lru_noprof+0x5ce/0xb20&#xA;[   70.703153][ T9333]  hfsplus_alloc_inode+0x5a/0xd0&#xA;[   70.703598][ T9333]  alloc_inode+0x82/0x490&#xA;[   70.703984][ T9333]  iget_locked+0x22e/0x1320&#xA;[   70.704428][ T9333]  hfsplus_iget+0x5c/0xba0&#xA;[   70.704827][ T9333]  hfsplus_btree_open+0x135/0x1dd0&#xA;[   70.705291][ T9333]  hfsplus_fill_super+0x1132/0x2700&#xA;[   70.705776][ T9333]  mount_bdev+0x37b/0x530&#xA;[   70.706171][ T9333]  hfsplus_mount+0x4d/0x60&#xA;[   70.706579][ T9333]  legacy_get_tree+0x113/0x2c0&#xA;[   70.707019][ T9333]  vfs_get_tree+0xb3/0x5c0&#xA;[   70.707444][ T9333]  do_new_mount+0x73e/0x1630&#xA;[   70.707865][ T9333]  path_mount+0x6e3/0x1eb0&#xA;[   70.708270][ T9333]  __se_sys_mount+0x733/0x830&#xA;[   70.708711][ T9333]  __x64_sys_mount+0xe4/0x150&#xA;[   70.709158][ T9333]  x64_sys_call+0x2691/0x3cf0&#xA;[   70.709630][ T9333]  do_syscall_64+0xd9/0x1d0&#xA;[   70.710053][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;[   70.710611][ T9333]&#xA;[   70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17&#xA;[   70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014&#xA;[   70.712490][ T9333] =====================================================&#xA;[   70.713085][ T9333] Disabling lock debugging due to kernel taint&#xA;[   70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...&#xA;[   70.714159][ T9333] &#xA;---truncated---&#xA;CVE-2025-40363:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ipv6: fix field-spanning memcpy warning in AH output&#xA;&#xA;Fix field-spanning memcpy warnings in ah6_output() and&#xA;ah6_output_done() where extension headers are copied to/from IPv6&#xA;address fields, triggering fortify-string warnings about writes beyond&#xA;the 16-byte address fields.&#xA;&#xA;  memcpy: detected field-spanning write (size 40) of single field &#34;&amp;top_iph-&gt;saddr&#34; at net/ipv6/ah6.c:439 (size 16)&#xA;  WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439&#xA;&#xA;The warnings are false positives as the extension headers are&#xA;intentionally placed after the IPv6 header in memory. Fix by properly&#xA;copying addresses and extension headers separately, and introduce&#xA;helper functions to avoid code duplication.&#xA;CVE-2025-68168:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jfs: fix uninitialized waitqueue in transaction manager&#xA;&#xA;The transaction manager initialization in txInit() was not properly&#xA;initializing TxBlock[0].waitor waitqueue, causing a crash when&#xA;txEnd(0) is called on read-only filesystems.&#xA;&#xA;When a filesystem is mounted read-only, txBegin() returns tid=0 to&#xA;indicate no transaction. However, txEnd(0) still gets called and&#xA;tries to access TxBlock[0].waitor via tid_to_tblock(0), but this&#xA;waitqueue was never initialized because the initialization loop&#xA;started at index 1 instead of 0.&#xA;&#xA;This causes a &#39;non-static key&#39; lockdep warning and system crash:&#xA;  INFO: trying to register non-static key in txEnd&#xA;&#xA;Fix by ensuring all transaction blocks including TxBlock[0] have&#xA;their waitqueues properly initialized during txInit().&#xA;CVE-2025-68176:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;PCI: cadence: Check for the existence of cdns_pcie::ops before using it&#xA;&#xA;cdns_pcie::ops might not be populated by all the Cadence glue drivers. This&#xA;is going to be true for the upcoming Sophgo platform which doesn&#39;t set the&#xA;ops.&#xA;&#xA;Hence, add a check to prevent NULL pointer dereference.&#xA;&#xA;[mani: reworded subject and description]&#xA;CVE-2025-68191:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;udp_tunnel: use netdev_warn() instead of netdev_WARN()&#xA;&#xA;netdev_WARN() uses WARN/WARN_ON to print a backtrace along with&#xA;file and line information. In this case, udp_tunnel_nic_register()&#xA;returning an error is just a failed operation, not a kernel bug.&#xA;&#xA;udp_tunnel_nic_register() can fail due to a memory allocation&#xA;failure (kzalloc() or udp_tunnel_nic_alloc()).&#xA;This is a normal runtime error and not a kernel bug.&#xA;&#xA;Replace netdev_WARN() with netdev_warn() accordingly.&#xA;CVE-2025-68194:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;media: imon: make send_packet() more robust&#xA;&#xA;syzbot is reporting that imon has three problems which result in&#xA;hung tasks due to forever holding device lock [1].&#xA;&#xA;First problem is that when usb_rx_callback_intf0() once got -EPROTO error&#xA;after ictx-&gt;dev_present_intf0 became true, usb_rx_callback_intf0()&#xA;resubmits urb after printk(), and resubmitted urb causes&#xA;usb_rx_callback_intf0() to again get -EPROTO error. This results in&#xA;printk() flooding (RCU stalls).&#xA;&#xA;Alan Stern commented [2] that&#xA;&#xA;  In theory it&#39;s okay to resubmit _if_ the driver has a robust&#xA;  error-recovery scheme (such as giving up after some fixed limit on the&#xA;  number of errors or after some fixed time has elapsed, perhaps with a&#xA;  time delay to prevent a flood of errors).  Most drivers don&#39;t bother to&#xA;  do this; they simply give up right away.  This makes them more&#xA;  vulnerable to short-term noise interference during USB transfers, but in&#xA;  reality such interference is quite rare.  There&#39;s nothing really wrong&#xA;  with giving up right away.&#xA;&#xA;but imon has a poor error-recovery scheme which just retries forever;&#xA;this behavior should be fixed.&#xA;&#xA;Since I&#39;m not sure whether it is safe for imon users to give up upon any&#xA;error code, this patch takes care of only union of error codes chosen from&#xA;modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.&#xA;ir_toy, mceusb and igorplugusb).&#xA;&#xA;Second problem is that when usb_rx_callback_intf0() once got -EPROTO error&#xA;before ictx-&gt;dev_present_intf0 becomes true, usb_rx_callback_intf0() always&#xA;resubmits urb due to commit 8791d63af0cf (&#34;[media] imon: don&#39;t wedge&#xA;hardware after early callbacks&#34;). Move the ictx-&gt;dev_present_intf0 test&#xA;introduced by commit 6f6b90c9231a (&#34;[media] imon: don&#39;t parse scancodes&#xA;until intf configured&#34;) to immediately before imon_incoming_packet(), or&#xA;the first problem explained above happens without printk() flooding (i.e.&#xA;hung task).&#xA;&#xA;Third problem is that when usb_rx_callback_intf0() is not called for some&#xA;reason (e.g. flaky hardware; the reproducer for this problem sometimes&#xA;prevents usb_rx_callback_intf0() from being called),&#xA;wait_for_completion_interruptible() in send_packet() never returns (i.e.&#xA;hung task). As a workaround for such situation, change send_packet() to&#xA;wait for completion with timeout of 10 seconds.&#xA;CVE-2025-68204:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;pmdomain: arm: scmi: Fix genpd leak on provider registration failure&#xA;&#xA;If of_genpd_add_provider_onecell() fails during probe, the previously&#xA;created generic power domains are not removed, leading to a memory leak&#xA;and potential kernel crash later in genpd_debug_add().&#xA;&#xA;Add proper error handling to unwind the initialized domains before&#xA;returning from probe to ensure all resources are correctly released on&#xA;failure.&#xA;&#xA;Example crash trace observed without this fix:&#xA;&#xA;  | Unable to handle kernel paging request at virtual address fffffffffffffc70&#xA;  | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT&#xA;  | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform&#xA;  | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#xA;  | pc : genpd_debug_add+0x2c/0x160&#xA;  | lr : genpd_debug_init+0x74/0x98&#xA;  | Call trace:&#xA;  |  genpd_debug_add+0x2c/0x160 (P)&#xA;  |  genpd_debug_init+0x74/0x98&#xA;  |  do_one_initcall+0xd0/0x2d8&#xA;  |  do_initcall_level+0xa0/0x140&#xA;  |  do_initcalls+0x60/0xa8&#xA;  |  do_basic_setup+0x28/0x40&#xA;  |  kernel_init_freeable+0xe8/0x170&#xA;  |  kernel_init+0x2c/0x140&#xA;  |  ret_from_fork+0x10/0x20&#xA;CVE-2025-68206:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;netfilter: nft_ct: add seqadj extension for natted connections&#xA;&#xA;Sequence adjustment may be required for FTP traffic with PASV/EPSV modes.&#xA;due to need to re-write packet payload (IP, port) on the ftp control&#xA;connection. This can require changes to the TCP length and expected&#xA;seq / ack_seq.&#xA;&#xA;The easiest way to reproduce this issue is with PASV mode.&#xA;Example ruleset:&#xA;table inet ftp_nat {&#xA;        ct helper ftp_helper {&#xA;                type &#34;ftp&#34; protocol tcp&#xA;                l3proto inet&#xA;        }&#xA;&#xA;        chain prerouting {&#xA;                type filter hook prerouting priority 0; policy accept;&#xA;                tcp dport 21 ct state new ct helper set &#34;ftp_helper&#34;&#xA;        }&#xA;}&#xA;table ip nat {&#xA;        chain prerouting {&#xA;                type nat hook prerouting priority -100; policy accept;&#xA;                tcp dport 21 dnat ip prefix to ip daddr map {&#xA;&#x9;&#x9;&#x9;192.168.100.1 : 192.168.13.2/32 }&#xA;        }&#xA;&#xA;        chain postrouting {&#xA;                type nat hook postrouting priority 100 ; policy accept;&#xA;                tcp sport 21 snat ip prefix to ip saddr map {&#xA;&#x9;&#x9;&#x9;192.168.13.2 : 192.168.100.1/32 }&#xA;        }&#xA;}&#xA;&#xA;Note that the ftp helper gets assigned *after* the dnat setup.&#xA;&#xA;The inverse (nat after helper assign) is handled by an existing&#xA;check in nf_nat_setup_info() and will not show the problem.&#xA;&#xA;Topoloy:&#xA;&#xA; +-------------------+     +----------------------------------+&#xA; | FTP: 192.168.13.2 | &lt;-&gt; | NAT: 192.168.13.3, 192.168.100.1 |&#xA; +-------------------+     +----------------------------------+&#xA;                                      |&#xA;                         +-----------------------+&#xA;                         | Client: 192.168.100.2 |&#xA;                         +-----------------------+&#xA;&#xA;ftp nat changes do not work as expected in this case:&#xA;Connected to 192.168.100.1.&#xA;[..]&#xA;ftp&gt; epsv&#xA;EPSV/EPRT on IPv4 off.&#xA;ftp&gt; ls&#xA;227 Entering passive mode (192,168,100,1,209,129).&#xA;421 Service not available, remote server has closed connection.&#xA;&#xA;Kernel logs:&#xA;Missing nfct_seqadj_ext_add() setup call&#xA;WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41&#xA;[..]&#xA; __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat]&#xA; nf_nat_ftp+0x142/0x280 [nf_nat_ftp]&#xA; help+0x4d1/0x880 [nf_conntrack_ftp]&#xA; nf_confirm+0x122/0x2e0 [nf_conntrack]&#xA; nf_hook_slow+0x3c/0xb0&#xA; ..&#xA;&#xA;Fix this by adding the required extension when a conntrack helper is assigned&#xA;to a connection that has a nat binding.&#xA;CVE-2025-68220:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error&#xA;&#xA;Make knav_dma_open_channel consistently return NULL on error instead&#xA;of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h&#xA;returns NULL when the driver is disabled, but the driver&#xA;implementation does not even return NULL or ERR_PTR on failure,&#xA;causing inconsistency in the users. This results in a crash in&#xA;netcp_free_navigator_resources as followed (trimmed):&#xA;&#xA;Unhandled fault: alignment exception (0x221) at 0xfffffff2&#xA;[fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000&#xA;Internal error: : 221 [#1] SMP ARM&#xA;Modules linked in:&#xA;CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE&#xA;Hardware name: Keystone&#xA;PC is at knav_dma_close_channel+0x30/0x19c&#xA;LR is at netcp_free_navigator_resources+0x2c/0x28c&#xA;&#xA;[... TRIM...]&#xA;&#xA;Call trace:&#xA; knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c&#xA; netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c&#xA; netcp_ndo_open from __dev_open+0x114/0x29c&#xA; __dev_open from __dev_change_flags+0x190/0x208&#xA; __dev_change_flags from netif_change_flags+0x1c/0x58&#xA; netif_change_flags from dev_change_flags+0x38/0xa0&#xA; dev_change_flags from ip_auto_config+0x2c4/0x11f0&#xA; ip_auto_config from do_one_initcall+0x58/0x200&#xA; do_one_initcall from kernel_init_freeable+0x1cc/0x238&#xA; kernel_init_freeable from kernel_init+0x1c/0x12c&#xA; kernel_init from ret_from_fork+0x14/0x38&#xA;[... TRIM...]&#xA;&#xA;Standardize the error handling by making the function return NULL on&#xA;all error conditions. The API is used in just the netcp_core.c so the&#xA;impact is limited.&#xA;&#xA;Note, this change, in effect reverts commit 5b6cb43b4d62 (&#34;net:&#xA;ethernet: ti: netcp_core: return error while dma channel open issue&#34;),&#xA;but provides a less error prone implementation.&#xA;CVE-2025-68261:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()&#xA;&#xA;Fix a race between inline data destruction and block mapping.&#xA;&#xA;The function ext4_destroy_inline_data_nolock() changes the inode data&#xA;layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.&#xA;At the same time, another thread may execute ext4_map_blocks(), which&#xA;tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()&#xA;or ext4_ind_map_blocks().&#xA;&#xA;Without i_data_sem protection, ext4_ind_map_blocks() may receive inode&#xA;with EXT4_INODE_EXTENTS flag and triggering assert.&#xA;&#xA;kernel BUG at fs/ext4/indirect.c:546!&#xA;EXT4-fs (loop2): unmounting filesystem.&#xA;invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI&#xA;Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014&#xA;RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546&#xA;&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681&#xA; _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822&#xA; ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124&#xA; ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255&#xA; ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000&#xA; generic_perform_write+0x259/0x5d0 mm/filemap.c:3846&#xA; ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285&#xA; ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679&#xA; call_write_iter include/linux/fs.h:2271 [inline]&#xA; do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735&#xA; do_iter_write+0x186/0x710 fs/read_write.c:861&#xA; vfs_iter_write+0x70/0xa0 fs/read_write.c:902&#xA; iter_file_splice_write+0x73b/0xc90 fs/splice.c:685&#xA; do_splice_from fs/splice.c:763 [inline]&#xA; direct_splice_actor+0x10f/0x170 fs/splice.c:950&#xA; splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896&#xA; do_splice_direct+0x1a9/0x280 fs/splice.c:1002&#xA; do_sendfile+0xb13/0x12c0 fs/read_write.c:1255&#xA; __do_sys_sendfile64 fs/read_write.c:1323 [inline]&#xA; __se_sys_sendfile64 fs/read_write.c:1309 [inline]&#xA; __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309&#xA; do_syscall_x64 arch/x86/entry/common.c:51 [inline]&#xA; do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81&#xA; entry_SYSCALL_64_after_hwframe+0x6e/0xd8&#xA;CVE-2025-68264:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ext4: refresh inline data size before write operations&#xA;&#xA;The cached ei-&gt;i_inline_size can become stale between the initial size&#xA;check and when ext4_update_inline_data()/ext4_create_inline_data() use&#xA;it. Although ext4_get_max_inline_size() reads the correct value at the&#xA;time of the check, concurrent xattr operations can modify i_inline_size&#xA;before ext4_write_lock_xattr() is acquired.&#xA;&#xA;This causes ext4_update_inline_data() and ext4_create_inline_data() to&#xA;work with stale capacity values, leading to a BUG_ON() crash in&#xA;ext4_write_inline_data():&#xA;&#xA;  kernel BUG at fs/ext4/inline.c:1331!&#xA;  BUG_ON(pos + len &gt; EXT4_I(inode)-&gt;i_inline_size);&#xA;&#xA;The race window:&#xA;1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)&#xA;2. Size check passes for 50-byte write&#xA;3. [Another thread adds xattr, i_inline_size changes to 40]&#xA;4. ext4_write_lock_xattr() acquires lock&#xA;5. ext4_update_inline_data() uses stale i_inline_size = 60&#xA;6. Attempts to write 50 bytes but only 40 bytes actually available&#xA;7. BUG_ON() triggers&#xA;&#xA;Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock()&#xA;immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()&#xA;and ext4_create_inline_data() work with current values that are protected&#xA;from concurrent modifications.&#xA;&#xA;This is similar to commit a54c4613dac1 (&#34;ext4: fix race writing to an&#xA;inline_data file while its xattrs are changing&#34;) which fixed i_inline_off&#xA;staleness. This patch addresses the related i_inline_size staleness issue.&#xA;CVE-2025-68295:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;smb: client: fix memory leak in cifs_construct_tcon()&#xA;&#xA;When having a multiuser mount with domain= specified and using&#xA;cifscreds, cifs_set_cifscreds() will end up setting @ctx-&gt;domainname,&#xA;so it needs to be freed before leaving cifs_construct_tcon().&#xA;&#xA;This fixes the following memory leak reported by kmemleak:&#xA;&#xA;  mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...&#xA;  su - testuser&#xA;  cifscreds add -d ZELDA -u testuser&#xA;  ...&#xA;  ls /mnt/1&#xA;  ...&#xA;  umount /mnt&#xA;  echo scan &gt; /sys/kernel/debug/kmemleak&#xA;  cat /sys/kernel/debug/kmemleak&#xA;  unreferenced object 0xffff8881203c3f08 (size 8):&#xA;    comm &#34;ls&#34;, pid 5060, jiffies 4307222943&#xA;    hex dump (first 8 bytes):&#xA;      5a 45 4c 44 41 00 cc cc                          ZELDA...&#xA;    backtrace (crc d109a8cf):&#xA;      __kmalloc_node_track_caller_noprof+0x572/0x710&#xA;      kstrdup+0x3a/0x70&#xA;      cifs_sb_tlink+0x1209/0x1770 [cifs]&#xA;      cifs_get_fattr+0xe1/0xf50 [cifs]&#xA;      cifs_get_inode_info+0xb5/0x240 [cifs]&#xA;      cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]&#xA;      cifs_getattr+0x28e/0x450 [cifs]&#xA;      vfs_getattr_nosec+0x126/0x180&#xA;      vfs_statx+0xf6/0x220&#xA;      do_statx+0xab/0x110&#xA;      __x64_sys_statx+0xd5/0x130&#xA;      do_syscall_64+0xbb/0x380&#xA;      entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2025-68302:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sxgbe: fix potential NULL dereference in sxgbe_rx()&#xA;&#xA;Currently, when skb is null, the driver prints an error and then&#xA;dereferences skb on the next line.&#xA;&#xA;To fix this, let&#39;s add a &#39;break&#39; after the error message to switch&#xA;to sxgbe_rx_refill(), which is similar to the approach taken by the&#xA;other drivers in this particular case, e.g. calxeda with xgmac_rx().&#xA;&#xA;Found during a code review.&#xA;CVE-2025-68303:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;platform/x86: intel: punit_ipc: fix memory corruption&#xA;&#xA;This passes the address of the pointer &#34;&amp;punit_ipcdev&#34; when the intent&#xA;was to pass the pointer itself &#34;punit_ipcdev&#34; (without the ampersand).&#xA;This means that the:&#xA;&#xA;&#x9;complete(&amp;ipcdev-&gt;cmd_complete);&#xA;&#xA;in intel_punit_ioc() will write to a wrong memory address corrupting it.&#xA;CVE-2025-68308:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: kvaser_usb: leaf: Fix potential infinite loop in command parsers&#xA;&#xA;The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`&#xA;functions contain logic to zero-length commands. These commands are used&#xA;to align data to the USB endpoint&#39;s wMaxPacketSize boundary.&#xA;&#xA;The driver attempts to skip these placeholders by aligning the buffer&#xA;position `pos` to the next packet boundary using `round_up()` function.&#xA;&#xA;However, if zero-length command is found exactly on a packet boundary&#xA;(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`&#xA;function will return the unchanged value of `pos`. This prevents `pos`&#xA;to be increased, causing an infinite loop in the parsing logic.&#xA;&#xA;This patch fixes this in the function by using `pos + 1` instead.&#xA;This ensures that even if `pos` is on a boundary, the calculation is&#xA;based on `pos + 1`, forcing `round_up()` to always return the next&#xA;aligned boundary.&#xA;CVE-2025-68312:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usbnet: Prevents free active kevent&#xA;&#xA;The root cause of this issue are:&#xA;1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);&#xA;put the kevent work in global workqueue. However, the kevent has not yet&#xA;been scheduled when the usbnet device is unregistered. Therefore, executing&#xA;free_netdev() results in the &#34;free active object (kevent)&#34; error reported&#xA;here.&#xA;&#xA;2. Another factor is that when calling usbnet_disconnect()-&gt;unregister_netdev(),&#xA;if the usbnet device is up, ndo_stop() is executed to cancel the kevent.&#xA;However, because the device is not up, ndo_stop() is not executed.&#xA;&#xA;The solution to this problem is to cancel the kevent before executing&#xA;free_netdev().&#xA;CVE-2025-68321:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;page_pool: always add GFP_NOWARN for ATOMIC allocations&#xA;&#xA;Driver authors often forget to add GFP_NOWARN for page allocation&#xA;from the datapath. This is annoying to users as OOMs are a fact&#xA;of life, and we pretty much expect network Rx to hit page allocation&#xA;failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations&#xA;by default.&#xA;CVE-2025-68324:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: imm: Fix use-after-free bug caused by unfinished delayed work&#xA;&#xA;The delayed work item &#39;imm_tq&#39; is initialized in imm_attach() and&#xA;scheduled via imm_queuecommand() for processing SCSI commands.  When the&#xA;IMM parallel port SCSI host adapter is detached through imm_detach(),&#xA;the imm_struct device instance is deallocated.&#xA;&#xA;However, the delayed work might still be pending or executing&#xA;when imm_detach() is called, leading to use-after-free bugs&#xA;when the work function imm_interrupt() accesses the already&#xA;freed imm_struct memory.&#xA;&#xA;The race condition can occur as follows:&#xA;&#xA;CPU 0(detach thread)   | CPU 1&#xA;                       | imm_queuecommand()&#xA;                       |   imm_queuecommand_lck()&#xA;imm_detach()           |     schedule_delayed_work()&#xA;  kfree(dev) //FREE    | imm_interrupt()&#xA;                       |   dev = container_of(...) //USE&#xA;                           dev-&gt; //USE&#xA;&#xA;Add disable_delayed_work_sync() in imm_detach() to guarantee proper&#xA;cancellation of the delayed work item before imm_struct is deallocated.&#xA;CVE-2025-68328:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;firmware: stratix10-svc: fix bug in saving controller data&#xA;&#xA;Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They&#xA;both are of the same data and overrides each other. This resulted in the&#xA;rmmod of the svc driver to fail and throw a kernel panic for kthread_stop&#xA;and fifo free.&#xA;CVE-2025-68330:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iio: accel: bmc150: Fix irq assumption regression&#xA;&#xA;The code in bmc150-accel-core.c unconditionally calls&#xA;bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,&#xA;such as on the runtime PM resume path giving a kernel&#xA;splat like this if the device has no interrupts:&#xA;&#xA;Unable to handle kernel NULL pointer dereference at virtual&#xA;  address 00000001 when read&#xA;&#xA;PC is at bmc150_accel_set_interrupt+0x98/0x194&#xA;LR is at __pm_runtime_resume+0x5c/0x64&#xA;(...)&#xA;Call trace:&#xA;bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108&#xA;bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc&#xA;__iio_update_buffers from enable_store+0x84/0xc8&#xA;enable_store from kernfs_fop_write_iter+0x154/0x1b4&#xA;&#xA;This bug seems to have been in the driver since the beginning,&#xA;but it only manifests recently, I do not know why.&#xA;&#xA;Store the IRQ number in the state struct, as this is a common&#xA;pattern in other drivers, then use this to determine if we have&#xA;IRQ support or not.&#xA;CVE-2025-68331:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer&#xA;&#xA;When a UAS device is unplugged during data transfer, there is&#xA;a probability of a system panic occurring. The root cause is&#xA;an access to an invalid memory address during URB callback handling.&#xA;Specifically, this happens when the dma_direct_unmap_sg() function&#xA;is called within the usb_hcd_unmap_urb_for_dma() interface, but the&#xA;sg-&gt;dma_address field is 0 and the sg data structure has already been&#xA;freed.&#xA;&#xA;The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()&#xA;in uas.c, using the uas_submit_urbs() function to submit requests to USB.&#xA;Within the uas_submit_urbs() implementation, three URBs (sense_urb,&#xA;data_urb, and cmd_urb) are sequentially submitted. Device removal may&#xA;occur at any point during uas_submit_urbs execution, which may result&#xA;in URB submission failure. However, some URBs might have been successfully&#xA;submitted before the failure, and uas_submit_urbs will return the -ENODEV&#xA;error code in this case. The current error handling directly calls&#xA;scsi_done(). In the SCSI driver, this eventually triggers scsi_complete()&#xA;to invoke scsi_end_request() for releasing the sgtable. The successfully&#xA;submitted URBs, when being unlinked to giveback, call&#xA;usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg&#xA;unmapping operations since the sg data structure has already been freed.&#xA;&#xA;This patch modifies the error condition check in the uas_submit_urbs()&#xA;function. When a UAS device is removed but one or more URBs have already&#xA;been successfully submitted to USB, it avoids immediately invoking&#xA;scsi_done() and save the cmnd to devinfo-&gt;cmnd array. If the successfully&#xA;submitted URBs is completed before devinfo-&gt;resetting being set, then&#xA;the scsi_done() function will be called within uas_try_complete() after&#xA;all pending URB operations are finalized. Otherwise, the scsi_done()&#xA;function will be called within uas_zap_pending(), which is executed after&#xA;usb_kill_anchored_urbs().&#xA;&#xA;The error handling only takes effect when uas_queuecommand_lck() calls&#xA;uas_submit_urbs() and returns the error value -ENODEV . In this case,&#xA;the device is disconnected, and the flow proceeds to uas_disconnect(),&#xA;where uas_zap_pending() is invoked to call uas_try_complete().&#xA;CVE-2025-68337:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted&#xA;&#xA;There&#39;s issue when file system corrupted:&#xA;------------[ cut here ]------------&#xA;kernel BUG at fs/jbd2/transaction.c:1289!&#xA;Oops: invalid opcode: 0000 [#1] SMP KASAN PTI&#xA;CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next&#xA;RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0&#xA;RSP: 0018:ffff888117aafa30 EFLAGS: 00010202&#xA;RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534&#xA;RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010&#xA;RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028&#xA;R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000&#xA;R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; __ext4_journal_get_create_access+0x42/0x170&#xA; ext4_getblk+0x319/0x6f0&#xA; ext4_bread+0x11/0x100&#xA; ext4_append+0x1e6/0x4a0&#xA; ext4_init_new_dir+0x145/0x1d0&#xA; ext4_mkdir+0x326/0x920&#xA; vfs_mkdir+0x45c/0x740&#xA; do_mkdirat+0x234/0x2f0&#xA; __x64_sys_mkdir+0xd6/0x120&#xA; do_syscall_64+0x5f/0xfa0&#xA; entry_SYSCALL_64_after_hwframe+0x76/0x7e&#xA;&#xA;The above issue occurs with us in errors=continue mode when accompanied by&#xA;storage failures. There have been many inconsistencies in the file system&#xA;data.&#xA;In the case of file system data inconsistency, for example, if the block&#xA;bitmap of a referenced block is not set, it can lead to the situation where&#xA;a block being committed is allocated and used again. As a result, the&#xA;following condition will not be satisfied then trigger BUG_ON. Of course,&#xA;it is entirely possible to construct a problematic image that can trigger&#xA;this BUG_ON through specific operations. In fact, I have constructed such&#xA;an image and easily reproduced this issue.&#xA;Therefore, J_ASSERT() holds true only under ideal conditions, but it may&#xA;not necessarily be satisfied in exceptional scenarios. Using J_ASSERT()&#xA;directly in abnormal situations would cause the system to crash, which is&#xA;clearly not what we want. So here we directly trigger a JBD abort instead&#xA;of immediately invoking BUG_ON.&#xA;CVE-2025-68340:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;team: Move team device type change at the end of team_port_add&#xA;&#xA;Attempting to add a port device that is already up will expectedly fail,&#xA;but not before modifying the team device header_ops.&#xA;&#xA;In the case of the syzbot reproducer the gre0 device is&#xA;already in state UP when it attempts to add it as a&#xA;port device of team0, this fails but before that&#xA;header_ops-&gt;create of team0 is changed from eth_header to ipgre_header&#xA;in the call to team_dev_type_check_change.&#xA;&#xA;Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense&#xA;as the private data of the device still holds a struct team.&#xA;&#xA;Example sequence of iproute2 commands to reproduce the hang/BUG():&#xA;ip link add dev team0 type team&#xA;ip link add dev gre0 type gre&#xA;ip link set dev gre0 up&#xA;ip link set dev gre0 master team0&#xA;ip link set dev team0 up&#xA;ping -I team0 1.1.1.1&#xA;&#xA;Move team_dev_type_check_change down where all other checks have passed&#xA;as it changes the dev type with no way to restore it in case&#xA;one of the checks that follow it fail.&#xA;&#xA;Also make sure to preserve the origial mtu assignment:&#xA;  - If port_dev is not the same type as dev, dev takes mtu from port_dev&#xA;  - If port_dev is the same type as dev, port_dev takes mtu from dev&#xA;&#xA;This is done by adding a conditional before the call to dev_set_mtu&#xA;to prevent it from assigning port_dev-&gt;mtu = dev-&gt;mtu and instead&#xA;letting team_dev_type_check_change assign dev-&gt;mtu = port_dev-&gt;mtu.&#xA;The conditional is needed because the patch moves the call to&#xA;team_dev_type_check_change past dev_set_mtu.&#xA;&#xA;Testing:&#xA;  - team device driver in-tree selftests&#xA;  - Add/remove various devices as slaves of team device&#xA;  - syzbot&#xA;CVE-2025-68346:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: dice: fix buffer overflow in detect_stream_formats()&#xA;&#xA;The function detect_stream_formats() reads the stream_count value directly&#xA;from a FireWire device without validating it. This can lead to&#xA;out-of-bounds writes when a malicious device provides a stream_count value&#xA;greater than MAX_STREAMS.&#xA;&#xA;Fix by applying the same validation to both TX and RX stream counts in&#xA;detect_stream_formats().&#xA;CVE-2025-68362:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()&#xA;&#xA;The rtl8187_rx_cb() calculates the rx descriptor header address&#xA;by subtracting its size from the skb tail pointer.&#xA;However, it does not validate if the received packet&#xA;(skb-&gt;len from urb-&gt;actual_length) is large enough to contain this&#xA;header.&#xA;&#xA;If a truncated packet is received, this will lead to a buffer&#xA;underflow, reading memory before the start of the skb data area,&#xA;and causing a kernel panic.&#xA;&#xA;Add length checks for both rtl8187 and rtl8187b descriptor headers&#xA;before attempting to access them, dropping the packet cleanly if the&#xA;check fails.&#xA;CVE-2025-68364:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()&#xA;&#xA;In &#39;__ocfs2_move_extent()&#39;, relax &#39;BUG()&#39; to &#39;ocfs2_error()&#39; just&#xA;to avoid crashing the whole kernel due to a filesystem corruption.&#xA;CVE-2025-68367:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse&#xA;&#xA;The following warning appears when running syzkaller, and this issue also&#xA;exists in the mainline code.&#xA;&#xA; ------------[ cut here ]------------&#xA; list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.&#xA; WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130&#xA; Modules linked in:&#xA; CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3&#xA; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014&#xA; RIP: 0010:__list_add_valid_or_report+0xf7/0x130&#xA; RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282&#xA; RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817&#xA; RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001&#xA; RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c&#xA; R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100&#xA; R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48&#xA; FS:  00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000&#xA; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA; CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0&#xA; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA; PKRU: 80000000&#xA; Call Trace:&#xA;  &lt;TASK&gt;&#xA;  input_register_handler+0xb3/0x210&#xA;  mac_hid_start_emulation+0x1c5/0x290&#xA;  mac_hid_toggle_emumouse+0x20a/0x240&#xA;  proc_sys_call_handler+0x4c2/0x6e0&#xA;  new_sync_write+0x1b1/0x2d0&#xA;  vfs_write+0x709/0x950&#xA;  ksys_write+0x12a/0x250&#xA;  do_syscall_64+0x5a/0x110&#xA;  entry_SYSCALL_64_after_hwframe+0x78/0xe2&#xA;&#xA;The WARNING occurs when two processes concurrently write to the mac-hid&#xA;emulation sysctl, causing a race condition in mac_hid_toggle_emumouse().&#xA;Both processes read old_val=0, then both try to register the input handler,&#xA;leading to a double list_add of the same handler.&#xA;&#xA;  CPU0                             CPU1&#xA;  -------------------------        -------------------------&#xA;  vfs_write() //write 1            vfs_write()  //write 1&#xA;    proc_sys_write()                 proc_sys_write()&#xA;      mac_hid_toggle_emumouse()          mac_hid_toggle_emumouse()&#xA;        old_val = *valp // old_val=0&#xA;                                           old_val = *valp // old_val=0&#xA;                                           mutex_lock_killable()&#xA;                                           proc_dointvec() // *valp=1&#xA;                                           mac_hid_start_emulation()&#xA;                                             input_register_handler()&#xA;                                           mutex_unlock()&#xA;        mutex_lock_killable()&#xA;        proc_dointvec()&#xA;        mac_hid_start_emulation()&#xA;          input_register_handler() //Trigger Warning&#xA;        mutex_unlock()&#xA;&#xA;Fix this by moving the old_val read inside the mutex lock region.&#xA;CVE-2025-68372:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;nbd: defer config put in recv_work&#xA;&#xA;There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and&#xA;NBD_CMD_RECONFIGURE:&#xA;  nbd_genl_connect     // conf_ref=2 (connect and recv_work A)&#xA;  nbd_open&#x9;       // conf_ref=3&#xA;  recv_work A done     // conf_ref=2&#xA;  NBD_CLEAR_SOCK       // conf_ref=1&#xA;  nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)&#xA;  close nbd&#x9;       // conf_ref=1&#xA;  recv_work B&#xA;    config_put         // conf_ref=0&#xA;    atomic_dec(&amp;config-&gt;recv_threads); -&gt; UAF&#xA;&#xA;Or only running NBD_CLEAR_SOCK:&#xA;  nbd_genl_connect   // conf_ref=2&#xA;  nbd_open &#x9;     // conf_ref=3&#xA;  NBD_CLEAR_SOCK     // conf_ref=2&#xA;  close nbd&#xA;    nbd_release&#xA;      config_put     // conf_ref=1&#xA;  recv_work&#xA;    config_put &#x9;     // conf_ref=0&#xA;    atomic_dec(&amp;config-&gt;recv_threads); -&gt; UAF&#xA;&#xA;Commit 87aac3a80af5 (&#34;nbd: call nbd_config_put() before notifying the&#xA;waiter&#34;) moved nbd_config_put() to run before waking up the waiter in&#xA;recv_work, in order to ensure that nbd_start_device_ioctl() would not&#xA;be woken up while nbd-&gt;task_recv was still uncleared.&#xA;&#xA;However, in nbd_start_device_ioctl(), after being woken up it explicitly&#xA;calls flush_workqueue() to make sure all current works are finished.&#xA;Therefore, there is no need to move the config put ahead of the wakeup.&#xA;&#xA;Move nbd_config_put() to the end of recv_work, so that the reference is&#xA;held for the whole lifetime of the worker thread. This makes sure the&#xA;config cannot be freed while recv_work is still running, even if clear&#xA;+ reconfigure interleave.&#xA;&#xA;In addition, we don&#39;t need to worry about recv_work dropping the last&#xA;nbd_put (which causes deadlock):&#xA;&#xA;path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):&#xA;  connect  // nbd_refs=1 (trigger recv_work)&#xA;  open nbd // nbd_refs=2&#xA;  NBD_CLEAR_SOCK&#xA;  close nbd&#xA;    nbd_release&#xA;      nbd_disconnect_and_put&#xA;        flush_workqueue // recv_work done&#xA;      nbd_config_put&#xA;        nbd_put // nbd_refs=1&#xA;      nbd_put // nbd_refs=0&#xA;        queue_work&#xA;&#xA;path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):&#xA;  connect  // nbd_refs=2 (trigger recv_work)&#xA;  open nbd // nbd_refs=3&#xA;  NBD_CLEAR_SOCK // conf_refs=2&#xA;  close nbd&#xA;    nbd_release&#xA;      nbd_config_put // conf_refs=1&#xA;      nbd_put // nbd_refs=2&#xA;  recv_work done // conf_refs=0, nbd_refs=1&#xA;  rmmod // nbd_refs=0&#xA;&#xA;Depends-on: e2daec488c57 (&#34;nbd: Fix hungtask when nbd_config_put&#34;)&#xA;CVE-2025-68724:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id&#xA;&#xA;Use check_add_overflow() to guard against potential integer overflows&#xA;when adding the binary blob lengths and the size of an asymmetric_key_id&#xA;structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a&#xA;possible buffer overflow when copying data from potentially malicious&#xA;X.509 certificate fields that can be arbitrarily large, such as ASN.1&#xA;INTEGER serial numbers, issuer names, etc.&#xA;CVE-2025-68725:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bpf: Do not let BPF test infra emit invalid GSO types to stack&#xA;&#xA;Yinhao et al. reported that their fuzzer tool was able to trigger a&#xA;skb_warn_bad_offload() from netif_skb_features() -&gt; gso_features_check().&#xA;When a BPF program - triggered via BPF test infra - pushes the packet&#xA;to the loopback device via bpf_clone_redirect() then mentioned offload&#xA;warning can be seen. GSO-related features are then rightfully disabled.&#xA;&#xA;We get into this situation due to convert___skb_to_skb() setting&#xA;gso_segs and gso_size but not gso_type. Technically, it makes sense&#xA;that this warning triggers since the GSO properties are malformed due&#xA;to the gso_type. Potentially, the gso_type could be marked non-trustworthy&#xA;through setting it at least to SKB_GSO_DODGY without any other specific&#xA;assumptions, but that also feels wrong given we should not go further&#xA;into the GSO engine in the first place.&#xA;&#xA;The checks were added in 121d57af308d (&#34;gso: validate gso_type in GSO&#xA;handlers&#34;) because there were malicious (syzbot) senders that combine&#xA;a protocol with a non-matching gso_type. If we would want to drop such&#xA;packets, gso_features_check() currently only returns feature flags via&#xA;netif_skb_features(), so one location for potentially dropping such skbs&#xA;could be validate_xmit_unreadable_skb(), but then otoh it would be&#xA;an additional check in the fast-path for a very corner case. Given&#xA;bpf_clone_redirect() is the only place where BPF test infra could emit&#xA;such packets, lets reject them right there.&#xA;CVE-2025-68771:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ocfs2: fix kernel BUG in ocfs2_find_victim_chain&#xA;&#xA;syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the&#xA;`cl_next_free_rec` field of the allocation chain list (next free slot in&#xA;the chain list) is 0, triggring the BUG_ON(!cl-&gt;cl_next_free_rec)&#xA;condition in ocfs2_find_victim_chain() and panicking the kernel.&#xA;&#xA;To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),&#xA;just before calling ocfs2_find_victim_chain(), the code block in it being&#xA;executed when either of the following conditions is true:&#xA;&#xA;1. `cl_next_free_rec` is equal to 0, indicating that there are no free&#xA;chains in the allocation chain list&#xA;2. `cl_next_free_rec` is greater than `cl_count` (the total number of&#xA;chains in the allocation chain list)&#xA;&#xA;Either of them being true is indicative of the fact that there are no&#xA;chains left for usage.&#xA;&#xA;This is addressed using ocfs2_error(), which prints&#xA;the error log for debugging purposes, rather than panicking the kernel.&#xA;CVE-2025-68783:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-mixer: us16x08: validate meter packet indices&#xA;&#xA;get_meter_levels_from_urb() parses the 64-byte meter packets sent by&#xA;the device and fills the per-channel arrays meter_level[],&#xA;comp_level[] and master_level[] in struct snd_us16x08_meter_store.&#xA;&#xA;Currently the function derives the channel index directly from the&#xA;meter packet (MUB2(meter_urb, s) - 1) and uses it to index those&#xA;arrays without validating the range. If the packet contains a&#xA;negative or out-of-range channel number, the driver may write past&#xA;the end of these arrays.&#xA;&#xA;Introduce a local channel variable and validate it before updating the&#xA;arrays. We reject negative indices, limit meter_level[] and&#xA;comp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]&#xA;updates with ARRAY_SIZE(master_level).&#xA;CVE-2025-68788:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fsnotify: do not generate ACCESS/MODIFY events on child for special files&#xA;&#xA;inotify/fanotify do not allow users with no read access to a file to&#xA;subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the&#xA;same user to subscribe for watching events on children when the user&#xA;has access to the parent directory (e.g. /dev).&#xA;&#xA;Users with no read access to a file but with read access to its parent&#xA;directory can still stat the file and see if it was accessed/modified&#xA;via atime/mtime change.&#xA;&#xA;The same is not true for special files (e.g. /dev/null). Users will not&#xA;generally observe atime/mtime changes when other users read/write to&#xA;special files, only when someone sets atime/mtime via utimensat().&#xA;&#xA;Align fsnotify events with this stat behavior and do not generate&#xA;ACCESS/MODIFY events to parent watchers on read/write of special files.&#xA;The events are still generated to parent watchers on utimensat(). This&#xA;closes some side-channels that could be possibly used for information&#xA;exfiltration [1].&#xA;&#xA;[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf&#xA;CVE-2025-68813:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvs: fix ipv4 null-ptr-deref in route error path&#xA;&#xA;The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()&#xA;without ensuring skb-&gt;dev is set, leading to a NULL pointer dereference&#xA;in fib_compute_spec_dst() when ipv4_link_failure() attempts to send&#xA;ICMP destination unreachable messages.&#xA;&#xA;The issue emerged after commit ed0de45a1008 (&#34;ipv4: recompile ip options&#xA;in ipv4_link_failure&#34;) started calling __ip_options_compile() from&#xA;ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()&#xA;which dereferences skb-&gt;dev. An attempt was made to fix the NULL skb-&gt;dev&#xA;dereference in commit 0113d9c9d1cc (&#34;ipv4: fix null-deref in&#xA;ipv4_link_failure&#34;), but it only addressed the immediate dev_net(skb-&gt;dev)&#xA;dereference by using a fallback device. The fix was incomplete because&#xA;fib_compute_spec_dst() later in the call chain still accesses skb-&gt;dev&#xA;directly, which remains NULL when IPVS calls dst_link_failure().&#xA;&#xA;The crash occurs when:&#xA;1. IPVS processes a packet in NAT mode with a misconfigured destination&#xA;2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route&#xA;3. The error path calls dst_link_failure(skb) with skb-&gt;dev == NULL&#xA;4. ipv4_link_failure() → ipv4_send_dest_unreach() →&#xA;   __ip_options_compile() → fib_compute_spec_dst()&#xA;5. fib_compute_spec_dst() dereferences NULL skb-&gt;dev&#xA;&#xA;Apply the same fix used for IPv6 in commit 326bf17ea5d4 (&#34;ipvs: fix&#xA;ipv6 route unreach panic&#34;): set skb-&gt;dev from skb_dst(skb)-&gt;dev before&#xA;calling dst_link_failure().&#xA;&#xA;KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]&#xA;CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2&#xA;RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233&#xA;RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285&#xA;Call Trace:&#xA;  &lt;TASK&gt;&#xA;  spec_dst_fill net/ipv4/ip_options.c:232&#xA;  spec_dst_fill net/ipv4/ip_options.c:229&#xA;  __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330&#xA;  ipv4_send_dest_unreach net/ipv4/route.c:1252&#xA;  ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265&#xA;  dst_link_failure include/net/dst.h:437&#xA;  __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412&#xA;  ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764&#xA;CVE-2025-68818:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: Revert &#34;scsi: qla2xxx: Perform lockless command completion in abort path&#34;&#xA;&#xA;This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.&#xA;&#xA;The commit being reverted added code to __qla2x00_abort_all_cmds() to&#xA;call sp-&gt;done() without holding a spinlock.  But unlike the older code&#xA;below it, this new code failed to check sp-&gt;cmd_type and just assumed&#xA;TYPE_SRB, which results in a jump to an invalid pointer in target-mode&#xA;with TYPE_TGT_CMD:&#xA;&#xA;qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success&#xA;  0000000009f7a79b&#xA;qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h&#xA;  mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.&#xA;qla2xxx [0000:65:00.0]-d01e:8: -&gt; fwdump no buffer&#xA;qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event&#xA;  0x8002 occurred&#xA;qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -&#xA;  ha=0000000058183fda.&#xA;BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;PF: supervisor instruction fetch in kernel mode&#xA;PF: error_code(0x0010) - not-present page&#xA;PGD 0 P4D 0&#xA;Oops: 0010 [#1] SMP&#xA;CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G           O       6.1.133 #1&#xA;Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023&#xA;RIP: 0010:0x0&#xA;Code: Unable to access opcode bytes at 0xffffffffffffffd6.&#xA;RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206&#xA;RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000&#xA;RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0&#xA;RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045&#xA;R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40&#xA;R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400&#xA;FS:  0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000&#xA;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0&#xA;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000&#xA;DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; ? __die+0x4d/0x8b&#xA; ? page_fault_oops+0x91/0x180&#xA; ? trace_buffer_unlock_commit_regs+0x38/0x1a0&#xA; ? exc_page_fault+0x391/0x5e0&#xA; ? asm_exc_page_fault+0x22/0x30&#xA; __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]&#xA; qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]&#xA; qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]&#xA; qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]&#xA; qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]&#xA; kthread+0xa8/0xd0&#xA; &lt;/TASK&gt;&#xA;&#xA;Then commit 4475afa2646d (&#34;scsi: qla2xxx: Complete command early within&#xA;lock&#34;) added the spinlock back, because not having the lock caused a&#xA;race and a crash.  But qla2x00_abort_srb() in the switch below already&#xA;checks for qla2x00_chip_is_down() and handles it the same way, so the&#xA;code above the switch is now redundant and still buggy in target-mode.&#xA;Remove it.&#xA;CVE-2025-71089:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;iommu: disable SVA when CONFIG_X86 is set&#xA;&#xA;Patch series &#34;Fix stale IOTLB entries for kernel address space&#34;, v7.&#xA;&#xA;This proposes a fix for a security vulnerability related to IOMMU Shared&#xA;Virtual Addressing (SVA).  In an SVA context, an IOMMU can cache kernel&#xA;page table entries.  When a kernel page table page is freed and&#xA;reallocated for another purpose, the IOMMU might still hold stale,&#xA;incorrect entries.  This can be exploited to cause a use-after-free or&#xA;write-after-free condition, potentially leading to privilege escalation or&#xA;data corruption.&#xA;&#xA;This solution introduces a deferred freeing mechanism for kernel page&#xA;table pages, which provides a safe window to notify the IOMMU to&#xA;invalidate its caches before the page is reused.&#xA;&#xA;&#xA;This patch (of 8):&#xA;&#xA;In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware&#xA;shares and walks the CPU&#39;s page tables.  The x86 architecture maps the&#xA;kernel&#39;s virtual address space into the upper portion of every process&#39;s&#xA;page table.  Consequently, in an SVA context, the IOMMU hardware can walk&#xA;and cache kernel page table entries.&#xA;&#xA;The Linux kernel currently lacks a notification mechanism for kernel page&#xA;table changes, specifically when page table pages are freed and reused. &#xA;The IOMMU driver is only notified of changes to user virtual address&#xA;mappings.  This can cause the IOMMU&#39;s internal caches to retain stale&#xA;entries for kernel VA.&#xA;&#xA;Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when&#xA;kernel page table pages are freed and later reallocated.  The IOMMU could&#xA;misinterpret the new data as valid page table entries.  The IOMMU might&#xA;then walk into attacker-controlled memory, leading to arbitrary physical&#xA;memory DMA access or privilege escalation.  This is also a&#xA;Write-After-Free issue, as the IOMMU will potentially continue to write&#xA;Accessed and Dirty bits to the freed memory while attempting to walk the&#xA;stale page tables.&#xA;&#xA;Currently, SVA contexts are unprivileged and cannot access kernel&#xA;mappings.  However, the IOMMU will still walk kernel-only page tables all&#xA;the way down to the leaf entries, where it realizes the mapping is for the&#xA;kernel and errors out.  This means the IOMMU still caches these&#xA;intermediate page table entries, making the described vulnerability a real&#xA;concern.&#xA;&#xA;Disable SVA on x86 architecture until the IOMMU can receive notification&#xA;to flush the paging cache before freeing the CPU kernel page table pages.&#xA;CVE-2025-71096:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly&#xA;&#xA;The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a&#xA;LS_NLA_TYPE_DGID attribute, it is invalid if it does not.&#xA;&#xA;Use the nl parsing logic properly and call nla_parse_deprecated() to fill&#xA;the nlattrs array and then directly index that array to get the data for&#xA;the DGID. Just fail if it is NULL.&#xA;&#xA;Remove the for loop searching for the nla, and squash the validation and&#xA;parsing into one function.&#xA;&#xA;Fixes an uninitialized read from the stack triggered by userspace if it&#xA;does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE&#xA;query.&#xA;&#xA;    BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]&#xA;    BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490&#xA;     hex_byte_pack include/linux/hex.h:13 [inline]&#xA;     ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490&#xA;     ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509&#xA;     ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633&#xA;     pointer+0xc09/0x1bd0 lib/vsprintf.c:2542&#xA;     vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930&#xA;     vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279&#xA;     vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426&#xA;     vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465&#xA;     vprintk+0x36/0x50 kernel/printk/printk_safe.c:82&#xA;     _printk+0x17e/0x1b0 kernel/printk/printk.c:2475&#xA;     ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]&#xA;     ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141&#xA;     rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]&#xA;     rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]&#xA;     rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259&#xA;     netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]&#xA;     netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346&#xA;     netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896&#xA;     sock_sendmsg_nosec net/socket.c:714 [inline]&#xA;     __sock_sendmsg+0x333/0x3d0 net/socket.c:729&#xA;     ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617&#xA;     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671&#xA;     __sys_sendmsg+0x1aa/0x300 net/socket.c:2703&#xA;     __compat_sys_sendmsg net/compat.c:346 [inline]&#xA;     __do_compat_sys_sendmsg net/compat.c:353 [inline]&#xA;     __se_compat_sys_sendmsg net/compat.c:350 [inline]&#xA;     __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350&#xA;     ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371&#xA;     do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]&#xA;     __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306&#xA;     do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331&#xA;     do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3&#xA;CVE-2025-71097:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv4: Fix reference count leak when using error routes with nexthop objects&#xA;&#xA;When a nexthop object is deleted, it is marked as dead and then&#xA;fib_table_flush() is called to flush all the routes that are using the&#xA;dead nexthop.&#xA;&#xA;The current logic in fib_table_flush() is to only flush error routes&#xA;(e.g., blackhole) when it is called as part of network namespace&#xA;dismantle (i.e., with flush_all=true). Therefore, error routes are not&#xA;flushed when their nexthop object is deleted:&#xA;&#xA; # ip link add name dummy1 up type dummy&#xA; # ip nexthop add id 1 dev dummy1&#xA; # ip route add 198.51.100.1/32 nhid 1&#xA; # ip route add blackhole 198.51.100.2/32 nhid 1&#xA; # ip nexthop del id 1&#xA; # ip route show&#xA; blackhole 198.51.100.2 nhid 1 dev dummy1&#xA;&#xA;As such, they keep holding a reference on the nexthop object which in&#xA;turn holds a reference on the nexthop device, resulting in a reference&#xA;count leak:&#xA;&#xA; # ip link del dev dummy1&#xA; [   70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2&#xA;&#xA;Fix by flushing error routes when their nexthop is marked as dead.&#xA;&#xA;IPv6 does not suffer from this problem.&#xA;CVE-2025-71098:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ip6_gre: make ip6gre_header() robust&#xA;&#xA;Over the years, syzbot found many ways to crash the kernel&#xA;in ip6gre_header() [1].&#xA;&#xA;This involves team or bonding drivers ability to dynamically&#xA;change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len&#xA;&#xA;In this particular crash mld_newpack() allocated an skb&#xA;with a too small reserve/headroom, and by the time mld_sendpack()&#xA;was called, syzbot managed to attach an ip6gre device.&#xA;&#xA;[1]&#xA;skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0&#xA;------------[ cut here ]------------&#xA; kernel BUG at net/core/skbuff.c:213 !&#xA; &lt;TASK&gt;&#xA;  skb_under_panic net/core/skbuff.c:223 [inline]&#xA;  skb_push+0xc3/0xe0 net/core/skbuff.c:2641&#xA;  ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371&#xA;  dev_hard_header include/linux/netdevice.h:3436 [inline]&#xA;  neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618&#xA;  neigh_output include/net/neighbour.h:556 [inline]&#xA;  ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136&#xA; __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]&#xA;  ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220&#xA;  NF_HOOK_COND include/linux/netfilter.h:307 [inline]&#xA;  ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247&#xA;  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318&#xA;  mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855&#xA;  mld_send_cr net/ipv6/mcast.c:2154 [inline]&#xA;  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693&#xA;CVE-2025-71109:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits&#xA;&#xA;Since commit e424054000878 (&#34;MIPS: Tracing: Reduce the overhead of&#xA;dynamic Function Tracer&#34;), the macro UASM_i_LA_mostly has been used,&#xA;and this macro can generate more than 2 instructions. At the same&#xA;time, the code in ftrace assumes that no more than 2 instructions can&#xA;be generated, which is why it stores them in an int[2] array. However,&#xA;as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)&#xA;causes a buffer overflow when _mcount is beyond 32 bits. This leads to&#xA;corruption of the variables located in the __read_mostly section.&#xA;&#xA;This corruption was observed because the variable&#xA;__cpu_primary_thread_mask was corrupted, causing a hang very early&#xA;during boot.&#xA;&#xA;This fix prevents the corruption by avoiding the generation of&#xA;instructions if they could exceed 2 instructions in&#xA;length. Fortunately, insn_la_mcount is only used if the instrumented&#xA;code is located outside the kernel code section, so dynamic ftrace can&#xA;still be used, albeit in a more limited scope. This is still&#xA;preferable to corrupting memory and/or crashing the kernel.&#xA;CVE-2025-71111:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;hwmon: (w83791d) Convert macros to functions to avoid TOCTOU&#xA;&#xA;The macro FAN_FROM_REG evaluates its arguments multiple times. When used&#xA;in lockless contexts involving shared driver data, this leads to&#xA;Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially&#xA;causing divide-by-zero errors.&#xA;&#xA;Convert the macro to a static function. This guarantees that arguments&#xA;are evaluated only once (pass-by-value), preventing the race&#xA;conditions.&#xA;&#xA;Additionally, in store_fan_div, move the calculation of the minimum&#xA;limit inside the update lock. This ensures that the read-modify-write&#xA;sequence operates on consistent data.&#xA;&#xA;Adhere to the principle of minimal changes by only converting macros&#xA;that evaluate arguments multiple times and are used in lockless&#xA;contexts.&#xA;CVE-2025-71114:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;via_wdt: fix critical boot hang due to unnamed resource allocation&#xA;&#xA;The VIA watchdog driver uses allocate_resource() to reserve a MMIO&#xA;region for the watchdog control register. However, the allocated&#xA;resource was not given a name, which causes the kernel resource tree&#xA;to contain an entry marked as &#34;&lt;BAD&gt;&#34; under /proc/iomem on x86&#xA;platforms.&#xA;&#xA;During boot, this unnamed resource can lead to a critical hang because&#xA;subsequent resource lookups and conflict checks fail to handle the&#xA;invalid entry properly.&#xA;CVE-2025-71116:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: make decode_pool() more resilient against corrupted osdmaps&#xA;&#xA;If the osdmap is (maliciously) corrupted such that the encoded length&#xA;of ceph_pg_pool envelope is less than what is expected for a particular&#xA;encoding version, out-of-bounds reads may ensue because the only bounds&#xA;check that is there is based on that length value.&#xA;&#xA;This patch adds explicit bounds checks for each field that is decoded&#xA;or skipped.&#xA;CVE-2025-71118:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ACPICA: Avoid walking the Namespace if start_node is NULL&#xA;&#xA;Although commit 0c9992315e73 (&#34;ACPICA: Avoid walking the ACPI Namespace&#xA;if it is not there&#34;) fixed the situation when both start_node and&#xA;acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed&#xA;on Honor Magicbook 14 Pro [1].&#xA;&#xA;That happens due to the access to the member of parent_node in&#xA;acpi_ns_get_next_node().  The NULL pointer dereference will always&#xA;happen, no matter whether or not the start_node is equal to&#xA;ACPI_ROOT_OBJECT, so move the check of start_node being NULL&#xA;out of the if block.&#xA;&#xA;Unfortunately, all the attempts to contact Honor have failed, they&#xA;refused to provide any technical support for Linux.&#xA;&#xA;The bad DSDT table&#39;s dump could be found on GitHub [2].&#xA;&#xA;DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025&#xA;&#xA;[ rjw: Subject adjustment, changelog edits ]&#xA;CVE-2025-71145:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;usb: phy: isp1301: fix non-OF device reference imbalance&#xA;&#xA;A recent change fixing a device reference leak in a UDC driver&#xA;introduced a potential use-after-free in the non-OF case as the&#xA;isp1301_get_client() helper only increases the reference count for the&#xA;returned I2C device in the OF case.&#xA;&#xA;Increment the reference count also for non-OF so that the caller can&#xA;decrement it unconditionally.&#xA;&#xA;Note that this is inherently racy just as using the returned I2C device&#xA;is since nothing is preventing the PHY driver from being unbound while&#xA;in use.&#xA;CVE-2025-71154:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: rtl8150: fix memory leak on usb_submit_urb() failure&#xA;&#xA;In async_set_registers(), when usb_submit_urb() fails, the allocated&#xA;  async_req structure and URB are not freed, causing a memory leak.&#xA;&#xA;  The completion callback async_set_reg_cb() is responsible for freeing&#xA;  these allocations, but it is only called after the URB is successfully&#xA;  submitted and completes (successfully or with error). If submission&#xA;  fails, the callback never runs and the memory is leaked.&#xA;&#xA;  Fix this by freeing both the URB and the request structure in the error&#xA;  path when usb_submit_urb() fails.&#xA;CVE-2025-71161:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dm-verity: disable recursive forward error correction&#xA;&#xA;There are two problems with the recursive correction:&#xA;&#xA;1. It may cause denial-of-service. In fec_read_bufs, there is a loop that&#xA;has 253 iterations. For each iteration, we may call verity_hash_for_block&#xA;recursively. There is a limit of 4 nested recursions - that means that&#xA;there may be at most 253^4 (4 billion) iterations. Red Hat QE team&#xA;actually created an image that pushes dm-verity to this limit - and this&#xA;image just makes the udev-worker process get stuck in the &#39;D&#39; state.&#xA;&#xA;2. It doesn&#39;t work. In fec_read_bufs we store data into the variable&#xA;&#34;fio-&gt;bufs&#34;, but fio bufs is shared between recursive invocations, if&#xA;&#34;verity_hash_for_block&#34; invoked correction recursively, it would&#xA;overwrite partially filled fio-&gt;bufs.&#xA;CVE-2025-71186:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;dmaengine: stm32: dmamux: fix device leak on route allocation&#xA;&#xA;Make sure to drop the reference taken when looking up the DMA mux&#xA;platform device during route allocation.&#xA;&#xA;Note that holding a reference to a device does not prevent its driver&#xA;data from going away so there is no point in keeping the reference.&#xA;CVE-2025-71224:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: mac80211: ocb: skip rx_no_sta when interface is not joined&#xA;&#xA;ieee80211_ocb_rx_no_sta() assumes a valid channel context, which is only&#xA;present after JOIN_OCB.&#xA;&#xA;RX may run before JOIN_OCB is executed, in which case the OCB interface&#xA;is not operational. Skip RX peer handling when the interface is not&#xA;joined to avoid warnings in the RX path.&#xA;CVE-2025-71235:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: qla2xxx: Delay module unload while fabric scan in progress&#xA;&#xA;System crash seen during load/unload test in a loop.&#xA;&#xA;[105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086&#xA;[105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0&#xA;[105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000&#xA;[105954.384923] FS:  0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000&#xA;[105954.384925] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0&#xA;[105954.384928] PKRU: 55555554&#xA;[105954.384929] Call Trace:&#xA;[105954.384931]  &lt;IRQ&gt;&#xA;[105954.384934]  qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx]&#xA;[105954.384962]  ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx]&#xA;[105954.384980]  ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx]&#xA;[105954.384999]  ? __wake_up_common+0x80/0x190&#xA;[105954.385004]  ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx]&#xA;[105954.385023]  ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx]&#xA;[105954.385040]  ? __handle_irq_event_percpu+0x3d/0x190&#xA;[105954.385044]  ? handle_irq_event+0x58/0xb0&#xA;[105954.385046]  ? handle_edge_irq+0x93/0x240&#xA;[105954.385050]  ? __common_interrupt+0x41/0xa0&#xA;[105954.385055]  ? common_interrupt+0x3e/0xa0&#xA;[105954.385060]  ? asm_common_interrupt+0x22/0x40&#xA;&#xA;The root cause of this was that there was a free (dma_free_attrs) in the&#xA;interrupt context.  There was a device discovery/fabric scan in&#xA;progress.  A module unload was issued which set the UNLOADING flag.  As&#xA;part of the discovery, after receiving an interrupt a work queue was&#xA;scheduled (which involved a work to be queued).  Since the UNLOADING&#xA;flag is set, the work item was not allocated and the mapped memory had&#xA;to be freed.  The free occurred in interrupt context leading to system&#xA;crash.  Delay the driver unload until the fabric scan is complete to&#xA;avoid the crash.&#xA;CVE-2026-22976:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset&#xA;&#xA;`qfq_class-&gt;leaf_qdisc-&gt;q.qlen &gt; 0` does not imply that the class&#xA;itself is active.&#xA;&#xA;Two qfq_class objects may point to the same leaf_qdisc. This happens&#xA;when:&#xA;&#xA;1. one QFQ qdisc is attached to the dev as the root qdisc, and&#xA;&#xA;2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()&#xA;/ qdisc_put()) and is pending to be destroyed, as in function&#xA;tc_new_tfilter.&#xA;&#xA;When packets are enqueued through the root QFQ qdisc, the shared&#xA;leaf_qdisc-&gt;q.qlen increases. At the same time, the second QFQ&#xA;qdisc triggers qdisc_put and qdisc_destroy: the qdisc enters&#xA;qfq_reset() with its own q-&gt;q.qlen == 0, but its class&#39;s leaf&#xA;qdisc-&gt;q.qlen &gt; 0. Therefore, the qfq_reset would wrongly deactivate&#xA;an inactive aggregate and trigger a null-deref in qfq_deactivate_agg:&#xA;&#xA;[    0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000&#xA;[    0.903571] #PF: supervisor write access in kernel mode&#xA;[    0.903860] #PF: error_code(0x0002) - not-present page&#xA;[    0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0&#xA;[    0.904502] Oops: Oops: 0002 [#1] SMP NOPTI&#xA;[    0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE&#xA;[    0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014&#xA;[    0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))&#xA;[    0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0&#xA;&#xA;Code starting with the faulting instruction&#xA;===========================================&#xA;   0:&#x9;0f 84 4d 01 00 00    &#x9;je     0x153&#xA;   6:&#x9;48 89 70 18          &#x9;mov    %rsi,0x18(%rax)&#xA;   a:&#x9;8b 4b 10             &#x9;mov    0x10(%rbx),%ecx&#xA;   d:&#x9;48 c7 c2 ff ff ff ff &#x9;mov    $0xffffffffffffffff,%rdx&#xA;  14:&#x9;48 8b 78 08          &#x9;mov    0x8(%rax),%rdi&#xA;  18:&#x9;48 d3 e2             &#x9;shl    %cl,%rdx&#xA;  1b:&#x9;48 21 f2             &#x9;and    %rsi,%rdx&#xA;  1e:&#x9;48 2b 13             &#x9;sub    (%rbx),%rdx&#xA;  21:&#x9;48 8b 30             &#x9;mov    (%rax),%rsi&#xA;  24:&#x9;48 d3 ea             &#x9;shr    %cl,%rdx&#xA;  27:&#x9;8b 4b 18             &#x9;mov    0x18(%rbx),%ecx&#xA;&#x9;...&#xA;[    0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246&#xA;[    0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000&#xA;[    0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000&#xA;[    0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000&#xA;[    0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000&#xA;[    0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880&#xA;[    0.909179] FS:  000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000&#xA;[    0.909572] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[    0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0&#xA;[    0.910247] PKRU: 55555554&#xA;[    0.910391] Call Trace:&#xA;[    0.910527]  &lt;TASK&gt;&#xA;[    0.910638]  qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)&#xA;[    0.910826]  qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)&#xA;[    0.911040]  __qdisc_destroy (net/sched/sch_generic.c:1076)&#xA;[    0.911236]  tc_new_tfilter (net/sched/cls_api.c:2447)&#xA;[    0.911447]  rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)&#xA;[    0.911663]  ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)&#xA;[    0.911894]  netlink_rcv_skb (net/netlink/af_netlink.c:2550)&#xA;[    0.912100]  netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)&#xA;[    0.912296]  ? __alloc_skb (net/core/skbuff.c:706)&#xA;[    0.912484]  netlink_sendmsg (net/netlink/af&#xA;---truncated---&#xA;CVE-2026-22977:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: sock: fix hardened usercopy panic in sock_recv_errqueue&#xA;&#xA;skbuff_fclone_cache was created without defining a usercopy region,&#xA;[1] unlike skbuff_head_cache which properly whitelists the cb[] field.&#xA;[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is&#xA;enabled and the kernel attempts to copy sk_buff.cb data to userspace&#xA;via sock_recv_errqueue() -&gt; put_cmsg().&#xA;&#xA;The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone()&#xA;   (from skbuff_fclone_cache) [1]&#xA;2. The skb is cloned via skb_clone() using the pre-allocated fclone&#xA;[3] 3. The cloned skb is queued to sk_error_queue for timestamp&#xA;reporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)&#xA;5. sock_recv_errqueue() calls put_cmsg() to copy serr-&gt;ee from skb-&gt;cb&#xA;[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no&#xA;   usercopy whitelist [5]&#xA;&#xA;When cloned skbs allocated from skbuff_fclone_cache are used in the&#xA;socket error queue, accessing the sock_exterr_skb structure in skb-&gt;cb&#xA;via put_cmsg() triggers a usercopy hardening violation:&#xA;&#xA;[    5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object &#39;skbuff_fclone_cache&#39; (offset 296, size 16)!&#xA;[    5.382796] kernel BUG at mm/usercopy.c:102!&#xA;[    5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI&#xA;[    5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7&#xA;[    5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014&#xA;[    5.384903] RIP: 0010:usercopy_abort+0x6c/0x80&#xA;[    5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff &lt;0f&gt; 0b 490&#xA;[    5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246&#xA;[    5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74&#xA;[    5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0&#xA;[    5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74&#xA;[    5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001&#xA;[    5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00&#xA;[    5.384903] FS:  0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000&#xA;[    5.384903] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#xA;[    5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0&#xA;[    5.384903] PKRU: 55555554&#xA;[    5.384903] Call Trace:&#xA;[    5.384903]  &lt;TASK&gt;&#xA;[    5.384903]  __check_heap_object+0x9a/0xd0&#xA;[    5.384903]  __check_object_size+0x46c/0x690&#xA;[    5.384903]  put_cmsg+0x129/0x5e0&#xA;[    5.384903]  sock_recv_errqueue+0x22f/0x380&#xA;[    5.384903]  tls_sw_recvmsg+0x7ed/0x1960&#xA;[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[    5.384903]  ? schedule+0x6d/0x270&#xA;[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;[    5.384903]  ? mutex_unlock+0x81/0xd0&#xA;[    5.384903]  ? __pfx_mutex_unlock+0x10/0x10&#xA;[    5.384903]  ? __pfx_tls_sw_recvmsg+0x10/0x10&#xA;[    5.384903]  ? _raw_spin_lock_irqsave+0x8f/0xf0&#xA;[    5.384903]  ? _raw_read_unlock_irqrestore+0x20/0x40&#xA;[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5&#xA;&#xA;The crash offset 296 corresponds to skb2-&gt;cb within skbuff_fclones:&#xA;  - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 -&#xA;  offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 =&#xA;  272 + 24 (inside sock_exterr_skb.ee)&#xA;&#xA;This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.&#xA;&#xA;[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885&#xA;[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104&#xA;[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566&#xA;[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491&#xA;[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719&#xA;CVE-2026-22978:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: avoid kernel-infoleak from struct iw_point&#xA;&#xA;struct iw_point has a 32bit hole on 64bit arches.&#xA;&#xA;struct iw_point {&#xA;  void __user   *pointer;       /* Pointer to the data  (in user space) */&#xA;  __u16         length;         /* number of fields or size in bytes */&#xA;  __u16         flags;          /* Optional params */&#xA;};&#xA;&#xA;Make sure to zero the structure to avoid disclosing 32bits of kernel data&#xA;to user space.&#xA;CVE-2026-22991:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: make free_choose_arg_map() resilient to partial allocation&#xA;&#xA;free_choose_arg_map() may dereference a NULL pointer if its caller fails&#xA;after a partial allocation.&#xA;&#xA;For example, in decode_choose_args(), if allocation of arg_map-&gt;args&#xA;fails, execution jumps to the fail label and free_choose_arg_map() is&#xA;called. Since arg_map-&gt;size is updated to a non-zero value before memory&#xA;allocation, free_choose_arg_map() will iterate over arg_map-&gt;args and&#xA;dereference a NULL pointer.&#xA;&#xA;To prevent this potential NULL pointer dereference and make&#xA;free_choose_arg_map() more resilient, add checks for pointers before&#xA;iterating.&#xA;CVE-2026-23011:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipv4: ip_gre: make ipgre_header() robust&#xA;&#xA;Analog to commit db5b4e39c4e6 (&#34;ip6_gre: make ip6gre_header() robust&#34;)&#xA;&#xA;Over the years, syzbot found many ways to crash the kernel&#xA;in ipgre_header() [1].&#xA;&#xA;This involves team or bonding drivers ability to dynamically&#xA;change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len&#xA;&#xA;In this particular crash mld_newpack() allocated an skb&#xA;with a too small reserve/headroom, and by the time mld_sendpack()&#xA;was called, syzbot managed to attach an ipgre device.&#xA;&#xA;[1]&#xA;skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0&#xA; kernel BUG at net/core/skbuff.c:213 !&#xA;Oops: invalid opcode: 0000 [#1] SMP KASAN PTI&#xA;CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)&#xA;Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025&#xA;Workqueue: mld mld_ifc_work&#xA; RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  skb_under_panic net/core/skbuff.c:223 [inline]&#xA;  skb_push+0xc3/0xe0 net/core/skbuff.c:2641&#xA;  ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897&#xA;  dev_hard_header include/linux/netdevice.h:3436 [inline]&#xA;  neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618&#xA;  NF_HOOK_COND include/linux/netfilter.h:307 [inline]&#xA;  ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247&#xA;  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318&#xA;  mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855&#xA;  mld_send_cr net/ipv6/mcast.c:2154 [inline]&#xA;  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693&#xA;  process_one_work kernel/workqueue.c:3257 [inline]&#xA;  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340&#xA;  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421&#xA;  kthread+0x711/0x8a0 kernel/kthread.c:463&#xA;  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158&#xA;  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246&#xA;CVE-2026-23021:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net: usb: pegasus: fix memory leak in update_eth_regs_async()&#xA;&#xA;When asynchronously writing to the device registers and if usb_submit_urb()&#xA;fail, the code fail to release allocated to this point resources.&#xA;CVE-2026-23047:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;libceph: make calc_target() set t-&gt;paused, not just clear it&#xA;&#xA;Currently calc_target() clears t-&gt;paused if the request shouldn&#39;t be&#xA;paused anymore, but doesn&#39;t ever set t-&gt;paused even though it&#39;s able to&#xA;determine when the request should be paused.  Setting t-&gt;paused is left&#xA;to __submit_request() which is fine for regular requests but doesn&#39;t&#xA;work for linger requests -- since __submit_request() doesn&#39;t operate&#xA;on linger requests, there is nowhere for lreq-&gt;t.paused to be set.&#xA;One consequence of this is that watches don&#39;t get reestablished on&#xA;paused -&gt; unpaused transitions in cases where requests have been paused&#xA;long enough for the (paused) unwatch request to time out and for the&#xA;subsequent (re)watch request to enter the paused state.  On top of the&#xA;watch not getting reestablished, rbd_reregister_watch() gets stuck with&#xA;rbd_dev-&gt;watch_mutex held:&#xA;&#xA;  rbd_register_watch&#xA;    __rbd_register_watch&#xA;      ceph_osdc_watch&#xA;        linger_reg_commit_wait&#xA;&#xA;It&#39;s waiting for lreq-&gt;reg_commit_wait to be completed, but for that to&#xA;happen the respective request needs to end up on need_resend_linger list&#xA;and be kicked when requests are unpaused.  There is no chance for that&#xA;if the request in question is never marked paused in the first place.&#xA;&#xA;The fact that rbd_dev-&gt;watch_mutex remains taken out forever then&#xA;prevents the image from getting unmapped -- &#34;rbd unmap&#34; would inevitably&#xA;hang in D state on an attempt to grab the mutex.&#xA;CVE-2026-23058:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak&#xA;&#xA;Fix similar memory leak as in commit 7352e1d5932a (&#34;can: gs_usb:&#xA;gs_usb_receive_bulk_callback(): fix URB memory leak&#34;).&#xA;&#xA;In ems_usb_open(), the URBs for USB-in transfers are allocated, added to&#xA;the dev-&gt;rx_submitted anchor and submitted. In the complete callback&#xA;ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In&#xA;ems_usb_close() the URBs are freed by calling&#xA;usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).&#xA;&#xA;However, this does not take into account that the USB framework unanchors&#xA;the URB before the complete function is called. This means that once an&#xA;in-URB has been completed, it is no longer anchored and is ultimately not&#xA;released in ems_usb_close().&#xA;&#xA;Fix the memory leak by anchoring the URB in the&#xA;ems_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.&#xA;CVE-2026-23071:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;regmap: Fix race condition in hwspinlock irqsave routine&#xA;&#xA;Previously, the address of the shared member &#39;&amp;map-&gt;spinlock_flags&#39; was&#xA;passed directly to &#39;hwspin_lock_timeout_irqsave&#39;. This creates a race&#xA;condition where multiple contexts contending for the lock could overwrite&#xA;the shared flags variable, potentially corrupting the state for the&#xA;current lock owner.&#xA;&#xA;Fix this by using a local stack variable &#39;flags&#39; to store the IRQ state&#xA;temporarily.&#xA;CVE-2026-23076:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: ctxfi: Fix potential OOB access in audio mixer handling&#xA;&#xA;In the audio mixer handling code of ctxfi driver, the conf field is&#xA;used as a kind of loop index, and it&#39;s referred in the index callbacks&#xA;(amixer_index() and sum_index()).&#xA;&#xA;As spotted recently by fuzzers, the current code causes OOB access at&#xA;those functions.&#xA;| UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48&#xA;| index 8 is out of range for type &#39;unsigned char [8]&#39;&#xA;&#xA;After the analysis, the cause was found to be the lack of the proper&#xA;(re-)initialization of conj field.&#xA;&#xA;This patch addresses those OOB accesses by adding the proper&#xA;initializations of the loop indices.&#xA;CVE-2026-23080:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak&#xA;&#xA;Fix similar memory leak as in commit 7352e1d5932a (&#34;can: gs_usb:&#xA;gs_usb_receive_bulk_callback(): fix URB memory leak&#34;).&#xA;&#xA;In mcba_usb_probe() -&gt; mcba_usb_start(), the URBs for USB-in transfers are&#xA;allocated, added to the priv-&gt;rx_submitted anchor and submitted. In the&#xA;complete callback mcba_usb_read_bulk_callback(), the URBs are processed and&#xA;resubmitted. In mcba_usb_close() -&gt; mcba_urb_unlink() the URBs are freed by&#xA;calling usb_kill_anchored_urbs(&amp;priv-&gt;rx_submitted).&#xA;&#xA;However, this does not take into account that the USB framework unanchors&#xA;the URB before the complete function is called. This means that once an&#xA;in-URB has been completed, it is no longer anchored and is ultimately not&#xA;released in usb_kill_anchored_urbs().&#xA;&#xA;Fix the memory leak by anchoring the URB in the&#xA;mcba_usb_read_bulk_callback()to the priv-&gt;rx_submitted anchor.&#xA;CVE-2026-23083:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fou: Don&#39;t allow 0 for FOU_ATTR_IPPROTO.&#xA;&#xA;fou_udp_recv() has the same problem mentioned in the previous&#xA;patch.&#xA;&#xA;If FOU_ATTR_IPPROTO is set to 0, skb is not freed by&#xA;fou_udp_recv() nor &#34;resubmit&#34;-ted in ip_protocol_deliver_rcu().&#xA;&#xA;Let&#39;s forbid 0 for FOU_ATTR_IPPROTO.&#xA;CVE-2026-23084:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list&#xA;&#xA;When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is&#xA;set to false, the driver may request the PMAC_ID from the firmware of the&#xA;network card, and this function will store that PMAC_ID at the provided&#xA;address pmac_id. This is the contract of this function.&#xA;&#xA;However, there is a location within the driver where both&#xA;pmac_id_valid == false and pmac_id == NULL are being passed. This could&#xA;result in dereferencing a NULL pointer.&#xA;&#xA;To resolve this issue, it is necessary to pass the address of a stub&#xA;variable to the function.&#xA;CVE-2026-23089:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()&#xA;&#xA;When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees&#xA;mixer-&gt;id_elems but the controls already added to the card still&#xA;reference the freed memory. Later when snd_card_register() runs,&#xA;the OSS mixer layer calls their callbacks and hits a use-after-free read.&#xA;&#xA;Call trace:&#xA;  get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411&#xA;  get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241&#xA;  mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381&#xA;  snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887&#xA;  ...&#xA;  snd_card_register+0x4ed/0x6d0 sound/core/init.c:923&#xA;  usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025&#xA;&#xA;Fix by calling snd_ctl_remove() for all mixer controls before freeing&#xA;id_elems. We save the next pointer first because snd_ctl_remove()&#xA;frees the current element.&#xA;CVE-2026-23093:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ksmbd: smbd: fix dma_unmap_sg() nents&#xA;&#xA;The dma_unmap_sg() functions should be called with the same nents as the&#xA;dma_map_sg(), not the value the map function returned.&#xA;CVE-2026-23095:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;gue: Fix skb memleak with inner IP protocol 0.&#xA;&#xA;syzbot reported skb memleak below. [0]&#xA;&#xA;The repro generated a GUE packet with its inner protocol 0.&#xA;&#xA;gue_udp_recv() returns -guehdr-&gt;proto_ctype for &#34;resubmit&#34;&#xA;in ip_protocol_deliver_rcu(), but this only works with&#xA;non-zero protocol number.&#xA;&#xA;Let&#39;s drop such packets.&#xA;&#xA;Note that 0 is a valid number (IPv6 Hop-by-Hop Option).&#xA;&#xA;I think it is not practical to encap HOPOPT in GUE, so once&#xA;someone starts to complain, we could pass down a resubmit&#xA;flag pointer to distinguish two zeros from the upper layer:&#xA;&#xA;  * no error&#xA;  * resubmit HOPOPT&#xA;&#xA;[0]&#xA;BUG: memory leak&#xA;unreferenced object 0xffff888109695a00 (size 240):&#xA;  comm &#34;syz.0.17&#34;, pid 6088, jiffies 4294943096&#xA;  hex dump (first 32 bytes):&#xA;    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................&#xA;    00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............&#xA;  backtrace (crc a84b336f):&#xA;    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]&#xA;    slab_post_alloc_hook mm/slub.c:4958 [inline]&#xA;    slab_alloc_node mm/slub.c:5263 [inline]&#xA;    kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270&#xA;    __build_skb+0x23/0x60 net/core/skbuff.c:474&#xA;    build_skb+0x20/0x190 net/core/skbuff.c:490&#xA;    __tun_build_skb drivers/net/tun.c:1541 [inline]&#xA;    tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636&#xA;    tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770&#xA;    tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999&#xA;    new_sync_write fs/read_write.c:593 [inline]&#xA;    vfs_write+0x45d/0x710 fs/read_write.c:686&#xA;    ksys_write+0xa7/0x170 fs/read_write.c:738&#xA;    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94&#xA;    entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;CVE-2026-23096:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;uacce: fix cdev handling in the cleanup path&#xA;&#xA;When cdev_device_add fails, it internally releases the cdev memory,&#xA;and if cdev_device_del is then executed, it will cause a hang error.&#xA;To fix it, we check the return value of cdev_device_add() and clear&#xA;uacce-&gt;cdev to avoid calling cdev_device_del in the uacce_remove.&#xA;CVE-2026-23101:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;leds: led-class: Only Add LED to leds_list when it is fully ready&#xA;&#xA;Before this change the LED was added to leds_list before led_init_core()&#xA;gets called adding it the list before led_classdev.set_brightness_work gets&#xA;initialized.&#xA;&#xA;This leaves a window where led_trigger_register() of a LED&#39;s default&#xA;trigger will call led_trigger_set() which calls led_set_brightness()&#xA;which in turn will end up queueing the *uninitialized*&#xA;led_classdev.set_brightness_work.&#xA;&#xA;This race gets hit by the lenovo-thinkpad-t14s EC driver which registers&#xA;2 LEDs with a default trigger provided by snd_ctl_led.ko in quick&#xA;succession. The first led_classdev_register() causes an async modprobe of&#xA;snd_ctl_led to run and that async modprobe manages to exactly hit&#xA;the window where the second LED is on the leds_list without led_init_core()&#xA;being called for it, resulting in:&#xA;&#xA; ------------[ cut here ]------------&#xA; WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390&#xA; Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025&#xA; ...&#xA; Call trace:&#xA;  __flush_work+0x344/0x390 (P)&#xA;  flush_work+0x2c/0x50&#xA;  led_trigger_set+0x1c8/0x340&#xA;  led_trigger_register+0x17c/0x1c0&#xA;  led_trigger_register_simple+0x84/0xe8&#xA;  snd_ctl_led_init+0x40/0xf88 [snd_ctl_led]&#xA;  do_one_initcall+0x5c/0x318&#xA;  do_init_module+0x9c/0x2b8&#xA;  load_module+0x7e0/0x998&#xA;&#xA;Close the race window by moving the adding of the LED to leds_list to&#xA;after the led_init_core() call.&#xA;CVE-2026-23103:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ipvlan: Make the addrs_lock be per port&#xA;&#xA;Make the addrs_lock be per port, not per ipvlan dev.&#xA;&#xA;Initial code seems to be written in the assumption,&#xA;that any address change must occur under RTNL.&#xA;But it is not so for the case of IPv6. So&#xA;&#xA;1) Introduce per-port addrs_lock.&#xA;&#xA;2) It was needed to fix places where it was forgotten&#xA;to take lock (ipvlan_open/ipvlan_close)&#xA;&#xA;This appears to be a very minor problem though.&#xA;Since it&#39;s highly unlikely that ipvlan_add_addr() will&#xA;be called on 2 CPU simultaneously. But nevertheless,&#xA;this could cause:&#xA;&#xA;1) False-negative of ipvlan_addr_busy(): one interface&#xA;iterated through all port-&gt;ipvlans + ipvlan-&gt;addrs&#xA;under some ipvlan spinlock, and another added IP&#xA;under its own lock. Though this is only possible&#xA;for IPv6, since looks like only ipvlan_addr6_event() can be&#xA;called without rtnl_lock.&#xA;&#xA;2) Race since ipvlan_ht_addr_add(port) is called under&#xA;different ipvlan-&gt;addrs_lock locks&#xA;&#xA;This should not affect performance, since add/remove IP&#xA;is a rare situation and spinlock is not taken on fast&#xA;paths.&#xA;CVE-2026-23105:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag&#xA;&#xA;This is more of a preventive patch to make the code more consistent and&#xA;to prevent possible exploits that employ child qlen manipulations on qfq.&#xA;use cl_is_active instead of relying on the child qdisc&#39;s qlen to determine&#xA;class activation.&#xA;CVE-2026-23108:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak&#xA;&#xA;Fix similar memory leak as in commit 7352e1d5932a (&#34;can: gs_usb:&#xA;gs_usb_receive_bulk_callback(): fix URB memory leak&#34;).&#xA;&#xA;In usb_8dev_open() -&gt; usb_8dev_start(), the URBs for USB-in transfers are&#xA;allocated, added to the priv-&gt;rx_submitted anchor and submitted. In the&#xA;complete callback usb_8dev_read_bulk_callback(), the URBs are processed and&#xA;resubmitted. In usb_8dev_close() -&gt; unlink_all_urbs() the URBs are freed by&#xA;calling usb_kill_anchored_urbs(&amp;priv-&gt;rx_submitted).&#xA;&#xA;However, this does not take into account that the USB framework unanchors&#xA;the URB before the complete function is called. This means that once an&#xA;in-URB has been completed, it is no longer anchored and is ultimately not&#xA;released in usb_kill_anchored_urbs().&#xA;&#xA;Fix the memory leak by anchoring the URB in the&#xA;usb_8dev_read_bulk_callback() to the priv-&gt;rx_submitted anchor.&#xA;CVE-2026-23110:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: core: Wake up the error handler when final completions race against each other&#xA;&#xA;The fragile ordering between marking commands completed or failed so&#xA;that the error handler only wakes when the last running command&#xA;completes or times out has race conditions. These race conditions can&#xA;cause the SCSI layer to fail to wake the error handler, leaving I/O&#xA;through the SCSI host stuck as the error state cannot advance.&#xA;&#xA;First, there is an memory ordering issue within scsi_dec_host_busy().&#xA;The write which clears SCMD_STATE_INFLIGHT may be reordered with reads&#xA;counting in scsi_host_busy(). While the local CPU will see its own&#xA;write, reordering can allow other CPUs in scsi_dec_host_busy() or&#xA;scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to&#xA;see a host busy equal to the host_failed count.&#xA;&#xA;This race condition can be prevented with a memory barrier on the error&#xA;path to force the write to be visible before counting host busy&#xA;commands.&#xA;&#xA;Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By&#xA;counting busy commands before incrementing host_failed, it can race with a&#xA;final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does&#xA;not see host_failed incremented but scsi_eh_inc_host_failed() counts busy&#xA;commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),&#xA;resulting in neither waking the error handler task.&#xA;&#xA;This needs the call to scsi_host_busy() to be moved after host_failed is&#xA;incremented to close the race condition.&#xA;CVE-2026-23113:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#xA;&#xA;Currently this is checked before running the pending work. Normally this&#xA;is quite fine, as work items either end up blocking (which will create a&#xA;new worker for other items), or they complete fairly quickly. But syzbot&#xA;reports an issue where io-wq takes seemingly forever to exit, and with a&#xA;bit of debugging, this turns out to be because it queues a bunch of big&#xA;(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&#39;t&#xA;support -&gt;read_iter(), loop_rw_iter() ends up handling them. Each read&#xA;returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of&#xA;these pending, processing the whole chain can take a long time. Easily&#xA;longer than the syzbot uninterruptible sleep timeout of 140 seconds.&#xA;This then triggers a complaint off the io-wq exit path:&#xA;&#xA;INFO: task syz.4.135:6326 blocked for more than 143 seconds.&#xA;      Not tainted syzkaller #0&#xA;      Blocked by coredump.&#xA;&#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.&#xA;task:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957   task_flags:0x400548 flags:0x00080000&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA; context_switch kernel/sched/core.c:5256 [inline]&#xA; __schedule+0x1139/0x6150 kernel/sched/core.c:6863&#xA; __schedule_loop kernel/sched/core.c:6945 [inline]&#xA; schedule+0xe7/0x3a0 kernel/sched/core.c:6960&#xA; schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75&#xA; do_wait_for_common kernel/sched/completion.c:100 [inline]&#xA; __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121&#xA; io_wq_exit_workers io_uring/io-wq.c:1328 [inline]&#xA; io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356&#xA; io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203&#xA; io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651&#xA; io_uring_files_cancel include/linux/io_uring.h:19 [inline]&#xA; do_exit+0x2ce/0x2bd0 kernel/exit.c:911&#xA; do_group_exit+0xd3/0x2a0 kernel/exit.c:1112&#xA; get_signal+0x2671/0x26d0 kernel/signal.c:3034&#xA; arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337&#xA; __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]&#xA; exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75&#xA; __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]&#xA; syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]&#xA; syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]&#xA; syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]&#xA; do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;RIP: 0033:0x7fa02738f749&#xA;RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca&#xA;RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749&#xA;RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098&#xA;RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000&#xA;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000&#xA;R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98&#xA;&#xA;There&#39;s really nothing wrong here, outside of processing these reads&#xA;will take a LONG time. However, we can speed up the exit by checking the&#xA;IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will&#xA;exit the ring after queueing up all of these reads. Then once the first&#xA;item is processed, io-wq will simply cancel the rest. That should avoid&#xA;syzbot running into this complaint again.&#xA;CVE-2026-23119:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bonding: provide a net pointer to __skb_flow_dissect()&#xA;&#xA;After 3cbf4ffba5ee (&#34;net: plumb network namespace into __skb_flow_dissect&#34;)&#xA;we have to provide a net pointer to __skb_flow_dissect(),&#xA;either via skb-&gt;dev, skb-&gt;sk, or a user provided pointer.&#xA;&#xA;In the following case, syzbot was able to cook a bare skb.&#xA;&#xA;WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053&#xA;Call Trace:&#xA; &lt;TASK&gt;&#xA;  bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]&#xA;  __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157&#xA;  bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]&#xA;  bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]&#xA;  bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515&#xA;  xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388&#xA;  bpf_prog_run_xdp include/net/xdp.h:700 [inline]&#xA;  bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421&#xA;  bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390&#xA;  bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703&#xA;  __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182&#xA;  __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]&#xA;  __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]&#xA;  __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272&#xA;  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;  do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94&#xA;CVE-2026-23120:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;l2tp: avoid one data-race in l2tp_tunnel_del_work()&#xA;&#xA;We should read sk-&gt;sk_socket only when dealing with kernel sockets.&#xA;&#xA;syzbot reported the following data-race:&#xA;&#xA;BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release&#xA;&#xA;write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:&#xA;  sk_set_socket include/net/sock.h:2092 [inline]&#xA;  sock_orphan include/net/sock.h:2118 [inline]&#xA;  sk_common_release+0xae/0x230 net/core/sock.c:4003&#xA;  udp_lib_close+0x15/0x20 include/net/udp.h:325&#xA;  inet_release+0xce/0xf0 net/ipv4/af_inet.c:437&#xA;  __sock_release net/socket.c:662 [inline]&#xA;  sock_close+0x6b/0x150 net/socket.c:1455&#xA;  __fput+0x29b/0x650 fs/file_table.c:468&#xA;  ____fput+0x1c/0x30 fs/file_table.c:496&#xA;  task_work_run+0x131/0x1a0 kernel/task_work.c:233&#xA;  resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]&#xA;  __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]&#xA;  exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75&#xA;  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]&#xA;  syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]&#xA;  syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]&#xA;  syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]&#xA;  do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:&#xA;  l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418&#xA;  process_one_work kernel/workqueue.c:3257 [inline]&#xA;  process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340&#xA;  worker_thread+0x582/0x770 kernel/workqueue.c:3421&#xA;  kthread+0x489/0x510 kernel/kthread.c:463&#xA;  ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158&#xA;  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246&#xA;&#xA;value changed: 0xffff88811b818000 -&gt; 0x0000000000000000&#xA;CVE-2026-23121:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mISDN: annotate data-race around dev-&gt;work&#xA;&#xA;dev-&gt;work can re read locklessly in mISDN_read()&#xA;and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.&#xA;&#xA;BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read&#xA;&#xA;write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1:&#xA;  misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]&#xA;  mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233&#xA;  vfs_ioctl fs/ioctl.c:51 [inline]&#xA;  __do_sys_ioctl fs/ioctl.c:597 [inline]&#xA;  __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583&#xA;  __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583&#xA;  x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17&#xA;  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;  do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0:&#xA;  mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112&#xA;  do_loop_readv_writev fs/read_write.c:847 [inline]&#xA;  vfs_readv+0x3fb/0x690 fs/read_write.c:1020&#xA;  do_readv+0xe7/0x210 fs/read_write.c:1080&#xA;  __do_sys_readv fs/read_write.c:1165 [inline]&#xA;  __se_sys_readv fs/read_write.c:1162 [inline]&#xA;  __x64_sys_readv+0x45/0x50 fs/read_write.c:1162&#xA;  x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20&#xA;  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]&#xA;  do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94&#xA; entry_SYSCALL_64_after_hwframe+0x77/0x7f&#xA;&#xA;value changed: 0x00000000 -&gt; 0x00000001&#xA;CVE-2026-23125:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT&#xA;&#xA;A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key&#xA;initialization fails:&#xA;&#xA;  ==================================================================&#xA;  KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]&#xA;  CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2&#xA;  RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]&#xA;  RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401&#xA;  Call Trace:&#xA;&#xA;  sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189&#xA;  sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111&#xA;  sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217&#xA;  sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787&#xA;  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]&#xA;  sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169&#xA;  sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052&#xA;  sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88&#xA;  sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243&#xA;  sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127&#xA;&#xA;The issue is triggered when sctp_auth_asoc_init_active_key() fails in&#xA;sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the&#xA;command sequence is currently:&#xA;&#xA;- SCTP_CMD_PEER_INIT&#xA;- SCTP_CMD_TIMER_STOP (T1_INIT)&#xA;- SCTP_CMD_TIMER_START (T1_COOKIE)&#xA;- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)&#xA;- SCTP_CMD_ASSOC_SHKEY&#xA;- SCTP_CMD_GEN_COOKIE_ECHO&#xA;&#xA;If SCTP_CMD_ASSOC_SHKEY fails, asoc-&gt;shkey remains NULL, while&#xA;asoc-&gt;peer.auth_capable and asoc-&gt;peer.peer_chunks have already been set by&#xA;SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL&#xA;to be queued by sctp_datamsg_from_user().&#xA;&#xA;Since command interpretation stops on failure, no COOKIE_ECHO should been&#xA;sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already&#xA;been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As&#xA;a result, the DATA chunk can be transmitted together with the COOKIE_ECHO&#xA;in sctp_outq_flush_data(), leading to the observed issue.&#xA;&#xA;Similar to the other places where it calls sctp_auth_asoc_init_active_key()&#xA;right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY&#xA;immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting&#xA;T1_COOKIE. This ensures that if shared key generation fails, authenticated&#xA;DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,&#xA;giving the client another chance to process INIT_ACK and retry key setup.&#xA;CVE-2026-23133:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;wifi: ath10k: fix dma_free_coherent() pointer&#xA;&#xA;dma_alloc_coherent() allocates a DMA mapped buffer and stores the&#xA;addresses in XXX_unaligned fields.  Those should be reused when freeing&#xA;the buffer rather than the aligned addresses.&#xA;CVE-2026-23137:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;of: unittest: Fix memory leak in unittest_data_add()&#xA;&#xA;In unittest_data_add(), if of_resolve_phandles() fails, the allocated&#xA;unittest_data is not freed, leading to a memory leak.&#xA;&#xA;Fix this by using scope-based cleanup helper __free(kfree) for automatic&#xA;resource cleanup. This ensures unittest_data is automatically freed when&#xA;it goes out of scope in error paths.&#xA;&#xA;For the success path, use retain_and_null_ptr() to transfer ownership&#xA;of the memory to the device tree and prevent double freeing.&#xA;CVE-2026-23141:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;btrfs: send: check for inline extents in range_is_hole_in_parent()&#xA;&#xA;Before accessing the disk_bytenr field of a file extent item we need&#xA;to check if we are dealing with an inline extent.&#xA;This is because for inline extents their data starts at the offset of&#xA;the disk_bytenr field. So accessing the disk_bytenr&#xA;means we are accessing inline data or in case the inline data is less&#xA;than 8 bytes we can actually cause an invalid&#xA;memory access if this inline extent item is the first item in the leaf&#xA;or access metadata from other items.&#xA;CVE-2026-23144:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure&#xA;&#xA;When a context DAMON sysfs directory setup is failed after setup of attrs/&#xA;directory, subdirectories of attrs/ directory are not cleaned up.  As a&#xA;result, DAMON sysfs interface is nearly broken until the system reboots,&#xA;and the memory for the unremoved directory is leaked.&#xA;&#xA;Cleanup the directories under such failures.&#xA;CVE-2026-23164:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;rocker: fix memory leak in rocker_world_port_post_fini()&#xA;&#xA;In rocker_world_port_pre_init(), rocker_port-&gt;wpriv is allocated with&#xA;kzalloc(wops-&gt;port_priv_size, GFP_KERNEL). However, in&#xA;rocker_world_port_post_fini(), the memory is only freed when&#xA;wops-&gt;port_post_fini callback is set:&#xA;&#xA;    if (!wops-&gt;port_post_fini)&#xA;        return;&#xA;    wops-&gt;port_post_fini(rocker_port);&#xA;    kfree(rocker_port-&gt;wpriv);&#xA;&#xA;Since rocker_ofdpa_ops does not implement port_post_fini callback&#xA;(it is NULL), the wpriv memory allocated for each port is never freed&#xA;when ports are removed. This leads to a memory leak of&#xA;sizeof(struct ofdpa_port) bytes per port on every device removal.&#xA;&#xA;Fix this by always calling kfree(rocker_port-&gt;wpriv) regardless of&#xA;whether the port_post_fini callback exists.&#xA;CVE-2026-23190:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;ASoC: amd: fix memory leak in acp3x pdm dma ops&#xA;CVE-2026-23193:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()&#xA;&#xA;In iscsit_dec_session_usage_count(), the function calls complete() while&#xA;holding the sess-&gt;session_usage_lock. Similar to the connection usage count&#xA;logic, the waiter signaled by complete() (e.g., in the session release&#xA;path) may wake up and free the iscsit_session structure immediately.&#xA;&#xA;This creates a race condition where the current thread may attempt to&#xA;execute spin_unlock_bh() on a session structure that has already been&#xA;deallocated, resulting in a KASAN slab-use-after-free.&#xA;&#xA;To resolve this, release the session_usage_lock before calling complete()&#xA;to ensure all dereferences of the sess pointer are finished before the&#xA;waiter is allowed to proceed with deallocation.&#xA;CVE-2026-23221:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;bus: fsl-mc: fix use-after-free in driver_override_show()&#xA;&#xA;The driver_override_show() function reads the driver_override string&#xA;without holding the device_lock. However, driver_override_store() uses&#xA;driver_set_override(), which modifies and frees the string while holding&#xA;the device_lock.&#xA;&#xA;This can result in a concurrent use-after-free if the string is freed&#xA;by the store function while being read by the show function.&#xA;&#xA;Fix this by holding the device_lock around the read operation.&#xA;CVE-2026-23222:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly&#xA;&#xA;The existing allocation of scatterlists in omap_crypto_copy_sg_lists()&#xA;was allocating an array of scatterlist pointers, not scatterlist objects,&#xA;resulting in a 4x too small allocation.&#xA;&#xA;Use sizeof(*new_sg) to get the correct object size.&#xA;CVE-2026-23229:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;crypto: virtio - Add spinlock protection with virtqueue notification&#xA;&#xA;When VM boots with one virtio-crypto PCI device and builtin backend,&#xA;run openssl benchmark command with multiple processes, such as&#xA;  openssl speed -evp aes-128-cbc -engine afalg  -seconds 10 -multi 32&#xA;&#xA;openssl processes will hangup and there is error reported like this:&#xA; virtio_crypto virtio0: dataq.0:id 3 is not a head!&#xA;&#xA;It seems that the data virtqueue need protection when it is handled&#xA;for virtio done notification. If the spinlock protection is added&#xA;in virtcrypto_done_task(), openssl benchmark with multiple processes&#xA;works well.&#xA;CVE-2026-23236:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;fbdev: smscufx: properly copy ioctl memory to kernelspace&#xA;&#xA;The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from&#xA;userspace to kernelspace, and instead directly references the memory,&#xA;which can cause problems if invalid data is passed from userspace.  Fix&#xA;this all up by correctly copying the memory before accessing it within&#xA;the kernel.&#xA;CVE-2026-23237:In the Linux kernel, the following vulnerability has been resolved:&#xA;&#xA;platform/x86: classmate-laptop: Add missing NULL pointer checks&#xA;&#xA;In a few places in the Classmate laptop driver, code using the accel&#xA;object may run before that object&#39;s address is stored in the driver&#xA;data of the input device using it.&#xA;&#xA;For example, cmpc_accel_sensitivity_store_v4() is the &#34;show&#34; method&#xA;of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),&#xA;before calling dev_set_drvdata() for inputdev-&gt;dev.  If the sysfs&#xA;attribute is accessed prematurely, the dev_get_drvdata(&amp;inputdev-&gt;dev)&#xA;call in in cmpc_accel_sensitivity_store_v4() returns NULL which&#xA;leads to a NULL pointer dereference going forward.&#xA;&#xA;Moreover, sysfs attributes using the input device are added before&#xA;initializing that device by cmpc_add_acpi_notify_device() and if one&#xA;of them is accessed before running that function, a NULL pointer&#xA;dereference will occur.&#xA;&#xA;For example, cmpc_accel_sensitivity_attr_v4 is added before calling&#xA;cmpc_add_acpi_notify_device() and if it is read prematurely, the&#xA;dev_get_drvdata(&amp;acpi-&gt;dev) call in cmpc_accel_sensitivity_show_v4()&#xA;returns NULL which leads to a NULL pointer dereference going forward.&#xA;&#xA;Fix this by adding NULL pointer checks in all of the relevant places.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="perf" release="316.0.0.219.u200" version="5.10.0">
					<filename>perf-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perf-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="316.0.0.219.u200" version="5.10.0">
					<filename>bpftool-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bpftool-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="316.0.0.219.u200" version="5.10.0">
					<filename>python3-perf-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-perf-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/kernel-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-tools-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/kernel-tools-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/kernel-tools-devel-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-devel-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/kernel-devel-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-headers-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/kernel-headers-5.10.0-316.0.0.219.u200.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/kernel-tools-devel-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="316.0.0.219.u200" version="5.10.0">
					<filename>bpftool-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bpftool-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-devel-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/kernel-devel-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="316.0.0.219.u200" version="5.10.0">
					<filename>perf-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/perf-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-headers-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/kernel-headers-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/kernel-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="316.0.0.219.u200" version="5.10.0">
					<filename>python3-perf-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-perf-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="316.0.0.219.u200" version="5.10.0">
					<filename>kernel-tools-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/kernel-tools-5.10.0-316.0.0.219.u200.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3134</id>
		<title>An update for mariadb is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21490&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21490" id="CVE-2025-21490" title="CVE-2025-21490" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30722&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30722" id="CVE-2025-30722" title="CVE-2025-30722" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30693&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30693" id="CVE-2025-30693" title="CVE-2025-30693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52970&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52970" id="CVE-2023-52970" title="CVE-2023-52970" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52969&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-52969" id="CVE-2023-52969" title="CVE-2023-52969" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-13699&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-13699" id="CVE-2025-13699" title="CVE-2025-13699" type="cve"></reference>
		</references>
		<description>CVE-2025-21490:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2025-30722:Vulnerability in the MySQL Client product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Client.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all MySQL Client accessible data as well as  unauthorized update, insert or delete access to some of MySQL Client accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N).&#xA;CVE-2025-30693:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).&#xA;CVE-2023-52970:MariaDB Server 10.4 through 10.5.*, 10.6 through 10.6.*, 10.7 through 10.11.*, 11.0 through 11.0.*, and 11.1 through 11.4.* crashes in Item_direct_view_ref::derived_field_transformer_for_where.&#xA;CVE-2023-52969:MariaDB Server 10.4 through 10.5.*, 10.6 through 10.6.*, 10.7 through 10.11.*, and 11.0 through 11.0.* can sometimes crash with an empty backtrace log. This may be related to make_aggr_tables_info and optimize_stage2.&#xA;CVE-2025-13699:MariaDB mariadb-dump Utility Directory Traversal Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of MariaDB. Interaction with the mariadb-dump utility is required to exploit this vulnerability but attack vectors may vary depending on the implementation.&#xA;&#xA;The specific flaw exists within the handling of view names. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-27000.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="4" name="mariadb-errmsg" release="2" version="10.5.29">
					<filename>mariadb-errmsg-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-errmsg-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-pam" release="2" version="10.5.29">
					<filename>mariadb-pam-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-pam-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb" release="2" version="10.5.29">
					<filename>mariadb-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-config" release="2" version="10.5.29">
					<filename>mariadb-config-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-config-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-gssapi-server" release="2" version="10.5.29">
					<filename>mariadb-gssapi-server-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-gssapi-server-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-test" release="2" version="10.5.29">
					<filename>mariadb-test-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-test-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-embedded" release="2" version="10.5.29">
					<filename>mariadb-embedded-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-embedded-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server" release="2" version="10.5.29">
					<filename>mariadb-server-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-server-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server-galera" release="2" version="10.5.29">
					<filename>mariadb-server-galera-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-server-galera-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-embedded-devel" release="2" version="10.5.29">
					<filename>mariadb-embedded-devel-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-embedded-devel-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-backup" release="2" version="10.5.29">
					<filename>mariadb-backup-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-backup-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-oqgraph-engine" release="2" version="10.5.29">
					<filename>mariadb-oqgraph-engine-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-oqgraph-engine-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-common" release="2" version="10.5.29">
					<filename>mariadb-common-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-common-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-devel" release="2" version="10.5.29">
					<filename>mariadb-devel-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-devel-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="4" name="mariadb-server-utils" release="2" version="10.5.29">
					<filename>mariadb-server-utils-10.5.29-2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mariadb-server-utils-10.5.29-2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-devel" release="2" version="10.5.29">
					<filename>mariadb-devel-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-devel-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-pam" release="2" version="10.5.29">
					<filename>mariadb-pam-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-pam-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-test" release="2" version="10.5.29">
					<filename>mariadb-test-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-test-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-common" release="2" version="10.5.29">
					<filename>mariadb-common-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-common-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-oqgraph-engine" release="2" version="10.5.29">
					<filename>mariadb-oqgraph-engine-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-oqgraph-engine-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-embedded" release="2" version="10.5.29">
					<filename>mariadb-embedded-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-embedded-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-embedded-devel" release="2" version="10.5.29">
					<filename>mariadb-embedded-devel-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-embedded-devel-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-gssapi-server" release="2" version="10.5.29">
					<filename>mariadb-gssapi-server-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-gssapi-server-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb" release="2" version="10.5.29">
					<filename>mariadb-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server-galera" release="2" version="10.5.29">
					<filename>mariadb-server-galera-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-server-galera-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-backup" release="2" version="10.5.29">
					<filename>mariadb-backup-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-backup-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-rocksdb-engine" release="2" version="10.5.29">
					<filename>mariadb-rocksdb-engine-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-rocksdb-engine-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server" release="2" version="10.5.29">
					<filename>mariadb-server-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-server-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-config" release="2" version="10.5.29">
					<filename>mariadb-config-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-config-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-errmsg" release="2" version="10.5.29">
					<filename>mariadb-errmsg-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-errmsg-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="4" name="mariadb-server-utils" release="2" version="10.5.29">
					<filename>mariadb-server-utils-10.5.29-2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mariadb-server-utils-10.5.29-2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3135</id>
		<title>An update for hsqldb is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-1183" id="CVE-2023-1183" title="CVE-2023-1183" type="cve"></reference>
		</references>
		<description>CVE-2023-1183:A flaw was found in the Libreoffice package. An attacker can craft an odb containing a &#34;database/script&#34; file with a SCRIPT command where the contents of the file could be written to a new file whose location was determined by the attacker.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="1" name="hsqldb-demo" release="6.u2" version="2.4.0">
					<filename>hsqldb-demo-2.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hsqldb-demo-2.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-javadoc" release="6.u2" version="2.4.0">
					<filename>hsqldb-javadoc-2.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hsqldb-javadoc-2.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-lib" release="6.u2" version="2.4.0">
					<filename>hsqldb-lib-2.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hsqldb-lib-2.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb-manual" release="6.u2" version="2.4.0">
					<filename>hsqldb-manual-2.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hsqldb-manual-2.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="hsqldb" release="6.u2" version="2.4.0">
					<filename>hsqldb-2.4.0-6.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hsqldb-2.4.0-6.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3136</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14831&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14831" id="CVE-2025-14831" title="CVE-2025-14831" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3832&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3832" id="CVE-2026-3832" title="CVE-2026-3832" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3833&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3833" id="CVE-2026-3833" title="CVE-2026-3833" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42009&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42009" id="CVE-2026-42009" title="CVE-2026-42009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42010&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42010" id="CVE-2026-42010" title="CVE-2026-42010" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42013&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42013" id="CVE-2026-42013" title="CVE-2026-42013" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42014&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42014" id="CVE-2026-42014" title="CVE-2026-42014" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42015" id="CVE-2026-42015" title="CVE-2026-42015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5260&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5260" id="CVE-2026-5260" title="CVE-2026-5260" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33846&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33846" id="CVE-2026-33846" title="CVE-2026-33846" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33845&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33845" id="CVE-2026-33845" title="CVE-2026-33845" type="cve"></reference>
		</references>
		<description>CVE-2025-14831:A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).&#xA;CVE-2026-3832:A flaw was found in gnutls. A remote attacker could exploit this vulnerability by presenting a specially crafted Online Certificate Status Protocol (OCSP) response during a TLS handshake. Due to a logic error in how gnutls processes multi-record OCSP responses, a client with OCSP verification enabled may incorrectly accept a revoked server certificate, potentially leading to a compromise of trust.&#xA;CVE-2026-3833:A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.&#xA;CVE-2026-42009:A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.&#xA;CVE-2026-42010:A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.&#xA;CVE-2026-42013:A flaw was found in gnutls. When validating certificates, an oversized Subject Alternative Name (SAN) could cause the validation process to incorrectly fall back to checking the Common Name (CN) field. This could allow a remote attacker to bypass proper certificate validation, potentially leading to spoofing or man-in-the-middle attacks.&#xA;CVE-2026-42014:Changing the Security Officer PIN with gnutls_pkcs11_token_set_pin() with oldpin == NULL for a token lacking a protected authentication path led to a use-after-free.&#xA;CVE-2026-42015:A flaw was found in gnutls. An off-by-one error exists in the PKCS#12 bag element bounds check. This vulnerability allows an remote attacker to write past the internal array of a PKCS#12 bag when appending to a bag that already contains 32 elements. This memory corruption could lead to a denial of service (DoS) or potentially other unspecified impacts.&#xA;CVE-2026-5260:A flaw was found in libgnutls. A remote attacker, by sending an extremely short premaster secret during an RSA key exchange to a server using an RSA key backed by a PKCS#11 token, could trigger a short heap overread. This memory corruption vulnerability could lead to information disclosure.&#xA;CVE-2026-33846:A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.&#xA;CVE-2026-33845:A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="gnutls-devel" release="23.u15" version="3.7.2">
					<filename>gnutls-devel-3.7.2-23.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gnutls-devel-3.7.2-23.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls" release="23.u15" version="3.7.2">
					<filename>gnutls-3.7.2-23.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gnutls-3.7.2-23.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gnutls-utils" release="23.u15" version="3.7.2">
					<filename>gnutls-utils-3.7.2-23.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gnutls-utils-3.7.2-23.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls" release="23.u15" version="3.7.2">
					<filename>gnutls-3.7.2-23.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gnutls-3.7.2-23.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-devel" release="23.u15" version="3.7.2">
					<filename>gnutls-devel-3.7.2-23.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gnutls-devel-3.7.2-23.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gnutls-utils" release="23.u15" version="3.7.2">
					<filename>gnutls-utils-3.7.2-23.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gnutls-utils-3.7.2-23.u15.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gnutls-help" release="23.u15" version="3.7.2">
					<filename>gnutls-help-3.7.2-23.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gnutls-help-3.7.2-23.u15.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3137</id>
		<title>An update for mchange-commons is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27727&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27727" id="CVE-2026-27727" title="CVE-2026-27727" type="cve"></reference>
		</references>
		<description>CVE-2026-27727:mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote `factoryClassLocation` values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted `jaxax.naming.Reference` or serialized object, they can provoke the download and execution of malicious code. Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to `false`, `com.sun.jndi.ldap.object.trustURLCodebase`. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened. Mirroring the JDK patch, mchange-commons-java&#39;s JNDI functionality is gated by configuration parameters that default to restrictive values starting in version 0.4.0. No known workarounds are available. Versions prior to 0.4.0 should be avoided on application CLASSPATHs.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="mchange-commons" release="12.u2" version="0.2.11">
					<filename>mchange-commons-0.2.11-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mchange-commons-0.2.11-12.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="mchange-commons-help" release="12.u2" version="0.2.11">
					<filename>mchange-commons-help-0.2.11-12.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mchange-commons-help-0.2.11-12.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3138</id>
		<title>An update for firebird is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-65104&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-65104" id="CVE-2025-65104" title="CVE-2025-65104" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27890&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27890" id="CVE-2026-27890" title="CVE-2026-27890" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28212&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28212" id="CVE-2026-28212" title="CVE-2026-28212" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33337&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33337" id="CVE-2026-33337" title="CVE-2026-33337" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28214&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28214" id="CVE-2026-28214" title="CVE-2026-28214" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28224&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28224" id="CVE-2026-28224" title="CVE-2026-28224" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34232&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34232" id="CVE-2026-34232" title="CVE-2026-34232" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35215&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35215" id="CVE-2026-35215" title="CVE-2026-35215" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40342&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40342" id="CVE-2026-40342" title="CVE-2026-40342" type="cve"></reference>
		</references>
		<description>CVE-2025-65104:Firebird is an open-source relational database management system. In versions FB3 of the client library placed incorrect data length values into XSQLDA fields when communicating with FB4 or higher servers, resulting in an information leak. This issue is fixed by upgrading to the FB4 client or higher.&#xA;CVE-2026-27890:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, when processing CNCT_specific_data segments during authentication, the server assumes segments arrive in strictly ascending order. If segments arrive out of order, the Array class&#39;s grow() method computes a negative size value, causing a SIGSEGV crash. An unauthenticated attacker who knows only the server&#39;s IP and port can exploit this to crash the server. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-28212:Firebird is an open-source relational database management system. In versions prior to 6.0.0, 5.0.4, 4.0.7 and 3.0.14, when processing an op_slice network packet, the server passes an unprepared structure containing a null pointer to the SDL_info() function, resulting in a null pointer dereference and server crash. An unauthenticated attacker can trigger this by sending a crafted packet to the server port. This issue has been fixed in versions 6.0.0, 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-33337:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, when deserializing a slice packet, the xdr_datum() function does not validate that a cstring length conforms to the slice descriptor bounds, allowing a cstring longer than the allocated buffer to overflow it. An unauthenticated attacker can exploit this by sending a crafted packet to the server, potentially causing a crash or other security impact. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-28214:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, the ClumpletReader::getClumpletSize() function can overflow the totalLength value when parsing a Wide type clumplet, causing an infinite loop. An authenticated user with INSERT privileges on any table can exploit this via a crafted Batch Parameter Block to cause a denial of service against the server. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-28224:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, when the server receives an op_crypt_key_callback packet without prior authentication, the port_server_crypt_callback handler is not initialized, resulting in a null pointer dereference and server crash. An unauthenticated attacker who knows only the server&#39;s IP and port can exploit this to crash the server. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-34232:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, the xdr_status_vector() function does not handle the isc_arg_cstring type when decoding an op_response packet, causing a server crash when one is encountered in the status vector. An unauthenticated attacker can exploit this by sending a crafted op_response packet to the server. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-35215:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, the sdl_desc() function does not validate the length of a decoded SDL descriptor from a slice packet. A zero-length descriptor is later used to calculate the number of slice items, causing a division by zero. An unauthenticated attacker can exploit this by sending a crafted slice packet to crash the server. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;CVE-2026-40342:Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, the external engine plugin loader concatenates a user-supplied engine name into a filesystem path without filtering path separators or .. components. An authenticated user with CREATE FUNCTION privileges can use a crafted ENGINE name to load an arbitrary shared library from anywhere on the filesystem via path traversal. The library&#39;s initialization code executes immediately during loading, before Firebird validates the module, achieving code execution as the server&#39;s OS account. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="firebird-devel" release="1.u1" version="3.0.14.33856">
					<filename>firebird-devel-3.0.14.33856-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/firebird-devel-3.0.14.33856-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="firebird" release="1.u1" version="3.0.14.33856">
					<filename>firebird-3.0.14.33856-1.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/firebird-3.0.14.33856-1.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="firebird" release="1.u1" version="3.0.14.33856">
					<filename>firebird-3.0.14.33856-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/firebird-3.0.14.33856-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="firebird-devel" release="1.u1" version="3.0.14.33856">
					<filename>firebird-devel-3.0.14.33856-1.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/firebird-devel-3.0.14.33856-1.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="firebird-help" release="1.u1" version="3.0.14.33856">
					<filename>firebird-help-3.0.14.33856-1.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/firebird-help-3.0.14.33856-1.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3139</id>
		<title>An update for postgresql-jdbc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42198&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42198" id="CVE-2026-42198" title="CVE-2026-42198" type="cve"></reference>
		</references>
		<description>CVE-2026-42198:pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue has been patched in version 42.7.11.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="postgresql-jdbc" release="4.u3" version="42.4.1">
					<filename>postgresql-jdbc-42.4.1-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-jdbc-42.4.1-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-jdbc-help" release="4.u3" version="42.4.1">
					<filename>postgresql-jdbc-help-42.4.1-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-jdbc-help-42.4.1-4.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-jdbc-javadoc" release="4.u3" version="42.4.1">
					<filename>postgresql-jdbc-javadoc-42.4.1-4.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-jdbc-javadoc-42.4.1-4.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3140</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-44431&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-44431" id="CVE-2026-44431" title="CVE-2026-44431" type="cve"></reference>
		</references>
		<description>CVE-2026-44431:urllib3 is an HTTP client library for Python. From 1.23 to before 2.7.0, cross-origin redirects followed from the low-level API via ProxyManager.connection_from_url().urlopen(..., assert_same_host=False) still forward these sensitive headers. This vulnerability is fixed in 2.7.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python3-urllib3" release="13.u11" version="1.26.12">
					<filename>python3-urllib3-1.26.12-13.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-urllib3-1.26.12-13.u11.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3141</id>
		<title>An update for jq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32316&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32316" id="CVE-2026-32316" title="CVE-2026-32316" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33947&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33947" id="CVE-2026-33947" title="CVE-2026-33947" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33948&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33948" id="CVE-2026-33948" title="CVE-2026-33948" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-39956&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-39956" id="CVE-2026-39956" title="CVE-2026-39956" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-39979&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-39979" id="CVE-2026-39979" title="CVE-2026-39979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40164&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40164" id="CVE-2026-40164" title="CVE-2026-40164" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40612&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40612" id="CVE-2026-40612" title="CVE-2026-40612" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41256&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41256" id="CVE-2026-41256" title="CVE-2026-41256" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41257&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41257" id="CVE-2026-41257" title="CVE-2026-41257" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43894&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43894" id="CVE-2026-43894" title="CVE-2026-43894" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43895&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43895" id="CVE-2026-43895" title="CVE-2026-43895" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43896&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43896" id="CVE-2026-43896" title="CVE-2026-43896" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-44777&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-44777" id="CVE-2026-44777" title="CVE-2026-44777" type="cve"></reference>
		</references>
		<description>CVE-2026-32316:jq is a command-line JSON processor. An integer overflow vulnerability exists through version 1.8.1 within the jvp_string_append() and jvp_string_copy_replace_bad functions, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow). Any system evaluating untrusted jq queries is affected, as an attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings. The root cause is the absence of string size bounds checking, unlike arrays and objects which already have size limits. The issue has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5.&#xA;CVE-2026-33947:jq is a command-line JSON processor. In versions 1.8.1 and below, functions jv_setpath(), jv_getpath(), and delpaths_sorted() in jq&#39;s src/jv_aux.c use unbounded recursion whose depth is controlled by the length of a caller-supplied path array, with no depth limit enforced. An attacker can supply a JSON document containing a flat array of ~65,000 integers (~200 KB) that, when used as a path argument by a trusted jq filter, exhausts the C call stack and crashes the process with a segmentation fault (SIGSEGV). This bypass works because the existing MAX_PARSING_DEPTH (10,000) limit only protects the JSON parser, not runtime path operations where arrays can be programmatically constructed to arbitrary lengths. The impact is denial of service (unrecoverable crash) affecting any application or service that processes untrusted JSON input through jq&#39;s setpath, getpath, or delpaths builtins. This issue has been addressed in commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f.&#xA;CVE-2026-33948:jq is a command-line JSON processor. Commits before 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b contain a vulnerability where CLI input parsing allows validation bypass via embedded NUL bytes. When reading JSON from files or stdin, jq uses strlen() to determine buffer length instead of the actual byte count from fgets(), causing it to truncate input at the first NUL byte and parse only the preceding prefix. This enables an attacker to craft input with a benign JSON prefix before a NUL byte followed by malicious trailing data, where jq validates only the prefix as valid JSON while silently discarding the suffix. Workflows relying on jq to validate untrusted JSON before forwarding it to downstream consumers are susceptible to parser differential attacks, as those consumers may process the full input including the malicious trailing bytes. This issue has been patched by commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.&#xA;CVE-2026-39956:jq is a command-line JSON processor. In commits after 69785bf77f86e2ea1b4a20ca86775916889e91c9, the _strindices builtin in jq&#39;s src/builtin.c passes its arguments directly to jv_string_indexes() without verifying they are strings, and jv_string_indexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like _strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive. Any deployment that evaluates untrusted jq filters against a release build is vulnerable. This issue has been patched in commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03.&#xA;CVE-2026-39979:jq is a command-line JSON processor. In commits before 2f09060afab23fe9390cce7cb860b10416e1bf5f, the jv_parse_sized() API in libjq accepts a counted buffer with an explicit length parameter, but its error-handling path formats the input buffer using %s in jv_string_fmt(), which reads until a NUL terminator is found rather than respecting the caller-supplied length. This means that when malformed JSON is passed in a non-NUL-terminated buffer, the error construction logic performs an out-of-bounds read past the end of the buffer. The vulnerability is reachable by any libjq consumer calling jv_parse_sized() with untrusted input, and depending on memory layout, can result in memory disclosure or process termination. The issue has been patched in commit 2f09060afab23fe9390cce7cb860b10416e1bf5f.&#xA;CVE-2026-40164:jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n²) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.&#xA;CVE-2026-40612:jq is a command-line JSON processor. In 1.8.1 and earlier, jv_contains recurses into nested arrays/objects with no depth limit. With a sufficiently nested input structure (built programmatically with reduce, since the JSON parser caps at depth 10000), the C stack is exhausted.&#xA;CVE-2026-41256:jq is a command-line JSON processor. In 1.8.1 and earlier, Top-level jq programs loaded from a file with -f are truncated at the first embedded NUL byte on current upstream HEAD. A crafted filter file such as . followed by \x00 and arbitrary suffix compiles and executes as only the prefix before the NUL. This leaves jq with a post-CVE-2026-33948 prefix/full-buffer mismatch on the compilation path even though the JSON parser path has already been fixed.&#xA;CVE-2026-41257:jq is a command-line JSON processor. In 1.8.1 and earlier, the jq bytecode VM&#39;s data stack tracks its allocation size in a signed int. When the stack grows beyond ≈1 GiB (via deeply nested generator forks), the doubling arithmetic overflows. The wrapped value is passed to realloc and then used for a memmove with attacker-influenced offsets.&#xA;CVE-2026-43894:jq is a command-line JSON processor. In 1.8.1 and earlier, when decNumberFromString is given a number literal of INT_MAX-1 (2147483646) digits, the D2U() macro overflows during signed-int arithmetic. The wrapped negative value bypasses the heap-allocation size check, causes the function to use a 30-byte stack buffer, and then writes ≈715 million 16-bit units (≈1.4 GiB) at an offset 1.43 GiB below the stack frame. The written content is fully attacker-controlled (the parsed decimal digits, packed 3-per-unit).&#xA;CVE-2026-43895:jq is a command-line JSON processor. In 1.8.1 and earlier, jq accepts embedded NUL bytes in import paths at the jq-language level, but later resolves those paths through C string operations during module and data-file lookup. This creates a mismatch between the logical import string that policy or audit code may validate and the on-disk path that jq actually opens.&#xA;CVE-2026-43896:jq is a command-line JSON processor. In 1.8.1 and earlier, unbounded recursion in jv_object_merge_recursive() allows a crafted jq program to crash the process with a segfault. The function is reachable through the * operator when both operands are objects.&#xA;CVE-2026-44777:jq is a command-line JSON processor. In 1.8.2rc1 and earlier, the ordinary module loader recurses without cycle detection when two&#xA;otherwise valid modules include each other.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="jq" release="4.u4" version="1.8.0">
					<filename>jq-1.8.0-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/jq-1.8.0-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="jq-devel" release="4.u4" version="1.8.0">
					<filename>jq-devel-1.8.0-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/jq-devel-1.8.0-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="jq-help" release="4.u4" version="1.8.0">
					<filename>jq-help-1.8.0-4.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/jq-help-1.8.0-4.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jq-devel" release="4.u4" version="1.8.0">
					<filename>jq-devel-1.8.0-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/jq-devel-1.8.0-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="jq" release="4.u4" version="1.8.0">
					<filename>jq-1.8.0-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/jq-1.8.0-4.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3142</id>
		<title>An update for libX11 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26597&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-26597" id="CVE-2025-26597" title="CVE-2025-26597" type="cve"></reference>
		</references>
		<description>CVE-2025-26597:A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libX11" release="10.u4" version="1.7.2">
					<filename>libX11-1.7.2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libX11-1.7.2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libX11-devel" release="10.u4" version="1.7.2">
					<filename>libX11-devel-1.7.2-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libX11-devel-1.7.2-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libX11-help" release="10.u4" version="1.7.2">
					<filename>libX11-help-1.7.2-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libX11-help-1.7.2-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libX11" release="10.u4" version="1.7.2">
					<filename>libX11-1.7.2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libX11-1.7.2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libX11-devel" release="10.u4" version="1.7.2">
					<filename>libX11-devel-1.7.2-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libX11-devel-1.7.2-10.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3143</id>
		<title>An update for bzip2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42250&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42250" id="CVE-2026-42250" title="CVE-2026-42250" type="cve"></reference>
		</references>
		<description>CVE-2026-42250:bzip2 contains an off‑by‑one error in the bzip2recover utility. When processing a specially crafted file, the application performs an out‑of‑bounds write to a global buffer, resulting in memory corruption and a crash (denial of service).&#xA;&#xA;This issue was fixed in bzip2 patch 35d122a3df8b0cc4082a4d89fdc6ee99f375fe67&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="bzip2" release="7.u1" version="1.0.8">
					<filename>bzip2-1.0.8-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bzip2-1.0.8-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bzip2-devel" release="7.u1" version="1.0.8">
					<filename>bzip2-devel-1.0.8-7.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bzip2-devel-1.0.8-7.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bzip2" release="7.u1" version="1.0.8">
					<filename>bzip2-1.0.8-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bzip2-1.0.8-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bzip2-devel" release="7.u1" version="1.0.8">
					<filename>bzip2-devel-1.0.8-7.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bzip2-devel-1.0.8-7.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="bzip2-help" release="7.u1" version="1.0.8">
					<filename>bzip2-help-1.0.8-7.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bzip2-help-1.0.8-7.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3144</id>
		<title>An update for hplip is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-8631&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-8631" id="CVE-2026-8631" title="CVE-2026-8631" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-8632&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-8632" id="CVE-2026-8632" title="CVE-2026-8632" type="cve"></reference>
		</references>
		<description>CVE-2026-8631:A potential security vulnerability has been identified in the HP Linux Imaging and Printing Software. This potential vulnerability may allow escalation of privileges and/or arbitrary code execution via an integer overflow in the hpcups processing path when handling crafted print data.&#xA;CVE-2026-8632:A potential security vulnerability has been identified in the HP Linux Imaging and Printing Software. This potential vulnerability may allow escalation of privileges and/or arbitrary code execution via operating system command injection.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="hplip" release="1.u2" version="3.26.4">
					<filename>hplip-3.26.4-1.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/hplip-3.26.4-1.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hplip" release="1.u2" version="3.26.4">
					<filename>hplip-3.26.4-1.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hplip-3.26.4-1.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3145</id>
		<title>An update for libgphoto2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40334&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40334" id="CVE-2026-40334" title="CVE-2026-40334" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40338&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40338" id="CVE-2026-40338" title="CVE-2026-40338" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40339&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40339" id="CVE-2026-40339" title="CVE-2026-40339" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40340&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40340" id="CVE-2026-40340" title="CVE-2026-40340" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40341&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40341" id="CVE-2026-40341" title="CVE-2026-40341" type="cve"></reference>
		</references>
		<description>CVE-2026-40334:libgphoto2 is a camera access and control library. In versions up to and including 2.5.33, a missing null terminator exists in ptp_unpack_Canon_FE() in camlibs/ptp2/ptp-pack.c (line 1377). The function copies a filename into a 13-byte buffer using strncpy without explicitly null-terminating the result. If the source data is exactly 13 bytes with no null terminator, the buffer is left unterminated, leading to out-of-bounds reads in any subsequent string operation. Commit 259fc7d3bfe534ce4b114c464f55b448670ab873 patches the issue.&#xA;CVE-2026-40338:libgphoto2 is a camera access and control library. Versions up to and including 2.5.33 have an out-of-bounds read in the PTP_DPFF_Enumeration case of `ptp_unpack_Sony_DPD()` in `camlibs/ptp2/ptp-pack.c` (line 856). The function reads a 2-byte enumeration count N via `dtoh16o(data, *poffset)` without verifying that 2 bytes remain in the buffer. The standard `ptp_unpack_DPD()` at line 704 has this exact check, confirming the Sony variant omitted it by oversight. Commit 3b9f9696be76ae51dca983d9dd8ce586a2561845 fixes the issue.&#xA;CVE-2026-40339:libgphoto2 is a camera access and control library. Versions up to and including 2.5.33 have an out-of-bounds read in `ptp_unpack_Sony_DPD()` in `camlibs/ptp2/ptp-pack.c` (line 842). The function reads the FormFlag byte via `dtoh8o(data, *poffset)` without a prior bounds check. The standard `ptp_unpack_DPD()` at lines 686–687 correctly validates `*offset + sizeof(uint8_t) &gt; dpdlen` before this same read, but the Sony variant omits this check entirely. Commit 09f8a940b1e418b5693f5c11e3016a1ad2cea62d fixes the issue.&#xA;CVE-2026-40340:libgphoto2 is a camera access and control library. Versions up to and including 2.5.33 have an out-of-bounds read vulnerability in `ptp_unpack_OI()` in `camlibs/ptp2/ptp-pack.c` (lines 530–563). The function validates `len &lt; PTP_oi_SequenceNumber` (i.e., len &lt; 48) but subsequently accesses offsets 48–56, up to 9 bytes beyond the validated boundary, via the Samsung Galaxy 64-bit objectsize detection heuristic. Commit 7c7f515bc88c3d0c4098ac965d313518e0ccbe33 fixes the issue.&#xA;CVE-2026-40341:libgphoto2 is a camera access and control library. In versions up to and including 2.5.33, an out of bound read in ptp_unpack_EOS_FocusInfoEx could be used to crash libgphoto2 when processing input from untrusted USB devices. Commit c385b34af260595dfbb5f9329526be5158985987 contains a patch. No known workarounds are available.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libgphoto2" release="5.u1" version="2.5.18">
					<filename>libgphoto2-2.5.18-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libgphoto2-2.5.18-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgphoto2-devel" release="5.u1" version="2.5.18">
					<filename>libgphoto2-devel-2.5.18-5.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libgphoto2-devel-2.5.18-5.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libgphoto2-help" release="5.u1" version="2.5.18">
					<filename>libgphoto2-help-2.5.18-5.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgphoto2-help-2.5.18-5.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgphoto2-devel" release="5.u1" version="2.5.18">
					<filename>libgphoto2-devel-2.5.18-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgphoto2-devel-2.5.18-5.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgphoto2" release="5.u1" version="2.5.18">
					<filename>libgphoto2-2.5.18-5.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgphoto2-2.5.18-5.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3146</id>
		<title>An update for libexif is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40385&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40385" id="CVE-2026-40385" title="CVE-2026-40385" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40386&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40386" id="CVE-2026-40386" title="CVE-2026-40386" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32775&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32775" id="CVE-2026-32775" title="CVE-2026-32775" type="cve"></reference>
		</references>
		<description>CVE-2026-40385:In libexif through 0.6.25, an unsigned 32bit integer overflow in Nikon MakerNote handling could be used by local attackers to cause crashes or information leaks. This only affects 32bit systems.&#xA;CVE-2026-40386:In libexif through 0.6.25, an integer underflow in size checking for Fuji and Olympus MakerNote decoding could be used by attackers to crash or leak information out of libexif-using programs.&#xA;CVE-2026-32775:libexif through 0.6.25 has a flaw in decoding MakerNotes. If the exif_mnote_data_get_value function gets passed in a 0 size, the passed in-buffer would be overwritten due to an integer underflow.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libexif" release="7.u5" version="0.6.22">
					<filename>libexif-0.6.22-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libexif-0.6.22-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libexif-devel" release="7.u5" version="0.6.22">
					<filename>libexif-devel-0.6.22-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libexif-devel-0.6.22-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libexif" release="7.u5" version="0.6.22">
					<filename>libexif-0.6.22-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libexif-0.6.22-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libexif-devel" release="7.u5" version="0.6.22">
					<filename>libexif-devel-0.6.22-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libexif-devel-0.6.22-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libexif-help" release="7.u5" version="0.6.22">
					<filename>libexif-help-0.6.22-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libexif-help-0.6.22-7.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3147</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28780&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28780" id="CVE-2026-28780" title="CVE-2026-28780" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24072&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24072" id="CVE-2026-24072" title="CVE-2026-24072" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29168" id="CVE-2026-29168" title="CVE-2026-29168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29169&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29169" id="CVE-2026-29169" title="CVE-2026-29169" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33006" id="CVE-2026-33006" title="CVE-2026-33006" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33007&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33007" id="CVE-2026-33007" title="CVE-2026-33007" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33523&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33523" id="CVE-2026-33523" title="CVE-2026-33523" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33857" id="CVE-2026-33857" title="CVE-2026-33857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34032&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34032" id="CVE-2026-34032" title="CVE-2026-34032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34059&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34059" id="CVE-2026-34059" title="CVE-2026-34059" type="cve"></reference>
		</references>
		<description>CVE-2026-28780:Heap-based Buffer Overflow vulnerability in mod_proxy_ajp of Apache HTTP Server.&#xA;If mod_proxy_ajp connects to a malicious AJP server this AJP server can send a malicious AJP message back to mod_proxy_ajp and cause it to write 4 attacker controlled bytes after the end of a heap based buffer.&#xA;&#xA;This issue affects Apache HTTP Server: through 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes the issue.&#xA;CVE-2026-24072:An escalation of privilege bug in various modules in Apache HTTP 2.4.66 and earlier allows local .htaccess authors to read files with the privileges of the httpd user.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes this issue.&#xA;CVE-2026-29168:Allocation of Resources Without Limits or Throttling vulnerability in Apache HTTP Server&#39;s  mod_md via OCSP response data.&#xA;&#xA;This issue affects Apache HTTP Server: from 2.4.30 through 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes the issue.&#xA;CVE-2026-29169:A NULL pointer dereference in mod_dav_lock in Apache HTTP Server 2.4.66 and earlier may allow an attacker to crash the server with a malicious request.mod_dav_lock is not used internally by mod_dav or mod_dav_fs.&#xA;&#xA;The only known use-case for mod_dav_lock was mod_dav_svn from Apache Subversion earlier than version 1.2.0.&#xA;&#xA;Users are recommended to upgrade to version 2.4.66, which fixes this issue, or remove mod_dav_lock.&#xA;CVE-2026-33006:A timing attack against mod_auth_digest in Apache HTTP Server 2.4.66 allows a bypass of Digest authentication by a remote attacker.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes this issue.&#xA;CVE-2026-33007:A NULL pointer dereference in the mod_authn_socache in Apache HTTP Server 2.4.66 and earlier allows an unauthenticated remote user to crash a child process in a caching forward proxy configuration.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes this issue.&#xA;CVE-2026-33523:HTTP response splitting vulnerability in multiple Apache HTTP Server modules with untrusted or compromised backend servers.&#xA;&#xA;This issue affects Apache HTTP Server: from through 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes the issue.&#xA;CVE-2026-33857:Out-of-bounds Read vulnerability in mod_proxy_ajp of &#xA;&#xA;Apache HTTP Server.&#xA;&#xA;This issue affects Apache HTTP Server: through 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes the issue.&#xA;CVE-2026-34032:Improper Null Termination, Out-of-bounds Read vulnerability in Apache HTTP Server.&#xA;&#xA;This issue affects Apache HTTP Server: through 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes the issue.&#xA;CVE-2026-34059:Buffer Over-read vulnerability in Apache HTTP Server.&#xA;&#xA;This issue affects Apache HTTP Server: through 2.4.66.&#xA;&#xA;Users are recommended to upgrade to version 2.4.67, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="mod_ldap" release="30.u19" version="2.4.51">
					<filename>mod_ldap-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mod_ldap-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_proxy_html" release="30.u19" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mod_proxy_html-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd" release="30.u19" version="2.4.51">
					<filename>httpd-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/httpd-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_md" release="30.u19" version="2.4.51">
					<filename>mod_md-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mod_md-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mod_session" release="30.u19" version="2.4.51">
					<filename>mod_session-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mod_session-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-devel" release="30.u19" version="2.4.51">
					<filename>httpd-devel-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/httpd-devel-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="httpd-tools" release="30.u19" version="2.4.51">
					<filename>httpd-tools-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/httpd-tools-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="mod_ssl" release="30.u19" version="2.4.51">
					<filename>mod_ssl-2.4.51-30.u19.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mod_ssl-2.4.51-30.u19.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_session" release="30.u19" version="2.4.51">
					<filename>mod_session-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mod_session-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_proxy_html" release="30.u19" version="2.4.51">
					<filename>mod_proxy_html-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mod_proxy_html-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-tools" release="30.u19" version="2.4.51">
					<filename>httpd-tools-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/httpd-tools-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd-devel" release="30.u19" version="2.4.51">
					<filename>httpd-devel-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/httpd-devel-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_ldap" release="30.u19" version="2.4.51">
					<filename>mod_ldap-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mod_ldap-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mod_md" release="30.u19" version="2.4.51">
					<filename>mod_md-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mod_md-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="httpd" release="30.u19" version="2.4.51">
					<filename>httpd-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/httpd-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="mod_ssl" release="30.u19" version="2.4.51">
					<filename>mod_ssl-2.4.51-30.u19.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mod_ssl-2.4.51-30.u19.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-help" release="30.u19" version="2.4.51">
					<filename>httpd-help-2.4.51-30.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/httpd-help-2.4.51-30.u19.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="httpd-filesystem" release="30.u19" version="2.4.51">
					<filename>httpd-filesystem-2.4.51-30.u19.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/httpd-filesystem-2.4.51-30.u19.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3148</id>
		<title>An update for util-linux is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3184&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3184" id="CVE-2026-3184" title="CVE-2026-3184" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27456&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27456" id="CVE-2026-27456" title="CVE-2026-27456" type="cve"></reference>
		</references>
		<description>CVE-2026-3184:A flaw was found in util-linux. Improper hostname canonicalization in the `login(1)` utility, when invoked with the `-h` option, can modify the supplied remote hostname before setting `PAM_RHOST`. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.&#xA;CVE-2026-27456:util-linux is a random collection of Linux utilities. Prior to version 2.41.4, a TOCTOU (Time-of-Check-Time-of-Use) vulnerability has been identified in the SUID binary /usr/bin/mount from util-linux. The mount binary, when setting up loop devices, validates the source file path with user privileges via fork() + setuid() + realpath(), but subsequently re-canonicalizes and opens it with root privileges (euid=0) without verifying that the path has not been replaced between both operations. Neither O_NOFOLLOW, nor inode comparison, nor post-open fstat() are employed. This allows a local unprivileged user to replace the source file with a symlink pointing to any root-owned file or device during the race window, causing the SUID binary to open and mount it as root. Exploitation requires an /etc/fstab entry with user,loop options whose path points to a directory where the attacker has write permission, and that /usr/bin/mount has the SUID bit set (the default configuration on virtually all Linux distributions). The impact is unauthorized read access to root-protected files and block devices, including backup images, disk volumes, and any file containing a valid filesystem. This issue has been patched in version 2.41.4.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="util-linux-help" release="52.u36" version="2.37.2">
					<filename>util-linux-help-2.37.2-52.u36.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/util-linux-help-2.37.2-52.u36.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libuuid" release="52.u36" version="2.37.2">
					<filename>libuuid-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libuuid-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux-user" release="52.u36" version="2.37.2">
					<filename>util-linux-user-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/util-linux-user-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libfdisk" release="52.u36" version="2.37.2">
					<filename>libfdisk-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libfdisk-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libblkid" release="52.u36" version="2.37.2">
					<filename>libblkid-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libblkid-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libmount" release="52.u36" version="2.37.2">
					<filename>libmount-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libmount-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libsmartcols" release="52.u36" version="2.37.2">
					<filename>libsmartcols-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libsmartcols-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux-devel" release="52.u36" version="2.37.2">
					<filename>util-linux-devel-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/util-linux-devel-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="util-linux" release="52.u36" version="2.37.2">
					<filename>util-linux-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/util-linux-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libmount" release="52.u36" version="2.37.2">
					<filename>python3-libmount-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-libmount-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uuidd" release="52.u36" version="2.37.2">
					<filename>uuidd-2.37.2-52.u36.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/uuidd-2.37.2-52.u36.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libfdisk" release="52.u36" version="2.37.2">
					<filename>libfdisk-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libfdisk-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libblkid" release="52.u36" version="2.37.2">
					<filename>libblkid-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libblkid-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libsmartcols" release="52.u36" version="2.37.2">
					<filename>libsmartcols-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libsmartcols-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libuuid" release="52.u36" version="2.37.2">
					<filename>libuuid-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libuuid-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux-user" release="52.u36" version="2.37.2">
					<filename>util-linux-user-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/util-linux-user-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libmount" release="52.u36" version="2.37.2">
					<filename>python3-libmount-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-libmount-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux" release="52.u36" version="2.37.2">
					<filename>util-linux-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/util-linux-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uuidd" release="52.u36" version="2.37.2">
					<filename>uuidd-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uuidd-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libmount" release="52.u36" version="2.37.2">
					<filename>libmount-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libmount-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="util-linux-devel" release="52.u36" version="2.37.2">
					<filename>util-linux-devel-2.37.2-52.u36.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/util-linux-devel-2.37.2-52.u36.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3149</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-1519&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-1519" id="CVE-2026-1519" title="CVE-2026-1519" type="cve"></reference>
		</references>
		<description>CVE-2026-1519:If a BIND resolver is performing DNSSEC validation and encounters a maliciously crafted zone, the resolver may consume excessive CPU. Authoritative-only servers are generally unaffected, although there are circumstances where authoritative servers may make recursive queries (see: https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries).&#xA;This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.46, 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.46-S1, and 9.20.9-S1 through 9.20.20-S1.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="32" name="bind-license" release="29.u14" version="9.16.23">
					<filename>bind-license-9.16.23-29.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-license-9.16.23-29.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="bind-dnssec-doc" release="29.u14" version="9.16.23">
					<filename>bind-dnssec-doc-9.16.23-29.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-dnssec-doc-9.16.23-29.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="32" name="python3-bind" release="29.u14" version="9.16.23">
					<filename>python3-bind-9.16.23-29.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-bind-9.16.23-29.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-devel" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-pkcs11-devel-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-libs" release="29.u14" version="9.16.23">
					<filename>bind-libs-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-libs-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-utils" release="29.u14" version="9.16.23">
					<filename>bind-utils-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-utils-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-libs" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-pkcs11-libs-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind" release="29.u14" version="9.16.23">
					<filename>bind-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-chroot" release="29.u14" version="9.16.23">
					<filename>bind-chroot-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-chroot-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-devel" release="29.u14" version="9.16.23">
					<filename>bind-devel-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-devel-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-dnssec-utils" release="29.u14" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-dnssec-utils-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11-utils" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-pkcs11-utils-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="32" name="bind-pkcs11" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-29.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bind-pkcs11-9.16.23-29.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-chroot" release="29.u14" version="9.16.23">
					<filename>bind-chroot-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-chroot-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-devel" release="29.u14" version="9.16.23">
					<filename>bind-devel-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-devel-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind" release="29.u14" version="9.16.23">
					<filename>bind-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-devel" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-devel-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-pkcs11-devel-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-utils" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-utils-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-pkcs11-utils-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-pkcs11-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-libs" release="29.u14" version="9.16.23">
					<filename>bind-libs-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-libs-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-dnssec-utils" release="29.u14" version="9.16.23">
					<filename>bind-dnssec-utils-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-dnssec-utils-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-pkcs11-libs" release="29.u14" version="9.16.23">
					<filename>bind-pkcs11-libs-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-pkcs11-libs-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="32" name="bind-utils" release="29.u14" version="9.16.23">
					<filename>bind-utils-9.16.23-29.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bind-utils-9.16.23-29.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3150</id>
		<title>An update for libXpm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4367&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4367" id="CVE-2026-4367" title="CVE-2026-4367" type="cve"></reference>
		</references>
		<description>CVE-2026-4367:A vulnerability was found in X.org libXpm up to 3.5.4. It has been classified as problematic.CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 3.5.19 eliminates this vulnerability. Applying the patch 5448e1bd is able to eliminate this problem. The bugfix is ready for download at gitlab.freedesktop.org. The best possible mitigation is suggested to be upgrading to the latest version.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="libXpm" release="6.u3" version="3.5.13">
					<filename>libXpm-3.5.13-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libXpm-3.5.13-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libXpm-devel" release="6.u3" version="3.5.13">
					<filename>libXpm-devel-3.5.13-6.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libXpm-devel-3.5.13-6.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libXpm" release="6.u3" version="3.5.13">
					<filename>libXpm-3.5.13-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libXpm-3.5.13-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libXpm-devel" release="6.u3" version="3.5.13">
					<filename>libXpm-devel-3.5.13-6.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libXpm-devel-3.5.13-6.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libXpm-help" release="6.u3" version="3.5.13">
					<filename>libXpm-help-3.5.13-6.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libXpm-help-3.5.13-6.u3.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3151</id>
		<title>An update for xdg-dbus-proxy is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34080&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34080" id="CVE-2026-34080" title="CVE-2026-34080" type="cve"></reference>
		</references>
		<description>CVE-2026-34080:xdg-dbus-proxy is a filtering proxy for D-Bus connections. Prior to 0.1.7, a policy parser vulnerability allows bypassing eavesdrop restrictions. The proxy checks for eavesdrop=true in policy rules but fails to handle eavesdrop =&#39;true&#39; (with a space before the equals sign) and similar cases. Clients can intercept D-Bus messages they should not have access to. This vulnerability is fixed in 0.1.7.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="xdg-dbus-proxy-help" release="2.u1" version="0.1.2">
					<filename>xdg-dbus-proxy-help-0.1.2-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xdg-dbus-proxy-help-0.1.2-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xdg-dbus-proxy" release="2.u1" version="0.1.2">
					<filename>xdg-dbus-proxy-0.1.2-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xdg-dbus-proxy-0.1.2-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xdg-dbus-proxy" release="2.u1" version="0.1.2">
					<filename>xdg-dbus-proxy-0.1.2-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/xdg-dbus-proxy-0.1.2-2.u1.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3152</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27143&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27143" id="CVE-2026-27143" title="CVE-2026-27143" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27144&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27144" id="CVE-2026-27144" title="CVE-2026-27144" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32288&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32288" id="CVE-2026-32288" title="CVE-2026-32288" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27140&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27140" id="CVE-2026-27140" title="CVE-2026-27140" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61732&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61732" id="CVE-2025-61732" title="CVE-2025-61732" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68119&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68119" id="CVE-2025-68119" title="CVE-2025-68119" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61731&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61731" id="CVE-2025-61731" title="CVE-2025-61731" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61728&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61728" id="CVE-2025-61728" title="CVE-2025-61728" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68121&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68121" id="CVE-2025-68121" title="CVE-2025-68121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-61723&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-61723" id="CVE-2025-61723" title="CVE-2025-61723" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27139&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27139" id="CVE-2026-27139" title="CVE-2026-27139" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27142&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27142" id="CVE-2026-27142" title="CVE-2026-27142" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25679&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25679" id="CVE-2026-25679" title="CVE-2026-25679" type="cve"></reference>
		</references>
		<description>CVE-2026-27143:Arithmetic over induction variables in loops were not correctly checked for underflow or overflow. As a result, the compiler would allow for invalid indexing to occur at runtime, potentially leading to memory corruption.&#xA;CVE-2026-27144:The compiler is meant to unwrap pointers which are the operands of a memory move; a no-op interface conversion prevented the compiler from making the correct determination about non-overlapping moves, potentially leading to memory corruption at runtime.&#xA;CVE-2026-32288:tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the &#34;old GNU sparse map&#34; format.&#xA;CVE-2026-27140:SWIG file names containing &#39;cgo&#39; and well-crafted payloads could lead to code smuggling and arbitrary code execution at build time due to trust layer bypass.&#xA;CVE-2025-61732:A discrepancy between how Go and C/C++ comments were parsed allowed for code smuggling into the resulting cgo binary.&#xA;CVE-2025-68119:Downloading and building modules with malicious version strings can cause local code execution. On systems with Mercurial (hg) installed, downloading modules from non-standard sources (e.g., custom domains) can cause unexpected code execution due to how external VCS commands are constructed. This issue can also be triggered by providing a malicious version string to the toolchain. On systems with Git installed, downloading and building modules with malicious version strings can allow an attacker to write to arbitrary files on the filesystem. This can only be triggered by explicitly providing the malicious version strings to the toolchain and does not affect usage of @latest or bare module paths.&#xA;CVE-2025-61731:Building a malicious file with cmd/go can cause can cause a write to an attacker-controlled file with partial control of the file content. The &#34;#cgo pkg-config:&#34; directive in a Go source file provides command-line arguments to provide to the Go pkg-config command. An attacker can provide a &#34;--log-file&#34; argument to this directive, causing pkg-config to write to an attacker-controlled location.&#xA;CVE-2025-61728:archive/zip uses a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.&#xA;CVE-2025-68121:During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake.&#xA;CVE-2025-61723:The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs.&#xA;CVE-2026-27139:On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened. The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.&#xA;CVE-2026-27142:Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value &#34;refresh&#34;. A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow &#34;url=&#34; by setting htmlmetacontenturlescape=0.&#xA;CVE-2026-25679:url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="golang" release="48.u15" version="1.21.4">
					<filename>golang-1.21.4-48.u15.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/golang-1.21.4-48.u15.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-devel" release="48.u15" version="1.21.4">
					<filename>golang-devel-1.21.4-48.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/golang-devel-1.21.4-48.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="golang-help" release="48.u15" version="1.21.4">
					<filename>golang-help-1.21.4-48.u15.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/golang-help-1.21.4-48.u15.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="golang" release="48.u15" version="1.21.4">
					<filename>golang-1.21.4-48.u15.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/golang-1.21.4-48.u15.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3153</id>
		<title>An update for dnsmasq is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4890&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4890" id="CVE-2026-4890" title="CVE-2026-4890" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4891&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4891" id="CVE-2026-4891" title="CVE-2026-4891" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4892&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4892" id="CVE-2026-4892" title="CVE-2026-4892" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4893&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4893" id="CVE-2026-4893" title="CVE-2026-4893" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2291&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2291" id="CVE-2026-2291" title="CVE-2026-2291" type="cve"></reference>
		</references>
		<description>CVE-2026-4890:A Denial of Service (DoS) vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to cause a denial of service via a crafted DNS packet.&#xA;CVE-2026-4891:A heap-based out-of-bounds read vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to cause a denial of service via a crafted DNS packet.&#xA;CVE-2026-4892:A heap-based out-of-bounds write vulnerability in the DHCPv6 implementation of dnsmasq allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet.&#xA;CVE-2026-4893:An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet with RFC 7871 client subnet information.&#xA;CVE-2026-2291:dnsmasqs extract_name() function can be abused to cause a heap buffer overflow, allowing an attacker to inject false DNS cache entries, which could result in DNS lookups to redirect to an attacker-controlled IP address, or to cause a DoS.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="dnsmasq-help" release="15.u11" version="2.86">
					<filename>dnsmasq-help-2.86-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/dnsmasq-help-2.86-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="dnsmasq" release="15.u11" version="2.86">
					<filename>dnsmasq-2.86-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/dnsmasq-2.86-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dnsmasq" release="15.u11" version="2.86">
					<filename>dnsmasq-2.86-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/dnsmasq-2.86-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="dnsmasq-help" release="15.u11" version="2.86">
					<filename>dnsmasq-help-2.86-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/dnsmasq-help-2.86-15.u11.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3154</id>
		<title>An update for postfix is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43964&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43964" id="CVE-2026-43964" title="CVE-2026-43964" type="cve"></reference>
		</references>
		<description>CVE-2026-43964:Postfix before 3.8.16, 3.9 before 3.9.10, and 3.10 before 3.10.9 sometimes allows a buffer over-read and process crash via an enhanced status code that lacks text after the third number.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="2" name="postfix-sysvinit" release="22.u4" version="3.3.1">
					<filename>postfix-sysvinit-3.3.1-22.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postfix-sysvinit-3.3.1-22.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="postfix-help" release="22.u4" version="3.3.1">
					<filename>postfix-help-3.3.1-22.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postfix-help-3.3.1-22.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="postfix-perl-scripts" release="22.u4" version="3.3.1">
					<filename>postfix-perl-scripts-3.3.1-22.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postfix-perl-scripts-3.3.1-22.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="postfix" release="22.u4" version="3.3.1">
					<filename>postfix-3.3.1-22.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postfix-3.3.1-22.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="postfix-pgsql" release="22.u4" version="3.3.1">
					<filename>postfix-pgsql-3.3.1-22.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postfix-pgsql-3.3.1-22.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="postfix-perl-scripts" release="22.u4" version="3.3.1">
					<filename>postfix-perl-scripts-3.3.1-22.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postfix-perl-scripts-3.3.1-22.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="postfix" release="22.u4" version="3.3.1">
					<filename>postfix-3.3.1-22.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postfix-3.3.1-22.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="postfix-pgsql" release="22.u4" version="3.3.1">
					<filename>postfix-pgsql-3.3.1-22.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postfix-pgsql-3.3.1-22.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3155</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5406&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5406" id="CVE-2026-5406" title="CVE-2026-5406" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6530&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6530" id="CVE-2026-6530" title="CVE-2026-6530" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6519&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6519" id="CVE-2026-6519" title="CVE-2026-6519" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6533&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6533" id="CVE-2026-6533" title="CVE-2026-6533" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6869&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6869" id="CVE-2026-6869" title="CVE-2026-6869" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6538&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6538" id="CVE-2026-6538" title="CVE-2026-6538" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6537&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6537" id="CVE-2026-6537" title="CVE-2026-6537" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6534&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6534" id="CVE-2026-6534" title="CVE-2026-6534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6535&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6535" id="CVE-2026-6535" title="CVE-2026-6535" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6867&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6867" id="CVE-2026-6867" title="CVE-2026-6867" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6532&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6532" id="CVE-2026-6532" title="CVE-2026-6532" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6531&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6531" id="CVE-2026-6531" title="CVE-2026-6531" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6870&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6870" id="CVE-2026-6870" title="CVE-2026-6870" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5409&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5409" id="CVE-2026-5409" title="CVE-2026-5409" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5653&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5653" id="CVE-2026-5653" title="CVE-2026-5653" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5654&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5654" id="CVE-2026-5654" title="CVE-2026-5654" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5657&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5657" id="CVE-2026-5657" title="CVE-2026-5657" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6520&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6520" id="CVE-2026-6520" title="CVE-2026-6520" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6521&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6521" id="CVE-2026-6521" title="CVE-2026-6521" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6522&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6522" id="CVE-2026-6522" title="CVE-2026-6522" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6523&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6523" id="CVE-2026-6523" title="CVE-2026-6523" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6524&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6524" id="CVE-2026-6524" title="CVE-2026-6524" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6527&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6527" id="CVE-2026-6527" title="CVE-2026-6527" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6529&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6529" id="CVE-2026-6529" title="CVE-2026-6529" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7379&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7379" id="CVE-2026-7379" title="CVE-2026-7379" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6868&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6868" id="CVE-2026-6868" title="CVE-2026-6868" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7375&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7375" id="CVE-2026-7375" title="CVE-2026-7375" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7378&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7378" id="CVE-2026-7378" title="CVE-2026-7378" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7376&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7376" id="CVE-2026-7376" title="CVE-2026-7376" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5408&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5408" id="CVE-2026-5408" title="CVE-2026-5408" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5299&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5299" id="CVE-2026-5299" title="CVE-2026-5299" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5401&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5401" id="CVE-2026-5401" title="CVE-2026-5401" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5407&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5407" id="CVE-2026-5407" title="CVE-2026-5407" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5404&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5404" id="CVE-2026-5404" title="CVE-2026-5404" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5403&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5403" id="CVE-2026-5403" title="CVE-2026-5403" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5656&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5656" id="CVE-2026-5656" title="CVE-2026-5656" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5405&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5405" id="CVE-2026-5405" title="CVE-2026-5405" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-9759&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-9759" id="CVE-2026-9759" title="CVE-2026-9759" type="cve"></reference>
		</references>
		<description>CVE-2026-5406:FC-SWILS protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6530:DCP-ETSI protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6519:MBIM protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6533:Dissection engine LZ77 decompression crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6869:WebSocket protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6538:BEEP protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6537:ZigBee protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6534:USB HID protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6535:Dissection engine zlib decompression crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6867:SMB2 protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6532:Kismet protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6531:SANE protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6870:GSM RP protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5409:Monero protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5653:DCP-ETSI protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5654:AMR-NB codec crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5657:iLBC codec crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6520:OpenFlow v6 protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6521:OpenFlow v5 protocol dissector infinite loops in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6522:RPKI-Router protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6523:GNW protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6524:MySQL protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6527:ASN.1 PER protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6529:iLBC audio codec crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-7379:Memory leak in sharkd 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-6868:HTTP protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-7375:UDS protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-7378:Crash in sharkd 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-7376:Crash in sharkd 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5408:BT-DHT protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5299:ICMPv6 PvD protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5401:AFP Spotlight protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5407:SMB2 protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5404:K12 RF5 file parser crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service&#xA;CVE-2026-5403:SBC codec crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service and possible code execution&#xA;CVE-2026-5656:Profile import path traversal in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service and possible code execution&#xA;CVE-2026-5405:RDP protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service and possible code execution&#xA;CVE-2026-9759:ROHC protocol dissector crash in Wireshark 4.6.0 to 4.6.5 and 4.4.0 to 4.4.15 allows denial of service&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="1.u14" version="4.4.16">
					<filename>wireshark-devel-4.4.16-1.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/wireshark-devel-4.4.16-1.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="1.u14" version="4.4.16">
					<filename>wireshark-4.4.16-1.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/wireshark-4.4.16-1.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="1.u14" version="4.4.16">
					<filename>wireshark-devel-4.4.16-1.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/wireshark-devel-4.4.16-1.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark" release="1.u14" version="4.4.16">
					<filename>wireshark-4.4.16-1.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/wireshark-4.4.16-1.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="wireshark-help" release="1.u14" version="4.4.16">
					<filename>wireshark-help-4.4.16-1.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/wireshark-help-4.4.16-1.u14.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3156</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26955&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26955" id="CVE-2026-26955" title="CVE-2026-26955" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-26965&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-26965" id="CVE-2026-26965" title="CVE-2026-26965" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31806&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31806" id="CVE-2026-31806" title="CVE-2026-31806" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31883&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31883" id="CVE-2026-31883" title="CVE-2026-31883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31885&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31885" id="CVE-2026-31885" title="CVE-2026-31885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33984&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33984" id="CVE-2026-33984" title="CVE-2026-33984" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33983&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33983" id="CVE-2026-33983" title="CVE-2026-33983" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25942&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25942" id="CVE-2026-25942" title="CVE-2026-25942" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25952&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25952" id="CVE-2026-25952" title="CVE-2026-25952" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25953&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25953" id="CVE-2026-25953" title="CVE-2026-25953" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25954&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25954" id="CVE-2026-25954" title="CVE-2026-25954" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27951&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27951" id="CVE-2026-27951" title="CVE-2026-27951" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29774&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29774" id="CVE-2026-29774" title="CVE-2026-29774" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29775&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29775" id="CVE-2026-29775" title="CVE-2026-29775" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31884&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31884" id="CVE-2026-31884" title="CVE-2026-31884" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31897&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31897" id="CVE-2026-31897" title="CVE-2026-31897" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33985&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33985" id="CVE-2026-33985" title="CVE-2026-33985" type="cve"></reference>
		</references>
		<description>CVE-2026-26955:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, a malicious RDP server can trigger a heap buffer overflow in FreeRDP clients using the GDI surface pipeline (e.g., `xfreerdp`) by sending an RDPGFX ClearCodec surface command with an out-of-bounds destination rectangle. The `gdi_SurfaceCommand_ClearCodec()` handler does not call `is_within_surface()` to validate the command rectangle against the destination surface dimensions, allowing attacker-controlled `cmd-&gt;left`/`cmd-&gt;top` (and subcodec rectangle offsets) to reach image copy routines that write into `surface-&gt;data` without bounds enforcement. The OOB write corrupts an adjacent `gdiGfxSurface` struct&#39;s `codecs*` pointer with attacker-controlled pixel data, and corruption of `codecs*` is sufficient to reach an indirect function pointer call (`NSC_CONTEXT.decode` at `nsc.c:500`) on a subsequent codec command — full instruction pointer (RIP) control demonstrated in exploitability harness. Users should upgrade to version 3.23.0 to receive a patch.&#xA;CVE-2026-26965:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, in the RLE planar decode path, `planar_decompress_plane_rle()` writes into `pDstData` at `((nYDst+y) * nDstStep) + (4*nXDst) + nChannel` without verifying that `(nYDst+nSrcHeight)` fits in the destination height or that `(nXDst+nSrcWidth)` fits in the destination stride. When `TempFormat != DstFormat`, `pDstData` becomes `planar-&gt;pTempData` (sized for the desktop), while `nYDst` is only validated against the **surface** by `is_within_surface()`. A malicious RDP server can exploit this to perform a heap out-of-bounds write with attacker-controlled offset and pixel data on any connecting FreeRDP client. The OOB write reaches up to 132,096 bytes past the temp buffer end, and  on the brk heap (desktop ≤ 128×128), an adjacent `NSC_CONTEXT` struct&#39;s `decode` function pointer is overwritten with attacker-controlled pixel data — control-flow–relevant corruption (function pointer overwritten) demonstrated under deterministic heap layout (`nsc-&gt;decode = 0xFF414141FF414141`). Version 3.23.0 fixes the vulnerability.&#xA;CVE-2026-31806:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0,  the gdi_surface_bits() function processes SURFACE_BITS_COMMAND messages sent by the RDP server. When the command is handled using NSCodec, the bmp.width and bmp.height values provided by the server are not properly validated against the actual desktop dimensions. A malicious RDP server can supply crafted bmp.width and bmp.height values that exceed the expected surface size. Because these values are used during bitmap decoding and memory operations without proper bounds checking, this can lead to a heap buffer overflow. Since the attacker can also control the associated pixel data transmitted by the server, the overflow may be exploitable to overwrite adjacent heap memory. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-31883:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a size_t underflow in the IMA-ADPCM and MS-ADPCM audio decoders leads to heap-buffer-overflow write via the RDPSND audio channel. In libfreerdp/codec/dsp.c, the IMA-ADPCM and MS-ADPCM decoders subtract block header sizes from a size_t variable without checking for underflow. When nBlockAlign (received from the server) is set such that size % block_size == 0 triggers the header parsing at a point where size is smaller than the header (4 or 8 bytes), the subtraction wraps size to ~SIZE_MAX. The while (size &gt; 0) loop then continues for an astronomical number of iterations. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-31885:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, there is an out-of-bounds read in MS-ADPCM and IMA-ADPCM decoders due to unchecked predictor and step_index values from input data. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-33984:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.24.2, in resize_vbar_entry() in libfreerdp/codec/clear.c, vBarEntry-&gt;size is updated to vBarEntry-&gt;count before the winpr_aligned_recalloc() call. If realloc fails, size is inflated while pixels still points to the old, smaller buffer. On a subsequent call where count &lt;= size (the inflated value), realloc is skipped. The caller then writes count * bpp bytes of attacker-controlled pixel data into the undersized buffer, causing a heap buffer overflow. This issue has been patched in version 3.24.2.&#xA;CVE-2026-33983:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.24.2, progressive_decompress_tile_upgrade() detects a mismatch via progressive_rfx_quant_cmp_equal() but only emits WLog_WARN, execution continues. The wrapped value (247) is used as a shift exponent, causing undefined behavior and an approximately 80 billion iteration loop (CPU DoS). This issue has been patched in version 3.24.2.&#xA;CVE-2026-25942:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, `xf_rail_server_execute_result` indexes the global `error_code_names[]` array (7 elements, indices 0–6) with an unchecked `execResult-&gt;execResult` value received from the server, allowing an out-of-bounds read when the server sends an `execResult` value of 7 or greater. Version 3.23.0 fixes the issue.&#xA;CVE-2026-25952:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, `xf_SetWindowMinMaxInfo` dereferences a freed `xfAppWindow` pointer because `xf_rail_get_window` in `xf_rail_server_min_max_info` returns an unprotected pointer from the `railWindows` hash table, and the main thread can concurrently delete the window (via a window delete order) while the RAIL channel thread is still using the pointer. Version 3.23.0 fixes the issue.&#xA;CVE-2026-25953:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, `xf_AppUpdateWindowFromSurface` reads from a freed `xfAppWindow` because the RDPGFX DVC thread obtains a bare pointer via `xf_rail_get_window` without any lifetime protection, while the main thread can concurrently delete the window through a fastpath window-delete order. Version 3.23.0 fixes the issue.&#xA;CVE-2026-25954:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, `xf_rail_server_local_move_size` dereferences a freed `xfAppWindow` pointer because `xf_rail_get_window` returns an unprotected pointer from the `railWindows` hash table, and the main thread can concurrently delete the window (via a window delete order) while the RAIL channel thread is still using the pointer. Version 3.23.0 fixes the issue.&#xA;CVE-2026-27951:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, the function `Stream_EnsureCapacity` can create an endless blocking loop. This may affect all client and server implementations using `FreeRDP`. For practical exploitation this will only work on 32bit systems where the available physical memory is `&gt;= SIZE_MAX`. Version 3.23.0 contains a patch. No known workarounds are available.&#xA;CVE-2026-29774:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a client-side heap buffer overflow occurs in the FreeRDP client&#39;s AVC420/AVC444 YUV-to-RGB conversion path due to missing horizontal bounds validation of H.264 metablock regionRects coordinates.  In yuv.c, the clamp() function (line 347) only validates top/bottom against the surface/YUV height, but never checks left/right against the surface width. When avc420_yuv_to_rgb (line 67) computes destination and source pointers using rect-&gt;left, it performs unchecked pointer arithmetic that can reach far beyond the allocated surface buffer. A malicious server sends a WIRE_TO_SURFACE_PDU_1 with AVC420 codec containing a regionRects entry where left greatly exceeds the surface width (e.g., left=60000 on a 128px surface). The H.264 bitstream decodes successfully, then yuv420_process_work_callback calls avc420_yuv_to_rgb which computes pDstPoint = pDstData + rect-&gt;top * nDstStep + rect-&gt;left * 4, writing 16-byte SSE vectors 1888+ bytes past the allocated heap region. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-29775:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a client-side heap out-of-bounds read/write occurs in FreeRDP&#39;s bitmap cache subsystem due to an off-by-one boundary check in bitmap_cache_put. A malicious server can send a CACHE_BITMAP_ORDER (Rev1) with cacheId equal to maxCells, bypassing the guard and accessing cells[] one element past the allocated array. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-31884:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, division by zero in MS-ADPCM and IMA-ADPCM decoders when nBlockAlign is 0, leading to a crash. In libfreerdp/codec/dsp.c, both ADPCM decoders use size % block_size where block_size = context-&gt;common.format.nBlockAlign. The nBlockAlign value comes from the Server Audio Formats PDU on the RDPSND channel. The value 0 is not validated anywhere before reaching the decoder. When nBlockAlign = 0, the modulo operation causes a SIGFPE (floating point exception) crash. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-31897:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, there is an out-of-bounds read in freerdp_bitmap_decompress_planar when SrcSize is 0. The function dereferences *srcp (which points to pSrcData) without first verifying that SrcSize &gt;= 1. When SrcSize is 0 and pSrcData is non-NULL, this reads one byte past the end of the source buffer. This vulnerability is fixed in 3.24.0.&#xA;CVE-2026-33985:FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.24.2, pixel data from adjacent heap memory is rendered to screen, potentially leaking sensitive data to the attacker. This issue has been patched in version 3.24.2.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="2" name="libwinpr-devel" release="5.u4" version="2.11.8">
					<filename>libwinpr-devel-2.11.8-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libwinpr-devel-2.11.8-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-help" release="5.u4" version="2.11.8">
					<filename>freerdp-help-2.11.8-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/freerdp-help-2.11.8-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="libwinpr" release="5.u4" version="2.11.8">
					<filename>libwinpr-2.11.8-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libwinpr-2.11.8-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp" release="5.u4" version="2.11.8">
					<filename>freerdp-2.11.8-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/freerdp-2.11.8-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="freerdp-devel" release="5.u4" version="2.11.8">
					<filename>freerdp-devel-2.11.8-5.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/freerdp-devel-2.11.8-5.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr-devel" release="5.u4" version="2.11.8">
					<filename>libwinpr-devel-2.11.8-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libwinpr-devel-2.11.8-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp" release="5.u4" version="2.11.8">
					<filename>freerdp-2.11.8-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/freerdp-2.11.8-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="libwinpr" release="5.u4" version="2.11.8">
					<filename>libwinpr-2.11.8-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libwinpr-2.11.8-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-help" release="5.u4" version="2.11.8">
					<filename>freerdp-help-2.11.8-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/freerdp-help-2.11.8-5.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="freerdp-devel" release="5.u4" version="2.11.8">
					<filename>freerdp-devel-2.11.8-5.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/freerdp-devel-2.11.8-5.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3157</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4873&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4873" id="CVE-2026-4873" title="CVE-2026-4873" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5545&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5545" id="CVE-2026-5545" title="CVE-2026-5545" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5773&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5773" id="CVE-2026-5773" title="CVE-2026-5773" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6253&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6253" id="CVE-2026-6253" title="CVE-2026-6253" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6276&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6276" id="CVE-2026-6276" title="CVE-2026-6276" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6429&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6429" id="CVE-2026-6429" title="CVE-2026-6429" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7168" id="CVE-2026-7168" title="CVE-2026-7168" type="cve"></reference>
		</references>
		<description>CVE-2026-4873:A vulnerability exists where a connection requiring TLS incorrectly reuses an&#xA;existing unencrypted connection from the same connection pool. If an initial&#xA;transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request&#xA;to that same host bypasses the TLS requirement and instead transmit data&#xA;unencrypted.&#xA;CVE-2026-5545:libcurl might in some circumstances reuse the wrong connection when asked to&#xA;do an authenticated HTTP(S) request after a Negotiate-authenticated one, when&#xA;both use the same host.&#xA;&#xA;libcurl features a pool of recent connections so that subsequent requests can&#xA;reuse an existing connection to avoid overhead.&#xA;&#xA;When reusing a connection a range of criteria must be met. Due to a logical&#xA;error in the code, a request that was issued by an application could&#xA;wrongfully reuse an existing connection to the same server that was&#xA;authenticated using different credentials.&#xA;&#xA;An application that first uses Negotiate authentication to a server with&#xA;`user1:password1` and then does another operation to the same server asking&#xA;for any authentication method but for `user2:password2` (while the previous&#xA;connection is still alive) - the second request gets confused and wrongly&#xA;reuses the same connection and sends the new request over that connection&#xA;thinking it uses a mix of user1&#39;s and user2&#39;s credentials when it is in fact&#xA;still using the connection authenticated for user1...&#xA;CVE-2026-5773:libcurl might in some circumstances reuse the wrong connection for SMB(S)&#xA;transfers.&#xA;&#xA;libcurl features a pool of recent connections so that subsequent requests can&#xA;reuse an existing connection to avoid overhead.&#xA;&#xA;When reusing a connection a range of criteria must be met. Due to a logical&#xA;error in the code, a network transfer operation that was requested by an&#xA;application could wrongfully reuse an existing SMB connection to the same&#xA;server that was using a different &#39;share&#39; than the new subsequent transfer&#xA;should.&#xA;&#xA;This could in unlucky situations lead to the download of the wrong file or the&#xA;upload of a file to the wrong place. When this happens, the same credentials&#xA;are used and the server name is the same.&#xA;CVE-2026-6253:curl might erroneously pass on credentials for a first proxy to a second&#xA;proxy.&#xA;&#xA;This can happen when the following conditions are true:&#xA;&#xA;1. curl is setup to use specific different proxies for different URL schemes&#xA;2. the first proxy needs credentials&#xA;3. the second proxy uses no credentials&#xA;4. while using the first proxy (using say `http://`), curl is asked to follow&#xA;   a redirect to a URL using another scheme (say `https://`), accessed using a&#xA;   second, different, proxy&#xA;CVE-2026-6276:Using libcurl, when a custom `Host:` header is first set for an HTTP request&#xA;and a second request is subsequently done using the same *easy handle* but&#xA;without the custom `Host:` header set, the second request would use stale&#xA;information and pass on cookies meant for the first host in the second&#xA;request. Leak them.&#xA;CVE-2026-6429:When asked to both use a `.netrc` file for credentials and to follow HTTP&#xA;redirects, libcurl could leak the password used for the first host to the&#xA;followed-to host under certain circumstances.&#xA;CVE-2026-7168:Successfully using libcurl to do a transfer over a specific HTTP proxy&#xA;(`proxyA`) with **Digest** authentication and then changing the proxy host to&#xA;a second one (`proxyB`) for a second transfer, reusing the same handle, makes&#xA;libcurl wrongly pass on the `Proxy-Authorization:` header field meant for&#xA;`proxyA`, to `proxyB`.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="49.u33" version="7.79.1">
					<filename>libcurl-devel-7.79.1-49.u33.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libcurl-devel-7.79.1-49.u33.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="49.u33" version="7.79.1">
					<filename>libcurl-7.79.1-49.u33.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libcurl-7.79.1-49.u33.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="49.u33" version="7.79.1">
					<filename>curl-7.79.1-49.u33.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/curl-7.79.1-49.u33.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="49.u33" version="7.79.1">
					<filename>libcurl-devel-7.79.1-49.u33.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libcurl-devel-7.79.1-49.u33.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="curl" release="49.u33" version="7.79.1">
					<filename>curl-7.79.1-49.u33.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/curl-7.79.1-49.u33.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="49.u33" version="7.79.1">
					<filename>libcurl-7.79.1-49.u33.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libcurl-7.79.1-49.u33.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="49.u33" version="7.79.1">
					<filename>curl-help-7.79.1-49.u33.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/curl-help-7.79.1-49.u33.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3158</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34956&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34956" id="CVE-2026-34956" title="CVE-2026-34956" type="cve"></reference>
		</references>
		<description>CVE-2026-34956:A flaw was found in Open vSwitch. When Open vSwitch is configured with a conntrack flow using FTP helpers over the userspace datapath, a remote attacker can send a specially crafted FTP stream with an EPASV command exceeding 255 characters. This heap access error can lead to a crash, resulting in a Denial of Service (DoS) for the affected system.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="openvswitch-devel" release="9.u7" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openvswitch-devel-2.12.4-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch-help" release="9.u7" version="2.12.4">
					<filename>openvswitch-help-2.12.4-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openvswitch-help-2.12.4-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openvswitch" release="9.u7" version="2.12.4">
					<filename>openvswitch-2.12.4-9.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openvswitch-2.12.4-9.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-openvswitch" release="9.u7" version="2.12.4">
					<filename>python3-openvswitch-2.12.4-9.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-openvswitch-2.12.4-9.u7.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-help" release="9.u7" version="2.12.4">
					<filename>openvswitch-help-2.12.4-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openvswitch-help-2.12.4-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch-devel" release="9.u7" version="2.12.4">
					<filename>openvswitch-devel-2.12.4-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openvswitch-devel-2.12.4-9.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openvswitch" release="9.u7" version="2.12.4">
					<filename>openvswitch-2.12.4-9.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openvswitch-2.12.4-9.u7.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3159</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28387&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28387" id="CVE-2026-28387" title="CVE-2026-28387" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28388&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28388" id="CVE-2026-28388" title="CVE-2026-28388" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28389&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28389" id="CVE-2026-28389" title="CVE-2026-28389" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28390&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28390" id="CVE-2026-28390" title="CVE-2026-28390" type="cve"></reference>
		</references>
		<description>CVE-2026-28387:Issue summary: An uncommon configuration of clients performing DANE TLSA-based&#xA;server authentication, when paired with uncommon server DANE TLSA records, may&#xA;result in a use-after-free and/or double-free on the client side.&#xA;&#xA;Impact summary: A use after free can have a range of potential consequences&#xA;such as the corruption of valid data, crashes or execution of arbitrary code.&#xA;&#xA;However, the issue only affects clients that make use of TLSA records with both&#xA;the PKIX-TA(0/PKIX-EE(1) certificate usages and the DANE-TA(2) certificate&#xA;usage.&#xA;&#xA;By far the most common deployment of DANE is in SMTP MTAs for which RFC7672&#xA;recommends that clients treat as &#39;unusable&#39; any TLSA records that have the PKIX&#xA;certificate usages.  These SMTP (or other similar) clients are not vulnerable&#xA;to this issue.  Conversely, any clients that support only the PKIX usages, and&#xA;ignore the DANE-TA(2) usage are also not vulnerable.&#xA;&#xA;The client would also need to be communicating with a server that publishes a&#xA;TLSA RRset with both types of TLSA records.&#xA;&#xA;No FIPS modules are affected by this issue, the problem code is outside the&#xA;FIPS module boundary.&#xA;CVE-2026-28388:Issue summary: When a delta CRL that contains a Delta CRL Indicator extension&#xA;is processed a NULL pointer dereference might happen if the required CRL&#xA;Number extension is missing.&#xA;&#xA;Impact summary: A NULL pointer dereference can trigger a crash which&#xA;leads to a Denial of Service for an application.&#xA;&#xA;When CRL processing and delta CRL processing is enabled during X.509&#xA;certificate verification, the delta CRL processing does not check&#xA;whether the CRL Number extension is NULL before dereferencing it.&#xA;When a malformed delta CRL file is being processed, this parameter&#xA;can be NULL, causing a NULL pointer dereference.&#xA;&#xA;Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in&#xA;the verification context, the certificate being verified to contain a&#xA;freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and&#xA;an attacker to provide a malformed CRL to an application that processes it.&#xA;&#xA;The vulnerability is limited to Denial of Service and cannot be escalated to&#xA;achieve code execution or memory disclosure. For that reason the issue was&#xA;assessed as Low severity according to our Security Policy.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the affected code is outside the OpenSSL FIPS module boundary.&#xA;CVE-2026-28389:Issue summary: During processing of a crafted CMS EnvelopedData message&#xA;with KeyAgreeRecipientInfo a NULL pointer dereference can happen.&#xA;&#xA;Impact summary: Applications that process attacker-controlled CMS data may&#xA;crash before authentication or cryptographic operations occur resulting in&#xA;Denial of Service.&#xA;&#xA;When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is&#xA;processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier&#xA;is examined without checking for its presence. This results in a NULL&#xA;pointer dereference if the field is missing.&#xA;&#xA;Applications and services that call CMS_decrypt() on untrusted input&#xA;(e.g., S/MIME processing or CMS-based protocols) are vulnerable.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this&#xA;issue, as the affected code is outside the OpenSSL FIPS module boundary.&#xA;CVE-2026-28390:Issue summary: During processing of a crafted CMS EnvelopedData message&#xA;with KeyTransportRecipientInfo a NULL pointer dereference can happen.&#xA;&#xA;Impact summary: Applications that process attacker-controlled CMS data may&#xA;crash before authentication or cryptographic operations occur resulting in&#xA;Denial of Service.&#xA;&#xA;When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with&#xA;RSA-OAEP encryption is processed, the optional parameters field of&#xA;RSA-OAEP SourceFunc algorithm identifier is examined without checking&#xA;for its presence. This results in a NULL pointer dereference if the field&#xA;is missing.&#xA;&#xA;Applications and services that call CMS_decrypt() on untrusted input&#xA;(e.g., S/MIME processing or CMS-based protocols) are vulnerable.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this&#xA;issue, as the affected code is outside the OpenSSL FIPS module boundary.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="1" name="openssl-libs" release="39.u22" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openssl-libs-1.1.1m-39.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-perl" release="39.u22" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openssl-perl-1.1.1m-39.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl" release="39.u22" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openssl-1.1.1m-39.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="openssl-devel" release="39.u22" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u22.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openssl-devel-1.1.1m-39.u22.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-perl" release="39.u22" version="1.1.1m">
					<filename>openssl-perl-1.1.1m-39.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openssl-perl-1.1.1m-39.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl" release="39.u22" version="1.1.1m">
					<filename>openssl-1.1.1m-39.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openssl-1.1.1m-39.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-devel" release="39.u22" version="1.1.1m">
					<filename>openssl-devel-1.1.1m-39.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openssl-devel-1.1.1m-39.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="openssl-libs" release="39.u22" version="1.1.1m">
					<filename>openssl-libs-1.1.1m-39.u22.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openssl-libs-1.1.1m-39.u22.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="openssl-help" release="39.u22" version="1.1.1m">
					<filename>openssl-help-1.1.1m-39.u22.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openssl-help-1.1.1m-39.u22.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3160</id>
		<title>An update for glib-networking is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2574&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2574" id="CVE-2026-2574" title="CVE-2026-2574" type="cve"></reference>
		</references>
		<description>CVE-2026-2574:A vulnerability classified as problematic has been found in glib-networking. CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. This is going to have an impact on availability. There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="glib-networking" release="7.u2" version="2.68.1">
					<filename>glib-networking-2.68.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glib-networking-2.68.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glib-networking-tests" release="7.u2" version="2.68.1">
					<filename>glib-networking-tests-2.68.1-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glib-networking-tests-2.68.1-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib-networking-tests" release="7.u2" version="2.68.1">
					<filename>glib-networking-tests-2.68.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glib-networking-tests-2.68.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glib-networking" release="7.u2" version="2.68.1">
					<filename>glib-networking-2.68.1-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glib-networking-2.68.1-7.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3161</id>
		<title>An update for python-requests is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25645&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25645" id="CVE-2026-25645" title="CVE-2026-25645" type="cve"></reference>
		</references>
		<description>CVE-2026-25645:Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python-requests-help" release="12.u9" version="2.26.0">
					<filename>python-requests-help-2.26.0-12.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-requests-help-2.26.0-12.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-requests" release="12.u9" version="2.26.0">
					<filename>python3-requests-2.26.0-12.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-requests-2.26.0-12.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3162</id>
		<title>An update for qt5-qtsvg is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-10729&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-10729" id="CVE-2025-10729" title="CVE-2025-10729" type="cve"></reference>
		</references>
		<description>CVE-2025-10729:The module will parse a &lt;pattern&gt; node which is not a child of a structural node. The node will be deleted after creation but might be accessed later leading to a use after free.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="qt5-qtsvg" release="2.u2" version="5.15.2">
					<filename>qt5-qtsvg-5.15.2-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtsvg-5.15.2-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtsvg-devel" release="2.u2" version="5.15.2">
					<filename>qt5-qtsvg-devel-5.15.2-2.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtsvg-devel-5.15.2-2.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtsvg" release="2.u2" version="5.15.2">
					<filename>qt5-qtsvg-5.15.2-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtsvg-5.15.2-2.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtsvg-devel" release="2.u2" version="5.15.2">
					<filename>qt5-qtsvg-devel-5.15.2-2.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtsvg-devel-5.15.2-2.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3163</id>
		<title>An update for mutt is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43859" id="CVE-2026-43859" title="CVE-2026-43859" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43860&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43860" id="CVE-2026-43860" title="CVE-2026-43860" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43861&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43861" id="CVE-2026-43861" title="CVE-2026-43861" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43862&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43862" id="CVE-2026-43862" title="CVE-2026-43862" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43863&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43863" id="CVE-2026-43863" title="CVE-2026-43863" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43864&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43864" id="CVE-2026-43864" title="CVE-2026-43864" type="cve"></reference>
		</references>
		<description>CVE-2026-43859:mutt before 2.3.2 sometimes uses strfcpy instead of memcpy for the IMAP auth_cram MD5 digest.&#xA;CVE-2026-43860:mutt before 2.3.2 sometimes truncates the hash_passwd by one byte for IMAP auth_cram MD5 digest.&#xA;CVE-2026-43861:mutt before 2.3.2 does not check for &#39;\0&#39; in url_pct_decode.&#xA;CVE-2026-43862:In mutt before 2.3.2, the imap_auth_gss security level is mishandled.&#xA;CVE-2026-43863:mutt before 2.3.2 has an infinite loop in data_object_to_stream in crypt-gpgme.c.&#xA;CVE-2026-43864:mutt before 2.3.2 has a show_sig_summary NULL pointer dereference.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="5" name="mutt-help" release="4.u2" version="2.2.12">
					<filename>mutt-help-2.2.12-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mutt-help-2.2.12-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="5" name="mutt" release="4.u2" version="2.2.12">
					<filename>mutt-2.2.12-4.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mutt-2.2.12-4.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="5" name="mutt" release="4.u2" version="2.2.12">
					<filename>mutt-2.2.12-4.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mutt-2.2.12-4.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3164</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-14575&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-14575" id="CVE-2025-14575" title="CVE-2025-14575" type="cve"></reference>
		</references>
		<description>CVE-2025-14575:An Uncontrolled Search Path Element vulnerability in the OpenSSL TLS backend of Qt Network (qtbase) in Qt Qt Framework (Unix) allows a local attacker to load a rogue CA certificate as a trusted system authority via a crafted certificate file placed in the application&#39;s working directory.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-examples" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-examples-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-postgresql" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-postgresql-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-odbc" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-odbc-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-private-devel" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-private-devel-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-devel" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-devel-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-static" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-static-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-gui" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-gui-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase-mysql" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-mysql-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="qt5-qtbase" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-19.u13.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/qt5-qtbase-5.15.2-19.u13.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-postgresql" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-postgresql-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-postgresql-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-private-devel" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-private-devel-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-private-devel-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-devel" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-devel-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-devel-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-mysql" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-mysql-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-mysql-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-odbc" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-odbc-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-odbc-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-static" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-static-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-static-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-gui" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-gui-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-gui-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="qt5-qtbase-examples" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-examples-5.15.2-19.u13.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-examples-5.15.2-19.u13.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="qt5-qtbase-common" release="19.u13" version="5.15.2">
					<filename>qt5-qtbase-common-5.15.2-19.u13.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/qt5-qtbase-common-5.15.2-19.u13.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3165</id>
		<title>An update for libssh2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7598&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7598" id="CVE-2026-7598" title="CVE-2026-7598" type="cve"></reference>
		</references>
		<description>CVE-2026-7598:A security vulnerability has been detected in libssh2 up to 1.11.1. The impacted element is the function userauth_password of the file src/userauth.c. Such manipulation of the argument username_len/password_len leads to integer overflow. The attack may be launched remotely. The name of the patch is 256d04b60d80bf1190e96b0ad1e91b2174d744b1. A patch should be applied to remediate this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libssh2" release="8.u5" version="1.10.0">
					<filename>libssh2-1.10.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libssh2-1.10.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh2-devel" release="8.u5" version="1.10.0">
					<filename>libssh2-devel-1.10.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libssh2-devel-1.10.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh2-help" release="8.u5" version="1.10.0">
					<filename>libssh2-help-1.10.0-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libssh2-help-1.10.0-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh2" release="8.u5" version="1.10.0">
					<filename>libssh2-1.10.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libssh2-1.10.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh2-devel" release="8.u5" version="1.10.0">
					<filename>libssh2-devel-1.10.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libssh2-devel-1.10.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3166</id>
		<title>An update for hadoop is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27821&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-27821" id="CVE-2025-27821" title="CVE-2025-27821" type="cve"></reference>
		</references>
		<description>CVE-2025-27821:Out-of-bounds Write vulnerability in Apache Hadoop HDFS native client.&#xA;&#xA;This issue affects Apache Hadoop: from 3.2.0 before 3.4.2.&#xA;&#xA;Users are recommended to upgrade to version 3.4.2, which fixes the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="hadoop-hdfs" release="5.u6" version="3.3.6">
					<filename>hadoop-hdfs-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-hdfs-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-mapreduce-examples" release="5.u6" version="3.3.6">
					<filename>hadoop-mapreduce-examples-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-mapreduce-examples-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-mapreduce" release="5.u6" version="3.3.6">
					<filename>hadoop-mapreduce-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-mapreduce-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-client" release="5.u6" version="3.3.6">
					<filename>hadoop-client-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-client-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-maven-plugin" release="5.u6" version="3.3.6">
					<filename>hadoop-maven-plugin-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-maven-plugin-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-tests" release="5.u6" version="3.3.6">
					<filename>hadoop-tests-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-tests-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-common" release="5.u6" version="3.3.6">
					<filename>hadoop-common-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-common-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="hadoop-httpfs" release="5.u6" version="3.3.6">
					<filename>hadoop-httpfs-3.3.6-5.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-httpfs-3.3.6-5.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-common-native" release="5.u6" version="3.3.6">
					<filename>hadoop-common-native-3.3.6-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/hadoop-common-native-3.3.6-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-devel" release="5.u6" version="3.3.6">
					<filename>hadoop-devel-3.3.6-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/hadoop-devel-3.3.6-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-yarn" release="5.u6" version="3.3.6">
					<filename>hadoop-yarn-3.3.6-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/hadoop-yarn-3.3.6-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libhdfs" release="5.u6" version="3.3.6">
					<filename>libhdfs-3.3.6-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libhdfs-3.3.6-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="hadoop-yarn-security" release="5.u6" version="3.3.6">
					<filename>hadoop-yarn-security-3.3.6-5.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/hadoop-yarn-security-3.3.6-5.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-common-native" release="5.u6" version="3.3.6">
					<filename>hadoop-common-native-3.3.6-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-common-native-3.3.6-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-yarn" release="5.u6" version="3.3.6">
					<filename>hadoop-yarn-3.3.6-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-yarn-3.3.6-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-yarn-security" release="5.u6" version="3.3.6">
					<filename>hadoop-yarn-security-3.3.6-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-yarn-security-3.3.6-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libhdfs" release="5.u6" version="3.3.6">
					<filename>libhdfs-3.3.6-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libhdfs-3.3.6-5.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="hadoop-devel" release="5.u6" version="3.3.6">
					<filename>hadoop-devel-3.3.6-5.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/hadoop-devel-3.3.6-5.u6.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3167</id>
		<title>An update for python-ecdsa is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33936&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33936" id="CVE-2026-33936" title="CVE-2026-33936" type="cve"></reference>
		</references>
		<description>CVE-2026-33936:The `ecdsa` PyPI package is a pure Python implementation of ECC (Elliptic Curve Cryptography) with support for ECDSA (Elliptic Curve Digital Signature Algorithm), EdDSA (Edwards-curve Digital Signature Algorithm) and ECDH (Elliptic Curve Diffie-Hellman). Prior to version 0.19.2, an issue in the low-level DER parsing functions can cause unexpected exceptions to be raised from the public API functions. `ecdsa.der.remove_octet_string()` accepts truncated DER where the encoded length exceeds the available buffer. For example, an OCTET STRING that declares a length of 4096 bytes but provides only 3 bytes is parsed successfully instead of being rejected. Because of that, a crafted DER input can cause `SigningKey.from_der()` to raise an internal exception (`IndexError: index out of bounds on dimension 1`) rather than cleanly rejecting malformed DER (e.g., raising `UnexpectedDER` or `ValueError`). Applications that parse untrusted DER private keys may crash if they do not handle unexpected exceptions, resulting in a denial of service. Version 0.19.2 patches the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python-ecdsa-help" release="4.u2" version="0.17.0">
					<filename>python-ecdsa-help-0.17.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-ecdsa-help-0.17.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-ecdsa" release="4.u2" version="0.17.0">
					<filename>python3-ecdsa-0.17.0-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-ecdsa-0.17.0-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3168</id>
		<title>An update for sudo is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35535&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35535" id="CVE-2026-35535" title="CVE-2026-35535" type="cve"></reference>
		</references>
		<description>CVE-2026-35535:In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="sudo-devel" release="21.u12" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sudo-devel-1.9.8p2-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sudo" release="21.u12" version="1.9.8p2">
					<filename>sudo-1.9.8p2-21.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sudo-1.9.8p2-21.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="sudo-help" release="21.u12" version="1.9.8p2">
					<filename>sudo-help-1.9.8p2-21.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sudo-help-1.9.8p2-21.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo" release="21.u12" version="1.9.8p2">
					<filename>sudo-1.9.8p2-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sudo-1.9.8p2-21.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sudo-devel" release="21.u12" version="1.9.8p2">
					<filename>sudo-devel-1.9.8p2-21.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sudo-devel-1.9.8p2-21.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3169</id>
		<title>An update for perl-Compress-Raw-Zlib is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3381&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3381" id="CVE-2026-3381" title="CVE-2026-3381" type="cve"></reference>
		</references>
		<description>CVE-2026-3381:Compress::Raw::Zlib versions through 2.219 for Perl use potentially insecure versions of zlib.&#xA;&#xA;Compress::Raw::Zlib includes a copy of the zlib library. Compress::Raw::Zlib version 2.220 includes zlib 1.3.2, which addresses findings fron the 7ASecurity audit of zlib. The includes fixs for CVE-2026-27171.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="1" name="perl-Compress-Raw-Zlib" release="3.u2" version="2.202">
					<filename>perl-Compress-Raw-Zlib-2.202-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/perl-Compress-Raw-Zlib-2.202-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="perl-Compress-Raw-Zlib-help" release="3.u2" version="2.202">
					<filename>perl-Compress-Raw-Zlib-help-2.202-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-Compress-Raw-Zlib-help-2.202-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="perl-Compress-Raw-Zlib" release="3.u2" version="2.202">
					<filename>perl-Compress-Raw-Zlib-2.202-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-Compress-Raw-Zlib-2.202-3.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3170</id>
		<title>An update for gstreamer1-plugins-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2921&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2921" id="CVE-2026-2921" title="CVE-2026-2921" type="cve"></reference>
		</references>
		<description>CVE-2026-2921:GStreamer RIFF Palette Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.&#xA;&#xA;The specific flaw exists within the handling of palette data in AVI files. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before writing to memory. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28854.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base-devel" release="10.u6" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-10.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gstreamer1-plugins-base-devel-1.18.4-10.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base" release="10.u6" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-10.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gstreamer1-plugins-base-1.18.4-10.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-base-help" release="10.u6" version="1.18.4">
					<filename>gstreamer1-plugins-base-help-1.18.4-10.u6.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gstreamer1-plugins-base-help-1.18.4-10.u6.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base-devel" release="10.u6" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-10.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gstreamer1-plugins-base-devel-1.18.4-10.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base" release="10.u6" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-10.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gstreamer1-plugins-base-1.18.4-10.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3171</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2003&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2003" id="CVE-2026-2003" title="CVE-2026-2003" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2004" id="CVE-2026-2004" title="CVE-2026-2004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2005" id="CVE-2026-2005" title="CVE-2026-2005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2006&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2006" id="CVE-2026-2006" title="CVE-2026-2006" type="cve"></reference>
		</references>
		<description>CVE-2026-2003:Improper validation of type &#34;oidvector&#34; in PostgreSQL allows a database user to disclose a few bytes of server memory.  We have not ruled out viability of attacks that arrange for presence of confidential information in disclosed bytes, but they seem unlikely.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2004:Missing validation of type of input in PostgreSQL intarray extension selectivity estimator function allows an object creator to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2005:Heap buffer overflow in PostgreSQL pgcrypto allows a ciphertext provider to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;CVE-2026-2006:Missing validation of multibyte character length in PostgreSQL text manipulation allows a database user to issue crafted queries that achieve a buffer overrun.  That suffices to execute arbitrary code as the operating system user running the database.  Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u5" version="13.23">
					<filename>postgresql-server-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-server-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u5" version="13.23">
					<filename>postgresql-plperl-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-plperl-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u5" version="13.23">
					<filename>postgresql-plpython3-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-plpython3-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u5" version="13.23">
					<filename>postgresql-test-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-test-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u5" version="13.23">
					<filename>postgresql-contrib-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-contrib-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u5" version="13.23">
					<filename>postgresql-private-devel-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-private-devel-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u5" version="13.23">
					<filename>postgresql-static-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-static-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u5" version="13.23">
					<filename>postgresql-pltcl-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-pltcl-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u5" version="13.23">
					<filename>postgresql-private-libs-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-private-libs-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u5" version="13.23">
					<filename>postgresql-server-devel-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-server-devel-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u5" version="13.23">
					<filename>postgresql-llvmjit-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-llvmjit-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u5" version="13.23">
					<filename>postgresql-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u5" version="13.23">
					<filename>postgresql-docs-13.23-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-docs-13.23-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u5" version="13.23">
					<filename>postgresql-private-libs-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-private-libs-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u5" version="13.23">
					<filename>postgresql-server-devel-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-server-devel-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u5" version="13.23">
					<filename>postgresql-test-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-test-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u5" version="13.23">
					<filename>postgresql-llvmjit-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-llvmjit-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u5" version="13.23">
					<filename>postgresql-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u5" version="13.23">
					<filename>postgresql-pltcl-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-pltcl-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u5" version="13.23">
					<filename>postgresql-docs-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-docs-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u5" version="13.23">
					<filename>postgresql-static-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-static-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u5" version="13.23">
					<filename>postgresql-plpython3-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-plpython3-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u5" version="13.23">
					<filename>postgresql-server-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-server-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u5" version="13.23">
					<filename>postgresql-contrib-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-contrib-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u5" version="13.23">
					<filename>postgresql-plperl-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-plperl-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u5" version="13.23">
					<filename>postgresql-private-devel-13.23-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/postgresql-private-devel-13.23-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u5" version="13.23">
					<filename>postgresql-test-rpm-macros-13.23-1.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/postgresql-test-rpm-macros-13.23-1.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3172</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0989&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0989" id="CVE-2026-0989" title="CVE-2026-0989" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0992&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0992" id="CVE-2026-0992" title="CVE-2026-0992" type="cve"></reference>
		</references>
		<description>CVE-2026-0989:A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested &lt;include&gt; directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.&#xA;CVE-2026-0992:A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated &lt;nextCatalog&gt; elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="libxml2-help" release="25.u20" version="2.9.14">
					<filename>libxml2-help-2.9.14-25.u20.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libxml2-help-2.9.14-25.u20.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-libxml2" release="25.u20" version="2.9.14">
					<filename>python3-libxml2-2.9.14-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-libxml2-2.9.14-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2" release="25.u20" version="2.9.14">
					<filename>libxml2-2.9.14-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libxml2-2.9.14-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libxml2-devel" release="25.u20" version="2.9.14">
					<filename>libxml2-devel-2.9.14-25.u20.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libxml2-devel-2.9.14-25.u20.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2-devel" release="25.u20" version="2.9.14">
					<filename>libxml2-devel-2.9.14-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libxml2-devel-2.9.14-25.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-libxml2" release="25.u20" version="2.9.14">
					<filename>python3-libxml2-2.9.14-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-libxml2-2.9.14-25.u20.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libxml2" release="25.u20" version="2.9.14">
					<filename>libxml2-2.9.14-25.u20.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libxml2-2.9.14-25.u20.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3173</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4775&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4775" id="CVE-2026-4775" title="CVE-2026-4775" type="cve"></reference>
		</references>
		<description>CVE-2026-4775:A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="50.u23" version="4.3.0">
					<filename>libtiff-static-4.3.0-50.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libtiff-static-4.3.0-50.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="50.u23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-50.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libtiff-tools-4.3.0-50.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="50.u23" version="4.3.0">
					<filename>libtiff-4.3.0-50.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libtiff-4.3.0-50.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="50.u23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-50.u23.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libtiff-devel-4.3.0-50.u23.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="50.u23" version="4.3.0">
					<filename>libtiff-static-4.3.0-50.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libtiff-static-4.3.0-50.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="50.u23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-50.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libtiff-tools-4.3.0-50.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff" release="50.u23" version="4.3.0">
					<filename>libtiff-4.3.0-50.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libtiff-4.3.0-50.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="50.u23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-50.u23.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libtiff-devel-4.3.0-50.u23.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="50.u23" version="4.3.0">
					<filename>libtiff-help-4.3.0-50.u23.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libtiff-help-4.3.0-50.u23.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3174</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32776&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32776" id="CVE-2026-32776" title="CVE-2026-32776" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32777&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32777" id="CVE-2026-32777" title="CVE-2026-32777" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32778" id="CVE-2026-32778" title="CVE-2026-32778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45186&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45186" id="CVE-2026-45186" title="CVE-2026-45186" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41080&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41080" id="CVE-2026-41080" title="CVE-2026-41080" type="cve"></reference>
		</references>
		<description>CVE-2026-32776:libexpat before 2.7.5 allows a NULL pointer dereference with empty external parameter entity content.&#xA;CVE-2026-32777:libexpat before 2.7.5 allows an infinite loop while parsing DTD content.&#xA;CVE-2026-32778:libexpat before 2.7.5 allows a NULL pointer dereference in the function setContext on retry after an earlier ouf-of-memory condition.&#xA;CVE-2026-45186:In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.&#xA;CVE-2026-41080:libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="expat" release="24.u9" version="2.4.1">
					<filename>expat-2.4.1-24.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/expat-2.4.1-24.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="expat-devel" release="24.u9" version="2.4.1">
					<filename>expat-devel-2.4.1-24.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/expat-devel-2.4.1-24.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="expat-help" release="24.u9" version="2.4.1">
					<filename>expat-help-2.4.1-24.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/expat-help-2.4.1-24.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat-devel" release="24.u9" version="2.4.1">
					<filename>expat-devel-2.4.1-24.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/expat-devel-2.4.1-24.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="expat" release="24.u9" version="2.4.1">
					<filename>expat-2.4.1-24.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/expat-2.4.1-24.u9.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3175</id>
		<title>An update for perl-HTTP-Tiny is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7010&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7010" id="CVE-2026-7010" title="CVE-2026-7010" type="cve"></reference>
		</references>
		<description>CVE-2026-7010:HTTP::Tiny versions before 0.093 for Perl do not validate CRLF in HTTP request lines or control field header values.&#xA;&#xA;The unvalidated inputs are the method and URI in the request line, the URL host that becomes the `Host:` header, and HTTP/1.1 control data field values.&#xA;&#xA;An attacker who controls one of these inputs, for example a user supplied URL passed to a webhook or URL fetch endpoint, can inject additional headers and smuggle requests to the upstream server.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="perl-HTTP-Tiny" release="3.u2" version="0.080">
					<filename>perl-HTTP-Tiny-0.080-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-HTTP-Tiny-0.080-3.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-HTTP-Tiny-help" release="3.u2" version="0.080">
					<filename>perl-HTTP-Tiny-help-0.080-3.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-HTTP-Tiny-help-0.080-3.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3176</id>
		<title>An update for rubygem-addressable is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35611&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35611" id="CVE-2026-35611" title="CVE-2026-35611" type="cve"></reference>
		</references>
		<description>CVE-2026-35611:Addressable is an alternative implementation to the URI implementation that is part of Ruby&#39;s standard library. From 2.3.0 to before 2.9.0, within the URI template implementation in Addressable, two classes of URI template generate regular expressions vulnerable to catastrophic backtracking. Templates using the * (explode) modifier with any expansion operator (e.g., {foo*}, {+var*}, {#var*}, {/var*}, {.var*}, {;var*}, {?var*}, {&amp;var*}) generate patterns with nested unbounded quantifiers that are O(2^n) when matched against a maliciously crafted URI. Templates using multiple variables with the + or # operators (e.g., {+v1,v2,v3}) generate patterns with O(n^k) complexity due to the comma separator being within the matched character class, causing ambiguous backtracking across k variables. When matched against a maliciously crafted URI, this can result in catastrophic backtracking and uncontrolled resource consumption, leading to denial of service. This vulnerability is fixed in 2.9.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="rubygem-addressable" release="2.u1" version="2.8.0">
					<filename>rubygem-addressable-2.8.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/rubygem-addressable-2.8.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-addressable-doc" release="2.u1" version="2.8.0">
					<filename>rubygem-addressable-doc-2.8.0-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/rubygem-addressable-doc-2.8.0-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3177</id>
		<title>An update for corosync is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35091&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35091" id="CVE-2026-35091" title="CVE-2026-35091" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35092&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35092" id="CVE-2026-35092" title="CVE-2026-35092" type="cve"></reference>
		</references>
		<description>CVE-2026-35091:A flaw was found in Corosync. A remote unauthenticated attacker can exploit a wrong return value vulnerability in the Corosync membership commit token sanity check by sending a specially crafted User Datagram Protocol (UDP) packet. This can lead to an out-of-bounds read, causing a denial of service (DoS) and potentially disclosing limited memory contents&#xA;CVE-2026-35092:A flaw was found in Corosync. An integer overflow vulnerability in Corosync&#39;s join message sanity validation allows a remote, unauthenticated attacker to send crafted User Datagram Protocol (UDP) packets. This can cause the service to crash, leading to a denial of service. This vulnerability specifically affects Corosync deployments configured to use totemudp/totemudpu mode.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="corosync" release="3.u2" version="3.1.5">
					<filename>corosync-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/corosync-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosynclib-devel" release="3.u2" version="3.1.5">
					<filename>corosynclib-devel-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/corosynclib-devel-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosynclib" release="3.u2" version="3.1.5">
					<filename>corosynclib-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/corosynclib-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="corosync-vqsim" release="3.u2" version="3.1.5">
					<filename>corosync-vqsim-3.1.5-3.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/corosync-vqsim-3.1.5-3.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosync-vqsim" release="3.u2" version="3.1.5">
					<filename>corosync-vqsim-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/corosync-vqsim-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosynclib" release="3.u2" version="3.1.5">
					<filename>corosynclib-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/corosynclib-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosynclib-devel" release="3.u2" version="3.1.5">
					<filename>corosynclib-devel-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/corosynclib-devel-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="corosync" release="3.u2" version="3.1.5">
					<filename>corosync-3.1.5-3.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/corosync-3.1.5-3.u2.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3178</id>
		<title>An update for perl-Authen-SASL is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40918&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-40918" id="CVE-2025-40918" title="CVE-2025-40918" type="cve"></reference>
		</references>
		<description>CVE-2025-40918:Authen::SASL::Perl::DIGEST_MD5 versions 2.04 through 2.1800 for Perl generates the cnonce insecurely.&#xA;&#xA;The cnonce (client nonce) is generated from an MD5 hash of the PID, the epoch time and the built-in rand function. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage.&#xA;&#xA;According to RFC 2831, The cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, and to provide mutual authentication. The security of the implementation&#xA; depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="perl-Authen-SASL" release="17.u1" version="2.16">
					<filename>perl-Authen-SASL-2.16-17.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-Authen-SASL-2.16-17.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Authen-SASL-help" release="17.u1" version="2.16">
					<filename>perl-Authen-SASL-help-2.16-17.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-Authen-SASL-help-2.16-17.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3179</id>
		<title>An update for python-cryptography is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50782&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-50782" id="CVE-2023-50782" title="CVE-2023-50782" type="cve"></reference>
		</references>
		<description>CVE-2023-50782:A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="python3-cryptography" release="8.u8" version="36.0.1">
					<filename>python3-cryptography-36.0.1-8.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-cryptography-36.0.1-8.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-cryptography-help" release="8.u8" version="36.0.1">
					<filename>python-cryptography-help-36.0.1-8.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-cryptography-help-36.0.1-8.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-cryptography" release="8.u8" version="36.0.1">
					<filename>python3-cryptography-36.0.1-8.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-cryptography-36.0.1-8.u8.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3180</id>
		<title>An update for libarchive is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4426&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4426" id="CVE-2026-4426" title="CVE-2026-4426" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5121&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5121" id="CVE-2026-5121" title="CVE-2026-5121" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4111&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4111" id="CVE-2026-4111" title="CVE-2026-4111" type="cve"></reference>
		</references>
		<description>CVE-2026-4426:A flaw was found in libarchive. An Undefined Behavior vulnerability exists in the zisofs decompression logic, caused by improper validation of a field (`pz_log2_bs`) read from ISO9660 Rock Ridge extensions. A remote attacker can exploit this by supplying a specially crafted ISO file. This can lead to incorrect memory allocation and potential application crashes, resulting in a denial-of-service (DoS) condition.&#xA;CVE-2026-5121:A flaw was found in libarchive. On 32-bit systems, an integer overflow vulnerability exists in the zisofs block pointer allocation logic. A remote attacker can exploit this by providing a specially crafted ISO9660 image, which can lead to a heap buffer overflow. This could potentially allow for arbitrary code execution on the affected system.&#xA;CVE-2026-4111:A flaw was identified in the RAR5 archive decompression logic of the libarchive library, specifically within the archive_read_data() processing path. When a specially crafted RAR5 archive is processed, the decompression routine may enter a state where internal logic prevents forward progress. This condition results in an infinite loop that continuously consumes CPU resources. Because the archive passes checksum validation and appears structurally valid, affected applications cannot detect the issue before processing. This can allow attackers to cause persistent denial-of-service conditions in services that automatically process archives.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="bsdcat" release="13.u11" version="3.5.2">
					<filename>bsdcat-3.5.2-13.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bsdcat-3.5.2-13.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdtar" release="13.u11" version="3.5.2">
					<filename>bsdtar-3.5.2-13.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bsdtar-3.5.2-13.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive" release="13.u11" version="3.5.2">
					<filename>libarchive-3.5.2-13.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libarchive-3.5.2-13.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libarchive-devel" release="13.u11" version="3.5.2">
					<filename>libarchive-devel-3.5.2-13.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libarchive-devel-3.5.2-13.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="bsdcpio" release="13.u11" version="3.5.2">
					<filename>bsdcpio-3.5.2-13.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/bsdcpio-3.5.2-13.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libarchive-help" release="13.u11" version="3.5.2">
					<filename>libarchive-help-3.5.2-13.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libarchive-help-3.5.2-13.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive" release="13.u11" version="3.5.2">
					<filename>libarchive-3.5.2-13.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libarchive-3.5.2-13.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdtar" release="13.u11" version="3.5.2">
					<filename>bsdtar-3.5.2-13.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bsdtar-3.5.2-13.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libarchive-devel" release="13.u11" version="3.5.2">
					<filename>libarchive-devel-3.5.2-13.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libarchive-devel-3.5.2-13.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcat" release="13.u11" version="3.5.2">
					<filename>bsdcat-3.5.2-13.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bsdcat-3.5.2-13.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="bsdcpio" release="13.u11" version="3.5.2">
					<filename>bsdcpio-3.5.2-13.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/bsdcpio-3.5.2-13.u11.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3181</id>
		<title>An update for nginx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27651&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27651" id="CVE-2026-27651" title="CVE-2026-27651" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27654&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27654" id="CVE-2026-27654" title="CVE-2026-27654" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27784&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27784" id="CVE-2026-27784" title="CVE-2026-27784" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28753&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28753" id="CVE-2026-28753" title="CVE-2026-28753" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32647&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32647" id="CVE-2026-32647" title="CVE-2026-32647" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42945&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42945" id="CVE-2026-42945" title="CVE-2026-42945" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40701&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40701" id="CVE-2026-40701" title="CVE-2026-40701" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42934&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42934" id="CVE-2026-42934" title="CVE-2026-42934" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42946&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42946" id="CVE-2026-42946" title="CVE-2026-42946" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-9256&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-9256" id="CVE-2026-9256" title="CVE-2026-9256" type="cve"></reference>
		</references>
		<description>CVE-2026-27651:When the ngx_mail_auth_http_module module is enabled on NGINX Plus or NGINX Open Source, undisclosed requests can cause worker processes to terminate. This issue may occur when (1) CRAM-MD5 or APOP authentication is enabled, and (2) the authentication server permits retry by returning the Auth-Wait response header. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-27654:NGINX Open Source and NGINX Plus have a vulnerability in the ngx_http_dav_module module that might allow an attacker to trigger a buffer overflow to the NGINX worker process; this vulnerability may result in termination of the NGINX worker process or modification of source or destination file names outside the document root. This issue affects NGINX Open Source and NGINX Plus when the configuration file uses DAV module MOVE or COPY methods, prefix location (nonregular expression location configuration), and alias directives. The integrity impact is constrained because the NGINX worker process user has low privileges and does not have access to the entire system. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-27784:The 32-bit implementation of NGINX Open Source has a vulnerability in the ngx_http_mp4_module module, which might allow an attacker to over-read or over-write NGINX worker memory resulting in its termination, using a specially crafted MP4 file. The issue only affects 32-bit NGINX Open Source if it is built with the ngx_http_mp4_module module and the mp4 directive is used in the configuration file. Additionally, the attack is possible only if an attacker can trigger the processing of a specially crafted MP4 file with the ngx_http_mp4_module module. &#xA;&#xA;&#xA;Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-28753:NGINX Plus and NGINX Open Source have a vulnerability in the ngx_mail_smtp_module module due to the improper handling of CRLF sequences in DNS responses. This allows an attacker-controlled DNS server to inject arbitrary headers into SMTP upstream requests, leading to potential request manipulation. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-32647:NGINX Open Source and NGINX Plus have a vulnerability in the ngx_http_mp4_module module, which might allow an attacker to trigger a buffer over-read or over-write to the NGINX worker memory resulting in its termination or possibly code execution, using a specially crafted MP4 file. This issue affects NGINX Open Source and NGINX Plus if it is built with the ngx_http_mp4_module module and the mp4 directive is used in the configuration file. Additionally, the attack is possible only if an attacker can trigger the processing of a specially crafted MP4 file with the ngx_http_mp4_module module. &#xA;&#xA;&#xA;Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-42945:NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when the rewrite directive is followed by a rewrite, if, or set directive and an unnamed Perl-Compatible Regular Expression (PCRE) capture (for example, $1, $2) with a replacement string that includes a question mark (?). An unauthenticated attacker along with conditions beyond its control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-40701:NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_ssl_module module when the ssl_verify_client directive is set to &#34;on&#34; or &#34;optional,&#34; and the ssl_ocsp directive is set to &#34;on&#34; or the leaf parameters are configured with a resolver. With this configuration, an unauthenticated attacker can send requests along with conditions beyond its control that may cause a heap-use-after-free error in the NGINX worker process. This vulnerability may result in limited modification of data or the NGINX worker process restarting.&#xA;&#xA;&#xA;&#xA; Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-42934:NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_charset_module module. When charset, source_charset, and charset_map and proxy_pass with disabled buffering (&#34;off&#34;) directives are configured, unauthenticated attackers can send requests that with conditions beyond the attackers&#39; control to cause a heap buffer over-read in the NGINX worker process, leading to limited disclosure of memory or a restart.&#xA;&#xA;&#xA;&#xA; Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-42946:A vulnerability exists in the ngx_http_scgi_module and ngx_http_uwsgi_module modules that may result in excessive memory allocation or an over-read of data. When scgi_pass or uwsgi_pass is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;CVE-2026-9256:NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when a rewrite directive uses a regex pattern with distinct, overlapping Perl-Compatible Regular Expression (PCRE) captures (for example, ^/((.*))$) and a replacement string that references multiple such captures (for example, $1$2) in a redirect or arguments context. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. &#xA;&#xA;&#xA;Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="15.u11" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-mod-http-xslt-filter-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="15.u11" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-mod-stream-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx" release="15.u11" version="1.21.5">
					<filename>nginx-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="15.u11" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-mod-devel-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="15.u11" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-mod-http-image-filter-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="15.u11" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-mod-mail-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="15.u11" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-15.u11.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nginx-mod-http-perl-1.21.5-15.u11.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="15.u11" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-mod-http-perl-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx" release="15.u11" version="1.21.5">
					<filename>nginx-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="15.u11" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-mod-http-xslt-filter-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="15.u11" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-mod-http-image-filter-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="15.u11" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-mod-devel-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="15.u11" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-mod-mail-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="15.u11" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-15.u11.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-mod-stream-1.21.5-15.u11.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="15.u11" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-15.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-filesystem-1.21.5-15.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="15.u11" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-15.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-all-modules-1.21.5-15.u11.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="15.u11" version="1.21.5">
					<filename>nginx-help-1.21.5-15.u11.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nginx-help-1.21.5-15.u11.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3182</id>
		<title>An update for pdfbox is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33929&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33929" id="CVE-2026-33929" title="CVE-2026-33929" type="cve"></reference>
		</references>
		<description>CVE-2026-33929:Improper Limitation of a Pathname to a Restricted Directory (&#39;Path Traversal&#39;) vulnerability in Apache PDFBox Examples.&#xA;&#xA;This issue affects the &#xA;ExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.36, from 3.0.0 through 3.0.7.&#xA;&#xA;&#xA;Users are recommended to update to version 2.0.37 or 3.0.8 once &#xA;available. Until then, they should apply the fix provided in GitHub PR &#xA;427.&#xA;&#xA;The ExtractEmbeddedFiles example contained a path traversal vulnerability (CWE-22) mentioned in CVE-2026-23907. However the change in the releases 2.0.36 and 3.0.7 is flawed because it doesn&#39;t consider the file path separator. Because of that, a user having writing rights on /home/ABC could be victim to a malicious PDF resulting in a write attempt to any path starting with /home/ABC, e.g. &#34;/home/ABCDEF&#34;.&#xA;&#xA;Users who have copied this example into their production code should apply the mentioned change. The example &#xA;has been changed accordingly and is available in the project repository.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="xmpbox" release="4.u1" version="2.0.25">
					<filename>xmpbox-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xmpbox-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="fontbox" release="4.u1" version="2.0.25">
					<filename>fontbox-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/fontbox-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pdfbox-parent" release="4.u1" version="2.0.25">
					<filename>pdfbox-parent-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pdfbox-parent-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pdfbox-reactor" release="4.u1" version="2.0.25">
					<filename>pdfbox-reactor-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pdfbox-reactor-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pdfbox-tools" release="4.u1" version="2.0.25">
					<filename>pdfbox-tools-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pdfbox-tools-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="preflight" release="4.u1" version="2.0.25">
					<filename>preflight-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/preflight-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pdfbox" release="4.u1" version="2.0.25">
					<filename>pdfbox-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pdfbox-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pdfbox-debugger" release="4.u1" version="2.0.25">
					<filename>pdfbox-debugger-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pdfbox-debugger-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="pdfbox-javadoc" release="4.u1" version="2.0.25">
					<filename>pdfbox-javadoc-2.0.25-4.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pdfbox-javadoc-2.0.25-4.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3183</id>
		<title>An update for lcms2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41254&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41254" id="CVE-2026-41254" title="CVE-2026-41254" type="cve"></reference>
		</references>
		<description>CVE-2026-41254:Little CMS (lcms2) through 2.18 has an integer overflow in CubeSize in cmslut.c because the overflow check is performed after the multiplication.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="lcms2-devel" release="3.u1" version="2.13.1">
					<filename>lcms2-devel-2.13.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/lcms2-devel-2.13.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lcms2-utils" release="3.u1" version="2.13.1">
					<filename>lcms2-utils-2.13.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/lcms2-utils-2.13.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="lcms2" release="3.u1" version="2.13.1">
					<filename>lcms2-2.13.1-3.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/lcms2-2.13.1-3.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lcms2" release="3.u1" version="2.13.1">
					<filename>lcms2-2.13.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/lcms2-2.13.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lcms2-devel" release="3.u1" version="2.13.1">
					<filename>lcms2-devel-2.13.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/lcms2-devel-2.13.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="lcms2-utils" release="3.u1" version="2.13.1">
					<filename>lcms2-utils-2.13.1-3.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/lcms2-utils-2.13.1-3.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="lcms2-help" release="3.u1" version="2.13.1">
					<filename>lcms2-help-2.13.1-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/lcms2-help-2.13.1-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3184</id>
		<title>An update for sed is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-5958&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-5958" id="CVE-2026-5958" title="CVE-2026-5958" type="cve"></reference>
		</references>
		<description>CVE-2026-5958:When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: &#xA;1. resolves symlink to its target and stores the resolved path for determining when output is written,&#xA;2. opens the original symlink path (not the resolved one) to read the file. &#xA;Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process.&#xA;&#xA;&#xA;This issue was fixed in version 4.10.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="sed-help" release="8.u2" version="4.8">
					<filename>sed-help-4.8-8.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sed-help-4.8-8.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sed" release="8.u2" version="4.8">
					<filename>sed-4.8-8.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sed-4.8-8.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sed" release="8.u2" version="4.8">
					<filename>sed-4.8-8.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sed-4.8-8.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3185</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-21998&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-21998" id="CVE-2026-21998" title="CVE-2026-21998" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22001&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22001" id="CVE-2026-22001" title="CVE-2026-22001" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22002&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22002" id="CVE-2026-22002" title="CVE-2026-22002" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22004&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22004" id="CVE-2026-22004" title="CVE-2026-22004" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22005&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22005" id="CVE-2026-22005" title="CVE-2026-22005" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22009&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22009" id="CVE-2026-22009" title="CVE-2026-22009" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22015" id="CVE-2026-22015" title="CVE-2026-22015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22017&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22017" id="CVE-2026-22017" title="CVE-2026-22017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34267&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34267" id="CVE-2026-34267" title="CVE-2026-34267" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34270&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34270" id="CVE-2026-34270" title="CVE-2026-34270" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34271&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34271" id="CVE-2026-34271" title="CVE-2026-34271" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34276&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34276" id="CVE-2026-34276" title="CVE-2026-34276" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34278&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34278" id="CVE-2026-34278" title="CVE-2026-34278" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34293&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34293" id="CVE-2026-34293" title="CVE-2026-34293" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34303&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34303" id="CVE-2026-34303" title="CVE-2026-34303" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34304&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34304" id="CVE-2026-34304" title="CVE-2026-34304" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34308&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34308" id="CVE-2026-34308" title="CVE-2026-34308" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35236&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35236" id="CVE-2026-35236" title="CVE-2026-35236" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35237&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35237" id="CVE-2026-35237" title="CVE-2026-35237" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35238&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35238" id="CVE-2026-35238" title="CVE-2026-35238" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35239&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35239" id="CVE-2026-35239" title="CVE-2026-35239" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35240&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35240" id="CVE-2026-35240" title="CVE-2026-35240" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34317&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34317" id="CVE-2026-34317" title="CVE-2026-34317" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34319&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34319" id="CVE-2026-34319" title="CVE-2026-34319" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34318&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34318" id="CVE-2026-34318" title="CVE-2026-34318" type="cve"></reference>
		</references>
		<description>CVE-2026-21998:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-22001:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2026-22002:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-22004:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-22005:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-22009:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-22015:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).&#xA;CVE-2026-22017:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34267:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34270:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34271:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34276:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34278:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34293:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.45. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34303:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34304:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34308:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: JSON).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-35236:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-35237:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-35238:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-35239:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-35240:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34317:Vulnerability in the MySQL Shell product of Oracle MySQL (component: Shell: Core Client).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where MySQL Shell executes to compromise MySQL Shell.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Shell. CVSS 3.1 Base Score 5.0 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34319:Vulnerability in the MySQL Shell product of Oracle MySQL (component: Shell: Core Client).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where MySQL Shell executes to compromise MySQL Shell.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Shell. CVSS 3.1 Base Score 5.0 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H).&#xA;CVE-2026-34318:Vulnerability in the MySQL Shell product of Oracle MySQL (component: Shell: Core Client).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Shell.  While the vulnerability is in MySQL Shell, attacks may significantly impact additional products (scope change).  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all MySQL Shell accessible data. CVSS 3.1 Base Score 5.8 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u5" version="8.0.46">
					<filename>mysql-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u5" version="8.0.46">
					<filename>mysql-devel-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-devel-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u5" version="8.0.46">
					<filename>mysql-help-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-help-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u5" version="8.0.46">
					<filename>mysql-common-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-common-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u5" version="8.0.46">
					<filename>mysql-errmsg-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-errmsg-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u5" version="8.0.46">
					<filename>mysql-config-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-config-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u5" version="8.0.46">
					<filename>mysql-test-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-test-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u5" version="8.0.46">
					<filename>mysql-libs-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-libs-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u5" version="8.0.46">
					<filename>mysql-server-8.0.46-1.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/mysql-server-8.0.46-1.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u5" version="8.0.46">
					<filename>mysql-server-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-server-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u5" version="8.0.46">
					<filename>mysql-errmsg-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-errmsg-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u5" version="8.0.46">
					<filename>mysql-help-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-help-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u5" version="8.0.46">
					<filename>mysql-libs-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-libs-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u5" version="8.0.46">
					<filename>mysql-test-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-test-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u5" version="8.0.46">
					<filename>mysql-common-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-common-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u5" version="8.0.46">
					<filename>mysql-devel-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-devel-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u5" version="8.0.46">
					<filename>mysql-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u5" version="8.0.46">
					<filename>mysql-config-8.0.46-1.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/mysql-config-8.0.46-1.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3186</id>
		<title>An update for uriparser is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-67899&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-67899" id="CVE-2025-67899" title="CVE-2025-67899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42371&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42371" id="CVE-2026-42371" title="CVE-2026-42371" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-44927&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-44927" id="CVE-2026-44927" title="CVE-2026-44927" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-44928&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-44928" id="CVE-2026-44928" title="CVE-2026-44928" type="cve"></reference>
		</references>
		<description>CVE-2025-67899:uriparser through 0.9.9 allows unbounded recursion and stack consumption, as demonstrated by ParseMustBeSegmentNzNc with large input containing many commas.&#xA;CVE-2026-42371:uriparser before 1.0.1 has numeric truncation in text range comparison, if an application accepts URIs with a length in gigabytes.&#xA;CVE-2026-44927:In uriparser before 1.0.2, there is pointer difference truncation to int in various places.&#xA;CVE-2026-44928:In uriparser before 1.0.2, the function family EqualsUri can misclassify two unequal URIs as equal.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="uriparser-devel" release="2.u1" version="1.0.1">
					<filename>uriparser-devel-1.0.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/uriparser-devel-1.0.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uriparser" release="2.u1" version="1.0.1">
					<filename>uriparser-1.0.1-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/uriparser-1.0.1-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uriparser-devel" release="2.u1" version="1.0.1">
					<filename>uriparser-devel-1.0.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uriparser-devel-1.0.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uriparser" release="2.u1" version="1.0.1">
					<filename>uriparser-1.0.1-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uriparser-1.0.1-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uriparser-help" release="2.u1" version="1.0.1">
					<filename>uriparser-help-1.0.1-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uriparser-help-1.0.1-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3187</id>
		<title>An update for python-pip is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25645&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25645" id="CVE-2026-25645" title="CVE-2026-25645" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3219&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3219" id="CVE-2026-3219" title="CVE-2026-3219" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-44431&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-44431" id="CVE-2026-44431" title="CVE-2026-44431" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5752&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2023-5752" id="CVE-2023-5752" title="CVE-2023-5752" type="cve"></reference>
		</references>
		<description>CVE-2026-25645:Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.&#xA;CVE-2026-3219:pip handles concatenated tar and ZIP files as ZIP files regardless of filename or whether a file is both a tar and ZIP file. This behavior could result in confusing installation behavior, such as installing &#34;incorrect&#34; files according to the filename of the archive. New behavior only proceeds with installation if the file identifies uniquely as a ZIP or tar archive, not as both.&#xA;CVE-2026-44431:urllib3 is an HTTP client library for Python. From 1.23 to before 2.7.0, cross-origin redirects followed from the low-level API via ProxyManager.connection_from_url().urlopen(..., assert_same_host=False) still forward these sensitive headers. This vulnerability is fixed in 2.7.0.&#xA;CVE-2023-5752:When installing a package from a Mercurial VCS URL  (ie &#34;pip install &#xA;hg+...&#34;) with pip prior to v23.3, the specified Mercurial revision could&#xA; be used to inject arbitrary configuration options to the &#34;hg clone&#34; &#xA;call (ie &#34;--config&#34;). Controlling the Mercurial configuration can modify&#xA; how and which repository is installed. This vulnerability does not &#xA;affect users who aren&#39;t installing from Mercurial.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python-pip-help" release="18.u9" version="21.3.1">
					<filename>python-pip-help-21.3.1-18.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-pip-help-21.3.1-18.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-wheel" release="18.u9" version="21.3.1">
					<filename>python-pip-wheel-21.3.1-18.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-pip-wheel-21.3.1-18.u9.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pip" release="18.u9" version="21.3.1">
					<filename>python3-pip-21.3.1-18.u9.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pip-21.3.1-18.u9.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3188</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27447&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27447" id="CVE-2026-27447" title="CVE-2026-27447" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34978&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34978" id="CVE-2026-34978" title="CVE-2026-34978" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34979&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34979" id="CVE-2026-34979" title="CVE-2026-34979" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34980&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34980" id="CVE-2026-34980" title="CVE-2026-34980" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34990&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34990" id="CVE-2026-34990" title="CVE-2026-34990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-39314&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-39314" id="CVE-2026-39314" title="CVE-2026-39314" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-39316&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-39316" id="CVE-2026-39316" title="CVE-2026-39316" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41079&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41079" id="CVE-2026-41079" title="CVE-2026-41079" type="cve"></reference>
		</references>
		<description>CVE-2026-27447:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, CUPS daemon (cupsd) contains an authorization bypass vulnerability due to case-insensitive username comparison during authorization checks. The vulnerability allows an unprivileged user to gain unauthorized access to restricted operations by using a user with a username that differs only in case from an authorized user. At time of publication, there are no publicly available patches.&#xA;CVE-2026-34978:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, the RSS notifier allows .. path traversal in notify-recipient-uri (e.g., rss:///../job.cache), letting a remote IPP client write RSS XML bytes outside CacheDir/rss (anywhere that is lp-writable). In particular, because CacheDir is group-writable by default (typically root:lp and mode 0770), the notifier (running as lp) can replace root-managed state files via temp-file + rename(). This PoC clobbers CacheDir/job.cache with RSS XML, and after restarting cupsd the scheduler fails to parse the job cache and previously queued jobs disappear. At time of publication, there are no publicly available patches.&#xA;CVE-2026-34979:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, there is a heap-based buffer overflow in the CUPS scheduler when building filter option strings from job attribute. At time of publication, there are no publicly available patches.&#xA;CVE-2026-34980:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, in a network-exposed cupsd with a shared target queue, an unauthorized client can send a Print-Job to that shared PostScript queue without authentication. The server accepts a page-border value supplied as textWithoutLanguage, preserves an embedded newline through option escaping and reparse, and then reparses the resulting second-line PPD: text as a trusted scheduler control record. A follow-up raw print job can therefore make the server execute an attacker-chosen existing binary such as /usr/bin/vim as lp. At time of publication, there are no publicly available patches.&#xA;CVE-2026-34990:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, a local unprivileged user can coerce cupsd into authenticating to an attacker-controlled localhost IPP service with a reusable Authorization: Local ... token. That token is enough to drive /admin/ requests on localhost, and the attacker can combine CUPS-Create-Local-Printer with printer-is-shared=true to persist a file:///... queue even though the normal FileDevice policy rejects such URIs. Printing to that queue gives an arbitrary root file overwrite; the PoC below uses that primitive to drop a sudoers fragment and demonstrate root command execution. At time of publication, there are no publicly available patches.&#xA;CVE-2026-39314:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, an integer underflow vulnerability in _ppdCreateFromIPP() (cups/ppd-cache.c) allows any unprivileged local user to crash the cupsd root process by supplying a negative job-password-supported IPP attribute. The bounds check only caps the upper bound, so a negative value passes validation, is cast to size_t (wrapping to ~2^64), and is used as the length argument to memset() on a 33-byte stack buffer. This causes an immediate SIGSEGV in the cupsd root process. Combined with systemd&#39;s Restart=on-failure, an attacker can repeat the crash for sustained denial of service.&#xA;CVE-2026-39316:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, a use-after-free vulnerability exists in the CUPS scheduler (cupsd) when temporary printers are automatically deleted. cupsdDeleteTemporaryPrinters() in scheduler/printers.c calls cupsdDeletePrinter() without first expiring subscriptions that reference the printer, leaving cupsd_subscription_t.dest as a dangling pointer to freed heap memory. The dangling pointer is subsequently dereferenced at multiple code sites, causing a crash (denial of service) of the cupsd daemon. With heap grooming, this can be leveraged for code execution.&#xA;CVE-2026-41079:OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to 2.4.17, a network-adjacent attacker can send a crafted SNMP response to the CUPS SNMP backend that causes an out-of-bounds read of up to 176 bytes past a stack buffer. The leaked memory is converted from UTF-16 to UTF-8 and stored as printer supply description strings, which are subsequently visible to authenticated users via IPP Get-Printer-Attributes responses and the CUPS web interface. This vulnerability is fixed in 2.4.17.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="1" name="cups-filesystem" release="20.u12" version="2.4.0">
					<filename>cups-filesystem-2.4.0-20.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-filesystem-2.4.0-20.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="cups-help" release="20.u12" version="2.4.0">
					<filename>cups-help-2.4.0-20.u12.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-help-2.4.0-20.u12.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-client" release="20.u12" version="2.4.0">
					<filename>cups-client-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-client-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-devel" release="20.u12" version="2.4.0">
					<filename>cups-devel-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-devel-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-printerapp" release="20.u12" version="2.4.0">
					<filename>cups-printerapp-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-printerapp-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups" release="20.u12" version="2.4.0">
					<filename>cups-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-libs" release="20.u12" version="2.4.0">
					<filename>cups-libs-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-libs-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-lpd" release="20.u12" version="2.4.0">
					<filename>cups-lpd-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-lpd-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="cups-ipptool" release="20.u12" version="2.4.0">
					<filename>cups-ipptool-2.4.0-20.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/cups-ipptool-2.4.0-20.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-libs" release="20.u12" version="2.4.0">
					<filename>cups-libs-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-libs-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-ipptool" release="20.u12" version="2.4.0">
					<filename>cups-ipptool-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-ipptool-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups" release="20.u12" version="2.4.0">
					<filename>cups-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-lpd" release="20.u12" version="2.4.0">
					<filename>cups-lpd-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-lpd-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-printerapp" release="20.u12" version="2.4.0">
					<filename>cups-printerapp-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-printerapp-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-client" release="20.u12" version="2.4.0">
					<filename>cups-client-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-client-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="cups-devel" release="20.u12" version="2.4.0">
					<filename>cups-devel-2.4.0-20.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/cups-devel-2.4.0-20.u12.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3189</id>
		<title>An update for xz is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34743&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34743" id="CVE-2026-34743" title="CVE-2026-34743" type="cve"></reference>
		</references>
		<description>CVE-2026-34743:XZ Utils provide a general-purpose data-compression library plus command-line tools. Prior to version 5.8.3, if lzma_index_decoder() was used to decode an Index that contained no Records, the resulting lzma_index was left in a state where where a subsequent lzma_index_append() would allocate too little memory, and a buffer overflow would occur. This issue has been patched in version 5.8.3.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="xz" release="5.u2" version="5.2.5">
					<filename>xz-5.2.5-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xz-5.2.5-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xz-lzma-compat" release="5.u2" version="5.2.5">
					<filename>xz-lzma-compat-5.2.5-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xz-lzma-compat-5.2.5-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xz-devel" release="5.u2" version="5.2.5">
					<filename>xz-devel-5.2.5-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xz-devel-5.2.5-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="xz-libs" release="5.u2" version="5.2.5">
					<filename>xz-libs-5.2.5-5.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xz-libs-5.2.5-5.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xz" release="5.u2" version="5.2.5">
					<filename>xz-5.2.5-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/xz-5.2.5-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xz-libs" release="5.u2" version="5.2.5">
					<filename>xz-libs-5.2.5-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/xz-libs-5.2.5-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xz-lzma-compat" release="5.u2" version="5.2.5">
					<filename>xz-lzma-compat-5.2.5-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/xz-lzma-compat-5.2.5-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="xz-devel" release="5.u2" version="5.2.5">
					<filename>xz-devel-5.2.5-5.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/xz-devel-5.2.5-5.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="xz-help" release="5.u2" version="5.2.5">
					<filename>xz-help-5.2.5-5.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/xz-help-5.2.5-5.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3190</id>
		<title>An update for firewalld is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4948&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4948" id="CVE-2026-4948" title="CVE-2026-4948" type="cve"></reference>
		</references>
		<description>CVE-2026-4948:A flaw was found in firewalld. A local unprivileged user can exploit this vulnerability by mis-authorizing two runtime D-Bus (Desktop Bus) setters, setZoneSettings2 and setPolicySettings. This mis-authorization allows the user to modify the runtime firewall state without proper authentication, leading to unauthorized changes in network security configurations.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="firewalld-doc" release="13.u8" version="1.0.2">
					<filename>firewalld-doc-1.0.2-13.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/firewalld-doc-1.0.2-13.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="firewalld-test" release="13.u8" version="1.0.2">
					<filename>firewalld-test-1.0.2-13.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/firewalld-test-1.0.2-13.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-firewall" release="13.u8" version="1.0.2">
					<filename>python3-firewall-1.0.2-13.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-firewall-1.0.2-13.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="firewalld" release="13.u8" version="1.0.2">
					<filename>firewalld-1.0.2-13.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/firewalld-1.0.2-13.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3191</id>
		<title>An update for sleuthkit is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40024&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40024" id="CVE-2026-40024" title="CVE-2026-40024" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40026&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40026" id="CVE-2026-40026" title="CVE-2026-40026" type="cve"></reference>
		</references>
		<description>CVE-2026-40024:The Sleuth Kit through 4.14.0 contains a path traversal vulnerability in tsk_recover that allows an attacker to write files to arbitrary locations outside the intended recovery directory via crafted filenames or directory paths with path traversal sequences in a filesystem image. An attacker can craft a malicious filesystem image with embedded /../ sequences in filenames that, when processed by tsk_recover, writes files outside the output directory, potentially achieving code execution by overwriting shell configuration or cron entries.&#xA;CVE-2026-40026:The Sleuth Kit through 4.14.0 contains an out-of-bounds read vulnerability in the ISO9660 filesystem parser where the parse_susp() function trusts len_id, len_des, and len_src fields from the disk image to memcpy data into a stack buffer without verifying that the source data falls within the parsed SUSP block. An attacker can craft a malicious ISO image that causes reads past the end of the SUSP data buffer, and a zero-length SUSP entry can trigger an infinite parsing loop.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="sleuthkit-devel" release="14.u5" version="4.6.7">
					<filename>sleuthkit-devel-4.6.7-14.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sleuthkit-devel-4.6.7-14.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sleuthkit-help" release="14.u5" version="4.6.7">
					<filename>sleuthkit-help-4.6.7-14.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sleuthkit-help-4.6.7-14.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="sleuthkit" release="14.u5" version="4.6.7">
					<filename>sleuthkit-4.6.7-14.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/sleuthkit-4.6.7-14.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sleuthkit-devel" release="14.u5" version="4.6.7">
					<filename>sleuthkit-devel-4.6.7-14.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sleuthkit-devel-4.6.7-14.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sleuthkit" release="14.u5" version="4.6.7">
					<filename>sleuthkit-4.6.7-14.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sleuthkit-4.6.7-14.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="sleuthkit-help" release="14.u5" version="4.6.7">
					<filename>sleuthkit-help-4.6.7-14.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/sleuthkit-help-4.6.7-14.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3192</id>
		<title>An update for tigervnc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34352&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34352" id="CVE-2026-34352" title="CVE-2026-34352" type="cve"></reference>
		</references>
		<description>CVE-2026-34352:In TigerVNC before 1.16.2, Image.cxx in x0vncserver allows other users to observe or manipulate the screen contents, or cause an application crash, because of incorrect permissions.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="tigervnc" release="10.u4" version="1.12.0">
					<filename>tigervnc-1.12.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/tigervnc-1.12.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tigervnc-server-module" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-module-1.12.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/tigervnc-server-module-1.12.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tigervnc-server" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-1.12.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/tigervnc-server-1.12.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="tigervnc-server-minimal" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-minimal-1.12.0-10.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/tigervnc-server-minimal-1.12.0-10.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tigervnc-help" release="10.u4" version="1.12.0">
					<filename>tigervnc-help-1.12.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-help-1.12.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tigervnc-server-applet" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-applet-1.12.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-server-applet-1.12.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tigervnc-license" release="10.u4" version="1.12.0">
					<filename>tigervnc-license-1.12.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-license-1.12.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="tigervnc-selinux" release="10.u4" version="1.12.0">
					<filename>tigervnc-selinux-1.12.0-10.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-selinux-1.12.0-10.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tigervnc-server-module" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-module-1.12.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-server-module-1.12.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tigervnc-server-minimal" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-minimal-1.12.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-server-minimal-1.12.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tigervnc" release="10.u4" version="1.12.0">
					<filename>tigervnc-1.12.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-1.12.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="tigervnc-server" release="10.u4" version="1.12.0">
					<filename>tigervnc-server-1.12.0-10.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tigervnc-server-1.12.0-10.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3193</id>
		<title>An update for kata-containers is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-65637&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-65637" id="CVE-2025-65637" title="CVE-2025-65637" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24054&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24054" id="CVE-2026-24054" title="CVE-2026-24054" type="cve"></reference>
		</references>
		<description>CVE-2025-65637:A denial-of-service vulnerability exists in github.com/sirupsen/logrus when using Entry.Writer() to log a single-line payload larger than 64KB without newline characters. Due to limitations in the internal bufio.Scanner, the read fails with &#34;token too long&#34; and the writer pipe is closed, leaving Writer() unusable and causing application unavailability (DoS). This affects versions &lt; 1.8.3, 1.9.0, and 1.9.2. The issue is fixed in 1.8.3, 1.9.1, and 1.9.3+, where the input is chunked and the writer continues to function even if an error is logged.&#xA;CVE-2026-24054:Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. In versions prior to 3.26.0, when a container image is malformed or contains no layers, containerd falls back to bind-mounting an empty snapshotter directory for the container rootfs. When the Kata runtime attempts to mount the container rootfs, the bind mount causes the rootfs to be detected as a block device, leading to the underlying device being hotplugged to the guest. This can cause filesystem-level errors on the host due to double inode allocation, and may lead to the host&#39;s block device being mounted as read-only. Version 3.26.0 contains a patch for the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="kata-containers" release="32.u2" version="1.11.1">
					<filename>kata-containers-1.11.1-32.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/kata-containers-1.11.1-32.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="kata-containers" release="32.u2" version="1.11.1">
					<filename>kata-containers-1.11.1-32.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/kata-containers-1.11.1-32.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3194</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42308&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42308" id="CVE-2026-42308" title="CVE-2026-42308" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42310&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42310" id="CVE-2026-42310" title="CVE-2026-42310" type="cve"></reference>
		</references>
		<description>CVE-2026-42308:Pillow is a Python imaging library. Prior to version 12.2.0, if a font advances for each glyph by an exceeding large amount, when Pillow keeps track of the current position, it may lead to an integer overflow. This issue has been patched in version 12.2.0.&#xA;CVE-2026-42310:Pillow is a Python imaging library. From version 4.2.0 to before version 12.2.0, an attacker can supply a malicious PDF that causes the process to hang indefinitely, consuming 100% CPU and making the application unresponsive. This issue has been patched in version 12.2.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python3-pillow-help" release="8.u5" version="9.0.1">
					<filename>python3-pillow-help-9.0.1-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pillow-help-9.0.1-8.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow" release="8.u5" version="9.0.1">
					<filename>python3-pillow-9.0.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-pillow-9.0.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-devel" release="8.u5" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-pillow-devel-9.0.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-tk" release="8.u5" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-pillow-tk-9.0.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-pillow-qt" release="8.u5" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-pillow-qt-9.0.1-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-qt" release="8.u5" version="9.0.1">
					<filename>python3-pillow-qt-9.0.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pillow-qt-9.0.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-tk" release="8.u5" version="9.0.1">
					<filename>python3-pillow-tk-9.0.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pillow-tk-9.0.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow" release="8.u5" version="9.0.1">
					<filename>python3-pillow-9.0.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pillow-9.0.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-pillow-devel" release="8.u5" version="9.0.1">
					<filename>python3-pillow-devel-9.0.1-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pillow-devel-9.0.1-8.u5.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3195</id>
		<title>An update for apache-mina is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41409&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41409" id="CVE-2026-41409" title="CVE-2026-41409" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41635&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41635" id="CVE-2026-41635" title="CVE-2026-41635" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42778&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42778" id="CVE-2026-42778" title="CVE-2026-42778" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42779&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42779" id="CVE-2026-42779" title="CVE-2026-42779" type="cve"></reference>
		</references>
		<description>CVE-2026-41409:The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.&#xA;&#xA;&#xA;&#xA;&#xA;Affected versions are Apache MINA 2.0.0 &lt;= 2.0.27, 2.1.0 &lt;= 2.1.10, and 2.2.0 &lt;= 2.2.5.&#xA;&#xA;&#xA;&#xA;&#xA;The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by &#xA;applying the classname allowlist earlier.&#xA;&#xA;&#xA;&#xA;&#xA;Affected are applications using Apache MINA that call IoBuffer.getObject().&#xA;&#xA;&#xA;&#xA;&#xA;Applications using Apache MINA are advised to upgrade&#xA;CVE-2026-41635:Apache MINA&#39;s AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.&#xA;&#xA;&#xA;&#xA;&#xA;The fix checks if the class is present in the accepted class filter before calling Class.forName(). &#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Affected versions are Apache MINA 2.0.0 &lt;= 2.0.27, 2.1.0 &lt;= 2.1.10, and&#xA;&#xA;&#xA;2.2.0 &lt;= 2.2.5.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by &#xA;applying the classname allowlist earlier.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Affected are applications using Apache MINA that call  IoBuffer.getObject().&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Applications using Apache MINA are advised to upgrade.&#xA;CVE-2026-42778:The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:&#xA;&#xA;&#xA;&#xA;&#xA;The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.&#xA;&#xA;&#xA;&#xA;&#xA;Affected versions are Apache MINA 2.1.0 &lt;= 2.1.11, and 2.2.0 &lt;= 2.2.6.&#xA;&#xA;&#xA;&#xA;&#xA;The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by &#xA;applying the classname allowlist earlier.&#xA;&#xA;&#xA;&#xA;&#xA;Affected are applications using Apache MINA that call IoBuffer.getObject().&#xA;&#xA;&#xA;&#xA;&#xA;Applications using Apache MINA are advised to upgrade&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.&#xA;&#xA;&#xA;&#xA;&#xA;Affected versions are Apache MINA 2.1.0 &lt;= 2.1.110, and 2.2.0 &lt;= 2.2.6.&#xA;&#xA;&#xA;&#xA;&#xA;The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by &#xA;applying the classname allowlist earlier.&#xA;&#xA;&#xA;&#xA;&#xA;Affected are applications using Apache MINA that call IoBuffer.getObject().&#xA;&#xA;&#xA;&#xA;&#xA;Applications using Apache MINA are advised to upgrade&#xA;CVE-2026-42779:The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Apache MINA&#39;s AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.&#xA;&#xA;&#xA;&#xA;&#xA;The fix checks if the class is present in the accepted class filter before calling Class.forName(). &#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Affected versions are Apache MINA 2.1.0 &lt;= 2.1.11, and 2.2.0 &lt;= 2.2.6.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by &#xA;applying the classname allowlist earlier.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Affected are applications using Apache MINA that call  IoBuffer.getObject().&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;Applications using Apache MINA are advised to upgrade.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="apache-mina-mina-statemachine" release="1" version="2.1.12">
					<filename>apache-mina-mina-statemachine-2.1.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/apache-mina-mina-statemachine-2.1.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina" release="1" version="2.1.12">
					<filename>apache-mina-2.1.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/apache-mina-2.1.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-mina-core" release="1" version="2.1.12">
					<filename>apache-mina-mina-core-2.1.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/apache-mina-mina-core-2.1.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-mina-http" release="1" version="2.1.12">
					<filename>apache-mina-mina-http-2.1.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/apache-mina-mina-http-2.1.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-javadoc" release="1" version="2.1.12">
					<filename>apache-mina-javadoc-2.1.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/apache-mina-javadoc-2.1.12-1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="apache-mina-mina-filter-compression" release="1" version="2.1.12">
					<filename>apache-mina-mina-filter-compression-2.1.12-1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/apache-mina-mina-filter-compression-2.1.12-1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3196</id>
		<title>An update for nghttp2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27135&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27135" id="CVE-2026-27135" title="CVE-2026-27135" type="cve"></reference>
		</references>
		<description>CVE-2026-27135:nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="nghttp2-help" release="7.u5" version="1.46.0">
					<filename>nghttp2-help-1.46.0-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nghttp2-help-1.46.0-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2-devel" release="7.u5" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libnghttp2-devel-1.46.0-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nghttp2" release="7.u5" version="1.46.0">
					<filename>nghttp2-1.46.0-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nghttp2-1.46.0-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnghttp2" release="7.u5" version="1.46.0">
					<filename>libnghttp2-1.46.0-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libnghttp2-1.46.0-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nghttp2" release="7.u5" version="1.46.0">
					<filename>nghttp2-1.46.0-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nghttp2-1.46.0-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2-devel" release="7.u5" version="1.46.0">
					<filename>libnghttp2-devel-1.46.0-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libnghttp2-devel-1.46.0-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnghttp2" release="7.u5" version="1.46.0">
					<filename>libnghttp2-1.46.0-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libnghttp2-1.46.0-7.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3197</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-68160&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-68160" id="CVE-2025-68160" title="CVE-2025-68160" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69418&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69418" id="CVE-2025-69418" title="CVE-2025-69418" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69419" id="CVE-2025-69419" title="CVE-2025-69419" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69420" id="CVE-2025-69420" title="CVE-2025-69420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69421&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69421" id="CVE-2025-69421" title="CVE-2025-69421" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22795&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22795" id="CVE-2026-22795" title="CVE-2026-22795" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22796&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22796" id="CVE-2026-22796" title="CVE-2026-22796" type="cve"></reference>
		</references>
		<description>CVE-2025-68160:Issue summary: Writing large, newline-free data into a BIO chain using the&#xA;line-buffering filter where the next BIO performs short writes can trigger&#xA;a heap-based out-of-bounds write.&#xA;&#xA;Impact summary: This out-of-bounds write can cause memory corruption which&#xA;typically results in a crash, leading to Denial of Service for an application.&#xA;&#xA;The line-buffering BIO filter (BIO_f_linebuffer) is not used by default in&#xA;TLS/SSL data paths. In OpenSSL command-line applications, it is typically&#xA;only pushed onto stdout/stderr on VMS systems. Third-party applications that&#xA;explicitly use this filter with a BIO chain that can short-write and that&#xA;write large, newline-free data influenced by an attacker would be affected.&#xA;However, the circumstances where this could happen are unlikely to be under&#xA;attacker control, and BIO_f_linebuffer is unlikely to be handling non-curated&#xA;data controlled by an attacker. For that reason the issue was assessed as&#xA;Low severity.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the BIO implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.&#xA;CVE-2025-69418:Issue summary: When using the low-level OCB API directly with AES-NI or&lt;br&gt;other hardware-accelerated code paths, inputs whose length is not a multiple&lt;br&gt;of 16 bytes can leave the final partial block unencrypted and unauthenticated.&lt;br&gt;&lt;br&gt;Impact summary: The trailing 1-15 bytes of a message may be exposed in&lt;br&gt;cleartext on encryption and are not covered by the authentication tag,&lt;br&gt;allowing an attacker to read or tamper with those bytes without detection.&lt;br&gt;&lt;br&gt;The low-level OCB encrypt and decrypt routines in the hardware-accelerated&lt;br&gt;stream path process full 16-byte blocks but do not advance the input/output&lt;br&gt;pointers. The subsequent tail-handling code then operates on the original&lt;br&gt;base pointers, effectively reprocessing the beginning of the buffer while&lt;br&gt;leaving the actual trailing bytes unprocessed. The authentication checksum&lt;br&gt;also excludes the true tail bytes.&lt;br&gt;&lt;br&gt;However, typical OpenSSL consumers using EVP are not affected because the&lt;br&gt;higher-level EVP and provider OCB implementations split inputs so that full&lt;br&gt;blocks and trailing partial blocks are processed in separate calls, avoiding&lt;br&gt;the problematic code path. Additionally, TLS does not use OCB ciphersuites.&lt;br&gt;The vulnerability only affects applications that call the low-level&lt;br&gt;CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with&lt;br&gt;non-block-aligned lengths in a single call on hardware-accelerated builds.&lt;br&gt;For these reasons the issue was assessed as Low severity.&lt;br&gt;&lt;br&gt;The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected&lt;br&gt;by this issue, as OCB mode is not a FIPS-approved algorithm.&lt;br&gt;&lt;br&gt;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&lt;br&gt;&lt;br&gt;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2025-69419:Issue summary: Calling PKCS12_get_friendlyname() function on a maliciously&#xA;crafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containing&#xA;non-ASCII BMP code point can trigger a one byte write before the allocated&#xA;buffer.&#xA;&#xA;Impact summary: The out-of-bounds write can cause a memory corruption&#xA;which can have various consequences including a Denial of Service.&#xA;&#xA;The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12&#xA;BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,&#xA;the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16&#xA;source byte count as the destination buffer capacity to UTF8_putc(). For BMP&#xA;code points above U+07FF, UTF-8 requires three bytes, but the forwarded&#xA;capacity can be just two bytes. UTF8_putc() then returns -1, and this negative&#xA;value is added to the output length without validation, causing the&#xA;length to become negative. The subsequent trailing NUL byte is then written&#xA;at a negative offset, causing write outside of heap allocated buffer.&#xA;&#xA;The vulnerability is reachable via the public PKCS12_get_friendlyname() API&#xA;when parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses a&#xA;different code path that avoids this issue, PKCS12_get_friendlyname() directly&#xA;invokes the vulnerable function. Exploitation requires an attacker to provide&#xA;a malicious PKCS#12 file to be parsed by the application and the attacker&#xA;can just trigger a one zero byte write before the allocated buffer.&#xA;For that reason the issue was assessed as Low severity according to our&#xA;Security Policy.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&#xA;&#xA;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2025-69420:Issue summary: A type confusion vulnerability exists in the TimeStamp Response&#xA;verification code where an ASN1_TYPE union member is accessed without first&#xA;validating the type, causing an invalid or NULL pointer dereference when&#xA;processing a malformed TimeStamp Response file.&#xA;&#xA;Impact summary: An application calling TS_RESP_verify_response() with a&#xA;malformed TimeStamp Response can be caused to dereference an invalid or&#xA;NULL pointer when reading, resulting in a Denial of Service.&#xA;&#xA;The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()&#xA;access the signing cert attribute value without validating its type.&#xA;When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memory&#xA;through the ASN1_TYPE union, causing a crash.&#xA;&#xA;Exploiting this vulnerability requires an attacker to provide a malformed&#xA;TimeStamp Response to an application that verifies timestamp responses. The&#xA;TimeStamp protocol (RFC 3161) is not widely used and the impact of the&#xA;exploit is just a Denial of Service. For these reasons the issue was&#xA;assessed as Low severity.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the TimeStamp Response implementation is outside the OpenSSL FIPS module&#xA;boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&#xA;&#xA;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2025-69421:Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer&#xA;dereference in the PKCS12_item_decrypt_d2i_ex() function.&#xA;&#xA;Impact summary: A NULL pointer dereference can trigger a crash which leads to&#xA;Denial of Service for an application processing PKCS#12 files.&#xA;&#xA;The PKCS12_item_decrypt_d2i_ex() function does not check whether the oct&#xA;parameter is NULL before dereferencing it. When called from&#xA;PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can&#xA;be NULL, causing a crash. The vulnerability is limited to Denial of Service&#xA;and cannot be escalated to achieve code execution or memory disclosure.&#xA;&#xA;Exploiting this issue requires an attacker to provide a malformed PKCS#12 file&#xA;to an application that processes it. For that reason the issue was assessed as&#xA;Low severity according to our Security Policy.&#xA;&#xA;The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.&#xA;CVE-2026-22795:Issue summary: An invalid or NULL pointer dereference can happen in&#xA;an application processing a malformed PKCS#12 file.&#xA;&#xA;Impact summary: An application processing a malformed PKCS#12 file can be&#xA;caused to dereference an invalid or NULL pointer on memory read, resulting&#xA;in a Denial of Service.&#xA;&#xA;A type confusion vulnerability exists in PKCS#12 parsing code where&#xA;an ASN1_TYPE union member is accessed without first validating the type,&#xA;causing an invalid pointer read.&#xA;&#xA;The location is constrained to a 1-byte address space, meaning any&#xA;attempted pointer manipulation can only target addresses between 0x00 and 0xFF.&#xA;This range corresponds to the zero page, which is unmapped on most modern&#xA;operating systems and will reliably result in a crash, leading only to a&#xA;Denial of Service. Exploiting this issue also requires a user or application&#xA;to process a maliciously crafted PKCS#12 file. It is uncommon to accept&#xA;untrusted PKCS#12 files in applications as they are usually used to store&#xA;private keys which are trusted by definition. For these reasons, the issue&#xA;was assessed as Low severity.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.&#xA;&#xA;OpenSSL 1.0.2 is not affected by this issue.&#xA;CVE-2026-22796:Issue summary: A type confusion vulnerability exists in the signature&#xA;verification of signed PKCS#7 data where an ASN1_TYPE union member is&#xA;accessed without first validating the type, causing an invalid or NULL&#xA;pointer dereference when processing malformed PKCS#7 data.&#xA;&#xA;Impact summary: An application performing signature verification of PKCS#7&#xA;data or calling directly the PKCS7_digest_from_attributes() function can be&#xA;caused to dereference an invalid or NULL pointer when reading, resulting in&#xA;a Denial of Service.&#xA;&#xA;The function PKCS7_digest_from_attributes() accesses the message digest attribute&#xA;value without validating its type. When the type is not V_ASN1_OCTET_STRING,&#xA;this results in accessing invalid memory through the ASN1_TYPE union, causing&#xA;a crash.&#xA;&#xA;Exploiting this vulnerability requires an attacker to provide a malformed&#xA;signed PKCS#7 to an application that verifies it. The impact of the&#xA;exploit is just a Denial of Service, the PKCS7 API is legacy and applications&#xA;should be using the CMS API instead. For these reasons the issue was&#xA;assessed as Low severity.&#xA;&#xA;The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,&#xA;as the PKCS#7 parsing implementation is outside the OpenSSL FIPS module&#xA;boundary.&#xA;&#xA;OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="30.u21" version="202011">
					<filename>edk2-devel-202011-30.u21.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/edk2-devel-202011-30.u21.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="30.u21" version="202011">
					<filename>edk2-devel-202011-30.u21.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/edk2-devel-202011-30.u21.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="30.u21" version="202011">
					<filename>edk2-help-202011-30.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/edk2-help-202011-30.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-aarch64" release="30.u21" version="202011">
					<filename>edk2-aarch64-202011-30.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/edk2-aarch64-202011-30.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="30.u21" version="202011">
					<filename>python3-edk2-devel-202011-30.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-edk2-devel-202011-30.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="30.u21" version="202011">
					<filename>edk2-ovmf-202011-30.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/edk2-ovmf-202011-30.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3198</id>
		<title>An update for dovecot is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59031&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59031" id="CVE-2025-59031" title="CVE-2025-59031" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-59032&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-59032" id="CVE-2025-59032" title="CVE-2025-59032" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-0394&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-0394" id="CVE-2026-0394" title="CVE-2026-0394" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27855&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27855" id="CVE-2026-27855" title="CVE-2026-27855" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27856&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27856" id="CVE-2026-27856" title="CVE-2026-27856" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27857&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27857" id="CVE-2026-27857" title="CVE-2026-27857" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27858&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27858" id="CVE-2026-27858" title="CVE-2026-27858" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27859&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27859" id="CVE-2026-27859" title="CVE-2026-27859" type="cve"></reference>
		</references>
		<description>CVE-2025-59031:Dovecot has provided a script to use for attachment to text conversion. This script unsafely handles zip-style attachments. Attacker can use specially crafted OOXML documents to cause unintended files on the system to be indexed and subsequently ending up in FTS indexes. Do not use the provided script, instead, use something else like FTS tika. No publicly available exploits are known.&#xA;CVE-2025-59032:ManageSieve AUTHENTICATE command crashes when using literal as SASL initial response. This can be used to crash ManageSieve service repeatedly, making it unavailable for other users. Control access to ManageSieve port, or disable the service if it&#39;s not needed. Alternatively upgrade to a fixed version. No publicly available exploits are known.&#xA;CVE-2026-0394:When dovecot has been configured to use per-domain passwd files, and they are placed one path component above /etc, or slash has been added to allowed characters, path traversal can happen if the domain component is directory partial. This allows inadvertently reading /etc/passwd (or some other path which ends with passwd). If this file contains passwords, it can be used to authenticate wrongly, or if this is userdb, it can unexpectly make system users appear valid users.  Upgrade to fixed version, or use different authentication scheme that does not rely on paths. Alternatively you can also ensure that the per-domain passwd files are in some other location, such as /etc/dovecot/auth/%d. No publicly available exploits are known.&#xA;CVE-2026-27855:Dovecot OTP authentication is vulnerable to replay attack under specific conditions. If auth cache is enabled, and username is altered in passdb, then OTP credentials can be cached so that same OTP reply is valid. An attacker able to observe an OTP exchange is able to log in as the user. If authentication happens over unsecure connection, switch to SCRAM protocol. Alternatively ensure the communcations are secured, and if possible switch to OAUTH2 or SCRAM. No publicly available exploits are known.&#xA;CVE-2026-27856:Doveadm credentials are verified using direct comparison which is susceptible to timing oracle attack. An attacker can use this to determine the configured credentials. Figuring out the credential will lead into full access to the affected component. Limit access to the doveadm http service port, install fixed version. No publicly available exploits are known.&#xA;CVE-2026-27857:Sending &#34;NOOP (((...)))&#34; command with 4000 parenthesis open+close results in ~1MB extra memory usage. Longer commands will result in client disconnection. This 1 MB can be left allocated for longer time periods by not sending the command ending LF. So attacker could connect possibly from even a single IP and create 1000 connections to allocate 1 GB of memory, which would likely result in reaching VSZ limit and killing the process and its other proxied connections. Attacker could connect possibly from even a single IP and create 1000 connections to allocate 1 GB of memory, which would likely result in reaching VSZ limit and killing the process and its other proxied connections. Install fixed version, there is no other remediation. No publicly available exploits are known.&#xA;CVE-2026-27858:Attacker can send a specifically crafted message before authentication that causes managesieve to allocate large amount of memory.&#xA; Attacker can force managesieve-login to be unavailable by repeatedly crashing the process. Protect access to managesieve protocol, or install fixed version. No publicly available exploits are known.&#xA;CVE-2026-27859:A mail message containing excessive amount of RFC 2231 MIME parameters causes LMTP to use too much CPU. A suitably formatted mail message causes mail delivery process to consume large amounts of CPU time. Use MTA capabilities to limit RFC 2231 MIME parameters in mail messages, or upgrade to fixed version where the processing is limited. No publicly available exploits are known.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="1" name="dovecot-help" release="7.u2" version="2.3.15">
					<filename>dovecot-help-2.3.15-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/dovecot-help-2.3.15-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dovecot-devel" release="7.u2" version="2.3.15">
					<filename>dovecot-devel-2.3.15-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/dovecot-devel-2.3.15-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="dovecot" release="7.u2" version="2.3.15">
					<filename>dovecot-2.3.15-7.u2.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/dovecot-2.3.15-7.u2.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot-help" release="7.u2" version="2.3.15">
					<filename>dovecot-help-2.3.15-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/dovecot-help-2.3.15-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot" release="7.u2" version="2.3.15">
					<filename>dovecot-2.3.15-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/dovecot-2.3.15-7.u2.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot-devel" release="7.u2" version="2.3.15">
					<filename>dovecot-devel-2.3.15-7.u2.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/dovecot-devel-2.3.15-7.u2.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3199</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-52885&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-52885" id="CVE-2025-52885" title="CVE-2025-52885" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36024&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-36024" id="CVE-2020-36024" title="CVE-2020-36024" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43903&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-43903" id="CVE-2025-43903" title="CVE-2025-43903" type="cve"></reference>
		</references>
		<description>CVE-2025-52885:Poppler ia a library for rendering PDF files, and examining or modifying their structure. A use-after-free (write) vulnerability has been detected in versions Poppler prior to 25.10.0 within the StructTreeRoot class. The issue arises from the use of raw pointers to elements of a `std::vector`, which can lead to dangling pointers when the vector is resized. The vulnerability stems from the way that refToParentMap stores references to `std::vector` elements using raw pointers. These pointers may become invalid when the vector is resized. This vulnerability is a common security problem involving the use of raw pointers to `std::vectors`. Internally, `std::vector `stores its elements in a dynamically allocated array. When the array reaches its capacity and a new element is added, the vector reallocates a larger block of memory and moves all the existing elements to the new location. At this point if any pointers to elements are stored before a resize occurs, they become dangling pointers once the reallocation happens. Version 25.10.0 contains a patch for the issue.&#xA;CVE-2020-36024:An issue was discovered in freedesktop poppler version 20.12.1, allows remote attackers to cause a denial of service (DoS) via crafted .pdf file to FoFiType1C::convertToType1 function.&#xA;CVE-2025-43903:NSSCryptoSignBackend.cc in Poppler before 25.04.0 does not verify the adbe.pkcs7.sha1 signatures on documents, resulting in potential signature forgeries.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="17.u14" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-glib-devel-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="17.u14" version="0.90.0">
					<filename>poppler-cpp-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-cpp-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="17.u14" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-cpp-devel-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="17.u14" version="0.90.0">
					<filename>poppler-devel-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-devel-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="17.u14" version="0.90.0">
					<filename>poppler-glib-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-glib-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="17.u14" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-qt5-devel-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="17.u14" version="0.90.0">
					<filename>poppler-utils-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-utils-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="17.u14" version="0.90.0">
					<filename>poppler-qt5-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-qt5-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="poppler" release="17.u14" version="0.90.0">
					<filename>poppler-0.90.0-17.u14.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-0.90.0-17.u14.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="17.u14" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-17.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-glib-doc-0.90.0-17.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="17.u14" version="0.90.0">
					<filename>poppler-help-0.90.0-17.u14.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/poppler-help-0.90.0-17.u14.fos23.noarch.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="17.u14" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-qt5-devel-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="17.u14" version="0.90.0">
					<filename>poppler-utils-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-utils-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="17.u14" version="0.90.0">
					<filename>poppler-devel-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-devel-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="17.u14" version="0.90.0">
					<filename>poppler-cpp-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-cpp-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="17.u14" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-glib-devel-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="17.u14" version="0.90.0">
					<filename>poppler-qt5-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-qt5-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="17.u14" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-cpp-devel-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="17.u14" version="0.90.0">
					<filename>poppler-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="17.u14" version="0.90.0">
					<filename>poppler-glib-0.90.0-17.u14.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/poppler-glib-0.90.0-17.u14.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3200</id>
		<title>An update for pyOpenSSL is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27448&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27448" id="CVE-2026-27448" title="CVE-2026-27448" type="cve"></reference>
		</references>
		<description>CVE-2026-27448:pyOpenSSL is a Python wrapper around the OpenSSL library. Starting in version 0.14.0 and prior to version 26.0.0, if a user provided callback to `set_tlsext_servername_callback` raised an unhandled exception, this would result in a connection being accepted. If a user was relying on this callback for any security-sensitive behavior, this could allow bypassing it. Starting in version 26.0.0, unhandled exceptions now result in rejecting the connection.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="pyOpenSSL-help" release="3.u1" version="21.0.0">
					<filename>pyOpenSSL-help-21.0.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/pyOpenSSL-help-21.0.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-pyOpenSSL" release="3.u1" version="21.0.0">
					<filename>python3-pyOpenSSL-21.0.0-3.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-pyOpenSSL-21.0.0-3.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3201</id>
		<title>An update for openjdk-11 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66293&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66293" id="CVE-2025-66293" title="CVE-2025-66293" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-22695&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-22695" id="CVE-2026-22695" title="CVE-2026-22695" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25646&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25646" id="CVE-2026-25646" title="CVE-2026-25646" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27171&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27171" id="CVE-2026-27171" title="CVE-2026-27171" type="cve"></reference>
		</references>
		<description>CVE-2025-66293:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng&#39;s simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng&#39;s internal state management. Upgrade to libpng 1.6.52 or later.&#xA;CVE-2026-22695:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function png_image_finish_read when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.&#xA;CVE-2026-25646:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.55, an out-of-bounds read vulnerability exists in the png_set_quantize() API function. When the function is called with no histogram and the number of colors in the palette is more than twice the maximum supported by the user&#39;s display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer. The images that trigger this vulnerability are valid per the PNG specification. This vulnerability is fixed in 1.6.55.&#xA;CVE-2026-27171:zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-headless-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-headless-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-src-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-src-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-headless-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-headless-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-javadoc-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-javadoc-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-javadoc-zip-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-javadoc-zip-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-jmods-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-jmods-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-devel-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-devel-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-jmods-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-src-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-src-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-devel-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-devel-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-demo-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-demo-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-demo-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-11-openjdk-demo-slowdebug-11.0.30.7-4.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-demo-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-demo-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-jmods-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-jmods-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-src-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-src-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-demo-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-demo-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-src-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-src-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-headless-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-headless-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-javadoc-zip-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-javadoc-zip-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-javadoc-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-javadoc-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-jmods-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-devel-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-devel-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-headless-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-headless-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-slowdebug-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="4.u4" version="11.0.30.7">
					<filename>java-11-openjdk-devel-11.0.30.7-4.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-11-openjdk-devel-11.0.30.7-4.u4.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3202</id>
		<title>An update for systemd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29111&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29111" id="CVE-2026-29111" title="CVE-2026-29111" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40226&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40226" id="CVE-2026-40226" title="CVE-2026-40226" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40225&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40225" id="CVE-2026-40225" title="CVE-2026-40225" type="cve"></reference>
		</references>
		<description>CVE-2026-29111:systemd, a system and service manager, (as PID 1) hits an assert and freezes execution when an unprivileged IPC API call is made with spurious data. On version v249 and older the effect is not an assert, but stack overwriting, with the attacker controlled content. From version v250 and newer this is not possible as the safety check causes an assert instead. This IPC call was added in v239, so versions older than that are not affected. Versions 260-rc1, 259.2, 258.5, and 257.11 contain patches. No known workarounds are available.&#xA;CVE-2026-40226:In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.&#xA;CVE-2026-40225:In udev in systemd before 260, local root execution can occur via malicious hardware devices and unsanitized kernel output.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="systemd-cryptsetup" release="106.u24" version="249">
					<filename>systemd-cryptsetup-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-cryptsetup-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-devel" release="106.u24" version="249">
					<filename>systemd-devel-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-devel-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-networkd" release="106.u24" version="249">
					<filename>systemd-networkd-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-networkd-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-pam" release="106.u24" version="249">
					<filename>systemd-pam-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-pam-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="106.u24" version="249">
					<filename>systemd-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-resolved" release="106.u24" version="249">
					<filename>systemd-resolved-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-resolved-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-udev" release="106.u24" version="249">
					<filename>systemd-udev-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-udev-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-nspawn" release="106.u24" version="249">
					<filename>systemd-nspawn-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-nspawn-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-timesyncd" release="106.u24" version="249">
					<filename>systemd-timesyncd-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-timesyncd-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-libs" release="106.u24" version="249">
					<filename>systemd-libs-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-libs-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="systemd-container" release="106.u24" version="249">
					<filename>systemd-container-249-106.u24.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/systemd-container-249-106.u24.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-pam" release="106.u24" version="249">
					<filename>systemd-pam-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-pam-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-cryptsetup" release="106.u24" version="249">
					<filename>systemd-cryptsetup-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-cryptsetup-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-devel" release="106.u24" version="249">
					<filename>systemd-devel-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-devel-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-container" release="106.u24" version="249">
					<filename>systemd-container-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-container-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-libs" release="106.u24" version="249">
					<filename>systemd-libs-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-libs-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-resolved" release="106.u24" version="249">
					<filename>systemd-resolved-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-resolved-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-udev" release="106.u24" version="249">
					<filename>systemd-udev-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-udev-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd" release="106.u24" version="249">
					<filename>systemd-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-nspawn" release="106.u24" version="249">
					<filename>systemd-nspawn-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-nspawn-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-networkd" release="106.u24" version="249">
					<filename>systemd-networkd-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-networkd-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="systemd-timesyncd" release="106.u24" version="249">
					<filename>systemd-timesyncd-249-106.u24.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-timesyncd-249-106.u24.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="systemd-help" release="106.u24" version="249">
					<filename>systemd-help-249-106.u24.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/systemd-help-249-106.u24.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3203</id>
		<title>An update for uboot-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33243&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33243" id="CVE-2026-33243" title="CVE-2026-33243" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42040&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-42040" id="CVE-2024-42040" title="CVE-2024-42040" type="cve"></reference>
		</references>
		<description>CVE-2026-33243:barebox is a bootloader. In barebox from version 2016.03.0 to before version 2026.03.1 (and the corresponding backport to 2025.09.3), an attacker could exploit a FIT signature verification vulnerability to trick the bootloader into booting different images than those that were verified as part of a signed configuration. mkimage(1) sets the hashed-nodes property of the FIT signature node to list which nodes of the FIT were hashed as part of the signing process as these will need to be verified later on by the bootloader. However, hashed-nodes itself is not part of the hash and could therefore be modified to allow booting different images than those that have been verified. This issue has been patched in barebox versions 2026.03.1 and backported to 2025.09.3.&#xA;CVE-2024-42040:Buffer Overflow vulnerability in the net/bootp.c in DENEX U-Boot from its initial commit in 2002 (3861aa5) up to today on any platform allows an attacker on the local network to leak memory from four up to 32 bytes of memory stored behind the packet to the network depending on the later use of DHCP-provided parameters via crafted DHCP responses.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="uboot-images-elf" release="12.u5" version="2021.10">
					<filename>uboot-images-elf-2021.10-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/uboot-images-elf-2021.10-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-tools" release="12.u5" version="2021.10">
					<filename>uboot-tools-2021.10-12.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/uboot-tools-2021.10-12.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="uboot-tools" release="12.u5" version="2021.10">
					<filename>uboot-tools-2021.10-12.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uboot-tools-2021.10-12.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uboot-images-armv8" release="12.u5" version="2021.10">
					<filename>uboot-images-armv8-2021.10-12.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uboot-images-armv8-2021.10-12.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="uboot-tools-help" release="12.u5" version="2021.10">
					<filename>uboot-tools-help-2021.10-12.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/uboot-tools-help-2021.10-12.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3204</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28417&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28417" id="CVE-2026-28417" title="CVE-2026-28417" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28418&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28418" id="CVE-2026-28418" title="CVE-2026-28418" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28419&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28419" id="CVE-2026-28419" title="CVE-2026-28419" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28420&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28420" id="CVE-2026-28420" title="CVE-2026-28420" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28421&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28421" id="CVE-2026-28421" title="CVE-2026-28421" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28422&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28422" id="CVE-2026-28422" title="CVE-2026-28422" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33412&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33412" id="CVE-2026-33412" title="CVE-2026-33412" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34982&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34982" id="CVE-2026-34982" title="CVE-2026-34982" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-39881&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-39881" id="CVE-2026-39881" title="CVE-2026-39881" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35177&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35177" id="CVE-2026-35177" title="CVE-2026-35177" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41411&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41411" id="CVE-2026-41411" title="CVE-2026-41411" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42307&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42307" id="CVE-2026-42307" title="CVE-2026-42307" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45130&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45130" id="CVE-2026-45130" title="CVE-2026-45130" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46483&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46483" id="CVE-2026-46483" title="CVE-2026-46483" type="cve"></reference>
		</references>
		<description>CVE-2026-28417:Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.&#xA;CVE-2026-28418:Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim&#39;s Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.&#xA;CVE-2026-28419:Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim&#39;s Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.&#xA;CVE-2026-28420:Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim&#39;s terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.&#xA;CVE-2026-28421:Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim&#39;s swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.&#xA;CVE-2026-28422:Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.&#xA;CVE-2026-33412:Vim is an open source, command line text editor. Prior to version 9.2.0202, a command injection vulnerability exists in Vim&#39;s glob() function on Unix-like systems. By including a newline character (\n) in a pattern passed to glob(), an attacker may be able to execute arbitrary shell commands. This vulnerability depends on the user&#39;s &#39;shell&#39; setting. This issue has been patched in version 9.2.0202.&#xA;CVE-2026-34982:Vim is an open source, command line text editor. Prior to version 9.2.0276, a modeline sandbox bypass in Vim allows arbitrary OS command execution when a user opens a crafted file. The `complete`, `guitabtooltip` and `printheader` options are missing the `P_MLE` flag, allowing a modeline to be executed. Additionally, the `mapset()` function lacks a `check_secure()` call, allowing it to be abused from sandboxed expressions. Commit 9.2.0276 fixes the issue.&#xA;CVE-2026-39881:Vim is an open source, command line text editor. Prior to 9.2.0316, a command injection vulnerability in Vim&#39;s netbeans interface allows a malicious netbeans server to execute arbitrary Ex commands when Vim connects to it, via unsanitized strings in the defineAnnoType and specialKeys protocol messages. This vulnerability is fixed in 9.2.0316.&#xA;CVE-2026-35177:Vim is an open source, command line text editor. Prior to 9.2.0280, a path traversal bypass in Vim&#39;s zip.vim plugin allows overwriting of arbitrary files when opening specially crafted zip archives, circumventing the previous fix for CVE-2025-53906. This vulnerability is fixed in 9.2.0280.&#xA;CVE-2026-41411:Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim&#39;s tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.&#xA;CVE-2026-42307:Vim is an open source, command line text editor. Prior to version 9.2.0383, an OS command injection vulnerability exists in the netrw standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the sftp:// or file:// protocol handlers), an attacker can execute arbitrary shell commands with the privileges of the Vim process. This issue has been patched in version 9.2.0383.&#xA;CVE-2026-45130:Vim is an open source, command line text editor. Prior to version 9.2.0450, a heap buffer overflow exists in read_compound() in src/spellfile.c when loading a crafted spell file (.spl) with UTF-8 encoding active. An attacker-controlled length field in the spell file&#39;s compound section overflows a 32-bit signed integer multiplication, causing a small buffer to be allocated for a write loop that runs many iterations, overflowing the heap. Because the &#39;spelllang&#39; option can be set from a modeline, a text file modeline can trigger spell file loading if a malicious .spl file has been planted on the runtimepath. This issue has been patched in version 9.2.0450.&#xA;CVE-2026-46483:Vim is an open source, command line text editor. Prior to 9.2.0479, a command injection vulnerability exists in tar#Vimuntar() in&#xA;runtime/autoload/tar.vim when decompressing .tgz archives on Unix-like systems. The function builds :!gunzip and :!gzip -d commands using shellescape(tartail) without the {special} flag, allowing a crafted archive filename to trigger Vim cmdline-special expansion and execute shell commands in the user&#39;s context. This vulnerability is fixed in 9.2.0479.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="2" name="vim-X11" release="48.u27" version="9.0">
					<filename>vim-X11-9.0-48.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/vim-X11-9.0-48.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-common" release="48.u27" version="9.0">
					<filename>vim-common-9.0-48.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/vim-common-9.0-48.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-enhanced" release="48.u27" version="9.0">
					<filename>vim-enhanced-9.0-48.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/vim-enhanced-9.0-48.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="2" name="vim-minimal" release="48.u27" version="9.0">
					<filename>vim-minimal-9.0-48.u27.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/vim-minimal-9.0-48.u27.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-enhanced" release="48.u27" version="9.0">
					<filename>vim-enhanced-9.0-48.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/vim-enhanced-9.0-48.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-minimal" release="48.u27" version="9.0">
					<filename>vim-minimal-9.0-48.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/vim-minimal-9.0-48.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-X11" release="48.u27" version="9.0">
					<filename>vim-X11-9.0-48.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/vim-X11-9.0-48.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="2" name="vim-common" release="48.u27" version="9.0">
					<filename>vim-common-9.0-48.u27.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/vim-common-9.0-48.u27.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="2" name="vim-filesystem" release="48.u27" version="9.0">
					<filename>vim-filesystem-9.0-48.u27.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/vim-filesystem-9.0-48.u27.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3205</id>
		<title>An update for gegl04 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2049&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2049" id="CVE-2026-2049" title="CVE-2026-2049" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-2050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-2050" id="CVE-2026-2050" title="CVE-2026-2050" type="cve"></reference>
		</references>
		<description>CVE-2026-2049:GEGL provides infrastructure to do demand based cached non destructive image editing on larger than RAM buffers. Through babl, it provides support for a wide range of color models and pixel storage formats for input and output.&#xA;CVE-2026-2050:A vulnerability was found in GIMP (Image Processing Software) (version unknown). It has been rated as critical.Using CWE to declare the problem leads to CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().Impacted is confidentiality, integrity, and availability.Upgrading eliminates this vulnerability.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="gegl04" release="2.u1" version="0.4.34">
					<filename>gegl04-0.4.34-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gegl04-0.4.34-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gegl04-devel" release="2.u1" version="0.4.34">
					<filename>gegl04-devel-0.4.34-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gegl04-devel-0.4.34-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libgegl-0_4-0" release="2.u1" version="0.4.34">
					<filename>libgegl-0_4-0-0.4.34-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libgegl-0_4-0-0.4.34-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gegl04" release="2.u1" version="0.4.34">
					<filename>gegl04-0.4.34-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gegl04-0.4.34-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libgegl-0_4-0" release="2.u1" version="0.4.34">
					<filename>libgegl-0_4-0-0.4.34-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libgegl-0_4-0-0.4.34-2.u1.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gegl04-devel" release="2.u1" version="0.4.34">
					<filename>gegl04-devel-0.4.34-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gegl04-devel-0.4.34-2.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3206</id>
		<title>An update for c3p0 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-27830&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-27830" id="CVE-2026-27830" title="CVE-2026-27830" type="cve"></reference>
		</references>
		<description>CVE-2026-27830:c3p0, a JDBC Connection pooling library, is vulnerable to attack via maliciously crafted Java-serialized objects and `javax.naming.Reference` instances. Several c3p0 `ConnectionPoolDataSource` implementations have a property called `userOverridesAsString` which conceptually represents a `Map&lt;String,Map&lt;String,String&gt;&gt;`. Prior to v0.12.0, that property was maintained as a hex-encoded serialized object. Any attacker able to reset this property, on an existing `ConnectionPoolDataSource` or via maliciously crafted serialized objects or `javax.naming.Reference` instances could be tailored execute unexpected code on the application&#39;s `CLASSPATH`. The danger of this vulnerability was strongly magnified by vulnerabilities in c3p0&#39;s main dependency, mchange-commons-java. This library includes code that mirrors early implementations of JNDI functionality, including ungated support for remote `factoryClassLocation` values. Attackers could set c3p0&#39;s `userOverridesAsString` hex-encoded serialized objects that include objects &#34;indirectly serialized&#34; via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. Although hazard presented by c3p0&#39;s vulnerabilites are exarcerbated by vulnerabilities in mchange-commons-java, use of Java-serialized-object hex as the format for a writable Java-Bean property, of objects that may be exposed across JNDI interfaces, represents a serious independent fragility. The `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` classes has been reimplemented to use a safe CSV-based format, rather than rely upon potentially dangerous Java object deserialization. c3p0-0.12.0+ and above depend upon mchange-commons-java 0.4.0+, which gates support for remote `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="c3p0" release="4.u2" version="0.9.5.4">
					<filename>c3p0-0.9.5.4-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/c3p0-0.9.5.4-4.u2.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="c3p0-help" release="4.u2" version="0.9.5.4">
					<filename>c3p0-help-0.9.5.4-4.u2.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/c3p0-help-0.9.5.4-4.u2.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3207</id>
		<title>An update for gstreamer1-plugins-good is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-1940&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-1940" id="CVE-2026-1940" title="CVE-2026-1940" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3083&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3083" id="CVE-2026-3083" title="CVE-2026-3083" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3085&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3085" id="CVE-2026-3085" title="CVE-2026-3085" type="cve"></reference>
		</references>
		<description>CVE-2026-1940:An incomplete fix for CVE-2024-47778 allows an out-of-bounds read in gst_wavparse_adtl_chunk() function. The patch added a size validation check lsize + 8 &gt; size, but it does not account for the GST_ROUND_UP_2(lsize) used in the actual offset calculation. When lsize is an odd number, the parser advances more bytes than validated, causing OOB read.&#xA;CVE-2026-3083:GStreamer rtpqdm2depay Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.&#xA;&#xA;The specific flaw exists within the processing of X-QDM RTP payload elements. When parsing the packetid element, the process does not properly validate user-supplied data, which can result in a write past the end of an allocated array. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28850.&#xA;CVE-2026-3085:GStreamer rtpqdm2depay Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.&#xA;&#xA;The specific flaw exists within the processing of X-QDM RTP payloads. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28851.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good-gtk" release="12.u7" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-12.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gstreamer1-plugins-good-gtk-1.16.2-12.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-good" release="12.u7" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-12.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gstreamer1-plugins-good-1.16.2-12.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good" release="12.u7" version="1.16.2">
					<filename>gstreamer1-plugins-good-1.16.2-12.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gstreamer1-plugins-good-1.16.2-12.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-good-gtk" release="12.u7" version="1.16.2">
					<filename>gstreamer1-plugins-good-gtk-1.16.2-12.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/gstreamer1-plugins-good-gtk-1.16.2-12.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-good-help" release="12.u7" version="1.16.2">
					<filename>gstreamer1-plugins-good-help-1.16.2-12.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gstreamer1-plugins-good-help-1.16.2-12.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3208</id>
		<title>An update for ncurses is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-69720&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-69720" id="CVE-2025-69720" title="CVE-2025-69720" type="cve"></reference>
		</references>
		<description>CVE-2025-69720:The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="ncurses-static" release="17.u7" version="6.3">
					<filename>ncurses-static-6.3-17.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-static-6.3-17.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-compat-libs" release="17.u7" version="6.3">
					<filename>ncurses-compat-libs-6.3-17.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-compat-libs-6.3-17.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-libs" release="17.u7" version="6.3">
					<filename>ncurses-libs-6.3-17.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-libs-6.3-17.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses" release="17.u7" version="6.3">
					<filename>ncurses-6.3-17.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-6.3-17.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-devel" release="17.u7" version="6.3">
					<filename>ncurses-devel-6.3-17.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-devel-6.3-17.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ncurses-help" release="17.u7" version="6.3">
					<filename>ncurses-help-6.3-17.u7.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-help-6.3-17.u7.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses" release="17.u7" version="6.3">
					<filename>ncurses-6.3-17.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ncurses-6.3-17.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-help" release="17.u7" version="6.3">
					<filename>ncurses-help-6.3-17.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ncurses-help-6.3-17.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-static" release="17.u7" version="6.3">
					<filename>ncurses-static-6.3-17.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ncurses-static-6.3-17.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-devel" release="17.u7" version="6.3">
					<filename>ncurses-devel-6.3-17.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ncurses-devel-6.3-17.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-libs" release="17.u7" version="6.3">
					<filename>ncurses-libs-6.3-17.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ncurses-libs-6.3-17.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ncurses-compat-libs" release="17.u7" version="6.3">
					<filename>ncurses-compat-libs-6.3-17.u7.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ncurses-compat-libs-6.3-17.u7.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="ncurses-base" release="17.u7" version="6.3">
					<filename>ncurses-base-6.3-17.u7.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ncurses-base-6.3-17.u7.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3209</id>
		<title>An update for polkit is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4897&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4897" id="CVE-2026-4897" title="CVE-2026-4897" type="cve"></reference>
		</references>
		<description>CVE-2026-4897:A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="polkit-help" release="12.u4" version="0.120">
					<filename>polkit-help-0.120-12.u4.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/polkit-help-0.120-12.u4.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="polkit" release="12.u4" version="0.120">
					<filename>polkit-0.120-12.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/polkit-0.120-12.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="polkit-devel" release="12.u4" version="0.120">
					<filename>polkit-devel-0.120-12.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/polkit-devel-0.120-12.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="polkit-libs" release="12.u4" version="0.120">
					<filename>polkit-libs-0.120-12.u4.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/polkit-libs-0.120-12.u4.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="polkit" release="12.u4" version="0.120">
					<filename>polkit-0.120-12.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/polkit-0.120-12.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="polkit-libs" release="12.u4" version="0.120">
					<filename>polkit-libs-0.120-12.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/polkit-libs-0.120-12.u4.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="polkit-devel" release="12.u4" version="0.120">
					<filename>polkit-devel-0.120-12.u4.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/polkit-devel-0.120-12.u4.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3210</id>
		<title>An update for llvm is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7883&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-7883" id="CVE-2024-7883" title="CVE-2024-7883" type="cve"></reference>
		</references>
		<description>CVE-2024-7883:When using Arm Cortex-M Security Extensions (CMSE), Secure stack &#xA;contents can be leaked to Non-secure state via floating-point registers &#xA;when a Secure to Non-secure function call is made that returns a &#xA;floating-point value and when this is the first use of floating-point &#xA;since entering Secure state. This allows an attacker to read a limited &#xA;quantity of Secure stack contents with an impact on confidentiality. &#xA;This issue is specific to code generated using LLVM-based compilers.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="llvm" release="8.u3" version="12.0.1">
					<filename>llvm-12.0.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/llvm-12.0.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="llvm-devel" release="8.u3" version="12.0.1">
					<filename>llvm-devel-12.0.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/llvm-devel-12.0.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="llvm-libs" release="8.u3" version="12.0.1">
					<filename>llvm-libs-12.0.1-8.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/llvm-libs-12.0.1-8.u3.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="llvm-help" release="8.u3" version="12.0.1">
					<filename>llvm-help-12.0.1-8.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/llvm-help-12.0.1-8.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="llvm-libs" release="8.u3" version="12.0.1">
					<filename>llvm-libs-12.0.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/llvm-libs-12.0.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="llvm-devel" release="8.u3" version="12.0.1">
					<filename>llvm-devel-12.0.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/llvm-devel-12.0.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="llvm" release="8.u3" version="12.0.1">
					<filename>llvm-12.0.1-8.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/llvm-12.0.1-8.u3.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3211</id>
		<title>An update for python-tornado is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-31958&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-31958" id="CVE-2026-31958" title="CVE-2026-31958" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-35536&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-35536" id="CVE-2026-35536" title="CVE-2026-35536" type="cve"></reference>
		</references>
		<description>CVE-2026-31958:Tornado is a Python web framework and asynchronous networking library. In versions of Tornado prior to 6.5.5, the only limit on the number of parts in multipart/form-data is the max_body_size setting (default 100MB). Since parsing occurs synchronously on the main thread, this creates the possibility of denial-of-service due to the cost of parsing very large multipart bodies with many parts. This vulnerability is fixed in 6.5.5.&#xA;CVE-2026-35536:In Tornado before 6.5.5, cookie attribute injection could occur because the domain, path, and samesite arguments to .RequestHandler.set_cookie were not checked for crafted characters.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="python-tornado-help" release="7.u6" version="6.1">
					<filename>python-tornado-help-6.1-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-tornado-help-6.1-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-tornado" release="7.u6" version="6.1">
					<filename>python3-tornado-6.1-7.u6.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-tornado-6.1-7.u6.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-tornado" release="7.u6" version="6.1">
					<filename>python3-tornado-6.1-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-tornado-6.1-7.u6.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python-tornado-help" release="7.u6" version="6.1">
					<filename>python-tornado-help-6.1-7.u6.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python-tornado-help-6.1-7.u6.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3212</id>
		<title>An update for ImageMagick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30931&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30931" id="CVE-2026-30931" title="CVE-2026-30931" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30936&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30936" id="CVE-2026-30936" title="CVE-2026-30936" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30937&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30937" id="CVE-2026-30937" title="CVE-2026-30937" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28494&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28494" id="CVE-2026-28494" title="CVE-2026-28494" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28688&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28688" id="CVE-2026-28688" title="CVE-2026-28688" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28689&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28689" id="CVE-2026-28689" title="CVE-2026-28689" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28690&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28690" id="CVE-2026-28690" title="CVE-2026-28690" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28691" id="CVE-2026-28691" title="CVE-2026-28691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28692&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28692" id="CVE-2026-28692" title="CVE-2026-28692" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28493&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28493" id="CVE-2026-28493" title="CVE-2026-28493" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30883&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30883" id="CVE-2026-30883" title="CVE-2026-30883" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30935" id="CVE-2026-30935" title="CVE-2026-30935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28693&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28693" id="CVE-2026-28693" title="CVE-2026-28693" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28686&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28686" id="CVE-2026-28686" title="CVE-2026-28686" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-28687&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-28687" id="CVE-2026-28687" title="CVE-2026-28687" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30929&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30929" id="CVE-2026-30929" title="CVE-2026-30929" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32259&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32259" id="CVE-2026-32259" title="CVE-2026-32259" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-30935&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-30935" id="CVE-2026-30935" title="CVE-2026-30935" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32636&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32636" id="CVE-2026-32636" title="CVE-2026-32636" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40312&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40312" id="CVE-2026-40312" title="CVE-2026-40312" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40311&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40311" id="CVE-2026-40311" title="CVE-2026-40311" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40310&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40310" id="CVE-2026-40310" title="CVE-2026-40310" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40183&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40183" id="CVE-2026-40183" title="CVE-2026-40183" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-40169&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-40169" id="CVE-2026-40169" title="CVE-2026-40169" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34238&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34238" id="CVE-2026-34238" title="CVE-2026-34238" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33908&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33908" id="CVE-2026-33908" title="CVE-2026-33908" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33905&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33905" id="CVE-2026-33905" title="CVE-2026-33905" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33902&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33902" id="CVE-2026-33902" title="CVE-2026-33902" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33901&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33901" id="CVE-2026-33901" title="CVE-2026-33901" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33900&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33900" id="CVE-2026-33900" title="CVE-2026-33900" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33899&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33899" id="CVE-2026-33899" title="CVE-2026-33899" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42050&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42050" id="CVE-2026-42050" title="CVE-2026-42050" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46521&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46521" id="CVE-2026-46521" title="CVE-2026-46521" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46520&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46520" id="CVE-2026-46520" title="CVE-2026-46520" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46522&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46522" id="CVE-2026-46522" title="CVE-2026-46522" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46559&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46559" id="CVE-2026-46559" title="CVE-2026-46559" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46557&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46557" id="CVE-2026-46557" title="CVE-2026-46557" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-46523&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-46523" id="CVE-2026-46523" title="CVE-2026-46523" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42326&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42326" id="CVE-2026-42326" title="CVE-2026-42326" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45358&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45358" id="CVE-2026-45358" title="CVE-2026-45358" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45664&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45664" id="CVE-2026-45664" title="CVE-2026-45664" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45031&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45031" id="CVE-2026-45031" title="CVE-2026-45031" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45359&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45359" id="CVE-2026-45359" title="CVE-2026-45359" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-45624&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-45624" id="CVE-2026-45624" title="CVE-2026-45624" type="cve"></reference>
		</references>
		<description>CVE-2026-30931:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16, a heap-based buffer overflow in the UHDR encoder can happen due to truncation of a value and it would allow an out of bounds write. This vulnerability is fixed in 7.1.2-16.&#xA;CVE-2026-30936:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a crafted image could cause an out of bounds heap write inside the WaveletDenoiseImage method. When processing a crafted image with the -wavelet-denoise operation an out of bounds write can occur. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-30937:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a 32-bit unsigned integer overflow in the XWD (X Windows) encoder can cause an undersized heap buffer allocation. When writing a extremely large image an out of bounds heap write can occur. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28494:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a stack buffer overflow exists in ImageMagick&#39;s morphology kernel parsing functions. User-controlled kernel strings exceeding a buffer are copied into fixed-size stack buffers via memcpy without bounds checking, resulting in stack corruption. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28688:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a heap-use-after-free vulnerability exists in the MSL encoder, where a cloned image is destroyed twice. The MSL coder does not support writing MSL so the write capability has been removed. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28689:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, domain=&#34;path&#34; authorization is checked before final file open/use. A symlink swap between check-time and use-time bypasses policy-denied read/write. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28690:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a stack buffer overflow vulnerability exists in the MNG encoder. There is a bounds checks missing that could corrupting the stack with attacker-controlled data. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28691:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, an uninitialized pointer dereference vulnerability exists in the JBIG decoder due to a missing check. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28692:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, MAT decoder uses 32-bit arithmetic due to incorrect parenthesization resulting in a heap over-read. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28493:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16, an integer overflow vulnerability exists in the SIXEL decoer. The vulnerability allows an attacker to perform an out of bounds via a specially crafted image. This vulnerability is fixed in 7.1.2-16.&#xA;CVE-2026-30883:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, an extremely large image profile could result in a heap overflow when encoding a PNG image. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-30935:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16, BilateralBlurImage contains a heap buffer over-read caused by an incorrect conversion. When processing a crafted image with the -bilateral-blur operation an out of bounds read can occur. This vulnerability is fixed in 7.1.2-16.&#xA;CVE-2026-28693:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, an integer overflow in DIB coder can result in out of bounds read or write. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28686:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, A heap-buffer-overflow vulnerability exists in the PCL encode due to an undersized output buffer allocation. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-28687:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a heap use-after-free vulnerability in ImageMagick&#39;s MSL decoder allows an attacker to trigger access to freed memory by crafting an MSL file. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-30929:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, MagnifyImage uses a fixed-size stack buffer. When using a specific image it is possible to overflow this buffer and corrupt the stack. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-32259:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-16 and 6.9.13-41, when a memory allocation fails in the sixel encoder it would be possible to write past the end of a buffer on the stack. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41.&#xA;CVE-2026-30935:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16, BilateralBlurImage contains a heap buffer over-read caused by an incorrect conversion. When processing a crafted image with the -bilateral-blur operation an out of bounds read can occur. This vulnerability is fixed in 7.1.2-16.&#xA;CVE-2026-32636:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-17 and 6.9.13-42, the NewXMLTree method contains a bug that could result in a crash due to an out of write bounds of a single zero byte. Versions 7.1.2-17 and 6.9.13-42 fix the issue.&#xA;CVE-2026-40312:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-19, an off by one error in the MSL decoder could result in a crash when a malicous MSL file is read. This issue has been fixed in version 7.1.2-19.&#xA;CVE-2026-40311:ImageMagick is free and open-source software used for editing and manipulating digital images. Versions below 7.1.2-19 and 6.9.13-44 contain a heap use-after-free vulnerability that can cause a crash when reading and printing values from an invalid XMP profile. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-40310:ImageMagick is free and open-source software used for editing and manipulating digital images. Versions below both 7.1.2-19 and 6.9.13-44, contain a heap out-of-bounds write in the JP2 encoder with when a user specifies an invalid sampling index. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-40183:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-19, the JXL encoder has an heap write overflow when a user specifies that the image should be encoded as 16 bit floats. This issue has been fixed in version 7.1.2-19.&#xA;CVE-2026-40169:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-19, a crafted image could result in an out of bounds heap write when writing a yaml or json output, resulting in a crash. This issue has been fixed in version 7.1.2-19.&#xA;CVE-2026-34238:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, an integer overflow in the despeckle operation causes a heap buffer overflow on 32-bit builds that will result in an out of bounds write. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-33908:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, Magick frees the memory of the XML tree via the `DestroyXMLTree()` function; however, this process is executed recursively with no depth limit imposed. When Magick processes an XML file with deeply nested structures, it will exhaust the stack memory, resulting in a Denial of Service (DoS) attack. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-33905:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, the -sample operation has an out of bounds read when an specific offset is set through the `sample:offset` define that could lead to an out of bounds read. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-33902:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, a stack overflow vulnerability in ImageMagick&#39;s FX expression parser allows an attacker to crash the process by providing a deeply nested expression. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-33901:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, a heap buffer overflow occurs in the MVG decoder that could result in an out of bounds write when processing a crafted image. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-33900:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, the viff encoder contains an integer truncation/wraparound issue on 32-bit builds that could trigger an out of bounds heap write, potentially causing a crash. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-33899:ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-189 and 6.9.13-44, when `Magick` parses an XML file it is possible that a single zero byte is written out of the bounds. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.&#xA;CVE-2026-42050:ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-21 and 6.9.13-46, a malicious MIFF file could trigger an overflow when a user opens it in the display tool and right-clicks a tile to invoke the Load / Update menu item. This vulnerability is fixed in 7.1.2-21 and 6.9.13-46.&#xA;CVE-2026-46521:When using LZMA compression in the MIFF encoder an out of bounds write can occur due to a missing check.&#xA;CVE-2026-46520:When reading multiple images with different dimensions an out of bounds heap write can occur.&#xA;CVE-2026-46522:Due to a missing check in the MIFF decoder a crafted file could cause an infinite loop resulting in CPU exhaustion.&#xA;CVE-2026-46559:An incorrect check in the JP2 will result in an heap buffer over-write of a single byte when specifying certain options.&#xA;CVE-2026-46557:Due to a missing depth check a stack overflow can occur in the fx operation by passing a crafted argument.&#xA;CVE-2026-46523:A crafted MSL image can trigger a heap-use-after-free.&#xA;CVE-2026-42326:When writing an IPTC output file a malicious input file could cause an out of bounds read of a single byte.&#xA;CVE-2026-45358:An of by one in the meta encoder could result in an out of bounds read of a single byte in the meta encoder.&#xA;CVE-2026-45664:Because of a missing check in the MNG coder it would be possible to read more images than the list limit policy would allow resulting in excessive resource use.&#xA;CVE-2026-45031:Due to a missing check in the PSD decoder it would be possible to bypass the list-length resource policy when decoding a PSD image. Other security limits would still apply.&#xA;CVE-2026-45359:An invalid connected-components:keep-top value could result in a heap buffer over-read when performing the connected components operation.&#xA;CVE-2026-45624:When performing a polynomial distortion an out of bounds over-read of 24 bytes can occur when specifying specific arguments.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="1" name="ImageMagick-perl" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-perl-7.1.2.23-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ImageMagick-perl-7.1.2.23-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-7.1.2.23-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ImageMagick-7.1.2.23-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-c++-7.1.2.23-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ImageMagick-c++-7.1.2.23-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-devel" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-devel-7.1.2.23-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ImageMagick-devel-7.1.2.23-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="ImageMagick-c++-devel" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-c++-devel-7.1.2.23-1.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ImageMagick-c++-devel-7.1.2.23-1.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="ImageMagick-help" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-help-7.1.2.23-1.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ImageMagick-help-7.1.2.23-1.u10.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-perl" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-perl-7.1.2.23-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ImageMagick-perl-7.1.2.23-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-c++-7.1.2.23-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ImageMagick-c++-7.1.2.23-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-devel" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-devel-7.1.2.23-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ImageMagick-devel-7.1.2.23-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-7.1.2.23-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ImageMagick-7.1.2.23-1.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="ImageMagick-c++-devel" release="1.u10" version="7.1.2.23">
					<filename>ImageMagick-c++-devel-7.1.2.23-1.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ImageMagick-c++-devel-7.1.2.23-1.u10.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3213</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-3731&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-3731" id="CVE-2026-3731" title="CVE-2026-3731" type="cve"></reference>
		</references>
		<description>CVE-2026-3731:A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftp_extensions_get_name/sftp_extensions_get_data of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="libssh" release="16.u10" version="0.9.6">
					<filename>libssh-0.9.6-16.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libssh-0.9.6-16.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libssh-devel" release="16.u10" version="0.9.6">
					<filename>libssh-devel-0.9.6-16.u10.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libssh-devel-0.9.6-16.u10.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh" release="16.u10" version="0.9.6">
					<filename>libssh-0.9.6-16.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libssh-0.9.6-16.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libssh-devel" release="16.u10" version="0.9.6">
					<filename>libssh-devel-0.9.6-16.u10.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libssh-devel-0.9.6-16.u10.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="libssh-help" release="16.u10" version="0.9.6">
					<filename>libssh-help-0.9.6-16.u10.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libssh-help-0.9.6-16.u10.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3214</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3549&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3549" id="CVE-2025-3549" title="CVE-2025-3549" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5165&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5165" id="CVE-2025-5165" title="CVE-2025-5165" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5168&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5168" id="CVE-2025-5168" title="CVE-2025-5168" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3548&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3548" id="CVE-2025-3548" title="CVE-2025-3548" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2752&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2752" id="CVE-2025-2752" title="CVE-2025-2752" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2754&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2754" id="CVE-2025-2754" title="CVE-2025-2754" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2755&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2755" id="CVE-2025-2755" title="CVE-2025-2755" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2756&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2756" id="CVE-2025-2756" title="CVE-2025-2756" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5200&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5200" id="CVE-2025-5200" title="CVE-2025-5200" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5201&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5201" id="CVE-2025-5201" title="CVE-2025-5201" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5202&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5202" id="CVE-2025-5202" title="CVE-2025-5202" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5203&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5203" id="CVE-2025-5203" title="CVE-2025-5203" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5204&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-5204" id="CVE-2025-5204" title="CVE-2025-5204" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-48424&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2024-48424" id="CVE-2024-48424" title="CVE-2024-48424" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2751&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2751" id="CVE-2025-2751" title="CVE-2025-2751" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2750&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-2750" id="CVE-2025-2750" title="CVE-2025-2750" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3196&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3196" id="CVE-2025-3196" title="CVE-2025-3196" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3158&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-3158" id="CVE-2025-3158" title="CVE-2025-3158" type="cve"></reference>
		</references>
		<description>CVE-2025-3549:A vulnerability, which was classified as critical, was found in Open Asset Import Library Assimp 5.4.3. Affected is the function Assimp::MD3Importer::ValidateSurfaceHeaderOffsets of the file code/AssetLib/MD3/MD3Loader.cpp of the component File Handler. The manipulation leads to heap-based buffer overflow. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-5165:A vulnerability was found in Open Asset Import Library Assimp 5.4.3 and classified as problematic. This issue affects the function MDCImporter::ValidateSurfaceHeader of the file assimp/code/AssetLib/MDC/MDCLoader.cpp. The manipulation of the argument pcSurface2 leads to out-of-bounds read. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2025-5168:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been rated as problematic. Affected by this issue is the function MDLImporter::ImportUVCoordinate_3DGS_MDL345 of the file assimp/code/AssetLib/MDL/MDLLoader.cpp. The manipulation of the argument iIndex leads to out-of-bounds read. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2025-3548:A vulnerability, which was classified as critical, has been found in Open Asset Import Library Assimp up to 5.4.3. This issue affects the function aiString::Set in the library include/assimp/types.h of the component File Handler. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.&#xA;CVE-2025-2752:A vulnerability was found in Open Asset Import Library Assimp 5.4.3 and classified as problematic. This issue affects the function fast_atoreal_move in the library include/assimp/fast_atof.h of the component CSM File Handler. The manipulation leads to out-of-bounds read. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2754:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been declared as critical. Affected by this vulnerability is the function Assimp::AC3DImporter::ConvertObjectSection of the file code/AssetLib/AC/ACLoader.cpp of the component AC3D File Handler. The manipulation of the argument it leads to heap-based buffer overflow. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2755:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been rated as critical. Affected by this issue is the function Assimp::AC3DImporter::ConvertObjectSection of the file code/AssetLib/AC/ACLoader.cpp of the component AC3D File Handler. The manipulation of the argument src.entries leads to out-of-bounds read. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2756:A vulnerability classified as critical has been found in Open Asset Import Library Assimp 5.4.3. This affects the function Assimp::AC3DImporter::ConvertObjectSection of the file code/AssetLib/AC/ACLoader.cpp of the component AC3D File Handler. The manipulation of the argument tmp leads to heap-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-5200:A vulnerability was found in Open Asset Import Library Assimp 5.4.3 and classified as problematic. This issue affects the function MDLImporter::InternReadFile_Quake1 of the file assimp/code/AssetLib/MDL/MDLLoader.cpp. The manipulation leads to out-of-bounds read. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2025-5201:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been classified as problematic. Affected is the function LWOImporter::CountVertsAndFacesLWO2 of the file assimp/code/AssetLib/LWO/LWOLoader.cpp. The manipulation leads to out-of-bounds read. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2025-5202:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been declared as problematic. Affected by this vulnerability is the function HL1MDLLoader::validate_header of the file assimp/code/AssetLib/MDL/HalfLife/HL1MDLLoader.cpp. The manipulation leads to out-of-bounds read. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2025-5203:A vulnerability was found in Open Asset Import Library Assimp 5.4.3. It has been rated as problematic. Affected by this issue is the function SkipSpaces in the library assimp/include/assimp/ParsingUtils.h. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2025-5204:A vulnerability classified as problematic has been found in Open Asset Import Library Assimp 5.4.3. This affects the function MDLImporter::ParseSkinLump_3DGS_MDL7 of the file assimp/code/AssetLib/MDL/MDLMaterialLoader.cpp. The manipulation leads to out-of-bounds read. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The project decided to collect all Fuzzer bugs in a main-issue to address them in the future.&#xA;CVE-2024-48424:A heap-buffer-overflow vulnerability has been identified in the OpenDDLParser::parseStructure function within the Assimp library, specifically during the processing of OpenGEX files.&#xA;CVE-2025-2751:A vulnerability has been found in Open Asset Import Library Assimp 5.4.3 and classified as problematic. This vulnerability affects the function Assimp::CSMImporter::InternReadFile of the file code/AssetLib/CSM/CSMLoader.cpp of the component CSM File Handler. The manipulation of the argument na leads to out-of-bounds read. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-2750:A vulnerability, which was classified as critical, was found in Open Asset Import Library Assimp 5.4.3. This affects the function Assimp::CSMImporter::InternReadFile of the file code/AssetLib/CSM/CSMLoader.cpp of the component CSM File Handler. The manipulation leads to out-of-bounds write. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.&#xA;CVE-2025-3196:A vulnerability, which was classified as critical, was found in Open Asset Import Library Assimp 5.4.3. Affected is the function Assimp::MD2Importer::InternReadFile in the library code/AssetLib/MD2/MD2Loader.cpp of the component Malformed File Handler. The manipulation of the argument Name leads to stack-based buffer overflow. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. It is recommended to upgrade the affected component.&#xA;CVE-2025-3158:A vulnerability, which was classified as critical, has been found in Open Asset Import Library Assimp 5.4.3. Affected by this issue is the function Assimp::LWO::AnimResolver::UpdateAnimRangeSetup of the file code/AssetLib/LWO/LWOAnimation.cpp of the component LWO File Handler. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="assimp" release="18.u8" version="5.2.4">
					<filename>assimp-5.2.4-18.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/assimp-5.2.4-18.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="18.u8" version="5.2.4">
					<filename>assimp-devel-5.2.4-18.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/assimp-devel-5.2.4-18.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="18.u8" version="5.2.4">
					<filename>assimp-devel-5.2.4-18.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/assimp-devel-5.2.4-18.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="assimp" release="18.u8" version="5.2.4">
					<filename>assimp-5.2.4-18.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/assimp-5.2.4-18.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="assimp-help" release="18.u8" version="5.2.4">
					<filename>assimp-help-5.2.4-18.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/assimp-help-5.2.4-18.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python3-assimp" release="18.u8" version="5.2.4">
					<filename>python3-assimp-5.2.4-18.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-assimp-5.2.4-18.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3215</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22017&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22017" id="CVE-2020-22017" title="CVE-2020-22017" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-20451&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-20451" id="CVE-2020-20451" title="CVE-2020-20451" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22029&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22029" id="CVE-2020-22029" title="CVE-2020-22029" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22025&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22025" id="CVE-2020-22025" title="CVE-2020-22025" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22030&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22030" id="CVE-2020-22030" title="CVE-2020-22030" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-20450&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-20450" id="CVE-2020-20450" title="CVE-2020-20450" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22022&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22022" id="CVE-2020-22022" title="CVE-2020-22022" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22015&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22015" id="CVE-2020-22015" title="CVE-2020-22015" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-20446&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-20446" id="CVE-2020-20446" title="CVE-2020-20446" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-20445&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-20445" id="CVE-2020-20445" title="CVE-2020-20445" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-20453&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-20453" id="CVE-2020-20453" title="CVE-2020-20453" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22027&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22027" id="CVE-2020-22027" title="CVE-2020-22027" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22034&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2020-22034" id="CVE-2020-22034" title="CVE-2020-22034" type="cve"></reference>
		</references>
		<description>CVE-2020-22017:A heap-based Buffer Overflow vulnerability exists in FFmpeg 4.2 at ff_fill_rectangle in libavfilter/drawutils.c, which might lead to memory corruption and other potential consequences.&#xA;CVE-2020-20451:Denial of Service issue in FFmpeg 4.2 due to resource management errors via fftools/cmdutils.c.&#xA;CVE-2020-22029:A heap-based Buffer Overflow vulnerability exists in FFmpeg 4.2 at libavfilter/vf_colorconstancy.c: in slice_get_derivative, which crossfade_samples_fltp, which might lead to memory corruption and other potential consequences.&#xA;CVE-2020-22025:A heap-based Buffer Overflow vulnerability exists in gaussian_blur at libavfilter/vf_edgedetect.c, which might lead to memory corruption and other potential consequences.&#xA;CVE-2020-22030:A heap-based Buffer Overflow vulnerability exists in FFmpeg 4.2 at libavfilter/af_afade.c in crossfade_samples_fltp, which might lead to memory corruption and other potential consequences.&#xA;CVE-2020-20450:FFmpeg 4.2 is affected by null pointer dereference passed as argument to libavformat/aviobuf.c, which could cause a Denial of Service.&#xA;CVE-2020-22022:A heap-based Buffer Overflow vulnerability exists in FFmpeg 4.2 in filter_frame at libavfilter/vf_fieldorder.c, which might lead to memory corruption and other potential consequences.&#xA;CVE-2020-22015:Buffer Overflow vulnerability in FFmpeg 4.2 in mov_write_video_tag due to the out of bounds in libavformat/movenc.c, which could let a remote malicious user obtain sensitive information, cause a Denial of Service, or execute arbitrary code.&#xA;CVE-2020-20446:FFmpeg 4.2 is affected by a Divide By Zero issue via libavcodec/aacpsy.c, which allows a remote malicious user to cause a Denial of Service.&#xA;CVE-2020-20445:FFmpeg 4.2 is affected by a Divide By Zero issue via libavcodec/lpc.h, which allows a remote malicious user to cause a Denial of Service.&#xA;CVE-2020-20453:FFmpeg 4.2 is affected by a Divide By Zero issue via libavcodec/aaccoder, which allows a remote malicious user to cause a Denial of Service&#xA;CVE-2020-22027:A heap-based Buffer Overflow vulnerability exits in FFmpeg 4.2 in deflate16 at libavfilter/vf_neighbor.c, which might lead to memory corruption and other potential consequences.&#xA;CVE-2020-22034:A heap-based Buffer Overflow vulnerability exists FFmpeg 4.2 at libavfilter/vf_floodfill.c, which might lead to memory corruption and other potential consequences.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="37.u9" version="4.2.4">
					<filename>ffmpeg-4.2.4-37.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ffmpeg-4.2.4-37.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="37.u9" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-37.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ffmpeg-devel-4.2.4-37.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="37.u9" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-37.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/ffmpeg-libs-4.2.4-37.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="37.u9" version="4.2.4">
					<filename>libavdevice-4.2.4-37.u9.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libavdevice-4.2.4-37.u9.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="37.u9" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-37.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ffmpeg-libs-4.2.4-37.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="37.u9" version="4.2.4">
					<filename>libavdevice-4.2.4-37.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libavdevice-4.2.4-37.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="37.u9" version="4.2.4">
					<filename>ffmpeg-4.2.4-37.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ffmpeg-4.2.4-37.u9.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="37.u9" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-37.u9.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/ffmpeg-devel-4.2.4-37.u9.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3216</id>
		<title>An update for python-click is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-7246&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-7246" id="CVE-2026-7246" title="CVE-2026-7246" type="cve"></reference>
		</references>
		<description>CVE-2026-7246:Pallets Click, versions 8.3.2 and below, contain a command injection vulnerability in the click.edit() function, allowing attackers to pass arbitrary OS commands from an unprivileged account.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python3-click" release="2.u1" version="8.0.4">
					<filename>python3-click-8.0.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-click-8.0.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="python-click-help" release="2.u1" version="8.0.4">
					<filename>python-click-help-8.0.4-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-click-help-8.0.4-2.u1.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3217</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-4046&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-4046" id="CVE-2026-4046" title="CVE-2026-4046" type="cve"></reference>
		</references>
		<description>CVE-2026-4046:The iconv() function in the GNU C Library versions 2.43 and earlier may crash due to an assertion failure when converting inputs from the IBM1390 or IBM1399 character sets, which may be used to remotely crash an application.&#xA;&#xA;&#xA;&#xA;This vulnerability can be trivially mitigated by removing the IBM1390 and IBM1399 character sets from systems that do not need them.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="glibc-common" release="175.u35" version="2.34">
					<filename>glibc-common-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-common-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-compat-2.17" release="175.u35" version="2.34">
					<filename>glibc-compat-2.17-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-compat-2.17-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-archive" release="175.u35" version="2.34">
					<filename>glibc-locale-archive-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-locale-archive-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-nss-devel" release="175.u35" version="2.34">
					<filename>glibc-nss-devel-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-nss-devel-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nscd" release="175.u35" version="2.34">
					<filename>nscd-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nscd-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="nss_modules" release="175.u35" version="2.34">
					<filename>nss_modules-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/nss_modules-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-devel" release="175.u35" version="2.34">
					<filename>glibc-devel-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-devel-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-locale-source" release="175.u35" version="2.34">
					<filename>glibc-locale-source-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-locale-source-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-all-langpacks" release="175.u35" version="2.34">
					<filename>glibc-all-langpacks-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-all-langpacks-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc-debugutils" release="175.u35" version="2.34">
					<filename>glibc-debugutils-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-debugutils-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="libnsl" release="175.u35" version="2.34">
					<filename>libnsl-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/libnsl-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="glibc" release="175.u35" version="2.34">
					<filename>glibc-2.34-175.u35.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/glibc-2.34-175.u35.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="glibc-help" release="175.u35" version="2.34">
					<filename>glibc-help-2.34-175.u35.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-help-2.34-175.u35.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-all-langpacks" release="175.u35" version="2.34">
					<filename>glibc-all-langpacks-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-all-langpacks-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-debugutils" release="175.u35" version="2.34">
					<filename>glibc-debugutils-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-debugutils-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-devel" release="175.u35" version="2.34">
					<filename>glibc-devel-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-devel-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="libnsl" release="175.u35" version="2.34">
					<filename>libnsl-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/libnsl-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nscd" release="175.u35" version="2.34">
					<filename>nscd-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nscd-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc" release="175.u35" version="2.34">
					<filename>glibc-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-archive" release="175.u35" version="2.34">
					<filename>glibc-locale-archive-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-locale-archive-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-locale-source" release="175.u35" version="2.34">
					<filename>glibc-locale-source-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-locale-source-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="nss_modules" release="175.u35" version="2.34">
					<filename>nss_modules-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/nss_modules-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-common" release="175.u35" version="2.34">
					<filename>glibc-common-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-common-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-compat-2.17" release="175.u35" version="2.34">
					<filename>glibc-compat-2.17-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-compat-2.17-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="glibc-nss-devel" release="175.u35" version="2.34">
					<filename>glibc-nss-devel-2.34-175.u35.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/glibc-nss-devel-2.34-175.u35.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3218</id>
		<title>An update for rubygem-bcrypt is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33306&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33306" id="CVE-2026-33306" title="CVE-2026-33306" type="cve"></reference>
		</references>
		<description>CVE-2026-33306:bcrypt-ruby is a Ruby binding for the OpenBSD bcrypt() password hashing algorithm. Prior to version 3.1.22, an integer overflow in the Java BCrypt implementation for JRuby can cause zero iterations in the strengthening loop.  Impacted applications must be setting the cost to 31 to see this happen. The JRuby implementation of bcrypt-ruby (`BCrypt.java`) computes the key-strengthening round count as a signed 32-bit integer. When `cost=31` (the maximum allowed by the gem), signed integer overflow causes the round count to become negative, and the strengthening loop executes **zero iterations**. This collapses bcrypt from 2^31 rounds of exponential key-strengthening to effectively constant-time computation — only the initial EksBlowfish key setup and final 64x encryption phase remain. The resulting hash looks valid (`$2a$31$...`) and verifies correctly via `checkpw`, making the weakness invisible to the application. This issue is triggered only when cost=31 is used or when verifying a `$2a$31$` hash. This problem has been fixed in version 3.1.22. As a workaround, set the cost to something less than 31.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="rubygem-bcrypt" release="2.u1" version="3.1.12">
					<filename>rubygem-bcrypt-3.1.12-2.u1.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/rubygem-bcrypt-3.1.12-2.u1.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-bcrypt-help" release="2.u1" version="3.1.12">
					<filename>rubygem-bcrypt-help-3.1.12-2.u1.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/rubygem-bcrypt-help-3.1.12-2.u1.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bcrypt" release="2.u1" version="3.1.12">
					<filename>rubygem-bcrypt-3.1.12-2.u1.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/rubygem-bcrypt-3.1.12-2.u1.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3219</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24733&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24733" id="CVE-2026-24733" title="CVE-2026-24733" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24734&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24734" id="CVE-2026-24734" title="CVE-2026-24734" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66614&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66614" id="CVE-2025-66614" title="CVE-2025-66614" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-24880&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-24880" id="CVE-2026-24880" title="CVE-2026-24880" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-25854&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-25854" id="CVE-2026-25854" title="CVE-2026-25854" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29129&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29129" id="CVE-2026-29129" title="CVE-2026-29129" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29145&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29145" id="CVE-2026-29145" title="CVE-2026-29145" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-29146&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-29146" id="CVE-2026-29146" title="CVE-2026-29146" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32990&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32990" id="CVE-2026-32990" title="CVE-2026-32990" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34483&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34483" id="CVE-2026-34483" title="CVE-2026-34483" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34486&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34486" id="CVE-2026-34486" title="CVE-2026-34486" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34487&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34487" id="CVE-2026-34487" title="CVE-2026-34487" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-34500&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-34500" id="CVE-2026-34500" title="CVE-2026-34500" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41284&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41284" id="CVE-2026-41284" title="CVE-2026-41284" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41293&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41293" id="CVE-2026-41293" title="CVE-2026-41293" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42498&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42498" id="CVE-2026-42498" title="CVE-2026-42498" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43512&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43512" id="CVE-2026-43512" title="CVE-2026-43512" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43513&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43513" id="CVE-2026-43513" title="CVE-2026-43513" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43514&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43514" id="CVE-2026-43514" title="CVE-2026-43514" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-43515&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-43515" id="CVE-2026-43515" title="CVE-2026-43515" type="cve"></reference>
		</references>
		<description>CVE-2026-24733:Improper Input Validation vulnerability in Apache Tomcat.&#xA;&#xA;&#xA;Tomcat did not limit HTTP/0.9 requests to the GET method. If a security &#xA;constraint was configured to allow HEAD requests to a URI but deny GET &#xA;requests, the user could bypass that constraint on GET requests by &#xA;sending a (specification invalid) HEAD request using HTTP/0.9.&#xA;&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0.M1 through 9.0.112.&#xA;&#xA;&#xA;Older, EOL versions are also affected.&#xA;&#xA;Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue.&#xA;CVE-2026-24734:Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat.&#xA;&#xA;When using an OCSP responder, Tomcat Native (and Tomcat&#39;s FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed.&#xA;&#xA;This issue affects Apache Tomcat Native:  from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114.&#xA;&#xA;&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected.&#xA;&#xA;Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue.&#xA;&#xA;Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue.&#xA;CVE-2025-66614:Improper Input Validation vulnerability.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.&#xA;&#xA;The following versions were EOL at the time the CVE was created but are &#xA;known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected.&#xA;Tomcat did not validate that the host name provided via the SNI &#xA;extension was the same as the host name provided in the HTTP host header &#xA;field. If Tomcat was configured with more than one virtual host and the &#xA;TLS configuration for one of those hosts did not require client &#xA;certificate authentication but another one did, it was possible for a &#xA;client to bypass the client certificate authentication by sending &#xA;different host names in the SNI extension and the HTTP host header field.&#xA;&#xA;&#xA;&#xA;The vulnerability only applies if client certificate authentication is &#xA;only enforced at the Connector. It does not apply if client certificate &#xA;authentication is enforced at the web application.&#xA;&#xA;&#xA;Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.&#xA;CVE-2026-24880:Inconsistent Interpretation of HTTP Requests (&#39;HTTP Request/Response Smuggling&#39;) vulnerability in Apache Tomcat via invalid chunk extension.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M1 through 9.0.115, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.&#xA;Other, unsupported versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to version 11.0.20, 10.1.52 or 9.0.116, which fix the issue.&#xA;CVE-2026-25854:Occasional URL redirection to untrusted Site (&#39;Open Redirect&#39;) vulnerability in Apache Tomcat via the LoadBalancerDrainingValve.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M23 through 9.0.115, from 8.5.30 through 8.5.100.&#xA;Other, unsupported versions may also be affected&#xA;&#xA;Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.&#xA;CVE-2026-29129:Configured cipher preference order not preserved vulnerability in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.16 through 11.0.18, from 10.1.51 through 10.1.52, from 9.0.114 through 9.0.115.&#xA;&#xA;Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.&#xA;CVE-2026-29145:CLIENT_CERT authentication does not fail as expected for some scenarios when soft fail is disabled vulnerability in Apache Tomcat, Apache Tomcat Native.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M7 through 10.1.52, from 9.0.83 through 9.0.115; Apache Tomcat Native: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39, from 1.3.0 through 1.3.6, from 2.0.0 through 2.0.13.&#xA;&#xA;Users are recommended to upgrade to version Tomcat Native 1.3.7 or 2.0.14 and Tomcat 11.0.20, 10.1.53 and 9.0.116, which fix the issue.&#xA;CVE-2026-29146:Padding Oracle vulnerability in Apache Tomcat&#39;s EncryptInterceptor with default configuration.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.0.0-M1 through 10.1.52, from 9.0.13 through 9..115, from 8.5.38 through 8.5.100, from 7.0.100 through 7.0.109.&#xA;&#xA;Users are recommended to upgrade to version 11.0.19, 10.1.53 and 9.0.116, which fixes the issue.&#xA;CVE-2026-32990:Improper Input Validation vulnerability in Apache Tomcat due to an incomplete fix of CVE-2025-66614.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.15 through 11.0.19, from 10.1.50 through 10.1.52, from 9.0.113 through 9.0.115.&#xA;&#xA;Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.&#xA;CVE-2026-34483:Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116.&#xA;&#xA;Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue.&#xA;CVE-2026-34486:Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146 allowing the bypass of the EncryptInterceptor.&#xA;&#xA;This issue affects Apache Tomcat: 11.0.20, 10.1.53, 9.0.116.&#xA;&#xA;Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.&#xA;CVE-2026-34487:Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.&#xA;&#xA;Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.&#xA;CVE-2026-34500:CLIENT_CERT authentication does not fail as expected for some scenarios when soft fail is disabled and FFM is used in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M14 through 11.0.20, from 10.1.22 through 10.1.53, from 9.0.92 through 9.0.116.&#xA;&#xA;Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fixes the issue.&#xA;CVE-2026-41284:Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117.&#xA;Older, unsupported versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.&#xA;CVE-2026-41293:Improper Input Validation vulnerability in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 10.0.0-M1 through 10.0.27.&#xA;Older, end of support versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.&#xA;CVE-2026-42498:Exposure of HTTP Authentication Header to unexpected hosts during WebSocket authentication vulnerability in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.2 through 9.0.117, from 8.5.24 through 8.5.100, from 7.0.83 through 7.0.109.&#xA;&#xA;Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118, which fix the issue.&#xA;CVE-2026-43512:DEPRECATED: Authentication Bypass Issues vulnerability in digest authentication in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from before 7.0.0.&#xA;Older unsupported versions any also be affect&#xA;&#xA;Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.&#xA;CVE-2026-43513:Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.&#xA;Older unsupported versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.&#xA;CVE-2026-43514:Observable Timing Discrepancy vulnerability when comparing AJP secret in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.&#xA;Older unsupported versions may also be affected.&#xA;&#xA;Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.&#xA;CVE-2026-43515:Improper Authorization vulnerability when multiple method constraints define an HTTP method for the same extension in Apache Tomcat.&#xA;&#xA;This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.&#xA;&#xA;Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="1" name="tomcat" release="1.u21" version="9.0.118">
					<filename>tomcat-9.0.118-1.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tomcat-9.0.118-1.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-help" release="1.u21" version="9.0.118">
					<filename>tomcat-help-9.0.118-1.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tomcat-help-9.0.118-1.u21.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="tomcat-jsvc" release="1.u21" version="9.0.118">
					<filename>tomcat-jsvc-9.0.118-1.u21.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/tomcat-jsvc-9.0.118-1.u21.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3220</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-32792&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-32792" id="CVE-2026-32792" title="CVE-2026-32792" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42534&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42534" id="CVE-2026-42534" title="CVE-2026-42534" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42923&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42923" id="CVE-2026-42923" title="CVE-2026-42923" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-44390&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-44390" id="CVE-2026-44390" title="CVE-2026-44390" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33278&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33278" id="CVE-2026-33278" title="CVE-2026-33278" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41292&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41292" id="CVE-2026-41292" title="CVE-2026-41292" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42959&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42959" id="CVE-2026-42959" title="CVE-2026-42959" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-42960&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-42960" id="CVE-2026-42960" title="CVE-2026-42960" type="cve"></reference>
		</references>
		<description>CVE-2026-32792:NLnet Labs Unbound 1.6.2 up to and including version 1.25.0 has a denial of service vulnerability when compiled with DNSCrypt support (&#39;--enable-dnscrypt&#39;). A bad DNSCrypt query could underflow Unbound&#39;s DNSCrypt packet reading procedure that may lead to heap overflow. A malicious actor can exploit the vulnerability with a single bad DNSCrypt query that its decrypted plaintext consists entirely of &#39;0x00&#39; bytes and does not contain the expected &#39;0x80&#39; marker. Unbound would then start reading more bytes than necessary until it finds a non-&#39;0x00&#39; byte. Based on the underlying memory allocator and the memory layout, it could lead to heap overflow while reading followed by a crash. Likelihood of a crash is low, since it relies heavily on the underlying memory allocator and the memory layout. If the heap overflow does not happen, Unbound&#39;s later packet checks will deny the packet. Unbound 1.25.1 contains a patch with a fix to bound reading in the given buffer space.&#xA;CVE-2026-42534:NLnet Labs Unbound up to and including version 1.25.0 has a vulnerability in the jostle logic that could defeat its purpose and degrade resolution performance. Retransmits of the same query could renew the age of slow running queries and not allow the jostle logic to see them as aged and potential targets for replacement with new queries. An adversary who can query a vulnerable Unbound and who can control a domain name server that replies slowly and/or maliciously to Unbound&#39;s queries can exploit the vulnerability and degrade the resolution performance of Unbound. When Unbound&#39;s &#39;num-queries-per-thread&#39; reaches its limit, the jostle logic kicks in. When a new query comes in, half of the available queries that are also slow to resolve are candidates for replacement. The vulnerability then happens because duplicate queries that need resolution would skew the aging result by using the timestamp of the latest duplicate query instead of the original one that started the resolution effort. Cache and local data response performance remains unaffected. Coordinated attacks could raise this to a denial of resolution service. Unbound 1.25.1 contains a patch with a fix to attach an initial, non-updatable start time for incoming queries that allow the jostle logic to work as intended.&#xA;CVE-2026-42923:NLnet Labs Unbound up to and including version 1.25.0 has a vulnerability in the DNSSEC validator where the code path to consult the negative cache for DS records does not take into account the limit on NSEC3 hash calculations introduced in 1.19.1. This leads to degradation of service during the attack. An adversary that controls a DNSSEC signed zone can exploit this by signing NSEC3 records with acceptably high iterations for child delegations and querying a vulnerable Unbound. Unbound will keep performing the allowed hash calculations on the NSEC3 records and will not limit the work by the mitigation introduced in 1.19.1. As a side effect, a global lock for the negative cache will be held for the duration of the hashing, blocking other threads that need to consult the negative cache. Coordinated attacks could raise the vulnerability to denial of service. Unbound 1.25.1 contains a patch with a fix to bound the vulnerable code path with the existing limit for NSEC3 hash calculations.&#xA;CVE-2026-44390:NLnet Labs Unbound up to and including version 1.25.0 has a vulnerability when handling replies with very large RRsets that Unbound needs to perform name compression for. Malicious upstream responses with very large RRsets with records that don&#39;t share a suffix above the root can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. An adversary can exploit the vulnerability by querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. A compression limit was introduced in 1.21.1 for this but it didn&#39;t account for the case where records would not share any suffix above the root. That causes Unbound to go in a different code path because of the compression tree lookup failure and eventually not increment the compression counter for those operations. Unbound 1.25.1 contains a patch with a fix that increments the compression counter regardless of the compression tree lookup. This is a complement fix to CVE-2024-8508.&#xA;CVE-2026-33278:NLnet Labs Unbound 1.19.1 up to and including version 1.25.0 has a vulnerability in the DNSSEC validator that enables denial of service and possible remote code execution as a result of deep copying a data structure and erroneously overwriting a destination pointer. An adversary can exploit the vulnerability by controlling a malicious signed zone and querying a vulnerable Unbound. When DS sub-queries need to suspend validation due to NSEC3 computational budget exhaustion (introduced in Unbound 1.19.1), Unbound deep-copies response messages to preserve them across memory region teardown. A struct-assignment bug overwrites the destination&#39;s pointer with the source&#39;s pointer. After the sub-query region is freed, the resumed validator dereferences this dangling pointer, triggering a crash or potentially enabling arbitrary code execution. Unbound 1.25.1 contains a patch with a fix to preserve the correct pointer when deep copying the data structure.&#xA;CVE-2026-41292:NLnet Labs Unbound up to and including version 1.25.0 is vulnerable to a degradation of service attack related to parsing long lists of incoming EDNS options. An adversary sending queries with too many EDNS options can hold Unbound threads hostage while they are parsing and creating internal data structures for the options. Coordinated attacks can result in degradation and/or denial of service. Unbound 1.25.1 contains a patch with a fix to limit acceptable incoming EDNS options (100).&#xA;CVE-2026-42959:NLnet Labs Unbound up to and including version 1.25.0 has a denial of service vulnerability in the DNSSEC validator that can lead to a crash given malicious upstream replies. When Unbound constructs chase-reply messages for validation, the code uses the wrong counter to calculate write offsets for ADDITIONAL section rrsets. DNAME duplication could increase the ANSWER section count and authority filtering could decrease the AUTHORITY section count and create an uninitialized array slot. Combining these two, the validator later dereferences this uninitialized pointer, causing an immediate process crash. An adversary controlling a DNSSEC-signed domain can trigger this bug with a single query by configuring a DNAME chain with unsigned CNAMEs and a response containing unsigned AUTHORITY records alongside signed ADDITIONAL glue records. Unbound 1.25.1 contains a patch with a fix to use the proper counters to calculate the write offsets.&#xA;CVE-2026-42960:NLnet Labs Unbound up to and including version 1.25.0 is vulnerable to poisoning via promiscuous records for the authority section. Promiscuous RRSets that complement DNS replies in the authority section can be used to trick Unbound to cache such records. If an adversary is able to attach such records in a reply (i.e., spoofed packet, fragmentation attack) he would be able to poison Unbound&#39;s cache. A malicious actor can exploit the possible poisonous effect by injecting RRSets other than NS that are also accompanied by address records in a reply, for example MX. This could be achieved by trying to spoof a reply packet or fragmentation attacks. Unbound would then accept the relative address records in the additional section and cache them if the authority RRSet has enough trust at this point, i.e., in-zone data for the delegation point. Unbound 1.25.1 contains a patch with a fix that disregards address records from the additional section if they are not explicitly relevant only to authority NS records, mitigating the possible poison effect. This is a complement fix to CVE-2025-11411.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="unbound-anchor" release="22.u12" version="1.13.2">
					<filename>unbound-anchor-1.13.2-22.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/unbound-anchor-1.13.2-22.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="22.u12" version="1.13.2">
					<filename>unbound-libs-1.13.2-22.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/unbound-libs-1.13.2-22.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="22.u12" version="1.13.2">
					<filename>unbound-1.13.2-22.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/unbound-1.13.2-22.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="22.u12" version="1.13.2">
					<filename>unbound-devel-1.13.2-22.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/unbound-devel-1.13.2-22.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="22.u12" version="1.13.2">
					<filename>unbound-help-1.13.2-22.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/unbound-help-1.13.2-22.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="22.u12" version="1.13.2">
					<filename>python3-unbound-1.13.2-22.u12.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-unbound-1.13.2-22.u12.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="22.u12" version="1.13.2">
					<filename>unbound-help-1.13.2-22.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/unbound-help-1.13.2-22.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="22.u12" version="1.13.2">
					<filename>python3-unbound-1.13.2-22.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-unbound-1.13.2-22.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound" release="22.u12" version="1.13.2">
					<filename>unbound-1.13.2-22.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/unbound-1.13.2-22.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-anchor" release="22.u12" version="1.13.2">
					<filename>unbound-anchor-1.13.2-22.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/unbound-anchor-1.13.2-22.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="22.u12" version="1.13.2">
					<filename>unbound-devel-1.13.2-22.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/unbound-devel-1.13.2-22.u12.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="22.u12" version="1.13.2">
					<filename>unbound-libs-1.13.2-22.u12.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/unbound-libs-1.13.2-22.u12.fos23.x86_64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3221</id>
		<title>An update for git is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66413&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66413" id="CVE-2025-66413" title="CVE-2025-66413" type="cve"></reference>
		</references>
		<description>CVE-2025-66413:Git for Windows is the Windows port of Git. Prior to 2.53.0(2), it is possible to obtain a user&#39;s NTLM hash by tricking them into cloning from a malicious server. Since NTLM hashing is weak, it is possible for the attacker to brute-force the user&#39;s account name and password. This vulnerability is fixed in 2.53.0(2).&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="git-daemon" release="21.u8" version="2.33.0">
					<filename>git-daemon-2.33.0-21.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/git-daemon-2.33.0-21.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git-core" release="21.u8" version="2.33.0">
					<filename>git-core-2.33.0-21.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/git-core-2.33.0-21.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="git" release="21.u8" version="2.33.0">
					<filename>git-2.33.0-21.u8.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/git-2.33.0-21.u8.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git" release="21.u8" version="2.33.0">
					<filename>git-2.33.0-21.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-2.33.0-21.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-core" release="21.u8" version="2.33.0">
					<filename>git-core-2.33.0-21.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-core-2.33.0-21.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="git-daemon" release="21.u8" version="2.33.0">
					<filename>git-daemon-2.33.0-21.u8.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-daemon-2.33.0-21.u8.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-help" release="21.u8" version="2.33.0">
					<filename>git-help-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-help-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git-SVN" release="21.u8" version="2.33.0">
					<filename>perl-Git-SVN-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-Git-SVN-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-svn" release="21.u8" version="2.33.0">
					<filename>git-svn-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-svn-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-web" release="21.u8" version="2.33.0">
					<filename>git-web-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-web-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="perl-Git" release="21.u8" version="2.33.0">
					<filename>perl-Git-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/perl-Git-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-email" release="21.u8" version="2.33.0">
					<filename>git-email-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-email-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="git-gui" release="21.u8" version="2.33.0">
					<filename>git-gui-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/git-gui-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="gitk" release="21.u8" version="2.33.0">
					<filename>gitk-2.33.0-21.u8.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/gitk-2.33.0-21.u8.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3222</id>
		<title>An update for openjpeg2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-6192&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-6192" id="CVE-2026-6192" title="CVE-2026-6192" type="cve"></reference>
		</references>
		<description>CVE-2026-6192:A vulnerability was identified in uclouvain openjpeg up to 2.5.4. This impacts the function opj_pi_initialise_encode in the library src/lib/openjp2/pi.c. The manipulation leads to integer overflow. The attack must be carried out locally. The exploit is publicly available and might be used. The identifier of the patch is 839936aa33eb8899bbbd80fda02796bb65068951. It is suggested to install a patch to address this issue.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="aarch64" epoch="0" name="openjpeg2-devel" release="8.u5" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openjpeg2-devel-2.5.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2-tools" release="8.u5" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openjpeg2-tools-2.5.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="openjpeg2" release="8.u5" version="2.5.0">
					<filename>openjpeg2-2.5.0-8.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/openjpeg2-2.5.0-8.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-devel" release="8.u5" version="2.5.0">
					<filename>openjpeg2-devel-2.5.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openjpeg2-devel-2.5.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2" release="8.u5" version="2.5.0">
					<filename>openjpeg2-2.5.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openjpeg2-2.5.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="openjpeg2-tools" release="8.u5" version="2.5.0">
					<filename>openjpeg2-tools-2.5.0-8.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openjpeg2-tools-2.5.0-8.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="openjpeg2-help" release="8.u5" version="2.5.0">
					<filename>openjpeg2-help-2.5.0-8.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/openjpeg2-help-2.5.0-8.u5.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3223</id>
		<title>An update for python-lxml is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-41066&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-41066" id="CVE-2026-41066" title="CVE-2026-41066" type="cve"></reference>
		</references>
		<description>CVE-2026-41066:lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.0, using either of the two parsers in the default configuration (with resolve_entities=True) allows untrusted XML input to read local files. Setting the resolve_entities option explicitly to resolve_entities=&#39;internal&#39; or resolve_entities=False disables the local file access. This vulnerability is fixed in 6.1.0.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="0" name="python-lxml-help" release="9.u3" version="4.7.1">
					<filename>python-lxml-help-4.7.1-9.u3.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python-lxml-help-4.7.1-9.u3.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="0" name="python3-lxml" release="9.u3" version="4.7.1">
					<filename>python3-lxml-4.7.1-9.u3.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/python3-lxml-4.7.1-9.u3.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="python3-lxml" release="9.u3" version="4.7.1">
					<filename>python3-lxml-4.7.1-9.u3.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/python3-lxml-4.7.1-9.u3.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3224</id>
		<title>An update for haproxy is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2026-33555&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2026-33555" id="CVE-2026-33555" title="CVE-2026-33555" type="cve"></reference>
		</references>
		<description>CVE-2026-33555:An issue was discovered in HAProxy before 3.3.6. The HTTP/3 parser does not check that the received body length matches a previously announced content-length when the stream is closed via a frame with an empty payload. This can cause desynchronization issues with the backend server and could be used for request smuggling. The earliest affected version is 2.6.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="x86_64" epoch="0" name="haproxy" release="19.u17" version="2.6.6">
					<filename>haproxy-2.6.6-19.u17.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/haproxy-2.6.6-19.u17.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="0" name="haproxy" release="19.u17" version="2.6.6">
					<filename>haproxy-2.6.6-19.u17.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/haproxy-2.6.6-19.u17.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="noarch" epoch="0" name="haproxy-help" release="19.u17" version="2.6.6">
					<filename>haproxy-help-2.6.6-19.u17.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/haproxy-help-2.6.6-19.u17.fos23.noarch.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" status="stable" type="security">
		<id>FusionOS-SA-2026-3225</id>
		<title>An update for openjdk-1.8.0 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS 23</release>
		<issued date="2026-06-09"></issued>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30698&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30698" id="CVE-2025-30698" title="CVE-2025-30698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30691" id="CVE-2025-30691" title="CVE-2025-30691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21587&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21587" id="CVE-2025-21587" title="CVE-2025-21587" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30698&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30698" id="CVE-2025-30698" title="CVE-2025-30698" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30691&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-30691" id="CVE-2025-30691" title="CVE-2025-30691" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21587&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-21587" id="CVE-2025-21587" title="CVE-2025-21587" type="cve"></reference>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-66293&#xA;https://www.cnnvd.org.cn/home/globalSearch?keyword=CVE-2025-66293" id="CVE-2025-66293" title="CVE-2025-66293" type="cve"></reference>
		</references>
		<description>CVE-2025-30698:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK: 17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition: 20.3.17 and  21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.6 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).&#xA;CVE-2025-30691:Vulnerability in Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 21.0.6, 24; Oracle GraalVM for JDK: 21.0.6 and  24. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data as well as  unauthorized read access to a subset of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2025-21587:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE:8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK:17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition:20.3.17 and  21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2025-30698:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK: 17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition: 20.3.17 and  21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.6 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).&#xA;CVE-2025-30691:Vulnerability in Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 21.0.6, 24; Oracle GraalVM for JDK: 21.0.6 and  24. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data as well as  unauthorized read access to a subset of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).&#xA;CVE-2025-21587:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE:8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK:17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition:20.3.17 and  21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).&#xA;CVE-2025-66293:LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng&#39;s simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng&#39;s internal state management. Upgrade to libpng 1.6.52 or later.&#xA;</description>
		<pkglist>
			<collection>
				<name>23.3.10</name>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.482.b08-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-javadoc-zip-1.8.0.482.b08-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.482.b08-7.u5.fos23.noarch.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-javadoc-1.8.0.482.b08-7.u5.fos23.noarch.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-devel-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-src-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-src-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-demo-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-demo-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-headless-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-headless-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-accessibility-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-headless-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-src-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-demo-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-devel-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-devel-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/x86_64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.482.b08-7.u5.fos23.x86_64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-src-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-src-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-headless-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-headless-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-demo-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-demo-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-devel-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-devel-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-accessibility-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-demo-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-devel-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-devel-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-src-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-headless-slowdebug-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="7.u5" version="1.8.0.482.b08">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</filename>
					<file_url>https://repo.xfusion.com/FusionOS/FusionOS-23_23.0/update/aarch64/Packages-23.3.10/java-1.8.0-openjdk-openjfx-1.8.0.482.b08-7.u5.fos23.aarch64.rpm</file_url>
				</package>
			</collection>
		</pkglist>
	</update>
</updates>